From Tina.Tsou.Zouting@huawei.com Fri Oct 7 13:52: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 8D10C21F8888 for ; Fri, 7 Oct 2011 13:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 A-778J8QGPah for ; Fri, 7 Oct 2011 13:52:41 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEBE21F86EC for ; Fri, 7 Oct 2011 13:52:41 -0700 (PDT) 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 <0LSP000PHRH5HR@szxga03-in.huawei.com> for multrans@ietf.org; Sat, 08 Oct 2011 04:55:53 +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 <0LSP0085BRH584@szxga03-in.huawei.com> for multrans@ietf.org; Sat, 08 Oct 2011 04:55:53 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC54099; Sat, 08 Oct 2011 04:55:51 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 08 Oct 2011 04:55:37 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.58]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Sat, 08 Oct 2011 04:55:41 +0800 Date: Fri, 07 Oct 2011 20:55:41 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.158] To: "multrans@ietf.org" 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: BoF in Taipei Thread-index: AcyFM3g2vMCjh9ysRMC+jv63J/vQZg== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: JPA= AQEX ASB7 A+Qf BC4r B8pN B+3e DaE4 D7Oi Fe94 GtjK JTdW Jped Lazo LdAx Ljv9; 1; bQB1AGwAdAByAGEAbgBzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {30900618-252E-4646-9499-87BDDD5DCC90}; dABpAG4AYQAuAHQAcwBvAHUALgB6AG8AdQB0AGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 07 Oct 2011 20:55:39 GMT;QgBvAEYAIABpAG4AIABUAGEAaQBwAGUAaQA= x-cr-puzzleid: {30900618-252E-4646-9499-87BDDD5DCC90} X-CFilter-Loop: Reflected Subject: [multrans] BoF in Taipei 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, 07 Oct 2011 20:52:42 -0000 http://trac.tools.ietf.org/bof/trac/wiki/WikiStart Operations and Management=B6 MULTRANS - Multicast Transition=20 Description: This BOF proposal is for discussing operational issues that IP= TV providers will face during the IPv4/IPv6 transition period and ALG solut= ions to those problems.=20 Length of session: 120 minutes=20 Responsible AD: Ron Bonica=20 Chairs: Greg Shepherd, Marshall Eubanks=20 Main driver: Tina Tsou=20 Expected Attendees: 100=20 Conflicts to avoid: All OPS WGs, PIM, RMT, SOFTWIRE, BEHAVE=20 Mailing list: https://www.ietf.org/mailman/listinfo/multrans=20 Drafts: http://tools.ietf.org/html/draft-jaclee-behave-v4v6-mcast-ps-02 h= ttps://datatracker.ietf.org/doc/draft-boucadair-behave-64-multicast-address= -format/=20 Agenda: http://www.bonica.org/dropbox/multranAgenda.txt=20 WebEx requested: TBD=20 Charter: http://www.bonica.org/dropbox/multrancharter.txt=20 Status: Approved=20 Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From Tina.Tsou.Zouting@huawei.com Mon Oct 31 12:49: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 9423021F8CCA for ; Mon, 31 Oct 2011 12:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.895 X-Spam-Level: X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[AWL=0.704, 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 oD9rrCiVKSPc for ; Mon, 31 Oct 2011 12:49:36 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 010EA21F8CC2 for ; Mon, 31 Oct 2011 12:49:36 -0700 (PDT) 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 <0LTY0037X4ENO9@szxga04-in.huawei.com> for multrans@ietf.org; Tue, 01 Nov 2011 03:49:35 +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 <0LTY00KOE4ENIV@szxga04-in.huawei.com> for multrans@ietf.org; Tue, 01 Nov 2011 03:49:35 +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 AEV30764; Tue, 01 Nov 2011 03:49:34 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 03:49:33 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.58]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 03:49:28 +0800 Date: Mon, 31 Oct 2011 19:49:28 +0000 From: Tina TSOU X-Originating-IP: [10.193.34.114] To: "multrans@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Importance: high Accept-Language: en-US, zh-CN X-Priority: 1 Thread-topic: Update of Multrans Problem Statement and Use Case draft Thread-index: AQHMmAUNjJb88rY39k25ujOJwT530ZWW2+xw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [multrans] Update of Multrans Problem Statement and Use Case 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: Mon, 31 Oct 2011 19:49:36 -0000 Dear all, Version -03 of the Multrans Problem Statement and Use Case draft has been submitted. By agreement amongst the authors, the diagrams and updated descriptions from draft-tsou-multrans-use-cases-00 have been absorbed into the problem statement and use case draft. https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ now presents the following use cases, all within the agreed context of IPTV: 1. IPv4 Receiver and Source Connected to an IPv6-Only Network (4-6-4) 2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 Multicast-Incapable Access Network and an IPv6 Multicast-Capable Network (6-4-6-4) 3. IPv6 Receiver and Source Connected to an IPv4-Only Network (6-4-6) 4. IPv6 Receiver and IPv4 Source (6-4) 5. IPv4 Receiver and IPv6 Source (4-6) The diagrams and accompanying text show a potential solution to the problem of differing IP versions through the use of nodes embodying "adaptation functions". The Multrans BoF was negotiated on the basis of solutions where these adaptation functions consisted of application layer gateways (ALGs). Comments on this assumption and how it should work are invited. B. R. Tina +1-408-859-4996 From gjshep@gmail.com Mon Oct 31 13:26:00 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 D5AFF11E8211 for ; Mon, 31 Oct 2011 13:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 LCTGx73fCw4F for ; Mon, 31 Oct 2011 13:26:00 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1653811E81D7 for ; Mon, 31 Oct 2011 13:25:59 -0700 (PDT) Received: by bkat8 with SMTP id t8so2059731bka.31 for ; Mon, 31 Oct 2011 13:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jIu2WqAsfabR08dSrbSLa2PIYJpcrV7dipfJYOY/MqY=; b=IskzoHcqmxD/Qsb1A9sRQD3hfjey6ETeimfbrfgOXSnJgszeNflGHQwvn3U1NJd4bP WiwEjL6q18H03v/FMoRD7hQHgFVJ/cBiKvw9CK01opDusWpBtpsD2GHhwgJN3uPiiPsb Yggsy2P/eyt2uWXHErJ3/68YU+3LZxsTrcDVA= MIME-Version: 1.0 Received: by 10.204.50.132 with SMTP id z4mr12664944bkf.29.1320092759102; Mon, 31 Oct 2011 13:25:59 -0700 (PDT) Received: by 10.204.40.5 with HTTP; Mon, 31 Oct 2011 13:25:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Oct 2011 13:25:59 -0700 Message-ID: From: Greg Shepherd To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Cc: "multrans@ietf.org" Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case draft X-BeenThere: multrans@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com List-Id: "Discuss the work of IPv4-IPv6 multicast." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:26:00 -0000 Tina, This list still seems to be missing the case Alain brought up in Quebec - L2 last mile w/ both v4 & v6 receivers but only one stream desired to serve both. Greg On Mon, Oct 31, 2011 at 12:49 PM, Tina TSOU wrote: > Dear all, > Version -03 of the Multrans Problem Statement and Use Case draft has > been submitted. By agreement amongst the authors, the diagrams and > updated descriptions from draft-tsou-multrans-use-cases-00 have been > absorbed into the problem statement and use case draft. > > https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ now > presents the following use cases, all within the agreed context of IPTV: > > 1. IPv4 Receiver and Source Connected to an IPv6-Only Network (4-6-4) > > 2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 > Multicast-Incapable Access Network and an IPv6 Multicast-Capable Network > (6-4-6-4) > > 3. IPv6 Receiver and Source Connected to an IPv4-Only Network (6-4-6) > > 4. IPv6 Receiver and IPv4 Source (6-4) > > 5. IPv4 Receiver and IPv6 Source (4-6) > > The diagrams and accompanying text show a potential solution to the > problem of differing IP versions through the use of nodes embodying > "adaptation functions". The Multrans BoF was negotiated on the basis of > solutions where these adaptation functions consisted of application > layer gateways (ALGs). Comments on this assumption and how it should > work are invited. > > > > B. R. > Tina > +1-408-859-4996 > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans > From tom111.taylor@bell.net Mon Oct 31 13:58: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 541CE11E8286 for ; Mon, 31 Oct 2011 13:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.796 X-Spam-Level: X-Spam-Status: No, score=-101.796 tagged_above=-999 required=5 tests=[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 IdLeDAlPxnUt for ; Mon, 31 Oct 2011 13:58:08 -0700 (PDT) Received: from blu0-omc4-s5.blu0.hotmail.com (blu0-omc4-s5.blu0.hotmail.com [65.55.111.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6064D11E8284 for ; Mon, 31 Oct 2011 13:58:08 -0700 (PDT) Received: from BLU0-SMTP53 ([65.55.111.136]) by blu0-omc4-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 13:58:08 -0700 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-SMTP53.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 13:58:06 -0700 Date: Mon, 31 Oct 2011 16:58:06 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: multrans@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Oct 2011 20:58:06.0827 (UTC) FILETIME=[CA06B3B0:01CC980F] Subject: Re: [multrans] Update of Multrans Problem Statement and Use Case 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: Mon, 31 Oct 2011 20:58:10 -0000 I think this fits into the scenarios presented if the adaptation function is located at the customer site. Otherwise, I can't really see how it would be possible. Tom Taylor On 31/10/2011 4:25 PM, Greg Shepherd wrote: > Tina, > > This list still seems to be missing the case Alain brought up in > Quebec - L2 last mile w/ both v4& v6 receivers but only one stream > desired to serve both. > > Greg > > On Mon, Oct 31, 2011 at 12:49 PM, Tina TSOU > wrote: >> Dear all, >> Version -03 of the Multrans Problem Statement and Use Case draft has >> been submitted. By agreement amongst the authors, the diagrams and >> updated descriptions from draft-tsou-multrans-use-cases-00 have been >> absorbed into the problem statement and use case draft. >> >> https://datatracker.ietf.org/doc/draft-jaclee-behave-v4v6-mcast-ps/ now >> presents the following use cases, all within the agreed context of IPTV: >> >> 1. IPv4 Receiver and Source Connected to an IPv6-Only Network (4-6-4) >> >> 2. IPv6 Receiver Connected to an IPv4 Source Through an IPv4 >> Multicast-Incapable Access Network and an IPv6 Multicast-Capable Network >> (6-4-6-4) >> >> 3. IPv6 Receiver and Source Connected to an IPv4-Only Network (6-4-6) >> >> 4. IPv6 Receiver and IPv4 Source (6-4) >> >> 5. IPv4 Receiver and IPv6 Source (4-6) >> >> The diagrams and accompanying text show a potential solution to the >> problem of differing IP versions through the use of nodes embodying >> "adaptation functions". The Multrans BoF was negotiated on the basis of >> solutions where these adaptation functions consisted of application >> layer gateways (ALGs). Comments on this assumption and how it should >> work are invited. >> >> >> >> B. R. >> Tina >> +1-408-859-4996 >> _______________________________________________ >> multrans mailing list >> multrans@ietf.org >> https://www.ietf.org/mailman/listinfo/multrans >> > _______________________________________________ > multrans mailing list > multrans@ietf.org > https://www.ietf.org/mailman/listinfo/multrans > > From Tina.Tsou.Zouting@huawei.com Mon Oct 31 20:27:16 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 7162811E8082 for ; Mon, 31 Oct 2011 20:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.670, 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 pj43NKG0vOSQ for ; Mon, 31 Oct 2011 20:27:15 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B2F2921F899F for ; Mon, 31 Oct 2011 20:27:14 -0700 (PDT) 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 <0LTY003JIPIWO9@szxga04-in.huawei.com> for multrans@ietf.org; Tue, 01 Nov 2011 11:25:45 +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 <0LTY00FD6PIW3N@szxga04-in.huawei.com> for multrans@ietf.org; Tue, 01 Nov 2011 11:25:44 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ83905; Tue, 01 Nov 2011 11:25:19 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 11:25:15 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.58]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 11:25:10 +0800 Date: Tue, 01 Nov 2011 03:25:10 +0000 From: Tina TSOU In-reply-to: <94C682931C08B048B7A8645303FDC9F35A378802B5@PUEXCB1B.nanterre.francetelecom.fr> X-Originating-IP: [10.212.246.224] To: "mohamed.boucadair@orange.com" 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: Proposed text to draft-boucadair Thread-index: AcyTdSwDjXvUNUDTTYuTgNXW0FIAIgAMHjXgAAMJFuAAHB98MAATisUwAPTRXqA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <94C682931C08B048B7A8645303FDC9F35A3787FF5E@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F35A378802B5@PUEXCB1B.nanterre.francetelecom.fr> Cc: "multrans@ietf.org" Subject: Re: [multrans] Proposed text to draft-boucadair 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, 01 Nov 2011 03:27:16 -0000 Bonjour Med, You justify the "sub-group-id" by relying on RFC 4291 (you say 4261, but th= at's a typo). However, RFC 4291 says: 2.7. Multicast Addresses An IPv6 multicast address is an identifier for a group of interfaces (t= ypically on different nodes). An interface may belong to any number of mul= ticast groups. Multicast addresses have the following format (I tried the = font "courier new" here, but it cannot be shown in MS Outlook): | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ binary 11111111 at the start of the address identifies the address a= s being a multicast address. .... group ID identifies the multicast group, either permanent or transient, within the given scope. Additional definitions of the mu= lticast group ID field structure are provided in [RFC3306]. So it's RFC 3306 that's the final authority, as I stated. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Wednesday, October 26, 2011 12:37 AM To: Tina TSOU Cc: draft-boucadair-behave-64-multicast-address-format@tools.ietf.org Subject: RE: Proposed text to draft-boucadair Hi Tina, I uploaded an updated version taking into account some of your comments.=20 The diff can be found: http://tools.ietf.org/rfcdiff?url2=3Ddraft-boucadair= -behave-64-multicast-address-format-03 Cheers Med -----Message d'origine----- De : BOUCADAIR Mohamed OLNC/NAD/TIP=20 Envoy=E9 : mercredi 26 octobre 2011 08:44 =C0 : 'Tina TSOU' Objet : RE: Proposed text to draft-boucadair Hi Tina, Thank you for the review. Please see inline. Cheers, Med=20 -----Message d'origine----- De : Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20 Envoy=E9 : mercredi 26 octobre 2011 02:21 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Objet : Proposed text to draft-boucadair Bonjour Med, Having studied RFCs 3306, 3307, 3956, 4291, and 6308 to set a context, I ha= ve the following comments on draft-boucadair-behave-64-multicast-address-fo= rmat-02.txt: 1. Given the long line of predecessors just listed, the draft should model = itself on them by concentrating on the address format definition (sections = 7-9 of the present draft). Discussion of the use in different transition ca= ses should be brief, and limited to the introduction. There is no need to d= iscuss interworking functions or translation vs. encapsulation functions --= these are topics for other drafts which apply the content of this one. Med: I moved several section to an appendix so that the core text focuses o= n the address specification. 2. Section 6.2 is useful, since the use of the remaining flag bit is indeed= very tempting. However, this is non-normative material and should be in an= appendix. Med: I moved that text to an appendix. 3. The address format should as much as possible model itself on RFC3306 as= its basis. In particular, it is unnecessary to define a new entity, the su= b-group-id. Just use the network prefix combined with plen for ASM. SSM nee= ds slightly different handling, of course, but since the "sub-group-id" is = all zeros, one could use a more neutral term. Med: Why should we model the prefix to RFC3306? I understand we need to be = able to support rfc3306 for unicast and also rfc but the base is imho rfc42= 61. in rfc4261, there is "group ID". The current text says: o sub-group-id: This field is configurable according to local policies of the entity managing the IPv4-IPv6 Interconnection Function. This field must follow the recommendations specified in [RFC3306] if If unicast-based prefix is used or the recommendations specified in [RFC3956] if embedded-RP is used. The default value is all zeros. Is there any issue with that text? 4. There is no need for section 10. It is up to the operator what sort of n= etwork prefix it wishes to define for ASM -- RFC 3306 gives several example= s. Med: I don't think we can model this document as per rfc3306 because we nee= d to do address synthesize and only; the service will provision the m_prefi= x64. That's why we need to explain that. Does this make sense to you? 5. The SSM address form should definitely be restricted to IPv4 SSM address= es in the lower 32 bits. This guarantees that those bits will be in the val= id range as specified by RFC 3307. The ASM lower 32 bits might as well be s= imilarly restricted to IPv4 ASM addresses. In brief, the draft should be an update to RFC 3306 rather than 6052, and s= hould be rather shorter. Med: It is not an update of RFC3306 but RFC4291 because we don't define a u= nicast prefix based multicast address. I removed the reference to RFC6052.= =20 Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html http://www.huawei.com/en/solutions/expand-broadband/hw-092950-ipv6.htm