From suresh.krishnan@ericsson.com Thu Nov 1 11:46:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B3D21F935E for ; Thu, 1 Nov 2012 11:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dTaSUvQf7xK for ; Thu, 1 Nov 2012 11:46:01 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 396B221F9364 for ; Thu, 1 Nov 2012 11:46:01 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qA1Ijwbn016213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Nov 2012 13:46:00 -0500 Received: from [142.133.112.74] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 1 Nov 2012 14:45:59 -0400 Message-ID: <5092C366.7070507@ericsson.com> Date: Thu, 1 Nov 2012 14:45:58 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Softwires WG References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] Fwd: CORRECTION: Help the NomCom X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:46:05 -0000 Please consider providing feedback to the Nomcom. They need our feedback to pick good candidates for the open positions. Thanks Suresh -------- Original Message -------- Subject: CORRECTION: Help the NomCom Date: Thu, 1 Nov 2012 05:17:22 -0700 From: NomCom Chair To: Working Group Chairs I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org From kristian.poscic@alcatel-lucent.com Thu Nov 1 21:19:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64D421F972D for ; Thu, 1 Nov 2012 21:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tSExd23pI2s for ; Thu, 1 Nov 2012 21:19:08 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3836421F9729 for ; Thu, 1 Nov 2012 21:19:07 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA24J6HZ029649 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 2 Nov 2012 05:19:07 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 2 Nov 2012 05:19:06 +0100 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.149]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Fri, 2 Nov 2012 00:19:04 -0400 From: "Poscic, Kristian (Kristian)" To: "softwires@ietf.org" Thread-Topic: map-e/t CE Thread-Index: Ac24sQEk5PRUANnUSb+NfqMO1qQulA== Date: Fri, 2 Nov 2012 04:19:04 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F0045536@US70TWXCHMBA11.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F0045536US70TWXCHMBA11zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [Softwires] map-e/t CE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 04:19:09 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F0045536US70TWXCHMBA11zam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are any CE vendors already on board with map-e/t implementation? In other words is there anything available today for early testing? Thanks, Kris --_000_7921F977B17D5B49B8DCC955A339D2F0045536US70TWXCHMBA11zam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are any CE vendors already on board with map-e/t imp= lementation?

In other words is there anything available today for= early testing?

Thanks,

Kris

--_000_7921F977B17D5B49B8DCC955A339D2F0045536US70TWXCHMBA11zam_-- From shtsuchi@cisco.com Thu Nov 1 23:37:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D9B21F999B for ; Thu, 1 Nov 2012 23:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKmsyW4cVgiv for ; Thu, 1 Nov 2012 23:37:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D15C921F9994 for ; Thu, 1 Nov 2012 23:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=759; q=dns/txt; s=iport; t=1351838277; x=1353047877; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lft3BaWI9iMAm7W29nhxisp2khSYUG0kPXcmRfU4U3w=; b=VFEcurP2UnIDLrWzWAxRt1dabM/cDH7jXyNK8+1V2V4P0rScuncJhi0Q NVagQ/Z07WO5SQqQNNyqXrMdU+f2l4iFSE7kSHBAI9j+OtrmEdW64Kj49 GVIqy8SaasQtp9/1LTMqDXuOqzDumiBv5T5TmM82xnhXu3wQacOWjuqtU w=; X-IronPort-AV: E=Sophos;i="4.80,697,1344211200"; d="scan'208";a="138033228" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 02 Nov 2012 06:37:56 +0000 Received: from [10.141.56.120] (dhcp-10-141-56-120.cisco.com [10.141.56.120]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA26bts6015014; Fri, 2 Nov 2012 06:37:55 GMT Message-ID: <50936A42.1010106@cisco.com> Date: Fri, 02 Nov 2012 15:37:54 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: kristian.poscic@alcatel-lucent.com References: <7921F977B17D5B49B8DCC955A339D2F0045536@US70TWXCHMBA11.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F0045536@US70TWXCHMBA11.zam.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] map-e/t CE X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 06:37:57 -0000 Kris We did MAP-E interop event in JAPAN. 6vendors and 8 OS attended to the event as BR or CE and BR/CE. I will report detail information of the event at IETF85. About testing,some open source already implemented MAP-E/MAP-T. You can use OpenWRT and ASAMAP. http://mapt.ivi2.org:8039/mapt.html http://enog.jp/~masakazu/vyatta/map/ Regards, -Shishio (2012/11/02 13:19), Poscic, Kristian (Kristian) wrote: > Are any CE vendors already on board with map-e/t implementation? > > In other words is there anything available today for early testing? > > Thanks, > > Kris > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From yong@csnet1.cs.tsinghua.edu.cn Sun Nov 4 05:36:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7166A21F86C6 for ; Sun, 4 Nov 2012 05:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPI11apaMplY for ; Sun, 4 Nov 2012 05:36:32 -0800 (PST) Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id B395C21F86B9 for ; Sun, 4 Nov 2012 05:36:31 -0800 (PST) Received: from [130.129.23.117] (dhcp-1775.meeting.ietf.org [130.129.23.117]) by mail.csnet1.cs.tsinghua.edu.cn (Tsinghua University (Postfix)) with ESMTPA id C78F11888014; Sun, 4 Nov 2012 21:28:21 +0800 (CST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 04 Nov 2012 21:35:21 +0800 From: Yong Cui To: Yong Cui , Softwires WG Message-ID: Thread-Topic: Call for presentation in IETF 85 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Softwires] Call for presentation in IETF 85 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:36:34 -0000 Dear all, Our agenda has been published at the following link: https://datatracker.ietf.org/meeting/85/agenda/softwire/ Please send your slides to me and Suresh by Monday 5pm at Atlanta time. Thanks, Yong & Suresh -----Original Message----- From: Yong Cui Date: Thu, 11 Oct 2012 15:47:33 +0800 To: Softwires WG Cc: Suresh Krishnan , Yong Cui Subject: Call for presentation in IETF 85 >Hi folks, > >We will have two sessions in the coming IETF meeting >in Atlanta according to the preliminary agenda: >1) Afternoon Session I on Tuesday (2h); >2) Afternoon Session I on Wednesday (1.5h). > >Please send your request to Suresh and me in the following >format by Oct. 20 if you would like to have a time slot: > >(name, title, link to IETF datatracker, minutes requested). > > >Thanks, > >Yong & Suresh > > From simon.perreault@viagenie.ca Wed Nov 7 09:57:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823B21F8BE1 for ; Wed, 7 Nov 2012 09:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hOL-ysyK4Lw for ; Wed, 7 Nov 2012 09:57:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0305921F8A7F for ; Wed, 7 Nov 2012 09:57:02 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:4d65:4644:8063:d971]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6C9F4414AF for ; Wed, 7 Nov 2012 12:57:01 -0500 (EST) Message-ID: <509AA0EC.5020609@viagenie.ca> Date: Wed, 07 Nov 2012 12:57:00 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1 MIME-Version: 1.0 To: softwires@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] Minutes X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 17:57:02 -0000 If anyone wants to help fill in the blanks while I try to take minutes: http://tools.ietf.org/wg/softwire/minutes Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From stig@venaas.com Thu Nov 8 06:44:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3AA21F8536 for ; Thu, 8 Nov 2012 06:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWJ9QX8aylpB for ; Thu, 8 Nov 2012 06:44:29 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 521FD21F84F8 for ; Thu, 8 Nov 2012 06:44:29 -0800 (PST) Received: from [10.21.91.84] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 4C9207FCF; Thu, 8 Nov 2012 15:44:27 +0100 (CET) Message-ID: <509BC548.1020701@venaas.com> Date: Thu, 08 Nov 2012 06:44:24 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "softwires@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] draft-ietf-softwire-dslite-multicast-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:44:30 -0000 I had another look at draft-ietf-softwire-dslite-multicast-04.txt as I promisted during the meeting and I believe the document is good to go! I mentioned a dependency on the address-format draft, but I see that the dependency is no longer there (sorry I missed that), so I do indeed think it is ready for publication. Stig From tom.taylor.stds@gmail.com Thu Nov 8 08:20:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DFB21F89F5 for ; Thu, 8 Nov 2012 08:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IftcA6mQVVZ for ; Thu, 8 Nov 2012 08:20:41 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFFBA21F85F9 for ; Thu, 8 Nov 2012 08:20:41 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so2239476pad.31 for ; Thu, 08 Nov 2012 08:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=X7IXlhi8P5cgCVy7gZG1P+LfsVIIgHuXWmAKILkdnFI=; b=ciuhDEg0qFZUlLT499N92dCwbbcmTUAWC35wuOnCylN5dLVlgyHmxuR3qpivtQjwob Y8yv+qqu9CHxbP5X6bycQiCQQ/gwHg84CTdA+42ThPTC1n4dUhLC1xRHWJIQhofOt3sL 8x9CBDwZb6x6jqvAHQyAVB04EEZ8hdp+nhBijAY/E7yxw0ylLOcLw1T4TDtU31DHxYg4 wBv2w9GHjdG9fBaxIn1+NgX7ruHNRUnQL25rq8HCf7r/EP/bMUfo7udJQlqxXrLuwqkZ RvdpmYQKGIl/xhwOkUt7s6gWEALhIn02jGh1vzlHzA2mWcmmNYfHOoMelwZnyJGW1r48 6HRA== Received: by 10.68.232.201 with SMTP id tq9mr25399371pbc.12.1352391641459; Thu, 08 Nov 2012 08:20:41 -0800 (PST) Received: from ?IPv6:2001:df8:0:32:c8d5:3974:d689:8979? ([2001:df8:0:32:c8d5:3974:d689:8979]) by mx.google.com with ESMTPS id ok8sm16152928pbb.42.2012.11.08.08.20.39 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 08:20:40 -0800 (PST) Message-ID: <509BDBD6.6000509@gmail.com> Date: Thu, 08 Nov 2012 11:20:38 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: softwires@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] Ambiguity in draft-ietf-softwire-map-02.txt algorithm description X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 16:20:42 -0000 Section 5 of draft-ietf-softwire-map-02.txt describes the MAP algorithm. The paragraph following bullet 3 reads as follows: " A MAP node finds its Basic Mapping Rule by doing a longest match between the End-user IPv6 prefix and the Rule IPv6 prefix in the Mapping Rules table. The rule is then used for IPv4 prefix, address or shared address assignment." and, of course, the next paragraph goes on to say that the BMR is used to derive the MAP node's IPv6 address for MAP purposes. I have a feeling the paragraph quoted above applies only to MAP CEs, not to all MAP nodes. Can someone confirm this? Tom Taylor From otroan@employees.org Thu Nov 8 10:24:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6C21F84DF for ; Thu, 8 Nov 2012 10:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzSa4myUv2nK for ; Thu, 8 Nov 2012 10:24:16 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 33DE221F84D2 for ; Thu, 8 Nov 2012 10:24:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK73m1CQ/khR/2dsb2JhbABEw1iBCIIeAQEBAwESASc/BQsLRlcGNYdiBpt/oDSReGEDiFqJb5IKgWuDDQ X-IronPort-AV: E=Sophos;i="4.80,739,1344211200"; d="scan'208";a="146471820" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2012 18:24:11 +0000 Received: from dhcp-10-61-102-126.cisco.com (dhcp-10-61-102-126.cisco.com [10.61.102.126]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA8IO8E6031239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Nov 2012 18:24:10 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <509BDBD6.6000509@gmail.com> Date: Thu, 8 Nov 2012 13:24:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <509BDBD6.6000509@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1498) Cc: softwires@ietf.org Subject: Re: [Softwires] Ambiguity in draft-ietf-softwire-map-02.txt algorithm description X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:24:19 -0000 Tom, > Section 5 of draft-ietf-softwire-map-02.txt describes the MAP = algorithm. The paragraph following bullet 3 reads as follows: >=20 > " A MAP node finds its Basic Mapping Rule by doing a longest match > between the End-user IPv6 prefix and the Rule IPv6 prefix in the > Mapping Rules table. The rule is then used for IPv4 prefix, address > or shared address assignment." >=20 > and, of course, the next paragraph goes on to say that the BMR is used = to derive the MAP node's IPv6 address for MAP purposes. >=20 > I have a feeling the paragraph quoted above applies only to MAP CEs, = not to all MAP nodes. Can someone confirm this? it isn't restricted to only MAP CEs. a BR could also configure the = shared IPv4 address. this overlaps with the issue of, should the BR have = an IPv4 address that the CE's IPv4 stack could use as an IPv4 next-hop. = I think we ended up with no. if you think clarifications in order, please propose text. cheers, Ole= From sunqi.csnet.thu@gmail.com Thu Nov 8 16:03:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5E221F8B6D for ; Thu, 8 Nov 2012 16:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvK+mR67Ax6N for ; Thu, 8 Nov 2012 16:03:18 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35E3721F8B6B for ; Thu, 8 Nov 2012 16:03:17 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so1498080dan.31 for ; Thu, 08 Nov 2012 16:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=5pCWvoZAlpjPY/rbpYSfEHUSmvohQ4OG6HnN86YHjCA=; b=yPuglnMD/1Z+ocHO/4Jh7nqcDbGcbymu+21834NOq/4vhWoKtt8PRWg7YPMab+r/0w 81ygvcLVcVYoYLje2zSMYCNHu2NFAqsel0iiuJbBf6LvnuDDbFgTSSUDsghm1XR0/8Sm jkHEdxDZDgqSBchGJ+JGk1kklaJeYow91zYfgYb3ZZrddb+vzwMk3F47vjLtjkiz1WLI J2a0GhF+ftVO2gr3dyrFEnDIux2TKSQsrhhf+Pqe3h+2qxzCgX4LfQi48tcGORpndUMc bTANC46yVQCgOBZL3yLCZ4YHyql57rLmpveh/1/QIHKFakQjnGxMa57NdXFCO+kE7ml6 fcGw== Received: by 10.66.77.74 with SMTP id q10mr26592610paw.81.1352419397630; Thu, 08 Nov 2012 16:03:17 -0800 (PST) Received: from ?IPv6:2001:df8::16:9284:dff:fef3:d346? ([2001:df8:0:16:9284:dff:fef3:d346]) by mx.google.com with ESMTPS id ms11sm16673826pbc.74.2012.11.08.16.03.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Nov 2012 16:03:17 -0800 (PST) From: Qi Sun Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2012 19:03:14 -0500 Message-Id: <589D08EA-8BAE-4025-827B-D9B3CA0BA1D5@gmail.com> To: Softwires WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] lightweight 4over6 Demo in Bits-n-Bites X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 00:03:18 -0000 Dear all , We are honored to tell that the demo of lightweight 4over6 is taking = place in today's Bits-n-Bites!=20 Please enjoy the food and surf the Internet with lightweight 4over6! Looking forward to your dropping by! Thanks, Qi Sun From leaf.y.yeh@huawei.com Thu Nov 8 18:22:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F09F21F880A for ; Thu, 8 Nov 2012 18:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb+KUDQ889pq for ; Thu, 8 Nov 2012 18:22:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 25F9A21F87E6 for ; Thu, 8 Nov 2012 18:22:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALJ01566; Fri, 09 Nov 2012 02:22:40 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 9 Nov 2012 02:21:54 +0000 Received: from SZXEML444-HUB.china.huawei.com (10.82.67.182) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 9 Nov 2012 02:22:07 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml444-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.01.0323.003; Fri, 9 Nov 2012 10:22:01 +0800 From: Leaf yeh To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Tom Taylor Thread-Topic: [Softwires] Ambiguity in draft-ietf-softwire-map-02.txt algorithm description Thread-Index: AQHNvd5RW3LEia+GTkaHDfaFsAYx4JfgxSFw Date: Fri, 9 Nov 2012 02:22:00 +0000 Message-ID: References: <509BDBD6.6000509@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] Ambiguity in draft-ietf-softwire-map-02.txt algorithm description X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 02:22:52 -0000 My 2 cents: 'Allocation' might be better than 'Assignment' in the text. The= word of 'assignment' makes the reader tend to think only about the CEs. Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Ole Tr?an Sent: Friday, November 09, 2012 2:24 AM To: Tom Taylor Cc: softwires@ietf.org Subject: Re: [Softwires] Ambiguity in draft-ietf-softwire-map-02.txt algori= thm description Tom, > Section 5 of draft-ietf-softwire-map-02.txt describes the MAP algorithm. = The paragraph following bullet 3 reads as follows: >=20 > " A MAP node finds its Basic Mapping Rule by doing a longest match > between the End-user IPv6 prefix and the Rule IPv6 prefix in the > Mapping Rules table. The rule is then used for IPv4 prefix, address > or shared address assignment." >=20 > and, of course, the next paragraph goes on to say that the BMR is used to= derive the MAP node's IPv6 address for MAP purposes. >=20 > I have a feeling the paragraph quoted above applies only to MAP CEs, not = to all MAP nodes. Can someone confirm this? it isn't restricted to only MAP CEs. a BR could also configure the shared I= Pv4 address. this overlaps with the issue of, should the BR have an IPv4 ad= dress that the CE's IPv4 stack could use as an IPv4 next-hop. I think we en= ded up with no. if you think clarifications in order, please propose text. cheers, Ole _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Fri Nov 9 11:43:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6460E21F8564 for ; Fri, 9 Nov 2012 11:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.144 X-Spam-Level: X-Spam-Status: No, score=-104.144 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1GHuZlFkl9v for ; Fri, 9 Nov 2012 11:43:14 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF1321F8552 for ; Fri, 9 Nov 2012 11:43:14 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.41254637; Fri, 09 Nov 2012 12:17:51 -0700 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.131]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 14:43:08 -0500 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: MAP-E 1:1 for HA Thread-Index: AQHNvrJUhwE7DtDnmkmwZYkUbhoBVw== Date: Fri, 9 Nov 2012 19:43:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3435316988_1115972" MIME-Version: 1.0 Subject: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 19:43:15 -0000 --B_3435316988_1115972 Content-type: multipart/alternative; boundary="B_3435316987_1103611" --B_3435316987_1103611 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I have a question for the HA design concept of MAP-E 1:1. The central theme of MAP-E is to make BR as stateless as possible and use Anycast address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the operator must have to pre-provision all the subscribe rules to all the BRs sharing the same Anycast address for reliable HA. This requires operators to carefully plan out which BRs support which subscribers. It is because BR is "per-subscriber stateful" in MAP-E 1:1 mode. Compared to the MAP-E design, HA in MAP-E only requires the operators to use the same set of rules to cover the entire domain. IMHO, this contradicts the original spirit of stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E name. MAP-E and 1:1 MAP-E are two completely different solutions and target to different deployment scenarios. I would love to hear others to comment in the ML how to resolve this issue. Thanks, Yiu --B_3435316987_1103611 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I have a question for the HA= design concept of MAP-E 1:1. The central theme of MAP-E is to make BR as st= ateless as possible and use Anycast address to identify the MAP-E BR. Howeve= r, if we use MAP-E 1:1 mode, the operator must have to pre-provision all the= subscribe rules to all the BRs sharing the same Anycast address for reliabl= e HA. This requires operators to carefully plan out which BRs support which = subscribers. It is because BR is "per-subscriber stateful" in MAP-E 1:1= mode. Compared to the MAP-E design, HA in MAP-E only requires the oper= ators to use the same set of rules to cover the entire domain. IMHO, this co= ntradicts  the original spirit of stateless solution and always puzzles= me why MAP-E 1:1 bears the MAP-E name. MAP-E and 1:1 MAP-E are two complete= ly different solutions and target to different deployment scenarios. I would= love to hear others to comment in the ML how to resolve this issue.

Thanks,
Yiu


<= /body> --B_3435316987_1103611-- --B_3435316988_1115972 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFGNR b70TjxDwJrJFCv3C58qDgKOfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTEwOTE5NDMwN1owDQYJKoZIhvcNAQEBBQAEggEAPBcwUWxP4trFh+MkHYMm PtDfhr3lv+M6e3rhe+DO0l2Z8DGqxQBqXq0C3gXbVEvpa7EBx06RRsr3oH0x4+ttAhTa87BF +QV7ciE6nU9K2eBLEZvb6uZv4oQC2hBwqxP2WcI7PXSBSA9zPqlGK33p+5tgwqKiRk238X6I ZOdG9nIIQ7TrpxlrOWD2pk/ORB1bYP2ndMWo6Im4WBM60KfYQacze8ODg8cy8Z3aZVSgj236 QfUfsHMI9lKVqDcj0OnVcB9Q5LO7BjS+WHPGbytm4kDIIZV+m8DM+c4blWSAWJ5+B+v5BZow CpCtQiyXm81zDdaVRP8RyW9NIcr/KYW6Gw== --B_3435316988_1115972-- From otroan@employees.org Fri Nov 9 17:41:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B621021F8595 for ; Fri, 9 Nov 2012 17:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-OpIXG5op11 for ; Fri, 9 Nov 2012 17:41:36 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id ED8FF21F84DF for ; Fri, 9 Nov 2012 17:41:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGGvnVCQ/khL/2dsb2JhbAA6CsNSgQiCHgEBAQMBEgEnPwULCyQiVwYuB4diBp17oAWMJIVZYQOIWpt5gWuDDQ X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="9464659" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 10 Nov 2012 01:41:34 +0000 Received: from dhcp-10-61-98-103.cisco.com (dhcp-10-61-98-103.cisco.com [10.61.98.103]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAA1fMdQ011315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Nov 2012 01:41:34 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 9 Nov 2012 20:41:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F938BE0-D4DE-4F30-B26F-6B862D674192@employees.org> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1498) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 01:41:36 -0000 Yiu, > I have a question for the HA design concept of MAP-E 1:1. The central = theme of MAP-E is to make BR as stateless as possible and use Anycast = address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the = operator must have to pre-provision all the subscribe rules to all the = BRs sharing the same Anycast address for reliable HA. This requires = operators to carefully plan out which BRs support which subscribers. It = is because BR is "per-subscriber stateful" in MAP-E 1:1 mode. Compared = to the MAP-E design, HA in MAP-E only requires the operators to use the = same set of rules to cover the entire domain. IMHO, this contradicts = the original spirit of stateless solution and always puzzles me why = MAP-E 1:1 bears the MAP-E name. MAP-E and 1:1 MAP-E are two completely = different solutions and target to different deployment scenarios. I = would love to hear others to comment in the ML how to resolve this = issue. all nodes in a MAP domain must have the same rules. in 1:1 mode there is only the CE and the BR in the domain. having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn't = mean you need a different RIB implementation. a host route which is what we have in 1:1 mode is just a corner case. = what is "completely different" about it? cheers, Ole= From satoru.matsushima@gmail.com Fri Nov 9 18:54:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9721F87A7 for ; Fri, 9 Nov 2012 18:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCfKuQ2k7eur for ; Fri, 9 Nov 2012 18:54:36 -0800 (PST) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9F2421F8778 for ; Fri, 9 Nov 2012 18:54:35 -0800 (PST) Received: by mail-gh0-f172.google.com with SMTP id g10so995774ghb.31 for ; Fri, 09 Nov 2012 18:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wNWrw4oZtr87q2Ffs48lsU62dh38/FFD9fKD8CVCAQM=; b=0skSC+im/kODCszhKR8WdAf6alJGW+3/xTzJuzHUrtZfjp8FnlGnp1izKLpq/7eehx yg5MUtxKB1IbgpCB/Mq3wNGcgcSXPPBRFFy/R7blRS9XTm8p7+pBPmkmMx7Ck3W3oxU9 8r0sYPmt/qhKSjHrVHXds639vzmqQRr926q3QNHib8/tFui8B6lpLkG32IDY8qmyJPmv guGuoO9E49xSudEIDn8q8G3SWY/T05CXyckd74kHESYwpeJEDu7rwBJ1PNzuizFt3JIf YO0UMptcXzxTo53NiGMnOu1bvbXslOLg6RRvNWw23XRjsswviYacNOicMsmZuEQGs650 CPVQ== Received: by 10.101.180.1 with SMTP id h1mr3809793anp.25.1352516075505; Fri, 09 Nov 2012 18:54:35 -0800 (PST) Received: from dhcp107-17-120-168.hil-atlahhh.atl.wayport.net (dhcp107-17-120-168.hil-atlahhh.atl.wayport.net. [107.17.120.168]) by mx.google.com with ESMTPS id a44sm352327yhe.21.2012.11.09.18.54.29 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 18:54:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Satoru Matsushima In-Reply-To: <0F938BE0-D4DE-4F30-B26F-6B862D674192@employees.org> Date: Fri, 9 Nov 2012 21:54:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2180441E-F929-4B55-A45E-05E686FBF475@gmail.com> References: <0F938BE0-D4DE-4F30-B26F-6B862D674192@employees.org> To: =?utf-8?Q?Ole_Tr=C3=B8an?= , "Lee, Yiu" X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 02:54:36 -0000 On 2012/11/09, at 20:41, Ole Tr=C3=B8an wrote: --snip-- >> IMHO, this contradicts the original spirit of stateless solution and = always puzzles me why MAP-E 1:1 bears the MAP-E name. MAP-E and 1:1 = MAP-E are two completely different solutions and target to different = deployment scenarios. I would love to hear others to comment in the ML = how to resolve this issue. >=20 > all nodes in a MAP domain must have the same rules. > in 1:1 mode there is only the CE and the BR in the domain. >=20 > having an aggregate route e.g. an IPv4 /24 or a host route a /32 = doesn't mean you need a different RIB implementation. > a host route which is what we have in 1:1 mode is just a corner case. = what is "completely different" about it? +1. It is consistent with IP networking principle. BTW, to just clarify about map domain, cited from map-02 draft: > 3. Terminology >=20 >=20 > MAP domain: One or more MAP CEs and BRs connected to = the > same virtual link. A service provider may > deploy a single MAP domain, or may utilize > multiple MAP domains. >=20 cheers, --satoru= From bingxuere@gmail.com Fri Nov 9 20:05:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CB621F8ACD for ; Fri, 9 Nov 2012 20:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKZSNGeyIkoE for ; Fri, 9 Nov 2012 20:05:44 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B07EE21F8604 for ; Fri, 9 Nov 2012 20:05:44 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so3578760iak.31 for ; Fri, 09 Nov 2012 20:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E6lKne5BTG2FPVrac/eQiOEN36ZSTiCgIDuyvP0c7ig=; b=oOdQjg0THR+/ojnXrT8YHZKWApO2Z+3y/pG5+o/+E8M/Wva8r6LQHseMRD7uSvAFEN 4dwO+1BJnhQJAfhjGWL+XoO1Erx1CC0lz+UZcM8dpn3wOe9Lrg0+dKvaoznL3xVXPuZ3 bzyTuki8QMaIop6BtkS9FUBtCY5lGw5ox2dmZsFBZe6NDF91SZg9pUR+3sF1AQiZ0mQy Uk39CBjMurW2ktYKxHyX1Zgi8W5u9OZagbZ/gVxJRZu2kAy0J0RtoTqTbxzjmm8DmGyL 8iswaak4iCTqMi/0zoL+MKaGlFWjbp/OcPdI5TgxbK/DkxqllYYPGt7OM8HAjW1Rz/Y7 VKag== Received: by 10.43.120.3 with SMTP id fw3mr13396775icc.34.1352520344364; Fri, 09 Nov 2012 20:05:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Fri, 9 Nov 2012 20:05:04 -0800 (PST) In-Reply-To: <0F938BE0-D4DE-4F30-B26F-6B862D674192@employees.org> References: <0F938BE0-D4DE-4F30-B26F-6B862D674192@employees.org> From: Qiong Date: Sat, 10 Nov 2012 12:05:04 +0800 Message-ID: To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=bcaec517cb52ad684004ce1c2e76 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 04:05:45 -0000 --bcaec517cb52ad684004ce1c2e76 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole, On Sat, Nov 10, 2012 at 9:41 AM, Ole Tr=C3=B8an wrot= e: > Yiu, > > > I have a question for the HA design concept of MAP-E 1:1. The central > theme of MAP-E is to make BR as stateless as possible and use Anycast > address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the > operator must have to pre-provision all the subscribe rules to all the BR= s > sharing the same Anycast address for reliable HA. This requires operators > to carefully plan out which BRs support which subscribers. It is because = BR > is "per-subscriber stateful" in MAP-E 1:1 mode. Compared to the MAP-E > design, HA in MAP-E only requires the operators to use the same set of > rules to cover the entire domain. IMHO, this contradicts the original > spirit of stateless solution and always puzzles me why MAP-E 1:1 bears th= e > MAP-E name. MAP-E and 1:1 MAP-E are two completely different solutions an= d > target to different deployment scenarios. I would love to hear others to > comment in the ML how to resolve this issue. > > all nodes in a MAP domain must have the same rules. > in 1:1 mode there is only the CE and the BR in the domain. > > having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn't > mean you need a different RIB implementation. > [Qiong] Actually, that's not the same. If we only need /32, there is no need to do LPM implementation anymore, only exact matching is needed and this is much eaiser than LPM. LPM is not optimized for /32 routing lookup. The reason that current routers still implement LPM rather not exact matching is because /32 is a truely corner case in RIB. However, if /32 is not a corner case, but is the major requirement for operators, I believe more efficient way should be introduced. Best wishes Qiong > a host route which is what we have in 1:1 mode is just a corner case. wha= t > is "completely different" about it? > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --bcaec517cb52ad684004ce1c2e76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole,


On= Sat, Nov 10, 2012 at 9:41 AM, Ole Tr=C3=B8an <otroan@employees.org= > wrote:
Yiu,

> I have a question for the HA design concept of MAP-E 1:1. The central = theme of MAP-E is to make BR as stateless as possible and use Anycast addre= ss to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the operato= r must have to pre-provision all the subscribe rules to all the BRs sharing= the same Anycast address for reliable HA. This requires operators to caref= ully plan out which BRs support which subscribers. It is because BR is &quo= t;per-subscriber stateful" in MAP-E 1:1 mode. Compared to the MAP-E de= sign, HA in MAP-E only requires the operators to use the same set of rules = to cover the entire domain. IMHO, this contradicts =C2=A0the original spiri= t of stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E= name. MAP-E and 1:1 MAP-E are two completely different solutions and targe= t to different deployment scenarios. I would love to hear others to comment= in the ML how to resolve this issue.

all nodes in a MAP domain must have the same rules.
in 1:1 mode there is only the CE and the BR in the domain.

having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn'= t mean you need a different RIB implementation.
[Qiong= ] Actually, that's not the same. If we only need /32, there is no need = to do LPM implementation anymore, only exact matching is needed and this is= much eaiser than LPM. LPM is not optimized for /32 routing lookup.
The reason that current routers still implement LPM rather not exact matchi= ng is because /32 is a truely corner case in RIB. However, if /32 is not a = corner case, but is the major requirement for operators, I believe more eff= icient way should be introduced.

Best wishes
Qiong
=C2=A0
a host route which is what we have in 1:1 mode is just a corner case. what = is "completely different" about it?

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



--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Be= ijing Research Institude


Open source code:
lightweight 4over6= : h= ttp://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--bcaec517cb52ad684004ce1c2e76-- From rajiva@cisco.com Fri Nov 9 22:34:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012E321F85F3 for ; Fri, 9 Nov 2012 22:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJvczqRa2Tf3 for ; Fri, 9 Nov 2012 22:34:57 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4905121F85BB for ; Fri, 9 Nov 2012 22:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1306; q=dns/txt; s=iport; t=1352529297; x=1353738897; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=a8ahtQVctFHlCYQZlgFq4zkt9+GSPB9TIl9kJse2JrM=; b=UrOgmpIDAYqkC8IirzezQP2+z1T15zwzFANjntMY8hnt9264hJ2/ZSjl 7ib3Olck39APMMNZB9WHexoaDLrpIAELi5+y5yWWjJa8PTaysA5KeWizZ 2tshCvkl8WhXUd+wPnfH0dYUIor4dvDhHsgupKBJVFgNJEtXZV1LRBG3N 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABH1nVCtJXG+/2dsb2JhbAA6CsNTgQiCHgEBAQQSASdLBgEIEQMBAgsCEkIdCAIEARIIEweHaJ1rn3KMFBCFWWEDpFOBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="140827148" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 10 Nov 2012 06:34:56 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAA6YugQ005368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Nov 2012 06:34:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.76]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Sat, 10 Nov 2012 00:34:56 -0600 From: "Rajiv Asati (rajiva)" To: "Lee, Yiu" , "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNvrJUhwE7DtDnmkmwZYkUbhoBV5firlkA Date: Sat, 10 Nov 2012 06:34:55 +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.4.120824 x-originating-ip: [10.82.250.31] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19352.005 x-tm-as-result: No--36.253500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4B65E6E6B72F5D42BF714C06681D7C15@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 06:34:58 -0000 One can define a MAP-domain consisting of 1 CE or N CEs. This is more of a deployment choice. Cheers, Rajiv -----Original Message----- From: , Yiu Lee Date: Friday, November 9, 2012 2:43 PM To: Softwires-wg list Subject: [Softwires] MAP-E 1:1 for HA >I have a question for the HA design concept of MAP-E 1:1. The central >theme of MAP-E is to make BR as stateless as possible and use Anycast >address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the >operator must have to pre-provision all > the subscribe rules to all the BRs sharing the same Anycast address for >reliable HA. This requires operators to carefully plan out which BRs >support which subscribers. It is because BR is "per-subscriber stateful" >in MAP-E 1:1 mode. Compared to the MAP-E design, > HA in MAP-E only requires the operators to use the same set of rules to >cover the entire domain. IMHO, this contradicts the original spirit of >stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E >name. MAP-E and 1:1 MAP-E are two completely > different solutions and target to different deployment scenarios. I >would love to hear others to comment in the ML how to resolve this issue. > > >Thanks, >Yiu > > > > From rajiva@cisco.com Fri Nov 9 22:45:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966F921F8630 for ; Fri, 9 Nov 2012 22:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOZ2MGtwvC06 for ; Fri, 9 Nov 2012 22:45:07 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0B23F21F84B3 for ; Fri, 9 Nov 2012 22:45:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3548; q=dns/txt; s=iport; t=1352529907; x=1353739507; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UJ7zVuA5uo6ZUKjSfWSbRYs5MbnMeXvxB3XtZ0pUNug=; b=GcFUg3raYh+JUx4ytDW75lM2urv9hmWvZnxbdU0aARqerTSH0Bt65Fbg 4n9gpjGkat7LFOSoudnS0aLURK31QEeYXhWFQszKki70DbHAVW8kiy98D 9JVSUG81c3Dg3ZEznJaQoLqR5PZUiati0jnsTSjj/Pdsch01JBs9fVOM7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADD3nVCtJV2Y/2dsb2JhbAA6CsNTgQiCHgEBAQQBAQEPAVsLDAYBCBEDAQIBCgJDBgsdCAIEAQ0FCBMHh1YDDwudZZYRDYlUiyxoEIVZYQOIJYwBgnGKFoMmgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="140829094" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 10 Nov 2012 06:45:06 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAA6j6gU019337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Nov 2012 06:45:06 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.76]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Sat, 10 Nov 2012 00:45:05 -0600 From: "Rajiv Asati (rajiva)" To: Qiong , =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNvrJUhwE7DtDnmkmwZYkUbhoBV5fisCuAgAAoJQD//9jeAA== Date: Sat, 10 Nov 2012 06:45:04 +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.4.120824 x-originating-ip: [10.82.250.31] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19352.005 x-tm-as-result: No--47.248200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 06:45:08 -0000 Let's not get into debating the local behavior e.g. Implementation specifics (since one can argue that the router vendors can provide comparable optimization for host routes as well as non-host routes). If I as a vendor were really bothered about host vs. non-host control-plane & data-plane, then I could take the same standard (e.g. MAP-E) and implement the preferred part with whatever optimization possible without benefitting the non-preferred part. It really becomes an implementation (local behavior) choice. We don't need more of the same thing. :) Cheers, Rajiv -----Original Message----- From: Qiong Date: Friday, November 9, 2012 11:05 PM To: Ole Troan Cc: Softwires-wg list Subject: Re: [Softwires] MAP-E 1:1 for HA > > > >Hi Ole, > > >On Sat, Nov 10, 2012 at 9:41 AM, Ole Tr=F8an > wrote: > >Yiu, > >> I have a question for the HA design concept of MAP-E 1:1. The central >>theme of MAP-E is to make BR as stateless as possible and use Anycast >>address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the >>operator must have to pre-provision all the > subscribe rules to all the BRs sharing the same Anycast address for >reliable HA. This requires operators to carefully plan out which BRs >support which subscribers. It is because BR is "per-subscriber stateful" >in MAP-E 1:1 mode. Compared to the MAP-E design, > HA in MAP-E only requires the operators to use the same set of rules to >cover the entire domain. IMHO, this contradicts the original spirit of >stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E >name. MAP-E and 1:1 MAP-E are two completely > different solutions and target to different deployment scenarios. I >would love to hear others to comment in the ML how to resolve this issue. > > >all nodes in a MAP domain must have the same rules. >in 1:1 mode there is only the CE and the BR in the domain. > >having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn't >mean you need a different RIB implementation. > > >[Qiong] Actually, that's not the same. If we only need /32, there is no >need to do LPM implementation anymore, only exact matching is needed and >this is much eaiser than LPM. LPM is not optimized for /32 routing lookup. > >The reason that current routers still implement LPM rather not exact >matching is because /32 is a truely corner case in RIB. However, if /32 >is not a corner case, but is the major requirement for operators, I >believe more efficient way should be introduced. > >Best wishes >Qiong=20 >=20 > >a host route which is what we have in 1:1 mode is just a corner case. >what is "completely different" about it? > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > > > > > > >--=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Qiong Sun >China Telecom Beijing Research Institude > > >Open source code: >lightweight 4over6: http://sourceforge.net/projects/laft6/ >PCP-natcoord:=20 >http://sourceforge.net/projects/pcpportsetdemo/ > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > From bingxuere@gmail.com Sat Nov 10 19:01:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1300621F88D1 for ; Sat, 10 Nov 2012 19:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE0YXHTaQAC0 for ; Sat, 10 Nov 2012 19:01:41 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E65721F88CD for ; Sat, 10 Nov 2012 19:01:41 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so4069974iak.31 for ; Sat, 10 Nov 2012 19:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vl5kR/EMaRb56OmkYPJLpSt9ofhuO02e1aw+XSRrLGE=; b=WGWHAx9pNyfphPL9qG88S/FFvnx6vCcqAsfTL1YqwzhntsuPV1RXXX24dj0+OCAXw9 QrCLqB+21x99Xz+c67F/hdw57txVgjT6PbSbUowu89tkBkXO0P1UKbWtMK8PBvZspAQl MLKWvB2SrIUR4NoMySdyJuHWw8iI3d3mw3FILG5/sO35XO9YnYc0FhzGENRG2HgGOVBi Eu7dIqIPXlMuMww4BacaJ3RZXey4uMKKept9P3TrnFwqXSP3PDLEKLmaYjWfnKcupDky sv3aFS+uDV3yDMmhw5X8GOtttiZ3TzxVhP7qQL7Jl55YUNohZVQjYU1/huln9LUOANQ+ NPug== Received: by 10.50.222.233 with SMTP id qp9mr4536243igc.61.1352602900648; Sat, 10 Nov 2012 19:01:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Sat, 10 Nov 2012 19:01:00 -0800 (PST) In-Reply-To: References: From: Qiong Date: Sun, 11 Nov 2012 11:01:00 +0800 Message-ID: To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=14dae93406d76a534704ce2f6758 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 03:01:42 -0000 --14dae93406d76a534704ce2f6758 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rajiv, On Sat, Nov 10, 2012 at 2:45 PM, Rajiv Asati (rajiva) wro= te: > > Let's not get into debating the local behavior e.g. Implementation > specifics (since one can argue that the router vendors can provide > comparable optimization for host routes as well as non-host routes). > > If I as a vendor were really bothered about host vs. non-host > control-plane & data-plane, then I could take the same standard (e.g. > MAP-E) and implement the preferred part with whatever optimization > possible without benefitting the non-preferred part. It really becomes an > implementation (local behavior) choice. > Now that you need to optimize the implementation for different requirements, why not optimize it from protocol level ? So that every vendor would know how to implement for different requirements, rather than let operators pushing vendors one by one and tell them how to do. Without standardization, operators could still ask vendors to implement whatever they want. But standardization would reflect the common requirements from operators, and that would be easier for vendors to follow and implement. I do not understand why we do not follow this efficient way. Best wishes Qiong > We don't need more of the same thing. :) > > Cheers, > Rajiv > > -----Original Message----- > From: Qiong > Date: Friday, November 9, 2012 11:05 PM > To: Ole Troan > Cc: Softwires-wg list > Subject: Re: [Softwires] MAP-E 1:1 for HA > > > > > > > > >Hi Ole, > > > > > >On Sat, Nov 10, 2012 at 9:41 AM, Ole Tr=C3=B8an > > wrote: > > > >Yiu, > > > >> I have a question for the HA design concept of MAP-E 1:1. The central > >>theme of MAP-E is to make BR as stateless as possible and use Anycast > >>address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, th= e > >>operator must have to pre-provision all the > > subscribe rules to all the BRs sharing the same Anycast address for > >reliable HA. This requires operators to carefully plan out which BRs > >support which subscribers. It is because BR is "per-subscriber stateful" > >in MAP-E 1:1 mode. Compared to the MAP-E design, > > HA in MAP-E only requires the operators to use the same set of rules to > >cover the entire domain. IMHO, this contradicts the original spirit of > >stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E > >name. MAP-E and 1:1 MAP-E are two completely > > different solutions and target to different deployment scenarios. I > >would love to hear others to comment in the ML how to resolve this issue= . > > > > > >all nodes in a MAP domain must have the same rules. > >in 1:1 mode there is only the CE and the BR in the domain. > > > >having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn't > >mean you need a different RIB implementation. > > > > > >[Qiong] Actually, that's not the same. If we only need /32, there is no > >need to do LPM implementation anymore, only exact matching is needed and > >this is much eaiser than LPM. LPM is not optimized for /32 routing looku= p. > > > >The reason that current routers still implement LPM rather not exact > >matching is because /32 is a truely corner case in RIB. However, if /32 > >is not a corner case, but is the major requirement for operators, I > >believe more efficient way should be introduced. > > > >Best wishes > >Qiong > > > > > >a host route which is what we have in 1:1 mode is just a corner case. > >what is "completely different" about it? > > > >cheers, > >Ole > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires > > > > > > > > > > > > > >-- > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Qiong Sun > >China Telecom Beijing Research Institude > > > > > >Open source code: > >lightweight 4over6: http://sourceforge.net/projects/laft6/ > >PCP-natcoord: > >http://sourceforge.net/projects/pcpportsetdemo/ > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --14dae93406d76a534704ce2f6758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rajiv,


On = Sat, Nov 10, 2012 at 2:45 PM, Rajiv Asati (rajiva) <rajiva@cisco.com>= ; wrote:

Let's not get into debating the local behavior e.g. Implementation
specifics (since one can argue that the router vendors can provide
comparable optimization for host routes as well as non-host routes).

If I as a vendor were really bothered about host vs. non-host
control-plane & data-plane, then I could take the same standard (e.g. MAP-E) and implement the preferred part with whatever optimization
possible without benefitting the non-preferred part. It really becomes an implementation (local behavior) choice.
Now that you n= eed to optimize the implementation for different requirements, why not opti= mize it from protocol level ? So that every vendor would know how to implem= ent for different requirements, rather than let operators pushing vendors o= ne by one and tell them how to do.

Without standardization, operators could still ask vendor= s to implement whatever they want. But standardization would reflect the co= mmon requirements from operators, and that would be easier for vendors to f= ollow and implement. I do not understand why we do not follow this efficien= t way.

Best wishes
Qiong



We don't need more of the same thing. :)

Cheers,
Rajiv

-----Original Message-----
From: Qiong <bingxuere@gmail.com<= /a>>
Date: Friday, November 9, 2012 11:05 PM
To: Ole Troan <otroan@employees.= org>
Cc: Softwires-wg list <softwires@i= etf.org>
Subject: Re: [Softwires] MAP-E 1:1 for HA

>
>
>
>Hi Ole,
>
>
>On Sat, Nov 10, 2012 at 9:41 AM, Ole Tr=C3=B8an
><otroan@employees.org>= ; wrote:
>
>Yiu,
>
>> I have a question for the HA design concept of MAP-E 1:1. The cent= ral
>>theme of MAP-E is to make BR as stateless as possible and use Anyca= st
>>address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode= , the
>>operator must have to pre-provision all the
> subscribe rules to all the BRs sharing the same Anycast address for >reliable HA. This requires operators to carefully plan out which BRs >support which subscribers. It is because BR is "per-subscriber sta= teful"
>in MAP-E 1:1 mode. Compared to the MAP-E design,
> HA in MAP-E only requires the operators to use the same set of rules t= o
>cover the entire domain. IMHO, this contradicts =C2=A0the original spir= it of
>stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E<= br> >name. MAP-E and 1:1 MAP-E are two completely
> different solutions and target to different deployment scenarios. I >would love to hear others to comment in the ML how to resolve this issu= e.
>
>
>all nodes in a MAP domain must have the same rules.
>in 1:1 mode there is only the CE and the BR in the domain.
>
>having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn&= #39;t
>mean you need a different RIB implementation.
>
>
>[Qiong] Actually, that's not the same. If we only need /32, there i= s no
>need to do LPM implementation anymore, only exact matching is needed an= d
>this is much eaiser than LPM. LPM is not optimized for /32 routing look= up.
>
>The reason that current routers still implement LPM rather not exact >matching is because /32 is a truely corner case in RIB. However, if /32=
>is not a corner case, but is the major requirement for operators, I
>believe more efficient way should be introduced.
>
>Best wishes
>Qiong
>
>
>a host route which is what we have in 1:1 mode is just a corner case. >what is "completely different" about it?
>
>cheers,
>Ole
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires
>
>
>
>
>
>
>--
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>Qiong Sun
>China Telecom Beijing Research Institude
>
>
>Open source code:
>lightweight 4over6: http://sourceforge.net/projects/laft6/
>PCP-natcoord:
>http://sourceforge.net/projects/pcpportsetdemo/
><http://sourceforge.net/projects/pcpportsetdemo/&= gt;
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >
>
>




--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Be= ijing Research Institude


Open source code:
lightweight 4over6= : h= ttp://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--14dae93406d76a534704ce2f6758-- From sunqi.csnet.thu@gmail.com Sun Nov 11 04:42:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DBF21F8781 for ; Sun, 11 Nov 2012 04:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcAFmFGn6Ujb for ; Sun, 11 Nov 2012 04:42:33 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADCD21F877B for ; Sun, 11 Nov 2012 04:42:33 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so2431734dan.31 for ; Sun, 11 Nov 2012 04:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9UtycRujbGFCl2lsnVjJcoVC5aC4laNusCSbN1IKf54=; b=UBirg51/NqHCqwwW+qos7yMe7wLteiO0XyH+33DDwCNtFx2Yzk+xIOnIMbMIlQbZxg C6hQe32j8mUnlyZ5lzG/qBjChzytSYtONqM88fBnO4O6u5f1x/i8TiPz2ZDmyR65oyoF O3nFSr4VGtX57ggjTRA2Y/i/Oy6c6By9ktYdQjPlGtaYjL+CW96i+vZNGZ/eEzjonj3s q0/nMDjYyCPNK0DaQA4Hz9UHj5jGVHJAoRLekbc4jbULfAs7Vk5CVpdoaQmuVcXZYAaT o26HyVbwKW3FzDaWgcAsLQs/5l2Dv8iGwEBNEh1gV4+AZFaZ0NENAA66EfwHkCKb/jyN 8aNQ== Received: by 10.68.232.2 with SMTP id tk2mr43202376pbc.92.1352637753104; Sun, 11 Nov 2012 04:42:33 -0800 (PST) Received: from [192.168.0.108] ([114.255.41.137]) by mx.google.com with ESMTPS id vi9sm2476413pbc.41.2012.11.11.04.42.29 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Nov 2012 04:42:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Sun, 11 Nov 2012 20:42:27 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 12:42:34 -0000 Rajiv, Please see inline. Thanks, Qi Sun On 2012-11-10, at =E4=B8=8B=E5=8D=882:45, Rajiv Asati (rajiva) wrote: >=20 > Let's not get into debating the local behavior e.g. Implementation > specifics (since one can argue that the router vendors can provide > comparable optimization for host routes as well as non-host routes). [Qi] This is not about implementations. But about the conflicts of two = parts in one protocol. >=20 > If I as a vendor were really bothered about host vs. non-host > control-plane & data-plane, then I could take the same standard (e.g. > MAP-E) and implement the preferred part with whatever optimization > possible [Qi]You mean implementing the preferred part with a method that is = conflicting with the base protocol? I don't see a reason why we should = do that.=20 There is another protocol (e.g. lw4over6) perfectly suitable for the = scenario, which is optimized by design. Vendors don't have to waste = energy figuring out how to optimize. > without benefitting the non-preferred part. It really becomes an > implementation (local behavior) choice. >=20 > We don't need more of the same thing. :) >=20 > Cheers, > Rajiv >=20 > -----Original Message----- > From: Qiong > Date: Friday, November 9, 2012 11:05 PM > To: Ole Troan > Cc: Softwires-wg list > Subject: Re: [Softwires] MAP-E 1:1 for HA >=20 >>=20 >>=20 >>=20 >> Hi Ole, >>=20 >>=20 >> On Sat, Nov 10, 2012 at 9:41 AM, Ole Tr=C3=B8an >> wrote: >>=20 >> Yiu, >>=20 >>> I have a question for the HA design concept of MAP-E 1:1. The = central >>> theme of MAP-E is to make BR as stateless as possible and use = Anycast >>> address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, = the >>> operator must have to pre-provision all the >> subscribe rules to all the BRs sharing the same Anycast address for >> reliable HA. This requires operators to carefully plan out which BRs >> support which subscribers. It is because BR is "per-subscriber = stateful" >> in MAP-E 1:1 mode. Compared to the MAP-E design, >> HA in MAP-E only requires the operators to use the same set of rules = to >> cover the entire domain. IMHO, this contradicts the original spirit = of >> stateless solution and always puzzles me why MAP-E 1:1 bears the = MAP-E >> name. MAP-E and 1:1 MAP-E are two completely >> different solutions and target to different deployment scenarios. I >> would love to hear others to comment in the ML how to resolve this = issue. >>=20 >>=20 >> all nodes in a MAP domain must have the same rules. >> in 1:1 mode there is only the CE and the BR in the domain. >>=20 >> having an aggregate route e.g. an IPv4 /24 or a host route a /32 = doesn't >> mean you need a different RIB implementation. >>=20 >>=20 >> [Qiong] Actually, that's not the same. If we only need /32, there is = no >> need to do LPM implementation anymore, only exact matching is needed = and >> this is much eaiser than LPM. LPM is not optimized for /32 routing = lookup. >>=20 >> The reason that current routers still implement LPM rather not exact >> matching is because /32 is a truely corner case in RIB. However, if = /32 >> is not a corner case, but is the major requirement for operators, I >> believe more efficient way should be introduced. >>=20 >> Best wishes >> Qiong=20 >>=20 >>=20 >> a host route which is what we have in 1:1 mode is just a corner case. >> what is "completely different" about it? >>=20 >> cheers, >> Ole >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> --=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Qiong Sun >> China Telecom Beijing Research Institude >>=20 >>=20 >> Open source code: >> lightweight 4over6: http://sourceforge.net/projects/laft6/ >> PCP-natcoord:=20 >> http://sourceforge.net/projects/pcpportsetdemo/ >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Sun Nov 11 23:47:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B8C21F84FA for ; Sun, 11 Nov 2012 23:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.803 X-Spam-Level: X-Spam-Status: No, score=-9.803 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3gBb9Jhl3X6 for ; Sun, 11 Nov 2012 23:47:36 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 64E6A21F8470 for ; Sun, 11 Nov 2012 23:47:36 -0800 (PST) X-IronPort-AV: E=McAfee;i="5400,1158,6893"; a="146599391" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 Nov 2012 07:47:35 +0000 Received: from dhcp-lys01-vla250-10-147-112-82.cisco.com (dhcp-lys01-vla250-10-147-112-82.cisco.com [10.147.112.82]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAC7lWnb007092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2012 07:47:35 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Sun, 11 Nov 2012 08:11:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> References: To: Qiong X-Mailer: Apple Mail (2.1498) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 07:47:37 -0000 Qiong, > Now that you need to optimize the implementation for different = requirements, why not optimize it from protocol level ? So that every = vendor would know how to implement for different requirements, rather = than let operators pushing vendors one by one and tell them how to do. what is the difference in protocol? are the bits on the wire between these two proposals different? cheers, Ole= From tom.taylor.stds@gmail.com Mon Nov 12 08:16:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECC121F8561 for ; Mon, 12 Nov 2012 08:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwYVethLg+uz for ; Mon, 12 Nov 2012 08:16:23 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 839E421F85F5 for ; Mon, 12 Nov 2012 08:16:23 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so553210iaf.31 for ; Mon, 12 Nov 2012 08:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=nEHYLQ25AJT8ZK46AGA1Scli9aFZkiUylcg0sAdYwCc=; b=ImQ0qt8pu973DzFpasK8zjS/FUS+XYz8f/8PfGWkFgBN+jo78IA83gJx2iEgn4qd14 jKCLLbWWJL0ANRBb/pckDw5U0o7psfaDKXfc146PbN3QgpFIbVdLvaxoX3KTQD4i2Rok SOhwoCFWYsTof4SPc1NsdiFKG0OSsNTH1EGQ8uVg+qBV80MpA6JEByXQo4+MNYSbQyFe XusNrV9Uy67krBXjUjWAr7fb2Uf+ffnOc2+F6V+MFwU5R0QjoQpgvFnAE6ZjYudx5eIe NdW62RpR/01Hftvtnokenw8+Rc2PjabWIMFZu4bjvTFZ5gj77xwj6xuTR+6Cv/GE1qNp i5+g== Received: by 10.50.57.234 with SMTP id l10mr8468586igq.18.1352736978444; Mon, 12 Nov 2012 08:16:18 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-12-215.tor.primus.ca. [173.206.12.215]) by mx.google.com with ESMTPS id az6sm8400280igb.11.2012.11.12.08.16.16 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 08:16:17 -0800 (PST) Message-ID: <50A120D0.3040402@gmail.com> Date: Mon, 12 Nov 2012 11:16:16 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> In-Reply-To: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121112-0, 12/11/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 16:16:25 -0000 I'd say they are, in that the IPv6 address for MAP has semantics buried in it. But the really relevant difference between MAP and LW4over6 is the latter's requirement for the AFTR to carry and use per-subscriber data. That is a fundamental factor in the cost equation. However, the cost of the AFTR is only part of the total system cost (including the cost of operation and feasibility of deployment), and the tradeoffs for some operators will be different from those for others. On 11/11/2012 8:11 AM, Ole Trøan wrote: > Qiong, > >> Now that you need to optimize the implementation for different requirements, why not optimize it from protocol level ? So that every vendor would know how to implement for different requirements, rather than let operators pushing vendors one by one and tell them how to do. > > what is the difference in protocol? > are the bits on the wire between these two proposals different? > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From yiu_lee@cable.comcast.com Mon Nov 12 10:33:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8109821F877C for ; Mon, 12 Nov 2012 10:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.682 X-Spam-Level: X-Spam-Status: No, score=-104.682 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tlhvnv+7J4Sq for ; Mon, 12 Nov 2012 10:33:12 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id BC52221F8775 for ; Mon, 12 Nov 2012 10:33:11 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.41516999; Mon, 12 Nov 2012 11:08:19 -0700 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.131]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 13:33:07 -0500 From: "Lee, Yiu" To: "Rajiv Asati (rajiva)" , "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNwQQoa+1buylRUkaNp5akp3fB8A== Date: Mon, 12 Nov 2012 18:33:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3435571985_1032527" MIME-Version: 1.0 Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:33:12 -0000 --B_3435571985_1032527 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I am not talking about whether a MAP-domain should support 1 or N CEs. What I am trying to say is MAP-E 1:1 requires the BR to know per subscriber information and the operator must pre-provision per-subscriber based rules to every BR in the same domain. In addition, the BR can't use programatic logic to reduce states. When the WG first decided to work on a "stateless" solution, the goal was to make BR as stateless as possible. MAP-E 1:1 in contrast requires to store all subscriber rules in the BR and can't derive the CE's IPv6 address using programatic logic. I found it odd to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a stateful solution to me. On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" wrote: > >One can define a MAP-domain consisting of 1 CE or N CEs. This is more of a >deployment choice. > >Cheers, >Rajiv > > >-----Original Message----- >From: , Yiu Lee >Date: Friday, November 9, 2012 2:43 PM >To: Softwires-wg list >Subject: [Softwires] MAP-E 1:1 for HA > >>I have a question for the HA design concept of MAP-E 1:1. The central >>theme of MAP-E is to make BR as stateless as possible and use Anycast >>address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the >>operator must have to pre-provision all >> the subscribe rules to all the BRs sharing the same Anycast address for >>reliable HA. This requires operators to carefully plan out which BRs >>support which subscribers. It is because BR is "per-subscriber stateful" >>in MAP-E 1:1 mode. Compared to the MAP-E design, >> HA in MAP-E only requires the operators to use the same set of rules to >>cover the entire domain. IMHO, this contradicts the original spirit of >>stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E >>name. MAP-E and 1:1 MAP-E are two completely >> different solutions and target to different deployment scenarios. I >>would love to hear others to comment in the ML how to resolve this issue. >> >> >>Thanks, >>Yiu >> >> >> >> > --B_3435571985_1032527 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFOuF 2WHAXPjgnqVlummc0tKpjMwXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTExMjE4MzMwNFowDQYJKoZIhvcNAQEBBQAEggEAbZpup9VSNIeLP1nAKnJh qQKGVwG8KztAb+jxiNhR2o0YujnrC06vLdTGcZN2D5Rrqdl2U4VL/QefazKJ4sLAnrbB9PiK 1lsHt0WGva5PULgou5YQ8m0vZ2lGLEeQ+TOG74WT0gQJeWW26NizNNGaJGUhQpNv5l0cSHNU niLyuhTLFKNiHAjciuIvzn3RQHuXauvedvZTGpCXSFRg9lEk7/hiAcH5T9GKs8oBb5vuowQO yNOYhDC3Y7twwWxLW3JnSOhELQydxPVesi2gde/dzYRWO8Ji2aa8Upr/hDi2ilDHSwkA10Cv d2LymUfKXq71okd/aYte2jaHMOmrcOVkaw== --B_3435571985_1032527-- From yiu_lee@cable.comcast.com Mon Nov 12 10:35:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA821F84C4 for ; Mon, 12 Nov 2012 10:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.792 X-Spam-Level: X-Spam-Status: No, score=-104.792 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP-mnfDsn9dI for ; Mon, 12 Nov 2012 10:35:20 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFD521F84BA for ; Mon, 12 Nov 2012 10:35:20 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.41517415; Mon, 12 Nov 2012 11:10:27 -0700 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.131]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 13:35:15 -0500 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNwQR0+B5WiTuES02FMV9tTE2Kig== Date: Mon, 12 Nov 2012 18:35:14 +0000 Message-ID: In-Reply-To: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3435572114_1032261" MIME-Version: 1.0 Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:35:21 -0000 --B_3435572114_1032261 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ole, >From my perspective, the argument is not whether two protocols are identical or not. I found MAP-E 1:1 is a stateful solution. I found it odd to make it part of MAP-E which was originally decided a stateless solution. Regards, Yiu On 11/11/12 8:11 AM, "Ole Tr=F8an" wrote: >Qiong, > >> Now that you need to optimize the implementation for different >>requirements, why not optimize it from protocol level ? So that every >>vendor would know how to implement for different requirements, rather >>than let operators pushing vendors one by one and tell them how to do. > >what is the difference in protocol? >are the bits on the wire between these two proposals different? > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3435572114_1032261 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFJXo rhRihYtdXzg10f11+bX5FgHxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEyMTExMjE4MzUxM1owDQYJKoZIhvcNAQEBBQAEggEASWPvq6DbLPiJTubDVB+C bSfdnoFphtlG46Ff0BLpn6A3de5IY+5joPJVartNVmzRFWRSFfwMDf9Py4n6nExrOcxG9/+Y +YpAMVmLi8R4lvZrdwkMlcTafFmDm/xUHf8hg+Q0vdvGXkWIqADLB7NCg9i4jorcKfxw22pa /Fl4CT5LyisZCEzxow6zz8n6zS1W3D++wEG10DUdPgGMhND7r7EqHlPMrlBG7CKqtmA1WNtz xOu7xzJgpMgLy1anLoTfdFI7dQ8segbCWf9IOxhIjHCo8EZrQ17MZFhpcIhYf38MST9B14Hi 7D82L+MQoODTTyL84LdlwRBMVAhF9Y7SqQ== --B_3435572114_1032261-- From otroan@employees.org Mon Nov 12 11:11:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0452321F8630 for ; Mon, 12 Nov 2012 11:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdVykB5PO8nI for ; Mon, 12 Nov 2012 11:11:07 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 398A621F8614 for ; Mon, 12 Nov 2012 11:11:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH9IoVCQ/khM/2dsb2JhbABEw1qBCIIeAQEBAwESAWYQC0ZXBi4Hh2IGmWKfe5F+YQObZ4htgWuCcA X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="9514214" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 12 Nov 2012 19:11:06 +0000 Received: from [10.61.103.246] (dhcp-10-61-103-246.cisco.com [10.61.103.246]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qACJB5ms006653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Nov 2012 19:11:05 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 12 Nov 2012 20:11:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8104BEC2-5705-4423-AF62-BA71A34FC195@employees.org> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:11:08 -0000 Yiu, >> =46rom my perspective, the argument is not whether two protocols are > identical or not. I found MAP-E 1:1 is a stateful solution. I found it = odd > to make it part of MAP-E which was originally decided a stateless = solution. look at it as a slider. just like you can represent both aggregate = routes (/20, /24) and host routes (/32) in a RIB, so you can in MAP. you can make a data structure that only support host routes (LW46), but = when you have a data structure that supports variable prefix lengths then host route support is part of the package. I don't think there is a way to take 1:1 mode out of MAP, even if we = wanted to. cheers, Ole= From rajiva@cisco.com Mon Nov 12 11:51:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C5521F86D3 for ; Mon, 12 Nov 2012 11:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx02PjkzzDAL for ; Mon, 12 Nov 2012 11:51:28 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F121221F8626 for ; Mon, 12 Nov 2012 11:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2741; q=dns/txt; s=iport; t=1352749888; x=1353959488; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=jVXUtZwiv2y17ddfy5s92pNwPbHt+uH/+ym7hRhrOEc=; b=b0Y0r1jaITU88DGpkRPI6xDnu+HUb1iKLnRcGMZD4K25/ow27JnXvNPK ypuoJQicIS353SqlAYjIVeMzxznArGZpMbavJ6xEWAokzPdTrR4VqMub6 +oduPVn1x2fO/DEq0PAXbGQgLahyRhw+jgvo5q54UPv9Poq4KRHBhPeEv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJdSoVCtJV2Z/2dsb2JhbAA6CsNagQiCHgEBAQQSASdLBgEIEQMBAgEKAhJCHQgCBAESCBMHh2iZY6ACjBUQhVlhA6RUgWuCb4IZ X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="138407307" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2012 19:51:27 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qACJpRST028004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 19:51:27 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.76]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 13:51:27 -0600 From: "Rajiv Asati (rajiva)" To: "Lee, Yiu" , "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNvrJUhwE7DtDnmkmwZYkUbhoBV5firlkAgARBJwD//8IOgA== Date: Mon, 12 Nov 2012 19:51:26 +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.4.120824 x-originating-ip: [10.82.249.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--46.197800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <49D47692214D3F43B8E8563A9CE8C326@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:51:29 -0000 Sure, and it is really a deployment choice (just like it is a deployment choice to use a dynamic routing protocol to advertise host routes or summary routes or both in an IP network). But that's not to say that we need one protocol for advertising the host routes, and another for advertising the summary routes. Cheers, Rajiv -----Original Message----- From: Yiu Lee Date: Monday, November 12, 2012 1:33 PM To: Rajiv Asati , Softwires-wg list Subject: Re: [Softwires] MAP-E 1:1 for HA >I am not talking about whether a MAP-domain should support 1 or N CEs. >What I am trying to say is MAP-E 1:1 requires the BR to know per >subscriber information and the operator must pre-provision per-subscriber >based rules to every BR in the same domain. In addition, the BR can't use >programatic logic to reduce states. When the WG first decided to work on a >"stateless" solution, the goal was to make BR as stateless as possible. >MAP-E 1:1 in contrast requires to store all subscriber rules in the BR and >can't derive the CE's IPv6 address using programatic logic. I found it odd >to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a >stateful solution to me. > > >On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" wrote: > >> >>One can define a MAP-domain consisting of 1 CE or N CEs. This is more of >>a >>deployment choice. >> >>Cheers, >>Rajiv >> >> >>-----Original Message----- >>From: , Yiu Lee >>Date: Friday, November 9, 2012 2:43 PM >>To: Softwires-wg list >>Subject: [Softwires] MAP-E 1:1 for HA >> >>>I have a question for the HA design concept of MAP-E 1:1. The central >>>theme of MAP-E is to make BR as stateless as possible and use Anycast >>>address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, the >>>operator must have to pre-provision all >>> the subscribe rules to all the BRs sharing the same Anycast address for >>>reliable HA. This requires operators to carefully plan out which BRs >>>support which subscribers. It is because BR is "per-subscriber stateful" >>>in MAP-E 1:1 mode. Compared to the MAP-E design, >>> HA in MAP-E only requires the operators to use the same set of rules to >>>cover the entire domain. IMHO, this contradicts the original spirit of >>>stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E >>>name. MAP-E and 1:1 MAP-E are two completely >>> different solutions and target to different deployment scenarios. I >>>would love to hear others to comment in the ML how to resolve this >>>issue. >>> >>> >>>Thanks, >>>Yiu >>> >>> >>> >>> >> From Tetsuya.Murakami@ipinfusion.com Mon Nov 12 18:01:16 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C39821F877F for ; Mon, 12 Nov 2012 18:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivdZayU1A3JL for ; Mon, 12 Nov 2012 18:01:16 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id D83AC21F8769 for ; Mon, 12 Nov 2012 18:01:15 -0800 (PST) Received: from mail23-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Nov 2012 02:01:14 +0000 Received: from mail23-co1 (localhost [127.0.0.1]) by mail23-co1-R.bigfish.com (Postfix) with ESMTP id D6E065C024B; Tue, 13 Nov 2012 02:01:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: PS3(zz4015Izz1de0h1202h1d1ah1d2ahzzz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received-SPF: pass (mail23-co1: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail23-co1 (localhost.localdomain [127.0.0.1]) by mail23-co1 (MessageSwitch) id 1352772073589391_7906; Tue, 13 Nov 2012 02:01:13 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.234]) by mail23-co1.bigfish.com (Postfix) with ESMTP id 8C26B7C004A; Tue, 13 Nov 2012 02:01:13 +0000 (UTC) Received: from CH1PRD0510HT003.namprd05.prod.outlook.com (157.56.244.213) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Nov 2012 02:01:13 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.12.147]) by CH1PRD0510HT003.namprd05.prod.outlook.com ([10.255.150.38]) with mapi id 14.16.0233.002; Tue, 13 Nov 2012 02:01:02 +0000 From: Tetsuya Murakami To: "Lee, Yiu" Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNwUK7a9eOrN8Lv0GWEZXSADDZFQ== Date: Tue, 13 Nov 2012 02:01:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:01:16 -0000 Yiu, > I am not talking about whether a MAP-domain should support 1 or N CEs. > What I am trying to say is MAP-E 1:1 requires the BR to know per > subscriber information and the operator must pre-provision per-subscriber > based rules to every BR in the same domain. In addition, the BR can't use > programatic logic to reduce states. When the WG first decided to work on = a > "stateless" solution, the goal was to make BR as stateless as possible. > MAP-E 1:1 in contrast requires to store all subscriber rules in the BR an= d > can't derive the CE's IPv6 address using programatic logic. I found it od= d > to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a > stateful solution to me. I am not sure why you are thinking MAP-E 1:1 as the stateful solution. BR j= ust has the configuration (not state). I think the stateless does not mean = "no configuration". Thanks, Tetsuya= From Tetsuya.Murakami@ipinfusion.com Mon Nov 12 18:02:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E2821F87BF for ; Mon, 12 Nov 2012 18:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.350, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWiKLl9tIzPE for ; Mon, 12 Nov 2012 18:02:47 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0E221F877F for ; Mon, 12 Nov 2012 18:02:46 -0800 (PST) Received: from mail268-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 13 Nov 2012 02:02:42 +0000 Received: from mail268-tx2 (localhost [127.0.0.1]) by mail268-tx2-R.bigfish.com (Postfix) with ESMTP id A4DC31F0013F; Tue, 13 Nov 2012 02:02:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzbb2dI98dIc89bh1432I4015Izz1de0h1202h1d1ah1d2ahzzz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received-SPF: pass (mail268-tx2: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail268-tx2 (localhost.localdomain [127.0.0.1]) by mail268-tx2 (MessageSwitch) id 1352772160920628_8411; Tue, 13 Nov 2012 02:02:40 +0000 (UTC) Received: from TX2EHSMHS007.bigfish.com (unknown [10.9.14.237]) by mail268-tx2.bigfish.com (Postfix) with ESMTP id DE72B60004C; Tue, 13 Nov 2012 02:02:40 +0000 (UTC) Received: from CH1PRD0510HT001.namprd05.prod.outlook.com (157.56.244.213) by TX2EHSMHS007.bigfish.com (10.9.99.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 13 Nov 2012 02:02:40 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.12.147]) by CH1PRD0510HT001.namprd05.prod.outlook.com ([10.255.150.36]) with mapi id 14.16.0233.002; Tue, 13 Nov 2012 02:02:39 +0000 From: Tetsuya Murakami To: =?utf-8?B?T2xlIFRyw7hhbg==?= Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNwUL0a9eOrN8Lv0GWEZXSADDZFQ== Date: Tue, 13 Nov 2012 02:02:38 +0000 Message-ID: References: <8104BEC2-5705-4423-AF62-BA71A34FC195@employees.org> In-Reply-To: <8104BEC2-5705-4423-AF62-BA71A34FC195@employees.org> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:02:48 -0000 DQpPbiAyMDEyLzExLzEyLCBhdCAxMToxMSwgT2xlIFRyw7hhbiB3cm90ZToNCg0KPiBZaXUsDQo+ IA0KPj4+IEZyb20gbXkgcGVyc3BlY3RpdmUsIHRoZSBhcmd1bWVudCBpcyBub3Qgd2hldGhlciB0 d28gcHJvdG9jb2xzIGFyZQ0KPj4gaWRlbnRpY2FsIG9yIG5vdC4gSSBmb3VuZCBNQVAtRSAxOjEg aXMgYSBzdGF0ZWZ1bCBzb2x1dGlvbi4gSSBmb3VuZCBpdCBvZGQNCj4+IHRvIG1ha2UgaXQgcGFy dCBvZiBNQVAtRSB3aGljaCB3YXMgb3JpZ2luYWxseSBkZWNpZGVkIGEgc3RhdGVsZXNzIHNvbHV0 aW9uLg0KPiANCj4gbG9vayBhdCBpdCBhcyBhIHNsaWRlci4ganVzdCBsaWtlIHlvdSBjYW4gcmVw cmVzZW50IGJvdGggYWdncmVnYXRlIHJvdXRlcyAoLzIwLCAvMjQpIGFuZCBob3N0IHJvdXRlcyAo LzMyKSBpbiBhIFJJQiwNCj4gc28geW91IGNhbiBpbiBNQVAuDQo+IHlvdSBjYW4gbWFrZSBhIGRh dGEgc3RydWN0dXJlIHRoYXQgb25seSBzdXBwb3J0IGhvc3Qgcm91dGVzIChMVzQ2KSwgYnV0IHdo ZW4geW91IGhhdmUgYSBkYXRhIHN0cnVjdHVyZSB0aGF0IHN1cHBvcnRzDQo+IHZhcmlhYmxlIHBy ZWZpeCBsZW5ndGhzIHRoZW4gaG9zdCByb3V0ZSBzdXBwb3J0IGlzIHBhcnQgb2YgdGhlIHBhY2th Z2UuDQo+IA0KPiBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgd2F5IHRvIHRha2UgMToxIG1vZGUg b3V0IG9mIE1BUCwgZXZlbiBpZiB3ZSB3YW50ZWQgdG8uDQoNCisxLiBUaGUgaG9zdCByb3V0ZSAo LzMyKSBpcyBhbHNvIHBhcnQgb2YgdGhlIHZhcmlhYmxlIHByZWZpeCBsZW5ndGguIA0KDQpUaGFu a3MsDQpUZXRzdXlh From bingxuere@gmail.com Mon Nov 12 19:55:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5944B21F8856 for ; Mon, 12 Nov 2012 19:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjXM97hHK4Bs for ; Mon, 12 Nov 2012 19:55:33 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 950AD21F85EE for ; Mon, 12 Nov 2012 19:55:33 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so1016961iaf.31 for ; Mon, 12 Nov 2012 19:55:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hW2wvWeoBTTmQpTU4U5vsICLGE3ZzIO2VT4+BaUlBaA=; b=du+92z/OSdaEsnqfGh6aV5/pnXZlLV8kuYu0SGRC4vBOcRm4ILaVJxwVakF+96eIkD 4HaPuKT1K08yGvtIP0gzeO9YSEM3Fg9Qrs+XsgsiY23/KEbSi1jw9t0cR7fPzmONkaWY UPoEZ5jfl+bW6yun8APXUUG4JH0vrALGMN7JmixGeTrt5B/LEuUQUJs/tc7kg5092n3M KVyVO5MiokGj1dHni8BVS0jmWTEgpSAoQGyAWVl83udGqG7iTiZfypzDd7JN5LHjjtJ3 CoBU0O0MzjH+9IOuG1Y95Iwv8m7OoFBFcrnJHSVj1KDDpuoKHVMxS3bHN4NKTBiphHS6 otNQ== Received: by 10.50.185.195 with SMTP id fe3mr9881537igc.25.1352778931195; Mon, 12 Nov 2012 19:55:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Mon, 12 Nov 2012 19:54:49 -0800 (PST) In-Reply-To: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> From: Qiong Date: Tue, 13 Nov 2012 11:54:49 +0800 Message-ID: To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=14dae93408b9a74ffe04ce586366 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 03:55:34 -0000 --14dae93408b9a74ffe04ce586366 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole, On Sun, Nov 11, 2012 at 9:11 PM, Ole Tr=C3=B8an wrot= e: > Qiong, > > > Now that you need to optimize the implementation for different > requirements, why not optimize it from protocol level ? So that every > vendor would know how to implement for different requirements, rather tha= n > let operators pushing vendors one by one and tell them how to do. > > what is the difference in protocol? > [Qiong] I list some of the differences below: 1) In lw4over6, IPv6 address does not have IPv4-related semantics, while in MAP, IPv6 address has IPv4-related semantics (EA-bits) 2) In lw4over6, there is no need to import mapping rules, e.g. FMRs, etc., to CPEs, and there is no need for CPEs to understand the IPv6 prefix rule length, IPv4 prefix rule length, etc. 3) In lw4over6, lwAFTR can support dynamically creating, deleting, renewing, and maintaining these subscriber bindings. This will greatly reduce the configuration overload and trouble shooting. While in MAP, the BR and CE MUST be configured with the MAP elements (section 7 of draft-ietf-softwire-map). > are the bits on the wire between these two proposals different? > [Qiong] The two proposals not only define the "bits on the wire", but also the functionalities need to be supported in both CE/lwB4 and BR/lwAFTR. Best wishes Qiong > > cheers, > Ole --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --14dae93408b9a74ffe04ce586366 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole,


On Su= n, Nov 11, 2012 at 9:11 PM, Ole Tr=C3=B8an <otroan@employees.org>= ; wrote:
Qiong,

> Now that you need to optimize the implementation for different require= ments, why not optimize it from protocol level ? So that every vendor would= know how to implement for different requirements, rather than let operator= s pushing vendors one by one and tell them how to do.

what is the difference in protocol?
[Qiong] I li= st some of the differences below:
1) In lw4over6, IPv6 address does not = have IPv4-related semantics, while in MAP, IPv6 address has IPv4-related se= mantics (EA-bits)
2) In lw4over6, there is no need to import mapping rules, e.g. FMRs, etc., = to CPEs, and there is no need for CPEs to understand the IPv6 prefix rule l= ength, IPv4 prefix rule length, etc.
3) In lw4over6, lwAFTR can support = dynamically creating, deleting, renewing, and maintaining these subscriber = bindings. This will greatly reduce the configuration overload and trouble s= hooting. While in MAP, the BR and CE MUST be configured with the MAP elemen= ts (section 7 of draft-ietf-softwire-map).
=C2=A0
are the bits on the wire between these two proposals different?
[Qiong] The two proposals not only define the "bits on the w= ire", but also the functionalities need to be supported in both CE/lwB= 4 and BR/lwAFTR.

Best wishes
Qiong=C2=A0

cheers,
Ole



--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom= Beijing Research Institude


Open source code:
lightweight 4ov= er6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--14dae93408b9a74ffe04ce586366-- From bingxuere@gmail.com Mon Nov 12 19:57:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593D821F8895 for ; Mon, 12 Nov 2012 19:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzJmKHewiYpJ for ; Mon, 12 Nov 2012 19:57:48 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDEC21F8893 for ; Mon, 12 Nov 2012 19:57:48 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id j26so1018104iaf.31 for ; Mon, 12 Nov 2012 19:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=j+3ybOfUJt/BA9ZSt6FSqkiFE0Mp5HzipKeY40m+0Kk=; b=0Y92pLEptl1x9d3TmGzpNcdMcVF3spxInLX19CjYlbroxRucHcl5hWKJWAzSj7ScIH LbAAdyzWIuRlUtR5mK0S8B0NNRWFTjfEMkCmsnUnFe9OrzXSnWbhYlp6A/6MxSOCtfKy lKE8FaDjqoh0Arwft6qh3BQub5VPmzXwgjlQl1HF9MR6ljF/BHjDM1L549rZq1KOfY2q nHoQ8ACSwJtNWJel+BpXEb+t2NWhQB40ETHlNY4Wn+gWsZrcS9zSkUiByBY73swFGgD+ EciZa+eN2rZ/bIcFLGSGYxnhodK6XImhG0pqHVfbLkG9mrpYKkR5OMVQb/+l9qfCbH1V x6jQ== Received: by 10.50.187.134 with SMTP id fs6mr9771214igc.61.1352779068288; Mon, 12 Nov 2012 19:57:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Mon, 12 Nov 2012 19:57:07 -0800 (PST) In-Reply-To: References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> From: Qiong Date: Tue, 13 Nov 2012 11:57:07 +0800 Message-ID: To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=14dae9340747d32dea04ce586bd9 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 03:57:49 -0000 --14dae9340747d32dea04ce586bd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 agree. If there is no "mapping with addressing and port" at all, how can it still be called MAP anymore ? Best wishes Qiong On Tue, Nov 13, 2012 at 2:35 AM, Lee, Yiu wrote= : > Ole, > > From my perspective, the argument is not whether two protocols are > identical or not. I found MAP-E 1:1 is a stateful solution. I found it od= d > to make it part of MAP-E which was originally decided a stateless solutio= n. > > Regards, > Yiu > > On 11/11/12 8:11 AM, "Ole Tr=C3=B8an" wrote: > > >Qiong, > > > >> Now that you need to optimize the implementation for different > >>requirements, why not optimize it from protocol level ? So that every > >>vendor would know how to implement for different requirements, rather > >>than let operators pushing vendors one by one and tell them how to do. > > > >what is the difference in protocol? > >are the bits on the wire between these two proposals different? > > > >cheers, > >Ole > >_______________________________________________ > >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 > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --14dae9340747d32dea04ce586bd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 agree.

If there is no "mapping with addressing and port"= ; at all, how can it still be called MAP anymore ?

Best wishes
Q= iong


On Tu= e, Nov 13, 2012 at 2:35 AM, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Ole,

>From my perspective, the argument is not whether two protocols are
identical or not. I found MAP-E 1:1 is a stateful solution. I found it odd<= br> to make it part of MAP-E which was originally decided a stateless solution.=

Regards,
Yiu

On 11/11/12 8:11 AM, "Ole Tr=C3=B8an" <otroan@employees.org> wrote:

>Qiong,
>
>> Now that you need to optimize the implementation for different
>>requirements, why not optimize it from protocol level ? So that eve= ry
>>vendor would know how to implement for different requirements, rath= er
>>than let operators pushing vendors one by one and tell them how to = do.
>
>what is the difference in protocol?
>are the bits on the wire between these two proposals different?
>
>cheers,
>Ole
>___________________= ____________________________
>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




--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom= Beijing Research Institude


Open source code:
lightweight 4ov= er6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--14dae9340747d32dea04ce586bd9-- From sunqi.csnet.thu@gmail.com Mon Nov 12 20:56:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A4821F889C for ; Mon, 12 Nov 2012 20:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY6OsVlcehRy for ; Mon, 12 Nov 2012 20:56:35 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8099221F8895 for ; Mon, 12 Nov 2012 20:56:35 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so4971169pad.31 for ; Mon, 12 Nov 2012 20:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZpOt/k6VLfucPqlW4P/Osu5N0znUx147s3vOAk38FIo=; b=OLjwJDTe9bN3ag32R9vrJhMVGPrjDFN3jlt5HhCLDz2Yf2393klIt20B2A98e2WJrg bScoZpqi3uYG3yavyEahPRAV3amWVpecrQfr8lBcep41WuyuYna+vGtskhiSdD82fWcA 9BHJYU2w40Q53IisuXQMmxwN1DrbpZKlzRvPdGSiwsRTnbwM/nslqpZcJ/Fh0wJSLpSV UrwHEzqk1eebqVznOKAgQD7Q/i+InUgoGHPBd2JljYUQKI2R1FO0FaGed8U/4Qcup1K2 8LPXlpCczXIqqNOECcdBE8nX1NC/SDVns/XscxeqZ+jlm4d2aq+6DAT/oVpXPdVSfn28 zPhg== Received: by 10.66.78.67 with SMTP id z3mr61191798paw.33.1352782595348; Mon, 12 Nov 2012 20:56:35 -0800 (PST) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPS id nm2sm5337831pbc.43.2012.11.12.20.56.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 20:56:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Tue, 13 Nov 2012 12:56:28 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <22BBF2C9-F451-4FB7-BED5-13309EC69D40@gmail.com> References: To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 04:56:36 -0000 If you need to advertise summary routes (as in MAP-E), IPv4 and IPv6 = address are coupled, i.e. IPv4 info is embedded in IPv6 prefix. But for = advertising host routes (as in Lw4over6), IPv4 and IPv6 address are = decoupled, which is needed by many operators. IPv4 and IPv6 coupled or decoupled, that is not a deployment choice. BR, Qi Sun On 2012-11-13, at =E4=B8=8A=E5=8D=883:51, Rajiv Asati (rajiva) wrote: >=20 > Sure, and it is really a deployment choice (just like it is a = deployment > choice to use a dynamic routing protocol to advertise host routes or > summary routes or both in an IP network). But that's not to say that = we > need one protocol for advertising the host routes, and another for > advertising the summary routes. >=20 > Cheers, > Rajiv >=20 > -----Original Message----- > From: Yiu Lee > Date: Monday, November 12, 2012 1:33 PM > To: Rajiv Asati , Softwires-wg list = > Subject: Re: [Softwires] MAP-E 1:1 for HA >=20 >> I am not talking about whether a MAP-domain should support 1 or N = CEs. >> What I am trying to say is MAP-E 1:1 requires the BR to know per >> subscriber information and the operator must pre-provision = per-subscriber >> based rules to every BR in the same domain. In addition, the BR can't = use >> programatic logic to reduce states. When the WG first decided to work = on a >> "stateless" solution, the goal was to make BR as stateless as = possible. >> MAP-E 1:1 in contrast requires to store all subscriber rules in the = BR and >> can't derive the CE's IPv6 address using programatic logic. I found = it odd >> to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks = a >> stateful solution to me. >>=20 >>=20 >> On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" wrote: >>=20 >>>=20 >>> One can define a MAP-domain consisting of 1 CE or N CEs. This is = more of >>> a >>> deployment choice. >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>>=20 >>> -----Original Message----- >>> From: , Yiu Lee >>> Date: Friday, November 9, 2012 2:43 PM >>> To: Softwires-wg list >>> Subject: [Softwires] MAP-E 1:1 for HA >>>=20 >>>> I have a question for the HA design concept of MAP-E 1:1. The = central >>>> theme of MAP-E is to make BR as stateless as possible and use = Anycast >>>> address to identify the MAP-E BR. However, if we use MAP-E 1:1 = mode, the >>>> operator must have to pre-provision all >>>> the subscribe rules to all the BRs sharing the same Anycast address = for >>>> reliable HA. This requires operators to carefully plan out which = BRs >>>> support which subscribers. It is because BR is "per-subscriber = stateful" >>>> in MAP-E 1:1 mode. Compared to the MAP-E design, >>>> HA in MAP-E only requires the operators to use the same set of = rules to >>>> cover the entire domain. IMHO, this contradicts the original = spirit of >>>> stateless solution and always puzzles me why MAP-E 1:1 bears the = MAP-E >>>> name. MAP-E and 1:1 MAP-E are two completely >>>> different solutions and target to different deployment scenarios. I >>>> would love to hear others to comment in the ML how to resolve this >>>> issue. >>>>=20 >>>>=20 >>>> Thanks, >>>> Yiu >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Mon Nov 12 22:06:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A52321F889C for ; Mon, 12 Nov 2012 22:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt4PBceGR05L for ; Mon, 12 Nov 2012 22:06:41 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7DD21F8874 for ; Mon, 12 Nov 2012 22:06:41 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1525727pbc.31 for ; Mon, 12 Nov 2012 22:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yyhupfUeTk0cwhj3W3qo0sIlrAXQfIJeiHE1cBkv9Wo=; b=BGg3zswAzXbDH73l1MN6uMtTf0w9/+9uRbtmdgYFkvCRymKpIUJc6/8FhMoukJ7csk Di1aWdOhFBvl1PqT+F0ilJ8ICk0MDdYpXe02FfMn2p53BCIzp8fNM+YP5erHlbQj8uuQ U8wy4FuypdbwXC9WiaBtZSWeP3k0vnuIsZhBw03Ho4H+aC2bjHhhepWVqGLoPrxXovQa oNCut0uG86sgu9D+NOqBg4SBegbtKbbE99OP9PoOY/7cMEYj7f6ZgJK0MvPRptLIKQDA ppigRt/icu6WK6J8rKOAkMPyOXkjCfknzisfSn1kHQe5m121JSYy54FUqJzYkxeZJLN7 2Q9Q== Received: by 10.66.84.163 with SMTP id a3mr55719954paz.2.1352786800956; Mon, 12 Nov 2012 22:06:40 -0800 (PST) Received: from [10.201.82.124] ([202.45.12.141]) by mx.google.com with ESMTPS id qt3sm5442170pbb.32.2012.11.12.22.06.39 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 22:06:40 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Satoru Matsushima In-Reply-To: Date: Tue, 13 Nov 2012 15:06:38 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> To: Qiong X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 06:06:42 -0000 Qiong, On 2012/11/13, at 12:57, Qiong wrote: > +1 agree. >=20 > If there is no "mapping with addressing and port" at all, how can it = still be called MAP anymore ?=20 It is conventional naming. Even DS-Lite has mapping with address and = port. Please keep discussion constructively. --satoru From sunqi.csnet.thu@gmail.com Mon Nov 12 23:50:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1921F87EA for ; Mon, 12 Nov 2012 23:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaGbVwJleWF8 for ; Mon, 12 Nov 2012 23:50:43 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBED121F8857 for ; Mon, 12 Nov 2012 23:50:42 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1576143pbc.31 for ; Mon, 12 Nov 2012 23:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Nt+Y/FUaIvotJdY/W99nf6dyGh2dwehNM3NUk06D+2w=; b=SbC39fbP+Q4nTL33D/0wrTdsNd5cz7uhvI8e/4mV7a+CgvxqT74LFUSmSzePnuhLYe K8wm+p9Pqz3KG+JsTsr5kqjIxZGeFlORBgwSII4k6X8rAN32WsQYpaCwHkTDfI+qQTl5 5fUjyoo26jchDz+Hd3+AmqZwxb+0jQ0AiwApOORBjG5VECPShFlGnXbMt4yvjBiscaeZ qh7peSAQgUmXs5UoidK3MotGF8AXwBB5qvWiyquwZTBv2dn42X7FQ1KzVbKLesfcML9e 7+gdZuZ97q9P9lWeljBfo2vfdJFosI1gdi5BPsK2cl/kMLi994z3YSRg6DAVcHhGMRjB vvHw== Received: by 10.66.88.4 with SMTP id bc4mr62096056pab.42.1352793042717; Mon, 12 Nov 2012 23:50:42 -0800 (PST) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPS id bd2sm5708312pab.36.2012.11.12.23.50.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 23:50:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> Date: Tue, 13 Nov 2012 15:50:35 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 07:50:44 -0000 On 2012-11-13, at =E4=B8=8B=E5=8D=882:06, Satoru Matsushima wrote: > Qiong, >=20 > On 2012/11/13, at 12:57, Qiong wrote: >=20 >> +1 agree. >>=20 >> If there is no "mapping with addressing and port" at all, how can it = still be called MAP anymore ?=20 >=20 > It is conventional naming. Even DS-Lite has mapping with address and = port. Please keep discussion constructively. > --satoru [Qi] Would you specify which part in DS-Lite? >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From chenycmx@gmail.com Mon Nov 12 23:56:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E4321F88E0 for ; Mon, 12 Nov 2012 23:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.344 X-Spam-Level: X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2ysF+rI-k8O for ; Mon, 12 Nov 2012 23:56:53 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6511721F88DF for ; Mon, 12 Nov 2012 23:56:53 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1579308pbc.31 for ; Mon, 12 Nov 2012 23:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=GC4LnUOLd78gbXw8nUFBkElYY6FZs5FcFAV/Q/RQRmY=; b=VY+clCU14j8dNqmV84592LJRF2E8TchCe8Od9DxFdHTy3YPrU4F6ohPHPw3yIig/qs cvaG6iKwf3t1dtudaL67Mexd71HUTLwHR5udjpQZ1IUr+1Vgw71600mzFueai0RzVRB7 jyazwEv5Qnf/tiWTLZNR0zzOh7CIDHd+gfCw0+5nQJrJf18KHoGfB9iJZhNJc/m3qtF0 FHWgIP8hCj01VaNAsLRmC4LRHvBqFGqVENe7EXunklhYO59OPfp+ECMXLaD436PyOxDY qoUSpXNfEM2a/oqcq5bBHDkpnz5jLFBzwRhzU35Jue50WrEG9HAOZ9P1ivis8c02Ezbb VruA== Received: by 10.68.189.102 with SMTP id gh6mr58376724pbc.37.1352793413133; Mon, 12 Nov 2012 23:56:53 -0800 (PST) Received: from user-902eaffedc ([166.111.68.231]) by mx.google.com with ESMTPS id ay5sm5731917pab.1.2012.11.12.23.56.49 (version=SSLv3 cipher=OTHER); Mon, 12 Nov 2012 23:56:52 -0800 (PST) Date: Tue, 13 Nov 2012 15:56:47 -0500 From: "Yuchi Chen" To: "Satoru Matsushima" References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> X-Priority: 3 X-GUID: 93C1FAD9-79C9-49C9-B62B-9F087E88BBD4 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <2012111315564298406823@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart281031103332_=----" Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 07:56:54 -0000 This is a multi-part message in MIME format. ------=_001_NextPart281031103332_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgU2F0b3J1LA0KDQpJIHRoaW5rIHRoZSBtYWluIGlzc3VlIGhlcmUgaXMgbm90IGFib3V0ICJu YW1pbmciLCBidXQgYWJvdXQgdGhlIG9yaWdpbmFsIG1vdGl2YXRpb24gb2YgTUFQLiBBRkFJSyBN QVAgZHJhZnQgcHJvbW90ZXMgYSBzdGF0ZWxlc3MgcHJvdmlzaW9uaW5nIG1ldGhvZCB1c2luZyBt YXBwaW5nIHdpdGggYWRkcmVzcyBhbmQgcG9ydC4gQWx0aG91Z2ggdGhlIGFsZ29yaXRobSBNQVAg ZHJhZnQgcHJvbW90ZXMgaXMga2luZCBvZiBjb21wbGljYXRlZCBhbmQgY291cGxlcyB2NCBhbmQg djYgYWRkcmVzc2VzLCB3aGljaCBpbnRyb2R1Y2VzIGEgcG90ZW50aWFsIHRocmVhdCBvZiBmbGV4 aWJpbGl0eSwgYnV0IGl0J3Mgd2VsbCBkZXNpZ25lZCBhbmQgYmVhdXRpZnVsIGluZGVlZCBhbmQg bWFrZXMgTUFQIGF0dHJhY3RpdmUgdG8gdGhvc2Ugd2hvIHdhbnQgc3VjaCBhIHN0YXRlbGVzcyBz b2x1dGlvbi4gSWYgTUFQIHR1cm5zIG91dCBhIHN0YXRlZnVsIHNvbHV0aW9uIGluIDE6MSBtb2Rl IChubyBtYXR0ZXIgd2hhdCBraW5kIG9mIHN0YXRlIGl0J3MgbGlrZSksIEkgZG9uJ3QgdGhpbmsg aXQgd2lsbCBiZSBzbyBjaGFybWluZyB0byB0aGVzZSBwZW9wbGUgYW55IG1vcmUsIGFuZCBJIHRo aW5rIHBlb3BsZSB3aG8gd2FudHMgMToxIG1heSBwcmVmZXIgdG8gYW5vdGhlciBzb2x1dGlvbiB3 aGljaCBpcyBtdWNoIHNpbXBsZXIsIHNhdGlzZmllcyB0aGUgMToxIHNjZW5hcmlvIHdlbGwgYW5k IGRvZXMgbm90IGludHJvZHVjZSBhbnkgZmxleGliaWxpdHkgcHJvYmxlbS4gDQoNCkl0IHdpbGwg YmUgYXBwcmVjaWF0ZWQgaWYgeW91IHdvdWxkIHNvIGtpbmQgY2xhcmlmeSB0aGUgcmVhbCBtb3Rp dmF0aW9uIG9mIE1BUCwgYW5kIHRoZSBtZWFuaW5nIG9mICdtYXBwaW5nJyB5b3UgdXNlZCB0byBk ZXNjcmliZSB0aGUgRFMtTGl0ZSAod2hpY2ggaXMgYSB3ZWxsLWtub3duIHN0YXRlZnVsIHNvbHV0 aW9uKSBpZiBwb3NzaWJsZSwgYW5kIHRodXMgaXQgbWF5IGhlbHAgdXMga2VlcCBkaXNjdXNzaW9u IG1vcmUgY29uc3RydWN0aXZlbHkuDQoNCkJlc3QgcmVnYXJkcyENCg0KDQoNCll1Y2hpIENoZW4N Cg0KRnJvbTogU2F0b3J1IE1hdHN1c2hpbWENCkRhdGU6IDIwMTItMTEtMTMgMDE6MDYNClRvOiBR aW9uZw0KQ0M6IHNvZnR3aXJlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIE1B UC1FIDE6MSBmb3IgSEENClFpb25nLA0KDQpPbiAyMDEyLzExLzEzLCBhdCAxMjo1NywgUWlvbmcg PGJpbmd4dWVyZUBnbWFpbC5jb20+IHdyb3RlOg0KDQo+ICsxIGFncmVlLg0KPiANCj4gSWYgdGhl cmUgaXMgbm8gIm1hcHBpbmcgd2l0aCBhZGRyZXNzaW5nIGFuZCBwb3J0IiBhdCBhbGwsIGhvdyBj YW4gaXQgc3RpbGwgYmUgY2FsbGVkIE1BUCBhbnltb3JlID8gDQoNCkl0IGlzIGNvbnZlbnRpb25h bCBuYW1pbmcuIEV2ZW4gRFMtTGl0ZSBoYXMgbWFwcGluZyB3aXRoIGFkZHJlc3MgYW5kIHBvcnQu IFBsZWFzZSBrZWVwIGRpc2N1c3Npb24gY29uc3RydWN0aXZlbHkuDQotLXNhdG9ydQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1h aWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NvZnR3aXJlcw== ------=_001_NextPart281031103332_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Satoru,
 
I think the main issue here is not about "naming", but about the= =20 original motivation of MAP. AFAIK MAP draft promotes a stateless=20 provisioning method using mapping with address and port. Although the algo= rithm=20 MAP draft promotes is kind of complicated and couples v4 and v6=20 addresses, which introduces a potential threat of flexibility, but it's we= ll=20 designed and beautiful indeed and makes MAP attractive to those who want=20 such a stateless solution. If MAP turns out a stateful solution in 1:= 1 mode=20 (no matter what kind of state it's like), I don't think it will be so char= ming=20 to these people any more, and I think people who wants 1:1 may prefer= to=20 another solution which is much simpler, satisfies the=20 1:1 scenario well and does not introduce any=20 flexibility problem.
 
It will be appreciated if you would so kind clarify the real=20 motivation of MAP, and the meaning of 'mapping' you used to desc= ribe=20 the DS-Lite (which is a well-known stateful solution) if possible, an= d thus=20 it may help us keep discussion more constructively.
 
Best regards!
Yuchi Chen
 
Date: 2012-11-13 01:06
To: Qiong
CC: softwires@ietf.org
Subject: Re: [Softwires] MAP-E 1:1 for HA
Qiong,
 
On 2012/11/13, at 12:57, Qiong <bingxuere= @gmail.com> wrote:
 
> +1 agree.
> 
> If there is no "mapping with = addressing and port" at all, how can it=  still be called MAP anymore ? 
 
It is conventional naming. Even DS-Lite = ;has mapping with address and port. Please&n= bsp;keep discussion constructively.
--satoru
 
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart281031103332_=------ From leaf.y.yeh@huawei.com Tue Nov 13 00:01:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AC521F88C7 for ; Tue, 13 Nov 2012 00:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtUejUw1aGUn for ; Tue, 13 Nov 2012 00:01:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 43D9021F884C for ; Tue, 13 Nov 2012 00:01:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT17980; Tue, 13 Nov 2012 08:01:47 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 08:01:37 +0000 Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 08:01:45 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml462-hub.china.huawei.com ([10.82.67.205]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 16:01:41 +0800 From: Leaf yeh To: Satoru Matsushima , Qiong Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNvrJUhwE7DtDnmkmwZYkUbhoBV5fhxXmAgAAoJQCAACy1AIABU7oAgACqiwCAAezPAIAAnP2AgAAkMACAAJ5q0A== Date: Tue, 13 Nov 2012 08:01:41 +0000 Message-ID: References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> In-Reply-To: <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:01:49 -0000 I guess '4over6' sounds a better name for the solution whether it has IPv6(= A) mapping for IPv4(A+P) or not. Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Satoru Matsushima Sent: Tuesday, November 13, 2012 2:07 PM To: Qiong Cc: softwires@ietf.org Subject: Re: [Softwires] MAP-E 1:1 for HA Qiong, On 2012/11/13, at 12:57, Qiong wrote: > +1 agree. >=20 > If there is no "mapping with addressing and port" at all, how can it stil= l be called MAP anymore ?=20 It is conventional naming. Even DS-Lite has mapping with address and port. = Please keep discussion constructively. --satoru _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Tue Nov 13 00:45:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F9F21F8488 for ; Tue, 13 Nov 2012 00:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBYaxOkDTsqA for ; Tue, 13 Nov 2012 00:45:17 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB3D321F847C for ; Tue, 13 Nov 2012 00:45:10 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so5080800pad.31 for ; Tue, 13 Nov 2012 00:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=6gc8Q1r8SHzJa8Agn19TmM9OAfYttobUFtuBRZ8Tm8A=; b=sPXH3J11RneRgFq2Xh5MuZTaNE44d+karq3TYzH83teXW8yGV80uDawew6bFOC1jfE i33v4qYKRC+16hG0rTjw90bd+tjzLFrgaIWyilRiiis5iE+zSIsJcMEwVtSyWMWnx/4k hkrBMw5PVriWcPp7TWCrtdvFe5WZuGXp9QcP05hHfagb1tB8BPNdeHbUUrKGYv+dmNiZ tCPHYCghgdxOwalrQNKIJ31ubnPXVa0Umg8xK5+4qqoDuuvmFrep+zuKvdRmNkoPDPbh 6FIrJz/vs51Je09Dx21zOyPiC3+SgfM/HFXHjYgxANGUOF6FeIWfYZb35QC9GAbtPom7 h6EQ== Received: by 10.66.77.199 with SMTP id u7mr62528402paw.7.1352796309611; Tue, 13 Nov 2012 00:45:09 -0800 (PST) Received: from [10.201.82.124] ([202.45.12.141]) by mx.google.com with ESMTPS id l5sm3294936paz.14.2012.11.13.00.45.03 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 00:45:09 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=GB2312 From: Satoru Matsushima X-Priority: 3 In-Reply-To: <2012111315564298406823@gmail.com> Date: Tue, 13 Nov 2012 17:45:00 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com> To: chenycmx X-Mailer: Apple Mail (2.1499) Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:45:18 -0000 Hi Yuchi, On 2012/11/14, at 5:56, "Yuchi Chen" wrote: > Hi Satoru, > =20 > I think the main issue here is not about "naming", but about the = original motivation of MAP. AFAIK MAP draft promotes a stateless = provisioning method using mapping with address and port. Although the = algorithm MAP draft promotes is kind of complicated and couples v4 and = v6 addresses, which introduces a potential threat of flexibility, MAP introduce complication and flixibility threat!? Not at all. So then, could you answer how much complicated is complicated, and how = much flexibility do you need? > but it's well designed and beautiful indeed and makes MAP attractive = to those who want such a stateless solution. If MAP turns out a stateful = solution in 1:1 mode (no matter what kind of state it's like), I don't = think it will be so charming to these people any more, and I think = people who wants 1:1 may prefer to another solution which is much = simpler, satisfies the 1:1 scenario well and does not introduce any = flexibility problem. Why 1:1 is stateful? I'm not clear where is the threshold to distinguish stateful and = stateless? N=3D2, 3, or 4??? > =20 > It will be appreciated if you would so kind clarify the real = motivation of MAP, and the meaning of 'mapping' you used to describe the = DS-Lite (which is a well-known stateful solution) if possible, and thus = it may help us keep discussion more constructively. > =20 Doesn't AFTR maintain mapping of remote IPv6 endpoint address with IPv4 = address and port? cheers, --satoru From bingxuere@gmail.com Tue Nov 13 01:06:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7556C21F8653 for ; Tue, 13 Nov 2012 01:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbfZQkEo1CHG for ; Tue, 13 Nov 2012 01:06:17 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF50E21F8676 for ; Tue, 13 Nov 2012 01:06:15 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so11474888iec.31 for ; Tue, 13 Nov 2012 01:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=peiQGBKlIji89TyYVG5x6ATJnNYx6DERspaoYyIs2Nw=; b=MGexJH/VteaDe+R6VbqW8nN4/dXPFsivwzAlKY4tMgh9/CUPIORaqyse2IY8EgOIPe ZSJp+vkqkH3QuMZ+zdYDKAXYquUvvetyepOWHU5rC/3ptC8jcpVjE4sYYahC2bdMId5E htF+xmuZegzacxxJHixYFjJYUtctgJeY7TlwG/Ed8B5DOu6/CxEcWRQgEZDKwWgt4saR FSnTkWTTy9wZU0GzHSptvBqGyFoTyu6DruB3m8HTxKagT/XKAbk9JOu0X2wMhHBdzzKq BmAPLfC6UZzI0EqahLcvh8p3/oNLlYoqpAT3SYZRrWdbA+ddIwi3UR7J38nlnFqex2NQ czOg== Received: by 10.50.152.194 with SMTP id va2mr10393903igb.25.1352797573373; Tue, 13 Nov 2012 01:06:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Tue, 13 Nov 2012 01:05:33 -0800 (PST) In-Reply-To: References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> From: Qiong Date: Tue, 13 Nov 2012 17:05:33 +0800 Message-ID: To: Leaf yeh Content-Type: multipart/alternative; boundary=e89a8f3b9de9d0605c04ce5cbab0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:06:21 -0000 --e89a8f3b9de9d0605c04ce5cbab0 Content-Type: text/plain; charset=UTF-8 Exactly! '4over6' indicates v4 address and v6 address is decoupled... Best wishes Qiong On Tue, Nov 13, 2012 at 4:01 PM, Leaf yeh wrote: > I guess '4over6' sounds a better name for the solution whether it has > IPv6(A) mapping for IPv4(A+P) or not. > > > Best Regards, > Leaf > > > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Satoru Matsushima > Sent: Tuesday, November 13, 2012 2:07 PM > To: Qiong > Cc: softwires@ietf.org > Subject: Re: [Softwires] MAP-E 1:1 for HA > > Qiong, > > On 2012/11/13, at 12:57, Qiong wrote: > > > +1 agree. > > > > If there is no "mapping with addressing and port" at all, how can it > still be called MAP anymore ? > > It is conventional naming. Even DS-Lite has mapping with address and port. > Please keep discussion constructively. > --satoru > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --e89a8f3b9de9d0605c04ce5cbab0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Exactly!=C2=A0 '4over6' indicates v4 address and v6 address is deco= upled...

Best wishes
Qiong

On Tue, Nov 13, 2012 at 4:01 PM, Leaf yeh <leaf.y.yeh@huawei.com> wrote:
I guess '4over6' sounds a better nam= e for the solution whether it has IPv6(A) mapping for IPv4(A+P) or not.


Best Regards,
Leaf


-----Original Message-----
From: softwires-bounces@ietf.= org [mailto:softwires-bou= nces@ietf.org] On Behalf Of Satoru Matsushima
Sent: Tuesday, November 13, 2012 2:07 PM
To: Qiong
Cc: softwires@ietf.org
Subject: Re: [Softwires] MAP-E 1:1 for HA

Qiong,

On 2012/11/13, at 12:57, Qiong <b= ingxuere@gmail.com> wrote:

> +1 agree.
>
> If there is no "mapping with addressing and port" at all, ho= w can it still be called MAP anymore ?

It is conventional naming. Even DS-Lite has mapping with address and port. = Please keep discussion constructively.
--satoru

_______________________= ________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires



--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--e89a8f3b9de9d0605c04ce5cbab0-- From satoru.matsushima@gmail.com Tue Nov 13 01:09:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8035D21F8678 for ; Tue, 13 Nov 2012 01:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcsPHL-fUK3N for ; Tue, 13 Nov 2012 01:09:49 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id C897B21F8676 for ; Tue, 13 Nov 2012 01:09:49 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so5093866pad.31 for ; Tue, 13 Nov 2012 01:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HV7VZyTkxGGv6nJUZ1UoBzPMq91AFeNDcnc6+IsjfOw=; b=HggtcD6hUHa+g39x9PTs3pHtxFe34gth6Y+Dkw9dKfuDxMVXf7+JaoUKS16sObw5uF fZ1xsBN2tq8Prik4q19/+t5Exp5kScLYLhBitYeP47tN4CAszKyCGqLl1KN0AyZSqX3D TdEdBtMNX2g0k6yfYUEepwut5w6HV6ojMdCdrQvfB1L1P7NVB6XsvWpi757IftHc3W0i HQ4hYydD/V+2X8/rXg9djM0n9CvvrHkgxL9H7jHDE6kECO3A1SLie/LUusPB9H63pSQA 4f+wCenosqlFmW+ExMS6RK276J7VLmxmy9yH/cVjvt23pq+Gp6H3hjVGKreGrPWX4swz u53Q== Received: by 10.68.137.234 with SMTP id ql10mr58828513pbb.158.1352797789121; Tue, 13 Nov 2012 01:09:49 -0800 (PST) Received: from [10.201.82.124] ([202.45.12.141]) by mx.google.com with ESMTPS id jw14sm5681207pbb.36.2012.11.13.01.09.46 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 01:09:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Satoru Matsushima In-Reply-To: Date: Tue, 13 Nov 2012 18:09:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9F713001-C330-4349-9F2E-CE7237E6B0BF@gmail.com> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> To: Leaf yeh X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:09:50 -0000 On 2012/11/13, at 17:01, Leaf yeh wrote: > I guess '4over6' sounds a better name for the solution whether it has = IPv6(A) mapping for IPv4(A+P) or not. >=20 >=20 Do you suggest DS-Lite should change its name to 4over6 too? --satoru > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Satoru Matsushima > Sent: Tuesday, November 13, 2012 2:07 PM > To: Qiong > Cc: softwires@ietf.org > Subject: Re: [Softwires] MAP-E 1:1 for HA >=20 > Qiong, >=20 > On 2012/11/13, at 12:57, Qiong wrote: >=20 >> +1 agree. >>=20 >> If there is no "mapping with addressing and port" at all, how can it = still be called MAP anymore ?=20 >=20 > It is conventional naming. Even DS-Lite has mapping with address and = port. Please keep discussion constructively. > --satoru >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From leaf.y.yeh@huawei.com Tue Nov 13 01:26:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62C721F861D for ; Tue, 13 Nov 2012 01:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVGm+qyDaqlZ for ; Tue, 13 Nov 2012 01:26:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4C21F84DA for ; Tue, 13 Nov 2012 01:26:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT26111; Tue, 13 Nov 2012 09:26:13 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 09:26:04 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Nov 2012 09:26:12 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 17:26:06 +0800 From: Leaf yeh To: Satoru Matsushima Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNvrJUhwE7DtDnmkmwZYkUbhoBV5fhxXmAgAAoJQCAACy1AIABU7oAgACqiwCAAezPAIAAnP2AgAAkMACAAJ5q0P//lMKAgACGaqA= Date: Tue, 13 Nov 2012 09:26:06 +0000 Message-ID: References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <9F713001-C330-4349-9F2E-CE7237E6B0BF@gmail.com> In-Reply-To: <9F713001-C330-4349-9F2E-CE7237E6B0BF@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:26:17 -0000 '4over6' could be DS-Lite 2.0, which may also embrace MAP-E; '4via6' could= be a better name for MAP-T in the same logic below. :-) Best Regards, Leaf -----Original Message----- From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com]=20 Sent: Tuesday, November 13, 2012 5:10 PM To: Leaf yeh Cc: Satoru Matsushima; Qiong; softwires@ietf.org Subject: Re: [Softwires] MAP-E 1:1 for HA On 2012/11/13, at 17:01, Leaf yeh wrote: > I guess '4over6' sounds a better name for the solution whether it has IPv= 6(A) mapping for IPv4(A+P) or not. >=20 >=20 Do you suggest DS-Lite should change its name to 4over6 too? --satoru > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Satoru Matsushima > Sent: Tuesday, November 13, 2012 2:07 PM > To: Qiong > Cc: softwires@ietf.org > Subject: Re: [Softwires] MAP-E 1:1 for HA >=20 > Qiong, >=20 > On 2012/11/13, at 12:57, Qiong wrote: >=20 >> +1 agree. >>=20 >> If there is no "mapping with addressing and port" at all, how can it sti= ll be called MAP anymore ?=20 >=20 > It is conventional naming. Even DS-Lite has mapping with address and port= . Please keep discussion constructively. > --satoru >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Tue Nov 13 01:31:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5058D21F8496 for ; Tue, 13 Nov 2012 01:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2e7YfU8rg9H for ; Tue, 13 Nov 2012 01:31:49 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98FB621F8624 for ; Tue, 13 Nov 2012 01:31:42 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so5104836pad.31 for ; Tue, 13 Nov 2012 01:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vw/c4gqp9nRLKwunKIFAL6eEPFMHIn0QwztgYG8Wd9c=; b=0GCCbUU1BWQA+Sot6djy/B2Xju9bC9yVYaqJ2WiNUmIa2qy5tOIDpXz+ITrohp8tid 7yFzEyr9IvBlS+kteHFoXFty6FenqDk92Zv+uh2CmiChQ72VT390/na8rYoGQdAjbv+h qRMMyaEcfKZJBdlnDrokiQo6xvvgzKWhoCMLMRRNrrNNxDPHJyUkvUfydp1Vk6hBardH ST6k354oWqJ0ZqtVsidz0KVV4RBmmuTIv0lDBvfTeOTNtlj9SkM/qV1xvVML1KwWnBCL pvuROURil7nzbSLQMQjmlbdDG0R2pf+czyFOC20RIX4oDMVD01kGOMh7raEdvWzFWg+G tlWA== Received: by 10.66.81.138 with SMTP id a10mr62767577pay.53.1352799100602; Tue, 13 Nov 2012 01:31:40 -0800 (PST) Received: from [10.201.82.124] ([202.45.12.141]) by mx.google.com with ESMTPS id ku7sm5715910pbc.0.2012.11.13.01.31.37 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 01:31:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Satoru Matsushima In-Reply-To: Date: Tue, 13 Nov 2012 18:31:40 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6D2C5479-4FD8-4864-BCED-12D53D4E419C@gmail.com> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <9F713001-C330-4349-9F2E-CE7237E6B0BF@gmail.com> To: Leaf yeh X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:31:50 -0000 On 2012/11/13, at 18:26, Leaf yeh wrote: > '4over6' could be DS-Lite 2.0, which may also embrace MAP-E; '4via6' = could be a better name for MAP-T in the same logic below. :-) >=20 You may write a draft to propose it. ;) --satoru >=20 > Best Regards, > Leaf >=20 >=20 > -----Original Message----- > From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com]=20 > Sent: Tuesday, November 13, 2012 5:10 PM > To: Leaf yeh > Cc: Satoru Matsushima; Qiong; softwires@ietf.org > Subject: Re: [Softwires] MAP-E 1:1 for HA >=20 > On 2012/11/13, at 17:01, Leaf yeh wrote: >=20 >> I guess '4over6' sounds a better name for the solution whether it has = IPv6(A) mapping for IPv4(A+P) or not. >>=20 >>=20 >=20 > Do you suggest DS-Lite should change its name to 4over6 too? > --satoru >=20 >=20 >> Best Regards, >> Leaf >>=20 >>=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Satoru Matsushima >> Sent: Tuesday, November 13, 2012 2:07 PM >> To: Qiong >> Cc: softwires@ietf.org >> Subject: Re: [Softwires] MAP-E 1:1 for HA >>=20 >> Qiong, >>=20 >> On 2012/11/13, at 12:57, Qiong wrote: >>=20 >>> +1 agree. >>>=20 >>> If there is no "mapping with addressing and port" at all, how can it = still be called MAP anymore ?=20 >>=20 >> It is conventional naming. Even DS-Lite has mapping with address and = port. Please keep discussion constructively. >> --satoru >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From chenycmx@gmail.com Tue Nov 13 05:15:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17121F84E4 for ; Tue, 13 Nov 2012 05:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DATE_IN_FUTURE_12_24=2.189, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCv1lr2VrOVV for ; Tue, 13 Nov 2012 05:15:44 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45B9021F8455 for ; Tue, 13 Nov 2012 05:15:39 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so3302166dan.31 for ; Tue, 13 Nov 2012 05:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type :content-transfer-encoding; bh=7KFvhnqGPv3W26e2NVAsMB6kgyRjWYanLBfAXt41wnM=; b=RfQx5sFOAVzrXcy/OP1/t5SRwguqhnYXqw9c325REzWrpsfp+nKPDj8j8myW54KqhO i4r7+jlmAO9pAXPBQkpQq8gE8Z0bgVb7n2PTIQ0jIL4cXBjU6YglNPoMu3/6bQMxfacq qnDA6ECg/Vgu4FjDmCtGhZyWG5L5yF/5ryqGKjtSaH2qG4M+GvTnXj2e+M74Zwpi8LiV tYO2zdQTQ+iTVLBja66nRQVKaMSDWgIZjEDcaGdMQW0RSfvW50qLYP51Sxqhye32ozN3 8azjEK1RS9S1SKPefGCBROuYVpnl7VKPVhmS3qcdgs9Bo/G1v8DHOuGkclvcjYS+R/wl CJIw== Received: by 10.69.0.40 with SMTP id av8mr67541865pbd.117.1352812537711; Tue, 13 Nov 2012 05:15:37 -0800 (PST) Received: from user-902eaffedc ([166.111.68.233]) by mx.google.com with ESMTPS id xk2sm5959159pbc.45.2012.11.13.05.15.34 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 05:15:37 -0800 (PST) Date: Tue, 13 Nov 2012 21:15:31 -0500 From: "Yuchi Chen" To: "Satoru Matsushima" References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com>, <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> X-Priority: 3 X-GUID: C0573AD9-54E8-4784-BED7-EE5EB3A8C716 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <2012111321152612549156@gmail.com> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 13:15:44 -0000 SGkgU2F0b3J1LA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQmVzdCByZWdhcmRzIQ0KLS0tLS0t LS0tLS0tLS0NCll1Y2hpIENoZW4NCj5IaSBZdWNoaSwNCj4NCj5PbiAyMDEyLzExLzE0LCBhdCA1 OjU2LCAiWXVjaGkgQ2hlbiIgPGNoZW55Y214QGdtYWlsLmNvbT4gd3JvdGU6DQo+DQo+PiBIaSBT YXRvcnUsDQo+PiAgDQo+PiBJIHRoaW5rIHRoZSBtYWluIGlzc3VlIGhlcmUgaXMgbm90IGFib3V0 ICJuYW1pbmciLCBidXQgYWJvdXQgdGhlIG9yaWdpbmFsIG1vdGl2YXRpb24gb2YgTUFQLiBBRkFJ SyBNQVAgZHJhZnQgcHJvbW90ZXMgYSBzdGF0ZWxlc3MgcHJvdmlzaW9uaW5nIG1ldGhvZCB1c2lu ZyBtYXBwaW5nIHdpdGggYWRkcmVzcyBhbmQgcG9ydC4gQWx0aG91Z2ggdGhlIGFsZ29yaXRobSBN QVAgZHJhZnQgcHJvbW90ZXMgaXMga2luZCBvZiBjb21wbGljYXRlZCBhbmQgY291cGxlcyB2NCBh bmQgdjYgYWRkcmVzc2VzLCB3aGljaCBpbnRyb2R1Y2VzIGEgcG90ZW50aWFsIHRocmVhdCBvZiBm bGV4aWJpbGl0eSwNCj4NCj5NQVAgaW50cm9kdWNlIGNvbXBsaWNhdGlvbiBhbmQgZmxpeGliaWxp dHkgdGhyZWF0IT8gTm90IGF0IGFsbC4NCj5TbyB0aGVuLCBjb3VsZCB5b3UgYW5zd2VyIGhvdyBt dWNoIGNvbXBsaWNhdGVkIGlzIGNvbXBsaWNhdGVkLCBhbmQgaG93IG11Y2ggZmxleGliaWxpdHkg ZG8geW91IG5lZWQ/DQo+DQpbWXVjaGldIEkgZG9uJ3QgdGhpbmsgdGhlIGRpc2N1c3Npb24gb24g ZGVmaW5pdGlvbnMgb3IgZGVncmVlcyBvZiAnY29tcGxpY2F0ZWQnIGFuZCAnZmxleGliaWxpdHkn IGlzIHNvIGNvbnN0cnVjdGl2ZSwgYW5kIEkgZG9uJ3QgdGhpbmsgaXQgd2lsbCBtYWtlIGFueSBz ZW5zZSBoZXJlLg0KDQo+PiBidXQgaXQncyB3ZWxsIGRlc2lnbmVkIGFuZCBiZWF1dGlmdWwgaW5k ZWVkIGFuZCBtYWtlcyBNQVAgYXR0cmFjdGl2ZSB0byB0aG9zZSB3aG8gd2FudCBzdWNoIGEgc3Rh dGVsZXNzIHNvbHV0aW9uLiBJZiBNQVAgdHVybnMgb3V0IGEgc3RhdGVmdWwgc29sdXRpb24gaW4g MToxIG1vZGUgKG5vIG1hdHRlciB3aGF0IGtpbmQgb2Ygc3RhdGUgaXQncyBsaWtlKSwgSSBkb24n dCB0aGluayBpdCB3aWxsIGJlIHNvIGNoYXJtaW5nIHRvIHRoZXNlIHBlb3BsZSBhbnkgbW9yZSwg YW5kIEkgdGhpbmsgcGVvcGxlIHdobyB3YW50cyAxOjEgbWF5IHByZWZlciB0byBhbm90aGVyIHNv bHV0aW9uIHdoaWNoIGlzIG11Y2ggc2ltcGxlciwgc2F0aXNmaWVzIHRoZSAxOjEgc2NlbmFyaW8g d2VsbCBhbmQgZG9lcyBub3QgaW50cm9kdWNlIGFueSBmbGV4aWJpbGl0eSBwcm9ibGVtLg0KPg0K PldoeSAxOjEgaXMgc3RhdGVmdWw/DQo+SSdtIG5vdCBjbGVhciB3aGVyZSBpcyB0aGUgdGhyZXNo b2xkIHRvIGRpc3Rpbmd1aXNoIHN0YXRlZnVsIGFuZCBzdGF0ZWxlc3M/IE49MiwgMywgb3IgND8/ Pw0KPg0KW1l1Y2hpXSBJIGJlbGlldmUgdGhhdCB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiBzdGF0 ZWZ1bCBhbmQgc3RhdGVsZXNzIGFyZSB3ZWxsIGRpc2N1c3NlZCBpbiB0aGUgcHJldmlvdXMgZGlz Y3Vzc2lvbnMuIFRoZSBwb2ludCBJIHdhbnQgdG8gZmlndXJlIG91dCBoZXJlIGlzIHRoYXQgTUFQ IDE6MSBtb2RlIGlzIG5vdCBzbyAnc3RhdGVsZXNzJyBhcyBvdGhlciBwYXJ0cyBvZiBNQVAtRS4g DQoNCj4+ICANCj4+IEl0IHdpbGwgYmUgYXBwcmVjaWF0ZWQgaWYgeW91IHdvdWxkIHNvIGtpbmQg Y2xhcmlmeSB0aGUgcmVhbCBtb3RpdmF0aW9uIG9mIE1BUCwgYW5kIHRoZSBtZWFuaW5nIG9mICdt YXBwaW5nJyB5b3UgdXNlZCB0byBkZXNjcmliZSB0aGUgRFMtTGl0ZSAod2hpY2ggaXMgYSB3ZWxs LWtub3duIHN0YXRlZnVsIHNvbHV0aW9uKSBpZiBwb3NzaWJsZSwgYW5kIHRodXMgaXQgbWF5IGhl bHAgdXMga2VlcCBkaXNjdXNzaW9uIG1vcmUgY29uc3RydWN0aXZlbHkuDQo+PiAgDQo+DQo+RG9l c24ndCBBRlRSIG1haW50YWluIG1hcHBpbmcgb2YgcmVtb3RlIElQdjYgZW5kcG9pbnQgYWRkcmVz cyB3aXRoIElQdjQgYWRkcmVzcyBhbmQgcG9ydD8NCj4gDQpbWXVjaGldIEFjdHVhbGx5IHRoZXJl IGlzIGEgJ2JpbmRpbmcnIHRhYmxlIG9uIHRoZSBBRlRSLCB3aGljaCBtYWludGFpbnMgbWF0Y2hp bmcgYmV0d2VlbiB2NCBBK1AgYW5kIHY2IEEsIGFuZCB0aGVyZSdzIG5vICdtYXBwaW5nIHdpdGgg YWRkcmVzcyBhbmQgcG9ydCcgaW4gRFMtTGl0ZSBvciBMdzRvdmVyNiBhcyBpbiBNQVAuIFRoZSBt YWluIHBvaW50IGhlcmUgaXMgbm90IGFib3V0IHRoZSBsaXRlcmFsIGRpZmZlcmVuY2UgYmV0d2Vl biAnYmluZGluZycgYW5kICdtYXBwaW5nJywgYnV0IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gZGVj b3VwbGluZyB2NCAmIHY2IGFuZCBjb3VwbGluZyB2NCAmIHY2Lg0KDQo+Y2hlZXJzLA0KPi0tc2F0 b3J1DQo+ From otroan@employees.org Tue Nov 13 05:46:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0914321F85E1 for ; Tue, 13 Nov 2012 05:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjvFoE+BjniN for ; Tue, 13 Nov 2012 05:46:08 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD9321F85DB for ; Tue, 13 Nov 2012 05:46:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAINNolCQ/khL/2dsb2JhbABEwDCDRoEIgh8BAQQSARQTPxAFBkZXBiQRh2iZeY9lkDCSFGEDpFSBa4Jw X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="9542691" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 13 Nov 2012 13:46:04 +0000 Received: from dhcp-lys01-vla250-10-147-112-107.cisco.com (dhcp-lys01-vla250-10-147-112-107.cisco.com [10.147.112.107]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qADDk3pl018919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Nov 2012 13:46:04 GMT Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Priority: 3 In-Reply-To: <2012111321152612549156@gmail.com> Date: Tue, 13 Nov 2012 14:46:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com>, <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com> To: chenycmx X-Mailer: Apple Mail (2.1499) Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 13:46:09 -0000 > [Yuchi] Actually there is a 'binding' table on the AFTR, which = maintains matching between v4 A+P and v6 A, and there's no 'mapping with = address and port' in DS-Lite or Lw4over6 as in MAP. The main point here = is not about the literal difference between 'binding' and 'mapping', but = the difference between decoupling v4 & v6 and coupling v4 & v6. let us assume we have a 1.1.1.0/24 for address sharing available with = 256 ports per user. in MAP 1:1 you'd have: 1.1.1.1:01/40 -> 2001:db8::1 1.1.1.1:02/40 -> 2001:db8::2 1.1.1.1:03/40 -> 2001:db8::3 . . . 64K rules. in MAP aggregated mode you have: 1.1.1.0/24 -> 2001:db8:XXXX::/48 can you please show how the LW46 rules / binding /mapping whatever you = call them look like for 1:1 mode? cheers, Ole From internet-drafts@ietf.org Tue Nov 13 05:53:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E23721F8644; Tue, 13 Nov 2012 05:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fian9x1x8K9; Tue, 13 Nov 2012 05:53:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFDE21F85DB; Tue, 13 Nov 2012 05:53:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121113135305.23819.77189.idtracker@ietfa.amsl.com> Date: Tue, 13 Nov 2012 05:53:05 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 13:53:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Motivations for Carrier-side Stateless IPv4 over IPv6 Mi= gration Solutions Author(s) : Mohamed Boucadair Satoru Matsushima Yiu Lee Olaf Bonness Isabel Borges Gang Chen Filename : draft-ietf-softwire-stateless-4v6-motivation-05.txt Pages : 15 Date : 2012-11-13 Abstract: IPv4 service continuity is one of the most pressing problems that must be resolved by Service Providers during the IPv6 transition period - especially after the exhaustion of the public IPv4 address space. Current standardization effort that addresses IPv4 service continuity focuses on stateful mechanisms. This document elaborates on the motivations for the need to undertake a companion effort to specify stateless IPv4 over IPv6 approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivati= on There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateless-4v6-motiva= tion-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From chenycmx@gmail.com Tue Nov 13 07:29:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275A421F85DB for ; Tue, 13 Nov 2012 07:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dqeaGnj7bgR for ; Tue, 13 Nov 2012 07:29:49 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6027221F85D9 for ; Tue, 13 Nov 2012 07:29:48 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so3346798dan.31 for ; Tue, 13 Nov 2012 07:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=/XQxmc7qXGL8IAnXFfjR9HRAxxX8U18syggFJfePjkI=; b=jpSZ0CHTc2aBJAvlGBZEGQsmu8DorPrI8zK9RIvHTMDS6xstXu3SuQEI2JPZ+agK0P MY+2+WImXLz98Y66l0zia3Sr+PyPjrfVjDS052bZZKF0z1g0WANRmH8/j9Ar7xtKk86u dWo2WcxvNgjAV0Bc0pGPx/ztM69MhgfGF8eaA2gKq1EegGgpB96wK/MqSWAyCmj0sx5+ 3z8O20FdA3lAItWbpA2cqvvc840XxR6OLQ4wyd4/Ru6x7CmN1cCoaUCbTNgQ9BFaCIhw Km+k1jbm+3hQkPeR7snh6d6BC4P0Em6kz80ZTXbsRj/+RQbVwWN/UMmizfdWUFRr8u92 sjPA== Received: by 10.68.189.138 with SMTP id gi10mr7970046pbc.165.1352820586562; Tue, 13 Nov 2012 07:29:46 -0800 (PST) Received: from user-902eaffedc ([114.255.41.145]) by mx.google.com with ESMTPS id x8sm6260048paw.16.2012.11.13.07.29.42 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 07:29:45 -0800 (PST) Date: Tue, 13 Nov 2012 23:29:35 +0800 From: "Yuchi Chen" To: =?utf-8?B?T2xlIFRyw7hhbg==?= References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com>, <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com>, <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> X-Priority: 3 X-GUID: 437ED216-4629-44CE-A78E-3C8076780DBE X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <2012111323293100042378@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart386138141364_=----" Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:29:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart386138141364_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT2xlLA0KDQpJJ20gbm90IHNvIHN1cmUgd2hhdCB5b3Ugd2FudCB0byBwb2ludCBvdXQgd2l0 aCB0aGUgZXhhbXBsZS4gT2YgY291cnNlIEkgY2FuIHNob3cgYW4gZXhhbXBsZSBvZiBiaW5kaW5n IHRhYmxlIG9uIHRoZSBBRlRSLCBidXQgSSB3b25kZXIgd2h5IGFuZCB3aGF0IGNhbiBiZSBhY2hp ZXZlZCB0byBkbyB0aGF0IGhlcmUuIFRoZSBxdW90ZSB5b3UgbWFkZSBpcyBqdXN0IHRyeWluZyB0 byBmaWd1cmUgb3V0IHRoYXQgdGhlIG5vdGlvbiBvZiAnbWFwcGluZycgaW4gTUFQIGlzIGRpZmZl cmVudCBmcm9tICdiaW5kaW5nJyBpbiBEUy1MaXRlL0x3NG92ZXI2IChpdCdzIG5vdCBqdXN0IGEg bGl0ZXJhbCBkaWZmZXJlbmNlIGFzIEkgc2FpZCkuDQoNCkJlc3QgcmVnYXJkcyENCg0KDQoNCll1 Y2hpIENoZW4NCg0KRnJvbTogT2xlIFRyw7hhbg0KRGF0ZTogMjAxMi0xMS0xMyAyMTo0Ng0KVG86 IGNoZW55Y214DQpDQzogU2F0b3J1IE1hdHN1c2hpbWE7IHNvZnR3aXJlcyBXRw0KU3ViamVjdDog UmU6IFtTb2Z0d2lyZXNdIE1BUC1FIDE6MSBmb3IgSEENCj4gW1l1Y2hpXSBBY3R1YWxseSB0aGVy ZSBpcyBhICdiaW5kaW5nJyB0YWJsZSBvbiB0aGUgQUZUUiwgd2hpY2ggbWFpbnRhaW5zIG1hdGNo aW5nIGJldHdlZW4gdjQgQStQIGFuZCB2NiBBLCBhbmQgdGhlcmUncyBubyAnbWFwcGluZyB3aXRo IGFkZHJlc3MgYW5kIHBvcnQnIGluIERTLUxpdGUgb3IgTHc0b3ZlcjYgYXMgaW4gTUFQLiBUaGUg bWFpbiBwb2ludCBoZXJlIGlzIG5vdCBhYm91dCB0aGUgbGl0ZXJhbCBkaWZmZXJlbmNlIGJldHdl ZW4gJ2JpbmRpbmcnIGFuZCAnbWFwcGluZycsIGJ1dCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGRl Y291cGxpbmcgdjQgJiB2NiBhbmQgY291cGxpbmcgdjQgJiB2Ni4NCg0KbGV0IHVzIGFzc3VtZSB3 ZSBoYXZlIGEgMS4xLjEuMC8yNCBmb3IgYWRkcmVzcyBzaGFyaW5nIGF2YWlsYWJsZSB3aXRoIDI1 NiBwb3J0cyBwZXIgdXNlci4NCg0KaW4gTUFQIDE6MSB5b3UnZCBoYXZlOg0KICAxLjEuMS4xOjAx LzQwIC0+IDIwMDE6ZGI4OjoxDQogIDEuMS4xLjE6MDIvNDAgLT4gMjAwMTpkYjg6OjINCiAgMS4x LjEuMTowMy80MCAtPiAyMDAxOmRiODo6Mw0KICAuDQogIC4NCiAgLg0KDQogIDY0SyBydWxlcy4N Cg0KaW4gTUFQIGFnZ3JlZ2F0ZWQgbW9kZSB5b3UgaGF2ZToNCiAgMS4xLjEuMC8yNCAtPiAyMDAx OmRiODpYWFhYOjovNDgNCg0KY2FuIHlvdSBwbGVhc2Ugc2hvdyBob3cgdGhlIExXNDYgcnVsZXMg LyBiaW5kaW5nIC9tYXBwaW5nIHdoYXRldmVyIHlvdSBjYWxsIHRoZW0gbG9vayBsaWtlIGZvciAx OjEgbW9kZT8NCg0KY2hlZXJzLA0KT2xl ------=_001_NextPart386138141364_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Ole,
 
I'm not so sure what you want to point out with the example. Of cours= e I=20 can show an example of binding table on the AFTR, but I wonder why and wha= t can=20 be achieved to do that here. The quote you made is just trying t= o=20 figure out that the notion of 'mapping' in MAP is different from 'bin= ding'=20 in DS-Lite/Lw4over6 (it's not just a literal difference as I said).
 
Best regards!
Yuchi Chen
 
Date: 2012-11-13 21:46
To: chenycmx
CC: Satoru= =20 Matsushima; softwires WG
Subject: Re: [Softwires] MAP-E 1:1 for HA
> [Yuchi] Actually there is a 'bindi= ng' table on the AFTR, which maintains = matching between v4 A+P and v6 A, and&n= bsp;there's no 'mapping with address and por= t' in DS-Lite or Lw4over6 as in MAP.&nb= sp;The main point here is not about the=  literal difference between 'binding' and 'm= apping', but the difference between decoupling&nb= sp;v4 & v6 and coupling v4 & v6= .
 
let us assume we have a 1.1.1.0/24 = ;for address sharing available with 256 port= s per user.
 
in MAP 1:1 you'd have:
  1.1.1.1:01/40 -> 2001:db8::1
  1.1.1.1:02/40 -> 2001:db8::2
  1.1.1.1:03/40 -> 2001:db8::3
  .
  .
  .
 
  64K rules.
 
in MAP aggregated mode you have:
  1.1.1.0/24 -> 2001:db8:XXXX::/48
 
can you please show how the LW46 r= ules / binding /mapping whatever you call&nb= sp;them look like for 1:1 mode?
 
cheers,
Ole
 
------=_001_NextPart386138141364_=------ From otroan@employees.org Tue Nov 13 10:35:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751BA21F8653 for ; Tue, 13 Nov 2012 10:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.266 X-Spam-Level: X-Spam-Status: No, score=-10.266 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01oTKwgefhdd for ; Tue, 13 Nov 2012 10:35:47 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BAAAD21F85F0 for ; Tue, 13 Nov 2012 10:35:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAGGRolCQ/khN/2dsb2JhbABEwEGDO4EIgh4BAQEDARIBFBM/BQsFBhQDL08IBiQRh2IGmkSPZZAwkh1hA5tniG2Ba4Jw X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="9540042" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 13 Nov 2012 18:35:45 +0000 Received: from [10.61.98.156] (dhcp-10-61-98-156.cisco.com [10.61.98.156]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qADIZjMM032706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Nov 2012 18:35:45 GMT Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Priority: 3 In-Reply-To: <2012111323293100042378@gmail.com> Date: Tue, 13 Nov 2012 19:35:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8272E911-D4D8-426E-913C-3CE828102886@employees.org> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com>, <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com>, <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> <2012111323293100042378@gmail.com> To: chenycmx X-Mailer: Apple Mail (2.1499) Cc: softwires WG Subject: Re: [Softwires] [SUSPECTED SPAM] Re: Re: MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 18:35:47 -0000 Yuchi, > I'm not so sure what you want to point out with the example. Of course = I can show an example of binding table on the AFTR, but I wonder why and = what can be achieved to do that here. The quote you made is just trying = to figure out that the notion of 'mapping' in MAP is different from = 'binding' in DS-Lite/Lw4over6 (it's not just a literal difference as I = said). my point is that your LW46 mapping table will look exactly like the MAP = 1:1 table. no? cheers, Ole > Date: 2012-11-13 21:46 > To: chenycmx > CC: Satoru Matsushima; softwires WG > Subject: Re: [Softwires] MAP-E 1:1 for HA > > [Yuchi] Actually there is a 'binding' table on the AFTR, which = maintains matching between v4 A+P and v6 A, and there's no 'mapping with = address and port' in DS-Lite or Lw4over6 as in MAP. The main point here = is not about the literal difference between 'binding' and 'mapping', but = the difference between decoupling v4 & v6 and coupling v4 & v6. > =20 > let us assume we have a 1.1.1.0/24 for address sharing available with = 256 ports per user. > =20 > in MAP 1:1 you'd have: > 1.1.1.1:01/40 -> 2001:db8::1 > 1.1.1.1:02/40 -> 2001:db8::2 > 1.1.1.1:03/40 -> 2001:db8::3 > . > . > . > =20 > 64K rules. > =20 > in MAP aggregated mode you have: > 1.1.1.0/24 -> 2001:db8:XXXX::/48 > =20 > can you please show how the LW46 rules / binding /mapping whatever you = call them look like for 1:1 mode? > =20 > cheers, > Ole > =20 From mark@townsley.net Tue Nov 13 13:02:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C376021F8527 for ; Tue, 13 Nov 2012 13:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOhr6gVKocIz for ; Tue, 13 Nov 2012 13:02:57 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1721F8525 for ; Tue, 13 Nov 2012 13:02:56 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1642553eek.31 for ; Tue, 13 Nov 2012 13:02:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=K7RikM5/4CmVHpvHFri2McYZfrAgiI58Ox0kl+PZ5gE=; b=JZRcsr4OG/d1yDewuqA8LOkzybW339UNQYHZOalTUnrGT1RDezerTN6lqD4mBKsKOF E18dA8GYQ55K9hxCiIvSXjfXlwzRxzJwsDNBHVMrqi+y6H1uolOIi52d+Zamu40yQoeI d6ltSZVCffU7TaYuU832fOVApel7+fK/eNpuXPhJdFrc+aFHwINm4TSdcBWZqu3tuZ/e wVRPGB1XfIDm0bcy08tU7nXsK4WvdM/PpCIFWqSr82QnzFgPU1TbpHnc5I1CLZA/Os+Z rY5esU/1hiYbfiuEVChFsI5gGcVMv4cOJZY5yrfB24aAqT/F0Gq0rjZ4OH5wwQccjAkG nemg== Received: by 10.14.215.69 with SMTP id d45mr78740508eep.16.1352840575756; Tue, 13 Nov 2012 13:02:55 -0800 (PST) Received: from ams-townsley-8915.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id g47sm24992626eeo.6.2012.11.13.13.02.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Nov 2012 13:02:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_7E239504-851D-49C5-9AEE-D033BB093341" From: Mark Townsley In-Reply-To: Date: Tue, 13 Nov 2012 22:02:48 +0100 Message-Id: References: <0F938BE0-D4DE-4F30-B26F-6B862D674192@employees.org> To: Qiong X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkY3nkKk8U0u5YFcry2AnDZZjAl5HwRs+lLpkde+NNuYeYiE/d9Sqmohh3knRaySLTr1JYy Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:02:57 -0000 --Apple-Mail=_7E239504-851D-49C5-9AEE-D033BB093341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 10, 2012, at 5:05 AM, Qiong wrote: > Hi Ole, >=20 >=20 > On Sat, Nov 10, 2012 at 9:41 AM, Ole Tr=F8an = wrote: > Yiu, >=20 > > I have a question for the HA design concept of MAP-E 1:1. The = central theme of MAP-E is to make BR as stateless as possible and use = Anycast address to identify the MAP-E BR. However, if we use MAP-E 1:1 = mode, the operator must have to pre-provision all the subscribe rules to = all the BRs sharing the same Anycast address for reliable HA. This = requires operators to carefully plan out which BRs support which = subscribers. It is because BR is "per-subscriber stateful" in MAP-E 1:1 = mode. Compared to the MAP-E design, HA in MAP-E only requires the = operators to use the same set of rules to cover the entire domain. IMHO, = this contradicts the original spirit of stateless solution and always = puzzles me why MAP-E 1:1 bears the MAP-E name. MAP-E and 1:1 MAP-E are = two completely different solutions and target to different deployment = scenarios. I would love to hear others to comment in the ML how to = resolve this issue. >=20 > all nodes in a MAP domain must have the same rules. > in 1:1 mode there is only the CE and the BR in the domain. >=20 > having an aggregate route e.g. an IPv4 /24 or a host route a /32 = doesn't mean you need a different RIB implementation. > [Qiong] Actually, that's not the same. If we only need /32, there is = no need to do LPM implementation anymore, only exact matching is needed = and this is much eaiser than LPM. LPM is not optimized for /32 routing = lookup.=20 > The reason that current routers still implement LPM rather not exact = matching is because /32 is a truely corner case in RIB. However, if /32 = is not a corner case, but is the major requirement for operators, I = believe more efficient way should be introduced. The PPP protocol is the same whether it is used on a router to router = serial link or a BNG terminating 100,000s of PPPoE and L2TP sessions. = DHCP is still DHCP whether being used to provision millions of routers = in a broadband network, a few in your home, on a wireless or wired = enterprise network, etc. etc... Of course implementations are optimized = and scaled differently, and may even have different tweaks or options = depending on how it is being used, but the protocol itself is the same = whether it is used in one type of deployment or another. Should we have = had separate RFCs and marketing names for every environment PPP and DHCP = have been used in?=20 - Mark >=20 > Best wishes > Qiong=20 > =20 > a host route which is what we have in 1:1 mode is just a corner case. = what is "completely different" about it? >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institude >=20 >=20 > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_7E239504-851D-49C5-9AEE-D033BB093341 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi = Ole,


On = Sat, Nov 10, 2012 at 9:41 AM, Ole Tr=F8an <otroan@employees.org> wrote:
Yiu,

> I have a question for the HA design concept of MAP-E 1:1. The = central theme of MAP-E is to make BR as stateless as possible and use = Anycast address to identify the MAP-E BR. However, if we use MAP-E 1:1 = mode, the operator must have to pre-provision all the subscribe rules to = all the BRs sharing the same Anycast address for reliable HA. This = requires operators to carefully plan out which BRs support which = subscribers. It is because BR is "per-subscriber stateful" in MAP-E 1:1 = mode. Compared to the MAP-E design, HA in MAP-E only requires the = operators to use the same set of rules to cover the entire domain. IMHO, = this contradicts  the original spirit of stateless solution and = always puzzles me why MAP-E 1:1 bears the MAP-E name. MAP-E and 1:1 = MAP-E are two completely different solutions and target to different = deployment scenarios. I would love to hear others to comment in the ML = how to resolve this issue.

all nodes in a MAP domain must have the same rules.
in 1:1 mode there is only the CE and the BR in the domain.

having an aggregate route e.g. an IPv4 /24 or a host route a /32 doesn't = mean you need a different RIB = implementation.
[Qiong] Actually, that's not the = same. If we only need /32, there is no need to do LPM implementation = anymore, only exact matching is needed and this is much eaiser than LPM. = LPM is not optimized for /32 routing lookup.
The reason that current routers still implement LPM rather not exact = matching is because /32 is a truely corner case in RIB. However, if /32 = is not a corner case, but is the major requirement for operators, I = believe more efficient way should be = introduced.

The = PPP protocol is the same whether it is used on a router to router serial = link or a BNG terminating 100,000s of PPPoE and L2TP sessions. =  DHCP is still DHCP whether being used to provision millions of = routers in a broadband network, a few in your home, on a wireless or = wired enterprise network, etc. etc... Of course implementations are = optimized and scaled differently, and may even have different tweaks or = options depending on how it is being used, but the protocol itself is = the same whether it is used in one type of deployment or another. Should = we have had separate RFCs and marketing names for every environment PPP = and DHCP have been used in? 

- = Mark


Best wishes
Qiong
 
a host route which is what we have in 1:1 mode is just a corner case. = what is "completely different" about it?

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



-- =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qion= g Sun
China Telecom Beijing Research Institude


Open source = code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


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

= --Apple-Mail=_7E239504-851D-49C5-9AEE-D033BB093341-- From chenycmx@gmail.com Tue Nov 13 23:22:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2554E21F85CF for ; Tue, 13 Nov 2012 23:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+wKVAqeHju5 for ; Tue, 13 Nov 2012 23:22:48 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 017F021F85C8 for ; Tue, 13 Nov 2012 23:22:47 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so57175eaa.31 for ; Tue, 13 Nov 2012 23:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:x-priority:x-guid :x-has-attach:x-mailer:mime-version:message-id:content-type; bh=n3bVk5DMDZlW9QQG1cNaX3OtMWWpGqqfhPU3PgO9bCs=; b=BMQ+2i10ljQtSdDQrTcGL+5xxE+zVx2fkyr1sdPYPdh21ubJSl0mjj7oRGy6Meu4kZ rDU7DxStMQrxlKV4CLCjzL52W/FtIF9Xkn7EXxzNsKvwSBRzR295Jv5pShw/lokgSWTp MXgvvT61u8OZ5aYTrgWC8fHCt6ycHX7AMsSnkio7yZtW5i8RVlLVB7k51ZIlfqvvWE79 UIbDSw3+u6vPxk44NWrwIWHb8SQhNV+mvPBW3zbPTQWyURhOCvlu1yqWkxEiBjogQiIr y+eI8AiGB97A1dOnyV59crbVCAZixVTaXg7EwoDjkeHqpEjUeEoXunNCHVic9ITb2Yae TVYQ== Received: by 10.14.0.198 with SMTP id 46mr84303165eeb.21.1352877761652; Tue, 13 Nov 2012 23:22:41 -0800 (PST) Received: from user-902eaffedc ([114.255.41.145]) by mx.google.com with ESMTPS id g5sm27872602eem.4.2012.11.13.23.22.20 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 23:22:40 -0800 (PST) Date: Wed, 14 Nov 2012 15:22:14 +0800 From: "Yuchi Chen" To: =?utf-8?B?T2xlIFRyw7hhbg==?= References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com>, <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com>, <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> <2012111323293100042378@gmail.com>, <8272E911-D4D8-426E-913C-3CE828102886@employees.org> X-Priority: 3 X-GUID: CCFC35AF-5AC1-4FC7-B45E-54F3BF342618 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.88[cn] Mime-Version: 1.0 Message-ID: <2012111415220096801455@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart125751741142_=----" Cc: softwires WG Subject: Re: [Softwires] [SUSPECTED SPAM] Re: Re: MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 07:22:49 -0000 This is a multi-part message in MIME format. ------=_001_NextPart125751741142_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgT2xlLA0KDQpGcm9tIG15IHBlcnNwZWN0aXZlLCB5b3VyIE1BUCAxOjEgbWFwcGluZyB0YWJs ZSBsb29rcyBub3Qgc28gcmVhbGx5IGxpa2UgTHc0b3ZlcjYgYmluZGluZyB0YWJsZSwgd2hpY2gg Y2FuIGJlIGVzdGFibGlzaGVkIGluIGEgc3RhdGljIG9yIGR5bmFtaWMgd2F5IG9yIGJvdGguDQoN CkFGQUlLIGFsbCB0aGUgMToxIHJ1bGVzIGluIHlvdXIgbWFwcGluZyB0YWJsZSBtdXN0IGJlIHBy ZS1jb25maWd1cmVkIHN0YXRpY2FsbHkgYXMgb3RoZXIgcnVsZXMgaW4gTUFQIGFnZ3JlZ2F0ZWQg bW9kZSwgd2hpY2ggbWVhbnMgdGhhdCB3aXRoIHRoZSAxLjEuMS4wLzI0IGZvciBhZGRyZXNzIHNo YXJpbmcgYXZhaWxhYmxlIHdpdGggMjU2IHBvcnRzIHBlciB1c2VyLCB0aGUgQlIgY2FuIGp1c3Qg c3VwcG9ydCBleGFjdGx5IDY0SyBDRXMgYXQgbW9zdC4gSG93ZXZlciwgYXMgdGhlIGx3QUZUUiBh bGxvY2F0ZXMgSVB2NCBhZGRyZXNzZXMgYW5kIHBvcnRzIGR5bmFtaWNhbGx5LCB3aXRoIHRoZXNl IHJlc291cmNlcyB0aGUgbHdBRlRSIGNhbiBrZWVwIDY0SyBsd0I0cyBjb25uZWN0ZWQgc2ltdWx0 YW5lb3VzbHksIGFuZCBub2JvZHkga25vd3MgaG93IGxhcmdlIHRoZSBudW1iZXIgb2YgbHdCNHMg dGhhdCB0aGUgbHdBRlRSIGNhbiBzdXBwb3J0IGF0IG1vc3QgY2FuIGJlLiBQbGVhc2Ugbm90ZSB0 aGF0IHRoaXMgbnVtYmVyIGNvdWxkIGJlIG11Y2ggbGFyZ2VyIHRoYW4gNjRLLCBiZWNhdXNlIG5v dCBhbGwgdGhlIHN1cHBvcnRlZCBsd0I0cyBtYXkgYmUgb25saW5lIGF0IHRoZSBzYW1lIHRpbWUu IElNSE8gdGhhdCB0aGUgTUFQIG1hcHBpbmcgdGFibGUgY2FuIGp1c3QgYmUgY29uZmlndXJlZCBz dGF0aWNhbGx5IHNlZW1zIHRvIGJlIGEgbGltaXQgd2hlbiBpdCBjb21lcyB0byAxOjEgc2NlbmFy aW8uDQoNCkJlc3QgcmVnYXJkcyENCg0KDQoNCll1Y2hpIENoZW4NCg0KRnJvbTogT2xlIFRyw7hh bg0KRGF0ZTogMjAxMi0xMS0xNCAwMjozNQ0KVG86IGNoZW55Y214DQpDQzogU2F0b3J1IE1hdHN1 c2hpbWE7IHNvZnR3aXJlcyBXRw0KU3ViamVjdDogUmU6IFtTVVNQRUNURUQgU1BBTV0gUmU6IFJl OiBbU29mdHdpcmVzXSBNQVAtRSAxOjEgZm9yIEhBDQpZdWNoaSwNCg0KPiBJJ20gbm90IHNvIHN1 cmUgd2hhdCB5b3Ugd2FudCB0byBwb2ludCBvdXQgd2l0aCB0aGUgZXhhbXBsZS4gT2YgY291cnNl IEkgY2FuIHNob3cgYW4gZXhhbXBsZSBvZiBiaW5kaW5nIHRhYmxlIG9uIHRoZSBBRlRSLCBidXQg SSB3b25kZXIgd2h5IGFuZCB3aGF0IGNhbiBiZSBhY2hpZXZlZCB0byBkbyB0aGF0IGhlcmUuIFRo ZSBxdW90ZSB5b3UgbWFkZSBpcyBqdXN0IHRyeWluZyB0byBmaWd1cmUgb3V0IHRoYXQgdGhlIG5v dGlvbiBvZiAnbWFwcGluZycgaW4gTUFQIGlzIGRpZmZlcmVudCBmcm9tICdiaW5kaW5nJyBpbiBE Uy1MaXRlL0x3NG92ZXI2IChpdCdzIG5vdCBqdXN0IGEgbGl0ZXJhbCBkaWZmZXJlbmNlIGFzIEkg c2FpZCkuDQoNCm15IHBvaW50IGlzIHRoYXQgeW91ciBMVzQ2IG1hcHBpbmcgdGFibGUgd2lsbCBs b29rIGV4YWN0bHkgbGlrZSB0aGUgTUFQIDE6MSB0YWJsZS4gbm8/DQoNCmNoZWVycywNCk9sZQ0K DQo+IERhdGU6IDIwMTItMTEtMTMgMjE6NDYNCj4gVG86IGNoZW55Y214DQo+IENDOiBTYXRvcnUg TWF0c3VzaGltYTsgc29mdHdpcmVzIFdHDQo+IFN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBNQVAt RSAxOjEgZm9yIEhBDQo+ID4gW1l1Y2hpXSBBY3R1YWxseSB0aGVyZSBpcyBhICdiaW5kaW5nJyB0 YWJsZSBvbiB0aGUgQUZUUiwgd2hpY2ggbWFpbnRhaW5zIG1hdGNoaW5nIGJldHdlZW4gdjQgQStQ IGFuZCB2NiBBLCBhbmQgdGhlcmUncyBubyAnbWFwcGluZyB3aXRoIGFkZHJlc3MgYW5kIHBvcnQn IGluIERTLUxpdGUgb3IgTHc0b3ZlcjYgYXMgaW4gTUFQLiBUaGUgbWFpbiBwb2ludCBoZXJlIGlz IG5vdCBhYm91dCB0aGUgbGl0ZXJhbCBkaWZmZXJlbmNlIGJldHdlZW4gJ2JpbmRpbmcnIGFuZCAn bWFwcGluZycsIGJ1dCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIGRlY291cGxpbmcgdjQgJiB2NiBh bmQgY291cGxpbmcgdjQgJiB2Ni4NCj4gIA0KPiBsZXQgdXMgYXNzdW1lIHdlIGhhdmUgYSAxLjEu MS4wLzI0IGZvciBhZGRyZXNzIHNoYXJpbmcgYXZhaWxhYmxlIHdpdGggMjU2IHBvcnRzIHBlciB1 c2VyLg0KPiAgDQo+IGluIE1BUCAxOjEgeW91J2QgaGF2ZToNCj4gICAxLjEuMS4xOjAxLzQwIC0+ IDIwMDE6ZGI4OjoxDQo+ICAgMS4xLjEuMTowMi80MCAtPiAyMDAxOmRiODo6Mg0KPiAgIDEuMS4x LjE6MDMvNDAgLT4gMjAwMTpkYjg6OjMNCj4gICAuDQo+ICAgLg0KPiAgIC4NCj4gIA0KPiAgIDY0 SyBydWxlcy4NCj4gIA0KPiBpbiBNQVAgYWdncmVnYXRlZCBtb2RlIHlvdSBoYXZlOg0KPiAgIDEu MS4xLjAvMjQgLT4gMjAwMTpkYjg6WFhYWDo6LzQ4DQo+ICANCj4gY2FuIHlvdSBwbGVhc2Ugc2hv dyBob3cgdGhlIExXNDYgcnVsZXMgLyBiaW5kaW5nIC9tYXBwaW5nIHdoYXRldmVyIHlvdSBjYWxs IHRoZW0gbG9vayBsaWtlIGZvciAxOjEgbW9kZT8NCj4gIA0KPiBjaGVlcnMsDQo+IE9sZQ0KPiAg ------=_001_NextPart125751741142_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Ole,
 
From my perspective, your MAP 1:1 mapping table looks not s= o=20 really like Lw4over6 binding table, which can be established in a sta= tic or=20 dynamic way or both.
 
AFAIK all the 1:1 rules in your mapping table must be pre-configured=20 statically as other rules in MAP aggregated mode, which means that with th= e=20 1.1.1.0/24 for address sharing available with&nbs= p;256 ports per user, the=20 BR can just support exactly 64K CEs at most. However, as the lwAFTR=20 allocates IPv4 addresses and ports dynamically, with these resources the l= wAFTR=20 can keep 64K lwB4s connected simultaneously, and nobody knows ho= w=20 large the number of lwB4s that the lwAFTR can support at most ca= n be.=20 Please note that this number could be much larger than 64K, because not al= l the=20 supported lwB4s may be online at the same time. IMHO that the MAP map= ping=20 table can just be configured statically seems to be a limit when= it=20 comes to 1:1 scenario.
 
Best regards!
Yuchi Chen
 
Date: 2012-11-14 02:35
To: chenycmx
CC: Satoru= =20 Matsushima; softwires WG
Subject: Re: [SUSPECTED SPAM] Re: Re: [Softwires] MAP-E 1= :1 for=20 HA
Yuchi,
 
> I'm not so sure what you want=  to point out with the example. Of = ;course I can show an example of bindin= g table on the AFTR, but I wonder = why and what can be achieved to do = ;that here. The quote you made is just&= nbsp;trying to figure out that the notion&nb= sp;of 'mapping' in MAP is different from&nbs= p;'binding' in DS-Lite/Lw4over6 (it's not just&nb= sp;a literal difference as I said).
 
my point is that your LW46 mapping = ;table will look exactly like the MAP 1= :1 table. no?
 
cheers,
Ole
 
> Date: 2012-11-13 21:46
> To: chenycmx
> CC: Satoru Matsushima; softwires WG
> Subject: Re: [Softwires] MAP-E 1:1 = ;for HA
> > [Yuchi] Actually there is a&n= bsp;'binding' table on the AFTR, which maint= ains matching between v4 A+P and v6 A,&= nbsp;and there's no 'mapping with address an= d port' in DS-Lite or Lw4over6 as in&nb= sp;MAP. The main point here is not abou= t the literal difference between 'binding' a= nd 'mapping', but the difference between dec= oupling v4 & v6 and coupling v4 &am= p; v6.
>  
> let us assume we have a 1.1.1= .0/24 for address sharing available with 256=  ports per user.
>  
> in MAP 1:1 you'd have:
>   1.1.1.1:01/40 -> 2001:db8::1
>   1.1.1.1:02/40 -> 2001:db8::2
>   1.1.1.1:03/40 -> 2001:db8::3
>   .
>   .
>   .
>  
>   64K rules.
>  
> in MAP aggregated mode you have:
>   1.1.1.0/24 -> 2001:db8:XXXX::/48
>  
> can you please show how the L= W46 rules / binding /mapping whatever you&nb= sp;call them look like for 1:1 mode?
>  
> cheers,
> Ole
>  
 
------=_001_NextPart125751741142_=------ From sunqi.csnet.thu@gmail.com Wed Nov 14 08:04:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33A21F8569 for ; Wed, 14 Nov 2012 08:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEvniDd4kiFJ for ; Wed, 14 Nov 2012 08:04:58 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1676B21F841B for ; Wed, 14 Nov 2012 08:04:58 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id h15so253374dan.31 for ; Wed, 14 Nov 2012 08:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=qVVEh+5PSBS6wzyl8FOzwbXDWd4c/B34k/gp+WWfbGw=; b=krg6++Ly9fL6Ha0ykRhr+YZlw1dtX/efFpNwhVD3YqQ6tXMwceeSR0FCPO25bK7scq 2CZ4AJ+Gy7Wt0KJl6Mj2tBzqOO8ZHE79hH53jUZoADhy5AbJ8ZaUFj3J4utHMHAyRmCV jBsHeVdKYXTfLGozZlNDLReop37zd6b3Jgwowj8ib5f5bixuLAnoW5FbNvwvYKJH7nTB NQary6Yk5/DpL+cl/UrUc9u8IE0yIv5KU5buS0p9zXK0KERUvXOcXMscwiZ+R+QctgkD b7SnuqvJp3T0GcHj6iBo+M+O/WOPV2zGAnXLd32avwuHG1L0jBCDYj3HFuqLaopHUJNi YQTw== Received: by 10.69.1.37 with SMTP id bd5mr79357023pbd.77.1352909097798; Wed, 14 Nov 2012 08:04:57 -0800 (PST) Received: from [192.168.43.198] ([219.141.159.58]) by mx.google.com with ESMTPS id na4sm2054984pbc.18.2012.11.14.08.04.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Nov 2012 08:04:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun X-Priority: 3 In-Reply-To: <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> Date: Thu, 15 Nov 2012 00:03:03 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0BF9E591-8683-4F67-A2AE-BF195F2EB0CD@gmail.com> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com>, <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com> <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:04:58 -0000 Ole, > in MAP aggregated mode you have: > 1.1.1.0/24 -> 2001:db8:XXXX::/48 Actually, the so called 'aggregated mode' is original MAP-E, with IPv4 = address and PSID embedded in the EA-bits field in End user IPv6 prefix. = Let me try to explain what you have 'aggregated'. 1.1.1.1:01 -> 2001:db8:101::/48 (EA-bits: 0x101) 1.1.1.1:02 -> 2001:db8:102::/48 (EA-bits: 0x102) 1.1.1.1:03 -> 2001:db8:103::/48 (EA-bits: 0x103) . . . The IPv4 address and port set are the same in what you called 'MAP 1:1'. = However, the corresponding IPv6 addresses are totally different. Because = one uses MAP algorithm, the other doesn't.=20 The original MAP-E achieves address sharing by embedding IPv4 suffix and = PSID into End User IPv6 prefix. But if the EA-bits is ZERO, PSID is also = ZERO. Nothing embedded in the IPv6 prefix. In this case, the so called = 'MAP 1:1' abandons the MAP algorithm and uses a per-subscriber stateful = kind method to achieve address sharing. That is NOT MAP-E.=20 So I question why 'MAP-E 1:1' bears the MAP-E name. Qi Sun On 2012-11-13, at =E4=B8=8B=E5=8D=889:46, Ole Tr=C3=B8an wrote: >> [Yuchi] Actually there is a 'binding' table on the AFTR, which = maintains matching between v4 A+P and v6 A, and there's no 'mapping with = address and port' in DS-Lite or Lw4over6 as in MAP. The main point here = is not about the literal difference between 'binding' and 'mapping', but = the difference between decoupling v4 & v6 and coupling v4 & v6. >=20 > let us assume we have a 1.1.1.0/24 for address sharing available with = 256 ports per user. >=20 > in MAP 1:1 you'd have: > 1.1.1.1:01/40 -> 2001:db8::1 > 1.1.1.1:02/40 -> 2001:db8::2 > 1.1.1.1:03/40 -> 2001:db8::3 > . > . > . >=20 > 64K rules. >=20 > in MAP aggregated mode you have: > 1.1.1.0/24 -> 2001:db8:XXXX::/48 >=20 > can you please show how the LW46 rules / binding /mapping whatever you = call them look like for 1:1 mode? >=20 > cheers, > Ole >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Wed Nov 14 08:59:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BB321F84FA for ; Wed, 14 Nov 2012 08:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeHjZKTR6bsb for ; Wed, 14 Nov 2012 08:59:13 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F02521F84F9 for ; Wed, 14 Nov 2012 08:59:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIfMo1CrRDoH/2dsb2JhbABEwz6BCIIeAQEBAwESARQTPxAFBkZXBiQRh2IFmzCgG5F4YQObZ4htgWuCcA X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="60921666" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 14 Nov 2012 16:59:09 +0000 Received: from [10.61.102.36] (dhcp-10-61-102-36.cisco.com [10.61.102.36]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAEGx59Y003246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Nov 2012 16:59:08 GMT Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Priority: 3 In-Reply-To: <0BF9E591-8683-4F67-A2AE-BF195F2EB0CD@gmail.com> Date: Wed, 14 Nov 2012 17:59:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96E51849-1E83-4996-8EDC-0534CADB94AD@employees.org> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com>, <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com> <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> <0BF9E591-8683-4F67-A2AE-BF195F2EB0CD@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1499) Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:59:13 -0000 >> in MAP aggregated mode you have: >> 1.1.1.0/24 -> 2001:db8:XXXX::/48 >=20 > Actually, the so called 'aggregated mode' is original MAP-E, with IPv4 = address and PSID embedded in the EA-bits field in End user IPv6 prefix. = Let me try to explain what you have 'aggregated'. >=20 > 1.1.1.1:01 -> 2001:db8:101::/48 (EA-bits: 0x101) > 1.1.1.1:02 -> 2001:db8:102::/48 (EA-bits: 0x102) > 1.1.1.1:03 -> 2001:db8:103::/48 (EA-bits: 0x103) > . > . > . >=20 > The IPv4 address and port set are the same in what you called 'MAP = 1:1'. However, the corresponding IPv6 addresses are totally different. = Because one uses MAP algorithm, the other doesn't.=20 >=20 >=20 > The original MAP-E achieves address sharing by embedding IPv4 suffix = and PSID into End User IPv6 prefix. But if the EA-bits is ZERO, PSID is = also ZERO. Nothing embedded in the IPv6 prefix. In this case, the so = called 'MAP 1:1' abandons the MAP algorithm and uses a per-subscriber = stateful kind method to achieve address sharing. That is NOT MAP-E.=20 >=20 > So I question why 'MAP-E 1:1' bears the MAP-E name. I really don't care what we call it. what we are talking about is simply = RFC2473 tunneling with extensions from RFC6346. if you want to, please suggest whatever name you like. what I'm arguing against is that we need a separate RFC for the = mechanism if it uses a /48 versus if it uses a /40. cheers, Ole= From sarikaya2012@gmail.com Wed Nov 14 13:40:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF1921F8480 for ; Wed, 14 Nov 2012 13:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRDPGte8BRXV for ; Wed, 14 Nov 2012 13:40:21 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 14C5C21F8475 for ; Wed, 14 Nov 2012 13:40:21 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so1481428iec.31 for ; Wed, 14 Nov 2012 13:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8QdPiZKOmQZU6KcI7IZO0RBRrHepYdiuQNpULjWlcnA=; b=RqzYgqN73oaQRYIQ+WJZfFCeFqU5I8Kz04B2SxCtzFu7bmLKp5aZc9ED+4Xvy2xIHX tOJJYZM/QhfOoz20sTa22LVKkQqOxn6r8Oepw15PcY3aQPK1m/quIzEyg6I7Enz+j3YR OxYou5Fv5AqpLPOHvfFzZAHCa89UnixXmfrk8Odmd18xzjxylNkSwXQWNGDZhffJvhzU MvFoMVejhkvoY4O+9313yUsOz+hd+X2pW8zRJ9399wk1CwasvIr4CFXk6k7NEA+o80A9 cHAFcObCWZQF2Gk2fdHuEEhz53J8aezn9HEmrXw2lTbVPrueFJ8mAGdym+qYxZngHMuy xcNg== MIME-Version: 1.0 Received: by 10.50.16.177 with SMTP id h17mr662272igd.37.1352929220680; Wed, 14 Nov 2012 13:40:20 -0800 (PST) Received: by 10.231.85.26 with HTTP; Wed, 14 Nov 2012 13:40:20 -0800 (PST) In-Reply-To: <20121114213649.28156.63680.idtracker@ietfa.amsl.com> References: <20121114213649.28156.63680.idtracker@ietfa.amsl.com> Date: Wed, 14 Nov 2012 15:40:20 -0600 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwire Chairs Subject: [Softwires] New Version Notification for draft-sarikaya-softwire-4rdmulticast-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:40:22 -0000 Hi all, This draft was discussed in last week's session in Atlanta. Please take some time to take a look and send some comments. Regards, Behcet A new version of I-D, draft-sarikaya-softwire-4rdmulticast-05.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-softwire-4rdmulticast Revision: 05 Title: Multicast Support for 4rd Creation date: 2012-11-14 WG ID: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-softwire-4rdmulticast-05.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast Htmlized: http://tools.ietf.org/html/draft-sarikaya-softwire-4rdmulticast-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-sarikaya-softwire-4rdmulticast-05 Abstract: This memo specifies 4rd technology's multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In 4rd encapsulation solution for encapsulation variant of Mapping of Address and Port (MAP), MAP-E, IGMP Proxy at the 4rd Customer Edge router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGMP messages to establish multicast state at MAP Border Relay so that MAP Border Relay can tunnel IPv4 multicast data to IPv4 hosts connected to MAP Customer Edge device. In 4rd Translation Multicast solution for 4rd and translation variant of MAP, MAP-T, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. 4rd Border Relay does the reverse translation and joins IPv4 multicast group for 4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. The IETF Secretariat From miyakawa@nttv6.jp Wed Nov 14 15:08:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A159321F8628 for ; Wed, 14 Nov 2012 15:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7h7Rxn8336B for ; Wed, 14 Nov 2012 15:08:08 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:144::148]) by ietfa.amsl.com (Postfix) with ESMTP id E663821F8558 for ; Wed, 14 Nov 2012 15:08:07 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:208::212]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 2CC66BDC1E; Thu, 15 Nov 2012 08:08:06 +0900 (JST) Received: from localhost (localhost [IPv6:::1]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 0CD99E1EB2; Thu, 15 Nov 2012 08:08:06 +0900 (JST) Date: Thu, 15 Nov 2012 08:08:06 +0900 (JST) Message-Id: <20121115.080806.104125486.miyakawa@nttv6.jp> To: otroan@employees.org From: Shin Miyakawa In-Reply-To: <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> References: <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com> <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> Organizaton: NTT Communications X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 23:08:08 -0000 Ole, By the way... I think, you should NOT use 1.1.1.1 as example. 1/8 is not a document prefix nor private address space but global space which belongs to APNIC. Cheers, Shin Miyakawa From: Ole Tr=F8an Subject: Re: [Softwires] MAP-E 1:1 for HA Date: Tue, 13 Nov 2012 14:46:03 +0100 >> [Yuchi] Actually there is a 'binding' table on the AFTR, which maint= ains matching between v4 A+P and v6 A, and there's no 'mapping with add= ress and port' in DS-Lite or Lw4over6 as in MAP. The main point here is= not about the literal difference between 'binding' and 'mapping', but = the difference between decoupling v4 & v6 and coupling v4 & v6. > = > let us assume we have a 1.1.1.0/24 for address sharing available with= 256 ports per user. > = > in MAP 1:1 you'd have: > 1.1.1.1:01/40 -> 2001:db8::1 > 1.1.1.1:02/40 -> 2001:db8::2 > 1.1.1.1:03/40 -> 2001:db8::3 > . > . > . > = > 64K rules. > = > in MAP aggregated mode you have: > 1.1.1.0/24 -> 2001:db8:XXXX::/48 > = > can you please show how the LW46 rules / binding /mapping whatever yo= u call them look like for 1:1 mode? > = > cheers, > Ole > = > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > = From bingxuere@gmail.com Wed Nov 14 18:45:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182541F0C67 for ; Wed, 14 Nov 2012 18:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.422 X-Spam-Level: X-Spam-Status: No, score=-3.422 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcTRh3ZFN7ts for ; Wed, 14 Nov 2012 18:45:35 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17B161F0C6E for ; Wed, 14 Nov 2012 18:45:35 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so1819555iec.31 for ; Wed, 14 Nov 2012 18:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eD9aJdb1aFXupyphOylVQ2XDPOk13ewwZxiR/gwIXYM=; b=INQVUvmfClxCw7Y09aDxmdc7W7N3N2/6RqqvtU1SxIFJnfYoB5lzJhFU1WNBrXvmKc iaA79y6nfjBUFh5Me0689l3J1GhjDJQwwM4n8qlWMp8wKjNCRpNPh9j49VWe0YxZrz7p 9n9U580nMLOacikkV751sBHN2/ojTPOxTSNfLmfQjqwkS+H8AzcSnD8s4ZxYUtP6wCku 1ALB47sxhtoYFgSYye/ehfTda5zwCUpcSenhjIJzlHOCYnBhh/Z9pYKWhhsxF+8cB5Qi mxuI97DV/AaFq5d1cqwGGIPjYObTyOBKdKq/w2ySgJeivIoGTk1s8wnFGpJ5UtYvUsak 8MaA== Received: by 10.42.37.142 with SMTP id y14mr25923791icd.44.1352947534710; Wed, 14 Nov 2012 18:45:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Wed, 14 Nov 2012 18:44:51 -0800 (PST) In-Reply-To: <96E51849-1E83-4996-8EDC-0534CADB94AD@employees.org> References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com> <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com> <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> <0BF9E591-8683-4F67-A2AE-BF195F2EB0CD@gmail.com> <96E51849-1E83-4996-8EDC-0534CADB94AD@employees.org> From: Qiong Date: Thu, 15 Nov 2012 10:44:51 +0800 Message-ID: To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=90e6ba6e80e434c61904ce7fa5b0 Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 02:45:36 -0000 --90e6ba6e80e434c61904ce7fa5b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole, On Thu, Nov 15, 2012 at 12:59 AM, Ole Tr=C3=B8an wro= te: > >> in MAP aggregated mode you have: > >> 1.1.1.0/24 -> 2001:db8:XXXX::/48 > > > > Actually, the so called 'aggregated mode' is original MAP-E, with IPv4 > address and PSID embedded in the EA-bits field in End user IPv6 prefix. L= et > me try to explain what you have 'aggregated'. > > > > 1.1.1.1:01 -> 2001:db8:101::/48 (EA-bits: 0x101) > > 1.1.1.1:02 -> 2001:db8:102::/48 (EA-bits: 0x102) > > 1.1.1.1:03 -> 2001:db8:103::/48 (EA-bits: 0x103) > > . > > . > > . > > > > The IPv4 address and port set are the same in what you called 'MAP 1:1'= . > However, the corresponding IPv6 addresses are totally different. Because > one uses MAP algorithm, the other doesn't. > > > > > > The original MAP-E achieves address sharing by embedding IPv4 suffix an= d > PSID into End User IPv6 prefix. But if the EA-bits is ZERO, PSID is also > ZERO. Nothing embedded in the IPv6 prefix. In this case, the so called 'M= AP > 1:1' abandons the MAP algorithm and uses a per-subscriber stateful kind > method to achieve address sharing. That is NOT MAP-E. > > > > So I question why 'MAP-E 1:1' bears the MAP-E name. > > I really don't care what we call it. what we are talking about is simply > RFC2473 tunneling with extensions from RFC6346. > if you want to, please suggest whatever name you like. > > what I'm arguing against is that we need a separate RFC for the mechanism > if it uses a /48 versus if it uses a /40. > [Qiong] The reason here is that they are actually two mechanisms steps from different motivations and requirements. That's why they will result in two kinds of rules/binding/or ...with the same 'aggregated' IPv4 rule. Best wishes Qiong > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --90e6ba6e80e434c61904ce7fa5b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole,



O= n Thu, Nov 15, 2012 at 12:59 AM, Ole Tr=C3=B8an <otroan@employees.org> wrote:
>>= ; in MAP aggregated mode you have:
>> 1.1.1.0/24 -&g= t; 2001:db8:XXXX::/48
>
> Actually, the so called 'aggregated mode' is original MAP-E, w= ith IPv4 address and PSID embedded in the EA-bits field in End user IPv6 pr= efix. Let me try to explain what you have 'aggregated'.
>
> 1.1.1.1:01 -> 2= 001:db8:101::/48 (EA-bits: 0x101)
> 1.1.1.1:02 -> 2= 001:db8:102::/48 (EA-bits: 0x102)
> 1.1.1.1:03 -> 2= 001:db8:103::/48 (EA-bits: 0x103)
> .
> .
> .
>
> The IPv4 address and port set are the same in what you called 'MAP= 1:1'. However, the corresponding IPv6 addresses are totally different.= Because one uses MAP algorithm, the other doesn't.
>
>
> The original MAP-E achieves address sharing by embedding IPv4 suffix a= nd PSID into End User IPv6 prefix. But if the EA-bits is ZERO, PSID is also= ZERO. Nothing embedded in the IPv6 prefix. In this case, the so called = 9;MAP 1:1' abandons the MAP algorithm and uses a per-subscriber statefu= l kind method to achieve address sharing. That is NOT MAP-E.
>
> So I question why 'MAP-E 1:1' bears the MAP-E name.

I really don't care what we call it. what we are talking about is= simply RFC2473 tunneling with extensions from RFC6346.
if you want to, please suggest whatever name you like.

what I'm arguing against is that we need a separate RFC for the mechani= sm if it uses a /48 versus if it uses a /40.

[Qion= g] The reason here is that they are actually two mechanisms steps from diff= erent motivations and requirements. That's why they will result in two = kinds of rules/binding/or ...with the same 'aggregated' IPv4 rule.<= br>
Best wishes
Qiong
=C2=A0

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



--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--90e6ba6e80e434c61904ce7fa5b0-- From otroan@employees.org Thu Nov 15 00:23:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C91221F87E9 for ; Thu, 15 Nov 2012 00:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.268 X-Spam-Level: X-Spam-Status: No, score=-10.268 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiKGWgnUMg9l for ; Thu, 15 Nov 2012 00:23:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9388821F869C for ; Thu, 15 Nov 2012 00:23:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcNANylpFCQ/khM/2dsb2JhbABEjjmxSYI7AQECAQECgQSBCIIeAQEBAwESAWYFCwtGVwY1h2MGnAugCZF8YQOkVIFrgnA X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="146769840" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Nov 2012 08:23:18 +0000 Received: from dhcp-lys01-vla250-10-147-112-121.cisco.com (dhcp-lys01-vla250-10-147-112-121.cisco.com [10.147.112.121]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAF8NHCj007820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 08:23:18 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <20121115.080806.104125486.miyakawa@nttv6.jp> Date: Thu, 15 Nov 2012 09:23:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1785E568-1A33-49C3-AE56-336B87BFD335@employees.org> References: <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com> <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> <20121115.080806.104125486.miyakawa@nttv6.jp> To: Shin Miyakawa X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 08:23:20 -0000 Shin, > By the way... I think, you should NOT use 1.1.1.1 as example. > > 1/8 is not a document prefix nor private address space > but global space which belongs to APNIC. too right. s/1.1.1.1/192.0.2.1/g apologies for spreading the usage of 1/8. cheers, Ole From sunqi.csnet.thu@gmail.com Thu Nov 15 02:25:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A726021F85D8 for ; Thu, 15 Nov 2012 02:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVBLcGQHaoqN for ; Thu, 15 Nov 2012 02:25:51 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 30C1221F85D1 for ; Thu, 15 Nov 2012 02:25:51 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so996296pad.31 for ; Thu, 15 Nov 2012 02:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=qVVEh+5PSBS6wzyl8FOzwbXDWd4c/B34k/gp+WWfbGw=; b=dh8mXkiWjKvxs31oTFqKniW4SjfHXyPdix5Dn8i8ILOG3ZbbO3JnPgAXUaVElUqGJ7 x5u+naLFzIKuSlXTDGTR8Kepa3Zn8J2N/6vz4ZzKrKoZjzB9pGM5phzTMwFyEGFAwsOZ jm9FzVbRFF9M/Y8eNegUMmP9NrvLjCv4gQ3lwCXedg6ZmxgvC/aINjx7XzAPcuUh/E6n zTkWSfpa47DvmatECqWUKO9c3ehzhnVd6UAzB8DyubOYKYIMWAz37yU10X8UIDqBzX+b DSCwG42zjpWv4gY8L5iS4LfzNw3BSEO36i38ZpemULn+9oAixWlhctMnOHaxWm2dpA9f 5AEg== Received: by 10.68.202.72 with SMTP id kg8mr3188195pbc.134.1352975150803; Thu, 15 Nov 2012 02:25:50 -0800 (PST) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPS id l5sm7031026paz.14.2012.11.15.02.25.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 02:25:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun X-Priority: 3 In-Reply-To: <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> Date: Thu, 15 Nov 2012 13:40:42 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <42004742-C524-4E0E-9129-6014DA196E97@employees.org> , <0A6072E9-8A10-439D-8CCC-EA1B99C0EA2E@gmail.com> <2012111315564298406823@gmail.com>, <354EF357-BEC8-40D5-9C13-97CA55597A0D@gmail.com> <2012111321152612549156@gmail.com> <78D8DB5C-06B4-433C-8F6F-2AE648C9FA87@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: softwires WG Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 10:25:51 -0000 Ole, > in MAP aggregated mode you have: > 1.1.1.0/24 -> 2001:db8:XXXX::/48 Actually, the so called 'aggregated mode' is original MAP-E, with IPv4 = address and PSID embedded in the EA-bits field in End user IPv6 prefix. = Let me try to explain what you have 'aggregated'. 1.1.1.1:01 -> 2001:db8:101::/48 (EA-bits: 0x101) 1.1.1.1:02 -> 2001:db8:102::/48 (EA-bits: 0x102) 1.1.1.1:03 -> 2001:db8:103::/48 (EA-bits: 0x103) . . . The IPv4 address and port set are the same in what you called 'MAP 1:1'. = However, the corresponding IPv6 addresses are totally different. Because = one uses MAP algorithm, the other doesn't.=20 The original MAP-E achieves address sharing by embedding IPv4 suffix and = PSID into End User IPv6 prefix. But if the EA-bits is ZERO, PSID is also = ZERO. Nothing embedded in the IPv6 prefix. In this case, the so called = 'MAP 1:1' abandons the MAP algorithm and uses a per-subscriber stateful = kind method to achieve address sharing. That is NOT MAP-E.=20 So I question why 'MAP-E 1:1' bears the MAP-E name. Qi Sun On 2012-11-13, at =E4=B8=8B=E5=8D=889:46, Ole Tr=C3=B8an wrote: >> [Yuchi] Actually there is a 'binding' table on the AFTR, which = maintains matching between v4 A+P and v6 A, and there's no 'mapping with = address and port' in DS-Lite or Lw4over6 as in MAP. The main point here = is not about the literal difference between 'binding' and 'mapping', but = the difference between decoupling v4 & v6 and coupling v4 & v6. >=20 > let us assume we have a 1.1.1.0/24 for address sharing available with = 256 ports per user. >=20 > in MAP 1:1 you'd have: > 1.1.1.1:01/40 -> 2001:db8::1 > 1.1.1.1:02/40 -> 2001:db8::2 > 1.1.1.1:03/40 -> 2001:db8::3 > . > . > . >=20 > 64K rules. >=20 > in MAP aggregated mode you have: > 1.1.1.0/24 -> 2001:db8:XXXX::/48 >=20 > can you please show how the LW46 rules / binding /mapping whatever you = call them look like for 1:1 mode? >=20 > cheers, > Ole >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From iesg-secretary@ietf.org Thu Nov 15 13:39:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0263F21F8A0F; Thu, 15 Nov 2012 13:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nci0RAs79TpU; Thu, 15 Nov 2012 13:39:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6683421F89AC; Thu, 15 Nov 2012 13:39:18 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 13:39:18 -0800 Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:39:19 -0000 The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot/ No IPR declarations have been submitted directly on this I-D. From yiu_lee@cable.comcast.com Thu Nov 15 15:19:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4A721F8421 for ; Thu, 15 Nov 2012 15:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=-1.801, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id traTgENvd1LA for ; Thu, 15 Nov 2012 15:19:33 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id EB73A21E803F for ; Thu, 15 Nov 2012 15:19:32 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.34365726; Thu, 15 Nov 2012 18:11:12 -0500 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.131]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 18:19:28 -0500 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNw4eo0Uu9B7D7VEWPteYjSkPgrg== Date: Thu, 15 Nov 2012 23:19:27 +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.5.121010 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <2EB6A42656094F49BBCC126518FC1450@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:19:33 -0000 Hi Rajiv, With all due respect, I disagree the analogy. Comparing MAP-E to routing protocol is comparing apple to orange. MAP-E is not a routing protocol. MAP-E won't synchronize or exchange states between two BRs. Instead, MAP-E requires to statically provision states (aka rules) in the BR. Original MAP-E describes a mechanism to reduce user states in BR by using programatic logic. 1:1 MAP-E does not require any of the good stuff defined in MAP-E. I just found it odd to combine stateful and stateless mechanisms in a single draft and use a same name. Thanks, Yiu On 11/12/12 2:51 PM, "Rajiv Asati (rajiva)" wrote: > >Sure, and it is really a deployment choice (just like it is a deployment >choice to use a dynamic routing protocol to advertise host routes or >summary routes or both in an IP network). But that's not to say that we >need one protocol for advertising the host routes, and another for >advertising the summary routes. > >Cheers, >Rajiv > >-----Original Message----- >From: Yiu Lee >Date: Monday, November 12, 2012 1:33 PM >To: Rajiv Asati , Softwires-wg list >Subject: Re: [Softwires] MAP-E 1:1 for HA > >>I am not talking about whether a MAP-domain should support 1 or N CEs. >>What I am trying to say is MAP-E 1:1 requires the BR to know per >>subscriber information and the operator must pre-provision per-subscriber >>based rules to every BR in the same domain. In addition, the BR can't use >>programatic logic to reduce states. When the WG first decided to work on >>a >>"stateless" solution, the goal was to make BR as stateless as possible. >>MAP-E 1:1 in contrast requires to store all subscriber rules in the BR >>and >>can't derive the CE's IPv6 address using programatic logic. I found it >>odd >>to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a >>stateful solution to me. >> >> >>On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" wrote: >> >>> >>>One can define a MAP-domain consisting of 1 CE or N CEs. This is more of >>>a >>>deployment choice. >>> >>>Cheers, >>>Rajiv >>> >>> >>>-----Original Message----- >>>From: , Yiu Lee >>>Date: Friday, November 9, 2012 2:43 PM >>>To: Softwires-wg list >>>Subject: [Softwires] MAP-E 1:1 for HA >>> >>>>I have a question for the HA design concept of MAP-E 1:1. The central >>>>theme of MAP-E is to make BR as stateless as possible and use Anycast >>>>address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, >>>>the >>>>operator must have to pre-provision all >>>> the subscribe rules to all the BRs sharing the same Anycast address >>>>for >>>>reliable HA. This requires operators to carefully plan out which BRs >>>>support which subscribers. It is because BR is "per-subscriber >>>>stateful" >>>>in MAP-E 1:1 mode. Compared to the MAP-E design, >>>> HA in MAP-E only requires the operators to use the same set of rules >>>>to >>>>cover the entire domain. IMHO, this contradicts the original spirit of >>>>stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E >>>>name. MAP-E and 1:1 MAP-E are two completely >>>> different solutions and target to different deployment scenarios. I >>>>would love to hear others to comment in the ML how to resolve this >>>>issue. >>>> >>>> >>>>Thanks, >>>>Yiu >>>> >>>> >>>> >>>> >>> > From internet-drafts@ietf.org Thu Nov 15 17:52:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D363721E8043; Thu, 15 Nov 2012 17:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9MSfVfzG+5t; Thu, 15 Nov 2012 17:52:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825BE21E805F; Thu, 15 Nov 2012 17:51:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121116015158.5798.41310.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 17:51:58 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-07.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:52:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Deployment Considerations for Dual-Stack Lite Author(s) : Yiu L. Lee Roberta Maglione Carl Williams Christian Jacquenet Mohamed Boucadair Filename : draft-ietf-softwire-dslite-deployment-07.txt Pages : 14 Date : 2012-11-15 Abstract: This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment considerations and applicability of the Dual-Stack Lite architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-deployment-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-deployment-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leaf.yeh.sdo@gmail.com Fri Nov 16 04:43:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E70821F8779; Fri, 16 Nov 2012 04:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJpq3Sv7aklO; Fri, 16 Nov 2012 04:43:48 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C22F21F84BB; Fri, 16 Nov 2012 04:43:48 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1937142pbc.31 for ; Fri, 16 Nov 2012 04:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=DnwKaKxPA9f354wAEa8c2nwqqvB83iXnCK4UyXeBCTY=; b=CkUypkZ+cufflVacXnauI1JtHab/QTUWsgWakm5hj/nqZ7sJXn09WtONYCsso7RaPd gUzbKtFtSG3LrA+x5/Sw0ViGxJFi0TP6q+9PgtXWjgWCttn42bqgHIMAkqkU9/W+vHAh qRDK9eqpzMXa6A5Bu+OCodM+MjYXzRiDSO5KXGvHlefPaNaoDY/DL479WJ9AJ6S7crVZ jveX1eD4c2zf8ljsSZH5+95K3NIv2fwpit/pWZik2/7rOchxgUpxkL0iQXAgzZZ0c6NE CK0z+SWz0aI3kNMcd/H5t9NvvgqYAzMxQNAxCCi1Fo057aFXqsfJtDufXas7L734BRqL Evvg== Received: by 10.68.216.234 with SMTP id ot10mr8913771pbc.26.1353069828152; Fri, 16 Nov 2012 04:43:48 -0800 (PST) Received: from lst9242355d22a ([14.153.105.155]) by mx.google.com with ESMTPS id se4sm1195770pbb.13.2012.11.16.04.43.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 04:43:47 -0800 (PST) From: "Leaf Yeh" To: References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> In-Reply-To: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> Date: Fri, 16 Nov 2012 20:43:47 +0800 Message-ID: <50a63503.848f440a.6460.6ac1@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3Dea+1vtvDT4NuRzq0ZZgefRaMjQAfhzhg Content-Language: zh-cn Cc: softwires@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 12:43:49 -0000 Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot / No IPR declarations have been submitted directly on this I-D. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From roberta.maglione@telecomitalia.it Fri Nov 16 05:13:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB16121F8D0A; Fri, 16 Nov 2012 05:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMP3KZ3+zAFn; Fri, 16 Nov 2012 05:13:03 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id AA36121F8C71; Fri, 16 Nov 2012 05:13:02 -0800 (PST) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 16 Nov 2012 14:13:01 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Fri, 16 Nov 2012 14:13:01 +0100 From: Maglione Roberta To: 'Leaf Yeh' , "ietf@ietf.org" Date: Fri, 16 Nov 2012 14:13:00 +0100 Thread-Topic: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Thread-Index: Ac3Dea+1vtvDT4NuRzq0ZZgefRaMjQAfhzhgAADf3CA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> <50a63503.848f440a.6460.6ac1@mx.google.com> In-Reply-To: <50a63503.848f440a.6460.6ac1@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , " WG" Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 13:13:04 -0000 Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent= > at time T1 has not responded, the DHCP client enters the REBINDING stat= e > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwires@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameter= s .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent a= t time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) t= o Proposed Standard The IESG has received a request from the Softwires WG (softwire) to conside= r the following document: - 'RADIUS Attribute for 6rd' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballo= t / No IPR declarations have been submitted directly on this I-D. _______________________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From leaf.yeh.sdo@gmail.com Fri Nov 16 05:57:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E555321F8769; Fri, 16 Nov 2012 05:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEiJ3z0p3ASn; Fri, 16 Nov 2012 05:57:51 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B30CF21F8661; Fri, 16 Nov 2012 05:57:51 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb11so1900640pad.31 for ; Fri, 16 Nov 2012 05:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=s9DkzeQ7c91TGu2rh5aAyXdJlulnUeUzz1AhpAk6ZyA=; b=RCZB5hJoNF6HwfKBXjoGjk9yzES1e0nGFtCEmq8zByF8k/D/dzjslvNAd698U83DqJ FZInyR2IqOdgYYZC/ZIxy8PHJimwscGmppIwBuFbfKXaYMIZ5gaRuqcZJPh036lTW6dS yjMuiSon8pe9L0KGt/I8d6eLtpZw3A+TV8set/5HvfIRuwrP1V3/xCryQBYDHssvzfK4 wD3X/EAGxjpxkREhJSq4E2Cg4vrRBGJHb+rw0cH2FlwkLtD+Gzv4i+YjDTIjokX1tEXr P00rhEqttFvQT+e06VYvajob73fiF9AenE6Rx4tbFIHczHRNJjOpCzIpJTEXc8gmSEnW gVqA== Received: by 10.68.234.201 with SMTP id ug9mr9438910pbc.63.1353074270985; Fri, 16 Nov 2012 05:57:50 -0800 (PST) Received: from lst9242355d22a ([14.153.105.155]) by mx.google.com with ESMTPS id o11sm1280720pby.8.2012.11.16.05.57.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 05:57:49 -0800 (PST) From: "Leaf Yeh" To: "'Maglione Roberta'" , References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> <50a63503.848f440a.6460.6ac1@mx.google.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> Date: Fri, 16 Nov 2012 21:57:43 +0800 Message-ID: <50a6465d.4b53440a.7e28.73cc@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3Dea+1vtvDT4NuRzq0ZZgefRaMjQAfhzhgAADf3CAAARUoIA== Content-Language: zh-cn Cc: softwires@ietf.org, dhcwg@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 13:57:53 -0000 According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Correct but not accurate. The client enters the rebinding state after T2 expired. How about to update the text to be 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING state and attempts to contact any possible server. '? Best Regards, Leaf -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: Friday, November 16, 2012 9:13 PM To: 'Leaf Yeh'; ietf@ietf.org Cc: softwires@ietf.org; WG Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent > at time T1 has not responded, the DHCP client enters the REBINDING state > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwires@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent at time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Attribute for 6rd' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballot / No IPR declarations have been submitted directly on this I-D. _______________________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. From roberta.maglione@telecomitalia.it Fri Nov 16 06:09:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B3921F8590; Fri, 16 Nov 2012 06:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+Boe+t0GLHe; Fri, 16 Nov 2012 06:09:17 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 43DA221F8521; Fri, 16 Nov 2012 06:09:16 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.279.5; Fri, 16 Nov 2012 15:09:13 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Fri, 16 Nov 2012 15:09:11 +0100 From: Maglione Roberta To: 'Leaf Yeh' , 'Sheng Jiang' Date: Fri, 16 Nov 2012 15:09:11 +0100 Thread-Topic: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Thread-Index: Ac3Dea+1vtvDT4NuRzq0ZZgefRaMjQAfhzhgAADf3CAAARUoIAAA6biw Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEB@GRFMBX704BA020.griffon.local> References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> <50a63503.848f440a.6460.6ac1@mx.google.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> <50a6465d.4b53440a.7e28.73cc@mx.google.com> In-Reply-To: <50a6465d.4b53440a.7e28.73cc@mx.google.com> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:09:18 -0000 Leaf, In my opinion current text is fine and inline with RFC2131, while the text = you are proposing is not completely accurate because it does not clarify "w= hich DHCP Server" has not replied. 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING stat= e and attempts to contact any possible server. ' Sheng, As original author of this text, what do you think? Thanks, Roberta -----Original Message----- From: Leaf Yeh [mailto:leaf.yeh.sdo@gmail.com] Sent: Friday, November 16, 2012 2:58 PM To: Maglione Roberta; ietf@ietf.org Cc: softwires@ietf.org; dhcwg@ietf.org Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Correct but not accurate. The client enters the rebinding state after T2 expired. How about to update the text to be 'If the DHCP server has not replied the DHCPREQUEST message till T2, the DHCP client enters into the REBINDING stat= e and attempts to contact any possible server. '? Best Regards, Leaf -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: Friday, November 16, 2012 9:13 PM To: 'Leaf Yeh'; ietf@ietf.org Cc: softwires@ietf.org; WG Subject: RE: [Softwires] Last Call: (RADIUS Attribute for 6rd) t= o Proposed Standard Hi Leaf, > Section 3 - If the DHCP server to which the DHCP Request message was sent > at time T1 has not responded, the DHCP client enters the REBINDING state > and attempts to contact any server. > Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Why T2? According to section 4.4.5 of RFC 2131: " At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease." [..] " If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease." The DHCPREQUEST is sent at T1, in my opinion the current text is correct. Thanks Regards, Roberta -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Leaf Yeh Sent: Friday, November 16, 2012 1:44 PM To: ietf@ietf.org Cc: softwires@ietf.org Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) t= o Proposed Standard Section 3 - After the BNG responds to the user with an Advertise message, the user requests for a DHCP 6rd Option by carrying a Parameter Request option (55) [RFC2132]. Per the Figure 1 in Section 3, the above 'Advertise message' sounds the DHCPv4 message of 'DHCPOFFER (2)'. (http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameter= s .xml) Section 3 - If the DHCP server to which the DHCP Request message was sent a= t time T1 has not responded, the DHCP client enters the REBINDING state and attempts to contact any server. Per the Figure 5 in RFC2131, the above 'T1' sounds 'T2'. (http://www.rfc-editor.org/rfc/rfc2131.txt) Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, November 16, 2012 5:39 AM To: IETF-Announce Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Attribute for 6rd) t= o Proposed Standard The IESG has received a request from the Softwires WG (softwire) to conside= r the following document: - 'RADIUS Attribute for 6rd' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ballo= t / No IPR declarations have been submitted directly on this I-D. _______________________________________________ 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intende= d recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From jiangsheng@huawei.com Sun Nov 18 18:10:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251BE21F84CF; Sun, 18 Nov 2012 18:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiCYjp0KHRRq; Sun, 18 Nov 2012 18:10:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4317F21F84CC; Sun, 18 Nov 2012 18:10:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMX51124; Mon, 19 Nov 2012 02:10:29 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 02:10:05 +0000 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Nov 2012 02:10:27 +0000 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.6]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 10:10:24 +0800 From: Sheng Jiang To: Maglione Roberta , "'Leaf Yeh'" Thread-Topic: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard Thread-Index: AQHNxAP5LyU1QcTX80yMPtxTT00nhZfwafBg Date: Mon, 19 Nov 2012 02:10:23 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239F8ECAC@szxeml545-mbx.china.huawei.com> References: <20121115213918.3949.85119.idtracker@ietfa.amsl.com> <50a63503.848f440a.6460.6ac1@mx.google.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEA@GRFMBX704BA020.griffon.local> <50a6465d.4b53440a.7e28.73cc@mx.google.com> <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEB@GRFMBX704BA020.griffon.local> In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE519AC44BEB@GRFMBX704BA020.griffon.local> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , "ietf@ietf.org" Subject: Re: [Softwires] Last Call: (RADIUS Attribute for 6rd) to Proposed Standard X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 02:10:37 -0000 SGksIFJvYmVydGEgYW5kIExlYWYsDQoNCkNhcmVmdWxseSBjaGVja2VkIFJGQzIxMzEsIHRoZSBv cmlnaW5hbCB0ZXh0IHdhcyByaWdodCwgYnV0IG5vdCBjbGVhcmx5IGRlZmluZSB0aGUgdGltZSB0 aGF0IGNsaWVudCBlbnRlcnMgUkVCSU5ESU5HIHN0YXRlLiBTbyBMZWFmJ3MgY29tbWVudHMgYWxz byByaWdodC4gTmV3IHRleHQgd2lsbCBiZSB0aGUgYmVsb3cuIEl0IHdvdWxkIGJlIGFkZGVkIGFm dGVyIEFEJ3MgaW5zdHJ1Y3Rpb24gZm9yIG5leHQgdXBkYXRlLCBtYXliZSB3aXRoIG90aGVyIGNv bW1lbnRzIGZyb20gSUVTRy4gDQoNCklmIHRoZSBESENQIHNlcnZlciB0byB3aGljaCB0aGUgREhD UCBSZXF1ZXN0IG1lc3NhZ2Ugd2FzIHNlbnQgYXQgdGltZSANCiAgIFQxIGhhcyBub3QgcmVzcG9u ZGVkICJ0aWxsIFQyIiwgdGhlIERIQ1AgY2xpZW50IGVudGVycyB0aGUgUkVCSU5ESU5HIHN0YXRl IGFuZCANCiAgIGF0dGVtcHRzIHRvIGNvbnRhY3QgYW55IHNlcnZlci4NCg0KTWFueSB0aGFua3Mg YW5kIGJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogTWFnbGlvbmUgUm9iZXJ0YSBbbWFpbHRvOnJvYmVydGEubWFnbGlvbmVAdGVsZWNv bWl0YWxpYS5pdF0NCj5TZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDEwOjA5IFBNDQo+ VG86ICdMZWFmIFllaCc7IFNoZW5nIEppYW5nDQo+Q2M6IHNvZnR3aXJlc0BpZXRmLm9yZzsgZGhj d2dAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogW1NvZnR3aXJlc10gTGFz dCBDYWxsOiA8ZHJhZnQtaWV0Zi1zb2Z0d2lyZS02cmQtcmFkaXVzLWF0dHJpYi0wNy50eHQ+DQo+ KFJBRElVUyBBdHRyaWJ1dGUgZm9yIDZyZCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4NCj5MZWFm LA0KPkluIG15IG9waW5pb24gY3VycmVudCB0ZXh0IGlzIGZpbmUgYW5kIGlubGluZSB3aXRoIFJG QzIxMzEsIHdoaWxlIHRoZSB0ZXh0IHlvdQ0KPmFyZSBwcm9wb3NpbmcgaXMgbm90IGNvbXBsZXRl bHkgYWNjdXJhdGUgYmVjYXVzZSBpdCBkb2VzIG5vdCBjbGFyaWZ5ICJ3aGljaA0KPkRIQ1AgU2Vy dmVyIiBoYXMgbm90IHJlcGxpZWQuDQo+DQo+J0lmIHRoZSBESENQIHNlcnZlciBoYXMgbm90IHJl cGxpZWQgdGhlDQo+REhDUFJFUVVFU1QgbWVzc2FnZSB0aWxsIFQyLCB0aGUgREhDUCBjbGllbnQg ZW50ZXJzIGludG8gdGhlIFJFQklORElORw0KPnN0YXRlDQo+YW5kIGF0dGVtcHRzIHRvIGNvbnRh Y3QgYW55IHBvc3NpYmxlIHNlcnZlci4gJw0KPg0KPlNoZW5nLA0KPiBBcyBvcmlnaW5hbCBhdXRo b3Igb2YgdGhpcyB0ZXh0LCB3aGF0IGRvIHlvdSB0aGluaz8NCj4NCj5UaGFua3MsDQo+Um9iZXJ0 YQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogTGVhZiBZZWggW21haWx0 bzpsZWFmLnllaC5zZG9AZ21haWwuY29tXQ0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIw MTIgMjo1OCBQTQ0KPlRvOiBNYWdsaW9uZSBSb2JlcnRhOyBpZXRmQGlldGYub3JnDQo+Q2M6IHNv ZnR3aXJlc0BpZXRmLm9yZzsgZGhjd2dAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogW1NvZnR3aXJl c10gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1zb2Z0d2lyZS02cmQtcmFkaXVzLWF0dHJpYi0wNy50 eHQ+DQo+KFJBRElVUyBBdHRyaWJ1dGUgZm9yIDZyZCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4N Cj48Um9iZXJ0YT4gQWNjb3JkaW5nIHRvIHNlY3Rpb24gNC40LjUgb2YgUkZDIDIxMzE6DQo+IiBB dCB0aW1lIFQxIHRoZSBjbGllbnQgbW92ZXMgdG8gUkVORVdJTkcgc3RhdGUgYW5kIHNlbmRzICh2 aWEgdW5pY2FzdCkNCj4gICBhIERIQ1BSRVFVRVNUIG1lc3NhZ2UgdG8gdGhlIHNlcnZlciB0byBl eHRlbmQgaXRzIGxlYXNlLiINCj5bLi5dDQo+IiBJZiBubyBESENQQUNLIGFycml2ZXMgYmVmb3Jl IHRpbWUgVDIsIHRoZSBjbGllbnQgbW92ZXMgdG8gUkVCSU5ESU5HDQo+ICAgc3RhdGUgYW5kIHNl bmRzICh2aWEgYnJvYWRjYXN0KSBhIERIQ1BSRVFVRVNUIG1lc3NhZ2UgdG8gZXh0ZW5kIGl0cw0K PiAgIGxlYXNlLiINCj5UaGUgREhDUFJFUVVFU1QgaXMgc2VudCBhdCBUMSwgaW4gbXkgb3Bpbmlv biB0aGUgY3VycmVudCB0ZXh0IGlzIGNvcnJlY3QuDQo+PC9Sb2JlcnRhPg0KPg0KPg0KPkNvcnJl Y3QgYnV0IG5vdCBhY2N1cmF0ZS4gVGhlIGNsaWVudCBlbnRlcnMgdGhlIHJlYmluZGluZyBzdGF0 ZSBhZnRlciBUMg0KPmV4cGlyZWQuDQo+DQo+SG93IGFib3V0IHRvIHVwZGF0ZSB0aGUgdGV4dCB0 byBiZSAnSWYgdGhlIERIQ1Agc2VydmVyIGhhcyBub3QgcmVwbGllZCB0aGUNCj5ESENQUkVRVUVT VCBtZXNzYWdlIHRpbGwgVDIsIHRoZSBESENQIGNsaWVudCBlbnRlcnMgaW50byB0aGUgUkVCSU5E SU5HDQo+c3RhdGUNCj5hbmQgYXR0ZW1wdHMgdG8gY29udGFjdCBhbnkgcG9zc2libGUgc2VydmVy LiAnPw0KPg0KPg0KPkJlc3QgUmVnYXJkcywNCj5MZWFmDQo+DQo+DQo+DQo+LS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBNYWdsaW9uZSBSb2JlcnRhIFttYWlsdG86cm9iZXJ0YS5t YWdsaW9uZUB0ZWxlY29taXRhbGlhLml0XQ0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIw MTIgOToxMyBQTQ0KPlRvOiAnTGVhZiBZZWgnOyBpZXRmQGlldGYub3JnDQo+Q2M6IHNvZnR3aXJl c0BpZXRmLm9yZzsgPGRoY3dnQGlldGYub3JnPiBXRw0KPlN1YmplY3Q6IFJFOiBbU29mdHdpcmVz XSBMYXN0IENhbGw6DQo+PGRyYWZ0LWlldGYtc29mdHdpcmUtNnJkLXJhZGl1cy1hdHRyaWItMDcu dHh0PiAoUkFESVVTIEF0dHJpYnV0ZSBmb3IgNnJkKSB0bw0KPlByb3Bvc2VkIFN0YW5kYXJkDQo+ DQo+SGkgTGVhZiwNCj4+IFNlY3Rpb24gMyAtIElmIHRoZSBESENQIHNlcnZlciB0byB3aGljaCB0 aGUgREhDUCBSZXF1ZXN0IG1lc3NhZ2Ugd2FzIHNlbnQNCj4+IGF0IHRpbWUgIFQxIGhhcyBub3Qg cmVzcG9uZGVkLCB0aGUgREhDUCBjbGllbnQgZW50ZXJzIHRoZSBSRUJJTkRJTkcNCj5zdGF0ZQ0K Pj4gYW5kICBhdHRlbXB0cyB0byBjb250YWN0IGFueSBzZXJ2ZXIuDQo+DQo+PiBQZXIgdGhlIEZp Z3VyZSA1IGluIFJGQzIxMzEsIHRoZSBhYm92ZSAnVDEnIHNvdW5kcyAnVDInLg0KPihodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMTMxLnR4dCkNCj4NCj5XaHkgVDI/DQo+QWNjb3Jk aW5nIHRvIHNlY3Rpb24gNC40LjUgb2YgUkZDIDIxMzE6DQo+IiBBdCB0aW1lIFQxIHRoZSBjbGll bnQgbW92ZXMgdG8gUkVORVdJTkcgc3RhdGUgYW5kIHNlbmRzICh2aWEgdW5pY2FzdCkNCj4gICBh IERIQ1BSRVFVRVNUIG1lc3NhZ2UgdG8gdGhlIHNlcnZlciB0byBleHRlbmQgaXRzIGxlYXNlLiIN Cj5bLi5dDQo+DQo+IiBJZiBubyBESENQQUNLIGFycml2ZXMgYmVmb3JlIHRpbWUgVDIsIHRoZSBj bGllbnQgbW92ZXMgdG8gUkVCSU5ESU5HDQo+ICAgc3RhdGUgYW5kIHNlbmRzICh2aWEgYnJvYWRj YXN0KSBhIERIQ1BSRVFVRVNUIG1lc3NhZ2UgdG8gZXh0ZW5kIGl0cw0KPiAgIGxlYXNlLiINCj4N Cj5UaGUgREhDUFJFUVVFU1QgaXMgc2VudCBhdCBUMSwgaW4gbXkgb3BpbmlvbiB0aGUgY3VycmVu dCB0ZXh0IGlzIGNvcnJlY3QuDQo+VGhhbmtzDQo+UmVnYXJkcywNCj5Sb2JlcnRhDQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPkJlaGFsZiBPZiBMZWFm IFllaA0KPlNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTYsIDIwMTIgMTo0NCBQTQ0KPlRvOiBpZXRm QGlldGYub3JnDQo+Q2M6IHNvZnR3aXJlc0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbU29mdHdp cmVzXSBMYXN0IENhbGw6DQo+PGRyYWZ0LWlldGYtc29mdHdpcmUtNnJkLXJhZGl1cy1hdHRyaWIt MDcudHh0PiAoUkFESVVTIEF0dHJpYnV0ZSBmb3IgNnJkKSB0bw0KPlByb3Bvc2VkIFN0YW5kYXJk DQo+DQo+U2VjdGlvbiAzIC0gQWZ0ZXIgdGhlIEJORyByZXNwb25kcyB0byB0aGUgdXNlciB3aXRo DQo+ICAgYW4gQWR2ZXJ0aXNlIG1lc3NhZ2UsIHRoZSB1c2VyIHJlcXVlc3RzIGZvciBhIERIQ1Ag NnJkIE9wdGlvbiBieQ0KPiAgIGNhcnJ5aW5nIGEgUGFyYW1ldGVyIFJlcXVlc3Qgb3B0aW9uICg1 NSkgW1JGQzIxMzJdLg0KPg0KPlBlciB0aGUgRmlndXJlIDEgaW4gU2VjdGlvbiAzLCB0aGUgYWJv dmUgJ0FkdmVydGlzZSBtZXNzYWdlJyBzb3VuZHMgdGhlDQo+REhDUHY0IG1lc3NhZ2Ugb2YgJ0RI Q1BPRkZFUiAoMiknLg0KPihodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2Jvb3RwLWRo Y3AtcGFyYW1ldGVycy9ib290cC1kaGNwLXBhcmENCj5tZXRlcnMNCj4ueG1sKQ0KPg0KPg0KPlNl Y3Rpb24gMyAtIElmIHRoZSBESENQIHNlcnZlciB0byB3aGljaCB0aGUgREhDUCBSZXF1ZXN0IG1l c3NhZ2Ugd2FzIHNlbnQNCj5hdA0KPnRpbWUNCj4gICBUMSBoYXMgbm90IHJlc3BvbmRlZCwgdGhl IERIQ1AgY2xpZW50IGVudGVycyB0aGUgUkVCSU5ESU5HIHN0YXRlIGFuZA0KPiAgIGF0dGVtcHRz IHRvIGNvbnRhY3QgYW55IHNlcnZlci4NCj4NCj5QZXIgdGhlIEZpZ3VyZSA1IGluIFJGQzIxMzEs IHRoZSBhYm92ZSAnVDEnIHNvdW5kcyAnVDInLg0KPihodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L3JmYy9yZmMyMTMxLnR4dCkNCj4NCj4NCj5CZXN0IFJlZ2FyZHMsDQo+TGVhZg0KPg0KPg0KPg0K Pg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc29mdHdpcmVzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj5CZWhh bGYgT2YgVGhlIElFU0cNCj5TZW50OiBGcmlkYXksIE5vdmVtYmVyIDE2LCAyMDEyIDU6MzkgQU0N Cj5UbzogSUVURi1Bbm5vdW5jZQ0KPkNjOiBzb2Z0d2lyZXNAaWV0Zi5vcmcNCj5TdWJqZWN0OiBb U29mdHdpcmVzXSBMYXN0IENhbGw6DQo+PGRyYWZ0LWlldGYtc29mdHdpcmUtNnJkLXJhZGl1cy1h dHRyaWItMDcudHh0PiAoUkFESVVTIEF0dHJpYnV0ZSBmb3IgNnJkKSB0bw0KPlByb3Bvc2VkIFN0 YW5kYXJkDQo+DQo+DQo+VGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBT b2Z0d2lyZXMgV0cgKHNvZnR3aXJlKSB0byBjb25zaWRlcg0KPnRoZSBmb2xsb3dpbmcgZG9jdW1l bnQ6DQo+LSAnUkFESVVTIEF0dHJpYnV0ZSBmb3IgNnJkJw0KPiAgPGRyYWZ0LWlldGYtc29mdHdp cmUtNnJkLXJhZGl1cy1hdHRyaWItMDcudHh0PiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KPg0KPlRo ZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFu ZCBzb2xpY2l0cyBmaW5hbA0KPmNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBz dWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCj5pZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMg YnkgMjAxMi0xMS0yOS4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJlDQo+c2VudCB0byBp ZXNnQGlldGYub3JnIGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZSBi ZWdpbm5pbmcNCj5vZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5n Lg0KPg0KPkFic3RyYWN0DQo+DQo+DQo+ICAgSVB2NiBSYXBpZCBEZXBsb3ltZW50ICg2cmQpIGlz IG9uZSBvZiB0aGUgbW9zdCBwb3B1bGFyIG1ldGhvZHMgdG8NCj4gICBwcm92aWRlIGJvdGggSVB2 NCBhbmQgSVB2NiBjb25uZWN0aXZpdHkgc2VydmljZXMgc2ltdWx0YW5lb3VzbHkNCj4gICBkdXJp bmcgdGhlIElQdjQvSVB2NiBjby1leGlzdGluZyBwZXJpb2QuIFRoZSBEeW5hbWljIEhvc3QNCj4g ICBDb25maWd1cmF0aW9uIFByb3RvY29sIChESENQKSA2cmQgb3B0aW9uIGhhcyBiZWVuIGRlZmlu ZWQgdG8NCj4gICBjb25maWd1cmUgNnJkIEN1c3RvbWVyIEVkZ2UgKENFKS4gSG93ZXZlciwgaW4g bWFueSBuZXR3b3JrcywgdGhlDQo+ICAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBtYXkgYmUg c3RvcmVkIGluIEF1dGhlbnRpY2F0aW9uDQo+ICAgQXV0aG9yaXphdGlvbiBhbmQgQWNjb3VudGlu ZyAoQUFBKSBzZXJ2ZXJzIHdoaWxlIHVzZXIgY29uZmlndXJhdGlvbg0KPiAgIGlzIG1haW5seSBm cm9tIEJyb2FkYmFuZCBOZXR3b3JrIEdhdGV3YXkgKEJORykgdGhyb3VnaCBESENQDQo+cHJvdG9j b2wuDQo+ICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgUmVtb3RlIEF1dGhlbnRpY2F0aW9uIERp YWwgSW4gVXNlciBTZXJ2aWNlDQo+ICAgKFJBRElVUykgYXR0cmlidXRlIHRoYXQgY2FycmllcyA2 cmQgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBmcm9tDQo+ICAgQUFBIHNlcnZlciB0byBCTkcu DQo+DQo+DQo+DQo+DQo+DQo+DQo+VGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KPmh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zb2Z0d2lyZS02cmQtcmFkaXVz LWF0dHJpYi8NCj4NCj5JRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+aHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNvZnR3aXJlLTZyZC1yYWRpdXMt YXR0cmliL2JhbGxvdA0KPi8NCj4NCj4NCj5ObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBz dWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+DQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+ U29mdHdpcmVzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zb2Z0d2lyZXMNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPlNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj5Tb2Z0d2lyZXNAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPg0KPlF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFt ZW50ZSBhbGxlDQo+cGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFs c2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZQ0KPmRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3Rl IGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYQ0KPmFiYmlh dGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50 ZSBwcmVnYXRpIGRpDQo+ZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUg ZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhDQo+ZGlzdHJ1emlvbmUsIEdyYXppZS4NCj4NCj5UaGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRh aW4gcHJpdmlsZWdlZA0KPmluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMp IG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsDQo+cHJpbnRpbmcgb3IgdXNlIGJ5IGFueWJv ZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPnJl Y2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBh bmQgYWR2aXNlIHRoZQ0KPnNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQo+DQo+DQo+ UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1 c2l2YW1lbnRlIGFsbGUNCj5wZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBv IHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhDQo+Y29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3JhDQo+ YWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVz ZW1lbnRlIHByZWdhdGkgZGkNCj5kYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0 ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWENCj5kaXN0cnV6aW9uZSwgR3JhemllLg0KPg0K PlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkg Y29udGFpbiBwcml2aWxlZ2VkDQo+aW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRoZSBhZGRyZXNz ZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywNCj5wcmludGluZyBvciB1c2UgYnkg YW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk DQo+cmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1l bnRzIGFuZCBhZHZpc2UgdGhlDQo+c2VuZGVyIGJ5IHJldHVybiBlLW1haWwsIFRoYW5rcy4NCg0K From wdec.ietf@gmail.com Mon Nov 26 00:25:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E80121F86B8 for ; Mon, 26 Nov 2012 00:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF2Vu0nuzNcl for ; Mon, 26 Nov 2012 00:25:12 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 235E221F86B9 for ; Mon, 26 Nov 2012 00:25:11 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so3943670eaa.31 for ; Mon, 26 Nov 2012 00:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bBhApyA5OuuUH2b+ZwJ1DMzRptldem8ynN4Q1tvPjjk=; b=s9EhuoybVnMoWpXt2GptWNulTUKdbhxIelp+tIUyrIpJXNIZtrfy0vJsCt3R0fpsqC MFrrQi5G0w7zqRMIT/tmkcu0PThDl8gI0K8/zSlXVCk2fo6ocAIbnW019jO8Jx5etOpL L4MPaYbpyIhtN3bBblx3b754WOow9epy8GaTSyFusQ2Ra0vwbCW3mnrfoe6jUGAXT8fC 2KsKGrrM8w9oDKCXfFRpnx/5mpnI2MCP40gE8Ngs8FbVEuFV8Btdim2it59D/bKcF1aY vn7aE+bCLhbFK7xhgoyG6+IpAEUcmsKub/FMPsGyheO6nc8pk6GIry+V6ft74uezlqA0 vLMA== MIME-Version: 1.0 Received: by 10.14.205.65 with SMTP id i41mr43251833eeo.2.1353918311146; Mon, 26 Nov 2012 00:25:11 -0800 (PST) Received: by 10.14.219.72 with HTTP; Mon, 26 Nov 2012 00:25:10 -0800 (PST) In-Reply-To: References: Date: Mon, 26 Nov 2012 09:25:10 +0100 Message-ID: From: Wojciech Dec To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=047d7b3436a2fda5ff04cf61ab83 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 08:25:13 -0000 --047d7b3436a2fda5ff04cf61ab83 Content-Type: text/plain; charset=ISO-8859-1 Yiu, What's your definition of "state" (as in stateful)? -Woj. On 16 November 2012 00:19, Lee, Yiu wrote: > Hi Rajiv, > > With all due respect, I disagree the analogy. Comparing MAP-E to routing > protocol is comparing apple to orange. MAP-E is not a routing protocol. > MAP-E won't synchronize or exchange states between two BRs. Instead, MAP-E > requires to statically provision states (aka rules) in the BR. Original > MAP-E describes a mechanism to reduce user states in BR by using > programatic logic. 1:1 MAP-E does not require any of the good stuff > defined in MAP-E. I just found it odd to combine stateful and stateless > mechanisms in a single draft and use a same name. > > Thanks, > Yiu > > > On 11/12/12 2:51 PM, "Rajiv Asati (rajiva)" wrote: > > > > >Sure, and it is really a deployment choice (just like it is a deployment > >choice to use a dynamic routing protocol to advertise host routes or > >summary routes or both in an IP network). But that's not to say that we > >need one protocol for advertising the host routes, and another for > >advertising the summary routes. > > > >Cheers, > >Rajiv > > > >-----Original Message----- > >From: Yiu Lee > >Date: Monday, November 12, 2012 1:33 PM > >To: Rajiv Asati , Softwires-wg list > > >Subject: Re: [Softwires] MAP-E 1:1 for HA > > > >>I am not talking about whether a MAP-domain should support 1 or N CEs. > >>What I am trying to say is MAP-E 1:1 requires the BR to know per > >>subscriber information and the operator must pre-provision per-subscriber > >>based rules to every BR in the same domain. In addition, the BR can't use > >>programatic logic to reduce states. When the WG first decided to work on > >>a > >>"stateless" solution, the goal was to make BR as stateless as possible. > >>MAP-E 1:1 in contrast requires to store all subscriber rules in the BR > >>and > >>can't derive the CE's IPv6 address using programatic logic. I found it > >>odd > >>to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a > >>stateful solution to me. > >> > >> > >>On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" wrote: > >> > >>> > >>>One can define a MAP-domain consisting of 1 CE or N CEs. This is more of > >>>a > >>>deployment choice. > >>> > >>>Cheers, > >>>Rajiv > >>> > >>> > >>>-----Original Message----- > >>>From: , Yiu Lee > >>>Date: Friday, November 9, 2012 2:43 PM > >>>To: Softwires-wg list > >>>Subject: [Softwires] MAP-E 1:1 for HA > >>> > >>>>I have a question for the HA design concept of MAP-E 1:1. The central > >>>>theme of MAP-E is to make BR as stateless as possible and use Anycast > >>>>address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, > >>>>the > >>>>operator must have to pre-provision all > >>>> the subscribe rules to all the BRs sharing the same Anycast address > >>>>for > >>>>reliable HA. This requires operators to carefully plan out which BRs > >>>>support which subscribers. It is because BR is "per-subscriber > >>>>stateful" > >>>>in MAP-E 1:1 mode. Compared to the MAP-E design, > >>>> HA in MAP-E only requires the operators to use the same set of rules > >>>>to > >>>>cover the entire domain. IMHO, this contradicts the original spirit of > >>>>stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-E > >>>>name. MAP-E and 1:1 MAP-E are two completely > >>>> different solutions and target to different deployment scenarios. I > >>>>would love to hear others to comment in the ML how to resolve this > >>>>issue. > >>>> > >>>> > >>>>Thanks, > >>>>Yiu > >>>> > >>>> > >>>> > >>>> > >>> > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --047d7b3436a2fda5ff04cf61ab83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yiu,

What's your definition of "state" (as in stateful= )?

-Woj.

On 16 November 2012 00:19= , Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Hi Rajiv,

With all due respect, I disagree the analogy. Comparing MAP-E to routing protocol is comparing apple to orange. MAP-E is not a routing protocol.
MAP-E won't synchronize or exchange states between two BRs. Instead, MA= P-E
requires to statically provision states (aka rules) in the BR. Original
MAP-E describes a mechanism to reduce user states in BR by using
programatic logic. 1:1 MAP-E does not require any of the good stuff
defined in MAP-E. I just found it odd to combine stateful and stateless
mechanisms in a single draft and use a same name.

Thanks,
Yiu


On 11/12/12 2:51 PM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:

>
>Sure, and it is really a deployment choice (just like it is a deploymen= t
>choice to use a dynamic routing protocol to advertise host routes or >summary routes or both in an IP network). But that's not to say tha= t we
>need one protocol for advertising the host routes, and another for
>advertising the summary routes.
>
>Cheers,
>Rajiv
>
>-----Original Message-----
>From: Yiu Lee <Yiu_Lee@= Cable.Comcast.com>
>Date: Monday, November 12, 2012 1:33 PM
>To: Rajiv Asati <rajiva@cisco.co= m>, Softwires-wg list <soft= wires@ietf.org>
>Subject: Re: [Softwires] MAP-E 1:1 for HA
>
>>I am not talking about whether a MAP-domain should support 1 or N C= Es.
>>What I am trying to say is MAP-E 1:1 requires the BR to know per >>subscriber information and the operator must pre-provision per-subs= criber
>>based rules to every BR in the same domain. In addition, the BR can= 't use
>>programatic logic to reduce states. When the WG first decided to wo= rk on
>>a
>>"stateless" solution, the goal was to make BR as stateles= s as possible.
>>MAP-E 1:1 in contrast requires to store all subscriber rules in the= BR
>>and
>>can't derive the CE's IPv6 address using programatic logic.= I found it
>>odd
>>to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 loo= ks a
>>stateful solution to me.
>>
>>
>>On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" <rajiva@cisco.com> wrote:
>>
>>>
>>>One can define a MAP-domain consisting of 1 CE or N CEs. This i= s more of
>>>a
>>>deployment choice.
>>>
>>>Cheers,
>>>Rajiv
>>>
>>>
>>>-----Original Message-----
>>>From: <Lee>, Yiu Lee <Yiu_Lee@Cable.Comcast.com>
>>>Date: Friday, November 9, 2012 2:43 PM
>>>To: Softwires-wg list <softwires@ietf.org>
>>>Subject: [Softwires] MAP-E 1:1 for HA
>>>
>>>>I have a question for the HA design concept of MAP-E 1:1. T= he central
>>>>theme of MAP-E is to make BR as stateless as possible and u= se Anycast
>>>>address to identify the MAP-E BR. However, if we use MAP-E = 1:1 mode,
>>>>the
>>>>operator must have to pre-provision all
>>>> the subscribe rules to all the BRs sharing the same Anycas= t address
>>>>for
>>>>reliable HA. This requires operators to carefully plan out = which BRs
>>>>support which subscribers. It is because BR is "per-su= bscriber
>>>>stateful"
>>>>in MAP-E 1:1 mode. Compared to the MAP-E design,
>>>> HA in MAP-E only requires the operators to use the same se= t of rules
>>>>to
>>>>cover the entire domain. IMHO, this contradicts =A0the orig= inal spirit of
>>>>stateless solution and always puzzles me why MAP-E 1:1 bear= s the MAP-E
>>>>name. MAP-E and 1:1 MAP-E are two completely
>>>> different solutions and target to different deployment sce= narios. I
>>>>would love to hear others to comment in the ML how to resol= ve this
>>>>issue.
>>>>
>>>>
>>>>Thanks,
>>>>Yiu
>>>>
>>>>
>>>>
>>>>
>>>
>

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

--047d7b3436a2fda5ff04cf61ab83-- From mohamed.boucadair@orange.com Thu Nov 29 02:16:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9830C21F8A1B for ; Thu, 29 Nov 2012 02:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuPMPbICVST0 for ; Thu, 29 Nov 2012 02:16:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DCB2F21F8A0F for ; Thu, 29 Nov 2012 02:16:29 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id EADCF2643D1; Thu, 29 Nov 2012 11:16:28 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C9EC427C054; Thu, 29 Nov 2012 11:16:28 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 29 Nov 2012 11:16:28 +0100 From: To: "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite , "Reinaldo Penno (repenno)" , "softwires@ietf.org" Date: Thu, 29 Nov 2012 11:16:29 +0100 Thread-Topic: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3OF/pB3BIR0BudQv+t/d7Z7WY4PAAAFncA Message-ID: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:16:30 -0000 Dear all, As agreed in Atlanta, we prepared an I-D describing a proposed approach for= the unified CPE.=20 We hope this version is a good starting point to have fruitful discussion.= =20 Your comments, suggestions and contributions are more than welcome.=20 Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : jeudi 29 novembre 2012 10:57 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Unified Softwire CPE Author(s) : Mohamed Boucadair Ian Farrer Suresh Krishnan Filename : draft-bfmk-softwire-unified-cpe-00.txt Pages : 12 Date : 2012-11-29 Abstract: Transporting IPv4 packets over IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe There's also a htmlized version available at: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From suresh.krishnan@ericsson.com Thu Nov 29 05:58:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590FE21F89EE for ; Thu, 29 Nov 2012 05:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdEW1KiT5vaC for ; Thu, 29 Nov 2012 05:58:52 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B344421F89E5 for ; Thu, 29 Nov 2012 05:58:52 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qATE7Img019120; Thu, 29 Nov 2012 08:07:19 -0600 Received: from EUSAAHC003.ericsson.se (147.117.188.81) by eusaamw0706.eamcs.ericsson.se (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 08:58:49 -0500 Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 08:58:49 -0500 From: Suresh Krishnan To: "mohamed.boucadair@orange.com" Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: AQHNzjmnIUFgI+neAkmOG2MH8dZ6jg== Date: Thu, 29 Nov 2012 13:58:48 +0000 Message-ID: <0wqhvffps96ej8anr48sw25g.1354197525263@email.android.com> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: draft-cui-softwire-b4-translated-ds-lite , "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , "softwires@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 13:58:53 -0000 Thanks Med. This is a highly exploratory draft to be used as a strawman to = determine if an unified CPE is even possible. Please comment on it so that = we can determine if proceeding in this path is worthwhile. Also, if you are= interested in being an editor of this draft and are not currently working = on any of the current solution drafts please contact the chairs. Thanks Suresh ----- Original Message ----- From: "mohamed.boucadair@orange.com" To: "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf= .org" , draft-cui-softwir= e-b4-translated-ds-lite , "Reinaldo Penno (repenno)" , "softwires@ietf.or= g" Sent: 11/29/2012 5:16 AM Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Dear all, As agreed in Atlanta, we prepared an I-D describing a proposed approach for= the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : jeudi 29 novembre 2012 10:57 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Unified Softwire CPE Author(s) : Mohamed Boucadair Ian Farrer Suresh Krishnan Filename : draft-bfmk-softwire-unified-cpe-00.txt Pages : 12 Date : 2012-11-29 Abstract: Transporting IPv4 packets over IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe There's also a htmlized version available at: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From mark@townsley.net Thu Nov 29 06:03:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8642021F89C0 for ; Thu, 29 Nov 2012 06:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-M80IfpXZRa for ; Thu, 29 Nov 2012 06:03:44 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFFC21F89BA for ; Thu, 29 Nov 2012 06:03:44 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr13so3191482wgb.13 for ; Thu, 29 Nov 2012 06:03:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=zOWUakBa74aNwGNSwu+c0Wb+FvGaVhzpwbK6FVMRhyQ=; b=gE4zmI7iZDSYsIS5VTDsGIsvrZ6GmPVlOrUO4BI8rwlGAhnJTSZgVsYGOWUQ0QDzk1 N6p7q/6gREdd6iXNdaVhwKB1pk0MyGmKY4YXwe79Rj6/GSi83DSQMC/yjAotqJ+rXYNd XCJGf3UiGXmVWY7ItAwzUsmd+uJMv5I7jK8WCzP/XiXByKKO6XsgX/bz/dHqcQYi+qk6 vVQFuwmJkhcqx+IjkpVZvoCUiFHZTWQJ96asv3i6cnXfYx3f8UShNJiOxQlh5pmMmczj UTVW68Q34jqsGVs0PkE8UpzHO9XBOpV92I4uUZ/CF9IkbDMnskqwt9p/Sv0b81ekvA7/ edcA== Received: by 10.180.97.137 with SMTP id ea9mr30787880wib.13.1354197823497; Thu, 29 Nov 2012 06:03:43 -0800 (PST) Received: from marks-mac-mini.home (AMontsouris-159-1-50-189.w92-128.abo.wanadoo.fr. [92.128.49.189]) by mx.google.com with ESMTPS id b1sm2520876wix.11.2012.11.29.06.03.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2012 06:03:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Thu, 29 Nov 2012 15:03:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQnxuM/H+yV9lbxux46iKdMeKHHX948xZawjaW4IJ18OVr1RXZgXIMJVokaik8pYfsQiSkix Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 14:03:45 -0000 I think Rajiv's point is more about how summarization of routes in IP = brings fundamental scalability advantages for IP routers, not whether = the routes are programmed with a what is traditionally referred to as a = "routing protocol" or via CLI, DHCP, netconf/yang, XML, or however the = MAP rules are programmed in a given network. Another way of saying this is that, in IP (v4, for example here) a /32 = route is no different than a /31, /24, etc. other than a /32 just = happens to refer to one address rather than two or more. The routing = system *could* be run with /32s everywhere, and while scalability would = suffer tremendously, hosts would have the flexibility to be numbered = with a static unique address no matter where the user connected to the = network. The system would have IP mobility built right in! No need for = Mobile IP tunnels! It's all possible right now, just turn the state = dial all the way to the right and enjoy. The point where your existing = equipment falls over requiring you to redesign the network accordingly = depends on the number of hosts, limitations in routers, churn and = convergence, etc. but there is nothing prohibiting this per se in the = protocol design - it's all just IP and CIDR. Relating this to MAP: At one extreme, you can choose to setup rules in = advance such that rule aggregation is possible to a degree whereby MAP = can be supported inline with routers positioned where they normally = would for regular IPv6 forwarding. At the other extreme, you have less = aggregation and at some point you'll probably have to introduce = special-purpose tunnel concentrator hardware at specific locations. The = point where this crossover occurs isn't necessarily at the 1:1 MAP rule = point, it could be 2:1, 8:1, 256:1... it all depends on how many MAP = rules are supported by the vendor equipment chosen and the number of = endpoints being addressed. Just as map supports 2^32:1,... 8192:1, 4096:1, 2048:1, 512:1, 256:1, = 128:1, 64:1, 32:1, 16:1, 8:1, 4:1, or 2:1, it follows pretty clearly = that it should also support 1:1 - to do otherwise would be arbitrary. I = think the only question that should be on the table is whether a 1:1 = rule is called something different or not - kind of like how we refer to = a /32 or /128 as a hostroute. We could have a MAP "hostrule" for 1:1, = and "aggregate-rule" for N:1. Vendor equipment optimized for 1:1 mode = would advertise how many "hostrules" it can support. A more general MAP = implementation might advertise x number of "rules", aggregate or not. = The protocol mechanism from Softwires remains happily agnostic to all of = this; To the protocol, its nothing more than semantics. Bottom line, "Stateless operation" is a variable tipping point... It's = roughly the point where you can no longer affordably stuff all rules = into all border routers in your network. If you have 2 rules for = millions of endpoints, it's pretty easy to see that stateless operation = is possible. If you have millions of rules for millions of endpoints, = it's probably not. It's all highly dependent on the hardware, size, and = design of the network. Softwires should focus on the best protocol design, and let the vendors, = operators and market battle over where to turn the dial and what to = optimize for in their implementations and deployments. - Mark On Nov 16, 2012, at 12:19 AM, Lee, Yiu wrote: > Hi Rajiv, >=20 > With all due respect, I disagree the analogy. Comparing MAP-E to = routing > protocol is comparing apple to orange. MAP-E is not a routing = protocol. > MAP-E won't synchronize or exchange states between two BRs. Instead, = MAP-E > requires to statically provision states (aka rules) in the BR. = Original > MAP-E describes a mechanism to reduce user states in BR by using > programatic logic. 1:1 MAP-E does not require any of the good stuff > defined in MAP-E. I just found it odd to combine stateful and = stateless > mechanisms in a single draft and use a same name. >=20 > Thanks, > Yiu >=20 >=20 > On 11/12/12 2:51 PM, "Rajiv Asati (rajiva)" wrote: >=20 >>=20 >> Sure, and it is really a deployment choice (just like it is a = deployment >> choice to use a dynamic routing protocol to advertise host routes or >> summary routes or both in an IP network). But that's not to say that = we >> need one protocol for advertising the host routes, and another for >> advertising the summary routes. >>=20 >> Cheers, >> Rajiv >>=20 >> -----Original Message----- >> From: Yiu Lee >> Date: Monday, November 12, 2012 1:33 PM >> To: Rajiv Asati , Softwires-wg list = >> Subject: Re: [Softwires] MAP-E 1:1 for HA >>=20 >>> I am not talking about whether a MAP-domain should support 1 or N = CEs. >>> What I am trying to say is MAP-E 1:1 requires the BR to know per >>> subscriber information and the operator must pre-provision = per-subscriber >>> based rules to every BR in the same domain. In addition, the BR = can't use >>> programatic logic to reduce states. When the WG first decided to = work on >>> a >>> "stateless" solution, the goal was to make BR as stateless as = possible. >>> MAP-E 1:1 in contrast requires to store all subscriber rules in the = BR >>> and >>> can't derive the CE's IPv6 address using programatic logic. I found = it >>> odd >>> to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 = looks a >>> stateful solution to me. >>>=20 >>>=20 >>> On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" = wrote: >>>=20 >>>>=20 >>>> One can define a MAP-domain consisting of 1 CE or N CEs. This is = more of >>>> a >>>> deployment choice. >>>>=20 >>>> Cheers, >>>> Rajiv >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: , Yiu Lee >>>> Date: Friday, November 9, 2012 2:43 PM >>>> To: Softwires-wg list >>>> Subject: [Softwires] MAP-E 1:1 for HA >>>>=20 >>>>> I have a question for the HA design concept of MAP-E 1:1. The = central >>>>> theme of MAP-E is to make BR as stateless as possible and use = Anycast >>>>> address to identify the MAP-E BR. However, if we use MAP-E 1:1 = mode, >>>>> the >>>>> operator must have to pre-provision all >>>>> the subscribe rules to all the BRs sharing the same Anycast = address >>>>> for >>>>> reliable HA. This requires operators to carefully plan out which = BRs >>>>> support which subscribers. It is because BR is "per-subscriber >>>>> stateful" >>>>> in MAP-E 1:1 mode. Compared to the MAP-E design, >>>>> HA in MAP-E only requires the operators to use the same set of = rules >>>>> to >>>>> cover the entire domain. IMHO, this contradicts the original = spirit of >>>>> stateless solution and always puzzles me why MAP-E 1:1 bears the = MAP-E >>>>> name. MAP-E and 1:1 MAP-E are two completely >>>>> different solutions and target to different deployment scenarios. = I >>>>> would love to hear others to comment in the ML how to resolve this >>>>> issue. >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Yiu >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Thu Nov 29 18:31:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACA021F84C6 for ; Thu, 29 Nov 2012 18:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Clzm+8uWTXlE for ; Thu, 29 Nov 2012 18:31:28 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25DC821F8457 for ; Thu, 29 Nov 2012 18:31:27 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so9606243eek.31 for ; Thu, 29 Nov 2012 18:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bm+LJhWxX/RYbH+99gEhlRPgH2gfwFN4mB/e/5amMvo=; b=a4A4dx1dzCmxOBoUlXqTKbXbH9ahyiGZFdXu2okLzLyqt6WuIWneOKZPrjtmCM7fBC mK3qqXaqJXFsUHsODGokHINTmITtR8Mco0r/DXQUsHE9QAGW56spdIuoXRIVUB5+YSRM eygKWwA+TP0r8+coopCRKjMYUsrckFyEucdte0i2gy1foL8KJCC/TGIw510TJTfNJ89N 6YNs9/AJqvgdLFBLcWg1rjuAP17AUKLNn13trIENeFscGGALEk7hAiQojCYmKaO+zjCn +CmNGw3V3cPDaMIzt1GjCYnMpANVcBLR3+MmCXdjOtlcb/5sK8mkTuacjEejRTbfd5xF x48w== MIME-Version: 1.0 Received: by 10.14.0.71 with SMTP id 47mr34713530eea.19.1354242687256; Thu, 29 Nov 2012 18:31:27 -0800 (PST) Received: by 10.223.6.90 with HTTP; Thu, 29 Nov 2012 18:31:27 -0800 (PST) In-Reply-To: <0wqhvffps96ej8anr48sw25g.1354197525263@email.android.com> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <0wqhvffps96ej8anr48sw25g.1354197525263@email.android.com> Date: Fri, 30 Nov 2012 11:31:27 +0900 Message-ID: From: Maoke To: Suresh Krishnan Content-Type: multipart/alternative; boundary=047d7b66f32950481404cfad32b3 Cc: draft-cui-softwire-b4-translated-ds-lite , "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , "softwires@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:31:29 -0000 --047d7b66f32950481404cfad32b3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable thanks Med for the initialization of the work! i noticed that: 1. MAP is working in the context of prefix delegation and therefore the LAN side IPv6 addresses (prefix) is involved in the mapping between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unified CPE is made, the logic of the address assignment to interfaces should also consider this difference in the behaviour. 2. is the deployment of difference modes able to be overlapped? current section 4.4 implies the answer is "yes". i agree. but is it the best behaviour to select one mode at the device-wise according to a certain preferences? my question is: when the CPE receives multiple rules/parameter-sets from different sources of provisioning, can it store and use these pieces of information to adapt packets for corresponding mode of service, i.e., applying a proper mode on demand and session-specific? 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? 4. fragmentation issue is common to all modes and it is also needed to be clarified/unified for the unified CPE. only my 2 cents, identifying the problems that i expect this draft to cover. - maoke 2012/11/29 Suresh Krishnan > Thanks Med. This is a highly exploratory draft to be used as a strawman t= o > determine if an unified CPE is even possible. Please comment on it so tha= t > we can determine if proceeding in this path is worthwhile. Also, if you a= re > interested in being an editor of this draft and are not currently working > on any of the current solution drafts please contact the chairs. > > Thanks > Suresh > > > ----- Original Message ----- > From: "mohamed.boucadair@orange.com" > To: "draft-ietf-softwire-map@tools.ietf.org" < > draft-ietf-softwire-map@tools.ietf.org>, " > draft-ietf-softwire-map-dhcp@tools.ietf.org" < > draft-ietf-softwire-map-dhcp@tools.ietf.org>, " > draft-ietf-softwire-public-4over6@tools.ietf.org" < > draft-ietf-softwire-public-4over6@tools.ietf.org>, > draft-cui-softwire-b4-translated-ds-lite < > draft-cui-softwire-b4-translated-ds-lite@tools.ietf.org>, "Reinaldo Penno > (repenno)" , "softwires@ietf.org" > Sent: 11/29/2012 5:16 AM > Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cp= e > > > > Dear all, > > As agreed in Atlanta, we prepared an I-D describing a proposed approach > for the unified CPE. > > We hope this version is a good starting point to have fruitful discussion= . > > Your comments, suggestions and contributions are more than welcome. > > Cheers, > Med > > > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > De la part de internet-drafts@ietf.org > Envoy=E9 : jeudi 29 novembre 2012 10:57 > =C0 : i-d-announce@ietf.org > Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Unified Softwire CPE > Author(s) : Mohamed Boucadair > Ian Farrer > Suresh Krishnan > Filename : draft-bfmk-softwire-unified-cpe-00.txt > Pages : 12 > Date : 2012-11-29 > > Abstract: > Transporting IPv4 packets over IPv6 is a common solution to the > problem of IPv4 service continuity over IPv6-only provider networks. > A number of differing functional approaches have been developed for > this, each having their own specific characteristics. As these > approaches share a similar functional architecture and use the same > data plane mechanisms, this memo describes a specification whereby a > single CPE can interwork with all of the standardized and proposed > approaches to providing encapsulated IPv4 in IPv6 services. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > 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 > --047d7b66f32950481404cfad32b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable thanks Med for the initialization of the work!

i noticed that:
1. MAP is working in the context of prefix delegation and therefore the L= AN side IPv6 addresses (prefix) is involved in the mapping between the IPv4= and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a uni= fied CPE is made, the logic of the address assignment to interfaces should = also consider this difference in the behaviour.

2. is the deployment of difference modes able to be overlapped? current= section 4.4 implies the answer is "yes". i agree. but is it the = best behaviour to select one mode at the device-wise according to a certain= preferences? my question is: when the CPE receives multiple rules/paramete= r-sets from different sources of provisioning, can it store and use these p= ieces of information to adapt packets for corresponding mode of service, i.= e., applying a proper mode on demand and session-specific?

3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency?
<= br>4. fragmentation issue is common to all modes and it is also needed to b= e clarified/unified for the unified CPE.

only my 2 cents, identifyi= ng the problems that i expect this draft to cover.

- maoke

2012/11/29 Suresh Krishnan <suresh.krishnan@ericsson.com>
Thanks Med. This is a highly exploratory draft to be used as a strawman to = determine if an unified CPE is even possible. Please comment on it so that = we can determine if proceeding in this path is worthwhile. Also, if you are= interested in being an editor of this draft and are not currently working = on any of the current solution drafts please contact the chairs.

Thanks
Suresh


----- Original Message -----
From: "mohamed.boucada= ir@orange.com" <mohamed.boucadair@orange.com>
To: "draft-i= etf-softwire-map@tools.ietf.org" <draft-ietf-softwire-map@tools.ietf.org>= , "draf= t-ietf-softwire-map-dhcp@tools.ietf.org" <draft-ietf-softwire-map-dhcp@tool= s.ietf.org>, "draft-ietf-softwire-public-4over6@tools.ietf.org&quo= t; <= draft-ietf-softwire-public-4over6@tools.ietf.org>, draft-cui-softwir= e-b4-translated-ds-lite <draft-cui-softwire-b4-translated-ds-lite@tools.= ietf.org>, "Reinaldo Penno =A0(repenno)" <repenno@cisco.com>, "softwires@ietf.org" <softwires@ietf.org>
Sent: 11/29/2012 5:16 AM
Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe<= br>


Dear all,

As agreed in Atlanta, we prepared an I-D describing a proposed approach for= the unified CPE.

We hope this version is a good starting point to have fruitful discussion.<= br>
Your comments, suggestions and contributions are more than welcome.

Cheers,
Med


-----Message d'origine-----
De : i-d-announce-bounces@= ietf.org [mailto:i-d-a= nnounce-bounces@ietf.org] De la part de internet-drafts@ietf.org
Envoy=E9 : jeudi 29 novembre 2012 10:57
=C0 : i-d-announce@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Unified Softwire CPE
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Mohamed Boucadair
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ian Farrer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Suresh Krishnan
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bfmk-softwire-unified-cpe-0= 0.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-11-29

Abstract:
=A0 =A0Transporting IPv4 packets over IPv6 is a common solution to the
=A0 =A0problem of IPv4 service continuity over IPv6-only provider networks.=
=A0 =A0A number of differing functional approaches have been developed for<= br> =A0 =A0this, each having their own specific characteristics. =A0As these =A0 =A0approaches share a similar functional architecture and use the same<= br> =A0 =A0data plane mechanisms, this memo describes a specification whereby a=
=A0 =A0single CPE can interwork with all of the standardized and proposed =A0 =A0approaches to providing encapsulated IPv4 in IPv6 services.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bfmk-softwire-un= ified-cpe

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe= -00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
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

--047d7b66f32950481404cfad32b3-- From leaf.y.yeh@huawei.com Thu Nov 29 20:13:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B4E21F88E8 for ; Thu, 29 Nov 2012 20:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uiyq3VKK9oce for ; Thu, 29 Nov 2012 20:13:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C594621F84C1 for ; Thu, 29 Nov 2012 20:13:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMA78935; Fri, 30 Nov 2012 04:13:36 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Nov 2012 04:13:22 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Nov 2012 12:13:35 +0800 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.9]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Fri, 30 Nov 2012 12:13:31 +0800 From: Leaf yeh To: Mark Townsley , "Lee, Yiu" Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNvrJUhwE7DtDnmkmwZYkUbhoBV5firlkAgANWdgCAABXjAIAE8R2AgBVlWgCAAW4JkA== Date: Fri, 30 Nov 2012 04:13:30 +0000 Message-ID: References: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> In-Reply-To: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 04:13:40 -0000 Mark - I think the only question that should be on the table is whether a 1= :1 rule is called something different or not - kind of like how we refer to= a /32 or /128 as a hostroute. Even in the case of MAP-E 1:1, there still has 2 kinds of deployments: a. map PSID into the EA bits of the delegated end-user IPv6 prefix; b. length of EA bits =3D 0, which might mean no mapping at all; Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Mark Townsley Sent: Thursday, November 29, 2012 10:04 PM To: Lee, Yiu Cc: softwires@ietf.org Subject: Re: [Softwires] MAP-E 1:1 for HA I think Rajiv's point is more about how summarization of routes in IP bring= s fundamental scalability advantages for IP routers, not whether the routes= are programmed with a what is traditionally referred to as a "routing prot= ocol" or via CLI, DHCP, netconf/yang, XML, or however the MAP rules are pro= grammed in a given network. Another way of saying this is that, in IP (v4, for example here) a /32 rout= e is no different than a /31, /24, etc. other than a /32 just happens to re= fer to one address rather than two or more. The routing system *could* be r= un with /32s everywhere, and while scalability would suffer tremendously, h= osts would have the flexibility to be numbered with a static unique address= no matter where the user connected to the network. The system would have I= P mobility built right in! No need for Mobile IP tunnels! It's all possibl= e right now, just turn the state dial all the way to the right and enjoy. T= he point where your existing equipment falls over requiring you to redesign= the network accordingly depends on the number of hosts, limitations in rou= ters, churn and convergence, etc. but there is nothing prohibiting this per= se in the protocol design - it's all just IP and CIDR. Relating this to MAP: At one extreme, you can choose to setup rules in adva= nce such that rule aggregation is possible to a degree whereby MAP can be s= upported inline with routers positioned where they normally would for regul= ar IPv6 forwarding. At the other extreme, you have less aggregation and at = some point you'll probably have to introduce special-purpose tunnel concent= rator hardware at specific locations. The point where this crossover occurs= isn't necessarily at the 1:1 MAP rule point, it could be 2:1, 8:1, 256:1..= . it all depends on how many MAP rules are supported by the vendor equipmen= t chosen and the number of endpoints being addressed. Just as map supports 2^32:1,... 8192:1, 4096:1, 2048:1, 512:1, 256:1, 128:1= , 64:1, 32:1, 16:1, 8:1, 4:1, or 2:1, it follows pretty clearly that it sho= uld also support 1:1 - to do otherwise would be arbitrary. I think the only= question that should be on the table is whether a 1:1 rule is called somet= hing different or not - kind of like how we refer to a /32 or /128 as a hos= troute. We could have a MAP "hostrule" for 1:1, and "aggregate-rule" for N:= 1. Vendor equipment optimized for 1:1 mode would advertise how many "hostru= les" it can support. A more general MAP implementation might advertise x nu= mber of "rules", aggregate or not. The protocol mechanism from Softwires re= mains happily agnostic to all of this; To the protocol, its nothing more th= an semantics. Bottom line, "Stateless operation" is a variable tipping point... It's roug= hly the point where you can no longer affordably stuff all rules into all b= order routers in your network. If you have 2 rules for millions of endpoint= s, it's pretty easy to see that stateless operation is possible. If you hav= e millions of rules for millions of endpoints, it's probably not. It's all = highly dependent on the hardware, size, and design of the network. Softwires should focus on the best protocol design, and let the vendors, op= erators and market battle over where to turn the dial and what to optimize = for in their implementations and deployments. - Mark On Nov 16, 2012, at 12:19 AM, Lee, Yiu wrote: > Hi Rajiv, >=20 > With all due respect, I disagree the analogy. Comparing MAP-E to routing > protocol is comparing apple to orange. MAP-E is not a routing protocol. > MAP-E won't synchronize or exchange states between two BRs. Instead, MAP-= E > requires to statically provision states (aka rules) in the BR. Original > MAP-E describes a mechanism to reduce user states in BR by using > programatic logic. 1:1 MAP-E does not require any of the good stuff > defined in MAP-E. I just found it odd to combine stateful and stateless > mechanisms in a single draft and use a same name. >=20 > Thanks, > Yiu >=20 >=20 > On 11/12/12 2:51 PM, "Rajiv Asati (rajiva)" wrote: >=20 >>=20 >> Sure, and it is really a deployment choice (just like it is a deployment >> choice to use a dynamic routing protocol to advertise host routes or >> summary routes or both in an IP network). But that's not to say that we >> need one protocol for advertising the host routes, and another for >> advertising the summary routes. >>=20 >> Cheers, >> Rajiv >>=20 >> -----Original Message----- >> From: Yiu Lee >> Date: Monday, November 12, 2012 1:33 PM >> To: Rajiv Asati , Softwires-wg list >> Subject: Re: [Softwires] MAP-E 1:1 for HA >>=20 >>> I am not talking about whether a MAP-domain should support 1 or N CEs. >>> What I am trying to say is MAP-E 1:1 requires the BR to know per >>> subscriber information and the operator must pre-provision per-subscrib= er >>> based rules to every BR in the same domain. In addition, the BR can't u= se >>> programatic logic to reduce states. When the WG first decided to work o= n >>> a >>> "stateless" solution, the goal was to make BR as stateless as possible. >>> MAP-E 1:1 in contrast requires to store all subscriber rules in the BR >>> and >>> can't derive the CE's IPv6 address using programatic logic. I found it >>> odd >>> to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks a >>> stateful solution to me. >>>=20 >>>=20 >>> On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" wrote: >>>=20 >>>>=20 >>>> One can define a MAP-domain consisting of 1 CE or N CEs. This is more = of >>>> a >>>> deployment choice. >>>>=20 >>>> Cheers, >>>> Rajiv >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: , Yiu Lee >>>> Date: Friday, November 9, 2012 2:43 PM >>>> To: Softwires-wg list >>>> Subject: [Softwires] MAP-E 1:1 for HA >>>>=20 >>>>> I have a question for the HA design concept of MAP-E 1:1. The central >>>>> theme of MAP-E is to make BR as stateless as possible and use Anycast >>>>> address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, >>>>> the >>>>> operator must have to pre-provision all >>>>> the subscribe rules to all the BRs sharing the same Anycast address >>>>> for >>>>> reliable HA. This requires operators to carefully plan out which BRs >>>>> support which subscribers. It is because BR is "per-subscriber >>>>> stateful" >>>>> in MAP-E 1:1 mode. Compared to the MAP-E design, >>>>> HA in MAP-E only requires the operators to use the same set of rules >>>>> to >>>>> cover the entire domain. IMHO, this contradicts the original spirit = of >>>>> stateless solution and always puzzles me why MAP-E 1:1 bears the MAP-= E >>>>> name. MAP-E and 1:1 MAP-E are two completely >>>>> different solutions and target to different deployment scenarios. I >>>>> would love to hear others to comment in the ML how to resolve this >>>>> issue. >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Yiu >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>=20 >=20 > _______________________________________________ > 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 mohamed.boucadair@orange.com Fri Nov 30 00:07:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827A721F8AD2 for ; Fri, 30 Nov 2012 00:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.004, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnEQPEJylcoY for ; Fri, 30 Nov 2012 00:07:02 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A8EAD21F897A for ; Fri, 30 Nov 2012 00:06:51 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 6E8A23B43EF; Fri, 30 Nov 2012 09:06:50 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4AB3927C066; Fri, 30 Nov 2012 09:06:50 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 30 Nov 2012 09:06:49 +0100 From: To: Maoke , Suresh Krishnan Date: Fri, 30 Nov 2012 09:06:48 +0100 Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3Oos1boHphMLLVT1q6o07gF9pQxwALSIBg Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D4EE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <0wqhvffps96ej8anr48sw25g.1354197525263@email.android.com> 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_94C682931C08B048B7A8645303FDC9F36E99E2D4EEPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.30.41521 Cc: draft-cui-softwire-b4-translated-ds-lite , "draft-ietf-softwire-public-4over6@tools.ietf.org" , "softwires@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 08:07:03 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E99E2D4EEPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Maoke, Thank you for the review and comments. Please see inline. Cheers, Med ________________________________ De : Maoke [mailto:fibrib@gmail.com] Envoy=E9 : vendredi 30 novembre 2012 03:31 =C0 : Suresh Krishnan Cc : BOUCADAIR Mohamed OLNC/OLN; draft-cui-softwire-b4-translated-ds-lite; = draft-ietf-softwire-map@tools.ietf.org; draft-ietf-softwire-public-4over6@t= ools.ietf.org; softwires@ietf.org; draft-ietf-softwire-map-dhcp@tools.ietf.= org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-c= pe thanks Med for the initialization of the work! i noticed that: 1. MAP is working in the context of prefix delegation and therefore the LAN= side IPv6 addresses (prefix) is involved in the mapping between the IPv4 a= nd IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unifi= ed CPE is made, the logic of the address assignment to interfaces should al= so consider this difference in the behaviour. [Med] I'm not sure I understand your point. Could you please clarify furthe= r the difference between the stateless and binding mode and what you think = it should be added to bullet (2.3.2) of Section 3.4? Thanks. 2. is the deployment of difference modes able to be overlapped? current sec= tion 4.4 implies the answer is "yes". i agree. but is it the best behaviour= to select one mode at the device-wise according to a certain preferences? = my question is: when the CPE receives multiple rules/parameter-sets from di= fferent sources of provisioning, can it store and use these pieces of infor= mation to adapt packets for corresponding mode of service, i.e., applying a= proper mode on demand and session-specific? [Med] The current text says: o For a given network attachment, only one mode MUST be activated. o The CPE MAY be configured by a user or via remote device management means (e.g., DHCP, TR-069). o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. Does this text answer your questions? If not, what you think is needed to b= e added? Thanks. 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? 4. fragmentation issue is common to all modes and it is also needed to be c= larified/unified for the unified CPE. [Med] Fully agree. We preferred to focus first on the unified logic. If the= WG accepts the proposed direction, then the document should be updated to = cover items common to all modes. only my 2 cents, identifying the problems that i expect this draft to cover= . - maoke 2012/11/29 Suresh Krishnan > Thanks Med. This is a highly exploratory draft to be used as a strawman to = determine if an unified CPE is even possible. Please comment on it so that = we can determine if proceeding in this path is worthwhile. Also, if you are= interested in being an editor of this draft and are not currently working = on any of the current solution drafts please contact the chairs. Thanks Suresh ----- Original Message ----- From: "mohamed.boucadair@orange.com" <= mohamed.boucadair@orange.com> To: "draft-ietf-softwire-map@tools.ietf.org" >, "draft-ietf-softwire-map-dhcp@tools.ietf.org= " = >, "draft-ietf-softwire-public-4over6@tools.ietf.org" >, draft= -cui-softwire-b4-translated-ds-lite >, "Reinaldo Penno (repenno)" >, "softwires@ietf.org" > Sent: 11/29/2012 5:16 AM Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Dear all, As agreed in Atlanta, we prepared an I-D describing a proposed approach for= the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [m= ailto:i-d-announce-bounces@ietf.org] = De la part de internet-drafts@ietf.org Envoy=E9 : jeudi 29 novembre 2012 10:57 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Unified Softwire CPE Author(s) : Mohamed Boucadair Ian Farrer Suresh Krishnan Filename : draft-bfmk-softwire-unified-cpe-00.txt Pages : 12 Date : 2012-11-29 Abstract: Transporting IPv4 packets over IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe There's also a htmlized version available at: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ 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 --_000_94C682931C08B048B7A8645303FDC9F36E99E2D4EEPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Maoke,
 
Thank you for the review and comments.=20
 
Please see inline.
 
Cheers,
Med

De : Maoke [mailto:fibrib@gmail.= com]=20
Envoy=E9 : vendredi 30 novembre 2012 03:31
=C0 = ;:=20 Suresh Krishnan
Cc : BOUCADAIR Mohamed OLNC/OLN;=20 draft-cui-softwire-b4-translated-ds-lite;=20 draft-ietf-softwire-map@tools.ietf.org;=20 draft-ietf-softwire-public-4over6@tools.ietf.org; softwires@ietf.org;=20 draft-ietf-softwire-map-dhcp@tools.ietf.org
Objet : Re:=20 [Softwires] Unified Softwire CPE:=20 draft-bfmk-softwire-unified-cpe

thanks Med for the initialization of the work!

i noticed=20 that:

1. MAP is working in the context of prefix delegation and=20 therefore the LAN side IPv6 addresses (prefix) is involved in the mapping= =20 between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address=20 directly. when a unified CPE is made, the logic of the address assignment= to=20 interfaces should also consider this difference in the behaviour.
[Med] I'm not sure I understand your point. Could yo= u=20 please clarify further the difference between the stateless and binding m= ode=20 and what you think it should be added to bullet (2.3.2) of Section 3.4?=20 Thanks.

2. is the deployment of difference modes ab= le to=20 be overlapped? current section 4.4 implies the answer is "yes". i agree. = but=20 is it the best behaviour to select one mode at the device-wise according = to a=20 certain preferences? my question is: when the CPE receives multiple=20 rules/parameter-sets from different sources of provisioning, can it store= and=20 use these pieces of information to adapt packets for corresponding mode o= f=20 service, i.e., applying a proper mode on demand and session-specific?
=
[Med] The current text says: 
 
   o  For a given network attachment,= only=20 one mode MUST be activated.
   o  The CPE MAY be config= ured=20 by a user or via remote device
      manageme= nt=20 means (e.g., DHCP, TR-069).
   o  A network which suppo= rts=20 one or several modes MUST return valid
     = =20 configuration data allowing requesting devices to=20 unambiguously
      select a single mode to u= se=20 for attachment.
 
Does this text answer your questions? If not, what y= ou=20 think is needed to be added?=20 Thanks.  

3. related to 2, how can = we=20 keep the CPE/BR CPE/AFTR consistency?

4. fragmentation issue is c= ommon=20 to all modes and it is also needed to be clarified/unified for the unifie= d=20 CPE.
[Med] Fully agree. We preferred to focus first = on the=20 unified logic. If the WG accepts the proposed direction, then the documen= t=20 should be updated to cover items common to all modes.=20

only my 2 cents, identifying the problems that i ex= pect=20 this draft to cover.

- maoke

2012/11/29 Suresh Krishnan <<= A=20 href=3D"mailto:suresh.krishnan@ericsson.com"=20 target=3D_blank>suresh.krishnan@ericsson.com>
Thanks Med. This is a highly exploratory draft to be = used=20 as a strawman to determine if an unified CPE is even possible. Please=20 comment on it so that we can determine if proceeding in this path is=20 worthwhile. Also, if you are interested in being an editor of this draf= t and=20 are not currently working on any of the current solution drafts please= =20 contact the chairs.

Thanks
Suresh


----- Original=20 Message -----
From: "mohamed.boucadair@orange.c= om"=20 <mohamed.boucadair@orange.c= om>
To:=20 "draft-ietf-softw= ire-map@tools.ietf.org"=20 <draft-ietf-softw= ire-map@tools.ietf.org>,=20 "draft-ietf-= softwire-map-dhcp@tools.ietf.org"=20 <draft-ietf-= softwire-map-dhcp@tools.ietf.org>,=20 "draft-= ietf-softwire-public-4over6@tools.ietf.org"=20 <draft-= ietf-softwire-public-4over6@tools.ietf.org>,=20 draft-cui-softwire-b4-translated-ds-lite <draft-cui-softwire-b4-translated-ds-lite@tools.ietf.org>,=20 "Reinaldo Penno  (repenno)" <repenno@cisco.com>, "softwires@ietf.org" <softwires@ietf.org>
Sent:= =20 11/29/2012 5:16 AM
Subject: [Softwires] Unified Softwire CPE:=20 draft-bfmk-softwire-unified-cpe



Dear all,

As agre= ed in=20 Atlanta, we prepared an I-D describing a proposed approach for the unif= ied=20 CPE.

We hope this version is a good starting point to have fruit= ful=20 discussion.

Your comments, suggestions and contributions are mor= e=20 than welcome.

Cheers,
Med


-----Message=20 d'origine-----
De : i-d-announce-bounces@ietf= .org=20 [mailto:i-d-announce-bounces@ietf= .org]=20 De la part de internet-drafts@ietf.orgEnvoy=E9=20 : jeudi 29 novembre 2012 10:57
=C0 : i-d-announce@ietf.org
Obje= t : I-D=20 Action: draft-bfmk-softwire-unified-cpe-00.txt


A New=20 Internet-Draft is available from the on-line Internet-Drafts=20 directories.


        Title    = =20       : Unified Softwire CPE
      &nb= sp;=20 Author(s)       : Mohamed Boucadair
    &nb= sp;=20                     I= an=20 Farrer
                 = ;=20         Suresh Krishnan
      &nb= sp;=20 Filename        :=20 draft-bfmk-softwire-unified-cpe-00.txt
        P= ages=20           : 12
        = Date=20            :=20 2012-11-29

Abstract:
   Transporting IPv4 packets o= ver=20 IPv6 is a common solution to the
   problem of IPv4 servic= e=20 continuity over IPv6-only provider networks.
   A number o= f=20 differing functional approaches have been developed for
 =20  this, each having their own specific characteristics.  As=20 these
   approaches share a similar functional architectur= e and=20 use the same
   data plane mechanisms, this memo describes= a=20 specification whereby a
   single CPE can interwork with a= ll of=20 the standardized and proposed
   approaches to providing=20 encapsulated IPv4 in IPv6 services.


The IETF datatracker sta= tus=20 page for this draft is:
https://datatracker.ietf.org/doc/draft-bfmk-softwire-un= ified-cpe

There's=20 also a htmlized version available at:
http://tools.ietf.org/html/draft-bfmk-softwire-unified-= cpe-00


Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

________= _______________________________________
I-D-Announce=20 mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
I= nternet-Draft=20 directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
______= _________________________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
= _______________________________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
=

--_000_94C682931C08B048B7A8645303FDC9F36E99E2D4EEPUEXCB1Bnante_-- From bingxuere@gmail.com Fri Nov 30 00:49:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A2621F8569 for ; Fri, 30 Nov 2012 00:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fbLEuhYO89t for ; Fri, 30 Nov 2012 00:49:07 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BFF9921F8567 for ; Fri, 30 Nov 2012 00:49:07 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so200814iaz.31 for ; Fri, 30 Nov 2012 00:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8Zoi/9iHCsQF+x+PCh/nwpylAIKzV9Lo6F09JQ4nkts=; b=CJincdd/DgTtIv/Hq/cTv19ufPi7XK2bi6ZLxhC05YXKVKatNIp3OMSTV/acXYDulT b6ZBhd6a7xjNouPy8AWTCn6ruCWBUx+jSos9+tAaIrnxsCPeiE3I9RS0Ii+bySBJYbqY s/a67Vj1EG2vrHNLkugGV23CxwsQ4g+xnBB33L7GrFTsiGEcwNDXKGxSCrvQ6Ar0n8xs 17D/EHHN11s5NB/9MXtTC7LfZKAry6ApxwYr1tX8me8NSLVOXMJmHsk1JcQEb1lGIb0m kx6OQaMv9PB3eUFxzsxMM+2QOr3WwNedACWulUEDVr8p42gnEduLa8HXjwCMRMde4ooP z0Mg== Received: by 10.42.94.8 with SMTP id z8mr365530icm.36.1354265347383; Fri, 30 Nov 2012 00:49:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Fri, 30 Nov 2012 00:48:26 -0800 (PST) In-Reply-To: References: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> From: Qiong Date: Fri, 30 Nov 2012 16:48:26 +0800 Message-ID: To: Leaf yeh Content-Type: multipart/alternative; boundary=20cf30334961f662d104cfb278bd Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 08:49:08 -0000 --20cf30334961f662d104cfb278bd Content-Type: text/plain; charset=UTF-8 Right. That's why I prefer the solution space provided by Med before, which will be much clearer and easy to understand: * Full stateful approach * Binding approach * Full stateless approach Best wishes Qiong On Fri, Nov 30, 2012 at 12:13 PM, Leaf yeh wrote: > Mark - I think the only question that should be on the table is whether a > 1:1 rule is called something different or not - kind of like how we refer > to a /32 or /128 as a hostroute. -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --20cf30334961f662d104cfb278bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right. That's why I prefer the solution spac= e provided by Med before, which will be much clearer and easy to understand= :
* Full stateful approach
* Binding approach
* Full stateless app= roach

Best wishes
Qiong

On Fri, Nov 30, = 2012 at 12:13 PM, Leaf yeh <leaf.y.yeh@huawei.com> wrote= :
Mark - I think the only question that should= be on the table is whether a 1:1 rule is called something different or not= - kind of like how we refer to a /32 or /128 as a hostroute.



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research = Institude


Open source code:
lightweight 4over6: http://sourcefor= ge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--20cf30334961f662d104cfb278bd-- From fibrib@gmail.com Fri Nov 30 01:54:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C3E21F8686 for ; Fri, 30 Nov 2012 01:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jH3ePoTWm16k for ; Fri, 30 Nov 2012 01:54:11 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 755BD21F8623 for ; Fri, 30 Nov 2012 01:54:10 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so193522eek.31 for ; Fri, 30 Nov 2012 01:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SBxTnJj2lXwNmsoEN4LrMQO4UtpA3+Me82zsDgWUESM=; b=MNwSYbGPm82yi9A/cCZpOLzf4i8VKw9MUBHxoq8+Nv/rM1ppLTdD+tA5yiGCgZQQNj LgDVgf7TSZ4LEfj78/He/X5eoNViTp7uq5HNOoh5wdovQ3HeYzJ437yXjCMJgTiMdi9P D8G19MAr/4ATQ77THcZc6kPRxptQIG6hDx3Ey15l7tMcnlaHvsS1uZiJBRXXcSGnWNBX lil+QynXyhelVcATh8Bn26KQmB8c/iqTfJHRxxE7XeMKY7wl5574LkCLlCCpDrp4ZV6t c33DJ8pYB8/iq5YEqpbonWa3jJbnzTVdAeVH+ha9aA66xyS7SpMQgRIcBh1GnHBdn1Te eisA== MIME-Version: 1.0 Received: by 10.14.176.66 with SMTP id a42mr2662592eem.34.1354269249546; Fri, 30 Nov 2012 01:54:09 -0800 (PST) Received: by 10.14.127.1 with HTTP; Fri, 30 Nov 2012 01:54:09 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D4EE@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <0wqhvffps96ej8anr48sw25g.1354197525263@email.android.com> <94C682931C08B048B7A8645303FDC9F36E99E2D4EE@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 30 Nov 2012 18:54:09 +0900 Message-ID: From: Maoke To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=047d7b6222d08cabed04cfb3615a Cc: draft-cui-softwire-b4-translated-ds-lite , "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , "softwires@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 09:54:12 -0000 --047d7b6222d08cabed04cfb3615a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Med, thanks for the response. please see inline. 2012/11/30 > ** > Dear Maoke, > > Thank you for the review and comments. > > Please see inline. > > Cheers, > Med > > ------------------------------ > *De :* Maoke [mailto:fibrib@gmail.com] > *Envoy=E9 :* vendredi 30 novembre 2012 03:31 > *=C0 :* Suresh Krishnan > *Cc :* BOUCADAIR Mohamed OLNC/OLN; > draft-cui-softwire-b4-translated-ds-lite; > draft-ietf-softwire-map@tools.ietf.org; > draft-ietf-softwire-public-4over6@tools.ietf.org; softwires@ietf.org; > draft-ietf-softwire-map-dhcp@tools.ietf.org > *Objet :* Re: [Softwires] Unified Softwire CPE: > draft-bfmk-softwire-unified-cpe > > thanks Med for the initialization of the work! > > i noticed that: > > 1. MAP is working in the context of prefix delegation and therefore the > LAN side IPv6 addresses (prefix) is involved in the mapping between the > IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when= a > unified CPE is made, the logic of the address assignment to interfaces > should also consider this difference in the behaviour. > [Med] I'm not sure I understand your point. Could you please clarify > further the difference between the stateless and binding mode and what yo= u > think it should be added to bullet (2.3.2) of Section 3.4? Thanks. > > [maoke] i a little doubt the binding mode is a proper way to unify the MA= P 1:1 and lw4over6. because MAP 1:1 is still working in the model of delegation while lw4over6 applies the WAN IPv6 address for the encapsulation. what if the CPE has a delegated prefix at LAN and an address at WAN simultaneously? which address is used for the source address of the tunnel in the "binding mode"? is the CPE choice fits the reality at the AFTR/BR? to my understanding, the behaviour of MAP 1:1 is identical with any MAP but different from lw4over6 to some extent. > > 2. is the deployment of difference modes able to be overlapped? current > section 4.4 implies the answer is "yes". i agree. but is it the best > behaviour to select one mode at the device-wise according to a certain > preferences? my question is: when the CPE receives multiple > rules/parameter-sets from different sources of provisioning, can it store > and use these pieces of information to adapt packets for corresponding mo= de > of service, i.e., applying a proper mode on demand and session-specific? > [Med] The current text says: > > o For a given network attachment, only one mode MUST be activated. > > [maoke ] why only ONE mode MUST be activated? [maoke] we noticed a fact that a domain of softwire, at least MAP, can be different from the "domain" in the sense of autonomous system, because the model of prefix delegation is totally independent of the deployment of the softwire. this feature makes the softwire domain able to spread over different AS. therefore it is possible that a CPE is involved in a AS's lw4over6 domain and meanwhile also involved in a inter-AS MAP domain. administration of the lw4over6 domain and that of the MAP domain are surely independent to each other but they impact the CPE simultaneously -- it could be treated as a typical case of softwire multi-homing. and we expect the CPE gets the benefits from the multi-homing: policy-based path selection, load-balance, fault-tolerance, etc. o The CPE MAY be configured by a user or via remote device > management means (e.g., DHCP, TR-069). > o A network which supports one or several modes MUST return valid > configuration data allowing requesting devices to unambiguously > select a single mode to use for attachment. > > Does this text answer your questions? If not, what you think is needed to > be added? Thanks. > > > 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? > > 4. fragmentation issue is common to all modes and it is also needed to be > clarified/unified for the unified CPE. > [Med] Fully agree. We preferred to focus first on the unified logic. If > the WG accepts the proposed direction, then the document should be update= d > to cover items common to all modes. > > thanks, - maoke P.S. i will be in a 3-nights&2-days trip since tonight so any further discussion will be responded in the beginning of next week. sorry in advance for the delay. > > only my 2 cents, identifying the problems that i expect this draft to > cover. > > - maoke > > 2012/11/29 Suresh Krishnan > >> Thanks Med. This is a highly exploratory draft to be used as a strawman >> to determine if an unified CPE is even possible. Please comment on it so >> that we can determine if proceeding in this path is worthwhile. Also, if >> you are interested in being an editor of this draft and are not currentl= y >> working on any of the current solution drafts please contact the chairs. >> >> Thanks >> Suresh >> >> >> ----- Original Message ----- >> From: "mohamed.boucadair@orange.com" >> To: "draft-ietf-softwire-map@tools.ietf.org" < >> draft-ietf-softwire-map@tools.ietf.org>, " >> draft-ietf-softwire-map-dhcp@tools.ietf.org" < >> draft-ietf-softwire-map-dhcp@tools.ietf.org>, " >> draft-ietf-softwire-public-4over6@tools.ietf.org" < >> draft-ietf-softwire-public-4over6@tools.ietf.org>, >> draft-cui-softwire-b4-translated-ds-lite < >> draft-cui-softwire-b4-translated-ds-lite@tools.ietf.org>, "Reinaldo >> Penno (repenno)" , "softwires@ietf.org" < >> softwires@ietf.org> >> Sent: 11/29/2012 5:16 AM >> Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-c= pe >> >> >> >> Dear all, >> >> As agreed in Atlanta, we prepared an I-D describing a proposed approach >> for the unified CPE. >> >> We hope this version is a good starting point to have fruitful discussio= n. >> >> Your comments, suggestions and contributions are more than welcome. >> >> Cheers, >> Med >> >> >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] >> De la part de internet-drafts@ietf.org >> Envoy=E9 : jeudi 29 novembre 2012 10:57 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Unified Softwire CPE >> Author(s) : Mohamed Boucadair >> Ian Farrer >> Suresh Krishnan >> Filename : draft-bfmk-softwire-unified-cpe-00.txt >> Pages : 12 >> Date : 2012-11-29 >> >> Abstract: >> Transporting IPv4 packets over IPv6 is a common solution to the >> problem of IPv4 service continuity over IPv6-only provider networks. >> A number of differing functional approaches have been developed for >> this, each having their own specific characteristics. As these >> approaches share a similar functional architecture and use the same >> data plane mechanisms, this memo describes a specification whereby a >> single CPE can interwork with all of the standardized and proposed >> approaches to providing encapsulated IPv4 in IPv6 services. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draftdirectories: >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> 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 >> > > --047d7b6222d08cabed04cfb3615a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Med,

thanks for the response. please see inline.

2012/11/30 <mohamed.boucadair@orange.com<= /a>>
Dear Maoke,
=A0
Thank you for the review and comments.=20
=A0
Please see inline.
=A0
Cheers,
Med

De=A0: Maoke [mailto:fibrib@gmail.com]=20
Envoy=E9=A0: vendredi 30 novembre 2012 03:31
=C0=A0:= =20 Suresh Krishnan
Cc=A0: BOUCADAIR Mohamed OLNC/OLN;=20 draft-cui-softwire-b4-translated-ds-lite;=20 draft-ietf-softwire-map@tools.ietf.org;=20 draft-ietf-softwire-public-4over6@tools.ietf.org; softwires@ietf.org;=20 draft-ietf-softwire-map-dhcp@tools.ietf.org
Objet=A0:= Re:=20 [Softwires] Unified Softwire CPE:=20 draft-bfmk-softwire-unified-cpe

thanks Med for the initialization of the work!

i noticed=20 that:

1. MAP is working in the context of prefix delegation and=20 therefore the LAN side IPv6 addresses (prefix) is involved in the mapping= =20 between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address=20 directly. when a unified CPE is made, the logic of the address assignment= to=20 interfaces should also consider this difference in the behaviour.
[Med] I'= ;m not sure I understand your point. Could you=20 please clarify further the difference between the stateless and binding m= ode=20 and what you think it should be added to bullet (2.3.2) of Section 3.4?= =20 Thanks.
[mao= ke] i a little doubt the binding mode is a proper way to unify the MAP 1:1 = and lw4over6. because MAP 1:1 is still working in the model of delegation w= hile lw4over6 applies the WAN IPv6 address for the encapsulation. what if t= he CPE has a delegated prefix at LAN and an address at WAN simultaneously? = which address is used for the source address of the tunnel in the "bin= ding mode"? is the CPE choice fits the reality at the AFTR/BR? to my u= nderstanding, the behaviour of MAP 1:1 is identical with any MAP but differ= ent from lw4over6 to some extent.

2. is the deployment of difference modes able to= =20 be overlapped? current section 4.4 implies the answer is "yes".= i agree. but=20 is it the best behaviour to select one mode at the device-wise according = to a=20 certain preferences? my question is: when the CPE receives multiple=20 rules/parameter-sets from different sources of provisioning, can it store= and=20 use these pieces of information to adapt packets for corresponding mode o= f=20 service, i.e., applying a proper mode on demand and session-specific?
=
[Med]=A0The curre= nt text says:=A0
=A0
=A0= =A0 o=A0 For a given network attachment, only=20 one mode MUST be activated.
[maoke ] why only ONE mode MUST be activated?

[maoke= ] we noticed a fact that a domain of softwire, at least MAP,=A0 can be diff= erent from the "domain" in the sense of autonomous system, becaus= e the model of prefix delegation is totally independent of the deployment o= f the softwire. this feature makes the softwire domain able to spread over = different AS. therefore it is possible that a CPE is involved in a AS's= lw4over6 domain and meanwhile also involved in a inter-AS MAP domain. admi= nistration of the lw4over6 domain and that of the MAP domain are surely ind= ependent to each other but they impact the CPE simultaneously -- it could b= e treated as=A0 a typical case of softwire multi-homing. and we expect the = CPE gets the benefits from the multi-homing: policy-based path selection, l= oad-balance, fault-tolerance, etc.=A0

=A0=A0 o=A0 The CPE= MAY be configured=20 by a user or via remote device
=A0=A0=A0=A0=A0 management=20 means (e.g., DHCP, TR-069).
=A0=A0 o=A0 A network which supports=20 one or several modes MUST return valid
=A0=A0=A0=A0=A0=20 configuration data allowing requesting devices to=20 unambiguously
=A0=A0=A0=A0=A0 select a single mode to use=20 for attachment.
=A0
Does this text an= swer your questions? If not, what you=20 think is needed to be added?=20 Thanks.=A0=A0


3. related to 2, how= can we=20 keep the CPE/BR CPE/AFTR consistency?

4. fragmentation issue is c= ommon=20 to all modes and it is also needed to be clarified/unified for the unifie= d=20 CPE.
[Med]=A0Fully agr= ee. We preferred to focus first on the=20 unified logic. If the WG accepts the proposed direction, then the documen= t=20 should be updated to cover items common to all modes.=20
thanks,
= - maoke

P.S. i will be in a=A0 3-nights&2-days trip since tonigh= t so any further discussion will be responded in the beginning of next week= . sorry in advance for the delay.

only my 2 cents, identifying the problems t= hat i expect=20 this draft to cover.

- maoke

2012/11/29 Suresh Krishnan &= lt;suresh= .krishnan@ericsson.com>
Thanks Med. This is a highly explor= atory draft to be used=20 as a strawman to determine if an unified CPE is even possible. Please= =20 comment on it so that we can determine if proceeding in this path is=20 worthwhile. Also, if you are interested in being an editor of this draf= t and=20 are not currently working on any of the current solution drafts please= =20 contact the chairs.

Thanks
Suresh


----- Original= =20 Message -----
From: "mohamed.boucadair@orange.com"=20 <m= ohamed.boucadair@orange.com>
To:=20 "draft-ietf-softwire-map@tools.ietf.org"=20 <draft-ietf-softwire-map@tools.ietf.org>,=20 "draft-ietf-softwire-map-dhcp@tools.ietf.org"=20 <draft-ietf-softwire-map-dhcp@tools.ietf.org>,=20 "draft-ietf-softwire-public-4over6@tools.ietf.org&q= uot;=20 <draft-ietf-softwire-public-4over6@tools.ietf.org>= ,=20 draft-cui-softwire-b4-translated-ds-lite <draft-cu= i-softwire-b4-translated-ds-lite@tools.ietf.org>,=20 "Reinaldo Penno =A0(repenno)" <repenno@cisco.com>, "softwires@ietf.org" <= softwires@ietf.org<= /a>>
Sent:=20 11/29/2012 5:16 AM
Subject: [Softwires] Unified Softwire CPE:=20 draft-bfmk-softwire-unified-cpe



Dear all,

As agre= ed in=20 Atlanta, we prepared an I-D describing a proposed approach for the unif= ied=20 CPE.

We hope this version is a good starting point to have fruit= ful=20 discussion.

Your comments, suggestions and contributions are mor= e=20 than welcome.

Cheers,
Med


-----Message=20 d'origine-----
De : i-d-announce-bounces@ietf.org=20 [mailto:i-d-announce-bounces@ietf.org]=20 De la part de internet-drafts@ietf.org
Envoy=E9=20 : jeudi 29 novembre 2012 10:57
=C0 : i-d-announce@ietf.org
Objet : I-D=20 Action: draft-bfmk-softwire-unified-cpe-00.txt


A New=20 Internet-Draft is available from the on-line Internet-Drafts=20 directories.


=A0 =A0 =A0 =A0 Title =A0 =A0=20 =A0 =A0 =A0 : Unified Softwire CPE
=A0 =A0 =A0 =A0=20 Author(s) =A0 =A0 =A0 : Mohamed Boucadair
=A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ian=20 Farrer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 Suresh Krishnan
=A0 =A0 =A0 =A0=20 Filename =A0 =A0 =A0 =A0:=20 draft-bfmk-softwire-unified-cpe-00.txt
=A0 =A0 =A0 =A0 Pages=20 =A0 =A0 =A0 =A0 =A0 : 12
=A0 =A0 =A0 =A0 Date=20 =A0 =A0 =A0 =A0 =A0 =A0:=20 2012-11-29

Abstract:
=A0 =A0Transporting IPv4 packets over=20 IPv6 is a common solution to the
=A0 =A0problem of IPv4 service=20 continuity over IPv6-only provider networks.
=A0 =A0A number of=20 differing functional approaches have been developed for
=A0=20 =A0this, each having their own specific characteristics. =A0As=20 these
=A0 =A0approaches share a similar functional architecture and= =20 use the same
=A0 =A0data plane mechanisms, this memo describes a=20 specification whereby a
=A0 =A0single CPE can interwork with all of= =20 the standardized and proposed
=A0 =A0approaches to providing=20 encapsulated IPv4 in IPv6 services.


The IETF datatracker sta= tus=20 page for this draft is:
https://datatracker.ietf= .org/doc/draft-bfmk-softwire-unified-cpe

There's=20 also a htmlized version available at:
http://tools.= ietf.org/html/draft-bfmk-softwire-unified-cpe-00


Internet-Dr= afts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce= =20 mailing list
I-D-Announce@ietf.org
https://www.ietf.or= g/mailman/listinfo/i-d-announce
Internet-Draft=20 directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-= sites.txt
_______________________________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwir= es
_______________________________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwir= es


--047d7b6222d08cabed04cfb3615a-- From wdec@cisco.com Fri Nov 30 02:42:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1239A21F8616 for ; Fri, 30 Nov 2012 02:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgH4ceEFRuTq for ; Fri, 30 Nov 2012 02:42:28 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id EB9A921F8611 for ; Fri, 30 Nov 2012 02:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4929; q=dns/txt; s=iport; t=1354272148; x=1355481748; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=VBZyxmpVh4idwDKymYtDY/pBkOM96jWMMeUBGf4uVi8=; b=aBiEp203D9lMQhLWdkPeIldadn/RPyV8AJiKJ0Gr9Auhb7aOVS2t00Fp eZz0RIWW7HVMh39m96Vq/TpKQG2CG/n/GJtHmHpX7jh4VQPgNkGNRskI7 w68ehRMsUpaa9dybTwbmI0Gy3Gmz78zqKw+I6V4dzqqjiQk9xSK/vllWP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP+LuFCtJV2d/2dsb2JhbABEwA4Wc4IgAQQBAQFrHQEIEhAdLgsUAw4BAQQBEggBEod1DL9MjECDYGEDiCiOdIobhQ2CcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="147898016" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 30 Nov 2012 10:42:27 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAUAgRau024876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 10:42:27 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.248]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 04:42:27 -0600 From: "Wojciech Dec (wdec)" To: "mohamed.boucadair@orange.com" , "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite , "Reinaldo Penno (repenno)" , "softwires@ietf.org" Thread-Topic: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3OF/pB3BIR0BudQv+t/d7Z7WY4PAAAFncAAEJuQgA= Date: Fri, 30 Nov 2012 10:42:26 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B31223C2@xmb-aln-x05.cisco.com> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.55.87.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <08542B9BA3BC09459160D22C2B40A101@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 10:42:29 -0000 Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states "co-existance" as the goal - this appears to imply some entirely different solutions for which co-existance is needed", and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a "unified solution CPE spec" in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on "unifying" MAP and Lw4o6, nor does it bear anything on the already "defined and shipped" ds.-lite solution. Work on such themes of "multiple solutions coexisting" is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. B) I disagree that "co-existance" between Lw4o6 and MAP is a goal; a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing "modes" as in "solution modes" is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. In Section 3 the draft coin a new term/class of solution called "Binding approach". This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Further in section 3 the draft lists different functional elements, and it is here that major changes are needed. For a unified solution a functional breakdown in a solution neutral text is essential. IMO A unified CE has the following basic functionalities, which I propose to be added to the text in place of the existing one: - IPv4 NAT whose address and port restrictions are configurable - an IPv6 transport whose source and destination transport address are deterministically derived/configurable - an IPv4 routing capability (also configurable) In example terms, consider a CPE configured with IPv4 address, restricted Port range X and IPv6 source address Y and transport address Z. There is no difference in these parameters between Lw4o6 and MAP, and it shows the essence of what we need to get at. One can comment further on the details of the draft, but getting the basic functional breakdown is essential (example above) before we get into that. The only thing different between the solutions are not the basic functionalities but rather how this functionality is configured. Regards, Woj.. On 29/11/2012 11:16, "mohamed.boucadair@orange.com" wrote: >Dear all, > >As agreed in Atlanta, we prepared an I-D describing a proposed approach >for the unified CPE. > >We hope this version is a good starting point to have fruitful >discussion.=20 > >Your comments, suggestions and contributions are more than welcome. > >Cheers, >Med > > >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >De la part de internet-drafts@ietf.org >Envoy=E9 : jeudi 29 novembre 2012 10:57 >=C0 : i-d-announce@ietf.org >Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Unified Softwire CPE > Author(s) : Mohamed Boucadair > Ian Farrer > Suresh Krishnan > Filename : draft-bfmk-softwire-unified-cpe-00.txt > Pages : 12 > Date : 2012-11-29 > >Abstract: > Transporting IPv4 packets over IPv6 is a common solution to the > problem of IPv4 service continuity over IPv6-only provider networks. > A number of differing functional approaches have been developed for > this, each having their own specific characteristics. As these > approaches share a similar functional architecture and use the same > data plane mechanisms, this memo describes a specification whereby a > single CPE can interwork with all of the standardized and proposed > approaches to providing encapsulated IPv4 in IPv6 services. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From wdec.ietf@gmail.com Fri Nov 30 02:51:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2950D21F84D0 for ; Fri, 30 Nov 2012 02:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBT18TFIVx3v for ; Fri, 30 Nov 2012 02:51:29 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6DD21F84CF for ; Fri, 30 Nov 2012 02:51:29 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so165441eaa.31 for ; Fri, 30 Nov 2012 02:51:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iZTiK0dLuAUVFYjlr3XNq9WldpVLJBUZy+d1ZEzxmDs=; b=FlQcIyk3gEzvvjh2nOdonJgUlIB2WWDmDJ+jeH/Katrjgc0Avtrs5zsd7BjPb8EwL0 hfgaUfSVhRXkhXXAQqTF/gFwOhyoIM8v4dtKCEDTD58kbLlz1pva6DkacetgEKjo+/v3 Z08DiRptRWFIZ5yAuIPcXeY+bDtxMtu4dShLBRkzKzdFZOagNU0fFDVqs77nHT/eiBEo JWq4jAlX+TLbOK1aSS9do3mUGu2Qr2LZ0kXVcewu++pXFGuyaJG9Au4qQyvjUI3t4Axr 13vo3dWFt7i4M0uaOjLj7ZdXOKDlhmUNvZyPe46vFGGwheB9dtC9uHVLE/4DZ9iuzaLo Tpyw== MIME-Version: 1.0 Received: by 10.14.193.136 with SMTP id k8mr3191326een.30.1354272688185; Fri, 30 Nov 2012 02:51:28 -0800 (PST) Received: by 10.14.219.72 with HTTP; Fri, 30 Nov 2012 02:51:27 -0800 (PST) In-Reply-To: References: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> Date: Fri, 30 Nov 2012 11:51:27 +0100 Message-ID: From: Wojciech Dec To: Qiong Content-Type: multipart/alternative; boundary=047d7b343e3682217604cfb42eb9 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 10:51:30 -0000 --047d7b343e3682217604cfb42eb9 Content-Type: text/plain; charset=ISO-8859-1 And much as was also said before, this categorization is bogus as all solutions need configuration state, ie categorizing solutions based on "amount of configuration" or some fluffy term like "binding approach" is equivalent to categorizing them based on "how long is a piece of string" and ultimately useless. What we do know is one-size of string does not work for all, and the implementers need to scale their configuration state as per their best judgement/capabilities. Cheers, Woj. On 30 November 2012 09:48, Qiong wrote: > Right. That's why I prefer the solution space provided by Med before, > which will be much clearer and easy to understand: > * Full stateful approach > * Binding approach > * Full stateless approach > > Best wishes > Qiong > > > On Fri, Nov 30, 2012 at 12:13 PM, Leaf yeh wrote: > >> Mark - I think the only question that should be on the table is whether a >> 1:1 rule is called something different or not - kind of like how we refer >> to a /32 or /128 as a hostroute. > > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/* > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * > =============================================== > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --047d7b343e3682217604cfb42eb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And much as was also said before, this categorization is bogus as all solut= ions need configuration state, ie categorizing solutions based on "amo= unt of configuration" or some fluffy term like "binding approach&= quot; is equivalent to categorizing them based on "how long is a piece= of string" and ultimately useless. What we do know is one-size of str= ing does not work for all, and the implementers need to scale their configu= ration state as per their best judgement/capabilities.

Cheers,
Woj.

On 30 November 2012 0= 9:48, Qiong <bingxuere@gmail.com> wrote:
Right. That's why I prefer the solution spac= e provided by Med before, which will be much clearer and easy to understand= :
* Full stateful approach
* Binding approach
* Full stateless app= roach

Best wishes
Qiong


On Fri, Nov = 30, 2012 at 12:13 PM, Leaf yeh <leaf.y.yeh@huawei.com> w= rote:
Mark - I think the only question that should= be on the table is whether a 1:1 rule is called something different or not= - kind of like how we refer to a /32 or /128 as a hostroute.



--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institude


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


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


--047d7b343e3682217604cfb42eb9-- From mohamed.boucadair@orange.com Fri Nov 30 03:10:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D6B21F86BE for ; Fri, 30 Nov 2012 03:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xsLcIcWP5LZ for ; Fri, 30 Nov 2012 03:10:23 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0575121F8518 for ; Fri, 30 Nov 2012 03:10:22 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 008FA22C774; Fri, 30 Nov 2012 12:10:22 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D21F94C017; Fri, 30 Nov 2012 12:10:21 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 30 Nov 2012 12:10:21 +0100 From: To: "Wojciech Dec (wdec)" , "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite , "Reinaldo Penno (repenno)" , "softwires@ietf.org" Date: Fri, 30 Nov 2012 12:10:21 +0100 Thread-Topic: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3OF/pB3BIR0BudQv+t/d7Z7WY4PAAAFncAAEJuQgAADnvzcA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D684@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <19F346EB777BEE4CB77DA1A2C56F20B31223C2@xmb-aln-x05.cisco.com> In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B31223C2@xmb-aln-x05.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.30.80316 Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 11:10:24 -0000 Hi Woj, Many thanks for the comments.=20 Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 >Envoy=E9 : vendredi 30 novembre 2012 11:42 >=C0 : BOUCADAIR Mohamed OLNC/OLN;=20 >draft-ietf-softwire-map@tools.ietf.org;=20 >draft-ietf-softwire-map-dhcp@tools.ietf.org;=20 >draft-ietf-softwire-public-4over6@tools.ietf.org;=20 >draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno=20 >(repenno); softwires@ietf.org >Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe > >Hi, > >While thanking the authors for their attempt, I need to=20 >provide some high >level feedback first on key issues: >The rationale section 1.1 states "co-existance" as the goal -=20 >this appears >to imply some entirely different solutions for which co-existance is >needed", and here are two points: >A) I can agree that DS.-lite is an entirely different solution, but I >firmly believe that it is entirely outside the agreed scope which was a >"unified solution CPE spec" in the context of MAP and Lw4o6.=20 >Thus, I would >recommend that ds.-lite be dropped from this draft as it bears no >influence on "unifying" MAP and Lw4o6, nor does it bear anything on the >already "defined and shipped" ds.-lite solution. Work on such themes of >"multiple solutions coexisting" is what the v6ops CPE draft is covering >and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-usi= ng existing modules.=20 * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoi= nt * A+P may be seen as an exit strategy of the CGN: optimisation migration pa= th and required changes in the CPEs need to be taken into account.=20 > >B) I disagree that "co-existance" between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the bindi= ng mode. =20 a >unified functional CPE spec for NAT44-less core relays=20 >accessed via IPv6 >is. As such, describing "modes" as in "solution modes" is not=20 >conductive >to that and a solution term neutral functional breakdown is=20 >essential and >IMO possible (further explained below). This will only make the spec >better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-= softwire-unified-cpe-00#section-4.3.=20 > >In Section 3 the draft coin a new term/class of solution=20 >called "Binding >approach". Med: FYI, this is not a new term: please refer to http://tools.ietf.org/htm= l/rfc6346#section-4.4. >This effectively refers to configuration state which *all*=20 >solutions need, >and is not helpful in providing anything but more verbiage.=20 >Removing this >classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. H= aving a neutral terminology and a full understand of what this is about is = IMHO important to converge.=20 > >Further in section 3 the draft lists different functional=20 >elements, and it >is here that major changes are needed. Med: Section 3 is to be seen as a reminder for the solution flavors we have= on the table. This section can be moved to an appendix. I would expect we = focus our discussion on Section 4. For a unified solution=20 >a functional >breakdown in a solution neutral text is essential.=20 Med: We really tried to adopt a neutral terminology in Section 4. Suggestio= ns are welcome on how to enhance that section. IMO A unified CE has >the following basic functionalities, which I propose to be added to the >text in place of the existing one: Med: Could you please point me which text you are referring to? Thanks.=20 >- IPv4 NAT whose address and port restrictions are configurable >- an IPv6 transport whose source and destination transport address are >deterministically derived/configurable > >- an IPv4 routing capability (also configurable) Med: What does that mean? > >In example terms, consider a CPE configured with IPv4 address,=20 >restricted >Port range X and IPv6 source address Y and transport address Z. >There is no difference in these parameters between Lw4o6 and=20 >MAP, and it >shows the essence of what we need to get at. Med: Isn't that what is captured in "Table 3: Supported Features" ? +--------------+----------------+-----------------+-----------------+ | Functional | IPv4-in-IPv6 | Port-restricted | Port-restricted | | Element | tunnel | IPv4 | NAT44 | | | endpoint | | | +--------------+----------------+-----------------+-----------------+ | B4 | Yes | N/A | No | +--------------+----------------+-----------------+-----------------+ | lwB4 | Yes | Yes | Optional | +--------------+----------------+-----------------+-----------------+ | MAP-E CE | Yes | Yes | Optional | +--------------+----------------+-----------------+-----------------+ > > >One can comment further on the details of the draft, but=20 >getting the basic >functional breakdown is essential (example above) before we=20 >get into that. > The only thing different between the solutions are not the basic >functionalities but rather how this functionality is configured. Med: I guess you are talking about MAP1:1 and LW4over6. > >Regards, >Woj.. > > > >On 29/11/2012 11:16, "mohamed.boucadair@orange.com" > wrote: > >>Dear all, >> >>As agreed in Atlanta, we prepared an I-D describing a=20 >proposed approach >>for the unified CPE. >> >>We hope this version is a good starting point to have fruitful >>discussion.=20 >> >>Your comments, suggestions and contributions are more than welcome. >> >>Cheers, >>Med >> >> >>-----Message d'origine----- >>De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] >>De la part de internet-drafts@ietf.org >>Envoy=E9 : jeudi 29 novembre 2012 10:57 >>=C0 : i-d-announce@ietf.org >>Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : Unified Softwire CPE >> Author(s) : Mohamed Boucadair >> Ian Farrer >> Suresh Krishnan >> Filename : draft-bfmk-softwire-unified-cpe-00.txt >> Pages : 12 >> Date : 2012-11-29 >> >>Abstract: >> Transporting IPv4 packets over IPv6 is a common solution to the >> problem of IPv4 service continuity over IPv6-only provider=20 >networks. >> A number of differing functional approaches have been developed for >> this, each having their own specific characteristics. As these >> approaches share a similar functional architecture and use the same >> data plane mechanisms, this memo describes a specification=20 >whereby a >> single CPE can interwork with all of the standardized and proposed >> approaches to providing encapsulated IPv4 in IPv6 services. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >= From wdec@cisco.com Fri Nov 30 04:20:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4912E21F8705 for ; Fri, 30 Nov 2012 04:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6LFuzhndNPf for ; Fri, 30 Nov 2012 04:20:49 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B963E21F86CE for ; Fri, 30 Nov 2012 04:20:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9852; q=dns/txt; s=iport; t=1354278049; x=1355487649; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hK1dFE/KQHmFxuc+1E7YlZRL3/R6SK7BVPcs/LOgdiU=; b=YkAXIl8o9cnnhDXU33A1rFLYFyMT2NLPQ9iwMAO14zvw637uJdSnIH83 2uG8WC2VWV8vf9E2AXwhm+sSXH9261us8pTEBCh6Nx1AbHmSTsOwVHpS7 w5XKuQi14Z/F1pPwVg0yaQBHeiMrH6n3ar+E/xSLN6ClCE50oHaEP76Ya Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANGjuFCtJXG//2dsb2JhbABEwA4Wc4IeAQEBBAEBAWsdAQgSBgoLEi4LFAMOAQEEARIIARKHdQy/XYxAgQ6CUmEDiCiOdIobhQ2CcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="147946941" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 30 Nov 2012 12:20:46 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAUCKkhv014257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 12:20:46 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.248]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 06:20:45 -0600 From: "Wojciech Dec (wdec)" To: "mohamed.boucadair@orange.com" , "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite , "Reinaldo Penno (repenno)" , "softwires@ietf.org" Thread-Topic: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3OF/pB3BIR0BudQv+t/d7Z7WY4PAAAFncAAEJuQgAADnvzcP//p5iA Date: Fri, 30 Nov 2012 12:20:45 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B31224D4@xmb-aln-x05.cisco.com> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D684@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.55.87.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4A7100812B41304CB1C8E8B2B87B4FEF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 12:20:51 -0000 Hi Med., On 30/11/2012 12:10, "mohamed.boucadair@orange.com" wrote: >Hi Woj, > >Many thanks for the comments. > >Please see inline. > >Cheers, >Med=20 > >>-----Message d'origine----- >>De : Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>Envoy=E9 : vendredi 30 novembre 2012 11:42 >>=C0 : BOUCADAIR Mohamed OLNC/OLN; >>draft-ietf-softwire-map@tools.ietf.org; >>draft-ietf-softwire-map-dhcp@tools.ietf.org; >>draft-ietf-softwire-public-4over6@tools.ietf.org; >>draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno >>(repenno); softwires@ietf.org >>Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe >> >>Hi, >> >>While thanking the authors for their attempt, I need to >>provide some high >>level feedback first on key issues: > >>The rationale section 1.1 states "co-existance" as the goal - >>this appears >>to imply some entirely different solutions for which co-existance is >>needed", and here are two points: >>A) I can agree that DS.-lite is an entirely different solution, but I >>firmly believe that it is entirely outside the agreed scope which was a >>"unified solution CPE spec" in the context of MAP and Lw4o6. >>Thus, I would >>recommend that ds.-lite be dropped from this draft as it bears no >>influence on "unifying" MAP and Lw4o6, nor does it bear anything on the >>already "defined and shipped" ds.-lite solution. Work on such themes of >>"multiple solutions coexisting" is what the v6ops CPE draft is covering >>and I would place ds.-lite coexistence there. > >Med: We included DS-Lite in the scope because of the following: > >* Several WG participants are concerned with optimizing the code and >re-using existing modules. This is an implementation reason. Should we include in this draft anything that re-uses IPinIP tunneling, which is presumably the module in question? >=20 >* Some DS-Lite components are shared with A+P solution: e.g., tunnel >endpoint The tunnel endpoint is "an address", and again, this hardly justfies ds.-lite inclusion Most notably the functionality of the regular DS.-lite AFTR is orthogonal to the working of the CPE. >* A+P may be seen as an exit strategy of the CGN: optimisation migration >path and required changes in the CPEs need to be taken into account. These topics are fine subject for some CGN-exit draft, rather then muddying up this one. >=20 > >> >>B) I disagree that "co-existance" between Lw4o6 and MAP is a goal; > >Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the >binding mode. =20 And the binding mode and duplicate descriptions should be removed IMO. > > a >>unified functional CPE spec for NAT44-less core relays >>accessed via IPv6 >>is. As such, describing "modes" as in "solution modes" is not >>conductive >>to that and a solution term neutral functional breakdown is >>essential and >>IMO possible (further explained below). This will only make the spec >>better and simpler for implementers. > >Med: This is what we tried to do in >http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#section-4.3. >=20 > >> >>In Section 3 the draft coin a new term/class of solution >>called "Binding >>approach". > >Med: FYI, this is not a new term: please refer to >http://tools.ietf.org/html/rfc6346#section-4.4. The point is that this is effectively configuration state, and calling it new terms is not changing things. > > >>This effectively refers to configuration state which *all* >>solutions need, >>and is not helpful in providing anything but more verbiage. >>Removing this >>classification from all of the text is recommended. > >Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. >Having a neutral terminology and a full understand of what this is about >is IMHO important to converge. You don't need any terminology like "binding mode", especially in the CPE spec since the CPE side doesn't care about what configuration is on the concentrator. It only cares about its own configuration and there is no difference >=20 > >> >>Further in section 3 the draft lists different functional >>elements, and it >>is here that major changes are needed. > >Med: Section 3 is to be seen as a reminder for the solution flavors we >have on the table. This section can be moved to an appendix. I would >expect we focus our discussion on Section 4. > > For a unified solution >>a functional >>breakdown in a solution neutral text is essential. > >Med: We really tried to adopt a neutral terminology in Section 4. >Suggestions are welcome on how to enhance that section. Suggestion is to can the myriad of tables and agree to the break down the basic functionality. This then allows us to focus on how it is expected to be configured (the mechanism of configuration) and using what external means (eg IP addresses, DHCP option). > >IMO A unified CE has >>the following basic functionalities, which I propose to be added to the >>text in place of the existing one: > >Med: Could you please point me which text you are referring to? Thanks. Section 3.1 >=20 > >>- IPv4 NAT whose address and port restrictions are configurable >>- an IPv6 transport whose source and destination transport address are >>deterministically derived/configurable >> >>- an IPv4 routing capability (also configurable) > >Med: What does that mean? It means IPv4 routing, and the ability to set a default route and more specific ones. > >> >>In example terms, consider a CPE configured with IPv4 address, >>restricted >>Port range X and IPv6 source address Y and transport address Z. >>There is no difference in these parameters between Lw4o6 and >>MAP, and it >>shows the essence of what we need to get at. > >Med: Isn't that what is captured in "Table 3: Supported Features" ? Yes, except you've dumped into this table DS.-lite, and made it replete with what will be normative solution terms. Get rid of the table and just state that the CPE has the basic functions of: ... And what these functions are to be configured with and how. > > +--------------+----------------+-----------------+-----------------+ > | Functional | IPv4-in-IPv6 | Port-restricted | Port-restricted | > | Element | tunnel | IPv4 | NAT44 | > | | endpoint | | | > +--------------+----------------+-----------------+-----------------+ > | B4 | Yes | N/A | No | > +--------------+----------------+-----------------+-----------------+ > | lwB4 | Yes | Yes | Optional | > +--------------+----------------+-----------------+-----------------+ > | MAP-E CE | Yes | Yes | Optional | > +--------------+----------------+-----------------+-----------------+ > > >> >> >>One can comment further on the details of the draft, but >>getting the basic >>functional breakdown is essential (example above) before we >>get into that. >> The only thing different between the solutions are not the basic >>functionalities but rather how this functionality is configured. > >Med: I guess you are talking about MAP1:1 and LW4over6. Correct. Ds.-lite doesn't fit into this draft. Cheers, -Woj.. > >> >>Regards, >>Woj.. >> >> >> >>On 29/11/2012 11:16, "mohamed.boucadair@orange.com" >> wrote: >> >>>Dear all, >>> >>>As agreed in Atlanta, we prepared an I-D describing a >>proposed approach >>>for the unified CPE. >>> >>>We hope this version is a good starting point to have fruitful >>>discussion.=20 >>> >>>Your comments, suggestions and contributions are more than welcome. >>> >>>Cheers, >>>Med >>> >>> >>>-----Message d'origine----- >>>De : i-d-announce-bounces@ietf.org >>[mailto:i-d-announce-bounces@ietf.org] >>>De la part de internet-drafts@ietf.org >>>Envoy=E9 : jeudi 29 novembre 2012 10:57 >>>=C0 : i-d-announce@ietf.org >>>Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> >>> >>> Title : Unified Softwire CPE >>> Author(s) : Mohamed Boucadair >>> Ian Farrer >>> Suresh Krishnan >>> Filename : draft-bfmk-softwire-unified-cpe-00.txt >>> Pages : 12 >>> Date : 2012-11-29 >>> >>>Abstract: >>> Transporting IPv4 packets over IPv6 is a common solution to the >>> problem of IPv4 service continuity over IPv6-only provider >>networks. >>> A number of differing functional approaches have been developed for >>> this, each having their own specific characteristics. As these >>> approaches share a similar functional architecture and use the same >>> data plane mechanisms, this memo describes a specification >>whereby a >>> single CPE can interwork with all of the standardized and proposed >>> approaches to providing encapsulated IPv4 in IPv6 services. >>> >>> >>>The IETF datatracker status page for this draft is: >>>https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 >>> >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www.ietf.org/mailman/listinfo/i-d-announce >>>Internet-Draft directories: http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> From sunqi.csnet.thu@gmail.com Fri Nov 30 04:37:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6821F86C9 for ; Fri, 30 Nov 2012 04:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szzuI6hFBxOp for ; Fri, 30 Nov 2012 04:37:19 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1385E21F84D0 for ; Fri, 30 Nov 2012 04:37:16 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so204027dae.31 for ; Fri, 30 Nov 2012 04:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=SakE58CnIoT+Vd69FD9rgpC69/y8fSCxptDcGs+4BAw=; b=JZGtNuGXoneIQvXDz5Qx1+wvGZ4p3dYztNZtAPttX10/a9bV/4BUIUelppAovCXX8Q y9z54/DiLXy//y4Gx73QMjAoOWcRneyTtHn18gIt2QZuMAKXOt7i8pTTJvDkkJHZn0NM BUEIGG/sMO8PAYYn03Cv+gwJPkUh3fHHEPkv7o4Gvw2UBeUFHDHw/oCVL+22u4nGI0s9 o1wbE2PMYb9qd0mqKiB/SDA/Q8jhE9eJ4PeoTJoCUkQotDxNujmK04cm2zPrR1jcmQb6 bPKIXicD7eYyldyVaKiu2QNygmx1zkzY66Q0FWGrI3Eo3nQwUYxfcscMfPuhd2/KHKxp noHg== Received: by 10.66.89.9 with SMTP id bk9mr2785922pab.67.1354279035842; Fri, 30 Nov 2012 04:37:15 -0800 (PST) Received: from [192.168.1.170] ([166.111.68.233]) by mx.google.com with ESMTPS id m7sm2872616paz.3.2012.11.30.04.37.12 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 04:37:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-162191038 From: Qi Sun In-Reply-To: Date: Fri, 30 Nov 2012 20:37:09 +0800 Message-Id: <27E7D19D-DCB9-4F13-906E-965C32F59213@gmail.com> References: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 12:37:22 -0000 --Apple-Mail-1-162191038 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This solution space is the outcome of Vancouver meeting. And IMO, the = word 'binding' not only means there are state to maintain, but also = indicates that IPv4 and IPv6 addresses are just bound together, with no = algorithmic relationship. Thanks, Qi Sun On 2012-11-30, at =E4=B8=8B=E5=8D=886:51, Wojciech Dec wrote: > And much as was also said before, this categorization is bogus as all = solutions need configuration state, ie categorizing solutions based on = "amount of configuration" or some fluffy term like "binding approach" is = equivalent to categorizing them based on "how long is a piece of string" = and ultimately useless. What we do know is one-size of string does not = work for all, and the implementers need to scale their configuration = state as per their best judgement/capabilities. >=20 > Cheers, > Woj. >=20 > On 30 November 2012 09:48, Qiong wrote: > Right. That's why I prefer the solution space provided by Med before, = which will be much clearer and easy to understand: > * Full stateful approach > * Binding approach > * Full stateless approach >=20 > Best wishes > Qiong >=20 >=20 > On Fri, Nov 30, 2012 at 12:13 PM, Leaf yeh = wrote: > Mark - I think the only question that should be on the table is = whether a 1:1 rule is called something different or not - kind of like = how we refer to a /32 or /128 as a hostroute. >=20 >=20 >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institude >=20 >=20 > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-1-162191038 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This solution space is the = outcome of Vancouver meeting. And IMO, the word 'binding' not only means = there are state to maintain, but also indicates that IPv4 and IPv6 = addresses are just bound together, with no algorithmic = relationship.


Thanks,
Qi Sun

On 2012-11-30, at =E4=B8=8B=E5=8D=886:51, Wojciech Dec = wrote:

And much as was also said before, this categorization is = bogus as all solutions need configuration state, ie categorizing = solutions based on "amount of configuration" or some fluffy term like = "binding approach" is equivalent to categorizing them based on "how long = is a piece of string" and ultimately useless. What we do know is = one-size of string does not work for all, and the implementers need to = scale their configuration state as per their best = judgement/capabilities.

Cheers,
Woj.

On 30 November = 2012 09:48, Qiong <bingxuere@gmail.com> = wrote:
Right. That's why I prefer the solution space = provided by Med before, which will be much clearer and easy to = understand:
* Full stateful approach
* Binding approach
* Full = stateless approach

Best wishes
Qiong


On Fri, Nov 30, 2012 at 12:13 PM, Leaf yeh <leaf.y.yeh@huawei.com> wrote:
Mark - I think the = only question that should be on the table is whether a 1:1 rule is = called something different or not - kind of like how we refer to a /32 = or /128 as a hostroute.



-- =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qion= g Sun
China Telecom Beijing Research Institude


Open source = code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=



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


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

= --Apple-Mail-1-162191038-- From simon.perreault@viagenie.ca Fri Nov 30 04:59:27 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9053421F8715 for ; Fri, 30 Nov 2012 04:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9h9kbgp++RZ for ; Fri, 30 Nov 2012 04:59:27 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id F40EE21F86C8 for ; Fri, 30 Nov 2012 04:59:26 -0800 (PST) Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 271C240384 for ; Fri, 30 Nov 2012 07:59:26 -0500 (EST) Message-ID: <50B8ADAD.5010409@viagenie.ca> Date: Fri, 30 Nov 2012 13:59:25 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 12:59:27 -0000 Le 2012-11-29 11:16, mohamed.boucadair@orange.com a écrit : > As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. > > We hope this version is a good starting point to have fruitful discussion. > > Your comments, suggestions and contributions are more than welcome. Here are some: - First, I think this is very positive. I like what I'm reading. - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the "minor change to lw4o6" that section 4.1 hints at? - In section "3.2. Required Provisoning Information", I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite < lw4o6 < MAP) One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. (I will refrain from commenting on section 4.4 until we have the higher-level design figured out.) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange.com Fri Nov 30 05:09:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4A321F84FB for ; Fri, 30 Nov 2012 05:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3afU7K2oa4T for ; Fri, 30 Nov 2012 05:09:15 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 223B221F84F2 for ; Fri, 30 Nov 2012 05:09:14 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3A3A718C99B; Fri, 30 Nov 2012 14:09:14 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BE9C735C06A; Fri, 30 Nov 2012 14:09:13 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 30 Nov 2012 14:09:13 +0100 From: To: Simon Perreault , "softwires@ietf.org" Date: Fri, 30 Nov 2012 14:09:11 +0100 Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3O+oqMF7eGV3gzSUSih1urjNDmjgAACvkw Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> In-Reply-To: <50B8ADAD.5010409@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.30.80316 Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 13:09:19 -0000 Hi Simon, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Simon Perreault >Envoy=E9 : vendredi 30 novembre 2012 13:59 >=C0 : softwires@ietf.org >Objet : Re: [Softwires] Unified Softwire CPE:=20 >draft-bfmk-softwire-unified-cpe > >Le 2012-11-29 11:16, mohamed.boucadair@orange.com a =E9crit : >> As agreed in Atlanta, we prepared an I-D describing a=20 >proposed approach for the unified CPE. >> >> We hope this version is a good starting point to have=20 >fruitful discussion. >> >> Your comments, suggestions and contributions are more than welcome. > >Here are some: > >- First, I think this is very positive. I like what I'm reading. Med: Thanks. > > >- Didn't we also consider public 4o6 as one mode? Any reason=20 >why it was=20 >left out? > - Is public 4o6 the "minor change to lw4o6" that section=20 >4.1 hints at? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding= mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network.=20 > > >- In section "3.2. Required Provisoning Information", I=20 >believe it would=20 >be possible and beneficial to specify only what each mode requires *in=20 >addition* to what the previous mode already provides. e.g. > - DS-Lite requires the remote tunnel endpoint address. > - In addition to that, lw4o6 requires the CPE's IPv4=20 >address and port=20 >set. > - In addition to that, MAP requires mesh routes. >So each mode's provisioning parameters would be a superset of the=20 >previous one. (DS-Lite < lw4o6 < MAP) Med: The current text of Section 3.2 says: +---------+-------------------------------------+ | Mode | Provisioning Information | +---------+-------------------------------------+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address | | | Port Set | | MAP-E | Mapping Rules | | | MAP Domain Parameters | +---------+-------------------------------------+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Tha= nks. > >One we have this kind of hierarchical provisioning, we can define CPE=20 >behaviour in the same way. For example, MAP behaviour would be: >1. Do exactly what a lw4o6 CPE does. >2. In addition to 1, also send and receive packets directly to=20 >and from=20 >other CPEs according to the provisioned mesh routes. Med: Do you think this is different from the approach adopted in Section 4.= 3? > >(I will refrain from commenting on section 4.4 until we have the=20 >higher-level design figured out.) > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From mohamed.boucadair@orange.com Fri Nov 30 05:17:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4683021F8203 for ; Fri, 30 Nov 2012 05:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYOUjDiomR7h for ; Fri, 30 Nov 2012 05:17:17 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C1D1B21F85BC for ; Fri, 30 Nov 2012 05:17:16 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2713B3246AA; Fri, 30 Nov 2012 14:17:16 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id DE72823805C; Fri, 30 Nov 2012 14:17:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 30 Nov 2012 14:17:15 +0100 From: To: "Wojciech Dec (wdec)" , "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite , "Reinaldo Penno (repenno)" , "softwires@ietf.org" Date: Fri, 30 Nov 2012 14:17:13 +0100 Thread-Topic: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3OF/pB3BIR0BudQv+t/d7Z7WY4PAAAFncAAEJuQgAADnvzcP//p5iAgABtggA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D706@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E99E2D684@PUEXCB1B.nanterre.francetelecom.fr> <19F346EB777BEE4CB77DA1A2C56F20B31224D4@xmb-aln-x05.cisco.com> In-Reply-To: <19F346EB777BEE4CB77DA1A2C56F20B31224D4@xmb-aln-x05.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.30.125423 Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 13:17:21 -0000 Re-, Please see inline/=20 Cheers, Med=20 >-----Message d'origine----- >De : Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 >Envoy=E9 : vendredi 30 novembre 2012 13:21 >=C0 : BOUCADAIR Mohamed OLNC/OLN;=20 >draft-ietf-softwire-map@tools.ietf.org;=20 >draft-ietf-softwire-map-dhcp@tools.ietf.org;=20 >draft-ietf-softwire-public-4over6@tools.ietf.org;=20 >draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno=20 >(repenno); softwires@ietf.org >Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe > >Hi Med., > >On 30/11/2012 12:10, "mohamed.boucadair@orange.com" > wrote: > >> >>>-----Message d'origine----- >>>De : Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>>Envoy=E9 : vendredi 30 novembre 2012 11:42 >>>=C0 : BOUCADAIR Mohamed OLNC/OLN; >>>draft-ietf-softwire-map@tools.ietf.org; >>>draft-ietf-softwire-map-dhcp@tools.ietf.org; >>>draft-ietf-softwire-public-4over6@tools.ietf.org; >>>draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno >>>(repenno); softwires@ietf.org >>>Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe >>> >>>Hi, >>> >>>While thanking the authors for their attempt, I need to >>>provide some high >>>level feedback first on key issues: >> >>>The rationale section 1.1 states "co-existance" as the goal - >>>this appears >>>to imply some entirely different solutions for which co-existance is >>>needed", and here are two points: >>>A) I can agree that DS.-lite is an entirely different solution, but I >>>firmly believe that it is entirely outside the agreed scope=20 >which was a >>>"unified solution CPE spec" in the context of MAP and Lw4o6. >>>Thus, I would >>>recommend that ds.-lite be dropped from this draft as it bears no >>>influence on "unifying" MAP and Lw4o6, nor does it bear=20 >anything on the >>>already "defined and shipped" ds.-lite solution. Work on=20 >such themes of >>>"multiple solutions coexisting" is what the v6ops CPE draft=20 >is covering >>>and I would place ds.-lite coexistence there. >> >>Med: We included DS-Lite in the scope because of the following: >> >>* Several WG participants are concerned with optimizing the code and >>re-using existing modules. > >This is an implementation reason. Should we include in this=20 >draft anything >that re-uses IPinIP tunneling, which is presumably the module=20 >in question? > >>=20 >>* Some DS-Lite components are shared with A+P solution: e.g., tunnel >>endpoint > >The tunnel endpoint is "an address", and again, this hardly justfies >ds.-lite inclusion >Most notably the functionality of the regular DS.-lite AFTR is=20 >orthogonal >to the working of the CPE. > >>* A+P may be seen as an exit strategy of the CGN:=20 >optimisation migration >>path and required changes in the CPEs need to be taken into account. > >These topics are fine subject for some CGN-exit draft, rather then >muddying up this one. Med: It is unfortunate to specify a unified CPE and exclude DS-Lite from it= . All the solutions we are discussing have the same objectives: offer IPv4 = service continuity over IPv6 network. Unlike A+P related solution,=20 * DS-Lite code is already supported by some CPEs * NAT44 code is already supported by CPEs * A standard method to provision the remote IPv4-in-IPv6 tunnel endpoint=20 The draft provides these items as a reminder. Having this big picture view = will help in assessing which modules are worth to be re-used and which func= tions are missing.=20 New solutions is almost a combination of existing modules + new configurati= on parameters. As I said earlier, all Section 3 can be removed to an appendix. I personall= y preferred to have in the core text for -00 so the WG is aware of: * solution flavors * subtleties between these solutions >>=20 >> >>> >>>B) I disagree that "co-existance" between Lw4o6 and MAP is a goal; >> >>Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the >>binding mode. =20 > >And the binding mode and duplicate descriptions should be removed IMO. >> >> a >>>unified functional CPE spec for NAT44-less core relays >>>accessed via IPv6 >>>is. As such, describing "modes" as in "solution modes" is not >>>conductive >>>to that and a solution term neutral functional breakdown is >>>essential and >>>IMO possible (further explained below). This will only make the spec >>>better and simpler for implementers. >> >>Med: This is what we tried to do in >>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00# >section-4.3. >>=20 >> >>> >>>In Section 3 the draft coin a new term/class of solution >>>called "Binding >>>approach". >> >>Med: FYI, this is not a new term: please refer to >>http://tools.ietf.org/html/rfc6346#section-4.4. > >The point is that this is effectively configuration state, and=20 >calling it >new terms is not changing things. >> >> >>>This effectively refers to configuration state which *all* >>>solutions need, >>>and is not helpful in providing anything but more verbiage. >>>Removing this >>>classification from all of the text is recommended. >> >>Med: IMHO this is the core of the discussion between MAP and=20 >Lw4o6 teams. >>Having a neutral terminology and a full understand of what=20 >this is about >>is IMHO important to converge. > >You don't need any terminology like "binding mode", especially=20 >in the CPE >spec since the CPE side doesn't care about what configuration is on the >concentrator. It only cares about its own configuration and there is no >difference Med: You may notice, the algo proposed in Section 4.3 does only care about = what to do with configuration parameters. From ian.farrer@telekom.de Fri Nov 30 05:22:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F068E21F8C81 for ; Fri, 30 Nov 2012 05:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCQHtOVDxn+D for ; Fri, 30 Nov 2012 05:22:10 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id BF09B21F8BA6 for ; Fri, 30 Nov 2012 05:22:09 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 30 Nov 2012 14:22:03 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 30 Nov 2012 14:22:03 +0100 From: To: , Date: Fri, 30 Nov 2012 14:22:12 +0100 Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3O/a9izBj+++DfS3WqK1UYubqtJw== Message-ID: In-Reply-To: <50B8ADAD.5010409@viagenie.ca> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 13:22:11 -0000 Hi Simon, One answer in line (I think Med covered off the rest) Cheers, Ian On 30/11/2012 13:59, "Simon Perreault" wrote: >Le 2012-11-29 11:16, mohamed.boucadair@orange.com a =E9crit : >> As agreed in Atlanta, we prepared an I-D describing a proposed approach >>for the unified CPE. >> >> We hope this version is a good starting point to have fruitful >>discussion. >> >> Your comments, suggestions and contributions are more than welcome. > >Here are some: > >- First, I think this is very positive. I like what I'm reading. > > >- Didn't we also consider public 4o6 as one mode? Any reason why it was >left out? > - Is public 4o6 the "minor change to lw4o6" that section 4.1 hints at? > > >- In section "3.2. Required Provisoning Information", I believe it would >be possible and beneficial to specify only what each mode requires *in >addition* to what the previous mode already provides. e.g. > - DS-Lite requires the remote tunnel endpoint address. > - In addition to that, lw4o6 requires the CPE's IPv4 address and port >set. > - In addition to that, MAP requires mesh routes. >So each mode's provisioning parameters would be a superset of the >previous one. (DS-Lite < lw4o6 < MAP) > >One we have this kind of hierarchical provisioning, we can define CPE >behaviour in the same way. For example, MAP behaviour would be: >1. Do exactly what a lw4o6 CPE does. >2. In addition to 1, also send and receive packets directly to and from >other CPEs according to the provisioned mesh routes. > >(I will refrain from commenting on section 4.4 until we have the >higher-level design figured out.) Ian: I broadly agree with what you've said, but one use case that did cross my mind is if you only needed to provision mesh routes to a client with no need for a concentrator/default route. A closed machine-to-machine type service could be an example of this architecture. I'm not sure if it's a strong enough use case to build the provisioning model around, however. > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From simon.perreault@viagenie.ca Fri Nov 30 05:24:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE4621F85CF for ; Fri, 30 Nov 2012 05:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6Mf8bmYpsHl for ; Fri, 30 Nov 2012 05:24:16 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C721F84CC for ; Fri, 30 Nov 2012 05:24:16 -0800 (PST) Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EB63540384; Fri, 30 Nov 2012 08:24:15 -0500 (EST) Message-ID: <50B8B37F.7000609@viagenie.ca> Date: Fri, 30 Nov 2012 14:24:15 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 13:24:17 -0000 Le 2012-11-30 14:09, mohamed.boucadair@orange.com a écrit : >> - Didn't we also consider public 4o6 as one mode? Any reason >> why it was >> left out? >> - Is public 4o6 the "minor change to lw4o6" that section >> 4.1 hints at? > > Med: The rationale we adopted in this draft is as follows: > > * there are three major flavors: full stateful, full stateless, and binding mode > * all these modes can support assigning a full or a shared IPv4 address > > As such Public4over6 is classified as part of binding mode (see Section 3) > > (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) > [I-D.cui-softwire-b4-translated-ds-lite], > [I-D.ietf-softwire-public-4over6] or MAP 1:1 > [I-D.ietf-softwire-map] ): Requires a single per-subscriber > state (or a few) to be maintained in the Service Provider's > network. Ah, right, I missed that reference. Thanks. >> - In section "3.2. Required Provisoning Information", I >> believe it would >> be possible and beneficial to specify only what each mode requires *in >> addition* to what the previous mode already provides. e.g. >> - DS-Lite requires the remote tunnel endpoint address. >> - In addition to that, lw4o6 requires the CPE's IPv4 >> address and port >> set. >> - In addition to that, MAP requires mesh routes. >> So each mode's provisioning parameters would be a superset of the >> previous one. (DS-Lite < lw4o6 < MAP) > > Med: The current text of Section 3.2 says: > > +---------+-------------------------------------+ > | Mode | Provisioning Information | > +---------+-------------------------------------+ > | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | > | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | > | | IPv4 Address | > | | Port Set | > | MAP-E | Mapping Rules | > | | MAP Domain Parameters | > +---------+-------------------------------------+ > > Table 4: Provisioning Information > > Note: MAP Mapping Rules are translated into the following > configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel > Endpoints, IPv4 Address and Port Set. > > Can you please explicit the change you want to see appear in that text? Thanks. Something like: DS-Lite: - Remote IPv4-in-IPv6 Tunnel Endpoint Lw4o6: - DS-Lite set of provisioning information - IPv4 address - Port set MAP-E: - Lw4o6 set of provisioning information - Forwarding mapping rules My intuition is that with a unified CPE we don't need MAP to differentiate between "basic mapping rule", "forwarding mapping rule", and "default mapping rule". - Basic mapping rule is just a forwarding mapping rule + IPv4 address + port set. - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. So in MAP mode we can just provide forwarding mapping rules in addition to the stuff that L4o6 already requires. >> One we have this kind of hierarchical provisioning, we can define CPE >> behaviour in the same way. For example, MAP behaviour would be: >> 1. Do exactly what a lw4o6 CPE does. >> 2. In addition to 1, also send and receive packets directly to >> and from >> other CPEs according to the provisioned mesh routes. > > Med: Do you think this is different from the approach adopted in Section 4.3? Well just from reading I thought it was different. Maybe your intent was what I expected, just not formulated the way I expected it. One thing I expected to see is that if you take a unified CPE that only implements up to LW4o6 mode, and provision it with full MAP mode parameters, it will still work. It will ignore the forwarding mapping rules, and thus will not do mesh networking, but it will still work. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Nov 30 05:38:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40F621F8826 for ; Fri, 30 Nov 2012 05:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGHKhgoDXhwe for ; Fri, 30 Nov 2012 05:38:28 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 232A421F8823 for ; Fri, 30 Nov 2012 05:38:27 -0800 (PST) Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2418B46984; Fri, 30 Nov 2012 08:38:27 -0500 (EST) Message-ID: <50B8B6D2.8030905@viagenie.ca> Date: Fri, 30 Nov 2012 14:38:26 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: ian.farrer@telekom.de References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: softwires@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 13:38:28 -0000 Le 2012-11-30 14:22, ian.farrer@telekom.de a écrit : > Ian: I broadly agree with what you've said, but one use case that did > cross my mind is if you only needed to provision mesh routes to a client > with no need for a concentrator/default route. A closed machine-to-machine > type service could be an example of this architecture. Ah good point. I always forget about that use case. > I'm not sure if it's a strong enough use case to build the provisioning > model around, however. Not sure either. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From wdec@cisco.com Fri Nov 30 06:00:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75221F89C3 for ; Fri, 30 Nov 2012 06:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPi8C6FXI7G7 for ; Fri, 30 Nov 2012 06:00:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 141BC21F89BB for ; Fri, 30 Nov 2012 06:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6495; q=dns/txt; s=iport; t=1354284032; x=1355493632; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=IWI7iH6BnCqIYZoK/8F6RddCTSyHabfSdxtJrtBi/AQ=; b=F29pJSD/NK6ljjmePkrYH5HcnCwiWoMNuUvV81Sy144U283VIIAMa54F Mgu6aR5SJQyoo0Xw2ohizwmTVkBo1W6p9+eH84VwPyClwAy5T/XeicNrh enXJAeYwyILwLk3OgXu67iZM83awR0QfxdKkGtFHzCBNDegh6C8jCSPQV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALi7uFCtJXG9/2dsb2JhbABEwA0Wc4IeAQEBBIELAQgYCgsSORQRAgQBEggTh3UMv2GMQIEOglJhA4gojnSPKIJygiE X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="147757626" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 30 Nov 2012 14:00:11 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAUE0Bht009635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 14:00:11 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.248]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 08:00:11 -0600 From: "Wojciech Dec (wdec)" To: "mohamed.boucadair@orange.com" , "draft-ietf-softwire-map@tools.ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-softwire-public-4over6@tools.ietf.org" , draft-cui-softwire-b4-translated-ds-lite , "Reinaldo Penno (repenno)" , "softwires@ietf.org" Thread-Topic: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3OF/pB3BIR0BudQv+t/d7Z7WY4PAAAFncAAEJuQgAADnvzcP//p5iAgABtggD//65EgA== Date: Fri, 30 Nov 2012 14:00:10 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B31225DB@xmb-aln-x05.cisco.com> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D706@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.55.87.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:00:34 -0000 On 30/11/2012 14:17, "mohamed.boucadair@orange.com" wrote: >Re-, > >Please see inline/ > >Cheers, >Med=20 > >>-----Message d'origine----- >>De : Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>Envoy=E9 : vendredi 30 novembre 2012 13:21 >>=C0 : BOUCADAIR Mohamed OLNC/OLN; >>draft-ietf-softwire-map@tools.ietf.org; >>draft-ietf-softwire-map-dhcp@tools.ietf.org; >>draft-ietf-softwire-public-4over6@tools.ietf.org; >>draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno >>(repenno); softwires@ietf.org >>Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe >> >>Hi Med., >> >>On 30/11/2012 12:10, "mohamed.boucadair@orange.com" >> wrote: >> >>> >>>>-----Message d'origine----- >>>>De : Wojciech Dec (wdec) [mailto:wdec@cisco.com] >>>>Envoy=E9 : vendredi 30 novembre 2012 11:42 >>>>=C0 : BOUCADAIR Mohamed OLNC/OLN; >>>>draft-ietf-softwire-map@tools.ietf.org; >>>>draft-ietf-softwire-map-dhcp@tools.ietf.org; >>>>draft-ietf-softwire-public-4over6@tools.ietf.org; >>>>draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno >>>>(repenno); softwires@ietf.org >>>>Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe >>>> >>>>Hi, >>>> >>>>While thanking the authors for their attempt, I need to >>>>provide some high >>>>level feedback first on key issues: >>> >>>>The rationale section 1.1 states "co-existance" as the goal - >>>>this appears >>>>to imply some entirely different solutions for which co-existance is >>>>needed", and here are two points: >>>>A) I can agree that DS.-lite is an entirely different solution, but I >>>>firmly believe that it is entirely outside the agreed scope >>which was a >>>>"unified solution CPE spec" in the context of MAP and Lw4o6. >>>>Thus, I would >>>>recommend that ds.-lite be dropped from this draft as it bears no >>>>influence on "unifying" MAP and Lw4o6, nor does it bear >>anything on the >>>>already "defined and shipped" ds.-lite solution. Work on >>such themes of >>>>"multiple solutions coexisting" is what the v6ops CPE draft >>is covering >>>>and I would place ds.-lite coexistence there. >>> >>>Med: We included DS-Lite in the scope because of the following: >>> >>>* Several WG participants are concerned with optimizing the code and >>>re-using existing modules. >> >>This is an implementation reason. Should we include in this >>draft anything >>that re-uses IPinIP tunneling, which is presumably the module >>in question? >> >>>=20 >>>* Some DS-Lite components are shared with A+P solution: e.g., tunnel >>>endpoint >> >>The tunnel endpoint is "an address", and again, this hardly justfies >>ds.-lite inclusion >>Most notably the functionality of the regular DS.-lite AFTR is >>orthogonal >>to the working of the CPE. >> >>>* A+P may be seen as an exit strategy of the CGN: >>optimisation migration >>>path and required changes in the CPEs need to be taken into account. >> >>These topics are fine subject for some CGN-exit draft, rather then >>muddying up this one. > >Med: It is unfortunate to specify a unified CPE and exclude DS-Lite from >it. All the solutions we are discussing have the same objectives: offer >IPv4 service continuity over IPv6 network. Unlike A+P related solution, There are/were many unfortunate things in softwires, but keeping ds.-lite-isms out of this spec would certainly not be one of them. I sympathize with your POV that a way to "co-exist" is desired, and a CGN-exit draft needed, but that is simply *outside* the scope of this spec. The ds.-lite ship has sailed, and there is nothing common between this spec and ds.-lite other than RFC2473. Anything with RFC2473 "heritage" should be included otherwise. >=20 >* DS-Lite code is already supported by some CPEs >* NAT44 code is already supported by CPEs >* A standard method to provision the remote IPv4-in-IPv6 tunnel endpoint > >The draft provides these items as a reminder. Having this big picture >view will help in assessing which modules are worth to be re-used and >which functions are missing. > >New solutions is almost a combination of existing modules + new >configuration parameters. > >As I said earlier, all Section 3 can be removed to an appendix. I >personally preferred to have in the core text for -00 so the WG is aware >of: > >* solution flavors >* subtleties between these solutions > > >>>=20 >>> >>>> >>>>B) I disagree that "co-existance" between Lw4o6 and MAP is a goal; >>> >>>Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the >>>binding mode. =20 >> >>And the binding mode and duplicate descriptions should be removed IMO. >>> >>> a >>>>unified functional CPE spec for NAT44-less core relays >>>>accessed via IPv6 >>>>is. As such, describing "modes" as in "solution modes" is not >>>>conductive >>>>to that and a solution term neutral functional breakdown is >>>>essential and >>>>IMO possible (further explained below). This will only make the spec >>>>better and simpler for implementers. >>> >>>Med: This is what we tried to do in >>>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00# >>section-4.3. >>>=20 >>> >>>> >>>>In Section 3 the draft coin a new term/class of solution >>>>called "Binding >>>>approach". >>> >>>Med: FYI, this is not a new term: please refer to >>>http://tools.ietf.org/html/rfc6346#section-4.4. >> >>The point is that this is effectively configuration state, and >>calling it >>new terms is not changing things. >>> >>> >>>>This effectively refers to configuration state which *all* >>>>solutions need, >>>>and is not helpful in providing anything but more verbiage. >>>>Removing this >>>>classification from all of the text is recommended. >>> >>>Med: IMHO this is the core of the discussion between MAP and >>Lw4o6 teams. >>>Having a neutral terminology and a full understand of what >>this is about >>>is IMHO important to converge. >> >>You don't need any terminology like "binding mode", especially >>in the CPE >>spec since the CPE side doesn't care about what configuration is on the >>concentrator. It only cares about its own configuration and there is no >>difference > >Med: You may notice, the algo proposed in Section 4.3 does only care >about what to do with configuration parameters. Yes, and I remain hopeful of distilling things down along that path. :-) Cheers, Woj.. > From mohamed.boucadair@orange.com Fri Nov 30 06:18:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22C21F8AB2 for ; Fri, 30 Nov 2012 06:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMA+PwvLy9UK for ; Fri, 30 Nov 2012 06:18:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 249C221F89CE for ; Fri, 30 Nov 2012 06:18:26 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id B7D9418C7B4; Fri, 30 Nov 2012 15:18:21 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8CE9D27C054; Fri, 30 Nov 2012 15:18:21 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 30 Nov 2012 15:18:20 +0100 From: To: Simon Perreault Date: Fri, 30 Nov 2012 15:18:19 +0100 Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3O/gCJOAVKxseZTPuWemmAbRJy4gAAs5Jg Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2D777@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <50B8B37F.7000609@viagenie.ca> In-Reply-To: <50B8B37F.7000609@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.30.130624 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:18:28 -0000 Re-, =20 >-----Message d'origine----- >De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 >Envoy=E9 : vendredi 30 novembre 2012 14:24 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : softwires@ietf.org >Objet : Re: [Softwires] Unified Softwire CPE:=20 >draft-bfmk-softwire-unified-cpe > >Le 2012-11-30 14:09, mohamed.boucadair@orange.com a =E9crit : >>> - Didn't we also consider public 4o6 as one mode? Any reason >>> why it was >>> left out? >>> - Is public 4o6 the "minor change to lw4o6" that section >>> 4.1 hints at? >> >> Med: The rationale we adopted in this draft is as follows: >> >> * there are three major flavors: full stateful, full=20 >stateless, and binding mode >> * all these modes can support assigning a full or a shared=20 >IPv4 address >> >> As such Public4over6 is classified as part of binding mode=20 >(see Section 3) >> >> (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) >> [I-D.cui-softwire-b4-translated-ds-lite], >> [I-D.ietf-softwire-public-4over6] or MAP 1:1 >> [I-D.ietf-softwire-map] ): Requires a single per-subscriber >> state (or a few) to be maintained in the Service Provider's >> network. > >Ah, right, I missed that reference. Thanks. > >>> - In section "3.2. Required Provisoning Information", I >>> believe it would >>> be possible and beneficial to specify only what each mode=20 >requires *in >>> addition* to what the previous mode already provides. e.g. >>> - DS-Lite requires the remote tunnel endpoint address. >>> - In addition to that, lw4o6 requires the CPE's IPv4 >>> address and port >>> set. >>> - In addition to that, MAP requires mesh routes. >>> So each mode's provisioning parameters would be a superset of the >>> previous one. (DS-Lite < lw4o6 < MAP) >> >> Med: The current text of Section 3.2 says: >> >> +---------+-------------------------------------+ >> | Mode | Provisioning Information | >> +---------+-------------------------------------+ >> | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | >> | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | >> | | IPv4 Address | >> | | Port Set | >> | MAP-E | Mapping Rules | >> | | MAP Domain Parameters | >> +---------+-------------------------------------+ >> >> Table 4: Provisioning Information >> >> Note: MAP Mapping Rules are translated into the following >> configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel >> Endpoints, IPv4 Address and Port Set. >> >> Can you please explicit the change you want to see appear in=20 >that text? Thanks. > >Something like: > >DS-Lite: >- Remote IPv4-in-IPv6 Tunnel Endpoint > >Lw4o6: >- DS-Lite set of provisioning information >- IPv4 address >- Port set > >MAP-E: >- Lw4o6 set of provisioning information >- Forwarding mapping rules Med: Because of the dependency between the IPv4 address/IPv6 prefix, additi= onal parameters are needed for MAP. This is why the table included two entr= ies for MAP. > >My intuition is that with a unified CPE we don't need MAP to=20 >differentiate between "basic mapping rule", "forwarding mapping rule",=20 >and "default mapping rule". >- Basic mapping rule is just a forwarding mapping rule + IPv4=20 >address +=20 >port set. >- Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. > >So in MAP mode we can just provide forwarding mapping rules in=20 >addition=20 >to the stuff that L4o6 already requires. Med: you need also MAP parameters (offset, EA-...). > >>> One we have this kind of hierarchical provisioning, we can=20 >define CPE >>> behaviour in the same way. For example, MAP behaviour would be: >>> 1. Do exactly what a lw4o6 CPE does. >>> 2. In addition to 1, also send and receive packets directly to >>> and from >>> other CPEs according to the provisioned mesh routes. >> >> Med: Do you think this is different from the approach=20 >adopted in Section 4.3? > >Well just from reading I thought it was different. Maybe your=20 >intent was=20 >what I expected, just not formulated the way I expected it. > >One thing I expected to see is that if you take a unified CPE=20 >that only=20 >implements up to LW4o6 mode, and provision it with full MAP mode=20 >parameters, it will still work. It will ignore the forwarding mapping=20 >rules, and thus will not do mesh networking, but it will still work. Med: Isn't this covered by the combination of these two points:=20 o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. and (1) If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE MUST be configured with the required provisioning information listed in Table 4. If all of the required information is not available locally, the CPE MUST use available provisioning means (e.g., DHCP) to retrieve the missing configuration data. If one mode is enabled, the CPE won't ask for more than what it needs.=20 If its receives more, it will ignore them. I can add this to text if you th= ink it is missing.= From simon.perreault@viagenie.ca Fri Nov 30 06:30:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9802221F89A9 for ; Fri, 30 Nov 2012 06:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSf6aONe7pII for ; Fri, 30 Nov 2012 06:30:39 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C634521F8935 for ; Fri, 30 Nov 2012 06:30:39 -0800 (PST) Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9529A4038B; Fri, 30 Nov 2012 09:30:38 -0500 (EST) Message-ID: <50B8C30D.9000506@viagenie.ca> Date: Fri, 30 Nov 2012 15:30:37 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <50B8B37F.7000609@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D777@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D777@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:30:40 -0000 Le 2012-11-30 15:18, mohamed.boucadair@orange.com a écrit : >> MAP-E: >> - Lw4o6 set of provisioning information >> - Forwarding mapping rules > > Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP. I don't follow. A MAP default mapping rule is exactly like a forwarding mapping rule, with added semantics saying "this chunk of IPv4 is yours". That can be split into a forwarding mapping rule + the usual LW4o6 parameters, can't you? >> My intuition is that with a unified CPE we don't need MAP to >> differentiate between "basic mapping rule", "forwarding mapping rule", >> and "default mapping rule". >> - Basic mapping rule is just a forwarding mapping rule + IPv4 >> address + >> port set. >> - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint. >> >> So in MAP mode we can just provide forwarding mapping rules in >> addition >> to the stuff that L4o6 already requires. > > Med: you need also MAP parameters (offset, EA-...). That stuff is included in a "forwarding mapping rule". >> One thing I expected to see is that if you take a unified CPE >> that only >> implements up to LW4o6 mode, and provision it with full MAP mode >> parameters, it will still work. It will ignore the forwarding mapping >> rules, and thus will not do mesh networking, but it will still work. > > Med: Isn't this covered by the combination of these two points: > > o A network which supports one or several modes MUST return valid > configuration data allowing requesting devices to unambiguously > select a single mode to use for attachment. > > and > > (1) If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE > MUST be configured with the required provisioning information > listed in Table 4. If all of the required information is not > available locally, the CPE MUST use available provisioning means > (e.g., DHCP) to retrieve the missing configuration data. > > If one mode is enabled, the CPE won't ask for more than what it needs. > If its receives more, it will ignore them. I can add this to text if you think it is missing. I think it would be good, and I would even add a specific example of what happens if you plug a LW4o6 CPE in a MAP-enabled network. (What I wrote above.) Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From wdec.ietf@gmail.com Fri Nov 30 07:40:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3E721F8B4B for ; Fri, 30 Nov 2012 07:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GHtkq9aNWVz for ; Fri, 30 Nov 2012 07:40:36 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C705F21F8B24 for ; Fri, 30 Nov 2012 07:40:35 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so431721eek.31 for ; Fri, 30 Nov 2012 07:40:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZDUd4Q+iEwvB2XLkG83OKsVpRAH+D4Urm3xdKOQxt+Y=; b=d5OwPsAgEpCQQzqviJi9WpBFKSnAhxe+T+nXbMuHLNsW8l9Wt5AlLoBvP7gzjfzV9q hlx3pldYut7rKGrkKDkNRo6/D6inae6x9sAy4sc8RROrEAlqFc2Bvb34I4mzNLprGSAD 6oJ7EyEXnvK1PpPaIz4CxTt4lpmE+l8cNFAxH/jM9NKgcpo/OX91/THFlzQos4XcPPoL eFdRl0jdcN5hiU3F1uPJeE0TFbVtFZPe8f6ZzpEHHtWI7Uz2IbLO0I+yDxaGLfg5hV4C jHRSU6h1N5NskvMeIhzqNf79f3XpbbJDN4pzJusJP/GjJ+m+23Y6W5qz82R49o493EZT /wcA== MIME-Version: 1.0 Received: by 10.14.216.193 with SMTP id g41mr5714117eep.37.1354290035003; Fri, 30 Nov 2012 07:40:35 -0800 (PST) Received: by 10.14.219.72 with HTTP; Fri, 30 Nov 2012 07:40:34 -0800 (PST) In-Reply-To: <27E7D19D-DCB9-4F13-906E-965C32F59213@gmail.com> References: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> <27E7D19D-DCB9-4F13-906E-965C32F59213@gmail.com> Date: Fri, 30 Nov 2012 16:40:34 +0100 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=047d7b6220727591a804cfb8384a Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 15:40:37 -0000 --047d7b6220727591a804cfb8384a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30 November 2012 13:37, Qi Sun wrote: > This solution space is the outcome of Vancouver meeting. And IMO, the wor= d > 'binding' not only means there are state to maintain, but also indicates > that IPv4 and IPv6 addresses are just bound together, with no algorithmic > relationship. > You just described an algorithm. I will assert that the *only* tangible difference between is whether it is derived from the data plane or not. Both lw46 and MAP do not derive their state from the data plane, but from a higher control plane as opposed to DS-lite/NAT44. Thus once again, coming up with "binding" categorization appears to be a pointless exercise. And yes, one must be able to maintain configuration state... Thanks, Woj. > > > Thanks, > > Qi Sun > > > On 2012-11-30, at =E4=B8=8B=E5=8D=886:51, Wojciech Dec wrote: > > And much as was also said before, this categorization is bogus as all > solutions need configuration state, ie categorizing solutions based on > "amount of configuration" or some fluffy term like "binding approach" is > equivalent to categorizing them based on "how long is a piece of string" > and ultimately useless. What we do know is one-size of string does not wo= rk > for all, and the implementers need to scale their configuration state as > per their best judgement/capabilities. > > Cheers, > Woj. > > On 30 November 2012 09:48, Qiong wrote: > >> Right. That's why I prefer the solution space provided by Med before, >> which will be much clearer and easy to understand: >> * Full stateful approach >> * Binding approach >> * Full stateless approach >> >> Best wishes >> Qiong >> >> >> On Fri, Nov 30, 2012 at 12:13 PM, Leaf yeh wrote= : >> >>> Mark - I think the only question that should be on the table is whether >>> a 1:1 rule is called something different or not - kind of like how we r= efer >>> to a /32 or /128 as a hostroute. >> >> >> >> >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Qiong Sun >> China Telecom Beijing Research Institude >> >> >> Open source code: >> lightweight 4over6: *http://sourceforge.net/projects/laft6/* >> PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> _______________________________________________ >> 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 > > > --047d7b6220727591a804cfb8384a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 30 November 2012 13:37, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:
This solution space is the outcome of Vancouver meeting. And IMO, the = word 'binding' not only means there are state to maintain, but also= indicates that IPv4 and IPv6 addresses are just bound together, with no al= gorithmic relationship.

You just= described an algorithm.

I will assert that the *only* tangible diff= erence between is whether it is derived from the data plane or not. Both lw= 46 and MAP do not derive their state from the data plane, but from a higher= control plane as opposed to DS-lite/NAT44. Thus once again, coming up with= "binding" categorization appears to be a pointless exercise.
And yes, one must be able to maintain configuration state...

Thanks,=
Woj.


Thanks,

Qi Sun

On 2012-11-30, at =E4=B8=8B=E5=8D=886:51, Wojciech Dec wrote:=

And much as was also said before, this = categorization is bogus as all solutions need configuration state, ie categ= orizing solutions based on "amount of configuration" or some fluf= fy term like "binding approach" is equivalent to categorizing the= m based on "how long is a piece of string" and ultimately useless= . What we do know is one-size of string does not work for all, and the impl= ementers need to scale their configuration state as per their best judgemen= t/capabilities.

Cheers,
Woj.

On 30 November 2012 0= 9:48, Qiong <bingxuere@gmail.com> wrote:
Right. That's why I prefer the solution spac= e provided by Med before, which will be much clearer and easy to understand= :
* Full stateful approach
* Binding approach
* Full stateless app= roach

Best wishes
Qiong

On Fri, Nov 30, 2012 at 12:13 PM, Leaf yeh= <leaf.y.yeh@huawei.com> wrote:
Mark - I think the only question that should= be on the table is whether a 1:1 rule is called something different or not= - kind of like how we refer to a /32 or /128 as a hostroute.



--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beiji= ng Research Institude


Open source code:
lightweight 4over6: <= i>http= ://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires


--047d7b6220727591a804cfb8384a-- From otroan@employees.org Fri Nov 30 10:34:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBF721F8AC8 for ; Fri, 30 Nov 2012 10:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj-Bk0DjYL-j for ; Fri, 30 Nov 2012 10:34:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5DC21F8590 for ; Fri, 30 Nov 2012 10:34:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIH7uFCQ/khM/2dsb2JhbABEv38Wc4IeAQEEATo/BQsLRlcGLodvBsAQkCBhA5trilmCcw X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="147599663" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2012 18:34:04 +0000 Received: from [10.61.105.205] (dhcp-10-61-105-205.cisco.com [10.61.105.205]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAUIY3v8028622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Nov 2012 18:34:03 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 30 Nov 2012 19:34:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E9AFA2C-596E-4FC2-A96E-E9712E79E8A5@employees.org> References: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> To: Qiong X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 18:34:06 -0000 All, > Right. That's why I prefer the solution space provided by Med before, = which will be much clearer and easy to understand: > * Full stateful approach > * Binding approach > * Full stateless approach but why would a CPE have to know what amount of state a tunnel = concentrator keeps? cheers, Ole= From otroan@employees.org Fri Nov 30 11:36:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065A821F89A7 for ; Fri, 30 Nov 2012 11:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42d4rL+4pbHW for ; Fri, 30 Nov 2012 11:36:34 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF3B21F88E9 for ; Fri, 30 Nov 2012 11:36:33 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGEKuVCQ/khL/2dsb2JhbABEv38Wc4IeAQEEAXkFCwtGV4gjBsAGjVqCRmEDm2uKWYJz X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="78710404" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 Nov 2012 19:36:23 +0000 Received: from [10.61.105.205] (dhcp-10-61-105-205.cisco.com [10.61.105.205]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qAUJaNsT017809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Nov 2012 19:36:23 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 30 Nov 2012 20:36:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 19:36:35 -0000 Med, et al, > Med: The rationale we adopted in this draft is as follows: >=20 > * there are three major flavors: full stateful, full stateless, and = binding mode > * all these modes can support assigning a full or a shared IPv4 = address now you got me thinking, are these really the right modes from a CPE = perspective? let me try to explain, with my CPE implementor hat on, what "modes" = would make sense? - NAT placement. do I need a NAT on the CPE or not? (no NAT && no IPv4 address =3D=3D DS-lite) - full IPv4 address assigned. I can assign the IPv4 address to the tunnel endpoint interface, and = use that address for local applications, and as the outbound address of the NAT (mechanisms: MAP, Public 4over6) - IPv4 prefix assigned: I need to disable the CPE NAT, and use the assigned IPv4 prefix as my = LAN side DHCPv4 pool (mechanism: MAP) - Shared IPv4 address. I must enable a local NAT, I cannot assign the IPv4 address on the = "WAN" interface, but only use it for the outbound side of the NAT. then there might be a sub-modes for "tunnel endpoint determination" i.e. = how to determine an IPv6 tunnel end point address given an IPv4 = destination address and port. 1) algorithmic (MAP) 2) configured (Public 4over6, LW46, DS-lite) and a sub-mode for IPv4 address configuration: 1) As "native IPv4" (Public4over6, LW46) 2) Embedded Address (MAP) 3) None DS-lite does this make sense? cheers, Ole From bingxuere@gmail.com Fri Nov 30 18:39:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B910B21F86A8 for ; Fri, 30 Nov 2012 18:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8rJcRIccnOs for ; Fri, 30 Nov 2012 18:39:35 -0800 (PST) Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) by ietfa.amsl.com (Postfix) with ESMTP id AC96221F8566 for ; Fri, 30 Nov 2012 18:39:34 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id k25so1060954iah.23 for ; Fri, 30 Nov 2012 18:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OfEurAaDpmOwVrSFeEeWYsuleRtTwxNHMRzkScsnnlo=; b=cD1V6TOd8TX/+QNXtsqrHREAG54KI0vRr0C9xs/qjSI/iivv67oeBUpcnoH5ySQZ5/ Vxae9GLaTJT7EKQCKoC8disG+iZUv0qCDR2Nv8gwiYqwq2LX3FmS7+C+ac5CaTNNYnou 29vcBM0UjEjXd0xzxjrL16vCtW6oRqOQM7qho7BelPhRs7JqSBftIvcuq8GrSe0P/NeT iI2yQad172iswwodyIzbkhYyvscK8KWj2t673GfmCV2nIPDpeCxjwpoQINcPuAv3fl73 P84KwgHKOOmTPgaqOTuuz2ZaPhaicVhF+SUdWQJ6RSpOChTBnprLhZUFawDfOTdDDln7 T8wA== Received: by 10.50.180.133 with SMTP id do5mr302779igc.2.1354329574190; Fri, 30 Nov 2012 18:39:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Fri, 30 Nov 2012 18:38:53 -0800 (PST) In-Reply-To: <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> From: Qiong Date: Sat, 1 Dec 2012 10:38:53 +0800 Message-ID: To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=14dae93407ad2dad0004cfc16d7e Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 02:39:36 -0000 --14dae93407ad2dad0004cfc16d7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole, I think there is one more point, see inline ~~ On Sat, Dec 1, 2012 at 3:36 AM, Ole Tr=C3=B8an wrote= : > Med, et al, > > > Med: The rationale we adopted in this draft is as follows: > > > > * there are three major flavors: full stateful, full stateless, and > binding mode > > * all these modes can support assigning a full or a shared IPv4 address > > now you got me thinking, are these really the right modes from a CPE > perspective? > > let me try to explain, with my CPE implementor hat on, what "modes" would > make sense? > > - NAT placement. do I need a NAT on the CPE or not? > (no NAT && no IPv4 address =3D=3D DS-lite) > - full IPv4 address assigned. > I can assign the IPv4 address to the tunnel endpoint interface, and use > that address for > local applications, and as the outbound address of the NAT > (mechanisms: MAP, Public 4over6) > - IPv4 prefix assigned: > I need to disable the CPE NAT, and use the assigned IPv4 prefix as my > LAN side DHCPv4 pool > (mechanism: MAP) > - Shared IPv4 address. > I must enable a local NAT, I cannot assign the IPv4 address on the "WAN= " > interface, but only use it > for the outbound side of the NAT. > > then there might be a sub-modes for "tunnel endpoint determination" i.e. > how to determine an IPv6 tunnel end point address given an IPv4 destinati= on > address and port. > 1) algorithmic (MAP) > 2) configured (Public 4over6, LW46, DS-lite) > > and a sub-mode for IPv4 address configuration: > 1) As "native IPv4" > (Public4over6, LW46) > 2) Embedded Address > (MAP) > 3) None > DS-lite > [Qiong] and a sub-mode for "source IPv6 address determiniation", how to determine the encapsulated IPv6 source address. 1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface Identifier (MAP) 2) WAN IPv6 address (DS-Lite, LW46, Public 4over6) Right ? Best wishes Qiong > > does this make sense? > > cheers, > Ole > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --14dae93407ad2dad0004cfc16d7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole,

I think there is one more point, = see inline ~~

On Sat, Dec 1, 2012 at 3:36= AM, Ole Tr=C3=B8an <otroan@employees.org> wrote:
Med, et al,

> Med: The rationale we adopted in this draft is as follows:
>
> * there are three major flavors: full stateful, full stateless, and bi= nding mode
> * all these modes can support assigning a full or a shared IPv4 addres= s

now you got me thinking, are these really the right modes from a CPE = perspective?

let me try to explain, with my CPE implementor hat on, what "modes&quo= t; would make sense?

- NAT placement. do I need a NAT on the CPE or not?
=C2=A0 (no NAT && no IPv4 address =3D=3D DS-lite)
- full IPv4 address assigned.
=C2=A0 I can assign the IPv4 address to the tunnel endpoint interface, and = use that address for
=C2=A0 local applications, and as the outbound address of the NAT
=C2=A0 (mechanisms: MAP, Public 4over6)
- IPv4 prefix assigned:
=C2=A0 I need to disable the CPE NAT, and use the assigned IPv4 prefix as m= y LAN side DHCPv4 pool
=C2=A0 (mechanism: MAP)
- Shared IPv4 address.
=C2=A0 I must enable a local NAT, I cannot assign the IPv4 address on the &= quot;WAN" interface, but only use it
=C2=A0 for the outbound side of the NAT.

then there might be a sub-modes for "tunnel endpoint determination&quo= t; i.e. how to determine an IPv6 tunnel end point address given an IPv4 des= tination address and port.
1) algorithmic (MAP)
2) configured (Public 4over6, LW46, DS-lite)

and a sub-mode for IPv4 address configuration:
1) As "native IPv4"
=C2=A0 =C2=A0 (Public4over6, LW46)
2) Embedded Address
=C2=A0 =C2=A0 (MAP)
3) None
=C2=A0 =C2=A0DS-lite
=C2=A0
[Qiong] and a su= b-mode for "source IPv6 address determiniation", how to determine= the encapsulated IPv6 source address.
1) algorithmic, LAN prefix + embe= dded IPv4 address/PSID in Interface Identifier (MAP)
2) WAN IPv6 address (DS-Lite, LW46, Public 4over6)
=C2=A0
Right ?
=
Best wishes
Qiong

does this make sense?

cheers,
Ole


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



--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--14dae93407ad2dad0004cfc16d7e-- From simon.perreault@viagenie.ca Fri Nov 30 23:46:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A40421F8527 for ; Fri, 30 Nov 2012 23:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbAuodLROj1W for ; Fri, 30 Nov 2012 23:46:19 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E155521F8502 for ; Fri, 30 Nov 2012 23:46:18 -0800 (PST) Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0798240384; Sat, 1 Dec 2012 02:46:16 -0500 (EST) Message-ID: <50B9B5C7.107@viagenie.ca> Date: Sat, 01 Dec 2012 08:46:15 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> In-Reply-To: <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 07:46:20 -0000 Le 2012-11-30 20:36, Ole Trøan a écrit : >> Med: The rationale we adopted in this draft is as follows: >> >> * there are three major flavors: full stateful, full stateless, and binding mode >> * all these modes can support assigning a full or a shared IPv4 address > > now you got me thinking, are these really the right modes from a CPE perspective? > > let me try to explain, with my CPE implementor hat on, what "modes" would make sense? > > - NAT placement. do I need a NAT on the CPE or not? > (no NAT && no IPv4 address == DS-lite) > - full IPv4 address assigned. > I can assign the IPv4 address to the tunnel endpoint interface, and use that address for > local applications, and as the outbound address of the NAT > (mechanisms: MAP, Public 4over6) > - IPv4 prefix assigned: > I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool > (mechanism: MAP) > - Shared IPv4 address. > I must enable a local NAT, I cannot assign the IPv4 address on the "WAN" interface, but only use it > for the outbound side of the NAT. Interesting... But note that even just implementing MAP alone would generate three of these "implementation modes". I would still like to see this list added to an "implementation considerations" section. Stuff like "you can't assign a partial address to a tunnel interface" may not be obvious to implementers. > then there might be a sub-modes for "tunnel endpoint determination" i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port. > 1) algorithmic (MAP) > 2) configured (Public 4over6, LW46, DS-lite) > > and a sub-mode for IPv4 address configuration: > 1) As "native IPv4" > (Public4over6, LW46) > 2) Embedded Address > (MAP) > 3) None > DS-lite > > does this make sense? Totally appropriate for an "implementation considerations" section IMHO. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca