From Tina.Tsou.Zouting@huawei.com Mon Dec 5 17:04:01 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBA31F0C35; Mon, 5 Dec 2011 17:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZmKnwcqaV8M; Mon, 5 Dec 2011 17:04:01 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 325C51F0C34; Mon, 5 Dec 2011 17:04:01 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVR008ZYCAO85@szxga03-in.huawei.com>; Tue, 06 Dec 2011 09:04:00 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVR007QUCAG2Y@szxga03-in.huawei.com>; Tue, 06 Dec 2011 09:04:00 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFK77994; Tue, 06 Dec 2011 09:04:00 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Dec 2011 09:03:58 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 06 Dec 2011 09:03:51 +0800 Date: Tue, 06 Dec 2011 01:03:51 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.145] To: "multrans@ietf.org" , MBONED WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Draft agenda for multicast transition interim Thread-index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 01:04:01 -0000 Dear all, It is proposed to hold the multicast transition interim meeting as a series of short meetings. Timing of individual meetings may be set to spread inconvenient hours around the globe. The objective of these meetings is to achieve technical progress in the indicated topics. Here is the proposed agenda: 1. Use Cases (1 hour) Ensure we are all clear on what use cases will be in scope. 2. Multicast address discovery by the receiver (2 hours) How does the receiver learn the multicast addresses corresponding to specific programs, in the IP version that the receiver understands? 3. Multicast address translation (2 hours) Stateless translation between IPv4 and IPv6 addresses should get priority in this discussion, but we may go on to the broader topic if there appears to be a need. 4. What and how an adaptation function between the receiver and the network works (2 hours) In cases where the receiver and the multicast-enabled network to which it is attached support different IP versions, an adaptation function (AF) is required between them. What are the requirements on that AF for the handling of multicast signalling and the handling of multicast content? 5. What and how an adaptation function between two networks works (2 hours) In cases where two adjacent multicast-enabled networks support different IP versions, another type of adaptation function is needed. What are the requirements on that AF for the handling of multicast signalling and the handling of multicast content? Comments on this draft agenda are invited. Tina From Tina.Tsou.Zouting@huawei.com Mon Dec 5 20:00:15 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D86D1F0C82; Mon, 5 Dec 2011 20:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9wsxWzpRZ3m; Mon, 5 Dec 2011 20:00:14 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 982701F0C77; Mon, 5 Dec 2011 20:00:14 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVR005H1KENVR@szxga05-in.huawei.com>; Tue, 06 Dec 2011 11:59:11 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVR00IS0KEMK6@szxga05-in.huawei.com>; Tue, 06 Dec 2011 11:59:11 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFO63585; Tue, 06 Dec 2011 11:59:10 +0800 Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Dec 2011 11:59:08 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.003; Tue, 06 Dec 2011 11:59:02 +0800 Date: Tue, 06 Dec 2011 03:59:01 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.145] To: "multrans@ietf.org" , MBONED WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Draft agenda v1.1 for multicast transition interim Thread-index: Acyzy2PE9TsV4sZQSmyPCMvy3bXRBg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [multrans] Draft agenda v1.1 for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 04:00:15 -0000 Dear all, It is proposed to hold the multicast transition interim meeting as a series of short meetings. Timing of individual meetings may be set to spread inconvenient hours around the globe. The objective of these meetings is to achieve technical progress in the indicated topics. Here is the proposed agenda: 1. Use Cases (1 hour) Ensure we are all clear on what use cases will be in scope. 2. Multicast address discovery by the receiver (2 hours) How does the receiver learn the multicast addresses corresponding to specific programs, in the IP version that the receiver understands? 3. Multicast address translation (2 hours) Stateless translation between IPv4 and IPv6 addresses should get priority in this discussion, but we may go on to the broader topic if there appears to be a need. 4. Specification of an adaptation function between the receiver and the network (2 hours) In cases where the receiver and the multicast-enabled network to which it is attached support different IP versions, an adaptation function (AF) is required between them. What are the requirements on that AF for the handling of multicast signalling and the handling of multicast content? 5. Specification of an adaptation function between two networks (2 hours) In cases where two adjacent multicast-enabled networks support different IP versions, another type of adaptation function is needed. What are the requirements on that AF for the handling of multicast signalling and the handling of multicast content? Comments on this draft agenda are invited. Tina From stig@venaas.com Mon Dec 5 20:04:39 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099641F0C7D; Mon, 5 Dec 2011 20:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y09G-JCEzQZ2; Mon, 5 Dec 2011 20:04:38 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 64ACB21F8A96; Mon, 5 Dec 2011 20:04:38 -0800 (PST) Received: from [10.21.119.5] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 48BF77FE2; Tue, 6 Dec 2011 05:04:30 +0100 (CET) Message-ID: <4EDD941D.2050801@venaas.com> Date: Mon, 05 Dec 2011 20:03:41 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tina TSOU References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MBONED WG , "multrans@ietf.org" Subject: Re: [multrans] Draft agenda v1.1 for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 04:04:39 -0000 On 05.12.2011 19:59, Tina TSOU wrote: > Dear all, > It is proposed to hold the multicast transition interim meeting as a series of short meetings. Timing of individual meetings may be set to spread inconvenient hours around the globe. The objective of these meetings is to achieve technical progress in the indicated topics. Here is the proposed agenda: > > 1. Use Cases (1 hour) > > Ensure we are all clear on what use cases will be in scope. > > > 2. Multicast address discovery by the receiver (2 hours) > > How does the receiver learn the multicast addresses corresponding to specific programs, in the IP version that the receiver understands? > > > 3. Multicast address translation (2 hours) > > Stateless translation between IPv4 and IPv6 addresses should get > priority in this discussion, but we may go on to the broader topic if > there appears to be a need. > > > 4. Specification of an adaptation function between the receiver and the network (2 hours) > > In cases where the receiver and the multicast-enabled network to which > it is attached support different IP versions, an adaptation function > (AF) is required between them. What are the requirements on that AF for > the handling of multicast signalling and the handling of multicast content? > > 5. Specification of an adaptation function between two networks (2 hours) > > In cases where two adjacent multicast-enabled networks support different > IP versions, another type of adaptation function is needed. What are the > requirements on that AF for the handling of multicast signalling and the > handling of multicast content? > > Comments on this draft agenda are invited. Looks quite good. Multiple short meetings seems like a good idea. Stig > > Tina > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans From rbonica@juniper.net Tue Dec 6 10:51:34 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32A721F8BBA; Tue, 6 Dec 2011 10:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZxDFoUWfVts; Tue, 6 Dec 2011 10:51:34 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id B937321F8BB9; Tue, 6 Dec 2011 10:51:32 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTt5kKH0jMNPyIdEMN2SDjgIdp8HhZkwf@postini.com; Tue, 06 Dec 2011 10:51:33 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Dec 2011 10:44:14 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 6 Dec 2011 13:44:12 -0500 From: Ronald Bonica To: Tina TSOU , "multrans@ietf.org" , MBONED WG Date: Tue, 6 Dec 2011 13:44:12 -0500 Thread-Topic: Draft agenda for multicast transition interim Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwA= Message-ID: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 18:51:34 -0000 Hi Tina, Thanks for the proposed agenda. A few comments are inline. Ron > -----Original Message----- > From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On > Behalf Of Tina TSOU > Sent: Monday, December 05, 2011 8:04 PM > To: multrans@ietf.org; MBONED WG > Subject: [multrans] Draft agenda for multicast transition interim >=20 > Dear all, > It is proposed to hold the multicast transition interim meeting as a > series of short meetings. Timing of individual meetings may be set to > spread inconvenient hours around the globe. The objective of these > meetings is to achieve technical progress in the indicated topics. Here > is the proposed agenda: >=20 > 1. Use Cases (1 hour) >=20 > Ensure we are all clear on what use cases will be in scope. We might want to call the first agenda item "Overview" instead of "Use Case= s". IMHO, the Overview contains the following parts: - an introduction to the problem space - an introduction to the solution space The crux of the problem is that multicast connectivity is required among th= e following host types: - dual-stack - IPv4-only - IPv6-only Therefore, multicast data and signaling will need to traverse IPv4/IPv6 bou= ndaries. The IPv4/IPv6 boundary may be adjacent to the source, at any point= between the source and destination, or adjacent to the destination. For so= me network topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6 boun= dary crossings may be required. For the purpose of this exercise, all netwo= rk segments are assumed to be multicast enabled. (You can talk about use cases here, but you probably don't want to enumerat= e every possible use-case. Talk about a use case only if it introduces new = requirements for the adaptation function that will be deployed at the IPv4/= IPv6 boundary). The solution space contains: - a source discovery solution - a multicast address mapping solution - an adaptation function solution More on each of those, below. It would be great if we had a short draft t= o review before the first Interim meeting. >=20 >=20 > 2. Multicast address discovery by the receiver (2 hours) >=20 > How does the receiver learn the multicast addresses corresponding to > specific programs, in the IP version that the receiver understands? We might want to call this Multicast Source Discovery. The following are a = few interesting questions: - How are multicast sources identified? - How dynamic is the Source Discovery Mechanism? Does it simple discover an= d announce every multicast stream in the network or is registration require= d? - How do we ensure that the scope of the Source discovery mechanism is the = same as the scope of the multicast network? - Can the Source Discovery mechanism be crafted from existing protocols? Again, it would be great if we had a draft to work from. >=20 >=20 > 3. Multicast address translation (2 hours) >=20 > Stateless translation between IPv4 and IPv6 addresses should get > priority in this discussion, but we may go on to the broader topic if > there appears to be a need. What broader topic? Stateful translation? Why go there? >=20 >=20 > 4. What and how an adaptation function between the receiver and the > network works (2 hours) >=20 > In cases where the receiver and the multicast-enabled network to which > it is attached support different IP versions, an adaptation function > (AF) is required between them. What are the requirements on that AF for > the handling of multicast signalling and the handling of multicast > content? >=20 > 5. What and how an adaptation function between two networks works (2 > hours) >=20 > In cases where two adjacent multicast-enabled networks support > different > IP versions, another type of adaptation function is needed. What are > the > requirements on that AF for the handling of multicast signalling and > the > handling of multicast content? >=20 > Comments on this draft agenda are invited. >=20 > Tina > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans From mohamed.boucadair@orange.com Wed Dec 7 04:07:34 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DDE21F8B94; Wed, 7 Dec 2011 04:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXR-giGC22oa; Wed, 7 Dec 2011 04:07:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E65A321F8B02; Wed, 7 Dec 2011 04:07:33 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6D7573247EC; Wed, 7 Dec 2011 13:07:32 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 52EC135C055; Wed, 7 Dec 2011 13:07:32 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Wed, 7 Dec 2011 13:07:32 +0100 From: To: Ronald Bonica , Tina TSOU , "multrans@ietf.org" , MBONED WG Date: Wed, 7 Dec 2011 13:07:30 +0100 Thread-Topic: Draft agenda for multicast transition interim Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCAAQ+9cA== Message-ID: <94C682931C08B048B7A8645303FDC9F35A8D144894@PUEXCB1B.nanterre.francetelecom.fr> References: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.7.101515 Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 12:07:34 -0000 Dear Ron, all, Please see inline. Cheers, Med=20 > -----Message d'origine----- > De : multrans-bounces@ietf.org=20 > [mailto:multrans-bounces@ietf.org] De la part de Ronald Bonica > Envoy=E9 : mardi 6 d=E9cembre 2011 19:44 > =C0 : Tina TSOU; multrans@ietf.org; MBONED WG > Objet : Re: [multrans] Draft agenda for multicast transition interim >=20 > Hi Tina, >=20 > Thanks for the proposed agenda. A few comments are inline. =20 >=20 > We might want to call the first agenda item "Overview"=20 > instead of "Use Cases". IMHO, the Overview contains the=20 > following parts: >=20 > - an introduction to the problem space > - an introduction to the solution space >=20 > The crux of the problem is that multicast connectivity is=20 > required among the following host types: >=20 > - dual-stack > - IPv4-only > - IPv6-only >=20 > Therefore, multicast data and signaling will need to traverse=20 > IPv4/IPv6 boundaries. The IPv4/IPv6 boundary may be adjacent=20 > to the source, at any point between the source and=20 > destination, or adjacent to the destination. For some network=20 > topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6=20 > boundary crossings may be required. For the purpose of this=20 > exercise, all network segments are assumed to be multicast enabled. >=20 > (You can talk about use cases here, but you probably don't=20 > want to enumerate every possible use-case. Talk about a use=20 > case only if it introduces new requirements for the=20 > adaptation function that will be deployed at the IPv4/IPv6 boundary). >=20 > The solution space contains: >=20 > - a source discovery solution > - a multicast address mapping solution > - an adaptation function solution >=20 > More on each of those, below. It would be great if we had a=20 > short draft to review before the first Interim meeting. Below some pointers which may be of interest: * Address mapping: http://tools.ietf.org/html/draft-boucadair-behave-64-mul= ticast-address-format-03 * Service discovery using SDP (Use Cases): http://tools.ietf.org/html/draft= -boucadair-mmusic-ipv6-use-cases-00#section-3 * Candidate solution for address discovery (SDP ALTC): http://tools.ietf.or= g/html/draft-boucadair-mmusic-altc-04 * Adaptation functions overview: http://tools.ietf.org/html/draft-jaclee-be= have-v4v6-mcast-ps-03#section-4.4 * Unicast/Multicast PREFIX provisioning: http://tools.ietf.org/html/draft-q= in-softwire-multicast-prefix-option-01 Cheers, Med= From rbonica@juniper.net Fri Dec 9 10:31:42 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7AA21F8A57; Fri, 9 Dec 2011 10:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qc7bgtPPFME; Fri, 9 Dec 2011 10:31:41 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2121F88B6; Fri, 9 Dec 2011 10:31:39 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTuJT97ABMjaZb4KRShAFFyJ7eIq4Jvb3@postini.com; Fri, 09 Dec 2011 10:31:41 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Dec 2011 10:28:24 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 9 Dec 2011 13:28:23 -0500 From: Ronald Bonica To: "mohamed.boucadair@orange.com" , "multrans@ietf.org" , MBONED WG Date: Fri, 9 Dec 2011 13:28:21 -0500 Thread-Topic: Draft agenda for multicast transition interim Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCAAQ+9cIADrvDw Message-ID: <13205C286662DE4387D9AF3AC30EF456D74E0D8304@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> <94C682931C08B048B7A8645303FDC9F35A8D144894@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F35A8D144894@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 18:31:42 -0000 Med, draft-boucadair-behave-64-multicast-address-format appears to be pretty wel= l cooked. Maybe the MBONED chairs could ask for a few volunteer reviewers? I will send my comments in a separate email. Ron > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, December 07, 2011 7:08 AM > To: Ronald Bonica; Tina TSOU; multrans@ietf.org; MBONED WG > Subject: RE: Draft agenda for multicast transition interim >=20 > Dear Ron, all, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De : multrans-bounces@ietf.org > > [mailto:multrans-bounces@ietf.org] De la part de Ronald Bonica > > Envoy=E9 : mardi 6 d=E9cembre 2011 19:44 > > =C0 : Tina TSOU; multrans@ietf.org; MBONED WG > > Objet : Re: [multrans] Draft agenda for multicast transition interim > > > > Hi Tina, > > > > Thanks for the proposed agenda. A few comments are inline. >=20 > > > > We might want to call the first agenda item "Overview" > > instead of "Use Cases". IMHO, the Overview contains the > > following parts: > > > > - an introduction to the problem space > > - an introduction to the solution space > > > > The crux of the problem is that multicast connectivity is > > required among the following host types: > > > > - dual-stack > > - IPv4-only > > - IPv6-only > > > > Therefore, multicast data and signaling will need to traverse > > IPv4/IPv6 boundaries. The IPv4/IPv6 boundary may be adjacent > > to the source, at any point between the source and > > destination, or adjacent to the destination. For some network > > topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6 > > boundary crossings may be required. For the purpose of this > > exercise, all network segments are assumed to be multicast enabled. > > > > (You can talk about use cases here, but you probably don't > > want to enumerate every possible use-case. Talk about a use > > case only if it introduces new requirements for the > > adaptation function that will be deployed at the IPv4/IPv6 boundary). > > > > The solution space contains: > > > > - a source discovery solution > > - a multicast address mapping solution > > - an adaptation function solution > > > > More on each of those, below. It would be great if we had a > > short draft to review before the first Interim meeting. >=20 > Below some pointers which may be of interest: >=20 > * Address mapping: http://tools.ietf.org/html/draft-boucadair-behave- > 64-multicast-address-format-03 > * Service discovery using SDP (Use Cases): > http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases- > 00#section-3 > * Candidate solution for address discovery (SDP ALTC): > http://tools.ietf.org/html/draft-boucadair-mmusic-altc-04 > * Adaptation functions overview: http://tools.ietf.org/html/draft- > jaclee-behave-v4v6-mcast-ps-03#section-4.4 > * Unicast/Multicast PREFIX provisioning: > http://tools.ietf.org/html/draft-qin-softwire-multicast-prefix-option- > 01 >=20 >=20 > Cheers, > Med From yiu_lee@cable.comcast.com Fri Dec 9 10:36:12 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE3B21F8A6C; Fri, 9 Dec 2011 10:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdjDNOoNBy4v; Fri, 9 Dec 2011 10:36:12 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id C86E421F88B6; Fri, 9 Dec 2011 10:36:11 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.63414289; Fri, 09 Dec 2011 11:37:02 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Fri, 9 Dec 2011 13:36:05 -0500 From: "Lee, Yiu" To: Ronald Bonica , "mohamed.boucadair@orange.com" , "multrans@ietf.org" , MBONED WG Thread-Topic: [multrans] Draft agenda for multicast transition interim Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCAAQ+9cIADrvDwgAAC14A= Date: Fri, 9 Dec 2011 18:36:04 +0000 Message-ID: In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E0D8304@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 18:36:12 -0000 Hi Ron, We also have a question which WG would like to be home for this draft. We have couple of WG drafts relying on this in Softwire. We presented it in BEHAVE w/o much response. We would like to hear from the IESG where this draft should belong. Regards, Yiu On 12/9/11 1:28 PM, "Ronald Bonica" wrote: >Med, > >draft-boucadair-behave-64-multicast-address-format appears to be pretty >well cooked. Maybe the MBONED chairs could ask for a few volunteer >reviewers? > >I will send my comments in a separate email. > > Ron > > >> -----Original Message----- >> From: mohamed.boucadair@orange.com >> [mailto:mohamed.boucadair@orange.com] >> Sent: Wednesday, December 07, 2011 7:08 AM >> To: Ronald Bonica; Tina TSOU; multrans@ietf.org; MBONED WG >> Subject: RE: Draft agenda for multicast transition interim >>=20 >> Dear Ron, all, >>=20 >> Please see inline. >>=20 >> Cheers, >> Med >>=20 >> > -----Message d'origine----- >> > De : multrans-bounces@ietf.org >> > [mailto:multrans-bounces@ietf.org] De la part de Ronald Bonica >> > Envoy=E9 : mardi 6 d=E9cembre 2011 19:44 >> > =C0 : Tina TSOU; multrans@ietf.org; MBONED WG >> > Objet : Re: [multrans] Draft agenda for multicast transition interim >> > >> > Hi Tina, >> > >> > Thanks for the proposed agenda. A few comments are inline. >>=20 >> > >> > We might want to call the first agenda item "Overview" >> > instead of "Use Cases". IMHO, the Overview contains the >> > following parts: >> > >> > - an introduction to the problem space >> > - an introduction to the solution space >> > >> > The crux of the problem is that multicast connectivity is >> > required among the following host types: >> > >> > - dual-stack >> > - IPv4-only >> > - IPv6-only >> > >> > Therefore, multicast data and signaling will need to traverse >> > IPv4/IPv6 boundaries. The IPv4/IPv6 boundary may be adjacent >> > to the source, at any point between the source and >> > destination, or adjacent to the destination. For some network >> > topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6 >> > boundary crossings may be required. For the purpose of this >> > exercise, all network segments are assumed to be multicast enabled. >> > >> > (You can talk about use cases here, but you probably don't >> > want to enumerate every possible use-case. Talk about a use >> > case only if it introduces new requirements for the >> > adaptation function that will be deployed at the IPv4/IPv6 boundary). >> > >> > The solution space contains: >> > >> > - a source discovery solution >> > - a multicast address mapping solution >> > - an adaptation function solution >> > >> > More on each of those, below. It would be great if we had a >> > short draft to review before the first Interim meeting. >>=20 >> Below some pointers which may be of interest: >>=20 >> * Address mapping: http://tools.ietf.org/html/draft-boucadair-behave- >> 64-multicast-address-format-03 >> * Service discovery using SDP (Use Cases): >> http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases- >> 00#section-3 >> * Candidate solution for address discovery (SDP ALTC): >> http://tools.ietf.org/html/draft-boucadair-mmusic-altc-04 >> * Adaptation functions overview: http://tools.ietf.org/html/draft- >> jaclee-behave-v4v6-mcast-ps-03#section-4.4 >> * Unicast/Multicast PREFIX provisioning: >> http://tools.ietf.org/html/draft-qin-softwire-multicast-prefix-option- >> 01 >>=20 >>=20 >> Cheers, >> Med >_______________________________________________ >multrans mailing list >multrans@ietf.org >https://www.ietf.org/mailman/listinfo/multrans From rbonica@juniper.net Fri Dec 9 11:15:46 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29421F86A5; Fri, 9 Dec 2011 11:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BitEC8dRV8me; Fri, 9 Dec 2011 11:15:45 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 705A421F8531; Fri, 9 Dec 2011 11:15:41 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTuJeUWejUikTjdCHLXbAnIQCaWGvMG8T@postini.com; Fri, 09 Dec 2011 11:15:45 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Dec 2011 11:14:03 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 9 Dec 2011 14:14:02 -0500 From: Ronald Bonica To: "Lee, Yiu" , "mohamed.boucadair@orange.com" , "multrans@ietf.org" , MBONED WG Date: Fri, 9 Dec 2011 14:14:00 -0500 Thread-Topic: [multrans] Draft agenda for multicast transition interim Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCAAQ+9cIADrvDwgAAC14CAAAploA== Message-ID: <13205C286662DE4387D9AF3AC30EF456D74E19E481@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D74E0D8304@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 19:15:46 -0000 This was proposed as part of the MULTRANS solution, so it is a candidate fo= r adoption in MBONED. Ron > -----Original Message----- > From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] > Sent: Friday, December 09, 2011 1:36 PM > To: Ronald Bonica; mohamed.boucadair@orange.com; multrans@ietf.org; > MBONED WG > Subject: Re: [multrans] Draft agenda for multicast transition interim >=20 > Hi Ron, >=20 > We also have a question which WG would like to be home for this draft. > We > have couple of WG drafts relying on this in Softwire. We presented it > in > BEHAVE w/o much response. We would like to hear from the IESG where > this > draft should belong. >=20 > Regards, > Yiu >=20 > On 12/9/11 1:28 PM, "Ronald Bonica" wrote: >=20 > >Med, > > > >draft-boucadair-behave-64-multicast-address-format appears to be > pretty > >well cooked. Maybe the MBONED chairs could ask for a few volunteer > >reviewers? > > > >I will send my comments in a separate email. > > > > Ron > > > > > >> -----Original Message----- > >> From: mohamed.boucadair@orange.com > >> [mailto:mohamed.boucadair@orange.com] > >> Sent: Wednesday, December 07, 2011 7:08 AM > >> To: Ronald Bonica; Tina TSOU; multrans@ietf.org; MBONED WG > >> Subject: RE: Draft agenda for multicast transition interim > >> > >> Dear Ron, all, > >> > >> Please see inline. > >> > >> Cheers, > >> Med > >> > >> > -----Message d'origine----- > >> > De : multrans-bounces@ietf.org > >> > [mailto:multrans-bounces@ietf.org] De la part de Ronald Bonica > >> > Envoy=E9 : mardi 6 d=E9cembre 2011 19:44 > >> > =C0 : Tina TSOU; multrans@ietf.org; MBONED WG > >> > Objet : Re: [multrans] Draft agenda for multicast transition > interim > >> > > >> > Hi Tina, > >> > > >> > Thanks for the proposed agenda. A few comments are inline. > >> > >> > > >> > We might want to call the first agenda item "Overview" > >> > instead of "Use Cases". IMHO, the Overview contains the > >> > following parts: > >> > > >> > - an introduction to the problem space > >> > - an introduction to the solution space > >> > > >> > The crux of the problem is that multicast connectivity is > >> > required among the following host types: > >> > > >> > - dual-stack > >> > - IPv4-only > >> > - IPv6-only > >> > > >> > Therefore, multicast data and signaling will need to traverse > >> > IPv4/IPv6 boundaries. The IPv4/IPv6 boundary may be adjacent > >> > to the source, at any point between the source and > >> > destination, or adjacent to the destination. For some network > >> > topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6 > >> > boundary crossings may be required. For the purpose of this > >> > exercise, all network segments are assumed to be multicast > enabled. > >> > > >> > (You can talk about use cases here, but you probably don't > >> > want to enumerate every possible use-case. Talk about a use > >> > case only if it introduces new requirements for the > >> > adaptation function that will be deployed at the IPv4/IPv6 > boundary). > >> > > >> > The solution space contains: > >> > > >> > - a source discovery solution > >> > - a multicast address mapping solution > >> > - an adaptation function solution > >> > > >> > More on each of those, below. It would be great if we had a > >> > short draft to review before the first Interim meeting. > >> > >> Below some pointers which may be of interest: > >> > >> * Address mapping: http://tools.ietf.org/html/draft-boucadair- > behave- > >> 64-multicast-address-format-03 > >> * Service discovery using SDP (Use Cases): > >> http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases- > >> 00#section-3 > >> * Candidate solution for address discovery (SDP ALTC): > >> http://tools.ietf.org/html/draft-boucadair-mmusic-altc-04 > >> * Adaptation functions overview: http://tools.ietf.org/html/draft- > >> jaclee-behave-v4v6-mcast-ps-03#section-4.4 > >> * Unicast/Multicast PREFIX provisioning: > >> http://tools.ietf.org/html/draft-qin-softwire-multicast-prefix- > option- > >> 01 > >> > >> > >> Cheers, > >> Med > >_______________________________________________ > >multrans mailing list > >multrans@ietf.org > >https://www.ietf.org/mailman/listinfo/multrans From yiu_lee@cable.comcast.com Fri Dec 9 11:17:50 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2DE21F8A6F; Fri, 9 Dec 2011 11:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.735 X-Spam-Level: X-Spam-Status: No, score=-101.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK0U1ZiVbpTQ; Fri, 9 Dec 2011 11:17:49 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8561621F8880; Fri, 9 Dec 2011 11:17:49 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.63418493; Fri, 09 Dec 2011 12:18:18 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Fri, 9 Dec 2011 14:17:29 -0500 From: "Lee, Yiu" To: Ronald Bonica , "mohamed.boucadair@orange.com" , "multrans@ietf.org" , MBONED WG Thread-Topic: [multrans] Draft agenda for multicast transition interim Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCAAQ+9cIADrvDwgAAC14CAAAploIAAASiA Date: Fri, 9 Dec 2011 19:17:26 +0000 Message-ID: In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74E19E481@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [69.241.25.0] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8A7FC06B62BFF84A94840B2E549BB465@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 19:17:50 -0000 Thanks. On 12/9/11 2:14 PM, "Ronald Bonica" wrote: >This was proposed as part of the MULTRANS solution, so it is a candidate >for adoption in MBONED. > > Ron > > >> -----Original Message----- >> From: Lee, Yiu [mailto:Yiu_Lee@cable.comcast.com] >> Sent: Friday, December 09, 2011 1:36 PM >> To: Ronald Bonica; mohamed.boucadair@orange.com; multrans@ietf.org; >> MBONED WG >> Subject: Re: [multrans] Draft agenda for multicast transition interim >>=20 >> Hi Ron, >>=20 >> We also have a question which WG would like to be home for this draft. >> We >> have couple of WG drafts relying on this in Softwire. We presented it >> in >> BEHAVE w/o much response. We would like to hear from the IESG where >> this >> draft should belong. >>=20 >> Regards, >> Yiu >>=20 >> On 12/9/11 1:28 PM, "Ronald Bonica" wrote: >>=20 >> >Med, >> > >> >draft-boucadair-behave-64-multicast-address-format appears to be >> pretty >> >well cooked. Maybe the MBONED chairs could ask for a few volunteer >> >reviewers? >> > >> >I will send my comments in a separate email. >> > >> > Ron >> > >> > >> >> -----Original Message----- >> >> From: mohamed.boucadair@orange.com >> >> [mailto:mohamed.boucadair@orange.com] >> >> Sent: Wednesday, December 07, 2011 7:08 AM >> >> To: Ronald Bonica; Tina TSOU; multrans@ietf.org; MBONED WG >> >> Subject: RE: Draft agenda for multicast transition interim >> >> >> >> Dear Ron, all, >> >> >> >> Please see inline. >> >> >> >> Cheers, >> >> Med >> >> >> >> > -----Message d'origine----- >> >> > De : multrans-bounces@ietf.org >> >> > [mailto:multrans-bounces@ietf.org] De la part de Ronald Bonica >> >> > Envoy=E9 : mardi 6 d=E9cembre 2011 19:44 >> >> > =C0 : Tina TSOU; multrans@ietf.org; MBONED WG >> >> > Objet : Re: [multrans] Draft agenda for multicast transition >> interim >> >> > >> >> > Hi Tina, >> >> > >> >> > Thanks for the proposed agenda. A few comments are inline. >> >> >> >> > >> >> > We might want to call the first agenda item "Overview" >> >> > instead of "Use Cases". IMHO, the Overview contains the >> >> > following parts: >> >> > >> >> > - an introduction to the problem space >> >> > - an introduction to the solution space >> >> > >> >> > The crux of the problem is that multicast connectivity is >> >> > required among the following host types: >> >> > >> >> > - dual-stack >> >> > - IPv4-only >> >> > - IPv6-only >> >> > >> >> > Therefore, multicast data and signaling will need to traverse >> >> > IPv4/IPv6 boundaries. The IPv4/IPv6 boundary may be adjacent >> >> > to the source, at any point between the source and >> >> > destination, or adjacent to the destination. For some network >> >> > topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6 >> >> > boundary crossings may be required. For the purpose of this >> >> > exercise, all network segments are assumed to be multicast >> enabled. >> >> > >> >> > (You can talk about use cases here, but you probably don't >> >> > want to enumerate every possible use-case. Talk about a use >> >> > case only if it introduces new requirements for the >> >> > adaptation function that will be deployed at the IPv4/IPv6 >> boundary). >> >> > >> >> > The solution space contains: >> >> > >> >> > - a source discovery solution >> >> > - a multicast address mapping solution >> >> > - an adaptation function solution >> >> > >> >> > More on each of those, below. It would be great if we had a >> >> > short draft to review before the first Interim meeting. >> >> >> >> Below some pointers which may be of interest: >> >> >> >> * Address mapping: http://tools.ietf.org/html/draft-boucadair- >> behave- >> >> 64-multicast-address-format-03 >> >> * Service discovery using SDP (Use Cases): >> >> http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases- >> >> 00#section-3 >> >> * Candidate solution for address discovery (SDP ALTC): >> >> http://tools.ietf.org/html/draft-boucadair-mmusic-altc-04 >> >> * Adaptation functions overview: http://tools.ietf.org/html/draft- >> >> jaclee-behave-v4v6-mcast-ps-03#section-4.4 >> >> * Unicast/Multicast PREFIX provisioning: >> >> http://tools.ietf.org/html/draft-qin-softwire-multicast-prefix- >> option- >> >> 01 >> >> >> >> >> >> Cheers, >> >> Med >> >_______________________________________________ >> >multrans mailing list >> >multrans@ietf.org >> >https://www.ietf.org/mailman/listinfo/multrans > From Tina.Tsou.Zouting@huawei.com Sat Dec 10 13:13:17 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36C721F84AE; Sat, 10 Dec 2011 13:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbsO-gxquHVh; Sat, 10 Dec 2011 13:13:17 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B2EFA21F86A0; Sat, 10 Dec 2011 13:13:16 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW0000TOAXXKE@szxga05-in.huawei.com>; Sun, 11 Dec 2011 05:13:09 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW0006Z8AXW0Y@szxga05-in.huawei.com>; Sun, 11 Dec 2011 05:13:09 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFT47272; Sun, 11 Dec 2011 05:13:08 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 11 Dec 2011 05:12:52 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Sun, 11 Dec 2011 05:13:00 +0800 Date: Sat, 10 Dec 2011 21:12:59 +0000 From: Tina TSOU In-reply-to: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> X-Originating-IP: [10.212.244.217] To: Ronald Bonica , "multrans@ietf.org" , MBONED WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Draft agenda for multicast transition interim Thread-index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCABnzlEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 21:13:18 -0000 Hi Ron, Input Drafts for the first agenda item "Overview" are below. 1. http://datatracker.ietf.org/doc/draft-tsou-multicast-transition-taxonomy/ A Classification and Evaluation of Approaches to Transitional Multicast 2. http://datatracker.ietf.org/doc/draft-tsou-behave-translated-multicast/ A Generic Approach to Multicast Translation In Support of IPv6 Transition Tina -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: Tuesday, December 06, 2011 10:44 AM To: Tina TSOU; multrans@ietf.org; MBONED WG Subject: RE: Draft agenda for multicast transition interim Hi Tina, Thanks for the proposed agenda. A few comments are inline. Ron > -----Original Message----- > From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On > Behalf Of Tina TSOU > Sent: Monday, December 05, 2011 8:04 PM > To: multrans@ietf.org; MBONED WG > Subject: [multrans] Draft agenda for multicast transition interim > > Dear all, > It is proposed to hold the multicast transition interim meeting as a > series of short meetings. Timing of individual meetings may be set to > spread inconvenient hours around the globe. The objective of these > meetings is to achieve technical progress in the indicated topics. Here > is the proposed agenda: > > 1. Use Cases (1 hour) > > Ensure we are all clear on what use cases will be in scope. We might want to call the first agenda item "Overview" instead of "Use Cases". IMHO, the Overview contains the following parts: - an introduction to the problem space - an introduction to the solution space The crux of the problem is that multicast connectivity is required among the following host types: - dual-stack - IPv4-only - IPv6-only Therefore, multicast data and signaling will need to traverse IPv4/IPv6 boundaries. The IPv4/IPv6 boundary may be adjacent to the source, at any point between the source and destination, or adjacent to the destination. For some network topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6 boundary crossings may be required. For the purpose of this exercise, all network segments are assumed to be multicast enabled. (You can talk about use cases here, but you probably don't want to enumerate every possible use-case. Talk about a use case only if it introduces new requirements for the adaptation function that will be deployed at the IPv4/IPv6 boundary). The solution space contains: - a source discovery solution - a multicast address mapping solution - an adaptation function solution More on each of those, below. It would be great if we had a short draft to review before the first Interim meeting. > > > 2. Multicast address discovery by the receiver (2 hours) > > How does the receiver learn the multicast addresses corresponding to > specific programs, in the IP version that the receiver understands? We might want to call this Multicast Source Discovery. The following are a few interesting questions: - How are multicast sources identified? - How dynamic is the Source Discovery Mechanism? Does it simple discover and announce every multicast stream in the network or is registration required? - How do we ensure that the scope of the Source discovery mechanism is the same as the scope of the multicast network? - Can the Source Discovery mechanism be crafted from existing protocols? Again, it would be great if we had a draft to work from. > > > 3. Multicast address translation (2 hours) > > Stateless translation between IPv4 and IPv6 addresses should get > priority in this discussion, but we may go on to the broader topic if > there appears to be a need. What broader topic? Stateful translation? Why go there? > > > 4. What and how an adaptation function between the receiver and the > network works (2 hours) > > In cases where the receiver and the multicast-enabled network to which > it is attached support different IP versions, an adaptation function > (AF) is required between them. What are the requirements on that AF for > the handling of multicast signalling and the handling of multicast > content? > > 5. What and how an adaptation function between two networks works (2 > hours) > > In cases where two adjacent multicast-enabled networks support > different > IP versions, another type of adaptation function is needed. What are > the > requirements on that AF for the handling of multicast signalling and > the > handling of multicast content? > > Comments on this draft agenda are invited. > > Tina > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans From tom111.taylor@bell.net Sun Dec 11 16:12:47 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31FC21F84CD; Sun, 11 Dec 2011 16:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.531 X-Spam-Level: X-Spam-Status: No, score=-100.531 tagged_above=-999 required=5 tests=[AWL=1.265, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuYRw3nljRxk; Sun, 11 Dec 2011 16:12:47 -0800 (PST) Received: from blu0-omc4-s6.blu0.hotmail.com (blu0-omc4-s6.blu0.hotmail.com [65.55.111.145]) by ietfa.amsl.com (Postfix) with ESMTP id B8A3D21F849E; Sun, 11 Dec 2011 16:12:38 -0800 (PST) Received: from BLU0-SMTP44 ([65.55.111.136]) by blu0-omc4-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Dec 2011 16:12:37 -0800 X-Originating-IP: [76.70.77.190] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP44.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Dec 2011 16:12:37 -0800 Date: Sun, 11 Dec 2011 19:12:38 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tina TSOU References: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Dec 2011 00:12:37.0827 (UTC) FILETIME=[C16BB930:01CCB862] Cc: MBONED WG , "multrans@ietf.org" Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 00:12:47 -0000 I can see a brief historical mention for taxonomy in the overview, since it was one of the triggers for the Multrans discussions in Prague. However, translated-multicast describes a stateful approach to translation, and people rejected it at the time as unnecessary. I'd say that one should "go into our back pocket" as a potential resource, bu need not take up our time at the interim meeting. On 10/12/2011 4:12 PM, Tina TSOU wrote: > Hi Ron, > Input Drafts for the first agenda item "Overview" are below. > 1. > http://datatracker.ietf.org/doc/draft-tsou-multicast-transition-taxonomy/ > A Classification and Evaluation of Approaches to Transitional Multicast > 2. > http://datatracker.ietf.org/doc/draft-tsou-behave-translated-multicast/ > A Generic Approach to Multicast Translation In Support of IPv6 Transition > > Tina > ... From Tina.Tsou.Zouting@huawei.com Sun Dec 11 18:31:10 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF59721F8483; Sun, 11 Dec 2011 18:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NThI4vE49XTv; Sun, 11 Dec 2011 18:31:10 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7600221F847A; Sun, 11 Dec 2011 18:31:07 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW200456K6QSX@szxga03-in.huawei.com>; Mon, 12 Dec 2011 10:28:02 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW2009U6K6Q5K@szxga03-in.huawei.com>; Mon, 12 Dec 2011 10:28:02 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFT65385; Mon, 12 Dec 2011 10:28:01 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Dec 2011 10:28:00 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Mon, 12 Dec 2011 10:27:55 +0800 Date: Mon, 12 Dec 2011 02:27:54 +0000 From: Tina TSOU X-Originating-IP: [10.212.245.201] To: "multrans@ietf.org" , MBONED WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-tsou-multrans-addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim meeting Thread-index: AQHMuHOgtP/11gjWKkmpPU/f+aPEA5XXdm2g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [multrans] New Version Notification for draft-tsou-multrans-addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim meeting X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 02:31:10 -0000 Dear all, Here is a new draft to work from for the 2nd item "Multicast Source Discovery" of the interim meeting. http://datatracker.ietf.org/doc/draft-tsou-multrans-addr-acquisition/ Title: Address Acquisition for Multicast Content When Source and Receiver Support Differing IP Versions Creation date: 2011-12-11 Number of pages: 9 Abstract: In a typical IP television (IPTV) system, the receiver acquires information about available program content, the subscriber selects a program to watch, and the receiver signals to the network to begin receiving the program in the form of multicast content. The program content information is typically XML-encoded, can be transmitted in multiple segments, possibly over multiple channels, but includes media stream descriptions for the individual program descriptions that may also be XML-encoded or may use the Session Description Protocol (SDP, RFC 4566). The media stream descriptions provide multicast group and unicast source addresses that are used in the subsequent signalling to the network. During the transition from IPv4 to IPv6, scenarios can occur where the IP version supported by the receiver differs from that supported by the source. This memo examines and evaluates alternative strategies for allowing the receiver to acquire addresses in such scenarios in the version it supports. >> 2. Multicast address discovery by the receiver (2 hours) >> >> How does the receiver learn the multicast addresses corresponding >> to specific programs, in the IP version that the receiver understands? > > We might want to call this Multicast Source Discovery. The following are a few interesting questions: > > - How are multicast sources identified? > - How dynamic is the Source Discovery Mechanism? Does it simple discover and announce every multicast stream in the network or is registration required? > - How do we ensure that the scope of the Source discovery mechanism is the same as the scope of the multicast network? > - Can the Source Discovery mechanism be crafted from existing protocols? > > Again, it would be great if we had a draft to work from. Specially, would like to thank Dave Thaler, for raising the problem, and inspiring the idea and giving technical advice; and valuable technical suggestions from Ron Bonica, Marshall Eubanks and Greg Shepherd. Best Regards, Tina From rbonica@juniper.net Mon Dec 12 08:37:19 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E635621F8B86; Mon, 12 Dec 2011 08:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iymKUVITgET; Mon, 12 Dec 2011 08:37:19 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 96BA921F8B81; Mon, 12 Dec 2011 08:37:17 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTuYtvSFH4tqd+784JfMLDTkbBtcVYhYw@postini.com; Mon, 12 Dec 2011 08:37:19 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Dec 2011 08:36:10 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 12 Dec 2011 11:35:38 -0500 From: Ronald Bonica To: Susan Hares , Tina TSOU , "multrans@ietf.org" , MBONED WG Date: Mon, 12 Dec 2011 11:35:36 -0500 Thread-Topic: Draft agenda for multicast transition interim Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCABnzlEIAC0MyggAAIn5A= Message-ID: <13205C286662DE4387D9AF3AC30EF456D74E19F108@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> <728F9B956B2C48439CA9294B1723B14616C19515@dfweml504-mbx> In-Reply-To: <728F9B956B2C48439CA9294B1723B14616C19515@dfweml504-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 16:37:20 -0000 Hi Sue, Given that the purpose of that meeting is to review Marshall's overview doc= ument, we should schedule the meeting for sometime after the draft has been= posted and everyone has had a chance to read it. Marshall, can you provide an ETA? Ron > -----Original Message----- > From: Susan Hares [mailto:susan.hares@huawei.com] > Sent: Monday, December 12, 2011 11:03 AM > To: Tina TSOU; Ronald Bonica; multrans@ietf.org; MBONED WG > Subject: RE: Draft agenda for multicast transition interim >=20 > Tina nd Ron: >=20 > Have we set the date for the interim? >=20 > Sue >=20 > -----Original Message----- > From: Tina TSOU > Sent: Saturday, December 10, 2011 4:13 PM > To: Ronald Bonica; multrans@ietf.org; MBONED WG > Subject: RE: Draft agenda for multicast transition interim >=20 > Hi Ron, > Input Drafts for the first agenda item "Overview" are below. > 1. > http://datatracker.ietf.org/doc/draft-tsou-multicast-transition- > taxonomy/ > A Classification and Evaluation of Approaches to Transitional Multicast > 2. > http://datatracker.ietf.org/doc/draft-tsou-behave-translated-multicast/ > A Generic Approach to Multicast Translation In Support of IPv6 > Transition >=20 > Tina >=20 > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: Tuesday, December 06, 2011 10:44 AM > To: Tina TSOU; multrans@ietf.org; MBONED WG > Subject: RE: Draft agenda for multicast transition interim >=20 > Hi Tina, >=20 > Thanks for the proposed agenda. A few comments are inline. >=20 > Ron >=20 > > -----Original Message----- > > From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On > > Behalf Of Tina TSOU > > Sent: Monday, December 05, 2011 8:04 PM > > To: multrans@ietf.org; MBONED WG > > Subject: [multrans] Draft agenda for multicast transition interim > > > > Dear all, > > It is proposed to hold the multicast transition interim meeting as a > > series of short meetings. Timing of individual meetings may be set to > > spread inconvenient hours around the globe. The objective of these > > meetings is to achieve technical progress in the indicated topics. > > Here is the proposed agenda: > > > > 1. Use Cases (1 hour) > > > > Ensure we are all clear on what use cases will be in scope. >=20 > We might want to call the first agenda item "Overview" instead of "Use > Cases". IMHO, the Overview contains the following parts: >=20 > - an introduction to the problem space > - an introduction to the solution space >=20 > The crux of the problem is that multicast connectivity is required > among the following host types: >=20 > - dual-stack > - IPv4-only > - IPv6-only >=20 > Therefore, multicast data and signaling will need to traverse IPv4/IPv6 > boundaries. The IPv4/IPv6 boundary may be adjacent to the source, at > any point between the source and destination, or adjacent to the > destination. For some network topologies (e.g., IPv4 edge, IPv6 core), > multiple IPv4/IPv6 boundary crossings may be required. For the purpose > of this exercise, all network segments are assumed to be multicast > enabled. >=20 > (You can talk about use cases here, but you probably don't want to > enumerate every possible use-case. Talk about a use case only if it > introduces new requirements for the adaptation function that will be > deployed at the IPv4/IPv6 boundary). >=20 > The solution space contains: >=20 > - a source discovery solution > - a multicast address mapping solution > - an adaptation function solution >=20 > More on each of those, below. It would be great if we had a short > draft to review before the first Interim meeting. > > > > > > 2. Multicast address discovery by the receiver (2 hours) > > > > How does the receiver learn the multicast addresses corresponding to > > specific programs, in the IP version that the receiver understands? >=20 > We might want to call this Multicast Source Discovery. The following > are a few interesting questions: >=20 > - How are multicast sources identified? > - How dynamic is the Source Discovery Mechanism? Does it simple > discover and announce every multicast stream in the network or is > registration required? > - How do we ensure that the scope of the Source discovery mechanism is > the same as the scope of the multicast network? > - Can the Source Discovery mechanism be crafted from existing > protocols? >=20 > Again, it would be great if we had a draft to work from. >=20 > > > > > > 3. Multicast address translation (2 hours) > > > > Stateless translation between IPv4 and IPv6 addresses should get > > priority in this discussion, but we may go on to the broader topic if > > there appears to be a need. >=20 > What broader topic? Stateful translation? Why go there? >=20 > > > > > > 4. What and how an adaptation function between the receiver and the > > network works (2 hours) > > > > In cases where the receiver and the multicast-enabled network to > which > > it is attached support different IP versions, an adaptation function > > (AF) is required between them. What are the requirements on that AF > > for the handling of multicast signalling and the handling of > multicast > > content? > > > > 5. What and how an adaptation function between two networks works (2 > > hours) > > > > In cases where two adjacent multicast-enabled networks support > > different IP versions, another type of adaptation function is needed. > > What are the requirements on that AF for the handling of multicast > > signalling and the handling of multicast content? > > > > Comments on this draft agenda are invited. > > > > Tina > > _______________________________________________ > > multrans mailing list > > multrans@ietf.org > > https://www.ietf.org/mailman/listinfo/multrans From susan.hares@huawei.com Mon Dec 12 08:05:05 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 514F121F8B3C; Mon, 12 Dec 2011 08:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq+znM33Osit; Mon, 12 Dec 2011 08:05:04 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4708121F8B0C; Mon, 12 Dec 2011 08:05:04 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABM15373; Mon, 12 Dec 2011 11:05:03 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Dec 2011 08:03:13 -0800 Received: from DFWEML504-MBX.china.huawei.com ([10.124.31.30]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Mon, 12 Dec 2011 08:03:03 -0800 From: Susan Hares To: Tina TSOU , Ronald Bonica , "multrans@ietf.org" , MBONED WG Thread-Topic: Draft agenda for multicast transition interim Thread-Index: AQHMs6Ffjh6RlJwL9UOCkcshob2Wj5XN/LJggAEdUwCABnzlEIAC0Myg Date: Mon, 12 Dec 2011 16:03:02 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14616C19515@dfweml504-mbx> References: <13205C286662DE4387D9AF3AC30EF456D74DE5BC2F@EMBX01-WF.jnpr.net> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.247] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 12 Dec 2011 14:56:03 -0800 Subject: Re: [multrans] Draft agenda for multicast transition interim X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 16:05:05 -0000 Tina nd Ron: Have we set the date for the interim? Sue=20 -----Original Message----- From: Tina TSOU=20 Sent: Saturday, December 10, 2011 4:13 PM To: Ronald Bonica; multrans@ietf.org; MBONED WG Subject: RE: Draft agenda for multicast transition interim Hi Ron, Input Drafts for the first agenda item "Overview" are below. 1. http://datatracker.ietf.org/doc/draft-tsou-multicast-transition-taxonomy/ A Classification and Evaluation of Approaches to Transitional Multicast 2. http://datatracker.ietf.org/doc/draft-tsou-behave-translated-multicast/ A Generic Approach to Multicast Translation In Support of IPv6 Transition Tina -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: Tuesday, December 06, 2011 10:44 AM To: Tina TSOU; multrans@ietf.org; MBONED WG Subject: RE: Draft agenda for multicast transition interim Hi Tina, Thanks for the proposed agenda. A few comments are inline. Ron > -----Original Message----- > From: multrans-bounces@ietf.org [mailto:multrans-bounces@ietf.org] On=20 > Behalf Of Tina TSOU > Sent: Monday, December 05, 2011 8:04 PM > To: multrans@ietf.org; MBONED WG > Subject: [multrans] Draft agenda for multicast transition interim >=20 > Dear all, > It is proposed to hold the multicast transition interim meeting as a=20 > series of short meetings. Timing of individual meetings may be set to=20 > spread inconvenient hours around the globe. The objective of these=20 > meetings is to achieve technical progress in the indicated topics.=20 > Here is the proposed agenda: >=20 > 1. Use Cases (1 hour) >=20 > Ensure we are all clear on what use cases will be in scope. We might want to call the first agenda item "Overview" instead of "Use Case= s". IMHO, the Overview contains the following parts: - an introduction to the problem space - an introduction to the solution space The crux of the problem is that multicast connectivity is required among th= e following host types: - dual-stack - IPv4-only - IPv6-only Therefore, multicast data and signaling will need to traverse IPv4/IPv6 bou= ndaries. The IPv4/IPv6 boundary may be adjacent to the source, at any point= between the source and destination, or adjacent to the destination. For so= me network topologies (e.g., IPv4 edge, IPv6 core), multiple IPv4/IPv6 boun= dary crossings may be required. For the purpose of this exercise, all netwo= rk segments are assumed to be multicast enabled. (You can talk about use cases here, but you probably don't want to enumerat= e every possible use-case. Talk about a use case only if it introduces new = requirements for the adaptation function that will be deployed at the IPv4/= IPv6 boundary). The solution space contains: - a source discovery solution - a multicast address mapping solution - an adaptation function solution More on each of those, below. It would be great if we had a short draft t= o review before the first Interim meeting. >=20 >=20 > 2. Multicast address discovery by the receiver (2 hours) >=20 > How does the receiver learn the multicast addresses corresponding to=20 > specific programs, in the IP version that the receiver understands? We might want to call this Multicast Source Discovery. The following are a = few interesting questions: - How are multicast sources identified? - How dynamic is the Source Discovery Mechanism? Does it simple discover an= d announce every multicast stream in the network or is registration require= d? - How do we ensure that the scope of the Source discovery mechanism is the = same as the scope of the multicast network? - Can the Source Discovery mechanism be crafted from existing protocols? Again, it would be great if we had a draft to work from. >=20 >=20 > 3. Multicast address translation (2 hours) >=20 > Stateless translation between IPv4 and IPv6 addresses should get=20 > priority in this discussion, but we may go on to the broader topic if=20 > there appears to be a need. What broader topic? Stateful translation? Why go there? >=20 >=20 > 4. What and how an adaptation function between the receiver and the=20 > network works (2 hours) >=20 > In cases where the receiver and the multicast-enabled network to which=20 > it is attached support different IP versions, an adaptation function > (AF) is required between them. What are the requirements on that AF=20 > for the handling of multicast signalling and the handling of multicast=20 > content? >=20 > 5. What and how an adaptation function between two networks works (2 > hours) >=20 > In cases where two adjacent multicast-enabled networks support=20 > different IP versions, another type of adaptation function is needed.=20 > What are the requirements on that AF for the handling of multicast=20 > signalling and the handling of multicast content? >=20 > Comments on this draft agenda are invited. >=20 > Tina > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans From Tina.Tsou.Zouting@huawei.com Thu Dec 15 15:36:39 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9983A1F0C4C; Thu, 15 Dec 2011 15:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKifo9vmIJQ6; Thu, 15 Dec 2011 15:36:39 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id F36961F0C3F; Thu, 15 Dec 2011 15:36:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW900613QWX87@szxga04-in.huawei.com>; Fri, 16 Dec 2011 07:36:33 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW9004Q8QWXS8@szxga04-in.huawei.com>; Fri, 16 Dec 2011 07:36:33 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFV82352; Fri, 16 Dec 2011 07:36:32 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Dec 2011 07:36:25 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Fri, 16 Dec 2011 07:36:23 +0800 Date: Thu, 15 Dec 2011 23:36:23 +0000 From: Tina TSOU To: Marshall Eubanks Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Marshall, how can I help u on the Multrans overview draft? Thread-index: Acy7glr97DRLxG1HSjihGhS/Wg1erw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "mboned@ietf.org" , "multrans@ietf.org" Subject: [multrans] Marshall, how can I help u on the Multrans overview draft? X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 23:36:39 -0000 Marshall, how can I help u on the Multrans overview draft? If u have the Table of Content, just allocate the section u want me to help. Sent from my iPad From cathy.zhou@huawei.com Thu Dec 15 23:34:45 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E1111E809A; Thu, 15 Dec 2011 23:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eusN2TNdXrOx; Thu, 15 Dec 2011 23:34:41 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4F08311E8093; Thu, 15 Dec 2011 23:34:41 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWA00KUOD1DUS@szxga05-in.huawei.com>; Fri, 16 Dec 2011 15:34:25 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWA008YKD1D5L@szxga05-in.huawei.com>; Fri, 16 Dec 2011 15:34:25 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFW04418; Fri, 16 Dec 2011 15:34:24 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 16 Dec 2011 15:34:07 +0800 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.201]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Fri, 16 Dec 2011 15:34:14 +0800 Date: Fri, 16 Dec 2011 07:34:14 +0000 From: "Cathy Zhou(Qian)" X-Originating-IP: [10.70.39.106] To: "multrans@ietf.org" , "mboned@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vNs33gt/t7/td3bHwyC6lA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [multrans] New Version Notification of draft-zhou-multrans-af1-specification-00 for the 4th item "an adaptation function between the receiver and the network" of the interim meeting Thread-index: Acy7xRu42eaFbqKLQxOkBaNs0wVlAg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [multrans] New Version Notification of draft-zhou-multrans-af1-specification-00 for the 4th item "an adaptation function between the receiver and the network" of the interim meeting X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 07:34:45 -0000 --Boundary_(ID_vNs33gt/t7/td3bHwyC6lA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, Here is a new draft to work from for the 4th item " Specification of an adaptation function between the receiver and the network" of the interim meeting. http://tools.ietf.org/html/draft-zhou-multrans-af1-specification-00 Abstract: Discussion of the problem of multicast transition has brought out a number of scenarios that are the most likely to be encountered in practice. In some of these scenarios the IP version supported by the multicast receiver differs from that supported by the provider network to which it is attached. In such cases an adaptation function is required between the receiver and the network, to mediate the signalling and data flows between them. This memo uses the term "Type 1 Adaptation Function" (AF1) for such a function. It is written for the purpose of specifying the functions performed by an AF1. The scope of this memo is limited to the case where flows are unidirectional, from a designated set of sources to a designated (and normally much more numerous) set of receivers. The IP television (IPTV) case falls within this scope. Comments are welcome. Best Regards, Cathy ZHOU & Tom Taylor --Boundary_(ID_vNs33gt/t7/td3bHwyC6lA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear all,

Here is a new draft to work from for the 4th item " Specification of an adaptation function between the receiver and the network" of the interim meeting.

http://tools.ietf.org/html/draft-zhou-multrans-af1-specification-00

 

 

Abstract:

   Discussion of the problem of multicast transition has brought out a

   number of scenarios that are the most likely to be encountered in

   practice.  In some of these scenarios the IP version supported by the

   multicast receiver differs from that supported by the provider

   network to which it is attached.  In such cases an adaptation

   function is required between the receiver and the network, to mediate

   the signalling and data flows between them.  This memo uses the term

   &quot;Type 1 Adaptation Function&quot; (AF1) for such a function.  It is

   written for the purpose of specifying the functions performed by an

   AF1.

 

   The scope of this memo is limited to the case where flows are

   unidirectional, from a designated set of sources to a designated (and

   normally much more numerous) set of receivers.  The IP television

   (IPTV) case falls within this scope.

 

Comments are welcome.

 

Best Regards,

Cathy ZHOU & Tom Taylor

 

--Boundary_(ID_vNs33gt/t7/td3bHwyC6lA)-- From albert.e.manfredi@boeing.com Fri Dec 16 13:09:35 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9B021F8A7E; Fri, 16 Dec 2011 13:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALaE7r-vlKx6; Fri, 16 Dec 2011 13:09:33 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id EE69621F8A71; Fri, 16 Dec 2011 13:09:31 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pBGL9cY2022061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Dec 2011 15:09:41 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pBGL9IYc020719; Fri, 16 Dec 2011 13:09:18 -0800 (PST) Received: from XCH-MWHT-04.mw.nos.boeing.com (xch-mwht-04.mw.nos.boeing.com [134.57.113.164]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pBGL9H1r020698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 16 Dec 2011 13:09:17 -0800 (PST) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-04.mw.nos.boeing.com ([134.57.113.164]) with mapi; Fri, 16 Dec 2011 15:09:16 -0600 From: "Manfredi, Albert E" To: "Cathy Zhou(Qian)" , "multrans@ietf.org" , "mboned@ietf.org" Date: Fri, 16 Dec 2011 15:09:15 -0600 Thread-Topic: [MBONED] [multrans] New Version Notification of draft-zhou-multrans-af1-specification-00 for the 4th item "an adaptation function between the receiver and the network" of the interim meeting Thread-Index: Acy7xRu42eaFbqKLQxOkBaNs0wVlAgAcTe2g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B0147C3DD45E42478038FC347CCB65FE02B3445BEFXCHMW08Vmwnos_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 16 Dec 2011 13:41:41 -0800 Subject: Re: [multrans] [MBONED] New Version Notification of draft-zhou-multrans-af1-specification-00 for the 4th item "an adaptation function between the receiver and the network" of the interim meeting X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 21:09:35 -0000 --_000_B0147C3DD45E42478038FC347CCB65FE02B3445BEFXCHMW08Vmwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm all in favor of this sort of approach. In fact, it's something I've bee= n expecting to have to implement in our systems, even without an RFC to des= cribe the process. Much like was the case with RFC 4605, where we had alrea= dy been doing IGMP proxying, to solve a specific problem we encountered (in= our case, it had to do with security requirements). Bert From: mboned-bounces@ietf.org [mailto:mboned-bounces@ietf.org] On Behalf Of= Cathy Zhou(Qian) Sent: Friday, December 16, 2011 2:34 AM To: multrans@ietf.org; mboned@ietf.org Subject: [MBONED] [multrans] New Version Notification of draft-zhou-multran= s-af1-specification-00 for the 4th item "an adaptation function between the= receiver and the network" of the interim meeting Dear all, Here is a new draft to work from for the 4th item " Specification of an ada= ptation function between the receiver and the network" of the interim meeti= ng. http://tools.ietf.org/html/draft-zhou-multrans-af1-specification-00 Abstract: Discussion of the problem of multicast transition has brought out a number of scenarios that are the most likely to be encountered in practice. In some of these scenarios the IP version supported by the multicast receiver differs from that supported by the provider network to which it is attached. In such cases an adaptation function is required between the receiver and the network, to mediate the signalling and data flows between them. This memo uses the term "Type 1 Adaptation Function" (AF1) for such a function. It is written for the purpose of specifying the functions performed by an AF1. The scope of this memo is limited to the case where flows are unidirectional, from a designated set of sources to a designated (and normally much more numerous) set of receivers. The IP television (IPTV) case falls within this scope. Comments are welcome. Best Regards, Cathy ZHOU & Tom Taylor --_000_B0147C3DD45E42478038FC347CCB65FE02B3445BEFXCHMW08Vmwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m all in favor of this sort of appro= ach. In fact, it’s something I’ve been expecting to have to imp= lement in our systems, even without an RFC to describe the process. Much li= ke was the case with RFC 4605, where we had already been doing IGMP proxyin= g, to solve a specific problem we encountered (in our case, it had to do wi= th security requirements).

 

Bert

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mboned-b= ounces@ietf.org [mailto:mboned-bounces@ietf.org] On Behalf Of Cathy = Zhou(Qian)
Sent: Friday, December 16, 2011 2:34 AM
To: = multrans@ietf.org; mboned@ietf.org
Subject: [MBONED] [multrans] N= ew Version Notification of draft-zhou-multrans-af1-specification-00 for the= 4th item "an adaptation function between the receiver and the network= " of the interim meeting

 

Dear all,

Here is a= new draft to work from for the 4th item " Specification of an adaptat= ion function between the receiver and the network" of the interim meet= ing.

http://tools.ietf.org/html/= draft-zhou-multrans-af1-specification-00

 

 

<= p class=3DMsoPlainText>Abstract:

&nbs= p;  Discussion of the problem of multicast transition has brought out = a

   number of scenarios th= at are the most likely to be encountered in

   practice.  In some of these scenarios the IP versi= on supported by the

   mult= icast receiver differs from that supported by the provider

   network to which it is attached.  I= n such cases an adaptation

 &nbs= p; function is required between the receiver and the network, to mediate

   the signalling and data fl= ows between them.  This memo uses the term

   &quot;Type 1 Adaptation Function&quot; (AF1= ) for such a function.  It is

&n= bsp;  written for the purpose of specifying the functions performed by= an

   AF1.

<= p class=3DMsoPlainText> 

 &= nbsp; The scope of this memo is limited to the case where flows are

   unidirectional, from a designat= ed set of sources to a designated (and

   normally much more numerous) set of receivers.  The IP = television

   (IPTV) case f= alls within this scope.

 

Comments are welcome.

 

Best Regards,<= /p>

Cathy ZHOU & Tom Taylor

 

= --_000_B0147C3DD45E42478038FC347CCB65FE02B3445BEFXCHMW08Vmwnos_-- From mmcbride7@gmail.com Fri Dec 16 14:04:46 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F4D1F0C53; Fri, 16 Dec 2011 14:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idrn8VUp00WW; Fri, 16 Dec 2011 14:04:46 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9F851F0C3F; Fri, 16 Dec 2011 14:04:45 -0800 (PST) Received: by eekc14 with SMTP id c14so2332565eek.31 for ; Fri, 16 Dec 2011 14:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1JKe4n1azWWZvj+3bK1wV36YHR8isJPANiDyiEWDbMA=; b=tZBXT0WCfVdz+IaYPLKEBi77qX5+JnJl0ESxKxNqc0BeZ/nP7rQprCLTx/mOMVpCXB xFtA4xVeUtq+5iGuPjXBN04j1YjFSOkagjz3XjTcXXy3zxhuiop4aN6hrkdOp2JiJUEx nCMpWVS79V9YfKNh21gnCyFkCV/Un3QcD6s1E= MIME-Version: 1.0 Received: by 10.213.25.219 with SMTP id a27mr2865067ebc.1.1324073084491; Fri, 16 Dec 2011 14:04:44 -0800 (PST) Received: by 10.213.105.137 with HTTP; Fri, 16 Dec 2011 14:04:44 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Dec 2011 14:04:44 -0800 Message-ID: From: Mike McBride To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: MBONED WG , "multrans@ietf.org" Subject: Re: [multrans] [MBONED] New Version Notification for draft-tsou-multrans-addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim meeting X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 22:04:47 -0000 Tina, Good summary and problem description. I'm getting a head a bit but my preference is that we keep the solutions as simple as possible (a vote for your administrative strategy). And use existing mechanisms where possible. SDP includes IP4/IP6 in media descriptions. SDP can use SAP (no please), SIP, RTSP, HTTP...for transport. All are v4/v6 worthy. ICE/STUN can be used for nat traversal. The end device uses the address it understands and then relies upon the forthcoming multrans solutions for the E2E connectivity. If we want to go down the road of new session announcement functionality, perhaps a new session announcement mapping server, then we should review draft-ietf-mboned-session-announcement (authors should revive draft) for mcast session announcement requirements. It should probably also be documented (with all multrans drafts?) how this works with those having the luxury of dual stack environments. Will the interim, to discuss this further, likely be in January? mike On Sun, Dec 11, 2011 at 6:27 PM, Tina TSOU w= rote: > Dear all, > Here is a new draft to work from for the 2nd item "Multicast Source Disco= very" of the interim meeting. > http://datatracker.ietf.org/doc/draft-tsou-multrans-addr-acquisition/ > > Title: > Address Acquisition for Multicast Content When Source and Receiver Suppor= t Differing IP Versions > Creation date: =A0 2011-12-11 > Number of pages: 9 > > Abstract: > =A0 In a typical IP television (IPTV) system, the receiver acquires > =A0 information about available program content, the subscriber selects a > =A0 program to watch, and the receiver signals to the network to begin > =A0 receiving the program in the form of multicast content. =A0The progra= m > =A0 content information is typically XML-encoded, can be transmitted in > =A0 multiple segments, possibly over multiple channels, but includes > =A0 media stream descriptions for the individual program descriptions > =A0 that may also be XML-encoded or may use the Session Description > =A0 Protocol (SDP, RFC 4566). =A0The media stream descriptions provide > =A0 multicast group and unicast source addresses that are used in the > =A0 subsequent signalling to the network. > > =A0 During the transition from IPv4 to IPv6, scenarios can occur where > =A0 the IP version supported by the receiver differs from that supported > =A0 by the source. =A0This memo examines and evaluates alternative > =A0 strategies for allowing the receiver to acquire addresses in such > =A0 scenarios in the version it supports. > >>> 2. Multicast address discovery by the receiver (2 hours) >>> >>> How does the receiver learn the multicast addresses corresponding >>> to specific programs, in the IP version that the receiver understands? >> >> We might want to call this Multicast Source Discovery. The following are= a few interesting questions: >> >> - How are multicast sources identified? >> - How dynamic is the Source Discovery Mechanism? Does it simple discover= and announce every multicast stream in the network or is registration requ= ired? >> - How do we ensure that the scope of the Source discovery mechanism is t= he same as the scope of the multicast network? >> - Can the Source Discovery mechanism be crafted from existing protocols? >> >> Again, it would be great if we had a draft to work from. > > Specially, would like to thank Dave Thaler, for raising the problem, and = inspiring the idea and giving technical advice; and valuable technical sugg= estions from Ron Bonica, Marshall Eubanks and Greg Shepherd. > > > Best Regards, > Tina > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www.ietf.org/mailman/listinfo/mboned From Tina.Tsou.Zouting@huawei.com Fri Dec 16 14:35:27 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342301F0C3F; Fri, 16 Dec 2011 14:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 353Kcg8zD42c; Fri, 16 Dec 2011 14:35:26 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3875B21F851F; Fri, 16 Dec 2011 14:35:26 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWB000VMIQT7D@szxga05-in.huawei.com>; Sat, 17 Dec 2011 06:35:17 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWB00GO8IQTN4@szxga05-in.huawei.com>; Sat, 17 Dec 2011 06:35:17 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFT45946; Sat, 17 Dec 2011 06:35:16 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 17 Dec 2011 06:35:10 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Sat, 17 Dec 2011 06:35:10 +0800 Date: Fri, 16 Dec 2011 22:35:10 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.193.34.145] To: Mike McBride Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [MBONED] New Version Notification for draft-tsou-multrans-addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim meeting Thread-index: AQHMuHOgtP/11gjWKkmpPU/f+aPEA5XXdm2ggAcP/gCAAI3aEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: MBONED WG , "multrans@ietf.org" Subject: Re: [multrans] [MBONED] New Version Notification for draft-tsou-multrans-addr-acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the interim meeting X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 22:35:27 -0000 Mike, Thank you for the comments. I believe the interim would be in January, but it is up to the powers that = be. Tina -----Original Message----- From: Mike McBride [mailto:mmcbride7@gmail.com]=20 Sent: Friday, December 16, 2011 2:05 PM To: Tina TSOU Cc: multrans@ietf.org; MBONED WG Subject: Re: [MBONED] New Version Notification for draft-tsou-multrans-addr= -acquisition-00.txt for the 2nd item "Multicast Source Discovery" of the in= terim meeting Tina, Good summary and problem description. I'm getting a head a bit but my preference is that we keep the solutions as simple as possible (a vote for your administrative strategy). And use existing mechanisms where possible. SDP includes IP4/IP6 in media descriptions. SDP can use SAP (no please), SIP, RTSP, HTTP...for transport. All are v4/v6 worthy. ICE/STUN can be used for nat traversal. The end device uses the address it understands and then relies upon the forthcoming multrans solutions for the E2E connectivity. If we want to go down the road of new session announcement functionality, perhaps a new session announcement mapping server, then we should review draft-ietf-mboned-session-announcement (authors should revive draft) for mcast session announcement requirements. It should probably also be documented (with all multrans drafts?) how this works with those having the luxury of dual stack environments. Will the interim, to discuss this further, likely be in January? mike On Sun, Dec 11, 2011 at 6:27 PM, Tina TSOU w= rote: > Dear all, > Here is a new draft to work from for the 2nd item "Multicast Source Disco= very" of the interim meeting. > http://datatracker.ietf.org/doc/draft-tsou-multrans-addr-acquisition/ > > Title: > Address Acquisition for Multicast Content When Source and Receiver Suppor= t Differing IP Versions > Creation date: =A0 2011-12-11 > Number of pages: 9 > > Abstract: > =A0 In a typical IP television (IPTV) system, the receiver acquires > =A0 information about available program content, the subscriber selects a > =A0 program to watch, and the receiver signals to the network to begin > =A0 receiving the program in the form of multicast content. =A0The progra= m > =A0 content information is typically XML-encoded, can be transmitted in > =A0 multiple segments, possibly over multiple channels, but includes > =A0 media stream descriptions for the individual program descriptions > =A0 that may also be XML-encoded or may use the Session Description > =A0 Protocol (SDP, RFC 4566). =A0The media stream descriptions provide > =A0 multicast group and unicast source addresses that are used in the > =A0 subsequent signalling to the network. > > =A0 During the transition from IPv4 to IPv6, scenarios can occur where > =A0 the IP version supported by the receiver differs from that supported > =A0 by the source. =A0This memo examines and evaluates alternative > =A0 strategies for allowing the receiver to acquire addresses in such > =A0 scenarios in the version it supports. > >>> 2. Multicast address discovery by the receiver (2 hours) >>> >>> How does the receiver learn the multicast addresses corresponding >>> to specific programs, in the IP version that the receiver understands? >> >> We might want to call this Multicast Source Discovery. The following are= a few interesting questions: >> >> - How are multicast sources identified? >> - How dynamic is the Source Discovery Mechanism? Does it simple discover= and announce every multicast stream in the network or is registration requ= ired? >> - How do we ensure that the scope of the Source discovery mechanism is t= he same as the scope of the multicast network? >> - Can the Source Discovery mechanism be crafted from existing protocols? >> >> Again, it would be great if we had a draft to work from. > > Specially, would like to thank Dave Thaler, for raising the problem, and = inspiring the idea and giving technical advice; and valuable technical sugg= estions from Ron Bonica, Marshall Eubanks and Greg Shepherd. > > > Best Regards, > Tina > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www.ietf.org/mailman/listinfo/mboned From Tina.Tsou.Zouting@huawei.com Mon Dec 19 16:39:21 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A621F8477; Mon, 19 Dec 2011 16:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TJN6S-0X4WY; Mon, 19 Dec 2011 16:39:20 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1E73821F8462; Mon, 19 Dec 2011 16:39:20 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWH001ZY8HBIM@szxga04-in.huawei.com>; Tue, 20 Dec 2011 08:39:11 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWH002WD8HA1Q@szxga04-in.huawei.com>; Tue, 20 Dec 2011 08:39:11 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFU52928; Tue, 20 Dec 2011 08:39:10 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Dec 2011 08:39:08 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Tue, 20 Dec 2011 08:39:03 +0800 Date: Tue, 20 Dec 2011 00:39:02 +0000 From: Tina TSOU In-reply-to: <1324206855.51664.YahooMailNeo@web121801.mail.ne1.yahoo.com> X-Originating-IP: [10.193.34.145] To: Ghanashyam Satpathy , "ipv6@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_f/BsSJ6RYBqOdKm0ahN7+w)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Question on IPV4/IPV6 Multicast interoperability Thread-index: AQHMvpzl8eODnaBst02N8+9ZmITwy5Xj4SAA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1324206855.51664.YahooMailNeo@web121801.mail.ne1.yahoo.com> Cc: MBONED WG , "multrans@ietf.org" Subject: Re: [multrans] Question on IPV4/IPV6 Multicast interoperability X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 00:39:21 -0000 --Boundary_(ID_f/BsSJ6RYBqOdKm0ahN7+w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Ghanashyam, http://datatracker.ietf.org/doc/draft-tsou-multrans-addr-acquisition/ http://datatracker.ietf.org/doc/draft-zhou-multrans-af1-specification/ Running code exists. Hope it helps. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ghanashyam Satpathy Sent: Sunday, December 18, 2011 3:14 AM To: ipv6@ietf.org Subject: Question on IPV4/IPV6 Multicast interoperability Hello, I have a question on IPV4/IPV6 Multicast interoperability. We have succesfully upgraded our application(Windows Based) to support IPV6 and faced issue on multicast interoperability. Multicast messages sent by a IPV6 server is successfully receved by a client running on IPV6. But any client running on IPV4 is not able to receive the message. Quite a no. of things I tried like using IPV4 mapped IPV6 address and V4 embeded V6 adress.But nothing seems to be working.Would like to know an unified way so that one multicast message sent by an IPV6 server should be received by both V6 and V4 client. Would be great if somebody can send some code snippet(C/C++) on it. Thanks. Ghanashyam --Boundary_(ID_f/BsSJ6RYBqOdKm0ahN7+w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Ghanashyam,

http://datatracker.ietf.org/doc/draft-tsou-multrans-addr-acquisition/

http://datatracker.ietf.org/doc/draft-zhou-multrans-af1-specification/

Running code exists.

Hope it helps.

 

Best Regards,

Tina TSOU

http://tinatsou.weebly.com/contact.html

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ghanashyam Satpathy
Sent: Sunday, December 18, 2011 3:14 AM
To: ipv6@ietf.org
Subject: Question on IPV4/IPV6 Multicast interoperability

 

Hello,

 

I have a question on IPV4/IPV6 Multicast interoperability. We have succesfully upgraded our application(Windows Based) to support IPV6 and faced issue on multicast interoperability. Multicast messages sent by a IPV6 server is successfully receved by a client running on IPV6. But any client running on IPV4 is not able to receive the message.

 

Quite a no. of things I tried like using IPV4 mapped IPV6 address and V4 embeded V6 adress.But nothing seems to be working.Would like to know an unified way so that one multicast message sent by an IPV6 server should be received by both V6 and V4 client.

 

Would be great if somebody can send some code snippet(C/C++) on it.

 

Thanks.

 

Ghanashyam

 

 

 

 

--Boundary_(ID_f/BsSJ6RYBqOdKm0ahN7+w)-- From susan.hares@huawei.com Thu Dec 22 15:09:10 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3788821F848E; Thu, 22 Dec 2011 15:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjzjKsYe2URQ; Thu, 22 Dec 2011 15:09:09 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6693421F845E; Thu, 22 Dec 2011 15:09:09 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ACA62211; Thu, 22 Dec 2011 18:09:09 -0500 (EST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Dec 2011 15:07:37 -0800 Received: from DFWEML504-MBX.china.huawei.com ([10.124.31.30]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Thu, 22 Dec 2011 15:07:34 -0800 From: Susan Hares To: Tina TSOU , "Lee, Yiu" , "mboned@ietf.org" , "multrans@ietf.org" Thread-Topic: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP Thread-Index: AczAfqWGmoLJV3pISzqQ/pwXEhM9kQAOmG6AABE7h2AAABQtEA== Date: Thu, 22 Dec 2011 23:07:33 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14616C1D2C8@dfweml504-mbx> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 23 Dec 2011 13:53:48 -0800 Subject: Re: [multrans] [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 23:09:10 -0000 Yiu Lee: Many people who I asked about live feeds, said the live feeds were often sh= ifted 5-20 minutes and then done as normal video streaming. Is this true?=20 Thanks, and If I don't hear from you.. Merry Christmas, Sue=20 -----Original Message----- From: Tina TSOU=20 Sent: Thursday, December 22, 2011 6:05 PM To: Lee, Yiu; mboned@ietf.org; multrans@ietf.org Subject: RE: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP Yiu, You address my puzzle. Thanks and Merry X'mas! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: Thursday, December 22, 2011 2:50 PM To: Tina TSOU; mboned@ietf.org; multrans@ietf.org Subject: Re: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP For OTT providers, unicast is the current option to deliver live content be= cause inter-domain multicast is uncommon. Speaking of trend, using unicast = for broadcasting is inefficient IMHO, so I don't see why using http to deli= ver live content is the trend. My 2 cents. On 12/22/11 2:52 AM, "Tina TSOU" wrote: >Hi, >Someone mentioned that it seems the trend that carriers' IPTV uses=20 >unicast, OTT/HTTP, rather than multicast. >Thoughts? > >Sent from my iPad >_______________________________________________ >MBONED mailing list >MBONED@ietf.org >https://www.ietf.org/mailman/listinfo/mboned From susan.hares@huawei.com Thu Dec 22 15:17:36 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA0521F84A1; Thu, 22 Dec 2011 15:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikbr7lLLmvFt; Thu, 22 Dec 2011 15:17:35 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 89DEB21F84A2; Thu, 22 Dec 2011 15:17:35 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABT64355; Thu, 22 Dec 2011 18:17:35 -0500 (EST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Dec 2011 15:16:09 -0800 Received: from DFWEML504-MBX.china.huawei.com ([10.124.31.30]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Thu, 22 Dec 2011 15:16:07 -0800 From: Susan Hares To: "Lee, Yiu" , Tina TSOU , "mboned@ietf.org" , "multrans@ietf.org" Thread-Topic: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP Thread-Index: AQHMwP8omoLJV3pISzqQ/pwXEhM9kZXofQxQ Date: Thu, 22 Dec 2011 23:16:07 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14616C1D308@dfweml504-mbx> References: <728F9B956B2C48439CA9294B1723B14616C1D2C8@dfweml504-mbx> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 23 Dec 2011 13:53:48 -0800 Subject: Re: [multrans] [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 23:17:36 -0000 Yiu: Wow! Thanks for the quick response. I was a bit unclear.=20 My understanding is that the buffering actually pushes things toward the mu= lticast model. Sue=20 -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, December 22, 2011 6:12 PM To: Susan Hares; Tina TSOU; mboned@ietf.org; multrans@ietf.org Subject: Re: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP Hi Sue, I think it really depends whom you speak to. Buffering can be done in diffe= rent places (e.g., broadcast stations put 5 sec delay in their live streams= ). This requirement alone won't require unicast streaming. Cheers, Yiu On 12/22/11 6:07 PM, "Susan Hares" wrote: > Yiu Lee: > >Many people who I asked about live feeds, said the live feeds were=20 >often shifted 5-20 minutes and then done as normal video streaming. > >Is this true?=20 > >Thanks, and If I don't hear from you.. Merry Christmas, > >Sue > >-----Original Message----- >From: Tina TSOU >Sent: Thursday, December 22, 2011 6:05 PM >To: Lee, Yiu; mboned@ietf.org; multrans@ietf.org >Subject: RE: [MBONED] Carriers' IPTV uses multicast vs unicast,=20 >OTT/HTTP > >Yiu, >You address my puzzle. Thanks and Merry X'mas! > > >Best Regards, >Tina TSOU >http://tinatsou.weebly.com/contact.html > > >-----Original Message----- >From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >Sent: Thursday, December 22, 2011 2:50 PM >To: Tina TSOU; mboned@ietf.org; multrans@ietf.org >Subject: Re: [MBONED] Carriers' IPTV uses multicast vs unicast,=20 >OTT/HTTP > >For OTT providers, unicast is the current option to deliver live=20 >content because inter-domain multicast is uncommon. Speaking of trend,=20 >using unicast for broadcasting is inefficient IMHO, so I don't see why=20 >using http to deliver live content is the trend. > >My 2 cents. > > >On 12/22/11 2:52 AM, "Tina TSOU" wrote: > >>Hi, >>Someone mentioned that it seems the trend that carriers' IPTV uses=20 >>unicast, OTT/HTTP, rather than multicast. >>Thoughts? >> >>Sent from my iPad >>_______________________________________________ >>MBONED mailing list >>MBONED@ietf.org >>https://www.ietf.org/mailman/listinfo/mboned > From susan.hares@huawei.com Thu Dec 22 15:24:33 2011 Return-Path: X-Original-To: multrans@ietfa.amsl.com Delivered-To: multrans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4530E21F84B8; Thu, 22 Dec 2011 15:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvfJGin62OtK; Thu, 22 Dec 2011 15:24:32 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4B021F84B4; Thu, 22 Dec 2011 15:24:32 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id ABT64694; Thu, 22 Dec 2011 18:24:32 -0500 (EST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Dec 2011 15:23:03 -0800 Received: from DFWEML504-MBX.china.huawei.com ([10.124.31.30]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Thu, 22 Dec 2011 15:22:52 -0800 From: Susan Hares To: "Lee, Yiu" , Tina TSOU , "mboned@ietf.org" , "multrans@ietf.org" Thread-Topic: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP Thread-Index: AQHMwQBdmoLJV3pISzqQ/pwXEhM9kZXofuoA Date: Thu, 22 Dec 2011 23:22:52 +0000 Message-ID: <728F9B956B2C48439CA9294B1723B14616C1D32F@dfweml504-mbx> References: <728F9B956B2C48439CA9294B1723B14616C1D308@dfweml504-mbx> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 23 Dec 2011 13:53:48 -0800 Subject: Re: [multrans] [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 23:24:33 -0000 Yiu: My understanding is that the buffering of the live event is at the source -= just like a video would be recorded. The actual deliver uses the multicast= infrastructure to be efficient.=20 Am I clearer this time? Maybe I need to drink more coffee. Cheers, Sue =20 -----Original Message----- From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, December 22, 2011 6:21 PM To: Susan Hares; Tina TSOU; mboned@ietf.org; multrans@ietf.org Subject: Re: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP AFAIK, the major push to use multicast is to preserve bandwidth. I don't se= e how buffering would make multicast even more favorable. If so, I would li= ke to know why. On 12/22/11 6:16 PM, "Susan Hares" wrote: > Yiu: > >Wow! Thanks for the quick response. I was a bit unclear. > >My understanding is that the buffering actually pushes things toward=20 >the multicast model. > >Sue > >-----Original Message----- >From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >Sent: Thursday, December 22, 2011 6:12 PM >To: Susan Hares; Tina TSOU; mboned@ietf.org; multrans@ietf.org >Subject: Re: [MBONED] Carriers' IPTV uses multicast vs unicast,=20 >OTT/HTTP > >Hi Sue, > >I think it really depends whom you speak to. Buffering can be done in=20 >different places (e.g., broadcast stations put 5 sec delay in their=20 >live streams). This requirement alone won't require unicast streaming. > >Cheers, >Yiu > > >On 12/22/11 6:07 PM, "Susan Hares" wrote: > >> Yiu Lee: >> >>Many people who I asked about live feeds, said the live feeds were=20 >>often shifted 5-20 minutes and then done as normal video streaming. >> >>Is this true?=20 >> >>Thanks, and If I don't hear from you.. Merry Christmas, >> >>Sue >> >>-----Original Message----- >>From: Tina TSOU >>Sent: Thursday, December 22, 2011 6:05 PM >>To: Lee, Yiu; mboned@ietf.org; multrans@ietf.org >>Subject: RE: [MBONED] Carriers' IPTV uses multicast vs unicast,=20 >>OTT/HTTP >> >>Yiu, >>You address my puzzle. Thanks and Merry X'mas! >> >> >>Best Regards, >>Tina TSOU >>http://tinatsou.weebly.com/contact.html >> >> >>-----Original Message----- >>From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] >>Sent: Thursday, December 22, 2011 2:50 PM >>To: Tina TSOU; mboned@ietf.org; multrans@ietf.org >>Subject: Re: [MBONED] Carriers' IPTV uses multicast vs unicast,=20 >>OTT/HTTP >> >>For OTT providers, unicast is the current option to deliver live=20 >>content because inter-domain multicast is uncommon. Speaking of trend,=20 >>using unicast for broadcasting is inefficient IMHO, so I don't see why=20 >>using http to deliver live content is the trend. >> >>My 2 cents. >> >> >>On 12/22/11 2:52 AM, "Tina TSOU" wrote: >> >>>Hi, >>>Someone mentioned that it seems the trend that carriers' IPTV uses=20 >>>unicast, OTT/HTTP, rather than multicast. >>>Thoughts? >>> >>>Sent from my iPad >>>_______________________________________________ >>>MBONED mailing list >>>MBONED@ietf.org >>>https://www.ietf.org/mailman/listinfo/mboned >> >