From tena@huawei.com Thu Jan 6 15:29:56 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449243A6E3F for ; Thu, 6 Jan 2011 15:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.206 X-Spam-Level: X-Spam-Status: No, score=-106.206 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psWvNpHgEN0D for ; Thu, 6 Jan 2011 15:29:55 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 1B8903A6D23 for ; Thu, 6 Jan 2011 15:29:55 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEM005ZFK1DKU@usaga02-in.huawei.com> for softwires@ietf.org; Thu, 06 Jan 2011 15:32:02 -0800 (PST) Received: from TingZousc1 ([10.193.34.133]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEM00DMAK1DMJ@usaga02-in.huawei.com> for softwires@ietf.org; Thu, 06 Jan 2011 15:32:01 -0800 (PST) Date: Thu, 06 Jan 2011 15:32:01 -0800 From: Tina Tsou To: 'Softwires' Message-id: <017401cbadf9$eb9eb5a0$c2dc20e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acut+enC1UFFZRP7QXCuH0+cJ9FaFw== x-cr-hashedpuzzle: A4U6 BDX1 CNHs CeKb EZFJ FKeN FRv+ GHcR GX+e HGRq HLqd IDDT I0ch I6SL J+QX LBnx; 1; cwBvAGYAdAB3AGkAcgBlAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8821F8CB-C556-4389-92D4-089E6B74A5C6}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Thu, 06 Jan 2011 23:31:59 GMT;NgByAGQAIABtAHUAbAB0AGkAYwBhAHMAdAA= x-cr-puzzleid: {8821F8CB-C556-4389-92D4-089E6B74A5C6} Subject: [Softwires] 6rd multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 23:29:56 -0000 Hi all, http://datatracker.ietf.org/doc/draft-tsou-softwire-6rd-multicast/ is available. This document describes how IPv6 multicast can be extended across an IPv4 network to an IPv6 host, using the native multicast capabilities of the IPv4 network. This is a first draft, and definitely needs more work. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From yiu_lee@cable.comcast.com Fri Jan 7 12:06:56 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06C6B3A696C for ; Fri, 7 Jan 2011 12:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.512 X-Spam-Level: X-Spam-Status: No, score=-104.512 tagged_above=-999 required=5 tests=[AWL=-2.778, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 957QCv-AupTo for ; Fri, 7 Jan 2011 12:06:55 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id AD5B03A6920 for ; Fri, 7 Jan 2011 12:03:36 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.21426674; Fri, 07 Jan 2011 13:15:48 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0270.001; Fri, 7 Jan 2011 15:05:39 -0500 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: DS-lite Multicast Thread-Index: AQHLrqZATIgntYAAg0GEOps/sLKxWg== Date: Fri, 7 Jan 2011 20:05:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: multipart/alternative; boundary="_000_C94CDC40649Ayiuleecablecomcastcom_" MIME-Version: 1.0 Subject: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:06:56 -0000 --_000_C94CDC40649Ayiuleecablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We submitted a version 02 of the DS-lite Multicast. Compared to the previou= s version, we clarified the procedure of building the IPv6 Multicast Distri= bution Tree and the Multicast AFTR functionality. The authors spent a lot o= f effort to specify the Multicast AFTR IWF between the IPv4 and IPv6 mcast = signaling (PIMv4-PIMv6 and IGMP-MLD). We appreciate any input and comment. You can read the draft at : http://tools.ietf.org/html/draft-qin-softwire-d= slite-multicast-02 Thanks, Yiu --_000_C94CDC40649Ayiuleecablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <477B5F025758754AB8F8233EA35738CB@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Hi all,

We submitted a version 02 of the DS-lite Multicast. Compared to the pr= evious version, we clarified the procedure of building the IPv6 Multicast D= istribution Tree and the Multicast AFTR functionality. The authors spent a = lot of effort to specify the Multicast AFTR IWF between the IPv4 and IPv6 mcast signaling (PIMv4-PIMv6 and IGMP-M= LD). We appreciate any input and comment.

You can read the draft at : http://tools.ietf.org/html/draft-qin-softw= ire-dslite-multicast-02

Thanks,
Yiu



--_000_C94CDC40649Ayiuleecablecomcastcom_-- From yiu_lee@cable.comcast.com Fri Jan 7 12:48:25 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2FA3A6989 for ; Fri, 7 Jan 2011 12:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.678 X-Spam-Level: X-Spam-Status: No, score=-107.678 tagged_above=-999 required=5 tests=[AWL=0.785, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUkkuKdkwtrX for ; Fri, 7 Jan 2011 12:48:24 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 537383A6993 for ; Fri, 7 Jan 2011 12:47:58 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.110279895; Fri, 07 Jan 2011 15:50:59 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Fri, 7 Jan 2011 15:49:56 -0500 From: "Lee, Yiu" To: Tina Tsou , 'Softwires' Thread-Topic: [Softwires] 6rd multicast Thread-Index: AQHLrqxwYQfuap/hBke+tcrXiJ2f7Q== Date: Fri, 7 Jan 2011 20:49:56 +0000 Message-ID: In-Reply-To: <017401cbadf9$eb9eb5a0$c2dc20e0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] 6rd multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 20:48:25 -0000 Hi Tina, I read the draft and I got few comments. Generally, it contains some interesting ideas and thanks for writing the draft. However, it also misses few key components that we must address to make it work: 1. IPv6 Mcast group -> IPv4 Mcast group. By design and pointed out in the mesh-mcast draft, v6 mcast group has much larger space than v4 mcast group, how do you foresee the mapping being done? This is the key part before describing the mechanism. 2. If I read the draft correctly, the 6rd CE will send a message (TBD) to the Translator Function (TF) to ask the 6rd BR to join the v6 mcast tree and give the mapping to the 6rd CE. Then 6rd CE will send a PIMv4-Join to the upstream mcast router. My question is why not ask the 6rd CE to translate the MLDv2 to IGMP directly? What is the benefit of defining a new protocol? 3. Section 3 mentioned that IGMPv3 is used. What is S? The 6rd BR? 4. I am not clear how Section 4 works. I assume 6rd-BR is a mcast router, so you are saying it will ask TR for a mapping when it receives a PIM-Join? How does 6rd-BR know which v4 grouds are meant for translation and which aren't? These are my comments so far. Regards, Yiu On 1/6/11 6:32 PM, "Tina Tsou" wrote: >Hi all, > >http://datatracker.ietf.org/doc/draft-tsou-softwire-6rd-multicast/ > >is available. > >This document describes how IPv6 multicast can be extended across an > IPv4 network to an IPv6 host, using the native multicast capabilities > of the IPv4 network. > >This is a first draft, and definitely needs more work. > > >Best Regards, >Tina TSOU >http://tinatsou.weebly.com/contact.html > > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Fri Jan 7 13:05:52 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081C13A6948 for ; Fri, 7 Jan 2011 13:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.366 X-Spam-Level: X-Spam-Status: No, score=-104.366 tagged_above=-999 required=5 tests=[AWL=-2.631, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9rWg0pe9okl for ; Fri, 7 Jan 2011 13:05:51 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 284723A6947 for ; Fri, 7 Jan 2011 13:05:51 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.21439564; Fri, 07 Jan 2011 14:17:39 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0270.001; Fri, 7 Jan 2011 16:07:32 -0500 From: "Lee, Yiu" To: Tom Taylor Thread-Topic: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-gwinit-6rd-02 Thread-Index: AQHLrq7lAAZukNU3rkKbvKYCC4e0IA== Date: Fri, 7 Jan 2011 21:07:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <0902F8F009C3AD4DA07FB546C61BD0C4@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-gwinit-6rd-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 21:05:52 -0000 Hi Tom,=20 Sorry for the late reply. See inline: On 12/20/10 9:39 PM, "Tom Taylor" wrote: >[PTT] One possibility is that the initial prefix potentially varies per >customer (e.g., depending on service class) and is available from AAA. >However, the set of possible initial prefixes has to be limited so the >BR can recognize that it can extract a Gateway Identifier (i.e., tunnel >identifier, see next response) from a given incoming packet. If I read it right, the customer's prefix needs not to be embedded in the 6rd prefix. Then, how you foresee the AAA and BR exchange the customer's prefix? In particular, this will require the AAA server to let the BR to inject an IPv6 route per customer. This will also require the AAA server to remember which BR the 6rd-GW must use. >[PTT] If the tunnel is IPv6 in IPv4, the GW identifier is the compressed >IPv4 address of the GW, as in RFC 5969. For other types of tunnel, I >expect (but haven't worked it out in detail) that the identifier would >be some sort of tunnel identifier. The catch would be to have an >identifier that is common to both the GW and BR ends and fits in the >bits available. Got it. Depending the size of the deployment and the 6rd prefix compression ratio, an ISP may require to deploy few 6rd domains. Cheers, Yiu From tom.taylor@huawei.com Fri Jan 7 15:38:09 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4577128C110 for ; Fri, 7 Jan 2011 15:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.155 X-Spam-Level: X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=1.340, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqZfkwsY2yWX for ; Fri, 7 Jan 2011 15:38:08 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5920828C105 for ; Fri, 7 Jan 2011 15:38:03 -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 <0LEO00IIXF2NYW@szxga04-in.huawei.com> for softwires@ietf.org; Sat, 08 Jan 2011 07:39:59 +0800 (CST) Received: from 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 <0LEO008TLF2NIV@szxga04-in.huawei.com> for softwires@ietf.org; Sat, 08 Jan 2011 07:39:59 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEO0031GF2M3L@szxml02-in.huawei.com> for softwires@ietf.org; Sat, 08 Jan 2011 07:39:59 +0800 (CST) Date: Fri, 07 Jan 2011 18:40:03 -0500 From: Tom Taylor In-reply-to: To: Softwires Message-id: <4D27A453.5070400@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 References: Subject: Re: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-gwinit-6rd-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:38:09 -0000 (Another resend.) Please see below under the first comment. On 07/01/2011 4:07 PM, Lee, Yiu wrote: > Hi Tom, > > Sorry for the late reply. See inline: > > On 12/20/10 9:39 PM, "Tom Taylor" wrote: > >> [PTT] One possibility is that the initial prefix potentially varies per >> customer (e.g., depending on service class) and is available from AAA. >> However, the set of possible initial prefixes has to be limited so the >> BR can recognize that it can extract a Gateway Identifier (i.e., tunnel >> identifier, see next response) from a given incoming packet. > > If I read it right, the customer's prefix needs not to be embedded in the > 6rd prefix. Then, how you foresee the AAA and BR exchange the customer's > prefix? In particular, this will require the AAA server to let the BR to > inject an IPv6 route per customer. This will also require the AAA server > to remember which BR the 6rd-GW must use. [PTT] Misunderstanding here. The initial prefix I'm talking about is most definitely embedded in the full 6rd prefix. > >> [PTT] If the tunnel is IPv6 in IPv4, the GW identifier is the compressed >> IPv4 address of the GW, as in RFC 5969. For other types of tunnel, I >> expect (but haven't worked it out in detail) that the identifier would >> be some sort of tunnel identifier. The catch would be to have an >> identifier that is common to both the GW and BR ends and fits in the >> bits available. > > Got it. Depending the size of the deployment and the 6rd prefix > compression ratio, an ISP may require to deploy few 6rd domains. > > > Cheers, > Yiu > > > > From tom.taylor@huawei.com Fri Jan 7 15:38:40 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E29F28B56A for ; Fri, 7 Jan 2011 15:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4YtnAnZpwUh for ; Fri, 7 Jan 2011 15:38:37 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3894328C0E3 for ; Fri, 7 Jan 2011 15:37:21 -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 <0LEO00K9HF1HGX@szxga05-in.huawei.com> for softwires@ietf.org; Sat, 08 Jan 2011 07:39:17 +0800 (CST) Received: from 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 <0LEO004Q6F1H2V@szxga05-in.huawei.com> for softwires@ietf.org; Sat, 08 Jan 2011 07:39:17 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEO0030NF1F3L@szxml02-in.huawei.com> for softwires@ietf.org; Sat, 08 Jan 2011 07:39:17 +0800 (CST) Date: Fri, 07 Jan 2011 18:39:19 -0500 From: Tom Taylor In-reply-to: To: 'Softwires' Message-id: <4D27A427.6060804@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 References: Subject: Re: [Softwires] 6rd multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:38:40 -0000 (I've already sent this to my co-authors and Yiu, but forgot that the IETF lists are currently rejecting my posts from my normal address.) Thanks for your comments. Responses below. BTW, we are going to follow a suggestion to write this draft as a more general mechanism, to cover any case where the host and the target network speak IPvx and the access network between speaks IPvy. We'll try to frame it so the host-end function (still trying to think of a name) can reside either in the CPE or in the provider IP edge. On 07/01/2011 3:49 PM, Lee, Yiu wrote: > Hi Tina, > > I read the draft and I got few comments. Generally, it contains some > interesting ideas and thanks for writing the draft. However, it also > misses few key components that we must address to make it work: > > 1. IPv6 Mcast group -> IPv4 Mcast group. By design and pointed out in the > mesh-mcast draft, v6 mcast group has much larger space than v4 mcast > group, how do you foresee the mapping being done? This is the key part > before describing the mechanism. [PTT] You don't need a mapping for every v6 multicast group, only the ones that someone in your network wants to join. So it's an engineering issue -- how many addresses do you set aside in the address pool to handle your demand? > > 2. If I read the draft correctly, the 6rd CE will send a message (TBD) to > the Translator Function (TF) to ask the 6rd BR to join the v6 mcast tree > and give the mapping to the 6rd CE. Then 6rd CE will send a PIMv4-Join to > the upstream mcast router. My question is why not ask the 6rd CE to > translate the MLDv2 to IGMP directly? What is the benefit of defining a > new protocol? [PTT] No, the new protocol is used only to request a mapping from in the target network to in the access network. The 6rd CE does indeed translate the MLDv2 to IGMP directly (you must have missed a step in your reading), but it needs to know the access network view of the address pair (i.e., ) before doing so. > > 3. Section 3 mentioned that IGMPv3 is used. What is S? The 6rd BR? [PTT] Let's start with the in the target network (IPv6 network, in our current draft). S is wild-carded if the multicast session is any-source (ASM). If the multicast session is specific-source (SSM), then S in the target network is a unicast IPv6 address. The translator maps that to an IPv4 unicast address S' from its pool, and the 6rd CE uses S' in its IGMP request. > > 4. I am not clear how Section 4 works. I assume 6rd-BR is a mcast router, > so you are saying it will ask TR for a mapping when it receives a > PIM-Join? How does 6rd-BR know which v4 grouds are meant for translation > and which aren't? [PTT] That's a point we hadn't thought of -- one of the details that have to be sorted out, along with the question of how the PIM-Join finds the 6rd-BR in the first place. For SSM, the answer is fairly simple: the translator sets S' to the unicast address of the 6rd-BR, as you suggested in an earlier comment. This doesn't work for ASM. > > These are my comments so far. > > Regards, > Yiu > > > On 1/6/11 6:32 PM, "Tina Tsou" wrote: > >> Hi all, >> >> http://datatracker.ietf.org/doc/draft-tsou-softwire-6rd-multicast/ >> >> is available. >> >> This document describes how IPv6 multicast can be extended across an >> IPv4 network to an IPv6 host, using the native multicast capabilities >> of the IPv4 network. >> >> This is a first draft, and definitely needs more work. >> >> >> Best Regards, >> Tina TSOU >> http://tinatsou.weebly.com/contact.html >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > From yiu_lee@cable.comcast.com Fri Jan 7 15:57:43 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8654328C125 for ; Fri, 7 Jan 2011 15:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.566 X-Spam-Level: X-Spam-Status: No, score=-107.566 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcDAbObLwEI7 for ; Fri, 7 Jan 2011 15:57:42 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1E0D128C184 for ; Fri, 7 Jan 2011 15:53:50 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.110298596; Fri, 07 Jan 2011 18:56:52 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Fri, 7 Jan 2011 18:55:52 -0500 From: "Lee, Yiu" To: Tom Taylor Thread-Topic: [Softwires] 6rd multicast Thread-Index: AQHLrsZpp22HT9NGe0Suk4trZA2cnw== Date: Fri, 7 Jan 2011 23:55:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <1715AEE8729EF5429A563D84C0EBB605@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Softwires' Subject: Re: [Softwires] 6rd multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:57:43 -0000 Hi Tom, See comments inline: On 1/7/11 5:17 PM, "Tom Taylor" wrote: >Thanks for your comments. Responses below. BTW, we are going to follow a >suggestion to write this draft as a more general mechanism, to cover any >case where the host and the target network speak IPvx and the access >network between speaks IPvy. We'll try to frame it so the host-end >function (still trying to think of a name) can reside either in the CPE >or in the provider IP edge. [YL] Looking forward to it. >[PTT] You don't need a mapping for every v6 multicast group, only the >ones that someone in your network wants to join. So it's an engineering >issue -- how many addresses do you set aside in the address pool to >handle your demand? [YL] This will require provision in the TF which is an overhead. > >[PTT] No, the new protocol is used only to request a mapping from >in the target network to in the access network. The 6rd CE does >indeed translate the MLDv2 to IGMP directly (you must have missed a step >in your reading), but it needs to know the access network view of the >address pair (i.e., ) before doing so. [YL] Ok. I read the step now: "The 6rd CE interworks between the MLDv2 request it received and an IGMPv3 request." > >[PTT] Let's start with the in the target network (IPv6 network, in >our current draft). S is wild-carded if the multicast session is >any-source (ASM). If the multicast session is specific-source (SSM), >then S in the target network is a unicast IPv6 address. The translator >maps that to an IPv4 unicast address S' from its pool, and the 6rd CE >uses S' in its IGMP request. [YL] Since the draft specified mentioned only IGMPv3, I thought it worked only on SSM. I think the text needed to update. > >[PTT] That's a point we hadn't thought of -- one of the details that >have to be sorted out, along with the question of how the PIM-Join finds >the 6rd-BR in the first place. For SSM, the answer is fairly simple: the >translator sets S' to the unicast address of the 6rd-BR, as you >suggested in an earlier comment. This doesn't work for ASM. [YL] One solution is to ask TF to give all the mappings to the BR (or the TF is collocated with the BR). For the get the PIMv4-Join question, you can make the BR the RP of the special v4 groups which are provisioned for v6 translation. Regards, Yiu From yiu_lee@cable.comcast.com Fri Jan 7 15:57:46 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23F728C137 for ; Fri, 7 Jan 2011 15:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.254 X-Spam-Level: X-Spam-Status: No, score=-104.254 tagged_above=-999 required=5 tests=[AWL=-2.519, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRs9++mm+YTm for ; Fri, 7 Jan 2011 15:57:46 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 8FC8828C192 for ; Fri, 7 Jan 2011 15:56:55 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.21463562; Fri, 07 Jan 2011 17:09:11 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Fri, 7 Jan 2011 18:58:58 -0500 From: "Lee, Yiu" To: Tom Taylor Thread-Topic: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-gwinit-6rd-02 Thread-Index: AQHLrsbZMjT4eIMXPUSPyUroGSUq0w== Date: Fri, 7 Jan 2011 23:58:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <113FFE567F3A384C88638212A7730710@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-gwinit-6rd-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 23:57:46 -0000 Hi Tom, >[PTT] Misunderstanding here. The initial prefix I'm talking about is >most definitely embedded in the full 6rd prefix. Since we have only 64-bit to play around, the more the bits given to the client, the more compression or larger v6 address allocation has to be used. I would like to see some recommendations/examples in the draft. Regards, Yiu From yiu_lee@cable.comcast.com Wed Jan 12 11:37:13 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF8B3A6A98 for ; Wed, 12 Jan 2011 11:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.478 X-Spam-Level: X-Spam-Status: No, score=-107.478 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7GwbXKwDVHN for ; Wed, 12 Jan 2011 11:37:12 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id F17333A6A4C for ; Wed, 12 Jan 2011 11:37:11 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.110694910; Wed, 12 Jan 2011 14:40:37 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0270.001; Wed, 12 Jan 2011 14:39:21 -0500 From: "Lee, Yiu" To: Softwires Thread-Topic: Softwire Multicast Drafts Summary Thread-Index: AQHLspBoAuKWUll2dk+xnr1SfLywQQ== Date: Wed, 12 Jan 2011 19:39:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [147.191.125.14] Content-Type: multipart/alternative; boundary="_000_C9536D956BAEyiuleecablecomcastcom_" MIME-Version: 1.0 Subject: [Softwires] Softwire Multicast Drafts Summary X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 19:37:13 -0000 --_000_C9536D956BAEyiuleecablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In the last Softwire meeting, there were three multicast drafts were presen= ted. They are: 1. draft-brockners-softwire-mcast-gi-ds-lite-00 2. draft-qin-softwire-dslite-multicast-02 3. draft-xu-softwire-mesh-multicast-00 They define how multicast works in different softwire technologies. In the = meeting, the chair asked the authors to get together to analyze any way to = merge them into a single multicast solution. This is our analysis: 1. GI-DS-lite's GW is normally the next-hop of the MH (e.g. GGSM), so the m= cast-gi-ds-lite suggests to create an IPv4-in-IPv6 tunnel to the upstream I= Pv4 mcast router and the GW will join the IPv4 mcast tree. This solution is= simple and doesn't require any new specification. 2. The basic DS-lite defines a solution to deliver unicast IPv4 packets ove= r an IPv6 access network. Multicast is left out-of-scope. The basic DS-lite= defines a single AFTR to serve hundreds to thousands B4 elements and the A= FTR can be deployed deep inside the network. If mcast was delivered over th= e IPv4-in-IPv6 tunnels by the AFTR, this would overload the IPv6 access net= work. The proposed solution is to map the encapsulated the IPv4 mcast group= into IPv6 mcast group. This will use the IPv6 mcast distribution tree to d= eliver the encapsulated IPv4 mcast packets. 3. Mesh-Softwire Multicast shares some similarities of Multicast DS-lite, b= ut it defines a solution of how to use BGP to advertise the next-hop betwee= n E-IPs. This is not required for either GI-DS-lite or Multicast DS-lite. In short, the authors believe the drafts should stay separately because the= y address different problems in very different use cases. Comments and thoughts? Yiu --_000_C9536D956BAEyiuleecablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

In the last Softwire meeting, there were three multicast drafts were p= resented. They are:

1. draft-brockners-softwire-mcast-gi-ds-lite-00



They define how multicast works in different softwire technologies. In= the meeting, the chair asked the authors to get together to analyze any wa= y to merge them into a single multicast solution. This is our analysis:

1. GI-DS-lite's GW is normally the next-hop of the MH (e.g. GGSM), so = the mcast-gi-ds-lite suggests to create an IPv4-in-IPv6 tunnel to the upstr= eam IPv4 mcast router and the GW will join the IPv4 mcast tree. This soluti= on is simple and doesn't require any new specification.

2. The basic DS-lite defines a solution to deliver unicast IPv4 packet= s over an IPv6 access network. Multicast is left out-of-scope. The basic DS= -lite defines a single AFTR to serve hundreds to thousands B4 elements and = the AFTR can be deployed deep inside the network. If mcast was delivered over the IPv4-in-IPv6 tunnels by the A= FTR, this would overload the IPv6 access network. The proposed solution is = to map the encapsulated the IPv4 mcast group into IPv6 mcast group. This wi= ll use the IPv6 mcast distribution tree to deliver the encapsulated IPv4 mcast packets.

3. Mesh-Softwire Multicast shares some similarities of Multicast DS-li= te, but it defines a solution of how to use BGP to advertise the next-hop b= etween E-IPs. This is not required for either GI-DS-lite or Multicast DS-li= te.

In short, the authors believe the drafts should stay separately becaus= e they address different problems   in very different use cases.

Comments and thoughts?
Yiu



--_000_C9536D956BAEyiuleecablecomcastcom_-- From jacniq@gmail.com Sun Jan 16 22:51:35 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA893A6D07 for ; Sun, 16 Jan 2011 22:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOtTI0R-ZqlL for ; Sun, 16 Jan 2011 22:51:34 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 1A3593A6C69 for ; Sun, 16 Jan 2011 22:51:32 -0800 (PST) Received: by fxm9 with SMTP id 9so6198978fxm.31 for ; Sun, 16 Jan 2011 22:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LOSWzMjiAxTW9W1o5T9Bz30+pihe/q8Rp+2LYzCbzSA=; b=ppcTU7bDrHhKPLJnVG4NvfHEXlKjMH+Uv87OMuuBFl6PHwCxsiwqSJ+f0GSJMWIJ/N DL4aON0OvasQBTOTYi2/6ZhGPEEAHqfH1ujBK0TUJ7rH275EV8tWV36WkjRwX+9zTPQC zMF6nofDzQkdFJ0KH6lwtLHkQsyFQ93VN3OME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PMcE5mKpw4L5gCSSIW7ETw8Z8fLu5JMYKsSjXuNp1pruba8d64zW8MaFn7F8r3sbg5 Xo5e/GlCoXBAoneZndmyaQF+bMvGGlTgesIMBjiYcU5+26A2HyEy7f9FdJCCTvdR/j3W b2jDRVUdQNkH8EBQD9jihCWiAxbHZ9P1hZvFg= MIME-Version: 1.0 Received: by 10.204.59.140 with SMTP id l12mr1854340bkh.2.1295247216115; Sun, 16 Jan 2011 22:53:36 -0800 (PST) Received: by 10.204.152.11 with HTTP; Sun, 16 Jan 2011 22:53:36 -0800 (PST) In-Reply-To: <017401cbadf9$eb9eb5a0$c2dc20e0$@com> References: <017401cbadf9$eb9eb5a0$c2dc20e0$@com> Date: Mon, 17 Jan 2011 14:53:36 +0800 Message-ID: From: Jacni Qin To: Tina Tsou Content-Type: multipart/alternative; boundary=001636ed6d01367fb5049a053e5a Cc: Softwires Subject: Re: [Softwires] 6rd multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 06:51:35 -0000 --001636ed6d01367fb5049a053e5a Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, A quick question, I read 2.1 and the section 6 of 2.2, It seems that, for the multicast data traffic, the IPv6 multicast packets are translated to native IPv4 packets on BR then translated back on 6rd CE? Or they are encapsulated over IPv4 and de-capsulated on 6rd CE? Cheers, Jacni On Fri, Jan 7, 2011 at 7:32 AM, Tina Tsou wrote: > Hi all, > > http://datatracker.ietf.org/doc/draft-tsou-softwire-6rd-multicast/ > > is available. > > This document describes how IPv6 multicast can be extended across an > IPv4 network to an IPv6 host, using the native multicast capabilities > of the IPv4 network. > > This is a first draft, and definitely needs more work. > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --001636ed6d01367fb5049a053e5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Authors,

A quick question, I read 2.1 and the section 6 of 2.2, It seems that, for the multicast dat= a traffic, the IPv6 multicast packets are translated to native IPv4 packets= on BR then translated back on 6rd CE?
Or they are encapsulated over IPv4 and de-capsulated on 6rd CE?
<= font face=3D"verdana,sans-serif">

Cheers,
Jacni

On Fri, Jan 7, 2011 at 7:32 AM, Tina Tsou <tena@huawei.com> wrote:
Hi all,

http://datatracker.ietf.org/doc/draft-tsou-softwire-6= rd-multicast/

is available.

This document describes how IPv6 multicast can be extended across an
=A0 IPv4 network to an IPv6 host, using the native multicast capabilities<= br> =A0 of the IPv4 network.

This is a first draft, and definitely needs more work.


Best Regards,
Tina TSOU
http:= //tinatsou.weebly.com/contact.html



_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--001636ed6d01367fb5049a053e5a-- From tom.taylor@huawei.com Mon Jan 17 05:52:04 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E7B28C0D9 for ; Mon, 17 Jan 2011 05:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[AWL=1.172, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj9QE489WnGP for ; Mon, 17 Jan 2011 05:52:03 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CBDDD28C0D7 for ; Mon, 17 Jan 2011 05:52:02 -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 <0LF6009996MJGP@szxga04-in.huawei.com> for softwires@ietf.org; Mon, 17 Jan 2011 21:54:19 +0800 (CST) Received: from 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 <0LF600KL16MJXM@szxga04-in.huawei.com> for softwires@ietf.org; Mon, 17 Jan 2011 21:54:19 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LF600IZV6MH7E@szxml01-in.huawei.com>; Mon, 17 Jan 2011 21:54:19 +0800 (CST) Date: Mon, 17 Jan 2011 08:54:24 -0500 From: Tom Taylor In-reply-to: To: Jacni Qin Message-id: <4D344A10.2030102@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 References: <017401cbadf9$eb9eb5a0$c2dc20e0$@com> Cc: Softwires Subject: Re: [Softwires] 6rd multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 13:52:04 -0000 It can go either way. Over the way we submitted a translation-based version to Behave: draft-tsou-behave-translated-multicast-00.txt. We will submit an encapsulation-based version to softwires shortly. On 17/01/2011 1:53 AM, Jacni Qin wrote: > Dear Authors, > > A quick question, > I read 2.1 and the section 6 of 2.2, It seems that, for the multicast data > traffic, the IPv6 multicast packets are translated to native IPv4 packets on > BR then translated back on 6rd CE? > Or they are encapsulated over IPv4 and de-capsulated on 6rd CE? > > > Cheers, > Jacni > > On Fri, Jan 7, 2011 at 7:32 AM, Tina Tsou wrote: > >> Hi all, >> >> http://datatracker.ietf.org/doc/draft-tsou-softwire-6rd-multicast/ >> >> is available. >> >> This document describes how IPv6 multicast can be extended across an >> IPv4 network to an IPv6 host, using the native multicast capabilities >> of the IPv4 network. >> >> This is a first draft, and definitely needs more work. >> >> >> Best Regards, >> Tina TSOU >> http://tinatsou.weebly.com/contact.html >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From dhankins@google.com Fri Jan 21 13:05:49 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD0228C10B for ; Fri, 21 Jan 2011 13:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZukFDbR6Qv7 for ; Fri, 21 Jan 2011 13:05:48 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 212F728C113 for ; Fri, 21 Jan 2011 13:05:47 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p0LL8XXH032091 for ; Fri, 21 Jan 2011 13:08:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295644114; bh=Z6VDEvgp8egxgT53VoZ8U5+fXzA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ftl5WIQdt5pDsP9qNEGJcrvoI0psZhsAcYdxAH1icNPTXGRFUdHWmTAiytvsGJ6Dp 2LNqflGU6OO1ppPQ00Png== Received: from yib17 (yib17.prod.google.com [10.243.65.81]) by kpbe17.cbf.corp.google.com with ESMTP id p0LL82ll006352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 21 Jan 2011 13:08:31 -0800 Received: by yib17 with SMTP id 17so712378yib.35 for ; Fri, 21 Jan 2011 13:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sy1/1mTImUFSp3rfImjSWONzjMlVGHQpW1S10u73L4w=; b=PPI6mA89GPYaQwNr1weWgLMfOCL2EhIpFict2GkPp++yZcYuFQ3ufmVtihnJEGov18 guWywO6Cw2iiTmbzFZkw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FfVWRYvQg0eii7fT9wjmaCX46n7le1DRr/1dIwtWA69duZUF5SvL9k06zrkMe9olCW Y00oygDXwB+BFKUD0+DQ== MIME-Version: 1.0 Received: by 10.100.195.5 with SMTP id s5mr815913anf.224.1295644110931; Fri, 21 Jan 2011 13:08:30 -0800 (PST) Received: by 10.100.27.31 with HTTP; Fri, 21 Jan 2011 13:08:30 -0800 (PST) In-Reply-To: References: <20101210200002.5362.92301.idtracker@localhost> <88FF3B58-F802-4566-A66B-151B598FF007@juniper.net> <4D03C75B.3020507@piuha.net> Date: Fri, 21 Jan 2011 13:08:30 -0800 Message-ID: From: David Hankins To: Ted Lemon Content-Type: multipart/alternative; boundary=0016e6435662fcca2a049a61a6b3 X-System-Of-Record: true Cc: "softwires@ietf.org list" , Softwire Chairs , Ralph@core3.amsl.com Subject: Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:05:50 -0000 --0016e6435662fcca2a049a61a6b3 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 11, 2010 at 11:04 AM, Ted Lemon wrote: > DHCPv6 server administrators should not configure DHCP servers to return > more > than one AFTR-Name option in any given context. If more than one > AFTR-Name > option is sent, it will be treated as an error by the client. > After deliberation, I'm willing to relax this to SHOULD (along with the other SHOULD for multilple names in one option) and provide the operator direction. I think for the long term, DHCP servers are going to need to be able to determine when only a single value like this is "supposed" to be sent in a given option, and to provide UI hints to the operator rather than just not working and making the operator go hunt down logs on clients. That is, server validation of operator configuration should happen in the server, and not in the client (unless we're going to invest in a command channel to send client parse errors back to server operator eyes). In fact, it wouldn't be a bad idea if we described the sets of validations and limitations we want to make on DHCPv6 options in the future, so that software designers today can make a language so that new options can be defined along with correct validation of configuration. It is an error for the DHCP server to return more than one AFTR-Name > option. > If a DHCP client receives more than one AFTR-Name option, it SHOULD > ignore all > AFTR-name options. > You're also changing the target behavior; I had it picking the first value. I'm thinking of two cases in client class; clients that pass a text string (e.g., writing a config file like ISC dhclient's /sbin/dhclient-script does) are likely to just pass whatever long list of domain names the server has supplied to the configuration knob it writes out; "aftr1.foo.com aftr2.foo.com etc". In this case, we expect the B4 to use the first name and ignore the others. The second possible client implementation passes a binary structure or calling parameter to another task in the same running system; this structure probably only has one field for the name, or maybe it is just a 16 octet IPv6 address and the "dhcpv6 client" end of the software does the resolution on B4's behalf. I'm suggesting this client also should trim the list down to just the first name. I think the current language, that it MUST select the first option and MUST select the first name appearing in the first option, fits current implementation (ISC dhclient) and both environments (you'd have to reduce the long list down to fit your single parameter call-out). What I was doing, is I was referring (for simplicity's sake) to "the client" to mean either software component; the DHCPv6 client or the B4 element it is configuring, one of these two need to perform this validation (and it doesn't really matter which one). I've updated the text to add a new terminology, "a B4 system", as distinct from the B4 element and the DHCPv6 client but whose specifications may be implemented by either party (or even a third party in the middle, some common system configuration software). Hopefully this alleviates your concern that it changes DHCPv6 client behavior. -- David W. Hankins SRE Google, Inc. --0016e6435662fcca2a049a61a6b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 11, 2010 at 11:04 AM, Ted Lemon <Ted.Lemon@nominu= m.com> wrote:
=A0=A0DHCPv6 server administrators should not configure DHCP servers to ret= urn more
=A0 than one AFTR-Name option in any given context. =A0 If more than one A= FTR-Name
=A0 option is sent, it will be treated as an error by the client.

After deliberation, I'm willing to relax th= is to SHOULD (along with the other SHOULD for multilple names in one option= ) and provide the operator direction. =A0I think for the long term, DHCP se= rvers are going to need to be able to determine when only a single value li= ke this is "supposed" to be sent in a given option, and to provid= e UI hints to the operator rather than just not working and making the oper= ator go hunt down logs on clients.

That is, server validation of operator configuration sh= ould happen in the server, and not in the client (unless we're going to= invest in a command channel to send client parse errors back to server ope= rator eyes).

In fact, it wouldn't be a bad idea if we described = the sets of validations and limitations we want to make on DHCPv6 options i= n the future, so that software designers today can make a language so that = new options can be defined along with correct validation of configuration.<= /div>

=A0=A0It is an error for the= DHCP server to return more than one AFTR-Name option.
=A0 If a DHCP client receives more than one AFTR-Name option, it SHOULD ig= nore all
=A0 AFTR-name options.

You're also= changing the target behavior; I had it picking the first value.
=
I'm thinking of two cases in client class; clients that = pass a text string (e.g., writing a config file like ISC dhclient's /sb= in/dhclient-script does) are likely to just pass whatever long list of doma= in names the server has supplied to the configuration knob it writes out; &= quot;aftr1.foo.com aftr2.foo.com etc". =A0In this case, we expect the B= 4 to use the first name and ignore the others. =A0The second possible clien= t implementation passes a binary structure or calling parameter to another = task in the same running system; this structure probably only has one field= for the name, or maybe it is just a 16 octet IPv6 address and the "dh= cpv6 client" end of the software does the resolution on B4's behal= f. =A0I'm suggesting this client also should trim the list down to just= the first name.

I think the current language, that it MUST select the f= irst option and MUST select the first name appearing in the first option, f= its current implementation (ISC dhclient) and both environments (you'd = have to reduce the long list down to fit your single parameter call-out).

What I was doing, is I was referring (for simplicity= 9;s sake) to "the client" to mean either software component; the = DHCPv6 client or the B4 element it is configuring, one of these two need to= perform this validation (and it doesn't really matter which one).

I've updated the text to add a new terminology, &qu= ot;a B4 system", as distinct from the B4 element and the DHCPv6 client= but whose specifications may be implemented by either party (or even a thi= rd party in the middle, some common system configuration software).

Hopefully this alleviates your concern that it changes = DHCPv6 client behavior.

--
David W. Hank= ins
SRE
Google, Inc.
--0016e6435662fcca2a049a61a6b3-- From dhankins@google.com Fri Jan 21 13:24:48 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7801D3A6823 for ; Fri, 21 Jan 2011 13:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.161 X-Spam-Level: X-Spam-Status: No, score=-105.161 tagged_above=-999 required=5 tests=[AWL=0.815, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-eo1M53HmAE for ; Fri, 21 Jan 2011 13:24:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BF1C13A68F7 for ; Fri, 21 Jan 2011 13:24:46 -0800 (PST) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p0LLRWdK030612 for ; Fri, 21 Jan 2011 13:27:32 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295645253; bh=fKoEJlX/Y5CyjdWblOMO1DHO7ac=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=nbceoghcHi1JXx/psFci1S+cejWxiLapGn7mhnGYFM7ZUqCOt9vD9ZLYhWl4PzYPl aUAIWAfVuQ+13Ps9Jmh4g== Received: from gxk21 (gxk21.prod.google.com [10.202.11.21]) by hpaq3.eem.corp.google.com with ESMTP id p0LLRUZT016201 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 21 Jan 2011 13:27:31 -0800 Received: by gxk21 with SMTP id 21so651336gxk.10 for ; Fri, 21 Jan 2011 13:27:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UXSNscCTZQIm1DKiq3xfGNgjDxnE8xCbRhHZ/tdRzsY=; b=wXtdHhXIcV4tAnrVV37jtmCalVbQeH7A7A3AdkANa3CESPAgQJ7B1ytC6pBtHRy3qb 0JKPWf1KsaI8MPPnHVkg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W8rfZv02FXdOPPcEk7Yqs9RNS0W57F81N0sncDcDyB8ty4/d98cK4ln0qkig2NPAY4 LpXWutp90WPkjL39iVhw== MIME-Version: 1.0 Received: by 10.100.17.13 with SMTP id 13mr827636anq.190.1295645249781; Fri, 21 Jan 2011 13:27:29 -0800 (PST) Received: by 10.100.27.31 with HTTP; Fri, 21 Jan 2011 13:27:29 -0800 (PST) In-Reply-To: <29123_1292226172_4D05CE7C_29123_53394_1_94C682931C08B048B7A8645303FDC9F3365A8233B4@PUEXCB1B.nanterre.francetelecom.fr> References: <20101210200002.5362.92301.idtracker@localhost> <88FF3B58-F802-4566-A66B-151B598FF007@juniper.net> <29123_1292226172_4D05CE7C_29123_53394_1_94C682931C08B048B7A8645303FDC9F3365A8233B4@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 21 Jan 2011 13:27:29 -0800 Message-ID: From: David Hankins To: mohamed.boucadair@orange-ftgroup.com Content-Type: multipart/alternative; boundary=0016e64692a2de3ffa049a61ea75 X-System-Of-Record: true Cc: "softwires@ietf.org list" , Softwire Chairs Subject: Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:24:48 -0000 --0016e64692a2de3ffa049a61ea75 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 12, 2010 at 11:42 PM, wrote: > This version is almost Ok. I still have two comments: > Thank you for your constancy in review and participation. I suggest to change > "It SHOULD NOT permit the configuration of multiple names within one > AFTR-Name option." > > To > > "It MUST NOT permit the configuration of multiple names within one > AFTR-Name option." > So far as I'm aware, DHCPv6 servers today do not implement any restriction on how many names can be configured if the server is informed that the format of the new option is the RFC 3315 format domain name (in fact, in ISC DHCP's v6 implementation, I called the atom to do RFC 3315 domain names a "domain list" atom). >From my point of view it can be validated that only one option can be configured, but Ted has reminded me that this is not the case in all currently conforming DHCPv6 server implementations. So this would mean that current DHCPv6 implementations could not conform to specification without software changes, something I was trying to avoid (incompletely) with the "MUST / SHOULD" language this version of the draft had. " > If the client receives more than one AFTR-Name option, it MUST use > only the first instance of that option. > > If the AFTR-Name option contains more than one FQDN, as distinguished > by the presence of multiple root labels, the client MUST use only the > first FQDN listed in configuration. > " > > To "If the DHCP Client receives more than one AFTR-Name option or if the > AFTR-Name option contains more than one FQDN, the DHCP Client MUST ignore > the received AFTR-Name option(s))". > I think this would require a software change in current DHCPv6 client implementations. I can't speak for B4 implementations, but if I were a B4 implementor, I would also be concerned that if I conformed to this direction and some other (it only takes one) B4 implementation didn't, then my software would not work where other software does, and this reasoning would not be very obvious to customers. If we're shaping conformance language away from concrete validation and towards current implementation practice, then I think we should do it both on the server and client side. (2) Multi-interface use case: this text has been introduced in 07: > > " Note that a client may have multiple network interfaces, and these > interfaces may be configured differently; some may be connected to > networks that call for DS-Lite, and some may be connected to networks > that are using normal dual stack or other means. The client should > consider the above on an interface-by-interface basis. For example, > if the client is attached to multiple networks that provide the AFTR > Name option, then the client MUST configure a tunnel for each > interface separately as each DS-Lite tunnel provides IPv4 > connectivity for each distinct interface." > > > The text does not elaborate on how an interface is identified and how the > server/client will proceed to enforce the received configuration for the > appropriate interface. BTW, this issue is not specific to DS-Lite and it is > generic to any MIFed device. > For this reason, I didn't want to elaborate. The goal is to include text that reminds the implementor that perhaps they should not follow a mindset that they will have only one B4 element on their system, in the case where they plan to have multiple external network interfaces, since we just finished explaining carefully that there should be only one domain name sent to configuration. The danger is that they may configure only one tunnel endpoint, either having only one B4 element running, or multiple endpoints for each interface all using some single endpoint. These would all be bad decisions, which may seem reinforced by the specification's demand for a single name. Can you suggest simpler language? -- David W. Hankins SRE Google, Inc. --0016e64692a2de3ffa049a61ea75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Dec 12, 2010 at 11:42 PM, <mohamed.bo= ucadair@orange-ftgroup.com> wrote:
This version is almost Ok. I still have two comments:
=
Thank you for your constancy in review and participation.

I suggest to change

"It SHOULD NOT permit the configuration of multiple names within one =A0 AFTR-Name option."

To

"It MUST NOT permit the configuration of multiple names within one
=A0 AFTR-Name option."

So far as = I'm aware, DHCPv6 servers today do not implement any restriction on how= many names can be configured if the server is informed that the format of = the new option is the RFC 3315 format domain name (in fact, in ISC DHCP'= ;s v6 implementation, I called the atom to do RFC 3315 domain names a "= ;domain list" atom).

From my point of view it can be validated that only one= option can be configured, but Ted has reminded me that this is not the cas= e in all currently conforming DHCPv6 server implementations.

So this would mean that current DHCPv6 implementations could= not conform to specification without software changes, something I was try= ing to avoid (incompletely) with the "MUST / SHOULD" language thi= s version of the draft had.

"
=A0 If the client receives more than one AFTR-Name option, it MUST use
=A0 only the first instance of that option.

=A0 If the AFTR-Name option contains more than one FQDN, as distinguished<= br> =A0 by the presence of multiple root labels, the client MUST use only the<= br> =A0 first FQDN listed in configuration.
"

To "If the DHCP Client receives more than one AFTR-Name option o= r if the AFTR-Name option contains more than one FQDN, the DHCP Client MUST= ignore the received AFTR-Name option(s))".

I think this would require a software change in current DHCP= v6 client implementations. =A0I can't speak for B4 implementations, but= if I were a B4 implementor, I would also be concerned that if I conformed = to this direction and some other (it only takes one) B4 implementation didn= 't, then my software would not work where other software does, and this= reasoning would not be very obvious to customers.

If we're shaping conformance language away from con= crete validation and towards current implementation practice, then I think = we should do it both on the server and client side.

(2) Multi-interface use case: this text has= been introduced in 07:

" =A0 Note that a client may have multiple network interfaces, and the= se
=A0 interfaces may be configured differently; some may be connected to
=A0 networks that call for DS-Lite, and some may be connected to networks<= br> =A0 that are using normal dual stack or other means. =A0The client should<= br> =A0 consider the above on an interface-by-interface basis. =A0For example,=
=A0 if the client is attached to multiple networks that provide the AFTR =A0 Name option, then the client MUST configure a tunnel for each
=A0 interface separately as each DS-Lite tunnel provides IPv4
=A0 connectivity for each distinct interface."


The text does not elaborate on how an interface is identified and how the s= erver/client will proceed to enforce the received configuration for the app= ropriate interface. BTW, this issue is not specific to DS-Lite and it is ge= neric to any MIFed device.

For this reason, I didn't want to elab= orate. =A0The goal is to include text that reminds the implementor that per= haps they should not follow a mindset that they will have only one B4 eleme= nt on their system, in the case where they plan to have multiple external n= etwork interfaces, since we just finished explaining carefully that there s= hould be only one domain name sent to configuration. =A0The danger is that = they may configure only one tunnel endpoint, either having only one B4 elem= ent running, or multiple endpoints for each interface all using some single= endpoint. =A0These would all be bad decisions, which may seem reinforced b= y the specification's demand for a single name.

Can you suggest simpler language?

<= div>--=A0
David W. Hankins
SRE
Google, = Inc.

--0016e64692a2de3ffa049a61ea75-- From dhankins@google.com Fri Jan 21 13:59:16 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F2D3A68F7 for ; Fri, 21 Jan 2011 13:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.309 X-Spam-Level: X-Spam-Status: No, score=-105.309 tagged_above=-999 required=5 tests=[AWL=-2.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0phj4cIZ9Q4 for ; Fri, 21 Jan 2011 13:59:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 95CC93A6803 for ; Fri, 21 Jan 2011 13:59:14 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p0LM20ZZ023330 for ; Fri, 21 Jan 2011 14:02:00 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295647320; bh=2TEKyknzGt7Dlt0q9p/rGinzCIE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=oWiCgbM9i3/f4sD6oavSd7EO5qtnzrwqs/xqqctLgcBAPgH4l4AIugxslhvo08+k0 PV1Cg71ciixpJS9xwVPmg== Received: from gyg13 (gyg13.prod.google.com [10.243.50.141]) by hpaq11.eem.corp.google.com with ESMTP id p0LM1wQB029145 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 21 Jan 2011 14:01:59 -0800 Received: by gyg13 with SMTP id 13so863018gyg.2 for ; Fri, 21 Jan 2011 14:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2LL+Siau3/6Pboq2DEljcl4ouOXZ/LNuMtazTsMUDDQ=; b=GcOcmiSZNS60NrXm+zM2Fi1rcfhEB5P5kmWQR0xu6lOomzPSVzaHrHScimdRdUarcS h0Udd1Vm7BRS12Gu9ShA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xx0r5n67Li9zf7LdIahZoKQBkk7ebFAkTyA1YRL2iBKw8zvldxVYASDfZHvycz1Mnn VUUlkaHQAB5NVHqdQxvA== MIME-Version: 1.0 Received: by 10.100.195.5 with SMTP id s5mr854841anf.224.1295647317752; Fri, 21 Jan 2011 14:01:57 -0800 (PST) Received: by 10.100.27.31 with HTTP; Fri, 21 Jan 2011 14:01:57 -0800 (PST) In-Reply-To: <20110121214655.730D43A6AA9@core3.amsl.com> References: <20110121214655.730D43A6AA9@core3.amsl.com> Date: Fri, 21 Jan 2011 14:01:57 -0800 Message-ID: From: David Hankins To: "softwires@ietf.org list" Content-Type: multipart/alternative; boundary=0016e643566220fd7e049a6266c7 X-System-Of-Record: true Cc: DHC WG Subject: [Softwires] Fwd: New Version Notification for draft-ietf-softwire-ds-lite-tunnel-option-08 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 21:59:16 -0000 --0016e643566220fd7e049a6266c7 Content-Type: text/plain; charset=ISO-8859-1 Incorporating (opposing) comments from the softwire and DHC wg's; 1) Servers MUST send one option relaxed to SHOULD, on the basis that current DHCPv6 server implementations don't have a control for how many instances of "new options" (defined after the software is released) may be configured or sent. 2) Introduction of a new term, a "B4 system", which is the amalgamation of the B4 element we are configuring and any other software co-resident (specifically the DHCPv6 client or other configuration management layers). Several normative specifications are changed to refer to the B4 system instead of "the client" which could otherwise be seen to require a change in software implementation of DHCPv6 clients specifically - we don't want that. Either the DHCPv6 client, the B4 element, or some software joining the two in the middle need to validate that only one domain name is being used, and we don't care which one. ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Fri, Jan 21, 2011 at 1:46 PM Subject: New Version Notification for draft-ietf-softwire-ds-lite-tunnel-option-08 To: dhankins@google.com Cc: tomasz.mrugalski@eti.pg.gda.pl A new version of I-D, draft-ietf-softwire-ds-lite-tunnel-option-08.txt has been successfully submitted by David Hankins and posted to the IETF repository. Filename: draft-ietf-softwire-ds-lite-tunnel-option Revision: 08 Title: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Creation_date: 2011-01-21 WG ID: softwire Number_of_pages: 8 Abstract: This document specifies a DHCPv6 option which is meant to be used by a Dual-Stack Lite Basic Bridging Broadband (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). The IETF Secretariat. -- David W. Hankins SRE Google, Inc. --0016e643566220fd7e049a6266c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Incorporating (opposing) comments from the softwire and DHC wg's;
<= br>
1) Servers MUST send one option relaxed to SHOULD, on the bas= is that current DHCPv6 server implementations don't have a control for = how many instances of "new options" (defined after the software i= s released) may be configured or sent.

2) Introduction of a new term, a "B4 system",= which is the amalgamation of the B4 element we are configuring and any oth= er software co-resident (specifically the DHCPv6 client or other configurat= ion management layers). =A0Several normative specifications are changed to = refer to the B4 system instead of "the client" which could otherw= ise be seen to require a change in software implementation of DHCPv6 client= s specifically - we don't want that. =A0Either the DHCPv6 client, the B= 4 element, or some software joining the two in the middle need to validate = that only one domain name is being used, and we don't care which one.
---------- Forwarded message ----------
F= rom: IETF I-D Submission Tool <ids= ubmission@ietf.org>
Date: Fri, Jan 21, 2011 at 1:46 PM
Subject: New Version Notification for= draft-ietf-softwire-ds-lite-tunnel-option-08
To: dhankins@google.com
Cc: = tomasz.= mrugalski@eti.pg.gda.pl



A new version of I-D, draft-ietf-softwire-ds-lite-tunnel-option-08.txt has = been successfully submitted by David Hankins and posted to the IETF reposit= ory.

Filename: =A0 =A0 =A0 =A0draft-ietf-softwire-ds-lite-tunnel-option
Revision: =A0 =A0 =A0 =A008
Title: =A0 =A0 =A0 =A0 =A0 Dynamic Host Configuration Protocol for IPv6 (DH= CPv6) Option for Dual- Stack Lite
Creation_date: =A0 2011-01-21
WG ID: =A0 =A0 =A0 =A0 =A0 softwire
Number_of_pages: 8

Abstract:
This document specifies a DHCPv6 option which is meant to be used by
a Dual-Stack Lite Basic Bridging Broadband (B4) element to discover
the IPv6 address of its corresponding Address Family Transition
Router (AFTR).



The IETF Secretariat.





--
David W. Hankins
SRE<= /div>
Google, Inc.

--0016e643566220fd7e049a6266c7-- From Internet-Drafts@ietf.org Fri Jan 21 14:00:02 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988363A68F7; Fri, 21 Jan 2011 14:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.84 X-Spam-Level: X-Spam-Status: No, score=-101.84 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+PYWaU70QxF; Fri, 21 Jan 2011 14:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F1C3A67FD; Fri, 21 Jan 2011 14:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110121220001.17291.81057.idtracker@localhost> Date: Fri, 21 Jan 2011 14:00:01 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-08.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 22:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename : draft-ietf-softwire-ds-lite-tunnel-option-08.txt Pages : 8 Date : 2011-01-21 This document specifies a DHCPv6 option which is meant to be used by a Dual-Stack Lite Basic Bridging Broadband (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-softwire-ds-lite-tunnel-option-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-21134654.I-D@ietf.org> --NextPart-- From tena@huawei.com Mon Jan 24 16:49:44 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACDF3A6B41 for ; Mon, 24 Jan 2011 16:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5rE0arnI-KH for ; Mon, 24 Jan 2011 16:49:43 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 5C5583A69E2 for ; Mon, 24 Jan 2011 16:49:43 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFJ004ZLZRQEV@usaga02-in.huawei.com> for softwires@ietf.org; Mon, 24 Jan 2011 16:52:38 -0800 (PST) Received: from TingZousc1 ([10.212.245.37]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFJ009IGZRLT9@usaga02-in.huawei.com> for softwires@ietf.org; Mon, 24 Jan 2011 16:52:38 -0800 (PST) Date: Mon, 24 Jan 2011 16:52:34 -0800 From: Tina Tsou To: 'Softwires' Message-id: <019f01cbbc2a$2c05ff70$8411fe50$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acu8KiXsd25e/0YKREqHQfN/Eib5/w== x-cr-puzzleid: {4E66416F-3B6E-4EA7-996F-5EA1BF2137B0} x-cr-hashedpuzzle: ACEH Av0Y BMXP Bhce C4Gv DF9C EuM6 Ezqw E0ho E90L GMo4 GQyq IuBt IvwG J2K1 KIoQ; 1; cwBvAGYAdAB3AGkAcgBlAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4E66416F-3B6E-4EA7-996F-5EA1BF2137B0}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 25 Jan 2011 00:52:32 GMT; UgBlAHYAaQBlAHcAIABvAGYAIABkAHIAYQBmAHQALQBpAGUAdABmAC0AcwBvAGYAdAB3AGkAcgBlAC0AZwBhAHQAZQB3AGEAeQAtAGkAbgBpAHQALQBkAHMALQBsAGkAdABlAC0AMAAyAA== Subject: [Softwires] Review of draft-ietf-softwire-gateway-init-ds-lite-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 00:49:44 -0000 Hi, As promised in IETF-79, I'm supposed to review draft-ietf-softwire-gateway-init-ds-lite-02. It is well written, for the wire line case, it matches the industry trend, for the wireless case, it has been discussed in 3GPP maturely. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From mohamed.boucadair@orange-ftgroup.com Mon Jan 31 23:25:36 2011 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D223A68BD for ; Mon, 31 Jan 2011 23:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQpUatXMFQHv for ; Mon, 31 Jan 2011 23:25:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id E2D933A6836 for ; Mon, 31 Jan 2011 23:25:34 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 2752BC01BC; Tue, 1 Feb 2011 08:28:50 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id F3BDE15805A; Tue, 1 Feb 2011 08:28:49 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 1 Feb 2011 08:28:49 +0100 From: To: David Hankins Date: Tue, 1 Feb 2011 08:28:47 +0100 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 Thread-Index: Acu5sgbF9djioK4rS46LjkS61INBcgILblxg Message-ID: <26000_1296545330_4D47B632_26000_387791_1_94C682931C08B048B7A8645303FDC9F33C433B8971@PUEXCB1B.nanterre.francetelecom.fr> References: <20101210200002.5362.92301.idtracker@localhost> <88FF3B58-F802-4566-A66B-151B598FF007@juniper.net> <29123_1292226172_4D05CE7C_29123_53394_1_94C682931C08B048B7A8645303FDC9F3365A8233B4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F33C433B8971PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.2.1.61516 Cc: "softwires@ietf.org list" , Softwire Chairs Subject: Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 07:25:36 -0000 --_000_94C682931C08B048B7A8645303FDC9F33C433B8971PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear David, Thank you for your answer. I read the new version and the answers below: * I still vote for clear language without taking care of the current implem= entations: since the aim is to convey one single option enclosing only one = name; then the client and the sever behaviours should be provided according= ly (i.e., use of "must" instead of the "should"). * I see your point about the multi-interface text. This is fair. I would ju= st add a sentence like: "Means to bind a FQDN_NAME configuration to a given interface in a MIFed de= vice are out of scope of this document." Anyway, please do whatever you think it is appropriate to make this documen= t progress. Cheers, Med ________________________________ De : David Hankins [mailto:dhankins@google.com] Envoy=E9 : vendredi 21 janvier 2011 22:27 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Alain Durand; softwires@ietf.org list; Softwire Chairs Objet : Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-= option-07 On Sun, Dec 12, 2010 at 11:42 PM, > wrote: This version is almost Ok. I still have two comments: Thank you for your constancy in review and participation. I suggest to change "It SHOULD NOT permit the configuration of multiple names within one AFTR-Name option." To "It MUST NOT permit the configuration of multiple names within one AFTR-Name option." So far as I'm aware, DHCPv6 servers today do not implement any restriction = on how many names can be configured if the server is informed that the form= at of the new option is the RFC 3315 format domain name (in fact, in ISC DH= CP's v6 implementation, I called the atom to do RFC 3315 domain names a "do= main list" atom). >From my point of view it can be validated that only one option can be confi= gured, but Ted has reminded me that this is not the case in all currently c= onforming DHCPv6 server implementations. So this would mean that current DHCPv6 implementations could not conform to= specification without software changes, something I was trying to avoid (i= ncompletely) with the "MUST / SHOULD" language this version of the draft ha= d. " If the client receives more than one AFTR-Name option, it MUST use only the first instance of that option. If the AFTR-Name option contains more than one FQDN, as distinguished by the presence of multiple root labels, the client MUST use only the first FQDN listed in configuration. " To "If the DHCP Client receives more than one AFTR-Name option or if the AF= TR-Name option contains more than one FQDN, the DHCP Client MUST ignore the= received AFTR-Name option(s))". I think this would require a software change in current DHCPv6 client imple= mentations. I can't speak for B4 implementations, but if I were a B4 imple= mentor, I would also be concerned that if I conformed to this direction and= some other (it only takes one) B4 implementation didn't, then my software = would not work where other software does, and this reasoning would not be v= ery obvious to customers. If we're shaping conformance language away from concrete validation and tow= ards current implementation practice, then I think we should do it both on = the server and client side. (2) Multi-interface use case: this text has been introduced in 07: " Note that a client may have multiple network interfaces, and these interfaces may be configured differently; some may be connected to networks that call for DS-Lite, and some may be connected to networks that are using normal dual stack or other means. The client should consider the above on an interface-by-interface basis. For example, if the client is attached to multiple networks that provide the AFTR Name option, then the client MUST configure a tunnel for each interface separately as each DS-Lite tunnel provides IPv4 connectivity for each distinct interface." The text does not elaborate on how an interface is identified and how the s= erver/client will proceed to enforce the received configuration for the app= ropriate interface. BTW, this issue is not specific to DS-Lite and it is ge= neric to any MIFed device. For this reason, I didn't want to elaborate. The goal is to include text t= hat reminds the implementor that perhaps they should not follow a mindset t= hat they will have only one B4 element on their system, in the case where t= hey plan to have multiple external network interfaces, since we just finish= ed explaining carefully that there should be only one domain name sent to c= onfiguration. The danger is that they may configure only one tunnel endpoi= nt, either having only one B4 element running, or multiple endpoints for ea= ch interface all using some single endpoint. These would all be bad decisi= ons, which may seem reinforced by the specification's demand for a single n= ame. Can you suggest simpler language? -- David W. Hankins SRE Google, Inc. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** --_000_94C682931C08B048B7A8645303FDC9F33C433B8971PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear David,
 
Thank you for your answer.
 
I read the new version and the answers=20 below:
 
* I still vote for clear language without tak= ing care=20 of the current implementations: since the aim is to convey one single= =20 option enclosing only one name; then the client and the sever behaviours sh= ould=20 be provided accordingly (i.e., use of "must" instead=20 of the "should").
 
* I see your point about the multi-interface text.= This is=20 fair. I would just add a sentence like:
 
"Means to bind a FQDN_NAME configuration to a give= n=20 interface in a MIFed device are out of scope of this document."=20
 
Anyway, please do whatever you think it is=20 appropriate to make this document progress.
 
Cheers,
Med=   
De : David Hankins=20 [mailto:dhankins@google.com]
Envoy=E9 : vendredi 21 janvier= 2011=20 22:27
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc :=20 Alain Durand; softwires@ietf.org list; Softwire Chairs
Objet :=20 Re: [Softwires] WG last call on=20 draft-ietf-softwire-ds-lite-tunnel-option-07

On Sun, Dec 12, 2010 at 11:42 PM, = <mohamed.boucadair@oran= ge-ftgroup.com>=20 wrote:
This=20 version is almost Ok. I still have two comments:

Thank you for your constancy in review and participation.

I=20 suggest to change

"It SHOULD NOT permit the configuration of multiple n= ames=20 within one
  AFTR-Name option."

To

"It MUST N= OT=20 permit the configuration of multiple names within one
  AFTR-Name= =20 option."

So far as I'm aware, DHCPv6 servers today do not implement any restric= tion=20 on how many names can be configured if the server is informed that the form= at of=20 the new option is the RFC 3315 format domain name (in fact, in ISC DHCP's v= 6=20 implementation, I called the atom to do RFC 3315 domain names a "domain lis= t"=20 atom).

From my point of view it can be validated that only one option can be= =20 configured, but Ted has reminded me that this is not the case in all curren= tly=20 conforming DHCPv6 server implementations.

So this would mean that current DHCPv6 implementations could not confo= rm to=20 specification without software changes, something I was trying to avoid=20 (incompletely) with the "MUST / SHOULD" language this version of the draft= =20 had.

"
  If the client receives more than one AFTR-Nam= e=20 option, it MUST use
  only the first instance of that=20 option.

  If the AFTR-Name option contains more than one FQDN= , as=20 distinguished
  by the presence of multiple root labels, the clie= nt=20 MUST use only the
  first FQDN listed in=20 configuration.
"

To "If the DHCP Client receives more tha= n one=20 AFTR-Name option or if the AFTR-Name option contains more than one FQDN, = the=20 DHCP Client MUST ignore the received AFTR-Name option(s))".

I think this would require a software change in current DHCPv6 client= =20 implementations.  I can't speak for B4 implementations, but if I were = a B4=20 implementor, I would also be concerned that if I conformed to this directio= n and=20 some other (it only takes one) B4 implementation didn't, then my software w= ould=20 not work where other software does, and this reasoning would not be very ob= vious=20 to customers.

If we're shaping conformance language away from concrete validation an= d=20 towards current implementation practice, then I think we should do it both = on=20 the server and client side.

(2)=20 Multi-interface use case: this text has been introduced in 07:

" &= nbsp;=20 Note that a client may have multiple network interfaces, and these
&nb= sp;=20 interfaces may be configured differently; some may be connected to
&nb= sp;=20 networks that call for DS-Lite, and some may be connected to=20 networks
  that are using normal dual stack or other means.  = ;The=20 client should
  consider the above on an interface-by-interface b= asis.=20  For example,
  if the client is attached to multiple networ= ks=20 that provide the AFTR
  Name option, then the client MUST configu= re a=20 tunnel for each
  interface separately as each DS-Lite tunnel pro= vides=20 IPv4
  connectivity for each distinct interface."


The = text=20 does not elaborate on how an interface is identified and how the server/c= lient=20 will proceed to enforce the received configuration for the appropriate=20 interface. BTW, this issue is not specific to DS-Lite and it is generic t= o any=20 MIFed device.

For this reason, I didn't want to elaborate.  The goal is to incl= ude=20 text that reminds the implementor that perhaps they should not follow a min= dset=20 that they will have only one B4 element on their system, in the case where = they=20 plan to have multiple external network interfaces, since we just finished= =20 explaining carefully that there should be only one domain name sent to=20 configuration.  The danger is that they may configure only one tunnel= =20 endpoint, either having only one B4 element running, or multiple endpoints = for=20 each interface all using some single endpoint.  These would all be bad= =20 decisions, which may seem reinforced by the specification's demand for a si= ngle=20 name.

Can you suggest simpler language?

-- 
David W. Hankins
SRE
Google, Inc.

*********************************
This message and any attachments (the "message") are confidential and inten=
ded solely for the addressees.=20
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.=20
France Telecom Group shall not be liable for the message if altered, change=
d or falsified.
If you are not the intended addressee of this message, please cancel it imm=
ediately and inform the sender.
********************************
--_000_94C682931C08B048B7A8645303FDC9F33C433B8971PUEXCB1Bnante_--