From despres.remi@laposte.net Fri Jun 1 00:25: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 4600821F858F for ; Fri, 1 Jun 2012 00:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7lCOAOXX3Nu for ; Fri, 1 Jun 2012 00:25:52 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 613A421F8585 for ; Fri, 1 Jun 2012 00:25:51 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 872FC7000128; Fri, 1 Jun 2012 09:25:50 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 3AA77700012A; Fri, 1 Jun 2012 09:25:49 +0200 (CEST) X-SFR-UUID: 20120601072550240.3AA77700012A@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 1 Jun 2012 09:25:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <822BAC8C-57F6-438E-ABBE-A8C93542406E@laposte.net> References: To: Yong Cui X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 01 Jun 2012 07:25:53 -0000 Support. RD Le 2012-05-27 =E0 16:28, Yong Cui a =E9crit : > Hi folks, >=20 > This is a wg last call on = draft-ietf-softwire-stateless-4v6-motivation-01. > = http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivati= o > n/ >=20 > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. >=20 > This wg last call will end on 2012 June 10 at 12pm EDT. >=20 >=20 > Yong & Alain >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Fri Jun 1 00:59:31 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 99F2B21F8550 for ; Fri, 1 Jun 2012 00:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir1nDo6tltVo for ; Fri, 1 Jun 2012 00:59:31 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0589621F854C for ; Fri, 1 Jun 2012 00:59:31 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id 608947000042; Fri, 1 Jun 2012 09:59:30 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id 92BD57000098; Fri, 1 Jun 2012 09:59:29 +0200 (CEST) X-SFR-UUID: 20120601075929601.92BD57000098@msfrf2306.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 1 Jun 2012 09:59:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <674099CF-AD1A-4C56-89A2-FBDC6406F3E0@laposte.net> References: To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 01 Jun 2012 07:59:31 -0000 2012-05-30 15:55, Ole Tr=F8an: > public 4over6 is exactly the same as MAP in hub and spoke mode with = one mapping rule per subscriber. Could you clarify how this relates to the MAP-rule definition saying = "Each MAP node in the domain has the same set of rules". (draft-mdt-softwire-mapping-address-and-port-03) RD > and if Reinaldo is correct, also the same as b4-translated-ds-lite. >=20 > we have 4 mechanisms doing almost the exact same thing (4rd, MAP, = 4over6, B4-translated). >=20 > I would suggest that we do not progress this document now, but pass it = through the same review process that 4rd/MAP is going through. unless we = can reach consensus on pruning prior to that. >=20 > cheers, > Ole >=20 >> This is a wg last call on draft-ietf-softwire-public-4over6-01. >> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >>=20 >> As usual, please send editorial comments to the authors and >> substantive comments to the mailing list. >>=20 >> This wg last call will end on 2012 June 10 at 12pm EDT. >>=20 >>=20 >> Yong & Alain >>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ichiroumakino@gmail.com Fri Jun 1 01:45:38 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 B37F021F8618 for ; Fri, 1 Jun 2012 01:45:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXQKai-3h2Y3 for ; Fri, 1 Jun 2012 01:45:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B521F8518 for ; Fri, 1 Jun 2012 01:45:33 -0700 (PDT) Received: by eaaq13 with SMTP id q13so474762eaa.31 for ; Fri, 01 Jun 2012 01:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dTrJir4H7NEPW42V5siEx4ZOn53GBQNlKjw91/QU4no=; b=fa0J2hhOkLXOqzgTJ8/HWlNXYbWUwewIeD3YZy3WYHdSbbqVQVDDfd9Wqdadxyv00h fbi6VSjtGCTxs/yNG04E4Kazrd9gTxOfcxAOGP+VztasZqmtQLUck9/TztaTHkFfZXDW 1qBoPrrxf6AcLarxc2yvu2h3NCPR+ejDEuCuQ79FHiZ8/ixH6wCbB+Dh+BwrEPwYhEkE g51cmm5UNPnBgc6blBaVhNw3398vCTNRDVkkdgTgUTgKsRhpr5hlLcdnKbj0XWHN3xhO iPodehGvGS8wllCCDojWEdI1j5vaQwypfoU985BrcGA7JUmitFVLsRMWCoNtvUkZ4ZSt jDRw== Received: by 10.14.119.66 with SMTP id m42mr951885eeh.4.1338540332272; Fri, 01 Jun 2012 01:45:32 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n52sm4391928eeh.9.2012.06.01.01.45.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 01:45:31 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <674099CF-AD1A-4C56-89A2-FBDC6406F3E0@laposte.net> Date: Fri, 1 Jun 2012 10:45:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CFBB5FC-EB57-4E3D-81CB-0BF22B7CE342@employees.org> References: <674099CF-AD1A-4C56-89A2-FBDC6406F3E0@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 01 Jun 2012 08:45:38 -0000 >> public 4over6 is exactly the same as MAP in hub and spoke mode with = one mapping rule per subscriber. >=20 > Could you clarify how this relates to the MAP-rule definition saying = "Each MAP node in the domain has the same set of rules". > (draft-mdt-softwire-mapping-address-and-port-03) you can look at it as if each subscriber has his own MAP domain. cheers, Ole From eleven.fuyu@huawei.com Sun Jun 3 18:55: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 6D0E421F87BE for ; Sun, 3 Jun 2012 18:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWkgOd6DsHmf for ; Sun, 3 Jun 2012 18:55:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0B221F8790 for ; Sun, 3 Jun 2012 18:55:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGV07973; Sun, 03 Jun 2012 21:55:02 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 3 Jun 2012 18:52:52 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 3 Jun 2012 18:52:51 -0700 Received: from SZXEML512-MBX.china.huawei.com ([169.254.5.169]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Mon, 4 Jun 2012 09:52:47 +0800 From: "Fuyu (Eleven)" To: Yong Cui Thread-Topic: WG last call on draft-ietf-softwire-public-4over6-01 Thread-Index: AQHNPBVU8Jc3FPt2qEqeDzV3jcKMEZbjH4XA Date: Mon, 4 Jun 2012 01:52:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.119] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 04 Jun 2012 01:55:09 -0000 Support for moving to the next step. Cheers Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Yong Cui Sent: Sunday, May 27, 2012 10:31 PM To: softwires@ietf.org Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Hi folks, This is a wg last call on draft-ietf-softwire-public-4over6-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 June 10 at 12pm EDT. Yong & Alain _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Sun Jun 3 19:35: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 1A91621F8810 for ; Sun, 3 Jun 2012 19:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PJ99go8FNvg for ; Sun, 3 Jun 2012 19:35:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB0E121F8724 for ; Sun, 3 Jun 2012 19:35:47 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2275248qcs.31 for ; Sun, 03 Jun 2012 19:35:46 -0700 (PDT) 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 :content-type; bh=Jd4XTadrBlUtVRBAu4ZhvCMwRCu2HUn+Hrpo3P8PCYE=; b=RLEo8OwEdji2tTBxwqBWPuSDXypi+PubIj1Slkbk1uyAuOufWgQgXhRXfaPNczbJPG hBv2mhTVulE6p2+YWou7EnedELPaHlsVL6AXXDakVcOHKnKasFyxaNMyni/V6mJUv74T pB3+0BWy84puhzkUleGtTf9HgCIEV+c89gH1tBXn5m/x8osyoEMe5X8502qPJ8DdiwJR jNkjuL6peFSs0d6MFGT4rbP4Y3xrA1k0I+J9REWUFQjAeOM9vtBIjTQ/HPonLfc/cFjO IWU6abJ7xzD6sii1h9LsNrP2h7mSxqjkEmeQNYDgMIpq5CvvjcRwRrpylGw2UUJ9wsQq AmEQ== MIME-Version: 1.0 Received: by 10.224.188.140 with SMTP id da12mr11845923qab.42.1338777345800; Sun, 03 Jun 2012 19:35:45 -0700 (PDT) Received: by 10.229.250.79 with HTTP; Sun, 3 Jun 2012 19:35:45 -0700 (PDT) In-Reply-To: <4FBCD6FF.2030900@viagenie.ca> References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> <4FBBCCA9.2050603@viagenie.ca> <4FBCD6FF.2030900@viagenie.ca> Date: Mon, 4 Jun 2012 02:35:45 +0000 Message-ID: From: Maoke To: Simon Perreault , Softwires-wg Content-Type: multipart/alternative; boundary=20cf303640bb21396104c19c6440 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.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: Mon, 04 Jun 2012 02:35:49 -0000 --20cf303640bb21396104c19c6440 Content-Type: text/plain; charset=ISO-8859-1 sorry for the late reply. 2012/5/23 Simon Perreault > (Did you intend to send this to the WG?) thanks for reminding :) i did reply but not reply-all. > > > On 2012-05-22 21:38, Maoke wrote: > >> My understanding: 4rd is a compromise. >> >> What you gain: only one protocol to consider. >> What you lose: some edge cases are not supported. >> >> >> that sort of statement is surely fair. but, unfortunately, 4rd document >> seldom admits it loses something (this is why i found writing a >> commentary was necessary). and the question is: are these *edge* cases >> are really edge? >> > > That is exactly the right question to ask. > > > a quick but incomplete list of these *edge* cases are: >> >> 1. routing protocols with TTL-security setting with number other than 1 >> or 255; >> > > Do such protocols exist? ebgp multihop with any possible value of ttl restriction; other applications also possible use ttl restriction (e.g., iptable -t mangle -m ttl). > > > 2. ipv6 domain has firewalls that need to filter unknown/unexpected >> protocols but not yet recognize ICMPv4 as IPv6 payload (at least Linux >> ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei can?); >> > > Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) a > valid use case? well, good question! but don't state 4rd can support intermediate tools of operation can work as in translation, seeing the L4 payload. - such a statement was one of the main motivation of 4rd-u. if it cannot support intermediate operation tools working with wanted filtering regarding any payload type, this superiority over MAP-E, AFAIK, is fake. > > > 3. ipv6 routers sometimes generates bit errors in hardware or software >> before dropping packets to NIC. >> > > I fail to understand the problem here, sorry. sorry but please read the history of 1. why Sun Microsystem enables NFS's UDP checksum after a long period of using null checksum? 2. why higher layer checksum is still needed and how it is significant even when link layer has contained CRC? otherwise it would be hard to make the dialogue. sorry. > > if any of the above *edge* cases actually happens, in such happening >> *edge* cases, we still need either encapsulation or translation. >> > > Since we're talking about compromise, I believe the edge case not only has > to happen, it also has to be *important*. Meaning that we might want to > avoid supporting some unimportant edge cases if that means simplifying the > protocol. good point. philosophy is the same. however, which is the simple protocol? - MAP suite: A. existing encapsulation, existing translation (not anything new but appying B); B. new address mapping rule; C. compromising DF=MF=1 edge cases (less than 10^-6 regarding importance). - 4rd: A. new trans-capsulation (let me call it like that); B. new address mapping rule; C. compromising (at least) C1. ttl preverving for any TTL but 1 or 225 (which MAP supports with the -E variant) C2. intermediate ipv6 filtering on any protocol (which MAP supports with the -T variant) i think the answer is obvious but i cannot help if you insist the latter is simpler. ;-) > > > So any argument to the effect that "MAP-E|T does X and 4rd doesn't" >> is empty. This is expected, it's a compromise. >> >> some arguments are about "MAP-E|T doesn't make a confusing Y but 4rd >> does". sorry this is not expected. >> > > I believe it's also a compromise. You lose some simplicity, you gain a > single protocol. your above: "simplifying the protocol"; here: "you lose some simplicity". ??? have you admitted that the 4rd is less simple?? > > > The argument should be: "I need 4rd to do X because ..." >> >> well, what is the X then? if the X is only "the number of protocol = >> 1"... we may have a lot of ways to achieve it without the need of >> excluding any so-called *edge* cases, without the need of introducing >> any ugly behavior with the excuse of "compromise". >> >> encapsulation and translation have been the cases of loss-and-gain >> compromises. do we need the third? >> > > For example: I need 4rd to support TTL preservation for value 64 because > I'm using routing protocol XYZ which needs it. > well, ttl 254, 253, 252, 251, 250, etc... are often used for eBGP multihop. ttl 64 are sometimes used in our application facility for internal web service. > > That's would be a real, justified use case. Otherwise it's just theory. you may directly say encapsulation doing a lot things only significant in theory. but the reality is not so. i also suggest we, moderately, not to argue something is only a theory just because we haven't known it is really happening somewhere unknown to us. thanks and regards, maoe > > > 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 > --20cf303640bb21396104c19c6440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sorry for the late reply.=A0

2012/5/23 Si= mon Perreault <simon.perreault@viagenie.ca>
(Did you intend to send this to the WG?)

th= anks for reminding :) i did reply but not reply-all.=A0
=A0
=


On 2012-05-22 21:38, Maoke wrote:
=A0 =A0My understanding: 4rd is a compromise.

=A0 =A0What you gain: only one protocol to consider.
=A0 =A0What you lose: some edge cases are not supported.


that sort of statement is surely fair. but, unfortunately, 4rd document
seldom admits it loses something (this is why i found writing a
commentary was necessary). and the question is: are these *edge* cases
are really edge?

That is exactly the right question to ask.


a quick but incomplete list of these *edge* cases are:

1. routing protocols with TTL-security setting with number other than 1
or 255;

Do such protocols exist?

ebgp multihop with= any possible value of ttl restriction; =A0
other applications al= so possible use ttl restriction (e.g., iptable -t mangle -m ttl). =A0
=A0


2. ipv6 domain has firewalls that need to filter unknown/unexpected
protocols but not yet recognize ICMPv4 as IPv6 payload (at least Linux
ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei can?);

Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) a val= id use case?

well, good question! but don&#= 39;t state 4rd can support intermediate tools of operation can work as in t= ranslation, seeing the L4 payload. - such a statement was one of the main m= otivation of 4rd-u. if it cannot support intermediate operation tools worki= ng with wanted filtering regarding any payload type, this superiority over = MAP-E, AFAIK, is fake.=A0
=A0


3. ipv6 routers sometimes generates bit errors in hardware or software
before dropping packets to NIC.

I fail to understand the problem here, sorry.

sorry but please read the history of=A0

1. why = Sun Microsystem enables NFS's UDP checksum after a long period of using= null checksum?
2. why higher layer checksum is still needed and how it is significant= even when link layer has contained CRC?=A0

otherw= ise it would be hard to make the dialogue. sorry.=A0
=A0

if any of the above *edge* cases actually happens, in such happening
*edge* cases, we still need either encapsulation or translation.

Since we're talking about compromise, I believe the edge case not only = has to happen, it also has to be *important*. Meaning that we might want to= avoid supporting some unimportant edge cases if that means simplifying the= protocol.

good point. philosophy is the same. however, which is t= he simple protocol?=A0

- MAP suite:
=A0= A. existing encapsulation, existing translation (not anything new but appy= ing B);
=A0 B. new address mapping rule;
=A0 C. compromising DF=3DM= F=3D1 edge cases (less than 10^-6 regarding importance).
- 4rd: <= /div>
=A0 A. new trans-capsulation (let me call it like that);
=A0 B. new address mapping rule;
=A0 C. compromising (at least)=A0
=A0 =A0 =A0C1. ttl preverv= ing for any TTL but 1 or 225 (which MAP supports with the -E variant)
=
=A0 =A0 =A0C2. intermediate ipv6 filtering on any protocol (which MAP = supports with the -T variant)=A0

i think the answer is obvious but i cannot help if you = insist the latter is simpler. ;-)
=A0


=A0 =A0So any argument to the effect that "MAP-E|T does X and 4rd doe= sn't"
=A0 =A0is empty. This is expected, it's a compromise.

some arguments are about "MAP-E|T doesn't make a confusing Y but 4= rd
does". sorry this is not expected.

I believe it's also a compromise. You lose some simplicity, you gain a = single protocol.

your above: "simplify= ing the protocol"; here: "you lose some simplicity". ??? hav= e you admitted that the 4rd is less simple??=A0
=A0


=A0 =A0The argument should be: "I need 4rd to do X because ..."<= br>
well, what is the X then? if the X is only "the number of protocol =3D=
1"... we may have a lot of ways to achieve it without the need of
excluding any so-called *edge* cases, without the need of introducing
any ugly behavior with the excuse of "compromise".

encapsulation and translation have been the cases of loss-and-gain
compromises. do we need the third?

For example: I need 4rd to support TTL preservation for value 64 because I&= #39;m using routing protocol XYZ which needs it.

<= /div>
well, ttl 254, 253, 252, 251, 250, etc... are often used for eBGP= multihop.=A0
ttl 64 are sometimes used in our application facility for internal web= service.
=A0

That's would be a real, justified use case. Otherwise it's just= theory.=A0

you may directly say encapsulat= ion doing a lot things only significant in theory. but the reality is not s= o. i also suggest we, moderately, not to argue something is only a theory j= ust because we haven't known it is really happening somewhere unknown t= o us.=A0

thanks and regards,
maoe
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--20cf303640bb21396104c19c6440-- From leo.liubing@huawei.com Mon Jun 4 00:55: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 E76E621F85FB for ; Mon, 4 Jun 2012 00:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIfNUEXWz81j for ; Mon, 4 Jun 2012 00:55:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 40B7821F854A for ; Mon, 4 Jun 2012 00:55:15 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGV31193; Mon, 04 Jun 2012 03:55:14 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 4 Jun 2012 00:52:37 -0700 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 4 Jun 2012 00:52:36 -0700 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Mon, 4 Jun 2012 15:52:31 +0800 From: "Liubing (Leo)" To: Softwires WG Thread-Topic: [Softwires] Call for adoption of DS-Lite Management Information Base (MIB) Thread-Index: AQHNPsyv77Q1b/4DV0uDeey5t+MfJpbpz5ig Date: Mon, 4 Jun 2012 07:52:30 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292CB450@szxeml509-mbx> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45292CB450szxeml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] Call for adoption of DS-Lite Management Information Base (MIB) 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, 04 Jun 2012 07:55:16 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45292CB450szxeml509mbx_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIHN1cHBvcnQuDQoNCkl0IGlzIG9uIHRoZSBXRyBjaGFydGVyIGFuZCBoYXMgYmVlbiBw cmVzZW50ZWQgZm9yIGEgY291cGxlIG9mIHRpbWVzLg0KDQpGcm9tOiBzb2Z0d2lyZXMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUWlvbmcNClNlbnQ6IFRodXJzZGF5LCBNYXkgMzEsIDIwMTIgOToyOCBBTQ0KVG86IFlvbmcg Q3VpDQpDYzogU29mdHdpcmVzIFdHDQpTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gQ2FsbCBmb3Ig YWRvcHRpb24gb2YgRFMtTGl0ZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UgKE1JQikNCg0K KzEgc3VwcG9ydC4gSSB0aGluayBpdCBpcyBtYXR1cmUgZW5vdWdoLg0KDQpCZXN0IHdpc2hlcw0K UWlvbmcNCk9uIFdlZCwgTWF5IDMwLCAyMDEyIGF0IDI6NTMgUE0sIFlvbmcgQ3VpIDxjdWl5b25n QHRzaW5naHVhLmVkdS5jbjxtYWlsdG86Y3VpeW9uZ0B0c2luZ2h1YS5lZHUuY24+PiB3cm90ZToN CkhpIGZvbGtzLA0KDQpBcyB3ZSBkaXNjdXNzZWQgb24gRFMtTGl0ZSBNYW5hZ2VtZW50IEluZm9y bWF0aW9uIEJhc2UgKE1JQikNCmluIFBhcmlzIG1lZXRpbmcsIHRoZSBjaGFpcnMgd291bGQgbGlr ZSB0byBhc2sgZm9yIFdHIGFkb3B0aW9uIG9uDQptYWlsaW5nIGxpc3QuIFBsZWFzZSByZXZpZXcg dGhpcyBkb2N1bWVudCBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzDQooZXNwZWNpYWxseSB5b3VyIG9w aW5pb24gb24gdGhlIGFkb3B0aW9uIHdpdGggeW91ciByZWFzb25zKSB0byB0aGUNCm1haWxpbmcg bGlzdCBieSB0d28gd2Vla3MsIGkuZS4gSnVuZSAxMy4NCg0KRllJOg0KaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1mdS1zb2Z0d2lyZS1kc2xpdGUtbWliLw0KDQoNCllvbmcg JiBBbGFpbg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnPG1haWx0 bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlcw0KDQo= --_000_8AE0F17B87264D4CAC7DE0AA6C406F45292CB450szxeml509mbx_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOzEg Zm9yIHN1cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IGlzIG9u IHRoZSBXRyBjaGFydGVyIGFuZCBoYXMgYmVlbiBwcmVzZW50ZWQgZm9yIGEgY291cGxlIG9mIHRp bWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5RaW9uZzxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWF5IDMxLCAyMDEyIDk6MjggQU08 YnI+DQo8Yj5Ubzo8L2I+IFlvbmcgQ3VpPGJyPg0KPGI+Q2M6PC9iPiBTb2Z0d2lyZXMgV0c8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTb2Z0d2lyZXNdIENhbGwgZm9yIGFkb3B0aW9uIG9mIERT LUxpdGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIChNSUIpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mIzQzOzEgc3Vw cG9ydC4gSSB0aGluayBpdCBpcyBtYXR1cmUgZW5vdWdoLjxicj4NCjxicj4NCkJlc3Qgd2lzaGVz PGJyPg0KUWlvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFdlZCwgTWF5IDMwLCAyMDEyIGF0IDI6NTMgUE0s IFlvbmcgQ3VpICZsdDs8YSBocmVmPSJtYWlsdG86Y3VpeW9uZ0B0c2luZ2h1YS5lZHUuY24iIHRh cmdldD0iX2JsYW5rIj5jdWl5b25nQHRzaW5naHVhLmVkdS5jbjwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5IaSBmb2xrcyw8YnI+DQo8YnI+DQpBcyB3ZSBkaXNjdXNzZWQgb24gRFMtTGl0ZSBNYW5hZ2Vt ZW50IEluZm9ybWF0aW9uIEJhc2UgKE1JQik8YnI+DQppbiBQYXJpcyBtZWV0aW5nLCB0aGUgY2hh aXJzIHdvdWxkIGxpa2UgdG8gYXNrIGZvciBXRyBhZG9wdGlvbiBvbjxicj4NCm1haWxpbmcgbGlz dC4gUGxlYXNlIHJldmlldyB0aGlzIGRvY3VtZW50IGFuZCBzZW5kIHlvdXIgY29tbWVudHM8YnI+ DQooZXNwZWNpYWxseSB5b3VyIG9waW5pb24gb24gdGhlIGFkb3B0aW9uIHdpdGggeW91ciByZWFz b25zKSB0byB0aGU8YnI+DQptYWlsaW5nIGxpc3QgYnkgdHdvIHdlZWtzLCBpLmUuIEp1bmUgMTMu PGJyPg0KPGJyPg0KRllJOjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZnUtc29mdHdpcmUtZHNsaXRlLW1pYi8iIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZ1LXNvZnR3aXJlLWRzbGl0ZS1taWIv PC9hPjxicj4NCjxicj4NCjxicj4NCllvbmcgJmFtcDsgQWxhaW48YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U29mdHdp cmVzQGlldGYub3JnIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F45292CB450szxeml509mbx_-- From despres.remi@laposte.net Mon Jun 4 03:27:43 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 D5EE121F8748 for ; Mon, 4 Jun 2012 03:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.159 X-Spam-Level: X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+9ukOMGQIDz for ; Mon, 4 Jun 2012 03:27:42 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id B43AF21F8771 for ; Mon, 4 Jun 2012 03:27:41 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id DD2847000045; Mon, 4 Jun 2012 12:27:39 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 2BE0170000B3; Mon, 4 Jun 2012 12:27:39 +0200 (CEST) X-SFR-UUID: 20120604102739179.2BE0170000B3@msfrf2417.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--278797089 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 4 Jun 2012 12:27:35 +0200 Message-Id: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> <4FBBCCA9.2050603@viagenie.ca> <4FBCD6FF.2030900@viagenie.ca> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.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: Mon, 04 Jun 2012 10:27:44 -0000 --Apple-Mail-5--278797089 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Maoke, Please see comments inline. 2012-06-04 04:35, Maoke: > sorry for the late reply.=20 >=20 > 2012/5/23 Simon Perreault > (Did you intend to send this to the WG?) >=20 > thanks for reminding :) i did reply but not reply-all.=20 > =20 >=20 >=20 > On 2012-05-22 21:38, Maoke wrote: > My understanding: 4rd is a compromise. >=20 > What you gain: only one protocol to consider. > What you lose: some edge cases are not supported. >=20 >=20 > that sort of statement is surely fair. but, unfortunately, 4rd = document > seldom admits it loses something (this is why i found writing a > commentary was necessary). and the question is: are these *edge* cases > are really edge? >=20 > That is exactly the right question to ask. >=20 >=20 > a quick but incomplete list of these *edge* cases are: >=20 > 1. routing protocols with TTL-security setting with number other than = 1 > or 255; >=20 > Do such protocols exist? >=20 > ebgp multihop with any possible value of ttl restriction; =20 > other applications also possible use ttl restriction (e.g., iptable -t = mangle -m ttl). =20 Right. But these protocols require communicating nodes to know how many routers = may be traversed between them. In this regard, 4rd doesn't introduce a new constraint (AFAIK). =20 > 2. ipv6 domain has firewalls that need to filter unknown/unexpected > protocols but not yet recognize ICMPv4 as IPv6 payload (at least Linux > ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei can?); >=20 > Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) = a valid use case? >=20 > well, good question! but don't state 4rd can support intermediate = tools of operation can work as in translation, seeing the L4 payload. - = such a statement was one of the main motivation of 4rd-u. There is no intent to claim that "intermediate tools of operation can = work as in translation". I found one place, in the Introduction, that you may find too general: "IPv4 headers can be reversibly translated into IPv6 headers in such a = way that, during IPv6 domain traversal, tunneled TCP and UDP packets are = valid IPv6 packets. Thus, IPv6-only middle boxes that perform = deep-packet-inspection can operate on them." It could become: "IPv4 headers can be reversibly translated into IPv6 headers in such a = way that, during IPv6 domain traversal, UDP packets having checksums and = TCP packets are valid IPv6 packets. Thus, IPv6-only middle boxes that = perform deep-packet-inspection, in particular on port numbers, can = operate on them."=20 Thought? > if it cannot support intermediate operation tools working with wanted = filtering regarding any payload type, this superiority over MAP-E, = AFAIK, is fake.=20 (*) There is AFAIK no claim in the draft that, regarding "wanted = filtering regarding any payload type", 4rd would be superior to MAP-E. Besides, a clarification of the problem you see concerning this "wanted = filtering regarding any payload type" would be appreciated.=20 (It is clear that deploying 4rd across an IPv6 domain may imply = adjustments of DPI filters if some have been configured.) > 3. ipv6 routers sometimes generates bit errors in hardware or software > before dropping packets to NIC. >=20 > I fail to understand the problem here, sorry. >=20 > sorry but please read the history of=20 >=20 > 1. why Sun Microsystem enables NFS's UDP checksum after a long period = of using null checksum? > 2. why higher layer checksum is still needed and how it is significant = even when link layer has contained CRC?=20 >=20 > otherwise it would be hard to make the dialogue. sorry.=20 a) UDP checksums, if used, aren't disabled by 4rd. IP payloads and = addresses remain protected e2e. b) If UDP checksum aren't used (as permitted only in IPv4), the fact = that addresses are not protected in tunnel headers as they are in IPv4 = headers is compensated in 4rd by the intrinsic redundancy of each = tunnel-endpoint address (see (**) at the end of section 4.2).=20 This address protection is also effective for ICMPv4 messages which = (unlike ICMPv6 messages) don't protect addresses by their checksums. Concerning hardware-originated errors, could you then indicate an error = example that would be insufficiently detected in 4rd while sufficiently = detected in MAP-T and MAP-E? > if any of the above *edge* cases actually happens, in such happening > *edge* cases, we still need either encapsulation or translation. >=20 > Since we're talking about compromise, I believe the edge case not only = has to happen, it also has to be *important*. Meaning that we might want = to avoid supporting some unimportant edge cases if that means = simplifying the protocol. >=20 > good point. philosophy is the same. however, which is the simple = protocol?=20 At least some contributors see 4rd as simpler than MAP-T plus MAP-E, but = you seem to think differently so let's take it at subjective at this = point. The main point however is that 4rd permits to have a single standardized = solution, an important simplification of the global situation for = vendors, operators, customers.=20 > - MAP suite: > A. existing encapsulation, existing translation (not anything new = but appying B); > B. new address mapping rule; > C. compromising DF=3DMF=3D1 edge cases (less than 10^-6 regarding = importance). Note that standard-track RFC4821 says: "All fragmentation SHOULD be done on the host, and all IPv4 packets, = including fragments, SHOULD have the DF bit set such that they will not = be fragmented (again) in the network." This can be expected to produce many legitimate DF=3DMF=3D1. There are AFAIK some other compromises in MAP-T+E, but to be discussed = when we have a stabilized specification. > - 4rd: > A. new trans-capsulation (let me call it like that); Reversible translation, as proposed in the draft, is IMHO a better way = to call it that "trans-capsulation". Could you use it, or is there a problem? > B. new address mapping rule; > C. compromising (at least)=20 > C1. ttl preverving for any TTL but 1 or 225 (which MAP supports = with the -E variant) ... and loses with the -T variant. > C2. intermediate ipv6 filtering on any protocol (which MAP = supports with the -T variant)=20 ... and loses with the -E variant. (This is assuming there is something significant in this point, bet see = (*) above) >=20 > i think the answer is obvious but i cannot help if you insist the = latter is simpler. ;-) > =20 >=20 >=20 > So any argument to the effect that "MAP-E|T does X and 4rd doesn't" > is empty. This is expected, it's a compromise. >=20 > some arguments are about "MAP-E|T doesn't make a confusing Y but 4rd > does". sorry this is not expected. >=20 > I believe it's also a compromise. You lose some simplicity, you gain a = single protocol. >=20 > your above: "simplifying the protocol"; here: "you lose some = simplicity". ??? have you admitted that the 4rd is less simple?? 4rd may be viewed IMHO as less simple than MAP-E alone, but it = shouldn't be ignored that it does largely more. To take just one = feature, independently of those of MAP-T, 4rd BRs forward IPv4 packets = on the fly, while the MAP-E specification says "If the packet is = fragmented, BR should reassemble the packet". This is significant for = scalability and for propagation delays. > The argument should be: "I need 4rd to do X because ..." >=20 > well, what is the X then? if the X is only "the number of protocol =3D > 1"... we may have a lot of ways to achieve it without the need of > excluding any so-called *edge* cases, without the need of introducing > any ugly behavior with the excuse of "compromise". >=20 > encapsulation and translation have been the cases of loss-and-gain > compromises. do we need the third? >=20 > For example: I need 4rd to support TTL preservation for value 64 = because I'm using routing protocol XYZ which needs it. >=20 > well, ttl 254, 253, 252, 251, 250, etc... are often used for eBGP = multihop.=20 > ttl 64 are sometimes used in our application facility for internal web = service. Fine. But which example would you have where these values would be a problem = with 4rd (knowing that any network decreases such values by the number = of traversed routers). Regards, RD > =20 >=20 > That's would be a real, justified use case. Otherwise it's just = theory.=20 >=20 > you may directly say encapsulation doing a lot things only significant = in theory. but the reality is not so. i also suggest we, moderately, not = to argue something is only a theory just because we haven't known it is = really happening somewhere unknown to us.=20 >=20 > thanks and regards, > maoe > =20 >=20 >=20 > 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 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-5--278797089 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
sorry for = the late reply. 

2012/5/23 Simon = Perreault <simon.perreault@viagenie.ca>
(Did you intend to send this to the = WG?)

thanks for reminding :) i did reply = but not reply-all. 
 


On 2012-05-22 21:38, Maoke wrote:
   My understanding: 4rd is a compromise.

   What you gain: only one protocol to consider.
   What you lose: some edge cases are not supported.


that sort of statement is surely fair. but, unfortunately, 4rd = document
seldom admits it loses something (this is why i found writing a
commentary was necessary). and the question is: are these *edge* = cases
are really edge?

That is exactly the right question to ask.


a quick but incomplete list of these *edge* cases are:

1. routing protocols with TTL-security setting with number other than = 1
or 255;

Do such protocols exist?

ebgp multihop = with any possible value of ttl restriction;  
other = applications also possible use ttl restriction (e.g., iptable -t mangle = -m ttl).  

Right.
But these protocols require communicating nodes to know how = many routers may be traversed between them.
In this regard, 4rd doesn't introduce = a new constraint (AFAIK).  


2. ipv6 domain has firewalls that need to filter unknown/unexpected
protocols but not yet recognize ICMPv4 as IPv6 payload (at least = Linux
ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei = can?);

Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) a = valid use case?

well, good question! but = don't state 4rd can support intermediate tools of operation can work as = in translation, seeing the L4 payload. - such a statement was one of the = main motivation of 4rd-u. =


There is no = intent to claim that "intermediate tools of operation can work as in = translation".

I found one place, in the = Introduction, that you may find too general:
"IPv4 headers can = be reversibly translated into IPv6 headers in such a way that, during = IPv6 domain traversal, tunneled TCP and UDP packets are valid IPv6 = packets. Thus, IPv6-only middle boxes that perform = deep-packet-inspection can operate on them."
It could = become:
"IPv4 headers can be reversibly translated into IPv6 = headers in such a way that, during IPv6 domain traversal, UDP = packets having checksums and TCP packets are valid IPv6 packets. = Thus, IPv6-only middle boxes that perform deep-packet-inspection, in = particular on port numbers, can operate on = them." 

Thought?


if it cannot = support intermediate operation tools working with wanted filtering = regarding any payload type, this superiority over MAP-E, AFAIK, is = fake. 

(*) There is AFAIK no = claim in the draft that, regarding "wanted filtering regarding any = payload type", 4rd would be superior to = MAP-E.

Besides, a clarification of the = problem you see concerning this "wanted filtering regarding any = payload type" would be appreciated. 
(It is clear = that deploying 4rd across an IPv6 domain may imply adjustments of DPI = filters if some have been = configured.)


3. ipv6 routers sometimes generates bit errors in hardware or = software
before dropping packets to NIC.

I fail to understand the problem here, = sorry.

sorry but please read the history = of 

1. why Sun Microsystem enables NFS's = UDP checksum after a long period of using null checksum?
2. why higher layer checksum is still needed and how it is = significant even when link layer has contained = CRC? 

otherwise it would be hard to make = the dialogue. = sorry. 

a) UDP = checksums, if used, aren't disabled by 4rd. IP payloads and addresses = remain protected e2e.

b) If UDP checksum aren't = used (as permitted only in IPv4), the fact that addresses are not = protected in tunnel headers as they are in IPv4 headers is compensated =  in  4rd by the intrinsic redundancy of each = tunnel-endpoint address (see (**) at the end of section = 4.2). 
This address protection is also effective for = ICMPv4 messages which (unlike ICMPv6 messages) don't protect addresses = by their checksums.


Concerning = hardware-originated errors, could you then indicate an error example = that would be insufficiently detected in 4rd while sufficiently detected = in MAP-T and MAP-E?


if any of the above *edge* cases actually happens, in such happening
*edge* cases, we still need either encapsulation or translation.

Since we're talking about compromise, I believe the edge case not only = has to happen, it also has to be *important*. Meaning that we might want = to avoid supporting some unimportant edge cases if that means = simplifying the protocol.

good point. philosophy is the same. however, which = is the simple = protocol? 

At least = some contributors see 4rd as simpler than MAP-T plus MAP-E, but you seem = to think differently so let's take it at subjective at this = point.
The main point however is that 4rd permits to have a = single standardized solution, an important simplification of the global = situation for vendors, operators, = customers. 


- MAP suite: =
  A. existing encapsulation, existing translation (not = anything new but appying B);
  B. new address mapping rule;
  C. = compromising DF=3DMF=3D1 edge cases (less than 10^-6 regarding = importance).

Note that = standard-track RFC4821 says:
 "All fragmentation SHOULD = be done on the host, and all IPv4 packets, including fragments, SHOULD = have the DF bit set such that they will not be fragmented (again) in the = network."
This can be expected to produce many legitimate = DF=3DMF=3D1.

There are AFAIK some other = compromises in MAP-T+E, but to be discussed when we have a stabilized = specification.


- = 4rd:
  A. new trans-capsulation (let me call = it like that);

Reversible = translation, as proposed in the draft, is IMHO a better way to call it = that "trans-capsulation".
Could you use it, or is there a = problem?


  B. new address mapping rule;
  C. compromising (at least) 
    =  C1. ttl preverving for any TTL but 1 or 225 (which MAP supports = with the -E variant)
... and loses with the -T = variant.

     C2. intermediate ipv6 = filtering on any protocol (which MAP supports with the -T = variant) 
... and loses with the -E = variant.
(This is assuming there is something significant in = this point, bet see (*) above)


i think the answer is obvious but i cannot help if = you insist the latter is simpler. ;-)
 


   So any argument to the effect that "MAP-E|T does X and 4rd = doesn't"
   is empty. This is expected, it's a compromise.

some arguments are about "MAP-E|T doesn't make a confusing Y but 4rd
does". sorry this is not expected.

I believe it's also a compromise. You lose some simplicity, you gain a = single protocol.

your above: = "simplifying the protocol"; here: "you lose some simplicity". ??? have = you admitted that the 4rd is less = simple??

4rd may be viewed =  IMHO as less simple than MAP-E alone, but it shouldn't be ignored = that it does largely more. To take just  one feature, independently = of those of MAP-T, 4rd BRs forward IPv4 packets on the fly, while the = MAP-E specification says "If the packet is fragmented, BR should = reassemble the packet". This is significant for scalability and for = propagation delays.


   The argument should be: "I need 4rd to do X because = ..."

well, what is the X then? if the X is only "the number of protocol =3D
= 1"... we may have a lot of ways to achieve it without the need of
excluding any so-called *edge* cases, without the need of = introducing
any ugly behavior with the excuse of "compromise".

encapsulation and translation have been the cases of loss-and-gain
compromises. do we need the third?

For example: I need 4rd to support TTL preservation for value 64 because = I'm using routing protocol XYZ which needs = it.

well, ttl 254, 253, 252, 251, = 250, etc... are often used for eBGP multihop. 
ttl 64 are sometimes used in our application facility for internal = web service.

Fine.
But = which example would you have where these values would be a problem with = 4rd (knowing that any network decreases such values by the number of = traversed = routers).


Regards,
RD




 

That's would be a real, justified use case. Otherwise it's just = theory. 

you may directly say = encapsulation doing a lot things only significant in theory. but the = reality is not so. i also suggest we, moderately, not to argue something = is only a theory just because we haven't known it is really happening = somewhere unknown to us. 

thanks and = regards,
maoe
 


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

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

= = --Apple-Mail-5--278797089-- From fibrib@gmail.com Mon Jun 4 07:22: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 271C321F886C for ; Mon, 4 Jun 2012 07:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.612 X-Spam-Level: X-Spam-Status: No, score=-3.612 tagged_above=-999 required=5 tests=[AWL=-0.914, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOc422k69aKh for ; Mon, 4 Jun 2012 07:22:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7D4A21F8864 for ; Mon, 4 Jun 2012 07:22:05 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2561559qcs.31 for ; Mon, 04 Jun 2012 07:22:05 -0700 (PDT) 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=YRrnQ1505WO9JX+R3GA3yzzYgrRmBG/NH4Oa5Fcd7QU=; b=OlebShUG/G74pf3moE+nLIqUf4Qx8UiqqCczVumckvSJ2uj9SgOZh8CeCXaR6jYk7Q kJ8Zj7MxC9fp+noW9xKjOZalOLca8o8rVI4lic9egDgeg+jQZdFvViYeX3RKuMEwBgB/ cVpuP9rFWDxmij4X6fSEUkfjVcezeDPvl/m9oy+LSNP8xoXsQxyKnOVKm1oFTVE8SUWM uowCph30pKf6lzxNsPvu1jgA1wkYEiSdMzdkUKcc+2x6DyXUR9lnhRr1FAMJUGcmMzxU jWehZSIYYvPzqSpVEqs5z84w90+IBTS4D2cMHPo/yBZ9XdKk/CZyGgOx4nV178H71pQ+ cwdw== MIME-Version: 1.0 Received: by 10.224.188.140 with SMTP id da12mr13571082qab.42.1338819725147; Mon, 04 Jun 2012 07:22:05 -0700 (PDT) Received: by 10.229.250.79 with HTTP; Mon, 4 Jun 2012 07:22:04 -0700 (PDT) In-Reply-To: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> <4FBBCCA9.2050603@viagenie.ca> <4FBCD6FF.2030900@viagenie.ca> Date: Mon, 4 Jun 2012 23:22:04 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf303640bb22bf4b04c1a642d7 Cc: Softwires-wg Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.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: Mon, 04 Jun 2012 14:22:08 -0000 --20cf303640bb22bf4b04c1a642d7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/6/4 R=E9mi Despr=E9s > Maoke, > Please see comments inline. > > 2012-06-04 04:35, Maoke: > > sorry for the late reply. > > 2012/5/23 Simon Perreault > >> (Did you intend to send this to the WG?) > > > thanks for reminding :) i did reply but not reply-all. > > >> >> >> On 2012-05-22 21:38, Maoke wrote: >> >>> My understanding: 4rd is a compromise. >>> >>> What you gain: only one protocol to consider. >>> What you lose: some edge cases are not supported. >>> >>> >>> that sort of statement is surely fair. but, unfortunately, 4rd document >>> seldom admits it loses something (this is why i found writing a >>> commentary was necessary). and the question is: are these *edge* cases >>> are really edge? >>> >> >> That is exactly the right question to ask. >> >> >> a quick but incomplete list of these *edge* cases are: >>> >>> 1. routing protocols with TTL-security setting with number other than 1 >>> or 255; >>> >> >> Do such protocols exist? > > > ebgp multihop with any possible value of ttl restriction; > other applications also possible use ttl restriction (e.g., iptable -t > mangle -m ttl). > > > Right. > But these protocols require communicating nodes to know how many routers > may be traversed between them. > no protocol can calculate the hops for setting the number. but human does. in the encapsulation mode, the IPv6 provider's domain is treated as 1 hop, which simplifies the counting. 4rd FORCES that operator MUST let the customer know the details if the customers would like to do the hop counting even though actually the customers don't care about such details. MAP-T is also doing so but if operators/customers wouldn't like to have this, MAP allows them to have the choice of MAP-E. okay. i think i finally almost am able to understand the philosophy of 4rd. just like the Lufthansa flight i once took. in the dinner, we had the choice between beef and chicken and then some bad passengers claimed that they rejected chicken because of the fear of bird diseases. in the breakfast later, however, we had only eggs. and nobody blamed. 4rd's idea is providing only the eggs to all people, forcing them to have to be happy but removing their trouble in choice. > > In this regard, 4rd doesn't introduce a new constraint (AFAIK). > > > 2. ipv6 domain has firewalls that need to filter unknown/unexpected >>> protocols but not yet recognize ICMPv4 as IPv6 payload (at least Linux >>> ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei can?); >>> >> >> Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) a >> valid use case? > > > well, good question! but don't state 4rd can support intermediate tools o= f > operation can work as in translation, seeing the L4 payload. - such a > statement was one of the main motivation of 4rd-u. > > > > There is no intent to claim that "intermediate tools of operation can wor= k > as in translation". > > fine. i got it. previously i understood the motivation of 4rd was making a high quality combination of both advantages. now i know it is the compromise for the single protocol. sorry but i was totally misunderstanding. > > > I found one place, in the Introduction, that you may find too general: > "IPv4 headers can be reversibly translated into IPv6 headers in such a wa= y > that, during IPv6 domain traversal, tunneled TCP and UDP packets are vali= d > IPv6 packets. Thus, IPv6-only middle boxes that perform > deep-packet-inspection can operate on them." > It could become: > "IPv4 headers can be reversibly translated into IPv6 headers in such a wa= y > that, during IPv6 domain traversal, UDP packets having checksums and TCP > packets are valid IPv6 packets. Thus, IPv6-only middle boxes that perform > deep-packet-inspection, in particular on port numbers, can operate on > them." > > no problem to me if it is explicitly specified what deep-inspection is ok what is compromised. > > > Thought? > > > if it cannot support intermediate operation tools working with wanted > filtering regarding any payload type, this superiority over MAP-E, AFAIK, > is fake. > > > (*) There is AFAIK no claim in the draft that, regarding "wanted filterin= g > regarding any payload type", 4rd would be superior to MAP-E. > > Besides, a clarification of the problem you see concerning this "wanted > filtering regarding any payload type" would be appreciated. > (It is clear that deploying 4rd across an IPv6 domain may imply > adjustments of DPI filters if some have been configured.) > > > 3. ipv6 routers sometimes generates bit errors in hardware or software >>> before dropping packets to NIC. >>> >> >> I fail to understand the problem here, sorry. > > > sorry but please read the history of > > 1. why Sun Microsystem enables NFS's UDP checksum after a long period of > using null checksum? > 2. why higher layer checksum is still needed and how it is significant > even when link layer has contained CRC? > > otherwise it would be hard to make the dialogue. sorry. > > > a) UDP checksums, if used, aren't disabled by 4rd. IP payloads and > addresses remain protected e2e. > > b) If UDP checksum aren't used (as permitted only in IPv4), the fact that > addresses are not protected in tunnel headers as they are in IPv4 headers > is compensated in 4rd by the intrinsic redundancy of each tunnel-endpoi= nt > address (see (**) at the end of section 4.2). > This address protection is also effective for ICMPv4 messages which > (unlike ICMPv6 messages) don't protect addresses by their checksums. > > limited checksum protection focusing on addresses. > > > > Concerning hardware-originated errors, could you then indicate an error > example that would be insufficiently detected in 4rd while sufficiently > detected in MAP-T and MAP-E? > > checksum is improving quite effectively, in the SIGCOMM'00 paper that i cited. i think you accept this conclusion as you so emphasize the importance of CNP. the point is, MAP-T doesn't lose any information of the pseudo-header-covered fields. the level of protection is as same as the native IPv6. MAP-E keeps whole IPv4 fields and the protection level is as same as the native IPv4 in the sense of end-to-end. i have stated, the bit error can happen in address and surely it could happen in any field including payload length or payload protocol (next-header). i don't think any further detailed example is needed. it has been clear enough. > > > > if any of the above *edge* cases actually happens, in such happening >>> *edge* cases, we still need either encapsulation or translation. >>> >> >> Since we're talking about compromise, I believe the edge case not only >> has to happen, it also has to be *important*. Meaning that we might want= to >> avoid supporting some unimportant edge cases if that means simplifying t= he >> protocol. > > > good point. philosophy is the same. however, which is the simple protocol= ? > > > At least some contributors see 4rd as simpler than MAP-T plus MAP-E, but > you seem to think differently so let's take it at subjective at this poin= t. > The main point however is that 4rd permits to have a single standardized > solution, an important simplification of the global situation for vendors= , > operators, customers. > > see the above. the main point is 4rd gets rid of possible choices of people and forces them to eat only one type of food. (i don't say it is definitely bad but just what i don't like.) it is still very subjective. > > > > - MAP suite: > A. existing encapsulation, existing translation (not anything new but > appying B); > B. new address mapping rule; > C. compromising DF=3DMF=3D1 edge cases (less than 10^-6 regarding > importance). > > > Note that standard-track RFC4821 says: > "All fragmentation SHOULD be done on the host, and all IPv4 packets, > including fragments, SHOULD have the DF bit set such that they will not b= e > fragmented (again) in the network." > This can be expected to produce many legitimate DF=3DMF=3D1. > > different understanding. host fragmentation means fragmenting the data from upper layers before generating the IP packets, rather than generating one and them putting it back to the stack for being fragmented. and therefore the result will be a lot of DF=3D1 but MF=3D0 packets. this is my understan= ding to the RFC4821, if wrong, please point out. (this is always welcome regardless of the relevance to this thread). > > > There are AFAIK some other compromises in MAP-T+E, but to be discussed > when we have a stabilized specification. > > > - 4rd: > > A. new trans-capsulation (let me call it like that); > > > Reversible translation, as proposed in the draft, is IMHO a better way to > call it that "trans-capsulation". > Could you use it, or is there a problem? > > IMHO, trans-capsulation is closer to the actual behavior of 4rd. reversible translation is a little confusing as a lot of its behavior is not translation at all. and double translation is partially reversible too, while 4rd, nevertheless, cannot be said "totally reversible" even it is a little more reversible than double translation. i don't this the trans-capsulation has anything bad meaning. scientists made Lion-Tiger very precious and very beautiful animal. i do suggest you use the term with more concrete meaning but i won't be over objective if you insist using "reversible translation". > B. new address mapping rule; > C. compromising (at least) > C1. ttl preverving for any TTL but 1 or 225 (which MAP supports with > the -E variant) > > ... and loses with the -T variant. > > C2. intermediate ipv6 filtering on any protocol (which MAP supports > with the -T variant) > > ... and loses with the -E variant. > (This is assuming there is something significant in this point, bet see > (*) above) > > > i think the answer is obvious but i cannot help if you insist the latter > is simpler. ;-) > > >> >> >> So any argument to the effect that "MAP-E|T does X and 4rd doesn't" >>> is empty. This is expected, it's a compromise. >>> >>> some arguments are about "MAP-E|T doesn't make a confusing Y but 4rd >>> does". sorry this is not expected. >>> >> >> I believe it's also a compromise. You lose some simplicity, you gain a >> single protocol. > > > your above: "simplifying the protocol"; here: "you lose some simplicity". > ??? have you admitted that the 4rd is less simple?? > > > 4rd may be viewed IMHO as less simple than MAP-E alone, but it shouldn't > be ignored that it does largely more. To take just one feature, > independently of those of MAP-T, 4rd BRs forward IPv4 packets on the fly, > while the MAP-E specification says "If the packet is fragmented, BR shoul= d > reassemble the packet". This is significant for scalability and for > propagation delays. > > another topic of discussion. i have little exploration on this and i have no right to argue. > > > > The argument should be: "I need 4rd to do X because ..." >>> >>> well, what is the X then? if the X is only "the number of protocol =3D >>> 1"... we may have a lot of ways to achieve it without the need of >>> excluding any so-called *edge* cases, without the need of introducing >>> any ugly behavior with the excuse of "compromise". >>> >>> encapsulation and translation have been the cases of loss-and-gain >>> compromises. do we need the third? >>> >> >> For example: I need 4rd to support TTL preservation for value 64 because >> I'm using routing protocol XYZ which needs it. >> > > well, ttl 254, 253, 252, 251, 250, etc... are often used for eBGP > multihop. > ttl 64 are sometimes used in our application facility for internal web > service. > > > Fine. > But which example would you have where these values would be a problem > with 4rd (knowing that any network decreases such values by the number of > traversed routers). > > surely, when i think my packets traverse your domain as tunneled, and my customer networks contains 2 hops, i may set 252 for the valid minimum ttl. however, 4rd makes the decrement and i will lose this packet. which is unexpected. the value of 255 and 254 is essentially the same but 4rd forces people have to treat them differently. and then you tell me "4rd-tunneling" is not a commonly understood "tunnel", i get the knowledge and i may follow 4rd's semantics. but i need to think differently when i come back to the normal world. fine but costy. if it is worth, just for the gain of a single specification? (very subjective, isn't it?) i think the problems has been much discussed. further debate may become too philosophical. let me make the commentary updated, to reflect the significant changes between the final two versions, and you may polish the 4rd specification further. my task is simple: to prevent the authors missing to note the changes of semantics different from our most popular understanding. the judgement on the impact might be subjective and the commentary won't focus on that. thanks for patience, maoke > > > > Regards, > RD > > > > > > >> >> That's would be a real, justified use case. Otherwise it's just theory. > > > you may directly say encapsulation doing a lot things only significant in > theory. but the reality is not so. i also suggest we, moderately, not to > argue something is only a theory just because we haven't known it is real= ly > happening somewhere unknown to us. > > > thanks and regards, > maoe > > >> >> >> 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 >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --20cf303640bb22bf4b04c1a642d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/6/4 R=E9mi Despr=E9s <despr= es.remi@laposte.net>
Maoke,
Please see comments inline.<= /div>

2012-06-04 =A004:35, Maoke:

sorry for the late reply.=A0

2012/5/23 Simon Perreault <simon.perreault@v= iagenie.ca>
(Did you intend to send this to the WG?)

th= anks for reminding :) i did reply but not reply-all.=A0
=A0
=


On 2012-05-22 21:38, Maoke wrote:
=A0 =A0My understanding: 4rd is a compromise.

=A0 =A0What you gain: only one protocol to consider.
=A0 =A0What you lose: some edge cases are not supported.


that sort of statement is surely fair. but, unfortunately, 4rd document
seldom admits it loses something (this is why i found writing a
commentary was necessary). and the question is: are these *edge* cases
are really edge?

That is exactly the right question to ask.


a quick but incomplete list of these *edge* cases are:

1. routing protocols with TTL-security setting with number other than 1
or 255;

Do such protocols exist?

ebgp multihop with= any possible value of ttl restriction; =A0
other applications al= so possible use ttl restriction (e.g., iptable -t mangle -m ttl). =A0

Right.
But these protocols= require communicating nodes to know how many routers may be traversed betw= een them.
=A0
no protocol can cal= culate=A0the hops for=A0setting the number. but human does.
in t= he encapsulation mode, the IPv6 provider's domain is=A0treated as 1 hop= , which simplifies the counting.
=A0
4rd FORCES=A0that operator MUST let the customer know th= e details if the customers would=A0like to do the hop counting even though = actually the customers don't care=A0about=A0such details.
MA= P-T is also=A0doing so but if operators/customers wouldn't like to have= this,=A0MAP allows them=A0to have the choice of MAP-E.
=A0
okay. i=A0think=A0i finally almost=A0am able to understa= nd the philosophy of 4rd. just=A0like the Lufthansa=A0flight=A0i once=A0too= k.=A0in the dinner, we=A0had the choice between beef and chicken and then= =A0some bad=A0passengers claimed=A0that they rejected chicken because of th= e fear of bird diseases. in the breakfast later, however, we had only eggs.= and nobody blamed.
=A0
4rd's idea is providing only the eggs to all people,= forcing them to have to be happy but removing their trouble in choice.
=A0
=A0
=A0
In this regard, = 4rd doesn't introduce a new constraint (AFAIK). =A0


=
2. ipv6 domain has firewalls that need to filter unknown/unexpected
protocols but not yet recognize ICMPv4 as IPv6 payload (at least Linux
ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei can?);

Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) a val= id use case?

well, good question! but don&#= 39;t state 4rd can support intermediate tools of operation can work as in t= ranslation, seeing the L4 payload. - such a statement was one of the main m= otivation of 4rd-u.


There is no int= ent to claim that "intermediate tools of operation can work as in tran= slation".
=A0
=A0
fine. i got it. previously i=A0understood the motivation of 4rd was ma= king a high quality combination of both advantages. now i know it is the co= mpromise for the single protocol. sorry but i was totally=A0misunderstandin= g.
=A0

=A0
I found one place, in the Introduction, that you may find= too general:
"IPv4 headers can be reversibly translated int= o IPv6 headers in such a way that, during IPv6 domain traversal, tunneled T= CP and UDP packets are valid IPv6 packets. Thus, IPv6-only middle boxes tha= t perform deep-packet-inspection can operate on them."
It could become:
"IPv4 headers can be reversibly transl= ated into IPv6 headers in such a way that, during IPv6 domain traversal,=A0= UDP packets having checksums and=A0TCP packets are valid IPv6 packets. Thus= , IPv6-only middle boxes that perform deep-packet-inspection, in particular= on port numbers, can operate on them."=A0
=A0
=A0
no problem = to me if it is explicitly specified what deep-inspection is ok what is comp= romised.=A0
=A0
=A0

=
Thought?


if it cannot support intermediate op= eration tools working with wanted filtering regarding any payload type, thi= s superiority over MAP-E, AFAIK, is fake.=A0

(*) There is AFAIK no claim in the = draft that, regarding "wanted filtering regarding any payload type&quo= t;, 4rd would be superior to MAP-E.

Besides,=A0a c= larification of the problem you see concerning this=A0"wanted filterin= g regarding any payload type"=A0would be appreciated.=A0
(It is clear that deploying 4rd across an IPv6 domain may imply adjust= ments of DPI filters if some have been configured.)


3. ipv6 routers sometimes generates bit errors in hardware or software
before dropping packets to NIC.

I fail to understand the problem here, sorry.

sorry but please read the history of=A0

1. why = Sun Microsystem enables NFS's UDP checksum after a long period of using= null checksum?
2. why higher layer checksum is still needed and how it is significant= even when link layer has contained CRC?=A0

otherw= ise it would be hard to make the dialogue. sorry.=A0

a) UDP checksums, if used, aren't disabled by= 4rd. IP payloads and addresses remain protected e2e.

<= div>b) If UDP checksum aren't used (as permitted only in IPv4), the fac= t that addresses are not protected in tunnel headers as they are in IPv4 he= aders is compensated =A0in =A04rd=A0by the intrinsic redundancy of each tun= nel-endpoint address (see (**) at the end of section 4.2).=A0
This address protection is also effective for ICMPv4 messages which (u= nlike ICMPv6 messages) don't protect addresses by their checksums.
=A0
=A0
limited ch= ecksum protection focusing on addresses.
=A0
=A0


Concerning hardware-originated = errors, could you then indicate an error example that would be insufficient= ly detected in 4rd while sufficiently detected in MAP-T and MAP-E?
=A0
=A0
checksum is impr= oving quite effectively, in the SIGCOMM'00 paper that i cited. i think= =A0you accept this conclusion as you so emphasize the importance of CNP.=A0= the point is,=A0MAP-T doesn't lose any information of the pseudo-header= -covered fields. the level of protection is as same as the native IPv6. MAP= -E keeps whole IPv4 fields and the protection level is as same as the nativ= e IPv4 in the sense of end-to-end.
=A0
i have stated, the bit error can happen in address and s= urely it could happen in any field including payload length or payload prot= ocol (next-header). i don't think any further detailed example is neede= d. it has been clear enough.
=A0
=A0


if any of the above *edge* cases actually happens, in such happening
*edge* cases, we still need either encapsulation or translation.

Since we're talking about compromise, I believe the edge case not only = has to happen, it also has to be *important*. Meaning that we might want to= avoid supporting some unimportant edge cases if that means simplifying the= protocol.

good point. philosophy is the same. however, which is t= he simple protocol?=A0

At= least some contributors see 4rd as simpler than MAP-T plus MAP-E, but you = seem to think differently so let's take it at subjective at this point.=
The main point however is that 4rd permits to have a single standardiz= ed solution, an important simplification of the global situation for vendor= s, operators, customers.=A0
=A0
=A0
see the above. the main point is 4rd gets rid of possibl= e choices of people and forces them to eat only one type of food. (i don= 9;t say it is definitely bad but just what i don't like.) it is still v= ery subjective.
=A0
=A0


- MAP suite:
=A0 A. ex= isting encapsulation, existing translation (not anything new but appying B)= ;
=A0 B. new address mapping rule;
=A0 C. compromising DF=3DM= F=3D1 edge cases (less than 10^-6 regarding importance).

Note that standard-track RFC4821 says:
=A0"All fragmentation SHOULD be done on the host, and all IPv4 packets= , including fragments, SHOULD have the DF bit set such that they will not b= e fragmented (again) in the network."
This can be expected t= o produce many legitimate DF=3DMF=3D1.
=A0
=A0
different u= nderstanding. host fragmentation means fragmenting the data from upper laye= rs before generating the IP packets, rather than generating one and them pu= tting it back to the stack for being fragmented. and therefore the result w= ill be a lot of DF=3D1 but MF=3D0 packets. this is my understanding to the = RFC4821, if wrong, please point out. (this is always welcome regardless of = the relevance to this thread).
=A0
=A0

There are AFAIK some other compromises in MAP-= T+E, but to be discussed when we have a stabilized specification.


- 4rd:
=A0 A. new trans-capsulatio= n (let me call it like that);

Reversible translation, as proposed in the draft, is IMHO a better way to c= all it that "trans-capsulation".
Could you use it, or i= s there a problem?
=A0
=A0
IMHO, trans-capsulation is closer to the actual behavior of 4= rd. reversible translation is a little confusing as a lot of its behavior i= s not translation at all. and double translation is partially reversible to= o, while 4rd, nevertheless, cannot=A0be said=A0"totally reversible&quo= t; even it is a little more reversible than double translation. i don't= this the trans-capsulation has anything bad meaning. scientists made Lion-= Tiger very precious and very beautiful animal. i do suggest you use the ter= m with more concrete meaning but i won't be over objective if you insis= t using "reversible translation".
=A0 B. new addres= s mapping rule;
=A0 C. compromising (at least)=A0
=A0 =A0 =A0C1. ttl preverv= ing for any TTL but 1 or 225 (which MAP supports with the -E variant)
=
... and loses with the -T variant.

=A0 =A0 =A0C2= . intermediate ipv6 filtering on any protocol (which MAP supports with the = -T variant)=A0
... and loses with the -E= variant.
(This is assuming there is something significant in this point, bet se= e (*) above)


i think the answer is obvious but i cannot help if you = insist the latter is simpler. ;-)
=A0


=A0 =A0So any argument to the effect that "MAP-E|T does X and 4rd doe= sn't"
=A0 =A0is empty. This is expected, it's a compromise.

some arguments are about "MAP-E|T doesn't make a confusing Y but 4= rd
does". sorry this is not expected.

I believe it's also a compromise. You lose some simplicity, you gain a = single protocol.

your above: "simplify= ing the protocol"; here: "you lose some simplicity". ??? hav= e you admitted that the 4rd is less simple??

4rd may be viewed =A0IMHO as l= ess simple than MAP-E alone, but it shouldn't be ignored that it does l= argely more. To take just =A0one feature, independently of those of MAP-T, = 4rd BRs forward IPv4 packets on the fly, while the MAP-E specification says= "If the packet is fragmented, BR should reassemble the packet". = This is significant for scalability and for propagation delays.
=A0
=A0
another top= ic of discussion. i have little exploration on this and i have no right to = argue.
=A0
=A0


=
=A0 =A0The argument should be: "I need 4rd to do X because ..."<= br>
well, what is the X then? if the X is only "the number of protocol =3D=
1"... we may have a lot of ways to achieve it without the need of
excluding any so-called *edge* cases, without the need of introducing
any ugly behavior with the excuse of "compromise".

encapsulation and translation have been the cases of loss-and-gain
compromises. do we need the third?

For example: I need 4rd to support TTL preservation for value 64 because I&= #39;m using routing protocol XYZ which needs it.

<= /div>
well, ttl 254, 253, 252, 251, 250, etc... are often used for eBGP= multihop.=A0
ttl 64 are sometimes used in our application facility for internal web= service.

Fine.
But = which example would you have where these values would be a problem with 4rd= (knowing that any network decreases such values by the number of traversed= routers).
=A0
=A0
surely, when i th= ink my packets traverse your domain as tunneled, and my customer networks c= ontains 2 hops, i may set 252 for the valid minimum ttl. however, 4rd makes= the decrement and i will lose this packet. which is unexpected. the value = of 255 and 254 is essentially the same but 4rd forces people have to treat = them differently. and then you tell me "4rd-tunneling" is not a c= ommonly understood "tunnel", i get the knowledge and i may follow= 4rd's semantics. but i need to think differently when i come back to t= he normal world.
=A0
fine but costy. if it is worth, just for the gain of a s= ingle specification? (very subjective, isn't it?)
=A0
i think the problems has been much discussed. further debate may become = too philosophical.=A0let me make the commentary updated, to reflect the=A0s= ignificant changes between the final=A0two versions,=A0and you=A0may=A0poli= sh the 4rd specification further. my task is simple: to prevent the authors= missing to note the changes of semantics=A0different from=A0our most popul= ar understanding. the judgement on the impact=A0might be subjective and the= commentary won't focus on that.
=A0
thanks for patience,
maoke
=A0
=A0
=A0

=
Regards,
RD




=A0

That's would be a real, justified use case. Otherwise it's just= theory.=A0

you may directly say encapsulat= ion doing a lot things only significant in theory. but the reality is not s= o. i also suggest we, moderately, not to argue something is only a theory j= ust because we haven't known it is really happening somewhere unknown t= o us.=A0

thanks and regards,
maoe
=A0
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c= olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class= =3D"gmail_quote">


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

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


--20cf303640bb22bf4b04c1a642d7-- From yiu_lee@cable.comcast.com Mon Jun 4 07:34: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 970E621F88AF for ; Mon, 4 Jun 2012 07:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.914 X-Spam-Level: X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=-2.317, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTx19IZSICet for ; Mon, 4 Jun 2012 07:34:29 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id D323421F86FD for ; Mon, 4 Jun 2012 07:34:28 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.14702220; Mon, 04 Jun 2012 10:25:31 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.28]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Mon, 4 Jun 2012 10:34:24 -0400 From: "Lee, Yiu" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Thread-Index: AQHNQl8iK0hTvhWfL0aFaL7i1fBJ7g== Date: Mon, 4 Jun 2012 14:34:23 +0000 Message-ID: In-Reply-To: <5CFBB5FC-EB57-4E3D-81CB-0BF22B7CE342@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.2.120421 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3421650862_348946" MIME-Version: 1.0 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 04 Jun 2012 14:34:29 -0000 --B_3421650862_348946 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Ole, AFAIK, this will couple the IPv4 address and IPv6 prefix. This isn't the requirement for Public 4over6. Thanks, Yiu On 6/1/12 4:45 AM, "Ole Tr=F8an" wrote: >>> public 4over6 is exactly the same as MAP in hub and spoke mode with >>>one mapping rule per subscriber. >>=20 >> Could you clarify how this relates to the MAP-rule definition saying >>"Each MAP node in the domain has the same set of rules". >> (draft-mdt-softwire-mapping-address-and-port-03) > >you can look at it as if each subscriber has his own MAP domain. > >cheers, >Ole > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3421650862_348946 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBR/R5By m2rNPuP52b61dFITM8cRpjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MDQxNDM0MjFaMA0GCSqGSIb3DQEBAQUABIIBABL/lyaPFM7i5Vxbf0W0kkPV y+0jVww35ugxVUKdz44KvHqvUjF4iRI9SjTTqXwpAV+3rP+6shhCIjpr34cU5UoNTCXk3+mr jUm92ooRrPaFAi+7EQ3pVXkBqDT6eOo9zm/n9J1MN9ZaznFK1RTuDYC2rT1yoDoarFu/nPUI lpYwnP3ABhPnSB6RPJlfO60/4VjnPcC/qw2zXuuetfuopQ+CpwkEqXNWTq0jPOvyOwfN6/z3 6gTiEHcQ00qo9jwnBM0la6oknZeDAG07PiZFnkQ9xYQsDMXEYg5SueybGl5b/pTov7KrVlT5 czp4BhLKNt9F3KniMc6g0z11MYqw6ns= --B_3421650862_348946-- From despres.remi@laposte.net Mon Jun 4 10:51: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 9020411E80A0 for ; Mon, 4 Jun 2012 10:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgPm2nsXeecd for ; Mon, 4 Jun 2012 10:51:48 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id A089D11E809F for ; Mon, 4 Jun 2012 10:51:44 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id C3A2194019C; Mon, 4 Jun 2012 19:51:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--252156154 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 4 Jun 2012 19:51:36 +0200 Message-Id: <988F10FB-54DB-4F7F-BD18-58CD7A076BFC@laposte.net> References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> <4FBBCCA9.2050603@viagenie.ca> <4FBCD6FF.2030900@viagenie.ca> To: Maoke X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 04 Jun 2012 11:05:46 -0700 Cc: Softwires-wg Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.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: Mon, 04 Jun 2012 17:51:50 -0000 --Apple-Mail-6--252156154 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-06-04 16:22, Maoke: >=20 >=20 > 2012/6/4 R=E9mi Despr=E9s > Maoke, > Please see comments inline. >=20 > 2012-06-04 04:35, Maoke: >=20 >> sorry for the late reply.=20 >>=20 >> 2012/5/23 Simon Perreault >> (Did you intend to send this to the WG?) >>=20 >> thanks for reminding :) i did reply but not reply-all.=20 >> =20 >>=20 >>=20 >> On 2012-05-22 21:38, Maoke wrote: >> My understanding: 4rd is a compromise. >>=20 >> What you gain: only one protocol to consider. >> What you lose: some edge cases are not supported. >>=20 >>=20 >> that sort of statement is surely fair. but, unfortunately, 4rd = document >> seldom admits it loses something (this is why i found writing a >> commentary was necessary). and the question is: are these *edge* = cases >> are really edge? >>=20 >> That is exactly the right question to ask. >>=20 >>=20 >> a quick but incomplete list of these *edge* cases are: >>=20 >> 1. routing protocols with TTL-security setting with number other than = 1 >> or 255; >>=20 >> Do such protocols exist? >>=20 >> ebgp multihop with any possible value of ttl restriction; =20 >> other applications also possible use ttl restriction (e.g., iptable = -t mangle -m ttl). =20 >=20 > Right. > But these protocols require communicating nodes to know how many = routers may be traversed between them. > =20 > no protocol can calculate the hops for setting the number. but human = does. > in the encapsulation mode, the IPv6 provider's domain is treated as 1 = hop, which simplifies the counting. > =20 > 4rd FORCES that operator MUST let the customer know the details if the = customers would like to do the hop counting even though actually the = customers don't care about such details. > MAP-T is also doing so but if operators/customers wouldn't like to = have this, MAP allows them to have the choice of MAP-E. It looks like you suggest that a customer who wants a feature of MAP-E = while his ISP has chosen MAP-T, or conversely, would ask his ISP to = change its choice. Since this is of course is unrealistic, I take it as a demonstration = that a single standard is much preferable. > okay. i think i finally almost am able to understand the philosophy of = 4rd. > just like the Lufthansa flight i once took. in the dinner, we had the = choice between beef and chicken and then some bad passengers claimed = that they rejected chicken because of the fear of bird diseases. in the = breakfast later, however, we had only eggs. and nobody blamed. > =20 > 4rd's idea is providing only the eggs to all people, forcing them to = have to be happy but removing their trouble in choice. > =20 > =20 > =20 > In this regard, 4rd doesn't introduce a new constraint (AFAIK). =20 >=20 >=20 >> 2. ipv6 domain has firewalls that need to filter unknown/unexpected >> protocols but not yet recognize ICMPv4 as IPv6 payload (at least = Linux >> ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei = can?); >>=20 >> Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) = a valid use case? >>=20 >> well, good question! but don't state 4rd can support intermediate = tools of operation can work as in translation, seeing the L4 payload. - = such a statement was one of the main motivation of 4rd-u. >=20 >=20 > There is no intent to claim that "intermediate tools of operation can = work as in translation". > =20 > =20 > fine. i got it. previously i understood the motivation of 4rd was = making a high quality combination of both advantages. Still true (significant advantages) > now i know it is the compromise for the single protocol. Still true (acceptable compromises) > sorry but i was totally misunderstanding. > =20 > I found one place, in the Introduction, that you may find too general: > "IPv4 headers can be reversibly translated into IPv6 headers in such a = way that, during IPv6 domain traversal, tunneled TCP and UDP packets are = valid IPv6 packets. Thus, IPv6-only middle boxes that perform = deep-packet-inspection can operate on them." > It could become: > "IPv4 headers can be reversibly translated into IPv6 headers in such a = way that, during IPv6 domain traversal, UDP packets having checksums and = TCP packets are valid IPv6 packets. Thus, IPv6-only middle boxes that = perform deep-packet-inspection, in particular on port numbers, can = operate on them."=20 > =20 > =20 > no problem to me if it is explicitly specified what deep-inspection is = ok what is compromised.=20 > =20 > =20 >=20 > Thought? >=20 >=20 >> if it cannot support intermediate operation tools working with wanted = filtering regarding any payload type, this superiority over MAP-E, = AFAIK, is fake.=20 >=20 > (*) There is AFAIK no claim in the draft that, regarding "wanted = filtering regarding any payload type", 4rd would be superior to MAP-E. >=20 > Besides, a clarification of the problem you see concerning this = "wanted filtering regarding any payload type" would be appreciated.=20 > (It is clear that deploying 4rd across an IPv6 domain may imply = adjustments of DPI filters if some have been configured.) >=20 >=20 >> 3. ipv6 routers sometimes generates bit errors in hardware or = software >> before dropping packets to NIC. >>=20 >> I fail to understand the problem here, sorry. >>=20 >> sorry but please read the history of=20 >>=20 >> 1. why Sun Microsystem enables NFS's UDP checksum after a long period = of using null checksum? >> 2. why higher layer checksum is still needed and how it is = significant even when link layer has contained CRC?=20 >>=20 >> otherwise it would be hard to make the dialogue. sorry.=20 >=20 > a) UDP checksums, if used, aren't disabled by 4rd. IP payloads and = addresses remain protected e2e. >=20 > b) If UDP checksum aren't used (as permitted only in IPv4), the fact = that addresses are not protected in tunnel headers as they are in IPv4 = headers is compensated in 4rd by the intrinsic redundancy of each = tunnel-endpoint address (see (**) at the end of section 4.2).=20 > This address protection is also effective for ICMPv4 messages which = (unlike ICMPv6 messages) don't protect addresses by their checksums. > =20 > =20 > limited checksum protection focusing on addresses. Asking for more protection would AFAIK not be asking for any operational = gain, only overdesign. - UDP/TCP checksums are as efficient with 4rd tunnel traversal as = without. - ICMPv4 has its own checksum, good enough for ICMP messages - Consequence of a corrupted null-checksum UDP datagram must be limited = anyway. > Concerning hardware-originated errors, could you then indicate an = error example that would be insufficiently detected in 4rd while = sufficiently detected in MAP-T and MAP-E? > =20 > =20 > checksum is improving quite effectively, in the SIGCOMM'00 paper that = i cited. > i think you accept this conclusion as you so emphasize the importance = of CNP. I say that CNP protects against misdirections (self-redunbdncy of = addresses), and permits to leave UDP/TCP layers unchanged. No emphasis needed. > the point is, MAP-T doesn't lose any information of the = pseudo-header-covered fields. > the level of protection is as same as the native IPv6. MAP-E keeps = whole IPv4 fields and the protection level is as same as the native IPv4 = in the sense of end-to-end. > =20 > i have stated, the bit error can happen in address and surely it could = happen in any field including payload length or payload protocol = (next-header). i don't think any further detailed example is needed. it = has been clear enough. > =20 > =20 >=20 >=20 >> if any of the above *edge* cases actually happens, in such happening >> *edge* cases, we still need either encapsulation or translation. >>=20 >> Since we're talking about compromise, I believe the edge case not = only has to happen, it also has to be *important*. Meaning that we might = want to avoid supporting some unimportant edge cases if that means = simplifying the protocol. >>=20 >> good point. philosophy is the same. however, which is the simple = protocol?=20 >=20 > At least some contributors see 4rd as simpler than MAP-T plus MAP-E, = but you seem to think differently so let's take it at subjective at this = point. > The main point however is that 4rd permits to have a single = standardized solution, an important simplification of the global = situation for vendors, operators, customers.=20 > =20 > =20 > see the above. the main point is 4rd gets rid of possible choices of = people and forces them to eat only one type of food. (i don't say it is = definitely bad but just what i don't like.) it is still very subjective. > =20 > =20 >=20 >=20 >> - MAP suite: >> A. existing encapsulation, existing translation (not anything new = but appying B); >> B. new address mapping rule; >> C. compromising DF=3DMF=3D1 edge cases (less than 10^-6 regarding = importance). >=20 > Note that standard-track RFC4821 says: > "All fragmentation SHOULD be done on the host, and all IPv4 packets, = including fragments, SHOULD have the DF bit set such that they will not = be fragmented (again) in the network." > This can be expected to produce many legitimate DF=3DMF=3D1. > =20 > =20 > different understanding. host fragmentation means fragmenting the data = from upper layers before generating the IP packets, rather than = generating one and them putting it back to the stack for being = fragmented. and therefore the result will be a lot of DF=3D1 but MF=3D0 = packets. this is my understanding to the RFC4821, if wrong, please point = out. (this is always welcome regardless of the relevance to this = thread). - You seem to say that packets with MF=3D1 are negligible but, if that = would be so, why to have fragmentation at all in IPv6? - The quoted sentence clearly deals with packet fragments, at layer 3, = asking for their not being fragmented "again" in networks.=20 > There are AFAIK some other compromises in MAP-T+E, but to be discussed = when we have a stabilized specification. >=20 >=20 >> - 4rd: >=20 >> A. new trans-capsulation (let me call it like that); >=20 > Reversible translation, as proposed in the draft, is IMHO a better way = to call it that "trans-capsulation". > Could you use it, or is there a problem? > =20 > =20 > IMHO, trans-capsulation is closer to the actual behavior of 4rd. = reversible translation is a little confusing as a lot of its behavior is = not translation at all. and double translation is partially reversible = too, while 4rd, nevertheless, cannot be said "totally reversible" even = it is a little more reversible than double translation. i don't this the = trans-capsulation has anything bad meaning. scientists made Lion-Tiger = very precious and very beautiful animal. i do suggest you use the term = with more concrete meaning but i won't be over objective if you insist = using "reversible translation". At the informal meeting on 4rd-u in Paris, someone insisted that, for = him, reversible "translation" was much better than reversible "mapping". = This being perceived as a problem, the terminology was changed. Regards, RD >> B. new address mapping rule; >> C. compromising (at least)=20 >> C1. ttl preverving for any TTL but 1 or 225 (which MAP supports = with the -E variant) > ... and loses with the -T variant. >=20 >> C2. intermediate ipv6 filtering on any protocol (which MAP = supports with the -T variant)=20 >=20 > ... and loses with the -E variant. > (This is assuming there is something significant in this point, bet = see (*) above) >=20 >>=20 >> i think the answer is obvious but i cannot help if you insist the = latter is simpler. ;-) >> =20 >>=20 >>=20 >> So any argument to the effect that "MAP-E|T does X and 4rd = doesn't" >> is empty. This is expected, it's a compromise. >>=20 >> some arguments are about "MAP-E|T doesn't make a confusing Y but 4rd >> does". sorry this is not expected. >>=20 >> I believe it's also a compromise. You lose some simplicity, you gain = a single protocol. >>=20 >> your above: "simplifying the protocol"; here: "you lose some = simplicity". ??? have you admitted that the 4rd is less simple?? >=20 > 4rd may be viewed IMHO as less simple than MAP-E alone, but it = shouldn't be ignored that it does largely more. To take just one = feature, independently of those of MAP-T, 4rd BRs forward IPv4 packets = on the fly, while the MAP-E specification says "If the packet is = fragmented, BR should reassemble the packet". This is significant for = scalability and for propagation delays. > =20 > =20 > another topic of discussion. i have little exploration on this and i = have no right to argue. > =20 > =20 >=20 >=20 >> The argument should be: "I need 4rd to do X because ..." >>=20 >> well, what is the X then? if the X is only "the number of protocol =3D >> 1"... we may have a lot of ways to achieve it without the need of >> excluding any so-called *edge* cases, without the need of introducing >> any ugly behavior with the excuse of "compromise". >>=20 >> encapsulation and translation have been the cases of loss-and-gain >> compromises. do we need the third? >>=20 >> For example: I need 4rd to support TTL preservation for value 64 = because I'm using routing protocol XYZ which needs it. >>=20 >> well, ttl 254, 253, 252, 251, 250, etc... are often used for eBGP = multihop.=20 >> ttl 64 are sometimes used in our application facility for internal = web service. >=20 > Fine. > But which example would you have where these values would be a problem = with 4rd (knowing that any network decreases such values by the number = of traversed routers). > =20 > =20 > surely, when i think my packets traverse your domain as tunneled, and = my customer networks contains 2 hops, i may set 252 for the valid = minimum ttl. however, 4rd makes the decrement and i will lose this = packet. which is unexpected. the value of 255 and 254 is essentially the = same but 4rd forces people have to treat them differently. and then you = tell me "4rd-tunneling" is not a commonly understood "tunnel", i get the = knowledge and i may follow 4rd's semantics. but i need to think = differently when i come back to the normal world. > =20 > fine but costy. if it is worth, just for the gain of a single = specification? (very subjective, isn't it?) > =20 > i think the problems has been much discussed. further debate may = become too philosophical. let me make the commentary updated, to reflect = the significant changes between the final two versions, and you may = polish the 4rd specification further. my task is simple: to prevent the = authors missing to note the changes of semantics different from our most = popular understanding. the judgement on the impact might be subjective = and the commentary won't focus on that. > =20 > thanks for patience, > maoke > =20 > =20 > =20 >=20 >=20 > Regards, > RD >=20 >=20 >=20 >=20 >> =20 >>=20 >> That's would be a real, justified use case. Otherwise it's just = theory.=20 >>=20 >> you may directly say encapsulation doing a lot things only = significant in theory. but the reality is not so. i also suggest we, = moderately, not to argue something is only a theory just because we = haven't known it is really happening somewhere unknown to us.=20 >>=20 >> thanks and regards, >> maoe >> =20 >>=20 >>=20 >> 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 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-6--252156154 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/6/4 R=E9mi Despr=E9s <despres.remi@laposte.net>
Maoke,
Please see comments = inline.

2012-06-04  04:35, = Maoke:

sorry for the late = reply. 

2012/5/23 Simon Perreault = <simon.perreault@viagenie.ca>
(Did you intend to send this to the = WG?)

thanks for reminding :) i did reply = but not reply-all. 
 


On 2012-05-22 21:38, Maoke wrote:
   My understanding: 4rd is a compromise.

   What you gain: only one protocol to consider.
   What you lose: some edge cases are not supported.


that sort of statement is surely fair. but, unfortunately, 4rd = document
seldom admits it loses something (this is why i found writing a
commentary was necessary). and the question is: are these *edge* = cases
are really edge?

That is exactly the right question to ask.


a quick but incomplete list of these *edge* cases are:

1. routing protocols with TTL-security setting with number other than = 1
or 255;

Do such protocols exist?

ebgp multihop = with any possible value of ttl restriction;  
other = applications also possible use ttl restriction (e.g., iptable -t mangle = -m ttl).  

Right.
But these protocols require = communicating nodes to know how many routers may be traversed between = them.
 
no protocol = can calculate the hops for setting the number. but human does. =
in the encapsulation mode, the IPv6 provider's domain = is treated as 1 hop, which simplifies the counting.
 
4rd FORCES that operator MUST let the = customer know the details if the customers would like to do the hop = counting even though actually the customers don't = care about such details.
MAP-T is also doing = so but if operators/customers wouldn't like to have this, MAP = allows them to have the choice of = MAP-E.

It looks like you suggest = that a customer who wants a feature of MAP-E while his ISP has = chosen MAP-T, or conversely, would ask his ISP to change its = choice.
Since this is of course is unrealistic, I take it as a = demonstration that a single standard is much = preferable.


okay. i think i finally almost am able to understand = the philosophy of 4rd.
just like the = Lufthansa flight i once took. in the dinner, = we had the choice between beef and chicken and then some = bad passengers claimed that they rejected chicken because of = the fear of bird diseases. in the breakfast later, however, we had only = eggs. and nobody blamed.
 
4rd's idea is providing only the eggs to all = people, forcing them to have to be happy but removing their trouble in = choice.
 
 
 
In this regard, 4rd doesn't introduce a = new constraint (AFAIK).  


2. ipv6 domain has firewalls that need to filter unknown/unexpected
protocols but not yet recognize ICMPv4 as IPv6 payload (at least = Linux
ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei = can?);

Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) a = valid use case?

well, good question! but = don't state 4rd can support intermediate tools of operation can work as = in translation, seeing the L4 payload. - such a statement was one of the = main motivation of 4rd-u.


There is no = intent to claim that "intermediate tools of operation can work as in = translation".
 
&n= bsp;
fine. i got it. previously i understood the motivation of 4rd = was making a high quality combination of both = advantages.

Still true = (significant advantages)

now i know it is the compromise for the = single protocol.

Still true = (acceptable compromises)

sorry but i was = totally misunderstanding.
 
I found = one place, in the Introduction, that you may find too = general:
"IPv4 headers can be reversibly translated into IPv6 = headers in such a way that, during IPv6 domain traversal, tunneled TCP = and UDP packets are valid IPv6 packets. Thus, IPv6-only middle boxes = that perform deep-packet-inspection can operate on them."
It could become:
"IPv4 headers can be reversibly = translated into IPv6 headers in such a way that, during IPv6 domain = traversal, UDP packets having checksums and TCP packets are = valid IPv6 packets. Thus, IPv6-only middle boxes that perform = deep-packet-inspection, in particular on port numbers, can operate on = them." 
 
 
no = problem to me if it is explicitly specified what deep-inspection is ok = what is compromised. 
 
 

<= div>Thought?


if it cannot support = intermediate operation tools working with wanted filtering regarding any = payload type, this superiority over MAP-E, AFAIK, is fake. 

(*) There is AFAIK no claim in = the draft that, regarding "wanted filtering regarding any payload type", = 4rd would be superior to MAP-E.

Besides, a = clarification of the problem you see concerning this "wanted = filtering regarding any payload type" would be = appreciated. 
(It is clear that deploying 4rd across an IPv6 domain may imply = adjustments of DPI filters if some have been = configured.)


3. ipv6 routers sometimes generates bit errors in hardware or = software
before dropping packets to NIC.

I fail to understand the problem here, = sorry.

sorry but please read the history = of 

1. why Sun Microsystem enables NFS's = UDP checksum after a long period of using null checksum?
2. why higher layer checksum is still needed and how it is = significant even when link layer has contained = CRC? 

otherwise it would be hard to make = the dialogue. sorry. 

a) UDP checksums, if used, aren't disabled by = 4rd. IP payloads and addresses remain protected = e2e.

b) If UDP checksum aren't used (as = permitted only in IPv4), the fact that addresses are not protected in = tunnel headers as they are in IPv4 headers is compensated  in =  4rd by the intrinsic redundancy of each tunnel-endpoint = address (see (**) at the end of section 4.2). 
This address protection is also effective for ICMPv4 messages which = (unlike ICMPv6 messages) don't protect addresses by their = checksums.
 
 = ;
limited checksum protection focusing on addresses. =

Asking for more protection = would AFAIK not be asking for any operational gain, only = overdesign.

- UDP/TCP checksums are as = efficient with 4rd tunnel traversal as without.
- ICMPv4 has = its own checksum, good enough for ICMP messages
- Consequence = of a corrupted null-checksum UDP datagram must be limited = anyway.


Concerning = hardware-originated errors, could you then indicate an error example = that would be insufficiently detected in 4rd while sufficiently detected = in MAP-T and MAP-E?
=  
 
checksum = is improving quite effectively, in the SIGCOMM'00 paper that i cited. =

i think you accept this conclusion as = you so emphasize the importance of = CNP.

I say that CNP protects = against misdirections (self-redunbdncy of addresses), and permits to = leave UDP/TCP layers unchanged.
No emphasis = needed.


 the point is, MAP-T doesn't lose = any information of the pseudo-header-covered = fields.
the level of protection is as same as the = native IPv6. MAP-E keeps whole IPv4 fields and the protection level is = as same as the native IPv4 in the sense of end-to-end.
 
i have stated, the bit error can happen in address = and surely it could happen in any field including payload length or = payload protocol (next-header). i don't think any further detailed = example is needed. it has been clear enough.
 
 


if any of the above *edge* cases actually happens, in such happening
*edge* cases, we still need either encapsulation or translation.

Since we're talking about compromise, I believe the edge case not only = has to happen, it also has to be *important*. Meaning that we might want = to avoid supporting some unimportant edge cases if that means = simplifying the protocol.

good point. philosophy is the same. however, which = is the simple = protocol? 

At = least some contributors see 4rd as simpler than MAP-T plus MAP-E, but = you seem to think differently so let's take it at subjective at this = point.
The main point however is that 4rd permits to have a single = standardized solution, an important simplification of the global = situation for vendors, operators, = customers. 
 
 
see the above. the main point is 4rd gets rid of = possible choices of people and forces them to eat only one type of food. = (i don't say it is definitely bad but just what i don't like.) it is = still very subjective.
 
 


- MAP suite: =
  A. existing encapsulation, existing translation (not = anything new but appying B);
  B. new address mapping rule;
  C. = compromising DF=3DMF=3D1 edge cases (less than 10^-6 regarding = importance).

Note that = standard-track RFC4821 says:
 "All fragmentation SHOULD be done on the host, and all IPv4 = packets, including fragments, SHOULD have the DF bit set such that they = will not be fragmented (again) in the network."
This can be = expected to produce many legitimate DF=3DMF=3D1.
=
 
 
diff= erent understanding. host fragmentation means fragmenting the data from = upper layers before generating the IP packets, rather than generating = one and them putting it back to the stack for being fragmented. and = therefore the result will be a lot of DF=3D1 but MF=3D0 packets. this is = my understanding to the RFC4821, if wrong, please point out. (this is = always welcome regardless of the relevance to this thread). =

- You seem to say that = packets with MF=3D1 are negligible but, if that would be so, why to = have fragmentation at all in IPv6?
- The quoted sentence = clearly deals with packet fragments, at layer 3, asking for their not = being fragmented "again" in = networks. 


There are AFAIK some other = compromises in MAP-T+E, but to be discussed when we have a stabilized = specification.


- 4rd:
  A. new trans-capsulation (let me call = it like that);

Reversible translation, as proposed in the draft, is IMHO a better way = to call it that "trans-capsulation".
Could you use it, or is = there a = problem?
 
 
IMHO, trans-capsulation is closer to the actual = behavior of 4rd. reversible translation is a little confusing as a lot = of its behavior is not translation at all. and double translation is = partially reversible too, while 4rd, nevertheless, cannot be = said "totally reversible" even it is a little more reversible than = double translation. i don't this the trans-capsulation has anything bad = meaning. scientists made Lion-Tiger very precious and very beautiful = animal. i do suggest you use the term with more concrete meaning but i = won't be over objective if you insist using "reversible translation". =

At the informal meeting on = 4rd-u in Paris, someone insisted that, for him, reversible "translation" = was much better than reversible "mapping". This being perceived as a = problem, the terminology was = changed.

Regards,
RD







  B. new = address mapping rule;
  C. compromising (at least) 
    =  C1. ttl preverving for any TTL but 1 or 225 (which MAP supports = with the -E variant)
... and loses with = the -T variant.

  =    C2. intermediate ipv6 filtering on any protocol (which MAP = supports with the -T = variant) 
... and loses with the = -E variant.
(This is assuming there is something significant in this point, bet = see (*) above)


i think the answer is obvious but i cannot help if = you insist the latter is simpler. ;-)
 


   So any argument to the effect that "MAP-E|T does X and 4rd = doesn't"
   is empty. This is expected, it's a compromise.

some arguments are about "MAP-E|T doesn't make a confusing Y but 4rd
does". sorry this is not expected.

I believe it's also a compromise. You lose some simplicity, you gain a = single protocol.

your above: = "simplifying the protocol"; here: "you lose some simplicity". ??? have = you admitted that the 4rd is less simple??

4rd may be viewed =  IMHO as less simple than MAP-E alone, but it shouldn't be ignored = that it does largely more. To take just  one feature, independently = of those of MAP-T, 4rd BRs forward IPv4 packets on the fly, while the = MAP-E specification says "If the packet is fragmented, BR should = reassemble the packet". This is significant for scalability and for = propagation delays.
=
 
 
anot= her topic of discussion. i have little exploration on this and i have no = right to argue.
 
 


   The argument should be: "I need 4rd to do X because = ..."

well, what is the X then? if the X is only "the number of protocol =3D
= 1"... we may have a lot of ways to achieve it without the need of
excluding any so-called *edge* cases, without the need of = introducing
any ugly behavior with the excuse of "compromise".

encapsulation and translation have been the cases of loss-and-gain
compromises. do we need the third?

For example: I need 4rd to support TTL preservation for value 64 because = I'm using routing protocol XYZ which needs = it.

well, ttl 254, 253, 252, 251, = 250, etc... are often used for eBGP multihop. 
ttl 64 are sometimes used in our application facility for internal = web = service.

Fine.
But = which example would you have where these values would be a problem with = 4rd (knowing that any network decreases such values by the number of = traversed routers).
 
 
surely, = when i think my packets traverse your domain as tunneled, and my = customer networks contains 2 hops, i may set 252 for the valid minimum = ttl. however, 4rd makes the decrement and i will lose this packet. which = is unexpected. the value of 255 and 254 is essentially the same but 4rd = forces people have to treat them differently. and then you tell me = "4rd-tunneling" is not a commonly understood "tunnel", i get the = knowledge and i may follow 4rd's semantics. but i need to think = differently when i come back to the normal world.
 
fine but costy. if it is worth, just for the gain = of a single specification? (very subjective, isn't = it?)
 
i think the problems has been much = discussed. further debate may become too philosophical. let me make = the commentary updated, to reflect the significant changes between = the final two versions, and you may polish the 4rd = specification further. my task is simple: to prevent the authors missing = to note the changes of semantics different from our most = popular understanding. the judgement on the impact might be = subjective and the commentary won't focus on that.
 
thanks for patience, =
maoke
 
 
 

<= br>
Regards,
RD




 

That's would be a real, justified use case. Otherwise it's just = theory. 

you may directly say = encapsulation doing a lot things only significant in theory. but the = reality is not so. i also suggest we, moderately, not to argue something = is only a theory just because we haven't known it is really happening = somewhere unknown to us. 

thanks and = regards,
maoe
 


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

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



= --Apple-Mail-6--252156154-- From ichiroumakino@gmail.com Mon Jun 4 11:06: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 16B6921F863C for ; Mon, 4 Jun 2012 11:06:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM+ACswfSiQa for ; Mon, 4 Jun 2012 11:06:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C33A821F862A for ; Mon, 4 Jun 2012 11:06:37 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1355567eaa.31 for ; Mon, 04 Jun 2012 11:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cqZl78s25tw1m4ut42TkGnwVNjX1MONzRZRohq7b46A=; b=MHHzalhjLwLcR82rIHiLocz49UClTRAKbN3DgFL5vbD4Wjesza0hU3m0A8dww35gmg LkLl+u6jX0NlJPJoY8puU8iwbByG2bATZx38BFLeHE1/11WOKPdVIVhg4yv+C4kzsvGZ saA02Wql6AlSU5r9LEte8jp7tErCst7R4hOKcXvcoSUhyKOE082EhTInFJ5V+fLwRm6E Yr4sxKcCYF55/Rx9vMj9BNlHjpsH3lI181DG3J9psQG/ZgZcFiq3T8ao41xAFLl4hSnG 5do51Y+WXrMmKw3jx8XwP6EZVNLP5qRrjBESuLH67M5bIe6XAK8IQbhB73URN7m8g5qd pvfg== Received: by 10.14.22.12 with SMTP id s12mr5533508ees.213.1338833194572; Mon, 04 Jun 2012 11:06:34 -0700 (PDT) Received: from dhcp-10-61-99-132.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e45sm39879258eeb.6.2012.06.04.11.06.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 11:06:33 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 4 Jun 2012 20:06:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1278) Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 04 Jun 2012 18:06:39 -0000 Yiu, > AFAIK, this will couple the IPv4 address and IPv6 prefix. This isn't = the > requirement for Public 4over6. with MAP you may embed parts of the IPv4 address into the IPv6 prefix = and optionally a PSID. the remaining bits are provisioned with DHCP (or something else). how = many bits you embed and how many bits you provision are an operational = choice. if you move those levers to the end, with no embedded bits, with all = bits provisioned, then you effectively have Public 4over6. no dependency = between IPv4 and IPv6, as the IPV4 address is provisioned in the MAP = DHCP option, independent of the IPv6 end user prefix. this implies one = mapping rule or domain per tunnel (same amount of state as public 4over6 = of course). is that still MAP, given that you don't have address mapping anymore? = well, who knows, but my point was that you can achieve Public 4over6 = with MAP. I didn't intend to put a spanner in the works of Public 4over6. it just = occurred to me as I was looking at Public and Lightweight 4over6, as = extensions to DS-lite. that we're basically talking about the exact same = thing. the differences between the solutions, when we're talking about = the hub and spoke 1:1 case (independence between IPv4 and IPv6 = addresses), is how they are provisioned. MAP, DS-lite, Lightweight = 4over6 and Public 4over6 are all equal when it comes to the amount of = state on both sides as well as the bits on the wire. do we want 3-4 'point' mechanisms specified separately or do we want one = mechanisms with multiple 'modes'? cheers, Ole >>>> public 4over6 is exactly the same as MAP in hub and spoke mode with >>>> one mapping rule per subscriber. >>>=20 >>> Could you clarify how this relates to the MAP-rule definition saying >>> "Each MAP node in the domain has the same set of rules". >>> (draft-mdt-softwire-mapping-address-and-port-03) >>=20 >> you can look at it as if each subscriber has his own MAP domain. >>=20 >> cheers, >> Ole >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From jacni@jacni.com Mon Jun 4 19:13: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 369FA11E80C2 for ; Mon, 4 Jun 2012 19:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKo9zoBv1OG0 for ; Mon, 4 Jun 2012 19:13:56 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id B07BB21F8604 for ; Mon, 4 Jun 2012 19:13:56 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 2CF8F38009A for ; Mon, 4 Jun 2012 22:13:55 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id D1E0E3400E5 for ; Tue, 5 Jun 2012 10:13:53 +0800 (CST) Received: from [10.140.20.56] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJBbf4dga81PPggoAQ--.33506S2; Tue, 05 Jun 2012 10:13:53 +0800 (CST) Message-ID: <4FCD6B5E.3060408@jacni.com> Date: Tue, 05 Jun 2012 10:13:50 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Simon Perreault References: <4FC38782.8020207@viagenie.ca> In-Reply-To: <4FC38782.8020207@viagenie.ca> Content-Type: multipart/alternative; boundary="------------090109020801010609030101" X-CM-TRANSID: +AWowJBbf4dga81PPggoAQ--.33506S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKw1xWFykAr18AFWkXFyftFb_yoWktFcE9w 40yF40yw4DGr12qw4xKFZxXrsrArZ5X343Z345Kw15K348tan8Jr92gas3Z3WfJrWxtFn8 KrnxWryrWw12gjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ-t7k0a2IF6FyUM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_ Wr0E3s1lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcV AKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI 7VAKI48JMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43 ZEXa7IU0_Ma5UUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQIJEko7lRKZDABPs0 Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 05 Jun 2012 02:13:57 -0000 This is a multi-part message in MIME format. --------------090109020801010609030101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi simon, Sorry for the late reply, please see below, On 5/28/2012 Monday 10:11 PM, Simon Perreault wrote: > On 2012-05-27 10:34, Yong Cui wrote: >> This is a wg last call on draft-ietf-softwire-dslite-multicast-02. > > Section 6.1 introduces IGMP/MLD translation, but I fear it is very > underspecified. Our own effort at specifying IGMP/MLD translation is > in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite > multicast would be better served by referencing our draft instead. > Thanks for your comments, while as stated in the text, the Interworking function is a combination of proxying (RFC4605) and translation (draft-ietf-mboned-64-multicast-address-format, sorry the reference was lost, we'll fix it). The implementations vary, and we are trying to avoid deeply diving into that since it is sufficient for the implementers, and those should be detailed in some deployment document if needed. Anyway, please list what you think is missing, we can add more text to further clarify it. Thanks a lot! Cheers, Jacni > So I would suggest replacing section 6.1 by a reference to the draft > above, which we hope to have adopted in the PIM WG shortly. > > Thanks, > Simon --------------090109020801010609030101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi simon,

Sorry for the late reply, please see below,

On 5/28/2012 Monday 10:11 PM, Simon Perreault wrote:
On 2012-05-27 10:34, Yong Cui wrote:
This is a wg last call on draft-ietf-softwire-dslite-multicast-02.

Section 6.1 introduces IGMP/MLD translation, but I fear it is very underspecified. Our own effort at specifying IGMP/MLD translation is in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite multicast would be better served by referencing our draft instead.

Thanks for your comments, while as stated in the text, the Interworking function is a combination of proxying (RFC4605) and translation (draft-ietf-mboned-64-multicast-address-format, sorry the reference was lost, we'll fix it).
The implementations vary, and we are trying to avoid deeply diving into that since it is sufficient for the implementers, and those should be detailed in some deployment document if needed. Anyway, please list what you think is missing, we can add more text to further clarify it. Thanks a lot!


Cheers,
Jacni

So I would suggest replacing section 6.1 by a reference to the draft above, which we hope to have adopted in the PIM WG shortly.

Thanks,
Simon
--------------090109020801010609030101-- From maxpassion@gmail.com Tue Jun 5 01:49: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 D0BA821F86B2 for ; Tue, 5 Jun 2012 01:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLXyvLbQb5sS for ; Tue, 5 Jun 2012 01:49:27 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 841D221F86A8 for ; Tue, 5 Jun 2012 01:49:27 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so74952obb.31 for ; Tue, 05 Jun 2012 01:49:26 -0700 (PDT) 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=Vf7cO1Kj7M0SGgdcqD+w0nSEHSwcCqU0bD9L2yz+/tE=; b=xT2mrlFm2QH8YFzlmwhCKngkXkCe58v5m9ugRBspG9o2W1/OAqQ6EzhwXqNLg1uAbd 7Qty/IQyjtnLTzxNwYWpm85zgQUe07sMzmKOkX6saV3HMDoJ3FWGGaIrxENTfzV0QYNr AKg/We7NGDUF5DRreCnpynl+/s9PK+AuaL3g8Wrjl1reDpW6i7cvzNYEfOJOOW4NCMxd GqxoYyDwpwSUJoIxLZrtLPyl8CTJ842wlPRbinOBIZ+L/ittN0/pfXsWPTe2S8Crse3w BAw3wfxplQHmAaVv1t1XF6NYphIZigtf9GP/56yfWlvFcesFXqwMw8ZnbU6zeiexnQeU IpGw== MIME-Version: 1.0 Received: by 10.60.171.135 with SMTP id au7mr14883847oec.62.1338886166817; Tue, 05 Jun 2012 01:49:26 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Tue, 5 Jun 2012 01:49:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 16:49:26 +0800 Message-ID: From: liu dapeng To: Yong Cui Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 05 Jun 2012 08:49:29 -0000 Hello all, I am not sure this version resolves my concerns regarding the possible misleading by the word "stateless". To avoid this misleading, I suggest the following changes: 1. Change the title to "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions". Since this document is mainly about carrier-side stateless, the new title is more precise to reflect the content of this document. 2. Add a subsection in introduction, clarify that this document is only about carrier side stateless. I would like to support it if the document was updated accordingly. Thanks, Best regards, Dapeng Liu 2012/5/27, Yong Cui : > Hi folks, > > This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01. > http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio > n/ > > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. > > This wg last call will end on 2012 June 10 at 12pm EDT. > > > Yong & Alain > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- ------ Best Regards, Dapeng Liu From simon.perreault@viagenie.ca Tue Jun 5 06: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 3A01B21F85B5 for ; Tue, 5 Jun 2012 06:09:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpz4oX6DGbsa for ; Tue, 5 Jun 2012 06:09:49 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E793021F8604 for ; Tue, 5 Jun 2012 06:09:48 -0700 (PDT) Received: from [192.168.0.100] (modemcable099.192-131-66.mc.videotron.ca [66.131.192.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1F4B74008D; Tue, 5 Jun 2012 09:09:48 -0400 (EDT) Message-ID: <4FCE051B.3060003@viagenie.ca> Date: Tue, 05 Jun 2012 09:09:47 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jacni Qin References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> In-Reply-To: <4FCD6B5E.3060408@jacni.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 05 Jun 2012 13:09:50 -0000 On 2012-06-04 22:13, Jacni Qin wrote: >> Section 6.1 introduces IGMP/MLD translation, but I fear it is very >> underspecified. Our own effort at specifying IGMP/MLD translation is >> in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite >> multicast would be better served by referencing our draft instead. >> > Thanks for your comments, while as stated in the text, the Interworking > function is a combination of proxying (RFC4605) and translation > (draft-ietf-mboned-64-multicast-address-format, sorry the reference was > lost, we'll fix it). I understand that. But note that this is an important new function. AFAIK IGMP/MLD translation doesn't exist in any other RFC. Your draft would be underspecifying it IMHO, possibly leading to interoperability issues. I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation. > The implementations vary, and we are trying to avoid deeply diving into > that since it is sufficient for the implementers, and those should be > detailed in some deployment document if needed. Anyway, please list what > you think is missing, we can add more text to further clarify it. Thanks > a lot! At IETF 83 I showed this list to the PIM working group to demonstrate that IGMP/MLD translation is not as simple as people think it is. It's a list of things our draft (draft-perreault-mboned-igmp-mld-translation) specifies: - Well-known multicast address equivalences between IPv4 and IPv6. - Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}. - Translation needs to be performed logically on upstream interface of proxy so as not to mess with Querier elections. - Router Alert - IPv4 option ↔ Hop-by-Hop IPv6 extension header - Send on output IFF it was received on input. - Set value to zero unconditionally. - Reports with unspecified source address need to be handled differently for IGMP vs MLD. - Allocation of a “Translated†bit in IGMPv3 and MLDv2 Queries and Reports. - Formulas for the conversion of MRD↔MRT with or without loss of precision. - Preservation of Additional and Auxiliary Data. - MTU considerations... sigh - Data plane handled according to RFC6145. I don't want to argue this list in SOFTWIRE because I think it's the wrong forum. My point is that IGMP/MLD translation needs to be correctly specified, and it needs to be done in PIM. Any SOFTWIRE protocol that requires IGMP/MLD translation needs to refer to something coming from PIM. 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 Wed Jun 6 06:43: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 03EFD21F8855 for ; Wed, 6 Jun 2012 06:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMUzNEorTiH3 for ; Wed, 6 Jun 2012 06:43:27 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id CB82E21F8547 for ; Wed, 6 Jun 2012 06:43:26 -0700 (PDT) Received: by qabj40 with SMTP id j40so3493678qab.15 for ; Wed, 06 Jun 2012 06:43:26 -0700 (PDT) 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=KULgtCyQcV7WY55nW1N4o/JCIipALfkrOOF3phleUrg=; b=tJRKhnziozIscqszPAhiCdQt98EgMERpQapedUhompEQzyQN+BFRRZjt3+BIh+gcOU pxXHw4p3mtrkz1VijgpyMtoBvMHkHk9mlLMHa9DOg61Dpkc7daRGyXpJxl4j28CFsI8Y CWGA9NzixQ204BO+gpPewNbSmIXy33vLNO/boNw9lgaZj+l1a6nHH+HLwuMns8disk+l A+4L13/7uEZCFOyijP/te9BpknNpk8YMbXLH2Xs0VeCe6ogA06ncUdyAUyyo2xkXSp38 7/2aNq7skGDGXt1aTSs6rykQk9t6Q9JtEpuzORXkir9ZqjuRsBFSMTtq5ww0rJTDX9ZW EUvA== MIME-Version: 1.0 Received: by 10.224.108.129 with SMTP id f1mr21998741qap.53.1338990206302; Wed, 06 Jun 2012 06:43:26 -0700 (PDT) Received: by 10.229.236.196 with HTTP; Wed, 6 Jun 2012 06:43:26 -0700 (PDT) In-Reply-To: <4FCE051B.3060003@viagenie.ca> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> Date: Wed, 6 Jun 2012 15:43:26 +0200 Message-ID: From: Wojciech Dec To: Simon Perreault Content-Type: multipart/alternative; boundary=20cf3074b37e9ab86504c1cdf39b Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 06 Jun 2012 13:43:28 -0000 --20cf3074b37e9ab86504c1cdf39b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 The IGMP/MLD translation is the key piece of this draft and needs to be thorough. In addition a general observation: This draft appears to have very little in common with DS-Lite (nothing except use of IPinIP on my reading), and using that reference and the AFTR terms is confusing. The fact that technically it features an address family mapped multicast transport, which alongside with the IGMP/MLD translation makes it anything but transparent tunneling. A change of title would be also useful, as well as general decoupling from the ds-lite architecture: The mAFTR device can, and likely will be a often a dedicated multicast device that plays no part in unicast forwarding. -Woj. On 5 June 2012 15:09, Simon Perreault wrote: > On 2012-06-04 22:13, Jacni Qin wrote: > >> Section 6.1 introduces IGMP/MLD translation, but I fear it is very >>> underspecified. Our own effort at specifying IGMP/MLD translation is >>> in draft-perreault-mboned-igmp-**mld-translation. I feel that DS-Lite >>> multicast would be better served by referencing our draft instead. >>> >>> Thanks for your comments, while as stated in the text, the Interworkin= g >> function is a combination of proxying (RFC4605) and translation >> (draft-ietf-mboned-64-**multicast-address-format, sorry the reference wa= s >> lost, we'll fix it). >> > > I understand that. But note that this is an important new function. AFAIK > IGMP/MLD translation doesn't exist in any other RFC. Your draft would be > underspecifying it IMHO, possibly leading to interoperability issues. > > I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation. > > > The implementations vary, and we are trying to avoid deeply diving into >> that since it is sufficient for the implementers, and those should be >> detailed in some deployment document if needed. Anyway, please list what >> you think is missing, we can add more text to further clarify it. Thanks >> a lot! >> > > At IETF 83 I showed this list to the PIM working group to demonstrate tha= t > IGMP/MLD translation is not as simple as people think it is. It's a list = of > things our draft (draft-perreault-mboned-igmp-**mld-translation) > specifies: > > - Well-known multicast address equivalences between IPv4 and IPv6. > - Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}. > - Translation needs to be performed logically on upstream interface of > proxy so as not to mess with Querier elections. > - Router Alert > - IPv4 option =E2=86=94 Hop-by-Hop IPv6 extension header > - Send on output IFF it was received on input. > - Set value to zero unconditionally. > - Reports with unspecified source address need to be handled differently > for IGMP vs MLD. > - Allocation of a =E2=80=9CTranslated=E2=80=9D bit in IGMPv3 and MLDv2 Qu= eries and Reports. > - Formulas for the conversion of MRD=E2=86=94MRT with or without loss of = precision. > - Preservation of Additional and Auxiliary Data. > - MTU considerations... sigh > - Data plane handled according to RFC6145. > > I don't want to argue this list in SOFTWIRE because I think it's the wron= g > forum. My point is that IGMP/MLD translation needs to be correctly > specified, and it needs to be done in PIM. Any SOFTWIRE protocol that > requires IGMP/MLD translation needs to refer to something coming from PIM= . > > > 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 > ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > --20cf3074b37e9ab86504c1cdf39b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1
The IGMP/MLD translation is the key piece of this draft and needs to= be thorough.

In addition a general observation: This draft appears = to have very little in common with DS-Lite (nothing except use of IPinIP on= my reading), and using that reference and the AFTR terms is confusing. The= fact that technically it features an address family mapped multicast trans= port, which alongside with the IGMP/MLD translation makes it anything but t= ransparent tunneling. A change of title would be also useful, as well as ge= neral decoupling from the ds-lite architecture: The mAFTR device can, and l= ikely will be a often a dedicated multicast device that plays no part in un= icast forwarding.

-Woj.

On 5 June 2012 15:09, Simon Per= reault <simon.perreault@viagenie.ca> wrote:
On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite<= br> multicast would be better served by referencing our draft instead.

Thanks for your comments, while as stated in the text, the Interworking
function is a combination of proxying (RFC4605) and translation
(draft-ietf-mboned-64-multicast-address-format, sorry the reference = was
lost, we'll fix it).

I understand that. But note that this is an important new function. AFAIK I= GMP/MLD translation doesn't exist in any other RFC. Your draft would be= underspecifying it IMHO, possibly leading to interoperability issues.

I don't think it's up to SOFTWIRE to standardize IGMP/MLD translati= on.


The implementations vary, and we are trying to avoid deeply diving into
that since it is sufficient for the implementers, and those should be
detailed in some deployment document if needed. Anyway, please list what you think is missing, we can add more text to further clarify it. Thanks a lot!

At IETF 83 I showed this list to the PIM working group to demonstrate that = IGMP/MLD translation is not as simple as people think it is. It's a lis= t of things our draft (draft-perreault-mboned-igmp-mld-translation) = specifies:

- Well-known multicast address equivalences between IPv4 and IPv6.
- Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}.
- Translation needs to be performed logically on upstream interface of prox= y so as not to mess with Querier elections.
- Router Alert
=C2=A0- IPv4 option =E2=86=94 Hop-by-Hop IPv6 extension header
=C2=A0- Send on output IFF it was received on input.
=C2=A0- Set value to zero unconditionally.
- Reports with unspecified source address need to be handled differently fo= r IGMP vs MLD.
- Allocation of a =E2=80=9CTranslated=E2=80=9D bit in IGMPv3 and MLDv2 Quer= ies and Reports.
- Formulas for the conversion of MRD=E2=86=94MRT with or without loss of pr= ecision.
- Preservation of Additional and Auxiliary Data.
- MTU considerations... sigh
- Data plane handled according to RFC6145.

I don't want to argue this list in SOFTWIRE because I think it's th= e wrong forum. My point is that IGMP/MLD translation needs to be correctly = specified, and it needs to be done in PIM. Any SOFTWIRE protocol that requi= res IGMP/MLD translation needs to refer to something coming from PIM.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074b37e9ab86504c1cdf39b-- From sarikaya2012@gmail.com Wed Jun 6 09:26:07 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 F31C621F8735 for ; Wed, 6 Jun 2012 09:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2eCYsG3owEH for ; Wed, 6 Jun 2012 09:26:06 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41B3F21F85B8 for ; Wed, 6 Jun 2012 09:26:06 -0700 (PDT) Received: by yhq56 with SMTP id 56so5647905yhq.31 for ; Wed, 06 Jun 2012 09:26:05 -0700 (PDT) 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=2Ph+mXkgricKEkTf+BSVpeu5zXqER9EL3VGyO586ye0=; b=yrxLfEHdp01dPI94FsDKGB2dmjQKawq12Cvc6OXGpDQauzvvMS7QdSi7vJjIVzX8li pYDmI7AJkZfVsAEyFHrWM0cYyEcaI3/eTi8GwY/FUJl57fTt1DtUsIDD3sWkUMKrPrCI u1BGI+kyZ32gXt9GF8jiqCE8Wne02qx4qRbyQHTYfY8oFRDo83C53usb02mdeluZMPAn D9Duyf/Y391IUjKZYQGxd8r56sL8dYSPj18Fvs7ELZfNhcPfyqGqkOcXtjAGlkRJBS9k WpPXK+TdNZVWXz5yAc6sGtbpNp4zaO4PYTPXbVqGhaXzHvx/xcqsVvbP+bKAI0Pk4kMA mJMg== MIME-Version: 1.0 Received: by 10.50.159.135 with SMTP id xc7mr7444855igb.9.1338999963898; Wed, 06 Jun 2012 09:26:03 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Wed, 6 Jun 2012 09:26:03 -0700 (PDT) In-Reply-To: References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> Date: Wed, 6 Jun 2012 11:26:03 -0500 Message-ID: From: Behcet Sarikaya To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 06 Jun 2012 16:26:07 -0000 On Wed, Jun 6, 2012 at 8:43 AM, Wojciech Dec wrote: > +1 > The IGMP/MLD translation is the key piece of this draft and needs to be > thorough. > > In addition a general observation: This draft appears to have very little in > common with DS-Lite (nothing except use of IPinIP on my reading), and using > that reference and the AFTR terms is confusing. The fact that technically it > features an address family mapped multicast transport, which alongside with > the IGMP/MLD translation makes it anything but transparent tunneling. A > change of title would be also useful, as well as general decoupling from the > ds-lite architecture: The mAFTR device can, and likely will be a often a > dedicated multicast device that plays no part in unicast forwarding. > You mean, in order to be DS-Lite related it has to be tunneling based? Actually, I did have a draft with such a solution. Some people argued that we should not go for a tunneling solution because there is already an inherent tunneling. So this draft was chosen as the solution approach. The philosophical question here is why do we have DS-Lite which does tunneling on top of the inherent tunnel? Behcet From bingxuere@gmail.com Thu Jun 7 01:18: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 D597C21F85AA for ; Thu, 7 Jun 2012 01:18:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3QEBOK0HVTw for ; Thu, 7 Jun 2012 01:18:38 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59AE921F855B for ; Thu, 7 Jun 2012 01:18:38 -0700 (PDT) Received: by ghbg16 with SMTP id g16so227542ghb.31 for ; Thu, 07 Jun 2012 01:18:38 -0700 (PDT) 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=PbbqR0B63iAh9J+2acnulhLTDjA9+cqtJjgya3W4kZc=; b=jK0EW3BGlImSR2q5UOYQh6DxvkssDOxkKjRNsNk5QbEufqUcAHAPk3hpal2C6aeUH0 /Q5fdThfhzfx/J2gQPWIxBK3GbEt+sXAKbeg9namA4T901tqIpA9l8WfKqW+kYGZG2a2 DJ+ESAa90AdmJiRpCSSgZXgREfytByxWL1SVkt/YGhy/R/oI2O9SJfz93sAU5Taj1g8X 1gwxenW+HT4wjHCq/PHIce6QzKIbGrFNH6nRlqUMBW9C7mCT7zEUHruMNk9e4SvSUV7F 3Q2zSC22Ranp+cruMOG5a12hgBTZh8Y7kk+iSW+080MeOs2S1jMbDTLmKQV1EooC2mxx LQ+g== Received: by 10.60.171.135 with SMTP id au7mr1092626oec.62.1339057117818; Thu, 07 Jun 2012 01:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.12.35 with HTTP; Thu, 7 Jun 2012 01:17:57 -0700 (PDT) In-Reply-To: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> From: Qiong Date: Thu, 7 Jun 2012 16:17:57 +0800 Message-ID: To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=bcaec55405a6d76e4504c1dd87a3 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 07 Jun 2012 08:18:40 -0000 --bcaec55405a6d76e4504c1dd87a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole, >From the draft-ietf-softwire-stateless-4v6-motivation, the definition of "Stateless 4/6 solution" is as follows: Stateless 4/6 solution denotes a solution which does not require any per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. I think it clearly explained the motivation of MAP and 4rd, and this is what we are seeking for in the design of any stateless solution. If public 4over6 is one extreme case of MAP, in which one subscriber represents one MAP domain, then should we also say that DS-Lite is another extreme case of MAP, where one application (session) represents one MAP domain ? I think we should still keep the initial feature of these solutions. Best wishes Qiong On Tue, Jun 5, 2012 at 2:06 AM, Ole Tr=C3=B8an wrote= : > Yiu, > > > AFAIK, this will couple the IPv4 address and IPv6 prefix. This isn't th= e > > requirement for Public 4over6. > > with MAP you may embed parts of the IPv4 address into the IPv6 prefix and > optionally a PSID. > the remaining bits are provisioned with DHCP (or something else). how man= y > bits you embed and how many bits you provision are an operational choice. > > if you move those levers to the end, with no embedded bits, with all bits > provisioned, then you effectively have Public 4over6. no dependency betwe= en > IPv4 and IPv6, as the IPV4 address is provisioned in the MAP DHCP option, > independent of the IPv6 end user prefix. this implies one mapping rule or > domain per tunnel (same amount of state as public 4over6 of course). > > is that still MAP, given that you don't have address mapping anymore? > well, who knows, but my point was that you can achieve Public 4over6 with > MAP. > > I didn't intend to put a spanner in the works of Public 4over6. it just > occurred to me as I was looking at Public and Lightweight 4over6, as > extensions to DS-lite. that we're basically talking about the exact same > thing. the differences between the solutions, when we're talking about th= e > hub and spoke 1:1 case (independence between IPv4 and IPv6 addresses), is > how they are provisioned. MAP, DS-lite, Lightweight 4over6 and Public > 4over6 are all equal when it comes to the amount of state on both sides a= s > well as the bits on the wire. > > do we want 3-4 'point' mechanisms specified separately or do we want one > mechanisms with multiple 'modes'? > > cheers, > Ole > > >>>> public 4over6 is exactly the same as MAP in hub and spoke mode with > >>>> one mapping rule per subscriber. > >>> > >>> Could you clarify how this relates to the MAP-rule definition saying > >>> "Each MAP node in the domain has the same set of rules". > >>> (draft-mdt-softwire-mapping-address-and-port-03) > >> > >> you can look at it as if each subscriber has his own MAP domain. > >> > >> 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 > --bcaec55405a6d76e4504c1dd87a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole,

From the draft-ietf-softwire-stateless-4v6-motivation, the d= efinition of "Stateless 4/6 solution" is as follows:

State= less 4/6 solution denotes a solution which does not require any per-user st= ate (see Section 2.3 of [RFC1958]) to be maintained by any IP address shari= ng function in the Service Provider's network. This category of solutio= ns assumes a dependency between an IPv6 prefix and IPv4 address.

I think it clearly explained the motivation of MAP and 4rd, and this is= what we are seeking for in the design of any stateless solution.

If= public 4over6 is one extreme case of MAP, in which one subscriber represen= ts one MAP domain, then should we also say that DS-Lite is another extreme = case of MAP, where one application (session) represents one MAP domain ?=C2= =A0

I think we should still keep the initial feature of these solutions.
Best wishes
Qiong

On Tue, Jun 5, = 2012 at 2:06 AM, Ole Tr=C3=B8an <otroan@employees.org> wr= ote:
Yiu,

> AFAIK, this will couple the IPv4 address and IPv6 prefix. This isn'= ;t the
> requirement for Public 4over6.

with MAP you may embed parts of the IPv4 address into the IPv6 prefix= and optionally a PSID.
the remaining bits are provisioned with DHCP (or something else). how many = bits you embed and how many bits you provision are an operational choice.
if you move those levers to the end, with no embedded bits, with all bits p= rovisioned, then you effectively have Public 4over6. no dependency between = IPv4 and IPv6, as the IPV4 address is provisioned in the MAP DHCP option, i= ndependent of the IPv6 end user prefix. this implies one mapping rule or do= main per tunnel (same amount of state as public 4over6 of course).

is that still MAP, given that you don't have address mapping anymore? w= ell, who knows, but my point was that you can achieve Public 4over6 with MA= P.

I didn't intend to put a spanner in the works of Public 4over6. it just= occurred to me as I was looking at Public and Lightweight 4over6, as exten= sions to DS-lite. that we're basically talking about the exact same thi= ng. the differences between the solutions, when we're talking about the= hub and spoke 1:1 case (independence between IPv4 and IPv6 addresses), is = how they are provisioned. MAP, DS-lite, Lightweight 4over6 and Public 4over= 6 are all equal when it comes to the amount of state on both sides as well = as the bits on the wire.

do we want 3-4 'point' mechanisms specified separately or do we wan= t one mechanisms with multiple 'modes'?

cheers,
Ole

>>>> public 4over6 is exactly the same as MAP in hub and spoke = mode with
>>>> one mapping rule per subscriber.
>>>
>>> Could you clarify how this relates to the MAP-rule definition = saying
>>> "Each MAP node in the domain has the same set of rules&qu= ot;.
>>> (draft-mdt-softwire-mapping-address-and-port-03)
>>
>> you can look at it as if each subscriber has his own MAP domain. >>
>> 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

--bcaec55405a6d76e4504c1dd87a3-- From ichiroumakino@gmail.com Thu Jun 7 01:49: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 9623F21F8751 for ; Thu, 7 Jun 2012 01:49:03 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6R2r76GiuVq for ; Thu, 7 Jun 2012 01:49:03 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E188521F85D5 for ; Thu, 7 Jun 2012 01:49:02 -0700 (PDT) Received: by eaaq13 with SMTP id q13so143710eaa.31 for ; Thu, 07 Jun 2012 01:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uf9MfQZlVR8icNaiZHg3ULcvyjKNJ1J2xVunyR7P1cY=; b=mSaufWJApcRO9g6vza1aNdBadd/3HdJCwLVHy1tE3rqF1DnRCf3pHQhH9lEOZwZV+M sscMXEa1mjSgfBkffDZctXRThVgX/tq4wSKS8J1Nx6SOgGL+Zn4wgjdHDOZf5W36K+KJ 7K4GwIJpbpHohlN+B/cFckUQeOmi3QbF3BEdUsAsbx/gSU8Wzhl2ONiadqxgmQxvrqXt bENW45f39n/m0CEyq5EEiuEf6MBUPbxZrc11ksFbjWjXSRI+NvgY8V0Mt76rCfOexlmH NdVFdvJ0PkOMHRSESmR/ozIaOrsBOPbhqpm12rvL0zpUFQgsxmLLa9/+egP3pLc1ROMY wpCg== Received: by 10.14.188.129 with SMTP id a1mr741378een.183.1339058941785; Thu, 07 Jun 2012 01:49:01 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id y54sm8329384eef.10.2012.06.07.01.49.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jun 2012 01:49:00 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 7 Jun 2012 10:48:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> To: Qiong X-Mailer: Apple Mail (2.1278) Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 07 Jun 2012 08:49:03 -0000 Qiong, > If public 4over6 is one extreme case of MAP, in which one subscriber = represents one MAP domain, then should we also say that DS-Lite is = another extreme case of MAP, where one application (session) represents = one MAP domain ? =20 a DS-lite AFTR could be represented by the combination of a MAP BR with = per subscriber rules combined with a NAT44. there is a reason we started = out calling MAP for "Stateless DS-lite". > I think we should still keep the initial feature of these solutions. all the proposed solutions, including DS-lite shares a large set of = commonalities. where the differences are more operational considerations = and deployment choices than technical differences. do we need a separate = protocol specification for each deployment choice? cheers, Ole From mohamed.boucadair@orange.com Thu Jun 7 04:50: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 9D72F21F87E8 for ; Thu, 7 Jun 2012 04:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-xEJar3W6Ba for ; Thu, 7 Jun 2012 04:50:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id A7BA821F87EC for ; Thu, 7 Jun 2012 04:50:20 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4E86222C64E; Thu, 7 Jun 2012 13:50:19 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3216E35C045; Thu, 7 Jun 2012 13:50:19 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 7 Jun 2012 13:50:19 +0200 From: To: liu dapeng , Yong Cui Date: Thu, 7 Jun 2012 13:50:18 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Thread-Index: Ac1C+CGKJnIH72FwSBq9DxiThugI8wBqtGhw Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.6.7.110315 Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 07 Jun 2012 11:50:21 -0000 Dear Dapeng, 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 liu dapeng >Envoy=E9 : mardi 5 juin 2012 10:49 >=C0 : Yong Cui >Cc : softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-stateless-4v6-motivation-01 > >Hello all, > >I am not sure this version resolves my concerns regarding the possible >misleading by the word "stateless". To avoid this misleading, I >suggest the following changes: > >1. Change the title to "Motivations for Carrier-side Stateless IPv4 >over IPv6 Migration Solutions". Since this document is mainly about >carrier-side stateless, the new title is more precise to reflect the >content of this document. Med: Done. I updated my local copy with the proposed title. > >2. Add a subsection in introduction, clarify that this document is >only about carrier side stateless. Med: We have already this text in the introduction:=20 Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a se= ntence you want to be added to the introduction. > >I would like to support it if the document was updated accordingly. > Thanks. From mohamed.boucadair@orange.com Thu Jun 7 05:51:10 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 A2F9821F86F6 for ; Thu, 7 Jun 2012 05:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtmUfu-R1qnR for ; Thu, 7 Jun 2012 05:51:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8171E21F8658 for ; Thu, 7 Jun 2012 05:51:06 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 2B63C2DC57F; Thu, 7 Jun 2012 14:51:05 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 102254C017; Thu, 7 Jun 2012 14:51:05 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 7 Jun 2012 14:51:04 +0200 From: To: Simon Perreault , Yong Cui Date: Thu, 7 Jun 2012 14:51:03 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac0828YBgWSviS+LTd+Cmuq1sIIUjwH0ExIA Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> In-Reply-To: <4FC38782.8020207@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.5.24.112414 Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 07 Jun 2012 12:51:10 -0000 Hi Simon, We tried in this document to avoid as much as possible including implementa= tion details but instead we focused on the external behaviour of the interw= orking functions. Let me recall there are already available implementations= based on the specification of draft-ietf-softwire-dslite-multicast. A demo= has been organized in one of the previous IETF meetings. Now for your comment, we can see the IGMP/MLD IWF is basically RFC4605 + ad= dress translation (draft-ietf-mboned-64-multicast-address-format). Among th= e use cases of high priority identified in http://tools.ietf.org/html/draft= -ietf-mboned-v4v6-mcast-ps-00#section-3.6, the IGMP/MLD IWF is only require= d for the use case described in draft-ietf-softwire-dslite-multicast. As su= ch, does-it really make sense to have a dedicated document for the IGMP/MLD= IWF? Wouldn't be efficient to have this elaborated in draft-ietf-softwire-= dslite-multicast? I personally vote for the second option. Of course, if th= is approach is maintained, the document should be LCed also in PIM and MBON= ED. 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 : lundi 28 mai 2012 16:11 >=C0 : Yong Cui >Cc : softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-dslite-multicast-02 > >On 2012-05-27 10:34, Yong Cui wrote: >> This is a wg last call on draft-ietf-softwire-dslite-multicast-02. > >Section 6.1 introduces IGMP/MLD translation, but I fear it is very=20 >underspecified. Our own effort at specifying IGMP/MLD=20 >translation is in=20 >draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite=20 >multicast would be better served by referencing our draft instead. > >So I would suggest replacing section 6.1 by a reference to the draft=20 >above, which we hope to have adopted in the PIM WG shortly. > >Thanks, >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 Thu Jun 7 06:07:59 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 68E9621F881E for ; Thu, 7 Jun 2012 06:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND+kBmAup5Qq for ; Thu, 7 Jun 2012 06:07:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9ED21F8723 for ; Thu, 7 Jun 2012 06:07:58 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id F01602DC211; Thu, 7 Jun 2012 15:07:57 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id CCC5E27C07B; Thu, 7 Jun 2012 15:07:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 7 Jun 2012 15:07:55 +0200 From: To: Wojciech Dec , Simon Perreault Date: Thu, 7 Jun 2012 15:07:54 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1D6lzHfqOw3+hGRj+tjB/biOxycwAwdjQw Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> 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_94C682931C08B048B7A8645303FDC9F36E32ED1EABPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.7.120320 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 07 Jun 2012 13:07:59 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E32ED1EABPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, DS-Lite terminology is used in the sense that an IPv4 receiver is delivered= (IPv4) multicast content (from an IPv4 source) over an IPv6 network. The generic use case as described in http://tools.ietf.org/html/draft-ietf-= mboned-v4v6-mcast-ps-00#section-3.1 is called 4-6-4. I personally agree to = change the title to reflect this. The document does not make any assumption about the location of AFTR and mA= FTR: deployment considerations are out of scope. FWIW, mAFTR is defined as = follows: o Multicast AFTR (mAFTR): is a functional entity which supports IPv4-IPv6 multicast interworking function (refer to Figure 3). It receives and encapsulates the IPv4 multicast packets into IPv4-in- IPv6 packets and behaves as the corresponding IPv6 multicast source for the encapsulated IPv4-in-IPv6 packets. If you still think mAFTR terminology is confusing, we can change it to mBR = (for multicast Border Router), 64mBR (IPv6/IPv4 Multicast Border Router), m= IXF (multicast Interconnection Function), etc. Cheers, Med ________________________________ De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p= art de Wojciech Dec Envoy=E9 : mercredi 6 juin 2012 15:43 =C0 : Simon Perreault Cc : softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicas= t-02 In addition a general observation: This draft appears to have very little i= n common with DS-Lite (nothing except use of IPinIP on my reading), and usi= ng that reference and the AFTR terms is confusing. The fact that technicall= y it features an address family mapped multicast transport, which alongside= with the IGMP/MLD translation makes it anything but transparent tunneling.= A change of title would be also useful, as well as general decoupling from= the ds-lite architecture: The mAFTR device can, and likely will be a often= a dedicated multicast device that plays no part in unicast forwarding. -Woj. --_000_94C682931C08B048B7A8645303FDC9F36E32ED1EABPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Woj,
 
DS-Lite terminology is used in the sense that= an IPv4=20 receiver is delivered (IPv4) multicast content (from an IPv4 source) over a= n=20 IPv6 network.
 
The generic use case as described in=20 http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#secti= on-3.1 is=20 called 4-6-4. I personally agree to change the title to reflect this.=20
 
The document does not make any assumption abo= ut the=20 location of AFTR and mAFTR: deployment considerations are out of scope. FWI= W,=20 mAFTR is defined as follows:
   o  Multicast AFTR (mAFTR): is a functional =
entity which supports
      IPv4-IPv6 multicast interworking function (refer to Figure 3).  It
      receives and encapsulates the IPv4 multicast packets into IPv4-in-
      IPv6 packets and behaves as the corresponding IPv6 multicast
      source for the encapsulated IPv4-in-IPv6 packets.
If you still think mAFTR terminology is=
 confusing, we can change it to mBR (for multicast Border Router), 64mBR (I=
Pv6/IPv4 Multicast Border Router), mIXF (multicast Interconnection Function=
), etc. 
Cheers,
Med
=

De : softwires-bounces@ietf.org= =20 [mailto:softwires-bounces@ietf.org] De la part de Wojciech=20 Dec
Envoy=E9 : mercredi 6 juin 2012 15:43
=C0 := =20 Simon Perreault
Cc : softwires@ietf.org; Yong=20 Cui
Objet : Re: [Softwires] WG last call on=20 draft-ietf-softwire-dslite-multicast-02


In=20 addition a general observation: This draft appears to have very little in= =20 common with DS-Lite (nothing except use of IPinIP on my reading), and usi= ng=20 that reference and the AFTR terms is confusing. The fact that technically= it=20 features an address family mapped multicast transport, which alongside wi= th=20 the IGMP/MLD translation makes it anything but transparent tunneling. A c= hange=20 of title would be also useful, as well as general decoupling from the ds-= lite=20 architecture: The mAFTR device can, and likely will be a often a dedicate= d=20 multicast device that plays no part in unicast forwarding.=20

-Woj.
--_000_94C682931C08B048B7A8645303FDC9F36E32ED1EABPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Thu Jun 7 06:11:41 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 CEAC021F86FE for ; Thu, 7 Jun 2012 06:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q02BUdaw5ru2 for ; Thu, 7 Jun 2012 06:11:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4497921F885B for ; Thu, 7 Jun 2012 06:11:39 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9E9993B4377; Thu, 7 Jun 2012 15:11:36 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 70F7A23809B; Thu, 7 Jun 2012 15:11:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 7 Jun 2012 15:11:33 +0200 From: To: Reinaldo Penno , Sheng Jiang , Yong Cui , "softwires@ietf.org" Date: Thu, 7 Jun 2012 15:11:32 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Thread-Index: Ac08lhndt7T0oxVUQluBbvQnN2+HegIGIDBQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1EAF@PUEXCB1B.nanterre.francetelecom.fr> References: <5D36713D8A4E7348A7E10DF7437A4B921EE69DBF@szxeml545-mbx.china.huawei.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: 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.6.7.120320 Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 07 Jun 2012 13:11:41 -0000 Dear all, I agree with Reinaldo. IMHO it makes sense to merge the two documents: either draft-ietf-softwire-= public-4over6 be extended to cover draft-cui-softwire-b4-translated-ds-lite= or add one or two sentences to draft-cui-softwire-b4-translated-ds-lite to= mention a non-shared IPv4 address may be assigned. Doing so would help to rationalize the solution space and associated docume= nts. We have the following main flavours: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translate= d-ds-lite) All the three modes must support the ability to assign a full IPv4 address.= =20 Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Reinaldo Penno >Envoy=E9 : lundi 28 mai 2012 07:53 >=C0 : Sheng Jiang; Yong Cui; softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-public-4over6-01 > >-1=20 > >In which significant way this document is different from >http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- >lite-06 ? > >We can insert one paragraph in the above draft and allow=20 >public IPs since >NAT is optional. The two documents even use DHCPv4ov6 as provisioning. > >=20 > >On 5/27/12 6:32 PM, "Sheng Jiang" wrote: > >>The document looks mature for being advanced. >> >>Sheng Jiang >> >>> -----Original Message----- >>> From: softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] On >>> Behalf Of Yong Cui >>> Sent: Sunday, May 27, 2012 10:31 PM >>> To: softwires@ietf.org >>> Cc: Yong Cui >>> Subject: [Softwires] WG last call on=20 >draft-ietf-softwire-public-4over6- >>> 01 >>>=20 >>> Hi folks, >>>=20 >>> This is a wg last call on draft-ietf-softwire-public-4over6-01. >>> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >>>=20 >>> As usual, please send editorial comments to the authors and >>> substantive comments to the mailing list. >>>=20 >>> This wg last call will end on 2012 June 10 at 12pm EDT. >>>=20 >>>=20 >>> Yong & Alain >>>=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 > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From simon.perreault@viagenie.ca Thu Jun 7 06:47:25 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 8E14921F88C2 for ; Thu, 7 Jun 2012 06:47:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-J4Vu-kLOCu for ; Thu, 7 Jun 2012 06:47:24 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 9F56321F88C1 for ; Thu, 7 Jun 2012 06:47:24 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:b4da:23a8:649d:b10c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1505C4150E; Thu, 7 Jun 2012 09:47:22 -0400 (EDT) Message-ID: <4FD0B0E9.4020206@viagenie.ca> Date: Thu, 07 Jun 2012 09:47:21 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 07 Jun 2012 13:47:25 -0000 On 2012-06-07 08:51, mohamed.boucadair@orange.com wrote: > Among the use cases > of high priority identified in > http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.6, > the IGMP/MLD IWF is only required for the use case described in > draft-ietf-softwire-dslite-multicast. The DS-Lite case is one instance of the 4-6-4 use case where encapsulation is used. Another instance of the 4-6-4 use case makes use of translation instead. That is not covered by the softwire draft. The 6-4-6-4 use case is also high priority, requires IGMP/MLD translation, and is not covered by the softwire draft. So we're looking at at least three use cases of IGMP/MLD translation, possibly more, of which only one is covered by the softwire draft. > As such, does-it really make > sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be > efficient to have this elaborated in > draft-ietf-softwire-dslite-multicast? I personally vote for the > second option. Of course, if this approach is maintained, the > document should be LCed also in PIM and MBONED. I think IGMP/MLD translation should stand on its own for the reasons above, and it should be a PIM document. 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 Thu Jun 7 07:01: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 A264E21F88D9 for ; Thu, 7 Jun 2012 07:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N7ijELVgReQ for ; Thu, 7 Jun 2012 07:01:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DCC5C21F88D7 for ; Thu, 7 Jun 2012 07:01:20 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id BEC3B32473D; Thu, 7 Jun 2012 16:01:19 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 99BA235C08F; Thu, 7 Jun 2012 16:01:19 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 7 Jun 2012 16:00:39 +0200 From: To: Simon Perreault Date: Thu, 7 Jun 2012 16:00:37 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1EtD1ZCsN4Iw8yQpme0vCvPAjEHQAAESHQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> In-Reply-To: <4FD0B0E9.4020206@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.6.7.120320 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 07 Jun 2012 14:01:21 -0000 Re-, See inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 >Envoy=E9 : jeudi 7 juin 2012 15:47 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Yong Cui; softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-dslite-multicast-02 > >On 2012-06-07 08:51, mohamed.boucadair@orange.com wrote: >> Among the use cases >> of high priority identified in >>=20 >http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#s >ection-3.6, >> the IGMP/MLD IWF is only required for the use case described in >> draft-ietf-softwire-dslite-multicast. > >The DS-Lite case is one instance of the 4-6-4 use case where=20 >encapsulation is used. Another instance of the 4-6-4 use case=20 >makes use=20 >of translation instead. That is not covered by the softwire draft. Med: It was there; see http://tools.ietf.org/html/draft-ietf-softwire-dslit= e-multicast-00#appendix-A.1. I failed to find back why we removed it in -01= of the draft. BTW, this is not a diffrent use case, only the way data is h= andled differs. > >The 6-4-6-4 use case is also high priority, requires IGMP/MLD=20 >translation, and is not covered by the softwire draft. Med: I'm not sure there is a consenus about the urgency of 6-4-6-4 scenario= . I knwo there is an operator representative voicing for it, but I always f= ailed to understand that use case. > >So we're looking at at least three use cases of IGMP/MLD translation,=20 >possibly more, of which only one is covered by the softwire draft. Med: I failed to count the three use cases.. > >> As such, does-it really make >> sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be >> efficient to have this elaborated in >> draft-ietf-softwire-dslite-multicast? I personally vote for the >> second option. Of course, if this approach is maintained, the >> document should be LCed also in PIM and MBONED. > >I think IGMP/MLD translation should stand on its own for the reasons=20 >above, and it should be a PIM document. > Med: There is no PIM WG document to cite at this stage. What is wrong with= LCing this in PIM and MBONED?= From pengwu.thu@gmail.com Thu Jun 7 07:04:41 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 7EA5121F88B5 for ; Thu, 7 Jun 2012 07:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIQGw18QS-bf for ; Thu, 7 Jun 2012 07:04:41 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D89A021F8693 for ; Thu, 7 Jun 2012 07:04:40 -0700 (PDT) Received: by qcsq13 with SMTP id q13so378062qcs.31 for ; Thu, 07 Jun 2012 07:04:40 -0700 (PDT) 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:content-transfer-encoding; bh=ZoonZBxiqKkz7BK6kZca13EYjWSrSeiaTS+t6STBxuY=; b=rf+sFM8wzG7vYEtPH0AgtfwsRdilC5ZSoSfxIY2ecw1vu5CiSiXIQ+fIcj3Jj4ozJJ 4MgDbUDKn1forIYfrfWC8HtwoZHsz2e8eMDWGYs6nHdgUPFzfMx2UtNAgvp+5hu7xq1c Iux+OaWqQ5z2pv3CRAPX75EenG3/XLjWXLfVX9eDHwyHmA5jolzJlDTpkwhczp7MzKKK kwt6FmqHhJkkgLOfG54uwckyJXPHe3KfcaeET/F5uc15q5om4MxPeLHrXNPvlw7u+dZ7 GyndmeQK/Ys4kvsNt4bUvadRkVqJai2jKmMAs/w+AhZgbhAdGNeDZkjadEzc6mYXhPQS hxRA== MIME-Version: 1.0 Received: by 10.224.176.148 with SMTP id be20mr2879173qab.64.1339077880242; Thu, 07 Jun 2012 07:04:40 -0700 (PDT) Received: by 10.229.30.203 with HTTP; Thu, 7 Jun 2012 07:04:40 -0700 (PDT) In-Reply-To: <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> Date: Thu, 7 Jun 2012 22:04:40 +0800 Message-ID: From: Peng Wu To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 07 Jun 2012 14:04:41 -0000 Hi Ole and all, Thank you all for the discussions on this topic, as well as sharing your opinions during the offline discussions in the last couple of days. Let me try to summarize. I understand that we MAY adapt MAP to be 4over6-like, or even DS-lite with more changes. It's actually a very interesting proposal. However, in my understanding, the advantage of MAP is built on its statelessness, with of cost of v4-v6 address coupling. If we mandate MAP to further include the features of 4over6/DS-lite, we lose its original generality: it's no longer stateless, the motivation document won't work; GMA algorithm is no longer needed, no rule provisioning anymore; we enforce a big bindng table on MAP BR. These are somehow signifcant changes in implmentaton and deployement. Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, they have respective application scenarios, pros and cons. 1)stateless, 4rd, MAP 2)per-flow stateful: DS-Lite 3)per-user stateful: public 4over6, lightweight 4over6 As Ole said, the problem is that, do we want serveral simple mechanisms, or one super-compatible mechanism with different modes. Now Given that a) the WG has accomplished DS-lite; b)MAP follows the stateless motivation all along the way; c)The signifcant changes to make MAP super-compatible, I vote for we define the third type, per-user stateful mechanisms independently. Cheers, Peng On Thu, Jun 7, 2012 at 4:48 PM, Ole Tr=F8an wrote: > Qiong, > >> If public 4over6 is one extreme case of MAP, in which one subscriber rep= resents one MAP domain, then should we also say that DS-Lite is another ext= reme case of MAP, where one application (session) represents one MAP domain= ? > > a DS-lite AFTR could be represented by the combination of a MAP BR with p= er subscriber rules combined with a NAT44. there is a reason we started out= calling MAP for "Stateless DS-lite". > >> I think we should still keep the initial feature of these solutions. > > all the proposed solutions, including DS-lite shares a large set of commo= nalities. where the differences are more operational considerations and dep= loyment choices than technical differences. do we need a separate protocol = specification for each deployment choice? > > cheers, > Ole > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From simon.perreault@viagenie.ca Thu Jun 7 07:08: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 19DDA21F884C for ; Thu, 7 Jun 2012 07:08:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1N993x4xTUy for ; Thu, 7 Jun 2012 07:08:18 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7083721F884B for ; Thu, 7 Jun 2012 07:08:18 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:b4da:23a8:649d:b10c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AA71C4150E; Thu, 7 Jun 2012 10:08:17 -0400 (EDT) Message-ID: <4FD0B5D1.3060803@viagenie.ca> Date: Thu, 07 Jun 2012 10:08:17 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 07 Jun 2012 14:08:19 -0000 On 2012-06-07 10:00, mohamed.boucadair@orange.com wrote: > Med: There is no PIM WG document to cite at this stage. What is wrong with LCing this in PIM and MBONED? That could work. If PIM and MBONED say that this document is fine as it is, then that will settle it. 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 bingxuere@gmail.com Thu Jun 7 07:24: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 C859321F8908 for ; Thu, 7 Jun 2012 07:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IblGguBNR4kj for ; Thu, 7 Jun 2012 07:24:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E31921F88FB for ; Thu, 7 Jun 2012 07:24:21 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1236675obb.31 for ; Thu, 07 Jun 2012 07:24:20 -0700 (PDT) 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=lytzEvzfJ6kTyo/8nlFK0ZpxUFXCK4HvQoxsgW9S04E=; b=ZaIsCsF6U+HssY84gTQ5CJcJ+s5xH7gb+/tNuDx8FJqdLDFe2WjGGkbnCV9HheiwrT og94KNyGaD9jWHXkInyypT5jJfv5U7qO87wEKQCtI5osXLj5RbLbgqyyyftZItAXUksu ZJ7oGPNYskWYGeqOHly5rdRWqoi5ExMXDDXyvSZPM8LwvTnBvH0Qb7sFLOOuE+v8yCDX lVkKsp+h4bniB/3cKFzH7WI9u7zPpufTUfeMjKcQBpIEt/k8gBrPGKeRWCsmNLFGNOpg IzAWEoZ5DnAfYANnF1toF+EFsOcqdigSzDHUT4GOmq2oFXb98Nll+b27X8SuhVNngG8C cE0A== Received: by 10.182.18.164 with SMTP id x4mr2318098obd.15.1339079060625; Thu, 07 Jun 2012 07:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.12.35 with HTTP; Thu, 7 Jun 2012 07:23:40 -0700 (PDT) In-Reply-To: <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> From: Qiong Date: Thu, 7 Jun 2012 22:23:40 +0800 Message-ID: To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=f46d043891a5bc18ea04c1e2a3d1 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 07 Jun 2012 14:24:22 -0000 --f46d043891a5bc18ea04c1e2a3d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole, On Thu, Jun 7, 2012 at 4:48 PM, Ole Tr=C3=B8an wrote= : > > > I think we should still keep the initial feature of these solutions. > > all the proposed solutions, including DS-lite shares a large set of > commonalities. where the differences are more operational considerations > and deployment choices than technical differences. do we need a separate > protocol specification for each deployment choice? > I vote for describing the protocol specifications for different scenarios seperately. Although they have some commonalities, there are still quite a lot of differences from techincal details for their own features. As we currently have three categories of solutions, I think it will be easier and clearer for readers to understand each solution in seperated document. Best wishes Qiong > > cheers, > Ole > > > > --f46d043891a5bc18ea04c1e2a3d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole,

On Thu, Jun 7, 2012 at 4:48 PM, O= le Tr=C3=B8an <otroan@employees.org> wrote:

> I think we should still keep the initial feature of these solutions.
all the proposed solutions, including DS-lite shares a large set of c= ommonalities. where the differences are more operational considerations and= deployment choices than technical differences. do we need a separate proto= col specification for each deployment choice?
=C2=A0
I vote for describing the protocol speci= fications for different scenarios seperatel= y. Although they have some commonalities, there are still quite a lot of di= fferences from techincal details for their own features. As we currently ha= ve three categories of solutions,=C2=A0 I think it will be easier and clear= er for readers to understand each solution in seperated document.

Best wishes
Qiong
=C2=A0=C2=A0=C2=A0

cheers,
Ole




--f46d043891a5bc18ea04c1e2a3d1-- From pengwu.thu@gmail.com Thu Jun 7 09:30: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 0EB7511E808C for ; Thu, 7 Jun 2012 09:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.374 X-Spam-Level: X-Spam-Status: No, score=-3.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYKsrez7BME1 for ; Thu, 7 Jun 2012 09:30:48 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2848611E8085 for ; Thu, 7 Jun 2012 09:30:48 -0700 (PDT) Received: by qcsq13 with SMTP id q13so477975qcs.31 for ; Thu, 07 Jun 2012 09:30:42 -0700 (PDT) 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:content-transfer-encoding; bh=98Zk+3lGcXkQtxo17wohw/mkkXrxOGQdf4uTi4mcXSk=; b=yMYMtGnMQdSonIL3dD2Tb+jVznGk9juDe3vz1paOJVyrIMhTjPC0Ug54HSc5t2pjss UrL58sBAxJVx+spoMdnGJ9PwCQRY8crhgOsV+YMbmqJHkEhpDNA1R+dyccXCA+Fgfjep tXXKG7kFyVC0jLnkMkoIIN0Fx6jlFlVYvUXJ3sYhWoJqKLnvc/X40xrmD0j7zA9l+cx4 LtTwCKI6L61zZAhV13chfO940nTk3lnpdCyu0ZDpIkssJPqmVpfY4IfwxFFD9aDbfA7+ tkhohvNw25bLriD288L4dNp+u+XwLRm1pf77zp434j1v2/lMbMP6JoqDdv5w7taYz7Wv XXvA== MIME-Version: 1.0 Received: by 10.224.207.4 with SMTP id fw4mr2478493qab.82.1339086642528; Thu, 07 Jun 2012 09:30:42 -0700 (PDT) Received: by 10.229.30.203 with HTTP; Thu, 7 Jun 2012 09:30:42 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED1EAF@PUEXCB1B.nanterre.francetelecom.fr> References: <5D36713D8A4E7348A7E10DF7437A4B921EE69DBF@szxeml545-mbx.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E32ED1EAF@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 8 Jun 2012 00:30:42 +0800 Message-ID: From: Peng Wu To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 07 Jun 2012 16:30:49 -0000 Med, >From protocol level, the difference between public 4over6 and lightweight 4over6(b4-translated-ds-lite) lies in port-set support. The extra efforts of lw 4over6 are as follows: (1) port set support in DHCP provisioning; (2) NAT on the initiator side.(whose address pool is not a full address but only a port set) (3) port-set supporting in the cocentrator's binding table. While we may cover public 4over6 by lightweight 4over6 with a special port set format (2^16 size) for (3), (1) and (2) brings quite significant changes to the intiator side. If I'm only a pb 4over6 initiator, more typically a host initiator, all the complexity needed is to plant a CRA process on the host, which is basically an IPv4 & IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is already supported in today's OS. No NAT is needed in host case, and full e2e transparency is guaranteed. If we support this by lw 4over6, we implemented extra complexity which is not needed at all by the initiator. We have deployement scenarios which probably don't require address sharing, such as CERNET, and I guess maybe the ISPs in USA also do not have an IPv4 address shortage problem? So, aside from the fact that the pb 4over6 draft starts earlier and its status has been a step furher, this is a problem of choice: do we want two clean, simple mechanisms, or one mechanism trying to be compatible with both. On Thu, Jun 7, 2012 at 9:11 PM, wrote: > Dear all, > > I agree with Reinaldo. > > IMHO it makes sense to merge the two documents: either draft-ietf-softwir= e-public-4over6 be extended to cover draft-cui-softwire-b4-translated-ds-li= te or add one or two sentences to draft-cui-softwire-b4-translated-ds-lite = to mention a non-shared IPv4 address may be assigned. > > Doing so would help to rationalize the solution space and associated docu= ments. We have the following main flavours: > > (1) Full stateful mode: DS-Lite > (2) Full stateless mode: MAP > (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-transla= ted-ds-lite) > > All the three modes must support the ability to assign a full IPv4 addres= s. > > Cheers, > Med > >>-----Message d'origine----- >>De : softwires-bounces@ietf.org >>[mailto:softwires-bounces@ietf.org] De la part de Reinaldo Penno >>Envoy=E9 : lundi 28 mai 2012 07:53 >>=C0 : Sheng Jiang; Yong Cui; softwires@ietf.org >>Objet : Re: [Softwires] WG last call on >>draft-ietf-softwire-public-4over6-01 >> >>-1 >> >>In which significant way this document is different from >>http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- >>lite-06 ? >> >>We can insert one paragraph in the above draft and allow >>public IPs since >>NAT is optional. The two documents even use DHCPv4ov6 as provisioning. >> >> >> >>On 5/27/12 6:32 PM, "Sheng Jiang" wrote: >> >>>The document looks mature for being advanced. >>> >>>Sheng Jiang >>> >>>> -----Original Message----- >>>> From: softwires-bounces@ietf.org >>[mailto:softwires-bounces@ietf.org] On >>>> Behalf Of Yong Cui >>>> Sent: Sunday, May 27, 2012 10:31 PM >>>> To: softwires@ietf.org >>>> Cc: Yong Cui >>>> Subject: [Softwires] WG last call on >>draft-ietf-softwire-public-4over6- >>>> 01 >>>> >>>> Hi folks, >>>> >>>> This is a wg last call on draft-ietf-softwire-public-4over6-01. >>>> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >>>> >>>> As usual, please send editorial comments to the authors and >>>> substantive comments to the mailing list. >>>> >>>> This wg last call will end on 2012 June 10 at 12pm EDT. >>>> >>>> >>>> Yong & Alain >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> >>_______________________________________________ >>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 sarikaya2012@gmail.com Thu Jun 7 10:08:56 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 2CC7321F87A8 for ; Thu, 7 Jun 2012 10:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na0guyLZ+y+J for ; Thu, 7 Jun 2012 10:08:55 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86AA521F876E for ; Thu, 7 Jun 2012 10:08:55 -0700 (PDT) Received: by ghbg16 with SMTP id g16so697937ghb.31 for ; Thu, 07 Jun 2012 10:08:55 -0700 (PDT) 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:content-transfer-encoding; bh=+aF2LgGy/rU9/3iaSw3YkdwICdENMFh/aIpTf75LYto=; b=OzQGAEifuaEeC90uT9VksLDzjpjsmS97eFPW9RrrQ5vXUvK1MPBJ5KmsjS3IR4d76Y JxxH9e0iCqSUxuLfw1ZY5QMVLpJYKBGgqzGegykw0DMixaYZwqZ27OYfjEuBLMOTaWbB 9YpziWQ5mh9j16OH5CTkuJcdmHeHudNYRXXKjN+1PlQC017+Gtki53OU6yjnJxJLTH5K /ho/CKQQ0ErmIs+yrcSaz7qpCMuu6aVpXt03M+6clnMbunOMKE5+dG2J8uhYenYKCSNy tM/Jh9LF0tvfMI/C9CBa39qRVMpaMmnXoJFviZrFlBTlVzKIMC/pTAeasfgPG4c1lUpC DZdw== MIME-Version: 1.0 Received: by 10.50.40.193 with SMTP id z1mr1754924igk.0.1339088934627; Thu, 07 Jun 2012 10:08:54 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Thu, 7 Jun 2012 10:08:54 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 7 Jun 2012 12:08:54 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Thu, 07 Jun 2012 17:08:56 -0000 On Thu, Jun 7, 2012 at 8:07 AM, wrote: > Hi Woj, > > DS-Lite terminology is used in the sense that an IPv4 receiver is deliver= ed > (IPv4) multicast content (from an IPv4 source) over an IPv6 network. > > The generic use case as described in > http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.1= =A0is > called 4-6-4. I personally agree to change the title to reflect this. > > The document does not make any assumption about the location of AFTR and > mAFTR: deployment considerations are out of scope. FWIW, mAFTR is defined= as > follows: > > o Multicast AFTR (mAFTR): is a functional entity which supports > IPv4-IPv6 multicast interworking function (refer to Figure 3). It > receives and encapsulates the IPv4 multicast packets into IPv4-in- > IPv6 packets and behaves as the corresponding IPv6 multicast > source for the encapsulated IPv4-in-IPv6 packets. > > If you still think mAFTR terminology is confusing, we can change it to mB= R > (for multicast Border Router), 64mBR (IPv6/IPv4 Multicast Border Router), > mIXF (multicast Interconnection Function), etc. > So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? Behcet From despres.remi@laposte.net Thu Jun 7 10:33: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 AD86321F87FD for ; Thu, 7 Jun 2012 10:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.182 X-Spam-Level: X-Spam-Status: No, score=-1.182 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F3sWVJ70oXq for ; Thu, 7 Jun 2012 10:33:45 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id 373B021F87FB for ; Thu, 7 Jun 2012 10:33:43 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2509.sfr.fr (SMTP Server) with ESMTP id B4C33700025B; Thu, 7 Jun 2012 19:33:42 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2509.sfr.fr (SMTP Server) with ESMTP id DD3577000115; Thu, 7 Jun 2012 19:33:41 +0200 (CEST) X-SFR-UUID: 20120607173341906.DD3577000115@msfrf2509.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-15-5968780 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 7 Jun 2012 19:33:41 +0200 Message-Id: <965CC1ED-EF21-427E-B576-A41AFBF25841@laposte.net> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> To: Qiong Sun , Softwires WG X-Mailer: Apple Mail (2.1084) Cc: Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 07 Jun 2012 17:33:45 -0000 --Apple-Mail-15-5968780 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Qiong, all, Le 2012-06-07 =E0 16:23, Qiong a =E9crit : > Hi Ole, >=20 > On Thu, Jun 7, 2012 at 4:48 PM, Ole Tr=F8an = wrote: >=20 > > I think we should still keep the initial feature of these solutions. >=20 > all the proposed solutions, including DS-lite shares a large set of = commonalities. where the differences are more operational considerations = and deployment choices than technical differences. do we need a separate = protocol specification for each deployment choice? > =20 > I vote for describing the protocol specifications for different = scenarios seperately. +1 Also considering that: - Draft-ietf-softwire-public-4over6-01 has already reached a WG document = status, and needs AFAIK no technical change to become an RFC - It has no dependency on 4rd or MAP=20 - There is even one more solution with different scope but commonality, = namely 464XLAT currently discussed in v6ops Regards, RD > Although they have some commonalities, there are still quite a lot of = differences from techincal details for their own features. As we = currently have three categories of solutions, I think it will be easier = and clearer for readers to understand each solution in seperated = document. >=20 > Best wishes > Qiong > =20 >=20 > cheers, > Ole >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-15-5968780 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Ole,

On Thu, Jun 7, = 2012 at 4:48 PM, Ole Tr=F8an <otroan@employees.org> = wrote:

> I think we should still keep the initial feature of these = solutions.

all the proposed solutions, including DS-lite shares a large set = of commonalities. where the differences are more operational = considerations and deployment choices than technical differences. do we = need a separate protocol specification for each deployment choice?
 
I vote for describing the protocol = specifications for different scenarios = seperately. =

+1
Also = considering that:
- Draft-ietf-softwire-public-4over6-01 = has already reached a WG document status, and needs AFAIK no = technical change to become an RFC
- It has no dependency = on 4rd or MAP 
- There is even one more solution with = different scope but commonality, namely 464XLAT currently discussed in = v6ops

Regards,
RD

<= br>
Although = they have some commonalities, there are still quite a lot of differences = from techincal details for their own features. As we currently have = three categories of solutions,  I think it will be easier and = clearer for readers to understand each solution in seperated = document.

Best wishes
Qiong
   

cheers,
Ole




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

= = --Apple-Mail-15-5968780-- From stig@venaas.com Thu Jun 7 10:44: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 1F7CA11E8134 for ; Thu, 7 Jun 2012 10:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqtXAnQJ8GWe for ; Thu, 7 Jun 2012 10:44:07 -0700 (PDT) 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 3CE8511E812E for ; Thu, 7 Jun 2012 10:43:36 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 998CD8047 for ; Thu, 7 Jun 2012 19:43:34 +0200 (CEST) Message-ID: <4FD0E840.1070904@venaas.com> Date: Thu, 07 Jun 2012 10:43:28 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "softwires@ietf.org" References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B5D1.3060803@viagenie.ca> In-Reply-To: <4FD0B5D1.3060803@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 07 Jun 2012 17:44:08 -0000 Here are my last call comments. I think substantial changes are needed to the draft. I understand that this draft is focusing on dslite. But it appears that it is a generic solution. As it says in the draft: An IPv4 receiver accesses IPv4 multicast contents over an IPv6- only multicast-enabled network. Based on this, I think the scope of the draft, the title and introduction etc should be updated to actually show that it is a generic approach. And then instead list dslite as one of the scenarios where this is needed. Since it is a generic approach, I think it should also be reviewed, perhaps an additional WGLC, in mboned. pim wg may also have some interest in reviewing it. There are some errors regarding pim in this document. In particular, it discussed translation of IGMP/MLD. This is a topic that has been discussed in mboned/pim, and there is also another draft discussing this. It refers to draft-ietf-mboned-64-multicast-address-format-01. If that is to stay, I think this draft needs to wait to see what happens with the address-format draft in 6man. Changes may be needed in this draft depending on what happens. If only minor changes, the examples in this draft may need to be updated. Technical issue: In 4.2 it says: The mB4 uses the G6 (and both S6 and G6 in SSM) to create the corresponding MLD Report message. The mB4 sends the Report message to the MLD Querier in the IPv6 network. The MLD Querier (typically acts as the PIMv6 Designated Router) receives the MLD Report message and sends the PIMv6 Join to join the IPv6 multicast distribution tree. The MLD Querier can send either PIMv6 Join (*,G6) in ASM or PIMv6 Join (S6,G6) in SSM to the mAFTR. As is noted, the MLD querier and the DR may be different routers. It is the DR and not the MLD Querier (if they are different) that sends the PIM join. Also note that they are often different. If there are two routers, then the one with the lowest address is the MLD querier, while the one with the highest address (unless DR priority is configured) is the DR. Near the end of 4.2: A branch of the multicast distribution tree is then grafted, comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 part (from mAFTR downstream to the mB4). It says "is then grafted". So it sounds like the branch is added to the tree after the procedure has finished. But basically it is being added to the tree bit by bit as the joins are sent hop by hop. Maybe it could say "is in this way grafted" or something. I'm also a bit unsure whether "grafted" is a good term, as "graft" has a specific meaning for PIM Dense Mode. At the end of 4.2: The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so as to represent the IPv4-embedded IPv6 source in the IPv6 multicast network. Yes, probably in the IGP. Perhaps say more explicitly that there must be a route due to PIM's use of RPF. I see this is mentioned in 7.1 though. In 6.1 it talks about IGMP messages being translated to MLD. I would argue that this is not necessarily how this would be done. If you look at a pure MLD proxy, you build state for various (*,G) or (S,G) based on the reports you receive. Then based on this state you create reports that you send upstream. It is not the message from downstream that is just sent upstream. In this case, when receiving downstream IGMP reports, they could be used to create the IPv6 state. And then independent of whether the state was created due to IGMP or MLD reports, reports are sent upstream, created from that state. If you do this, messages are not translated. In 7.1 it says: information to discover the source. In order to pass the Reverse Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on the interfaces which has the shortest path to the uPrefix64. Note that the shortest path might change due to topology changes, links going down or coming up etc. So one would typically enable PIM on all the routers. If one wants to constrain multicast to only some of the topology, there are ways to build a separate multicast RIB for those routers, and then enable PIM on all of them. In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB is something different. I think it should say TIB. Check the terms MRIB and TIB in RFC 4601. The draft assumes PIM-SM is used. I think the approach could also be used with e.g. PIM Bidir (RFC 5015). 7.5 talks about scope, and mentions E and 8. Then it says that this specification does not specify which scope to use. I would perhaps not mention E and 8 then, it seems now to indicate that those are the only alternatives. The security considerations should probably be extended a bit. E.g. what about scoping? Can one traverse a scoped boundary by say joining a v4 scoped group using a join for a global v6 prefix? The draft should point out that it is just plain IPv4 in IPv6. At least that seems to be the intention. However, one might use the same solution with other tunnel types, e.g. GRE. Minor nits: o PIMv4: refers to PIM when deployed in an IPv4 infrastructure (i.e., IPv4 transfer capabilities are used to exchange PIM messages). o PIMv6: refers to PIM when deployed in an IPv6 infrastructure (i.e., IPv6 transfer capabilities are used to exchange PIM messages). Replace transfer with transport? Section 6.4 starts with this: If the mB4 function is implemented in the host which is directly connected to an IPv6-only network. If an IPv4 application running in I'm not exactly sure what the first "if" refers to. This needs to be reformulated. Also in 6.4 there is this typo: "implemntation". Stig From stig@venaas.com Thu Jun 7 10:49:04 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 F356E11E8132 for ; Thu, 7 Jun 2012 10:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMkotJavTmge for ; Thu, 7 Jun 2012 10:49:03 -0700 (PDT) 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 468B011E8116 for ; Thu, 7 Jun 2012 10:49:03 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 723BD8047; Thu, 7 Jun 2012 19:48:59 +0200 (CEST) Message-ID: <4FD0E989.90801@venaas.com> Date: Thu, 07 Jun 2012 10:48:57 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , Yong Cui , Behcet Sarikaya Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 07 Jun 2012 17:49:04 -0000 On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: > On Thu, Jun 7, 2012 at 8:07 AM, wrote: >> Hi Woj, >> >> DS-Lite terminology is used in the sense that an IPv4 receiver is delivered >> (IPv4) multicast content (from an IPv4 source) over an IPv6 network. >> >> The generic use case as described in >> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.1 is >> called 4-6-4. I personally agree to change the title to reflect this. >> >> The document does not make any assumption about the location of AFTR and >> mAFTR: deployment considerations are out of scope. FWIW, mAFTR is defined as >> follows: >> >> o Multicast AFTR (mAFTR): is a functional entity which supports >> IPv4-IPv6 multicast interworking function (refer to Figure 3). It >> receives and encapsulates the IPv4 multicast packets into IPv4-in- >> IPv6 packets and behaves as the corresponding IPv6 multicast >> source for the encapsulated IPv4-in-IPv6 packets. >> >> If you still think mAFTR terminology is confusing, we can change it to mBR >> (for multicast Border Router), 64mBR (IPv6/IPv4 Multicast Border Router), >> mIXF (multicast Interconnection Function), etc. >> > > So you are saying that this draft does not correspond to > Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. Stig > > Behcet > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sarikaya2012@gmail.com Thu Jun 7 11:20:26 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 A06EC11E8137 for ; Thu, 7 Jun 2012 11:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtZXgiVmH9js for ; Thu, 7 Jun 2012 11:20:25 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2F511E812E for ; Thu, 7 Jun 2012 11:20:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so763440ghb.31 for ; Thu, 07 Jun 2012 11:20:24 -0700 (PDT) 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:content-transfer-encoding; bh=nZ3hbK33x6TgMt/4VBOMewWnaSph6YjPrDyJkvP8/ag=; b=C2cVDDcBxUjVzqxHDEWDS0t9K/iqkMK5YjRi3mwYi/pOzKU8jvUDULsI8jumeFkNNC 2cUUEbj0MCk7PM3Aq41F3OmfO21pRUsdNmMKJvUSZc2lKw2x6aDGKYoGdO6ZUnOJTNkd y8Ao1pPSze6G2rNtitwCCnGUS3hS279mBuWUHktwrfS/MZGFAnikad3G4K0otX7LnGEe WdF4yKBqzdXAeMeXtKawKa2UnOdqf1G79+YT4+ALCfKH8aRS6msKVlLqmFvW65RoyUaG ern39qOEts6jIqo5zpoEfHHhS241+3iw3vGqgO/m6rUb5faiMNUB0fbJYKkRVXglnm26 ayzQ== MIME-Version: 1.0 Received: by 10.50.159.135 with SMTP id xc7mr1943128igb.9.1339093224316; Thu, 07 Jun 2012 11:20:24 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Thu, 7 Jun 2012 11:20:24 -0700 (PDT) In-Reply-To: <4FD0E989.90801@venaas.com> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> Date: Thu, 7 Jun 2012 13:20:24 -0500 Message-ID: From: Behcet Sarikaya To: Stig Venaas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Thu, 07 Jun 2012 18:20:26 -0000 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas wrote: > On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >> >> On Thu, Jun 7, 2012 at 8:07 AM, =A0wrote: >>> >> So you are saying that this draft does not correspond to >> Multicast extensions for DS-Lite? > > > I sent a separate review, but anyway, it is not an extension to > DS-Lite as I see it. It is a completely generic approach for > tunneling v6 through v4. It can certainly be deployed in DS-Lite > scenarios, but it is much more generic. I would like the title and > the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet From mohamed.boucadair@orange.com Thu Jun 7 22:38:59 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 0D6FD21F8714 for ; Thu, 7 Jun 2012 22:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDF2UXfM86ff for ; Thu, 7 Jun 2012 22:38:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A627C11E809A for ; Thu, 7 Jun 2012 22:38:48 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 708AB22C7AB; Fri, 8 Jun 2012 07:38:47 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 50D3035C045; Fri, 8 Jun 2012 07:38:47 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 8 Jun 2012 07:38:47 +0200 From: To: "sarikaya@ieee.org" Date: Fri, 8 Jun 2012 07:38:45 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1E0DloptnFVqXzSFKjorD/B6BP1QAZ/a6A Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1FD8@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.6.8.30340 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 08 Jun 2012 05:38:59 -0000 Dear all, >So you are saying that this draft does not correspond to >Multicast extensions for DS-Lite? > >Behcet > =20 No. =20 This draft is designed to provide multicast services to DS-Lite serviced cu= stomers. This is the main mission of the draft. But, the proposed approach can be applied for any other 4-6-4 use case (as = defined in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00).= =20 Cheers, Med >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : jeudi 7 juin 2012 19:09 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Wojciech Dec; softwires@ietf.org; Yong Cui >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-dslite-multicast-02 > >On Thu, Jun 7, 2012 at 8:07 AM, wrote: >> Hi Woj, >> >> DS-Lite terminology is used in the sense that an IPv4=20 >receiver is delivered >> (IPv4) multicast content (from an IPv4 source) over an IPv6 network. >> >> The generic use case as described in >>=20 >http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#s ection-3.1=A0is >> called 4-6-4. I personally agree to change the title to reflect this. >> >> The document does not make any assumption about the location=20 >of AFTR and >> mAFTR: deployment considerations are out of scope. FWIW,=20 >mAFTR is defined as >> follows: >> >> o Multicast AFTR (mAFTR): is a functional entity which supports >> IPv4-IPv6 multicast interworking function (refer to=20 >Figure 3). It >> receives and encapsulates the IPv4 multicast packets=20 >into IPv4-in- >> IPv6 packets and behaves as the corresponding IPv6 multicast >> source for the encapsulated IPv4-in-IPv6 packets. >> >> If you still think mAFTR terminology is confusing, we can=20 >change it to mBR >> (for multicast Border Router), 64mBR (IPv6/IPv4 Multicast=20 >Border Router), >> mIXF (multicast Interconnection Function), etc. >> > >So you are saying that this draft does not correspond to >Multicast extensions for DS-Lite? > >Behcet >= From mohamed.boucadair@orange.com Thu Jun 7 22:48:38 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 4FCFD21F87A4 for ; Thu, 7 Jun 2012 22:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnTDtFygWhTT for ; Thu, 7 Jun 2012 22:48:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB5121F87A0 for ; Thu, 7 Jun 2012 22:48:37 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 8FC4B22C7DD; Fri, 8 Jun 2012 07:48:36 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 73FD235C048; Fri, 8 Jun 2012 07:48:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 8 Jun 2012 07:48:36 +0200 From: To: "sarikaya@ieee.org" , Stig Venaas Date: Fri, 8 Jun 2012 07:48:34 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1E2jZg1j8wz+qjTVGjYTV/TFym7QAXspcA Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.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: 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.6.8.30340 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 08 Jun 2012 05:48:38 -0000 Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-L= ite serviced customers.=20 * The draft proposes multicast extensions and not unicast ones. Cheers, Med >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : jeudi 7 juin 2012 20:20 >=C0 : Stig Venaas >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-dslite-multicast-02 > >On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas wrote: >> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>> >>> On Thu, Jun 7, 2012 at 8:07=20 >AM, =A0wrote: >>>> > >>> So you are saying that this draft does not correspond to >>> Multicast extensions for DS-Lite? >> >> >> I sent a separate review, but anyway, it is not an extension to >> DS-Lite as I see it. It is a completely generic approach for >> tunneling v6 through v4. It can certainly be deployed in DS-Lite >> scenarios, but it is much more generic. I would like the title and >> the text to reflect that. > >So it means that this draft does not correspond to Softwire charter >item and we discover this quite late in the process. > >My recommendation to the chairs is to read and double check the draft >before making an adoption call, especially if there is choice. > >As I mentioned in my mboned mail, in multicast transition I think the >right approach is to agree to the fact that most of the host's >communication will be unicast. For unicast, v4-v6 transition has >already been well analyzed and several protocols have been specified. >Multicast extensions to those protocols are what we need. > >Regards, > >Behcet >= From mohamed.boucadair@orange.com Thu Jun 7 22:58: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 1053521F85F2 for ; Thu, 7 Jun 2012 22:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au3uFspN5uBD for ; Thu, 7 Jun 2012 22:58:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0309121F858F for ; Thu, 7 Jun 2012 22:58:38 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id EA339264422; Fri, 8 Jun 2012 07:58:36 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id CF60F35C048; Fri, 8 Jun 2012 07:58:36 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 8 Jun 2012 07:58:36 +0200 From: To: Peng Wu Date: Fri, 8 Jun 2012 07:58:35 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Thread-Index: Ac1EyuKlGljIzBeWSG26c6DHHkGDzAAb51hw Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED1FE0@PUEXCB1B.nanterre.francetelecom.fr> References: <5D36713D8A4E7348A7E10DF7437A4B921EE69DBF@szxeml545-mbx.china.huawei.com> <94C682931C08B048B7A8645303FDC9F36E32ED1EAF@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.6.8.53333 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 05:58:39 -0000 Hi Peng, I vote for having one single document which covers both shared and full IPv= 4 address.=20 If you start for instance from draft-cui-softwire-b4-translated-ds-lite, wh= at is needed is to add one sentence to say a full IPv4 address can be provi= sioned. Does this make draft-cui-softwire-b4-translated-ds-lite more comple= x? I don't think so. I really think we need all to do an effort of rationalizing the solutions s= pace.=20 Cheers, Med=20 >-----Message d'origine----- >De : Peng Wu [mailto:pengwu.thu@gmail.com]=20 >Envoy=E9 : jeudi 7 juin 2012 18:31 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Yong Cui; softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-public-4over6-01 > >Med, > >From protocol level, the difference between public 4over6 and >lightweight 4over6(b4-translated-ds-lite) lies in port-set support. >The extra efforts of lw 4over6 are as follows: (1) port set support in >DHCP provisioning; (2) NAT on the initiator side.(whose address pool >is not a full address but only a port set) (3) port-set supporting in >the cocentrator's binding table. > >While we may cover public 4over6 by lightweight 4over6 with a special >port set format (2^16 size) for (3), (1) and (2) brings quite >significant changes to the intiator side. If I'm only a pb 4over6 >initiator, more typically a host initiator, all the complexity needed >is to plant a CRA process on the host, which is basically an IPv4 & >IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already >there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is >already supported in today's OS. No NAT is needed in host case, and >full e2e transparency is guaranteed. If we support this by lw 4over6, >we implemented extra complexity which is not needed at all by the >initiator. > >We have deployement scenarios which probably don't require address >sharing, such as CERNET, and I guess maybe the ISPs in USA also do not >have an IPv4 address shortage problem? > >So, aside from the fact that the pb 4over6 draft starts earlier and >its status has been a step furher, this is a problem of choice: do we >want two clean, simple mechanisms, or one mechanism trying to be >compatible with both. > >On Thu, Jun 7, 2012 at 9:11 PM, wrote: >> Dear all, >> >> I agree with Reinaldo. >> >> IMHO it makes sense to merge the two documents: either=20 >draft-ietf-softwire-public-4over6 be extended to cover=20 >draft-cui-softwire-b4-translated-ds-lite or add one or two=20 >sentences to draft-cui-softwire-b4-translated-ds-lite to=20 >mention a non-shared IPv4 address may be assigned. >> >> Doing so would help to rationalize the solution space and=20 >associated documents. We have the following main flavours: >> >> (1) Full stateful mode: DS-Lite >> (2) Full stateless mode: MAP >> (3) Per-customer state/binding mode: lw4o6=20 >(draft-cui-softwire-b4-translated-ds-lite) >> >> All the three modes must support the ability to assign a=20 >full IPv4 address. >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : softwires-bounces@ietf.org >>>[mailto:softwires-bounces@ietf.org] De la part de Reinaldo Penno >>>Envoy=E9 : lundi 28 mai 2012 07:53 >>>=C0 : Sheng Jiang; Yong Cui; softwires@ietf.org >>>Objet : Re: [Softwires] WG last call on >>>draft-ietf-softwire-public-4over6-01 >>> >>>-1 >>> >>>In which significant way this document is different from >>>http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- >>>lite-06 ? >>> >>>We can insert one paragraph in the above draft and allow >>>public IPs since >>>NAT is optional. The two documents even use DHCPv4ov6 as=20 >provisioning. >>> >>> >>> >>>On 5/27/12 6:32 PM, "Sheng Jiang" wrote: >>> >>>>The document looks mature for being advanced. >>>> >>>>Sheng Jiang >>>> >>>>> -----Original Message----- >>>>> From: softwires-bounces@ietf.org >>>[mailto:softwires-bounces@ietf.org] On >>>>> Behalf Of Yong Cui >>>>> Sent: Sunday, May 27, 2012 10:31 PM >>>>> To: softwires@ietf.org >>>>> Cc: Yong Cui >>>>> Subject: [Softwires] WG last call on >>>draft-ietf-softwire-public-4over6- >>>>> 01 >>>>> >>>>> Hi folks, >>>>> >>>>> This is a wg last call on draft-ietf-softwire-public-4over6-01. >>>>> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >>>>> >>>>> As usual, please send editorial comments to the authors and >>>>> substantive comments to the mailing list. >>>>> >>>>> This wg last call will end on 2012 June 10 at 12pm EDT. >>>>> >>>>> >>>>> Yong & Alain >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>>_______________________________________________ >>>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 ichiroumakino@gmail.com Fri Jun 8 00:43: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 A897421F85F6 for ; Fri, 8 Jun 2012 00:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH-TFOYAeCLB for ; Fri, 8 Jun 2012 00:43:27 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D929921F85F0 for ; Fri, 8 Jun 2012 00:43:26 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1022863eaa.31 for ; Fri, 08 Jun 2012 00:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ukCL8X8tbR0ohni2iwpzeDn0EKGTuEICGqO498adalE=; b=gEnNCrNPLJKtkuGOMKV2EUPhsXHNu7Z/FasZ0jz18GXsoJU96aRugEmtsVBOsClegW yk7GPnvm82E58MR2QnJ9qzsC6C3VV0z+IKpeOVLjRdlclTmWBA2Tcs9cZ4nQgvKgrHcO Ljj5p+19Lp+L32LWhZKt6UNQoH5e0ur8gSvORb1zj2WTEEA1gfnSClGI+O5e83cDEc5r ynftuSHEifzXe6FP4gzA9OV7q77CZDN2K/LF7OTtJNRUPVCe3aAMdqd5K7cZgg2Nj4a+ tl78QZS6rZopyJUX9IdKp9jTfgxvZvjhCbYQxduhE7m+QlL92WLcm+p7ILvor2+SjDZe 6pBw== Received: by 10.14.45.14 with SMTP id o14mr3158712eeb.189.1339141406016; Fri, 08 Jun 2012 00:43:26 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id h53sm19173170eea.1.2012.06.08.00.43.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 00:43:25 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 8 Jun 2012 09:43:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 07:43:27 -0000 Peng, > Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, > they have respective application scenarios, pros and cons. > 1)stateless, 4rd, MAP > 2)per-flow stateful: DS-Lite > 3)per-user stateful: public 4over6, lightweight 4over6 > As Ole said, the problem is that, do we want serveral simple > mechanisms, or one super-compatible mechanism with different modes. >=20 > Now Given that a) the WG has accomplished DS-lite; b)MAP follows the > stateless motivation all along the way; c)The signifcant changes to > make MAP super-compatible, I vote for we define the third type, > per-user stateful mechanisms independently. actually there are no significant changes to the MAP specification, the = per-user stateful mechanism is just intrinsically supported by MAP. it = is a corner case, and it would be more work in the specification to = "ban" this operational mode, than to support it. btw, one thing that appears most complicated is provisioning; currently = it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options = to get provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel = up, then a DHCPv6 option for the DHCPv4 server address, and then a = DHCPv4 exchange to get the IPv4 address, and then a new DHCPv4 option to = get the port set. that seems to me to be quite a few moving parts, and = quiet a few corner cases to be specified when one or more of the above = fails. in MAP you do all of that with one single DHCPv6 option... cheers, Ole= From wdec.ietf@gmail.com Fri Jun 8 00: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 E78F421F88C7 for ; Fri, 8 Jun 2012 00:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cazjQoJgK+Gb for ; Fri, 8 Jun 2012 00:57:02 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCB321F88BB for ; Fri, 8 Jun 2012 00:57:00 -0700 (PDT) Received: by qadz3 with SMTP id z3so589684qad.10 for ; Fri, 08 Jun 2012 00:57:00 -0700 (PDT) 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=QKSY/PStqVPTzWyCC8byk3F/OXF3716YB83+wyWeaTM=; b=v9NEP1DVUldKjAuKdKob21sTmt5y8BdZDw2MGx/++7LVexM/SLUW9uXZc2zuZ4mBK0 9ZzG+dmMAxKzHiQi8QiRwU90XnbR/aFhQ08cP8JvJFCad325UubDzuzQgfkhDGO4XYZx UZFlPAfSZqVH0N+jCQAqa6ufUbf5NLovS4rvF7oJ4qsEuDG0yWvDfJ9U+i7wxKK0tm0o US0PYHOLATISFlP6XHfbj0o6oU3Evdrc/l92IQr2T8z6ahSxQmxlfPPHl1ehc/d73KnY ZqgnS+cJH+DYVvUX5pGLD/l0MhE5m0DXsYLCZPeDQqw4GBUly61y0VLJVw0fuOkdjHB6 KQ5Q== MIME-Version: 1.0 Received: by 10.224.221.141 with SMTP id ic13mr6234744qab.2.1339142220272; Fri, 08 Jun 2012 00:57:00 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Fri, 8 Jun 2012 00:57:00 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 8 Jun 2012 09:57:00 +0200 Message-ID: From: Wojciech Dec To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=20cf3074b4f857d27e04c1f158f8 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 08 Jun 2012 07:57:03 -0000 --20cf3074b4f857d27e04c1f158f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, wrote: > Re-, > > May I re-iterate: > > * The draft is designed to allow the delivery of multicast services to > DS-Lite serviced customers. > * The draft proposes multicast extensions and not unicast ones. > > Cheers, > Med > > >-----Message d'origine----- > >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] > >Envoy=E9 : jeudi 7 juin 2012 20:20 > >=C0 : Stig Venaas > >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui > >Objet : Re: [Softwires] WG last call on > >draft-ietf-softwire-dslite-multicast-02 > > > >On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas wrote: > >> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: > >>> > >>> On Thu, Jun 7, 2012 at 8:07 > >AM, wrote: > >>>> > > > >>> So you are saying that this draft does not correspond to > >>> Multicast extensions for DS-Lite? > >> > >> > >> I sent a separate review, but anyway, it is not an extension to > >> DS-Lite as I see it. It is a completely generic approach for > >> tunneling v6 through v4. It can certainly be deployed in DS-Lite > >> scenarios, but it is much more generic. I would like the title and > >> the text to reflect that. > > > >So it means that this draft does not correspond to Softwire charter > >item and we discover this quite late in the process. > > > >My recommendation to the chairs is to read and double check the draft > >before making an adoption call, especially if there is choice. > > > >As I mentioned in my mboned mail, in multicast transition I think the > >right approach is to agree to the fact that most of the host's > >communication will be unicast. For unicast, v4-v6 transition has > >already been well analyzed and several protocols have been specified. > >Multicast extensions to those protocols are what we need. > > > >Regards, > > > >Behcet > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074b4f857d27e04c1f158f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Med,

there is no dependency here on ds-lite, ie This has all t= he hallmarks of a standalone solution, which will almost certainly be imple= mented as such, and one that will work with or without ds-lite for unicast.=

Regards,
Woj.

On 8 June 2012 07:48= , <mohamed.boucadair@orange.com> wrote:
Re-,

May I re-iterate:

* The draft is designed to allow the delivery of multicast services to DS-L= ite serviced customers.
* The draft proposes multicast extensions and not unicast ones.

Cheers,
Med

>-----Message d'origine-----
>De : Behcet Sarikaya [mailto:= sarikaya2012@gmail.com]
>Envoy=E9 : jeudi 7 juin 2012 20:20
>=C0 : Stig Venaas
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui
>Objet : Re: [Softwires] WG last call on
>draft-ietf-softwire-dslite-multicast-02
>
>On Thu, Jun 7, 2012 at 12= :48 PM, Stig Venaas <stig@venaas.com<= /a>> wrote:
>> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote:
>>>
>>> On Thu, Jun 7, 2012 at 8:07
>AM,<mohamed.boucadai= r@orange.com> =A0wrote:
>>>>
>
>>> So you are saying that this draft does not correspond to
>>> Multicast extensions for DS-Lite?
>>
>>
>> I sent a separate review, but anyway, it is not an extension to >> DS-Lite as I see it. It is a completely generic approach for
>> tunneling v6 through v4. It can certainly be deployed in DS-Lite >> scenarios, but it is much more generic. I would like the title and=
>> the text to reflect that.
>
>So it means that this draft does not correspond to Softwire charter
>item and we discover this quite late in the process.
>
>My recommendation to the chairs is to read and double check the draft >before making an adoption call, especially if there is choice.
>
>As I mentioned in my mboned mail, in multicast transition I think the >right approach is to agree to the fact that most of the host's
>communication will be unicast. For unicast, v4-v6 transition has
>already been well analyzed and several protocols have been specified. >Multicast extensions to those protocols are what we need.
>
>Regards,
>
>Behcet
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074b4f857d27e04c1f158f8-- From mohamed.boucadair@orange.com Fri Jun 8 01:43: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 1FB0221F88BF for ; Fri, 8 Jun 2012 01:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4hRlj-5JTCF for ; Fri, 8 Jun 2012 01:43:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C313B21F88BD for ; Fri, 8 Jun 2012 01:43:11 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0D0222DC4F9; Fri, 8 Jun 2012 10:43:11 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DDEBF35C045; Fri, 8 Jun 2012 10:43:10 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 8 Jun 2012 10:43:11 +0200 From: To: Wojciech Dec Date: Fri, 8 Jun 2012 10:43:09 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1FTEn2Bu6am+eeRvSRAptFDcthuQABdZ+w Message-ID: <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E32ED20B4PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.8.81523 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 08 Jun 2012 08:43:13 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E32ED20B4PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draf= t: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. Thi= s will be reflected in the updated version of the draft. Cheers, Med ________________________________ De : Wojciech Dec [mailto:wdec.ietf@gmail.com] Envoy=E9 : vendredi 8 juin 2012 09:57 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicas= t-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a = standalone solution, which will almost certainly be implemented as such, an= d one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, > wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-L= ite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >Envoy=E9 : jeudi 7 juin 2012 20:20 >=C0 : Stig Venaas >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >Objet : Re: [Softwires] WG last call on >draft-ietf-softwire-dslite-multicast-02 > >On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas > wrote: >> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>> >>> On Thu, Jun 7, 2012 at 8:07 >AM,> wr= ote: >>>> > >>> So you are saying that this draft does not correspond to >>> Multicast extensions for DS-Lite? >> >> >> I sent a separate review, but anyway, it is not an extension to >> DS-Lite as I see it. It is a completely generic approach for >> tunneling v6 through v4. It can certainly be deployed in DS-Lite >> scenarios, but it is much more generic. I would like the title and >> the text to reflect that. > >So it means that this draft does not correspond to Softwire charter >item and we discover this quite late in the process. > >My recommendation to the chairs is to read and double check the draft >before making an adoption call, especially if there is choice. > >As I mentioned in my mboned mail, in multicast transition I think the >right approach is to agree to the fact that most of the host's >communication will be unicast. For unicast, v4-v6 transition has >already been well analyzed and several protocols have been specified. >Multicast extensions to those protocols are what we need. > >Regards, > >Behcet > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_94C682931C08B048B7A8645303FDC9F36E32ED20B4PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Woj,
 
Your comment is valid.
 
The point I wanted to make is to recall the i= nitial=20 motivation of this draft: solve an issue raised by DS-Lite people.=20
 
Evidently, the proposed approach can be deplo= yed in=20 any 4-6-4 scenario. This will be reflected in the updated version of the=20 draft.
 
Cheers,
Med

De : Wojciech Dec=20 [mailto:wdec.ietf@gmail.com]
Envoy=E9 : vendredi 8 juin 2= 012=20 09:57
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc := =20 sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong=20 Cui
Objet : Re: [Softwires] WG last call on=20 draft-ietf-softwire-dslite-multicast-02

Hello Med,

there is no dependency here on ds-lite, ie T= his=20 has all the hallmarks of a standalone solution, which will almost certain= ly be=20 implemented as such, and one that will work with or without ds-lite for=20 unicast.

Regards,
Woj.

On 8 June 2012 07:48, <mohamed.boucadair@orange.com> wrote:
Re-,

May I re-iterate:

* The draft is=20 designed to allow the delivery of multicast services to DS-Lite service= d=20 customers.
* The draft proposes multicast extensions and not unicast= =20 ones.

Cheers,
Med

>-----Message=20 d'origine-----
>De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
<= /DIV>>Envoy=E9=20 : jeudi 7 juin 2012 20:20
>=C0 : Stig Venaas
>Cc : BOUCADAI= R=20 Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui
>Objet : Re: [Softwires] WG last call=20 on
>draft-ietf-softwire-dslite-multicast-02
>
>On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas <stig@venaas.com> wrote:
>&= gt; On=20 6/7/2012 10:08 AM, Behcet Sarikaya wrote:
>>>
>>&g= t; On=20 Thu, Jun 7, 2012 at 8:07
>AM,<mohamed.boucadair@orange.c= om>=20  wrote:
>>>>
>
>>> So you are say= ing=20 that this draft does not correspond to
>>> Multicast extens= ions=20 for DS-Lite?
>>
>>
>> I sent a separate revi= ew,=20 but anyway, it is not an extension to
>> DS-Lite as I see it. = It is=20 a completely generic approach for
>> tunneling v6 through v4. = It=20 can certainly be deployed in DS-Lite
>> scenarios, but it is m= uch=20 more generic. I would like the title and
>> the text to reflec= t=20 that.
>
>So it means that this draft does not correspond to= =20 Softwire charter
>item and we discover this quite late in the=20 process.
>
>My recommendation to the chairs is to read and= =20 double check the draft
>before making an adoption call, especiall= y if=20 there is choice.
>
>As I mentioned in my mboned mail, in=20 multicast transition I think the
>right approach is to agree to t= he=20 fact that most of the host's
>communication will be unicast. For= =20 unicast, v4-v6 transition has
>already been well analyzed and sev= eral=20 protocols have been specified.
>Multicast extensions to those=20 protocols are what we=20 need.
>
>Regards,
>
>Behcet
>
________= _______________________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
=

--_000_94C682931C08B048B7A8645303FDC9F36E32ED20B4PUEXCB1Bnante_-- From pengwu.thu@gmail.com Fri Jun 8 02:35: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 E6B4521F8552 for ; Fri, 8 Jun 2012 02:35:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuC6RJZ+ng95 for ; Fri, 8 Jun 2012 02:35:36 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5294D21F85B7 for ; Fri, 8 Jun 2012 02:35:36 -0700 (PDT) Received: by qabj40 with SMTP id j40so792529qab.15 for ; Fri, 08 Jun 2012 02:35:35 -0700 (PDT) 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:content-transfer-encoding; bh=A7NdoPaE7ad/tAOg8IcSah0k2zCejyfMCySQ1fKCQQI=; b=m+nyizup/+xKB//1rL3imlMcewyhR0VlGBnLlLKE2Kazg59MVGzYYnadKPp51lPiFi 0y0zHEaRv4zh56XRGo/qtkV/rgOZdcVjDOIVoZuYP/04kAZtG2Mh69kqLkiM4StiCIzv ECh9G+TM4nSFaSm3qKU73Q3ERMSDI/bHh2qksFbK1Qv0Jl1JqCh1TyXJ0AR6hZyfM5yX T8j3kDFpBmGYsEtMvKj/qg1aX6Kng+UJFoDwgWE27yYNDd+5OQIVxTAyJ6aA9nlNZ+ww Yn5TnnwZD4zR2Eix7skMx4U9dreYgIvkUPYQj80cj5gLpPaT0Kh16U0ejagYQrHtzbps uJeA== MIME-Version: 1.0 Received: by 10.224.176.148 with SMTP id be20mr6411174qab.64.1339148135547; Fri, 08 Jun 2012 02:35:35 -0700 (PDT) Received: by 10.229.30.203 with HTTP; Fri, 8 Jun 2012 02:35:35 -0700 (PDT) In-Reply-To: <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org> Date: Fri, 8 Jun 2012 17:35:35 +0800 Message-ID: From: Peng Wu To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 09:35:37 -0000 Ole, > btw, one thing that appears most complicated is provisioning; currently i= t looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to g= et provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, th= en a DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchang= e to get the IPv4 address, and then a new DHCPv4 option to get the port set= . that seems to me to be quite a few moving parts, and quiet a few corner c= ases to be specified when one or more of the above fails. in MAP you do all= of that with one single DHCPv6 option... Let me make it more precise. In lw 4over6, It's one DHCPv6 exchange and one DHCPv4 exchange. DHCPv6 exchange to get the concentrator address and DHCPv4 server address, two options at the same time. And of course the DHCPv4 server could be collocated with the concentrator. DHCPv4 exchange to retrieve the address and port-set at the same time. Now compared with MAP: 1) Concentrator address is also needed in provisioning. 2) DHCPv4 server address. This is only used when we want to separate DHCPv4 server from the concentrator (For HA, redundancy...). With MAP you cannot do this separation. 3) DHCPv4 is used to provision the address and port-set to the intiator. Now with MAP you provide this as a rule in DHCPv6. That's the most significant difference So, I don't see lw4over6 provisioning more complicated than MAP... From wdec.ietf@gmail.com Fri Jun 8 04:44: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 72CD921F85D8 for ; Fri, 8 Jun 2012 04:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq7xpuUeUk9A for ; Fri, 8 Jun 2012 04:44:17 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3407221F88FF for ; Fri, 8 Jun 2012 04:44:17 -0700 (PDT) Received: by qcsq13 with SMTP id q13so953040qcs.31 for ; Fri, 08 Jun 2012 04:44:16 -0700 (PDT) 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=aSSQrO2Zi1KcSPbQe6HNtXmdd2FEVh9jIeCzRyd+0Ws=; b=cu46LAxWPkCvkc45ShW67u5zGSvLXudTbqW8yDvJXKYRgZLIyW5S+O4gwRenmBEqgh u169dYJcKkYuPtlF6+PWyyPelQRm0meWjY+9l8OgkewzWzhc9qoojc+HDnxlzMq4K19n MzCU6IZ6axT6+q9lz6SnuHLhmQYCMayTZWyusgJIeQ+L7iIa0p6Wkjv8HZqUksQCXNey ROfILXomgt2vjHaUonZwp+Jfk08uMZLg55GLPqclTtrJt/h2sxnEPDmSmESwThvpBGqP PIf8KeO7zJ+02maXfJO6HUItyp5zjQCYTkLrtWA/HdC4GuwrfUdWx1rJuZni4FweRTez VqTA== MIME-Version: 1.0 Received: by 10.224.220.145 with SMTP id hy17mr6712220qab.85.1339155856556; Fri, 08 Jun 2012 04:44:16 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Fri, 8 Jun 2012 04:44:16 -0700 (PDT) In-Reply-To: References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org> Date: Fri, 8 Jun 2012 13:44:16 +0200 Message-ID: From: Wojciech Dec To: Peng Wu Content-Type: multipart/alternative; boundary=20cf3074d75821041c04c1f485bb Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 11:44:18 -0000 --20cf3074d75821041c04c1f485bb Content-Type: text/plain; charset=ISO-8859-1 Peng, On 8 June 2012 11:35, Peng Wu wrote: > Ole, > > > > btw, one thing that appears most complicated is provisioning; currently > it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to > get provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, > then a DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 > exchange to get the IPv4 address, and then a new DHCPv4 option to get the > port set. that seems to me to be quite a few moving parts, and quiet a few > corner cases to be specified when one or more of the above fails. in MAP > you do all of that with one single DHCPv6 option... > > Let me make it more precise. > > In lw 4over6, It's one DHCPv6 exchange and one DHCPv4 exchange. > DHCPv6 exchange to get the concentrator address and DHCPv4 server > address, two options at the same time. And of course the DHCPv4 server > could be collocated with the concentrator. > DHCPv4 exchange to retrieve the address and port-set at the same time. > > Now compared with MAP: > 1) Concentrator address is also needed in provisioning. > 2) DHCPv4 server address. This is only used when we want to separate > DHCPv4 server from the concentrator (For HA, redundancy...). With MAP > you cannot do this separation. > Yes, because MAP doesn't require one to use another component like DHCPv4 which is in itself subject to failure. That said, MAP can also use DHCPv4, but quite honestly what's the point of running DHCPv4 when all the useful info is available via DHCPv6? > 3) DHCPv4 is used to provision the address and port-set to the > intiator. Now with MAP you provide this as a rule in DHCPv6. That's > the most significant difference > > So, I don't see lw4over6 provisioning more complicated than MAP... > Current MAP = operating DHCPv6 l24over6 = operating DHCPv4 and DHCPv6 + mechanisms to get to the DHCPv4 server over IPv6 There appears to be some evident complication there, for no clear benefit. -Woj. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074d75821041c04c1f485bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peng,

On 8 June 2012 11:35, Peng Wu <= pengwu.thu@gmail.com> wrote:


> btw, one thing that appears most complicated is provisioning; currentl= y it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options t= o get provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up,= then a DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exch= ange to get the IPv4 address, and then a new DHCPv4 option to get the port = set. that seems to me to be quite a few moving parts, and quiet a few corne= r cases to be specified when one or more of the above fails. in MAP you do = all of that with one single DHCPv6 option...

Let me make it more precise.

In lw 4over6, It's one DHCPv6 exchange and one DHCPv4 exchange.
DHCPv6 exchange to get the concentrator address and DHCPv4 server
address, two options at the same time. And of course the DHCPv4 server
could be collocated with the concentrator.
DHCPv4 exchange to retrieve the address and port-set at the same time.

Now compared with MAP:
1) Concentrator address is also needed in provisioning.
2) DHCPv4 server address. This is only used when we want to separate
DHCPv4 server from the concentrator (For HA, redundancy...). With MAP
you cannot do this separation.

Yes, because MAP do= esn't require one to use another component like DHCPv4 which is in itse= lf subject to failure. That said, MAP can also use DHCPv4, but quite honest= ly what's the point of running DHCPv4 when all the useful info is avail= able via DHCPv6?
=A0
3) DHCPv4 is used to provision the address and port-set to the
intiator. Now with MAP you provide this as a rule in DHCPv6. That's
the most significant difference

So, I don't see lw4over6 provisioning more complicated than MAP...
<= /blockquote>

Current MAP =3D operating DHCPv6
l24over6 =3D=A0 o= perating DHCPv4 and DHCPv6 +=A0 mechanisms to get to the DHCPv4 server over= IPv6
There appears to be some evident complication there, for no clear benefit.<= br>
-Woj.
___________________________________= ____________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf3074d75821041c04c1f485bb-- From maxpassion@gmail.com Fri Jun 8 04:49: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 A7B9721F8903 for ; Fri, 8 Jun 2012 04:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qz7SP8ViW+J for ; Fri, 8 Jun 2012 04:49:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5179021F8907 for ; Fri, 8 Jun 2012 04:49:15 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2920317obb.31 for ; Fri, 08 Jun 2012 04:49:15 -0700 (PDT) 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:content-transfer-encoding; bh=cgyRS19oQUK+Q5AamvU9La/gvjcrZ9xeCttNURP0wtE=; b=UQtMh+I+pQhMKhmbhQFUBeBpKXmdwZ08XXXd1tNhjB0tlbsH/qmFfTaUehpoRVwEar Z6yU0OU4rMuw5K32rkMHE2Lxvw2bMkCsXDvVyuTGaHsTTRSC45x9T5xb7pxfdq9791EH 77guZxdvjxgQJWQJ6fiIKPAPvTQk1NNz0amwL0rHF5DPZbmhrol0UAQIqcReqK81GYrl Ln18ymFRxQ5JWIUmaREzZX1TB1LeF93jAsdHlLHVQs7ywGLmGxXGdYswtmhR+kkl155x awlWb9ZYnmndWmc7D2BxQ+ziskVGwkS0rE6QjmVW0wQ5AFZLe8MpvZTURNOJY6FqgiCE lAAA== MIME-Version: 1.0 Received: by 10.60.1.165 with SMTP id 5mr5819124oen.36.1339156154864; Fri, 08 Jun 2012 04:49:14 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Fri, 8 Jun 2012 04:49:14 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 8 Jun 2012 19:49:14 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 08 Jun 2012 11:49:16 -0000 2012/6/7, mohamed.boucadair@orange.com : > Dear Dapeng, > > Please see inline. > > Cheers; > Med > >>-----Message d'origine----- >>De : softwires-bounces@ietf.org >>[mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>Envoy=E9 : mardi 5 juin 2012 10:49 >>=C0 : Yong Cui >>Cc : softwires@ietf.org >>Objet : Re: [Softwires] WG last call on >>draft-ietf-softwire-stateless-4v6-motivation-01 >> >>Hello all, >> >>I am not sure this version resolves my concerns regarding the possible >>misleading by the word "stateless". To avoid this misleading, I >>suggest the following changes: >> >>1. Change the title to "Motivations for Carrier-side Stateless IPv4 >>over IPv6 Migration Solutions". Since this document is mainly about >>carrier-side stateless, the new title is more precise to reflect the >>content of this document. > > Med: Done. I updated my local copy with the proposed title. =3D=3D> Thanks >> >>2. Add a subsection in introduction, clarify that this document is >>only about carrier side stateless. > > Med: We have already this text in the introduction: > > Current standardization effort that is meant to address this IPv4 > service continuity issue focuses mainly on stateful mechanisms that > assume the sharing of any global IPv4 address that is left between > several customers, based upon the deployment of NAT (Network Address > Translation) capabilities in the network. Because of some caveats of > such stateful approaches the Service Provider community feels that a > companion effort is required to specify stateless IPv4 over IPv6 > approaches. This document provides elaboration on such need. > > Isn't this text sufficient enough? If not, it would helpful to propose a > sentence you want to be added to the introduction. How about adding the following sentences: ------- In many networks today, NAT44 functions is equipped on customer-edge device= . It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of =93stateless=94 terminology. This document provides elaboration on such need. ------- Thanks, Best regards, Dapeng Liu >> >>I would like to support it if the document was updated accordingly. >> > > Thanks. > --=20 ------ Best Regards, Dapeng Liu From mohamed.boucadair@orange.com Fri Jun 8 05:12:38 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 C1BAB21F86DD for ; Fri, 8 Jun 2012 05:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPsvytKHA0Kr for ; Fri, 8 Jun 2012 05:12:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 33AF121F86F1 for ; Fri, 8 Jun 2012 05:12:25 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 41E6618C7A8; Fri, 8 Jun 2012 14:12:24 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 17D9E27C053; Fri, 8 Jun 2012 14:12:24 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Fri, 8 Jun 2012 14:12:23 +0200 From: To: liu dapeng Date: Fri, 8 Jun 2012 14:12:22 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Thread-Index: Ac1FbL5Lqyq4Ac6ITcqFkmBEmTaCXwAAZnbA Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.5.24.112414 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 08 Jun 2012 12:12:38 -0000 Dear Dapeng, Please see inline. Cheers,=20 >-----Message d'origine----- >De : liu dapeng [mailto:maxpassion@gmail.com]=20 >Envoy=E9 : vendredi 8 juin 2012 13:49 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Yong Cui; softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-stateless-4v6-motivation-01 > >> >> Med: We have already this text in the introduction: >> >> Current standardization effort that is meant to address this IPv4 >> service continuity issue focuses mainly on stateful=20 >mechanisms that >> assume the sharing of any global IPv4 address that is left between >> several customers, based upon the deployment of NAT=20 >(Network Address >> Translation) capabilities in the network. Because of=20 >some caveats of >> such stateful approaches the Service Provider community=20 >feels that a >> companion effort is required to specify stateless IPv4 over IPv6 >> approaches. This document provides elaboration on such need. >> >> Isn't this text sufficient enough? If not, it would helpful=20 >to propose a >> sentence you want to be added to the introduction. > >How about adding the following sentences: > >------- >In many networks today, NAT44 functions is equipped on=20 >customer-edge device. >It may impact IPv4 over IPv6 solution to be a stateful solution from >end-to-end perspectives. The stateless solution also may subject to >NAT44 state. >In this document, we mainly refer this stateless paradigm to >large-scale address Sharing, i.e. carrier-side stateless IPv4 over >IPv6, which resolve the concern of "stateless" terminology. This >document provides elaboration on such need. >------- > Med: Thanks for the proposal. I shortened your proposal and updated the tex= t to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? = From despres.remi@laposte.net Fri Jun 8 05:36: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 ADFAE21F8838 for ; Fri, 8 Jun 2012 05:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMgFk58PORPf for ; Fri, 8 Jun 2012 05:36:44 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 93F6B21F8816 for ; Fri, 8 Jun 2012 05:36:16 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2213.sfr.fr (SMTP Server) with ESMTP id 185DE7000065; Fri, 8 Jun 2012 14:36:15 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2213.sfr.fr (SMTP Server) with ESMTP id 1E7467000057; Fri, 8 Jun 2012 14:36:14 +0200 (CEST) X-SFR-UUID: 20120608123614124.1E7467000057@msfrf2213.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 8 Jun 2012 14:36:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9AA089CB-4927-4D9C-8ADB-5F4CBCF33AB4@laposte.net> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> To: Peng Wu X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 12:36:44 -0000 Peng, 2012-06-07 =E0 16:04, Peng Wu: > Hi Ole and all, >=20 > Thank you all for the discussions on this topic, as well as sharing > your opinions during the offline discussions in the last couple of > days. Let me try to summarize. >=20 > I understand that we MAY adapt MAP to be 4over6-like, or even DS-lite > with more changes. It's actually a very interesting proposal. However, > in my understanding, the advantage of MAP is built on its > statelessness, with of cost of v4-v6 address coupling. If we mandate > MAP to further include the features of 4over6/DS-lite, we lose its > original generality: it's no longer stateless, the motivation document > won't work; GMA algorithm is no longer needed, no rule provisioning > anymore; we enforce a big bindng table on MAP BR. These are somehow > signifcant changes in implmentaton and deployement. >=20 > Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, > they have respective application scenarios, pros and cons. > 1)stateless, 4rd, MAP Thank you for having not forgotten that 4rd and MAP are on equal footing = in Softwire, something that seems to be forgotten more than needed on = this discussion thread.=20 Incidentally, while the WG draft on 4rd has been available since May 16, = the MAP specification, which was claimed in Paris to be well stabilized, = already tested, and urgent to be published, is still not available as a = WG draft. I therefore believe that discussing relationship between MAP = and/or 4rd and 4over6 would be more useful when an up-to-date MAP = specification is available. In any case, I renew my support for Public 4over6 to progress = autonomously. Regards, RD > 2)per-flow stateful: DS-Lite > 3)per-user stateful: public 4over6, lightweight 4over6 > As Ole said, the problem is that, do we want serveral simple > mechanisms, or one super-compatible mechanism with different modes. >=20 > Now Given that a) the WG has accomplished DS-lite; b)MAP follows the > stateless motivation all along the way; c)The signifcant changes to > make MAP super-compatible, I vote for we define the third type, > per-user stateful mechanisms independently. >=20 > Cheers, > Peng >=20 >=20 > On Thu, Jun 7, 2012 at 4:48 PM, Ole Tr=F8an = wrote: >> Qiong, >>=20 >>> If public 4over6 is one extreme case of MAP, in which one subscriber = represents one MAP domain, then should we also say that DS-Lite is = another extreme case of MAP, where one application (session) represents = one MAP domain ? >>=20 >> a DS-lite AFTR could be represented by the combination of a MAP BR = with per subscriber rules combined with a NAT44. there is a reason we = started out calling MAP for "Stateless DS-lite". >>=20 >>> I think we should still keep the initial feature of these solutions. >>=20 >> all the proposed solutions, including DS-lite shares a large set of = commonalities. where the differences are more operational considerations = and deployment choices than technical differences. do we need a separate = protocol specification for each deployment choice? >>=20 >> cheers, >> Ole >>=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 pengwu.thu@gmail.com Fri Jun 8 07:02: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 A138F21F86F2 for ; Fri, 8 Jun 2012 07:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO3uN8Tz8o3R for ; Fri, 8 Jun 2012 07:02:09 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE7B721F86E2 for ; Fri, 8 Jun 2012 07:02:00 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1029523qcs.31 for ; Fri, 08 Jun 2012 07:02:00 -0700 (PDT) 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:content-transfer-encoding; bh=A5WTMChvjK37an1uFaRgGRhYSx2XT/QalidNVp7gAN4=; b=R2HuMtmYwPFrzZ3urZJkLTiAbWLsBDj9cTHfUWD3TcQ4VggF6Ild3GtCdY5AwQ/jKj ggWiOWwLW+IzNd2b9+U6/mArdxlJyFXGQx3CyO2TAIcTirFWe41hi97wrgOcLin50NdA IQZ5eGQt0SXUnSgybn6ckCbOggxwcl8Cf0XtIl48LvMEKXJ/MOr0UBVUG72S7QwVPYNS o4UUK+H50g9dHSFSzp0yNghK3397aljzllafpGVaEn/+4LUOImr+6J2dfzkKXU8HO+25 H1BQAYf2m5ifng5A8TEGSTR0HSy4HcDe2jWNsDZfS9FtZ6R5WuE4TCxXL2Ica169D13s T5XA== MIME-Version: 1.0 Received: by 10.224.216.7 with SMTP id hg7mr4068794qab.3.1339164120045; Fri, 08 Jun 2012 07:02:00 -0700 (PDT) Received: by 10.229.30.203 with HTTP; Fri, 8 Jun 2012 07:01:59 -0700 (PDT) In-Reply-To: References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org> Date: Fri, 8 Jun 2012 22:01:59 +0800 Message-ID: From: Peng Wu To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 14:02:09 -0000 Woj, On Fri, Jun 8, 2012 at 7:44 PM, Wojciech Dec wrote: > Peng, > > On 8 June 2012 11:35, Peng Wu wrote: >> >> Ole, >> >> >> > btw, one thing that appears most complicated is provisioning; currentl= y >> > it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP option= s to >> > get provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel = up, >> > then a DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 >> > exchange to get the IPv4 address, and then a new DHCPv4 option to get = the >> > port set. that seems to me to be quite a few moving parts, and quiet a= few >> > corner cases to be specified when one or more of the above fails. in M= AP you >> > do all of that with one single DHCPv6 option... >> >> Let me make it more precise. >> >> In lw 4over6, It's one DHCPv6 exchange and one DHCPv4 exchange. >> DHCPv6 exchange to get the concentrator address and DHCPv4 server >> address, two options at the same time. And of course the DHCPv4 server >> could be collocated with the concentrator. >> DHCPv4 exchange to retrieve the address and port-set at the same time. >> >> Now compared with MAP: >> 1) Concentrator address is also needed in provisioning. >> 2) DHCPv4 server address. This is only used when we want to separate >> DHCPv4 server from the concentrator (For HA, redundancy...). With MAP >> you cannot do this separation. > > > Yes, because MAP doesn't require one to use another component like DHCPv4 > which is in itself subject to failure. That said, MAP can also use DHCPv4= , [Peng] PLEASE NOTE that I'm talking about concentrator/BR HA rather than DHCPv4 server HA. It applies to both lw 4over6 and MAP, as long as you want to implement per-user stateful mode by MAP > but quite honestly what's the point of running DHCPv4 when all the useful > info is available via DHCPv6? [Peng] You can use DHCPv6 in lw 4over6, too. We list it in the draft as a provisioning possibility. We explicitly use a DHCPv6 port-set option, while you use a MAP rule. But that's not the point. > >> >> 3) DHCPv4 is used to provision the address and port-set to the >> intiator. Now with MAP you provide this as a rule in DHCPv6. That's >> the most significant difference >> >> So, I don't see lw4over6 provisioning more complicated than MAP... > > > Current MAP =3D operating DHCPv6 > l24over6 =3D=A0 operating DHCPv4 and DHCPv6 +=A0 mechanisms to get to the= DHCPv4 > server over IPv6 > There appears to be some evident complication there, for no clear benefit= . [Peng] Well, the information amount are the same, with the MAP form a little difficult to understand from today's view, honestly. DHCPv4 is chosen because evidently we are provision IPv4 information, and we keep IPv4 and IPv6 addressing separated. In my understanding, the story in original MAP/4rd is because of the algorithmic mapping, you provision IPv4 address/port along with IPv6 address. Now you are talking about provison IPv4 as a rule. That's not exactly the same. Another question is that, how do you configure the rules in DHCPv6 now that it's per-user specific, and you do not have address mapping? Relay all DHCPv6 messages to BR and generate the rules dynamically there? I guess that's not a feature in original MAP. I want to say that, please develop your understanding on this problem from the fundamental per-user stateful feature, rather than directly from MAP, a solution initially not designed for this case. That's not fair. > > -Woj. >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > From jacni@jacni.com Fri Jun 8 07:39:43 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 CB67721F86D0 for ; Fri, 8 Jun 2012 07:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnQGg003eWkU for ; Fri, 8 Jun 2012 07:39:41 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 595EF21F88CF for ; Fri, 8 Jun 2012 07:39:40 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 2901A3800CF for ; Fri, 8 Jun 2012 10:39:39 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id C8D7B3400A0 for ; Fri, 8 Jun 2012 22:39:36 +0800 (CST) Received: from [192.168.1.105] (unknown [58.209.119.216]) by app (Coremail) with SMTP id +AWowJCrgQenDtJP4WMyAQ--.44482S2; Fri, 08 Jun 2012 22:39:36 +0800 (CST) Message-ID: <4FD20EA2.9080700@jacni.com> Date: Fri, 08 Jun 2012 22:39:30 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Simon Perreault References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> In-Reply-To: <4FCE051B.3060003@viagenie.ca> Content-Type: multipart/alternative; boundary="------------090103090209080603010100" X-CM-TRANSID: +AWowJCrgQenDtJP4WMyAQ--.44482S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZryDGrWruF43Cr1UXw15twb_yoW5ZFyUpa yDG3WxCFn7J3yxAw1kCw4IqryxCFn7Kr45JF9rJ3sxZws0grn7tF4Yy390gFy7ur18X3Wj qw4jvr45ur4qv3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07j6wZcUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQITEko7lRSF6gABsc Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 08 Jun 2012 14:39:43 -0000 This is a multi-part message in MIME format. --------------090103090209080603010100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Re-, On 6/5/2012 Tuesday 9:09 PM, Simon Perreault wrote: > On 2012-06-04 22:13, Jacni Qin wrote: >>> Section 6.1 introduces IGMP/MLD translation, but I fear it is very >>> underspecified. Our own effort at specifying IGMP/MLD translation is >>> in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite >>> multicast would be better served by referencing our draft instead. >>> >> Thanks for your comments, while as stated in the text, the Interworking >> function is a combination of proxying (RFC4605) and translation >> (draft-ietf-mboned-64-multicast-address-format, sorry the reference was >> lost, we'll fix it). > > I understand that. But note that this is an important new function. > AFAIK IGMP/MLD translation doesn't exist in any other RFC. Your draft > would be underspecifying it IMHO, possibly leading to interoperability > issues. To be honest, we've ever considered a separate draft to specify that function, but we finally dropped it in the last moment before submitting, since we realized during the preparation for the Demo in Taipei that it's actually not a new function, nor needs to be standardized anywhere, but more belongs to the scope of implementation. The implements vary, one example could be: have both IPv4 and IPv6 membership database maintained, then just synchronize the two through the address translation, all other things can be handled by the Proxying functionality (RFC4605). > > I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation. > >> The implementations vary, and we are trying to avoid deeply diving into >> that since it is sufficient for the implementers, and those should be >> detailed in some deployment document if needed. Anyway, please list what >> you think is missing, we can add more text to further clarify it. Thanks >> a lot! > > At IETF 83 I showed this list to the PIM working group to demonstrate > that IGMP/MLD translation is not as simple as people think it is. It's > a list of things our draft > (draft-perreault-mboned-igmp-mld-translation) specifies: > > - Well-known multicast address equivalences between IPv4 and IPv6. > - Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}. > - Translation needs to be performed logically on upstream interface of > proxy so as not to mess with Querier elections. > - Router Alert > - IPv4 option ? Hop-by-Hop IPv6 extension header > - Send on output IFF it was received on input. > - Set value to zero unconditionally. > - Reports with unspecified source address need to be handled > differently for IGMP vs MLD. > - Allocation of a "Translated" bit in IGMPv3 and MLDv2 Queries and > Reports. > - Formulas for the conversion of MRD?MRT with or without loss of > precision. > - Preservation of Additional and Auxiliary Data. > - MTU considerations... sigh > - Data plane handled according to RFC6145. > You are doing a protocol translation, which is just one possible kind of implementations, and it's true that what you list above are required if you want to go this way, IMHO it is a complicated one. As mentioned earlier, RFC4605 plus the address translation can also do that. And most columns you list will be avoid. While I'm happy to see a deployment document to discuss the issues of implementations. Cheers, Jacni --------------090103090209080603010100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-,

On 6/5/2012 Tuesday 9:09 PM, Simon Perreault wrote:
On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite
multicast would be better served by referencing our draft instead.

Thanks for your comments, while as stated in the text, the Interworking
function is a combination of proxying (RFC4605) and translation
(draft-ietf-mboned-64-multicast-address-format, sorry the reference was
lost, we'll fix it).

I understand that. But note that this is an important new function. AFAIK IGMP/MLD translation doesn't exist in any other RFC. Your draft would be underspecifying it IMHO, possibly leading to interoperability issues.

To be honest, we've ever considered a separate draft to specify that function, but we finally dropped it in the last moment before submitting, since we realized during the preparation for the Demo in Taipei that it's actually not a new function, nor needs to be standardized anywhere, but more belongs to the scope of implementation.

The implements vary, one example could be: have both IPv4 and IPv6 membership database maintained, then just synchronize the two through the address translation, all other things can be handled by the Proxying functionality (RFC4605).
 

I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation.

The implementations vary, and we are trying to avoid deeply diving into
that since it is sufficient for the implementers, and those should be
detailed in some deployment document if needed. Anyway, please list what
you think is missing, we can add more text to further clarify it. Thanks
a lot!

At IETF 83 I showed this list to the PIM working group to demonstrate that IGMP/MLD translation is not as simple as people think it is. It's a list of things our draft (draft-perreault-mboned-igmp-mld-translation) specifies:

- Well-known multicast address equivalences between IPv4 and IPv6.
- Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}.
- Translation needs to be performed logically on upstream interface of proxy so as not to mess with Querier elections.
- Router Alert
  - IPv4 option ↔ Hop-by-Hop IPv6 extension header
  - Send on output IFF it was received on input.
  - Set value to zero unconditionally.
- Reports with unspecified source address need to be handled differently for IGMP vs MLD.
- Allocation of a “Translated” bit in IGMPv3 and MLDv2 Queries and Reports.
- Formulas for the conversion of MRD↔MRT with or without loss of precision.
- Preservation of Additional and Auxiliary Data.
- MTU considerations... sigh
- Data plane handled according to RFC6145.


You are doing a protocol translation, which is just one possible kind of implementations, and it's true that what you list above are required if you want to go this way, IMHO it is a complicated one.
As mentioned earlier, RFC4605 plus the address translation can also do that. And most columns you list will be avoid.

While I'm happy to see a deployment document to discuss the issues of implementations.


Cheers,
Jacni


--------------090103090209080603010100-- From sarikaya2012@gmail.com Fri Jun 8 08:34: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 3990221F8568 for ; Fri, 8 Jun 2012 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.416 X-Spam-Level: X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAenEO4egqoy for ; Fri, 8 Jun 2012 08:34:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0249F21F8559 for ; Fri, 8 Jun 2012 08:34:49 -0700 (PDT) Received: by yenq13 with SMTP id q13so1579944yen.31 for ; Fri, 08 Jun 2012 08:34:49 -0700 (PDT) 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:content-transfer-encoding; bh=Z08As1gwbzJd2tsg8xwQXdmEE6ZLeASQ/39n2TeY5dk=; b=o0OMPENjO2nEHlJ2zRymuEjSmb33xx8JzDQ7lucc01fBiUgDzWCQNfDrnnFExOGyK1 U0ZZENNo+CeIgM29Ey93aiajCHQMS5lQKLYjxvJ9EuKnFWeIz2uHC2TtLc1QFn6t61o+ yiPa0b4/7QET3izjnXQQB6vEMIb7xKjNwZ55Z8ZGcOxXGCBXQ3CY/9rKmRAWvPxK/xWt 57VrKoUN3/zwLBfh0mmg5mYso191wjihEq5AUrI+YF5MrtXh+8UN8/b7/kWl352bNecl 0HLzRsunVGvS6D10k2PpFwoRADUvI0Y2x+E5ZmpcrUxQx2vI8kfdr/kxvUhRBKviNHJz Vfpg== MIME-Version: 1.0 Received: by 10.50.195.234 with SMTP id ih10mr3103157igc.0.1339169689391; Fri, 08 Jun 2012 08:34:49 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Fri, 8 Jun 2012 08:34:49 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 8 Jun 2012 10:34:49 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Fri, 08 Jun 2012 15:34:53 -0000 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM, wrote: > Hi Woj, > > Your comment is valid. > > The point I wanted to make is to recall the initial motivation of this > draft: solve an issue raised by DS-Lite people. > > Evidently, the proposed approach can be deployed in any 4-6-4 scenario. T= his > will be reflected in the updated version of the draft. > > Cheers, > Med > > ________________________________ > De=A0: Wojciech Dec [mailto:wdec.ietf@gmail.com] > Envoy=E9=A0: vendredi 8 juin 2012 09:57 > =C0=A0: BOUCADAIR Mohamed OLNC/NAD/TIP > Cc=A0: sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui > > Objet=A0: Re: [Softwires] WG last call on > draft-ietf-softwire-dslite-multicast-02 > > Hello Med, > > there is no dependency here on ds-lite, ie This has all the hallmarks of = a > standalone solution, which will almost certainly be implemented as such, = and > one that will work with or without ds-lite for unicast. > > Regards, > Woj. > > On 8 June 2012 07:48, wrote: >> >> Re-, >> >> May I re-iterate: >> >> * The draft is designed to allow the delivery of multicast services to >> DS-Lite serviced customers. >> * The draft proposes multicast extensions and not unicast ones. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> >Envoy=E9 : jeudi 7 juin 2012 20:20 >> >=C0 : Stig Venaas >> >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >> >Objet : Re: [Softwires] WG last call on >> >draft-ietf-softwire-dslite-multicast-02 >> > >> >On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas wrote: >> >> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >> >>> >> >>> On Thu, Jun 7, 2012 at 8:07 >> >AM, =A0wrote: >> >>>> >> > >> >>> So you are saying that this draft does not correspond to >> >>> Multicast extensions for DS-Lite? >> >> >> >> >> >> I sent a separate review, but anyway, it is not an extension to >> >> DS-Lite as I see it. It is a completely generic approach for >> >> tunneling v6 through v4. It can certainly be deployed in DS-Lite >> >> scenarios, but it is much more generic. I would like the title and >> >> the text to reflect that. >> > >> >So it means that this draft does not correspond to Softwire charter >> >item and we discover this quite late in the process. >> > >> >My recommendation to the chairs is to read and double check the draft >> >before making an adoption call, especially if there is choice. >> > >> >As I mentioned in my mboned mail, in multicast transition I think the >> >right approach is to agree to the fact that most of the host's >> >communication will be unicast. For unicast, v4-v6 transition has >> >already been well analyzed and several protocols have been specified. >> >Multicast extensions to those protocols are what we need. >> > >> >Regards, >> > >> >Behcet >> > >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > From ichiroumakino@gmail.com Fri Jun 8 09:31:46 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 6953F21F8804 for ; Fri, 8 Jun 2012 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDpz+IRGRj-3 for ; Fri, 8 Jun 2012 09:31:45 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86DDD21F8803 for ; Fri, 8 Jun 2012 09:31:45 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1615284eaa.31 for ; Fri, 08 Jun 2012 09:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mjNMWYo1xbQphbgnzats125FPIfqVWmdjAn+Bc2aLJI=; b=uw/0DrMsPL8sU10MNzL+iEXdddnPDwfqTaqP8gF8CVbfeRCWrKM1g6mSvR+YMHjmnC XW790APKOaGLQTAfhM+eSB65bgpMHRbH3/wckdaZ1k3+MqL0on2N8BH/ExtBzQ2UFQEB /UrtEZo+HGuoqZVdugMomwG6WX+B4dCrokk4kZAnLq7k/5G3MoWYPkRvOqMCYyFqNvOo rkUZ1sUViVcIg6i//NjcJWq0PdKcidBGIuhrFjGBsc/QSRVrO0OP7iUdecm8WD1ZzgyC hiN6l5UE+pJrxyEzpIKoHsV/b8MhF6BJyO7dKB2Ltom6NV0AhjlLDHB85tyYtgi1ROSI ibLA== Received: by 10.14.95.201 with SMTP id p49mr3962204eef.103.1339173104529; Fri, 08 Jun 2012 09:31:44 -0700 (PDT) Received: from dhcp-10-61-103-121.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n52sm23995069eeh.9.2012.06.08.09.31.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 09:31:43 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <9AA089CB-4927-4D9C-8ADB-5F4CBCF33AB4@laposte.net> Date: Fri, 8 Jun 2012 18:31:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84C925A2-8737-46C4-B5D7-54C2FB1EFB6E@employees.org> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> <9AA089CB-4927-4D9C-8ADB-5F4CBCF33AB4@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1278) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 16:31:46 -0000 Remi, > Incidentally, while the WG draft on 4rd has been available since May = 16, the MAP specification, which was claimed in Paris to be well = stabilized, already tested, and urgent to be published, is still not = available as a WG draft. I therefore believe that discussing = relationship between MAP and/or 4rd and 4over6 would be more useful when = an up-to-date MAP specification is available. since you specifically bring it up. the MAP draft was posted on June 1, and we are awaiting the softwire = chairs to approve it as a -00 softwire document. I expect they are busy as everyone else, but Alain promised to get to it = today. cheers, Ole From despres.remi@laposte.net Fri Jun 8 09:53: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 40D6411E8074 for ; Fri, 8 Jun 2012 09:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GwuMVvQS8-G for ; Fri, 8 Jun 2012 09:53:14 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id B964D21F8812 for ; Fri, 8 Jun 2012 09:52:53 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 4122C70000A4; Fri, 8 Jun 2012 18:52:52 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 4CC5D7000098; Fri, 8 Jun 2012 18:52:51 +0200 (CEST) X-SFR-UUID: 20120608165251314.4CC5D7000098@msfrf2117.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <84C925A2-8737-46C4-B5D7-54C2FB1EFB6E@employees.org> Date: Fri, 8 Jun 2012 18:52:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7693BA57-599D-40AB-9B5E-F80094DA7C23@laposte.net> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> <9AA089CB-4927-4D9C-8ADB-5F4CBCF33AB4@laposte.net> <84C925A2-8737-46C4-B5D7-54C2FB1EFB6E@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 16:53:16 -0000 Le 2012-06-08 =E0 18:31, Ole Tr=F8an a =E9crit : > Remi, >=20 >> Incidentally, while the WG draft on 4rd has been available since May = 16, the MAP specification, which was claimed in Paris to be well = stabilized, already tested, and urgent to be published, is still not = available as a WG draft. I therefore believe that discussing = relationship between MAP and/or 4rd and 4over6 would be more useful when = an up-to-date MAP specification is available. >=20 > since you specifically bring it up. > the MAP draft was posted on June 1, and we are awaiting the softwire = chairs to approve it as a -00 softwire document. >=20 > I expect they are busy as everyone else, but Alain promised to get to = it today. Thanks. RD >=20 > cheers, > Ole >=20 From stig@venaas.com Fri Jun 8 09:58: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 4872821F87AF for ; Fri, 8 Jun 2012 09:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AnVX418nVK4 for ; Fri, 8 Jun 2012 09:58:57 -0700 (PDT) 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 59D9121F87A8 for ; Fri, 8 Jun 2012 09:58:57 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 0B888805D; Fri, 8 Jun 2012 18:58:54 +0200 (CEST) Message-ID: <4FD22F48.9040807@venaas.com> Date: Fri, 08 Jun 2012 09:58:48 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" , Yong Cui , Behcet Sarikaya Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 08 Jun 2012 16:58:58 -0000 On 6/8/2012 8:34 AM, Behcet Sarikaya wrote: > Hi Med, > > I agree with Woj. > > I do not favor moving this draft to somewhere else. > > Instead this draft should be revised to make it > Multicast extensions to DS-Lite as in the charter. > > There is enough time to do it. As this draft shows though, one can provide multicast in a DS-Lite environment in an entirely generic way. I think that is great. It's much better to have a general solution. But this means the draft should be modified to reflect that. It is great to have a draft describing this. Whether charter or not or where it belongs is something I'm sure can be figured out. Right now I'm more concerned about getting a good document. Stig > > Regards, > > Behcet > > On Fri, Jun 8, 2012 at 3:43 AM, wrote: >> Hi Woj, >> >> Your comment is valid. >> >> The point I wanted to make is to recall the initial motivation of this >> draft: solve an issue raised by DS-Lite people. >> >> Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This >> will be reflected in the updated version of the draft. >> >> Cheers, >> Med >> >> ________________________________ >> De : Wojciech Dec [mailto:wdec.ietf@gmail.com] >> Envoyé : vendredi 8 juin 2012 09:57 >> À : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui >> >> Objet : Re: [Softwires] WG last call on >> draft-ietf-softwire-dslite-multicast-02 >> >> Hello Med, >> >> there is no dependency here on ds-lite, ie This has all the hallmarks of a >> standalone solution, which will almost certainly be implemented as such, and >> one that will work with or without ds-lite for unicast. >> >> Regards, >> Woj. >> >> On 8 June 2012 07:48, wrote: >>> >>> Re-, >>> >>> May I re-iterate: >>> >>> * The draft is designed to allow the delivery of multicast services to >>> DS-Lite serviced customers. >>> * The draft proposes multicast extensions and not unicast ones. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>> Envoyé : jeudi 7 juin 2012 20:20 >>>> À : Stig Venaas >>>> Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >>>> Objet : Re: [Softwires] WG last call on >>>> draft-ietf-softwire-dslite-multicast-02 >>>> >>>> On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas wrote: >>>>> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>>>>> >>>>>> On Thu, Jun 7, 2012 at 8:07 >>>> AM, wrote: >>>>>>> >>>> >>>>>> So you are saying that this draft does not correspond to >>>>>> Multicast extensions for DS-Lite? >>>>> >>>>> >>>>> I sent a separate review, but anyway, it is not an extension to >>>>> DS-Lite as I see it. It is a completely generic approach for >>>>> tunneling v6 through v4. It can certainly be deployed in DS-Lite >>>>> scenarios, but it is much more generic. I would like the title and >>>>> the text to reflect that. >>>> >>>> So it means that this draft does not correspond to Softwire charter >>>> item and we discover this quite late in the process. >>>> >>>> My recommendation to the chairs is to read and double check the draft >>>> before making an adoption call, especially if there is choice. >>>> >>>> As I mentioned in my mboned mail, in multicast transition I think the >>>> right approach is to agree to the fact that most of the host's >>>> communication will be unicast. For unicast, v4-v6 transition has >>>> already been well analyzed and several protocols have been specified. >>>> Multicast extensions to those protocols are what we need. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>> _______________________________________________ >>> 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 repenno@cisco.com Fri Jun 8 10:00: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 CFEB621F87BD for ; Fri, 8 Jun 2012 10:00:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNvbA+jMw1m5 for ; Fri, 8 Jun 2012 10:00:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 931E621F87B7 for ; Fri, 8 Jun 2012 10:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=6142; q=dns/txt; s=iport; t=1339174817; x=1340384417; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=bVOkANxCZs6SunK7jO914ZX74ZmUMkcX/i/c3nT55uY=; b=BFdwekKBuD32hZxYotjO4+eDKrsGrcx8zVUEPFXW9FCcselQWMQhhq5/ YHPaeksM/0lVKl7APeKgAg2wW2Xd454nUxXTnu3V/LGaPs92kZ1T4YAkG SXJF/7Ycx52BrmmnPXDhrebv0pGSDQCDb0wbC4FTzMqh9uiGecSjEdHKe Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ8u0k+tJXG//2dsb2JhbABFtFeBB4IYAQEBBAEBAQ8BKQExCwwHCBEEAQEBJygGHwkIBgENBRsHh1sDCwuZPZYNDYlOikVhhgADiA0zjF6BEoRBhSuDF4FmgwA X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="90798157" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 08 Jun 2012 17:00:17 +0000 Received: from [10.21.71.122] ([10.21.71.122]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q58H0AM8015352; Fri, 8 Jun 2012 17:00:13 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Fri, 08 Jun 2012 10:00:07 -0700 From: Reinaldo Penno To: , Peng Wu Message-ID: Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED1FE0@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 08 Jun 2012 17:00:18 -0000 Med, I'm glad we are in synch. That's exactly what I suggested Peng to do it. We can a single sentence in L46 to the effect: "If a full public IPv4 is given through DHCP no port set support is needed on CPE or concentrator. It is still up to the CPE if it wants to do NAT or not". Many DC scenarios use 1:1 NAT. Even DS-Lite can support public servers by using full port range port forwarding and disabling NAT. Thanks, Reinaldo On 6/7/12 10:58 PM, "mohamed.boucadair@orange.com" wrote: >Hi Peng, > >I vote for having one single document which covers both shared and full >IPv4 address.=20 > >If you start for instance from draft-cui-softwire-b4-translated-ds-lite, >what is needed is to add one sentence to say a full IPv4 address can be >provisioned. Does this make draft-cui-softwire-b4-translated-ds-lite more >complex? I don't think so. > >I really think we need all to do an effort of rationalizing the solutions >space.=20 > >Cheers, >Med=20 > >>-----Message d'origine----- >>De : Peng Wu [mailto:pengwu.thu@gmail.com] >>Envoy=E9 : jeudi 7 juin 2012 18:31 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : Yong Cui; softwires@ietf.org >>Objet : Re: [Softwires] WG last call on >>draft-ietf-softwire-public-4over6-01 >> >>Med, >> >>From protocol level, the difference between public 4over6 and >>lightweight 4over6(b4-translated-ds-lite) lies in port-set support. >>The extra efforts of lw 4over6 are as follows: (1) port set support in >>DHCP provisioning; (2) NAT on the initiator side.(whose address pool >>is not a full address but only a port set) (3) port-set supporting in >>the cocentrator's binding table. >> >>While we may cover public 4over6 by lightweight 4over6 with a special >>port set format (2^16 size) for (3), (1) and (2) brings quite >>significant changes to the intiator side. If I'm only a pb 4over6 >>initiator, more typically a host initiator, all the complexity needed >>is to plant a CRA process on the host, which is basically an IPv4 & >>IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already >>there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is >>already supported in today's OS. No NAT is needed in host case, and >>full e2e transparency is guaranteed. If we support this by lw 4over6, >>we implemented extra complexity which is not needed at all by the >>initiator. >> >>We have deployement scenarios which probably don't require address >>sharing, such as CERNET, and I guess maybe the ISPs in USA also do not >>have an IPv4 address shortage problem? >> >>So, aside from the fact that the pb 4over6 draft starts earlier and >>its status has been a step furher, this is a problem of choice: do we >>want two clean, simple mechanisms, or one mechanism trying to be >>compatible with both. >> >>On Thu, Jun 7, 2012 at 9:11 PM, wrote: >>> Dear all, >>> >>> I agree with Reinaldo. >>> >>> IMHO it makes sense to merge the two documents: either >>draft-ietf-softwire-public-4over6 be extended to cover >>draft-cui-softwire-b4-translated-ds-lite or add one or two >>sentences to draft-cui-softwire-b4-translated-ds-lite to >>mention a non-shared IPv4 address may be assigned. >>> >>> Doing so would help to rationalize the solution space and >>associated documents. We have the following main flavours: >>> >>> (1) Full stateful mode: DS-Lite >>> (2) Full stateless mode: MAP >>> (3) Per-customer state/binding mode: lw4o6 >>(draft-cui-softwire-b4-translated-ds-lite) >>> >>> All the three modes must support the ability to assign a >>full IPv4 address. >>> >>> Cheers, >>> Med >>> >>>>-----Message d'origine----- >>>>De : softwires-bounces@ietf.org >>>>[mailto:softwires-bounces@ietf.org] De la part de Reinaldo Penno >>>>Envoy=E9 : lundi 28 mai 2012 07:53 >>>>=C0 : Sheng Jiang; Yong Cui; softwires@ietf.org >>>>Objet : Re: [Softwires] WG last call on >>>>draft-ietf-softwire-public-4over6-01 >>>> >>>>-1 >>>> >>>>In which significant way this document is different from >>>>http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- >>>>lite-06 ? >>>> >>>>We can insert one paragraph in the above draft and allow >>>>public IPs since >>>>NAT is optional. The two documents even use DHCPv4ov6 as >>provisioning. >>>> >>>> >>>> >>>>On 5/27/12 6:32 PM, "Sheng Jiang" wrote: >>>> >>>>>The document looks mature for being advanced. >>>>> >>>>>Sheng Jiang >>>>> >>>>>> -----Original Message----- >>>>>> From: softwires-bounces@ietf.org >>>>[mailto:softwires-bounces@ietf.org] On >>>>>> Behalf Of Yong Cui >>>>>> Sent: Sunday, May 27, 2012 10:31 PM >>>>>> To: softwires@ietf.org >>>>>> Cc: Yong Cui >>>>>> Subject: [Softwires] WG last call on >>>>draft-ietf-softwire-public-4over6- >>>>>> 01 >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> This is a wg last call on draft-ietf-softwire-public-4over6-01. >>>>>> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >>>>>> >>>>>> As usual, please send editorial comments to the authors and >>>>>> substantive comments to the mailing list. >>>>>> >>>>>> This wg last call will end on 2012 June 10 at 12pm EDT. >>>>>> >>>>>> >>>>>> Yong & Alain >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>>_______________________________________________ >>>>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 >> >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From sarikaya2012@gmail.com Fri Jun 8 10:58:01 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 626CA21F8803 for ; Fri, 8 Jun 2012 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0UTWl8FUrap for ; Fri, 8 Jun 2012 10:58:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA0AD21F84EC for ; Fri, 8 Jun 2012 10:58:00 -0700 (PDT) Received: by yenq13 with SMTP id q13so1730119yen.31 for ; Fri, 08 Jun 2012 10:58:00 -0700 (PDT) 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=YyHh0CfUdVJID7s0l7epwdmRS3anoHul5bxsQLVNmb4=; b=mh8DFkgtN1L/+k/vfQQxq9r093Yi9LDti7zodUS9uHcXAGlRH1HeBKwJE0fiVkXkYi uxM4YHhNObCSgMtlG5yEfJI8rr3yhuqrHu7gP+P/YZpiNeWtnFa87GHWvTNxTKSn8fa/ HQ9ZjLiYv7otMaexCXslE/M9Ec8+cL9zdHlDrAWb+nPXC/o9r8MFDprrN4zp4Lg1SC8R DtQuYnu+PNLWjJ0zqFTY77tPNt3h+DVEC38xmQN6mdrX+LtkBjnPbLgHNPyJKny6vnYg f8OFkPN9EfSWYf1n0SVHQseABi5IpGIh+XH01o+jziNf/zWcQnkhQHeTRyUx0wMXAdcf kH3g== MIME-Version: 1.0 Received: by 10.50.40.193 with SMTP id z1mr3237021igk.0.1339178280093; Fri, 08 Jun 2012 10:58:00 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Fri, 8 Jun 2012 10:58:00 -0700 (PDT) In-Reply-To: <4FD22F48.9040807@venaas.com> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> <4FD22F48.9040807@venaas.com> Date: Fri, 8 Jun 2012 12:58:00 -0500 Message-ID: From: Behcet Sarikaya To: Stig Venaas Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Fri, 08 Jun 2012 17:58:01 -0000 On Fri, Jun 8, 2012 at 11:58 AM, Stig Venaas wrote: > On 6/8/2012 8:34 AM, Behcet Sarikaya wrote: >> >> Hi Med, >> >> I agree with Woj. >> >> I do not favor moving this draft to somewhere else. >> >> Instead this draft should be revised to make it >> Multicast extensions to DS-Lite as in the charter. >> >> There is enough time to do it. > > > As this draft shows though, one can provide multicast in a DS-Lite > environment in an entirely generic way. I think that is great. It's > much better to have a general solution. > > But this means the draft should be modified to reflect that. It is > great to have a draft describing this. A "general" solution using translation won't simply cut it for DS-Lite which is a tunneling protocol. No matter how hard you try. Behcet From stig@venaas.com Fri Jun 8 11:49: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 7AF8C11E80F1 for ; Fri, 8 Jun 2012 11:49:42 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiW78NSyP0Wg for ; Fri, 8 Jun 2012 11:49:42 -0700 (PDT) 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 E506211E80FC for ; Fri, 8 Jun 2012 11:49:41 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id B43757FAC; Fri, 8 Jun 2012 20:49:39 +0200 (CEST) Message-ID: <4FD24940.9000505@venaas.com> Date: Fri, 08 Jun 2012 11:49:36 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> <4FD22F48.9040807@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , Yong Cui , Behcet Sarikaya Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 08 Jun 2012 18:49:42 -0000 On 6/8/2012 10:58 AM, Behcet Sarikaya wrote: > On Fri, Jun 8, 2012 at 11:58 AM, Stig Venaas wrote: >> On 6/8/2012 8:34 AM, Behcet Sarikaya wrote: >>> >>> Hi Med, >>> >>> I agree with Woj. >>> >>> I do not favor moving this draft to somewhere else. >>> >>> Instead this draft should be revised to make it >>> Multicast extensions to DS-Lite as in the charter. >>> >>> There is enough time to do it. >> >> >> As this draft shows though, one can provide multicast in a DS-Lite >> environment in an entirely generic way. I think that is great. It's >> much better to have a general solution. >> >> But this means the draft should be modified to reflect that. It is >> great to have a draft describing this. > > A "general" solution using translation won't simply cut it for DS-Lite > which is a tunneling protocol. > No matter how hard you try. This draft specifies a general solution using tunneling, and it looks like a good solution to me. It also seems this general solution is what at least the authors think is suitable in a DS-Lite environment. This is all good. My main issue is that even though the draft specifies a general solution, the draft pretends it is a DS-Lite specific solution. Stig > > > > Behcet > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Fri Jun 8 14:30: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 59D4411E8183; Fri, 8 Jun 2012 14:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMQks01J4dVi; Fri, 8 Jun 2012 14:30:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC4611E80AE; Fri, 8 Jun 2012 14:30:32 -0700 (PDT) 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.02 Message-ID: <20120608213032.29686.80428.idtracker@ietfa.amsl.com> Date: Fri, 08 Jun 2012 14:30:32 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-00.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, 08 Jun 2012 21:30:33 -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 : Mapping of Address and Port (MAP) Author(s) : Ole Troan Wojciech Dec Xing Li Congxiao Bao Yu Zhai Satoru Matsushima Tetsuya Murakami Filename : draft-ietf-softwire-map-00.txt Pages : 33 Date : 2012-06-01 This document describes a mechanism for transporting IPv4 packets across an IPv6 network, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-map-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-map-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map/ From sunqi.csnet.thu@gmail.com Fri Jun 8 20:35: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 955A821F85AF for ; Fri, 8 Jun 2012 20:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLh8c9nQDXx3 for ; Fri, 8 Jun 2012 20:35:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F921F84E7 for ; Fri, 8 Jun 2012 20:35:32 -0700 (PDT) Received: by dacx6 with SMTP id x6so3124067dac.31 for ; Fri, 08 Jun 2012 20:35:31 -0700 (PDT) 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:content-transfer-encoding; bh=UsJu0MAiy4pHJu4+qce7+epd+OQB/1e6T+juDjUhNtw=; b=xTfjlnhSSgTtzLbyChOvMKi9NjvmWc6SvtzM4SeE31p6dK3m2fGESTPhoZqr3SVKic zJqk8tBhrLDwcZf5aDDo+zQ++PZ6x4Vxb8Fki80xcBpFtRqGYh7U0erqd4qKHRx8rBXK KfvZ8Sy2/nfWOIYvTwEyXE9eiWYNIRsf64o0IDhvljJZoil80YdxTqZJeANaMvhYGwrk vER4LhIbkkttjB9whn5C2Z+J7sdTCPMCO/3XTKhDXj9I4WQdqVLiIVz9VC+4sRknTIJ6 lC5xgiaIwAu8J9ZZxZBde2toRLYOmcOWI72oWzzVfBaWqj1NpH0blOID2p58NgtaiiO8 4V/A== MIME-Version: 1.0 Received: by 10.68.195.106 with SMTP id id10mr1902999pbc.116.1339212931753; Fri, 08 Jun 2012 20:35:31 -0700 (PDT) Received: by 10.142.105.1 with HTTP; Fri, 8 Jun 2012 20:35:31 -0700 (PDT) In-Reply-To: <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org> References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org> Date: Sat, 9 Jun 2012 11:35:31 +0800 Message-ID: From: Qi Sun To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 09 Jun 2012 03:35:44 -0000 Hi Ole, In your previous Email you wrote, > in MAP you do all of that with one single DHCPv6 option... IMHO, that's because the one DHCPv6 option contains so many KINDS of information (e.g. PSID, BR's prefix or address, see draft of map-dhcp-option ). And with separate provisoning processes , it's easier to detect problems if the whole process fails. Best Regards! Qi Sun On 6/8/12, Ole Tr=F8an wrote: > Peng, > >> Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, >> they have respective application scenarios, pros and cons. >> 1)stateless, 4rd, MAP >> 2)per-flow stateful: DS-Lite >> 3)per-user stateful: public 4over6, lightweight 4over6 >> As Ole said, the problem is that, do we want serveral simple >> mechanisms, or one super-compatible mechanism with different modes. >> >> Now Given that a) the WG has accomplished DS-lite; b)MAP follows the >> stateless motivation all along the way; c)The signifcant changes to >> make MAP super-compatible, I vote for we define the third type, >> per-user stateful mechanisms independently. > > actually there are no significant changes to the MAP specification, the > per-user stateful mechanism is just intrinsically supported by MAP. it is= a > corner case, and it would be more work in the specification to "ban" this > operational mode, than to support it. > > btw, one thing that appears most complicated is provisioning; currently i= t > looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to g= et > provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, the= n a > DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchange t= o > get the IPv4 address, and then a new DHCPv4 option to get the port set. t= hat > seems to me to be quite a few moving parts, and quiet a few corner cases = to > be specified when one or more of the above fails. in MAP you do all of th= at > with one single DHCPv6 option... > > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From sunqi.csnet.thu@gmail.com Fri Jun 8 21:16: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 48A0811E80D7 for ; Fri, 8 Jun 2012 21:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsCXCDHkX6sl for ; Fri, 8 Jun 2012 21:16:55 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B827511E8097 for ; Fri, 8 Jun 2012 21:16:55 -0700 (PDT) Received: by dacx6 with SMTP id x6so3149302dac.31 for ; Fri, 08 Jun 2012 21:16:55 -0700 (PDT) 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:content-transfer-encoding; bh=ZoBI2/pFlg7HYEd0l9Z4//hyirKSquMi4X/xNPrQGnE=; b=0bWRm4gBAr24zYGpvzitG9pBcYWewFboim7xqxkmCMOWx2Dghux3gEQEHg9xlptuO6 yXbdptO1WVVOI4Yb4a/6bEUoktvL7JikuTeHtqpR3g/cpg7r894gZPrqTf7dZHI5XUHf 8Oz0SnWD/atA6QS8qg8OJw+r7MdX8lOe4KrIcbKeI7r1WxomNPiwupE1vYD4MCtR5bDF t29TRpaymPpGVd+9Tlg3+BJSzd5XPOkVGxyY4PqdjA2wLgyB3vPV0K+JNwmEQhUjXrPK 1/gCoS8naZptBxUXQWyCc5VmZT565q4oLKUUCC9hmdKsN3JPQrrFikry2ntdbGsCQ/zC 8mjQ== MIME-Version: 1.0 Received: by 10.68.203.40 with SMTP id kn8mr1827932pbc.162.1339215415293; Fri, 08 Jun 2012 21:16:55 -0700 (PDT) Received: by 10.142.105.1 with HTTP; Fri, 8 Jun 2012 21:16:55 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E32ED1FE0@PUEXCB1B.nanterre.francetelecom.fr> Date: Sat, 9 Jun 2012 12:16:55 +0800 Message-ID: From: Qi Sun To: Reinaldo Penno Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 09 Jun 2012 04:16:57 -0000 Hi Reinado, IMHO, both MAP(Mapping of Address and PORT ) and lw4over6 DO NOT design to deal with full Ipv4 address case originally. In many senarios, users(like campanies, governments, ICPs and so on ) JUST want full addresses instead of shared addresses. It is more reasonable to have Public 4over6 to handle this. And Public 4over6 is matual enough to step forward without technical changes. Best Regards! Qi Sun On 6/9/12, Reinaldo Penno wrote: > Med, > > I'm glad we are in synch. That's exactly what I suggested Peng to do it. > We can a single sentence in L46 to the effect: > > "If a full public IPv4 is given through DHCP no port set support is neede= d > on CPE or concentrator. It is still up to the CPE if it wants to do NAT o= r > not". Many DC scenarios use 1:1 NAT. > > Even DS-Lite can support public servers by using full port range port > forwarding and disabling NAT. > > Thanks, > > Reinaldo > > On 6/7/12 10:58 PM, "mohamed.boucadair@orange.com" > wrote: > >>Hi Peng, >> >>I vote for having one single document which covers both shared and full >>IPv4 address. >> >>If you start for instance from draft-cui-softwire-b4-translated-ds-lite, >>what is needed is to add one sentence to say a full IPv4 address can be >>provisioned. Does this make draft-cui-softwire-b4-translated-ds-lite more >>complex? I don't think so. >> >>I really think we need all to do an effort of rationalizing the solutions >>space. >> >>Cheers, >>Med >> >>>-----Message d'origine----- >>>De : Peng Wu [mailto:pengwu.thu@gmail.com] >>>Envoy=E9 : jeudi 7 juin 2012 18:31 >>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>Cc : Yong Cui; softwires@ietf.org >>>Objet : Re: [Softwires] WG last call on >>>draft-ietf-softwire-public-4over6-01 >>> >>>Med, >>> >>>From protocol level, the difference between public 4over6 and >>>lightweight 4over6(b4-translated-ds-lite) lies in port-set support. >>>The extra efforts of lw 4over6 are as follows: (1) port set support in >>>DHCP provisioning; (2) NAT on the initiator side.(whose address pool >>>is not a full address but only a port set) (3) port-set supporting in >>>the cocentrator's binding table. >>> >>>While we may cover public 4over6 by lightweight 4over6 with a special >>>port set format (2^16 size) for (3), (1) and (2) brings quite >>>significant changes to the intiator side. If I'm only a pb 4over6 >>>initiator, more typically a host initiator, all the complexity needed >>>is to plant a CRA process on the host, which is basically an IPv4 & >>>IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already >>>there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is >>>already supported in today's OS. No NAT is needed in host case, and >>>full e2e transparency is guaranteed. If we support this by lw 4over6, >>>we implemented extra complexity which is not needed at all by the >>>initiator. >>> >>>We have deployement scenarios which probably don't require address >>>sharing, such as CERNET, and I guess maybe the ISPs in USA also do not >>>have an IPv4 address shortage problem? >>> >>>So, aside from the fact that the pb 4over6 draft starts earlier and >>>its status has been a step furher, this is a problem of choice: do we >>>want two clean, simple mechanisms, or one mechanism trying to be >>>compatible with both. >>> >>>On Thu, Jun 7, 2012 at 9:11 PM, wrote: >>>> Dear all, >>>> >>>> I agree with Reinaldo. >>>> >>>> IMHO it makes sense to merge the two documents: either >>>draft-ietf-softwire-public-4over6 be extended to cover >>>draft-cui-softwire-b4-translated-ds-lite or add one or two >>>sentences to draft-cui-softwire-b4-translated-ds-lite to >>>mention a non-shared IPv4 address may be assigned. >>>> >>>> Doing so would help to rationalize the solution space and >>>associated documents. We have the following main flavours: >>>> >>>> (1) Full stateful mode: DS-Lite >>>> (2) Full stateless mode: MAP >>>> (3) Per-customer state/binding mode: lw4o6 >>>(draft-cui-softwire-b4-translated-ds-lite) >>>> >>>> All the three modes must support the ability to assign a >>>full IPv4 address. >>>> >>>> Cheers, >>>> Med >>>> >>>>>-----Message d'origine----- >>>>>De : softwires-bounces@ietf.org >>>>>[mailto:softwires-bounces@ietf.org] De la part de Reinaldo Penno >>>>>Envoy=E9 : lundi 28 mai 2012 07:53 >>>>>=C0 : Sheng Jiang; Yong Cui; softwires@ietf.org >>>>>Objet : Re: [Softwires] WG last call on >>>>>draft-ietf-softwire-public-4over6-01 >>>>> >>>>>-1 >>>>> >>>>>In which significant way this document is different from >>>>>http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- >>>>>lite-06 ? >>>>> >>>>>We can insert one paragraph in the above draft and allow >>>>>public IPs since >>>>>NAT is optional. The two documents even use DHCPv4ov6 as >>>provisioning. >>>>> >>>>> >>>>> >>>>>On 5/27/12 6:32 PM, "Sheng Jiang" wrote: >>>>> >>>>>>The document looks mature for being advanced. >>>>>> >>>>>>Sheng Jiang >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: softwires-bounces@ietf.org >>>>>[mailto:softwires-bounces@ietf.org] On >>>>>>> Behalf Of Yong Cui >>>>>>> Sent: Sunday, May 27, 2012 10:31 PM >>>>>>> To: softwires@ietf.org >>>>>>> Cc: Yong Cui >>>>>>> Subject: [Softwires] WG last call on >>>>>draft-ietf-softwire-public-4over6- >>>>>>> 01 >>>>>>> >>>>>>> Hi folks, >>>>>>> >>>>>>> This is a wg last call on draft-ietf-softwire-public-4over6-01. >>>>>>> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >>>>>>> >>>>>>> As usual, please send editorial comments to the authors and >>>>>>> substantive comments to the mailing list. >>>>>>> >>>>>>> This wg last call will end on 2012 June 10 at 12pm EDT. >>>>>>> >>>>>>> >>>>>>> Yong & Alain >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> >>>>>_______________________________________________ >>>>>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 >>> >>_______________________________________________ >>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 maxpassion@gmail.com Sun Jun 10 20:46: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 757CA21F84D8 for ; Sun, 10 Jun 2012 20:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAz4fP5ZQxMC for ; Sun, 10 Jun 2012 20:46:56 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D2A6B21F84BF for ; Sun, 10 Jun 2012 20:46:56 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8618984obb.31 for ; Sun, 10 Jun 2012 20:46:56 -0700 (PDT) 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:content-transfer-encoding; bh=vMTwjpUDPc35TTXHpKGpFWFW1maTQxksyWIOuvqjmGM=; b=A+M1ouE3Vw+mJNYRUAVRcMuWYP3+FK3Emec79QpHzsurf3tgHobrmllnlXwxT0fFQX GVWZY4Yyjw/5BiPR2WH4tflvoOZO8mkRLqst0pzFS2UC/ZaYyAeHlhVLfhBCUud98EyS 5c8IhRg1h2fvOBroDt7nN5v1+tssPMNCeISL0WvUV+d/YBwqVqtr7rwt91BIVfkG3rDl Zs3nLklTrecxjczPTxRgQ6hN3ewmPoIz2yIyVneu4lX0YTxs4LRs2GlyKbORHu3qHZVO FNT8Ck4LNCUBvy3uD8bwF5ZQ1V+PUgk9dMAUpkYGb2EJHQDbDEQGOGmPD1PzRC3u9n8k AV+Q== MIME-Version: 1.0 Received: by 10.60.28.162 with SMTP id c2mr15010958oeh.3.1339386416445; Sun, 10 Jun 2012 20:46:56 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Sun, 10 Jun 2012 20:46:56 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 11 Jun 2012 11:46:56 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 03:46:57 -0000 Hi Med: 2012/6/8, mohamed.boucadair@orange.com : > Dear Dapeng, > > Please see inline. > > Cheers, > >>-----Message d'origine----- >>De : liu dapeng [mailto:maxpassion@gmail.com] >>Envoy=E9 : vendredi 8 juin 2012 13:49 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : Yong Cui; softwires@ietf.org >>Objet : Re: [Softwires] WG last call on >>draft-ietf-softwire-stateless-4v6-motivation-01 >> >>> >>> Med: We have already this text in the introduction: >>> >>> Current standardization effort that is meant to address this IPv4 >>> service continuity issue focuses mainly on stateful >>mechanisms that >>> assume the sharing of any global IPv4 address that is left between >>> several customers, based upon the deployment of NAT >>(Network Address >>> Translation) capabilities in the network. Because of >>some caveats of >>> such stateful approaches the Service Provider community >>feels that a >>> companion effort is required to specify stateless IPv4 over IPv6 >>> approaches. This document provides elaboration on such need. >>> >>> Isn't this text sufficient enough? If not, it would helpful >>to propose a >>> sentence you want to be added to the introduction. >> >>How about adding the following sentences: >> >>------- >>In many networks today, NAT44 functions is equipped on >>customer-edge device. >>It may impact IPv4 over IPv6 solution to be a stateful solution from >>end-to-end perspectives. The stateless solution also may subject to >>NAT44 state. >>In this document, we mainly refer this stateless paradigm to >>large-scale address Sharing, i.e. carrier-side stateless IPv4 over >>IPv6, which resolve the concern of "stateless" terminology. This >>document provides elaboration on such need. >>------- >> > > Med: Thanks for the proposal. I shortened your proposal and updated the t= ext > to: > > > Current standardization effort that is meant to address this IPv4 > service continuity issue focuses mainly on stateful mechanisms that > assume the sharing of any global IPv4 address that is left between > several customers, based upon the deployment of NAT (Network Address > Translation) capabilities in the network. Because of some caveats of > such stateful approaches the Service Provider community feels that a > companion effort is required to specify stateless IPv4 over IPv6 > approaches. Note stateless IPv4 over IPv6 solutions may be enabled > in conjunction with a port-restricted NAT44 function located in the > customer premises. > > This document provides elaboration on the need for carrier-side > stateless IPv4 over IPv6 solution. > > > Are you OK with this new text? [Dapeng]=3D=3D> I make a minor change of the last two sentences: --------- Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. --------- Besides, how about changing all the terminology "stateless" to "carrier-side stateless" in the document? Thanks, Best Regards, Dapeng Liu > > --=20 ------ Best Regards, Dapeng Liu From rajiva@cisco.com Sun Jun 10 21:26:31 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 2B95121F8491 for ; Sun, 10 Jun 2012 21:26:31 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtxmsZ6HU3iX for ; Sun, 10 Jun 2012 21:26:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3B02821F847F for ; Sun, 10 Jun 2012 21:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4770; q=dns/txt; s=iport; t=1339388790; x=1340598390; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4wxLiAqg8Ihl5HnHefuBqLbOBdwux/S9okEX6v5RKOw=; b=VEjeZQpJhfXqnJWX6kZFK27VtFgW8+Cp9zASq+v6H0ZnckdwvYGd+VN7 hrYQEw1iM4/hIkL0q0BF4QEmo2k0mVOktWWxFWKwtanLSTT3RJwGwRUpP donTQj9mWnkmTSXe61/BLz+2MIuoITvESMTDUDw/48YGYdGxlpMfkziY2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMZy1U+tJV2c/2dsb2JhbABFtFuBB4IYAQEBBAEBAQ8BHTcHCwwEAgEIEQQBAQsGFwEGASAGHwkIAQEEARIIDAcHh1sDCwuYIZUxDYlKBIpGYYUJYAOIDTOXXIMXgWaCfg X-IronPort-AV: E=Sophos;i="4.75,748,1330905600"; d="scan'208";a="91230430" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jun 2012 04:26:29 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5B4QTsx006970; Mon, 11 Jun 2012 04:26:29 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Jun 2012 23:26:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Jun 2012 23:26:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] WG last call ondraft-ietf-softwire-stateless-4v6-motivation-01 Thread-Index: Ac1HhN0x5ULuXmKoQ4m8vubLxqciTQABRDWg References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr><94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> From: "Rajiv Asati (rajiva)" To: "liu dapeng" , X-OriginalArrivalTime: 11 Jun 2012 04:26:29.0480 (UTC) FILETIME=[5F600680:01CD478A] Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call ondraft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 04:26:31 -0000 I am not fond of the proposed change.=20 After all, most of the other documents refer to stateful without taking = a "side" (e.g. carrier-side), and so this document should state = stateless in the same regard. Of course, where it makes sense to clarify, it must be clarified that = stateless is in the carrier-side, with or without stateful NAT44 in the = customer-side. We must not make the assumption that stateless and = stateful go together, though they will likely. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On > Behalf Of liu dapeng > Sent: Sunday, June 10, 2012 11:47 PM > To: mohamed.boucadair@orange.com > Cc: softwires@ietf.org; Yong Cui > Subject: Re: [Softwires] WG last call = ondraft-ietf-softwire-stateless-4v6- > motivation-01 >=20 > Hi Med: >=20 > 2012/6/8, mohamed.boucadair@orange.com > : > > Dear Dapeng, > > > > Please see inline. > > > > Cheers, > > > >>-----Message d'origine----- > >>De : liu dapeng [mailto:maxpassion@gmail.com] Envoy=E9 : vendredi 8 = juin > >>2012 13:49 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; > >>softwires@ietf.org Objet : Re: [Softwires] WG last call on > >>draft-ietf-softwire-stateless-4v6-motivation-01 > >> > >>> > >>> Med: We have already this text in the introduction: > >>> > >>> Current standardization effort that is meant to address this = IPv4 > >>> service continuity issue focuses mainly on stateful > >>mechanisms that > >>> assume the sharing of any global IPv4 address that is left = between > >>> several customers, based upon the deployment of NAT > >>(Network Address > >>> Translation) capabilities in the network. Because of > >>some caveats of > >>> such stateful approaches the Service Provider community > >>feels that a > >>> companion effort is required to specify stateless IPv4 over = IPv6 > >>> approaches. This document provides elaboration on such need. > >>> > >>> Isn't this text sufficient enough? If not, it would helpful > >>to propose a > >>> sentence you want to be added to the introduction. > >> > >>How about adding the following sentences: > >> > >>------- > >>In many networks today, NAT44 functions is equipped on customer-edge > >>device. > >>It may impact IPv4 over IPv6 solution to be a stateful solution from > >>end-to-end perspectives. The stateless solution also may subject to > >>NAT44 state. > >>In this document, we mainly refer this stateless paradigm to > >>large-scale address Sharing, i.e. carrier-side stateless IPv4 over > >>IPv6, which resolve the concern of "stateless" terminology. This > >>document provides elaboration on such need. > >>------- > >> > > > > Med: Thanks for the proposal. I shortened your proposal and updated > > the text > > to: > > > > > > Current standardization effort that is meant to address this IPv4 > > service continuity issue focuses mainly on stateful mechanisms = that > > assume the sharing of any global IPv4 address that is left = between > > several customers, based upon the deployment of NAT (Network > Address > > Translation) capabilities in the network. Because of some = caveats of > > such stateful approaches the Service Provider community feels = that a > > companion effort is required to specify stateless IPv4 over IPv6 > > approaches. Note stateless IPv4 over IPv6 solutions may be = enabled > > in conjunction with a port-restricted NAT44 function located in = the > > customer premises. > > > > This document provides elaboration on the need for carrier-side > > stateless IPv4 over IPv6 solution. > > > > > > Are you OK with this new text? >=20 > [Dapeng]=3D=3D> > I make a minor change of the last two sentences: > --------- > Because of some caveats of such stateful approaches the Service = Provider > community feels that a companion effort is required to specify = carrier-side > stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 = over > IPv6 solutions may be enabled in conjunction with a port-restricted = NAT44 > function located in the customer premises or port translation in the = host > and that is still stateful in the whole. > --------- >=20 > Besides, how about changing all the terminology "stateless" to = "carrier-side > stateless" in the document? >=20 >=20 > Thanks, > Best Regards, > Dapeng Liu >=20 >=20 >=20 >=20 > > > > >=20 >=20 > -- >=20 > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From mohamed.boucadair@orange.com Sun Jun 10 23:05:38 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 9565811E8079 for ; Sun, 10 Jun 2012 23:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di3US+MYW5fO for ; Sun, 10 Jun 2012 23:05:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AFD4711E8072 for ; Sun, 10 Jun 2012 23:05:37 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id BCB183B427E; Mon, 11 Jun 2012 08:05:34 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9F29F238056; Mon, 11 Jun 2012 08:05:34 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 11 Jun 2012 08:05:34 +0200 From: To: liu dapeng Date: Mon, 11 Jun 2012 08:05:33 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Thread-Index: Ac1HhNn0YWaPtGk/SNOkbribD44ZQgAEoAhQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FE853@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.6.11.45416 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 06:05:38 -0000 Hi Dapeng, A state maintained in the endpoint does not make the solution stateful, see= this excerpt from RFC1958: This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). I didn't considered your last proposed changes for the reason mentioned abo= ve.=20 Thank you for your help. Cheers, Med=20 >-----Message d'origine----- >De : liu dapeng [mailto:maxpassion@gmail.com]=20 >Envoy=E9 : lundi 11 juin 2012 05:47 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Yong Cui; softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-stateless-4v6-motivation-01 > >Hi Med: > >2012/6/8, mohamed.boucadair@orange.com : >> Dear Dapeng, >> >> Please see inline. >> >> Cheers, >> >>>-----Message d'origine----- >>>De : liu dapeng [mailto:maxpassion@gmail.com] >>>Envoy=E9 : vendredi 8 juin 2012 13:49 >>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>Cc : Yong Cui; softwires@ietf.org >>>Objet : Re: [Softwires] WG last call on >>>draft-ietf-softwire-stateless-4v6-motivation-01 >>> >>>> >>>> Med: We have already this text in the introduction: >>>> >>>> Current standardization effort that is meant to address=20 >this IPv4 >>>> service continuity issue focuses mainly on stateful >>>mechanisms that >>>> assume the sharing of any global IPv4 address that is=20 >left between >>>> several customers, based upon the deployment of NAT >>>(Network Address >>>> Translation) capabilities in the network. Because of >>>some caveats of >>>> such stateful approaches the Service Provider community >>>feels that a >>>> companion effort is required to specify stateless IPv4 over IPv6 >>>> approaches. This document provides elaboration on such need. >>>> >>>> Isn't this text sufficient enough? If not, it would helpful >>>to propose a >>>> sentence you want to be added to the introduction. >>> >>>How about adding the following sentences: >>> >>>------- >>>In many networks today, NAT44 functions is equipped on >>>customer-edge device. >>>It may impact IPv4 over IPv6 solution to be a stateful solution from >>>end-to-end perspectives. The stateless solution also may subject to >>>NAT44 state. >>>In this document, we mainly refer this stateless paradigm to >>>large-scale address Sharing, i.e. carrier-side stateless IPv4 over >>>IPv6, which resolve the concern of "stateless" terminology. This >>>document provides elaboration on such need. >>>------- >>> >> >> Med: Thanks for the proposal. I shortened your proposal and=20 >updated the text >> to: >> >> >> Current standardization effort that is meant to address this IPv4 >> service continuity issue focuses mainly on stateful=20 >mechanisms that >> assume the sharing of any global IPv4 address that is left between >> several customers, based upon the deployment of NAT=20 >(Network Address >> Translation) capabilities in the network. Because of=20 >some caveats of >> such stateful approaches the Service Provider community=20 >feels that a >> companion effort is required to specify stateless IPv4 over IPv6 >> approaches. Note stateless IPv4 over IPv6 solutions may=20 >be enabled >> in conjunction with a port-restricted NAT44 function=20 >located in the >> customer premises. >> >> This document provides elaboration on the need for carrier-side >> stateless IPv4 over IPv6 solution. >> >> >> Are you OK with this new text? > >[Dapeng]=3D=3D> >I make a minor change of the last two sentences: >--------- >Because of some caveats of such stateful approaches the Service >Provider community feels that a companion effort is required to >specify carrier-side stateless IPv4 over IPv6 approaches. Note >carrier-side stateless IPv4 over IPv6 solutions may be enabled in >conjunction with a port-restricted NAT44 function located in the >customer premises or port translation in the host and that is still >stateful in the whole. >--------- > >Besides, how about changing all the terminology "stateless" to >"carrier-side stateless" in the document? > > >Thanks, >Best Regards, >Dapeng Liu > > > > >> >> > > >--=20 > >------ >Best Regards, >Dapeng Liu >= From maxpassion@gmail.com Sun Jun 10 23:10: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 25D8211E8072 for ; Sun, 10 Jun 2012 23:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU9oaVK2Wc5q for ; Sun, 10 Jun 2012 23:10:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5AD11E8085 for ; Sun, 10 Jun 2012 23:10:28 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8834276obb.31 for ; Sun, 10 Jun 2012 23:10:28 -0700 (PDT) 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:content-transfer-encoding; bh=adkURgMszsPK4WpZprsTuD45qKJChDIxc0/LB+3mXME=; b=avazdUJHI1KPKqwEPXLBgJtkmSOIMztWbXM1IL6PNmaosnSuADeBgxWCbTi+ARtfCG 1F4NHW30X9venIJlxIMVjDW9dHU+72Gst38KJ09WUoLfwAUPQYV12URkVgQkN3LT4wxS n0uKcn7cVM5ypa0GkSTMnHnCmxX3a83x69JC0Ow7vzRdrfV8tvdU0y7jiLkXOxtsgQq4 CzmlanEbjYZH3ngTbwz06SWbAp/OcBEDgSC6K+tg1MSuJKvm7YMQYSLySPvP+j9R3ImU q2e5D47yEgtY3vWDvWiYE+J9EelMqKIaVEwJG/epj53J6/8GhA7demLHj0Ftzkn5jSv9 QtHg== MIME-Version: 1.0 Received: by 10.182.48.100 with SMTP id k4mr15027416obn.21.1339395028521; Sun, 10 Jun 2012 23:10:28 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Sun, 10 Jun 2012 23:10:28 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 11 Jun 2012 14:10:28 +0800 Message-ID: From: liu dapeng To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call ondraft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 06:10:30 -0000 I would prefer IETF more strict about what accurate terminology we are using other than favorite. At this moment this document go through working group last call which I have reviewed, and believe it should be Revised for not misleading other people. Thanks for your suggestion. Regards, Dapeng Liu 2012/6/11, Rajiv Asati (rajiva) : > I am not fond of the proposed change. > > After all, most of the other documents refer to stateful without taking a > "side" (e.g. carrier-side), and so this document should state stateless i= n > the same regard. > > Of course, where it makes sense to clarify, it must be clarified that > stateless is in the carrier-side, with or without stateful NAT44 in the > customer-side. We must not make the assumption that stateless and statefu= l > go together, though they will likely. > > Cheers, > Rajiv > > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >> Behalf Of liu dapeng >> Sent: Sunday, June 10, 2012 11:47 PM >> To: mohamed.boucadair@orange.com >> Cc: softwires@ietf.org; Yong Cui >> Subject: Re: [Softwires] WG last call >> ondraft-ietf-softwire-stateless-4v6- >> motivation-01 >> >> Hi Med: >> >> 2012/6/8, mohamed.boucadair@orange.com >> : >> > Dear Dapeng, >> > >> > Please see inline. >> > >> > Cheers, >> > >> >>-----Message d'origine----- >> >>De : liu dapeng [mailto:maxpassion@gmail.com] Envoy=E9 : vendredi 8 ju= in >> >>2012 13:49 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; >> >>softwires@ietf.org Objet : Re: [Softwires] WG last call on >> >>draft-ietf-softwire-stateless-4v6-motivation-01 >> >> >> >>> >> >>> Med: We have already this text in the introduction: >> >>> >> >>> Current standardization effort that is meant to address this IPv4 >> >>> service continuity issue focuses mainly on stateful >> >>mechanisms that >> >>> assume the sharing of any global IPv4 address that is left betwee= n >> >>> several customers, based upon the deployment of NAT >> >>(Network Address >> >>> Translation) capabilities in the network. Because of >> >>some caveats of >> >>> such stateful approaches the Service Provider community >> >>feels that a >> >>> companion effort is required to specify stateless IPv4 over IPv6 >> >>> approaches. This document provides elaboration on such need. >> >>> >> >>> Isn't this text sufficient enough? If not, it would helpful >> >>to propose a >> >>> sentence you want to be added to the introduction. >> >> >> >>How about adding the following sentences: >> >> >> >>------- >> >>In many networks today, NAT44 functions is equipped on customer-edge >> >>device. >> >>It may impact IPv4 over IPv6 solution to be a stateful solution from >> >>end-to-end perspectives. The stateless solution also may subject to >> >>NAT44 state. >> >>In this document, we mainly refer this stateless paradigm to >> >>large-scale address Sharing, i.e. carrier-side stateless IPv4 over >> >>IPv6, which resolve the concern of "stateless" terminology. This >> >>document provides elaboration on such need. >> >>------- >> >> >> > >> > Med: Thanks for the proposal. I shortened your proposal and updated >> > the text >> > to: >> > >> > >> > Current standardization effort that is meant to address this IPv4 >> > service continuity issue focuses mainly on stateful mechanisms that >> > assume the sharing of any global IPv4 address that is left between >> > several customers, based upon the deployment of NAT (Network >> Address >> > Translation) capabilities in the network. Because of some caveats >> > of >> > such stateful approaches the Service Provider community feels that = a >> > companion effort is required to specify stateless IPv4 over IPv6 >> > approaches. Note stateless IPv4 over IPv6 solutions may be enabled >> > in conjunction with a port-restricted NAT44 function located in the >> > customer premises. >> > >> > This document provides elaboration on the need for carrier-side >> > stateless IPv4 over IPv6 solution. >> > >> > >> > Are you OK with this new text? >> >> [Dapeng]=3D=3D> >> I make a minor change of the last two sentences: >> --------- >> Because of some caveats of such stateful approaches the Service Provider >> community feels that a companion effort is required to specify >> carrier-side >> stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 >> over >> IPv6 solutions may be enabled in conjunction with a port-restricted NAT4= 4 >> function located in the customer premises or port translation in the hos= t >> and that is still stateful in the whole. >> --------- >> >> Besides, how about changing all the terminology "stateless" to >> "carrier-side >> stateless" in the document? >> >> >> Thanks, >> Best Regards, >> Dapeng Liu >> >> >> >> >> > >> > >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > --=20 ------ Best Regards, Dapeng Liu From mohamed.boucadair@orange.com Sun Jun 10 23:15: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 A9AB511E8073 for ; Sun, 10 Jun 2012 23:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNDf1VgjQoRf for ; Sun, 10 Jun 2012 23:15:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 98BF411E8072 for ; Sun, 10 Jun 2012 23:15:52 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 02B323242B0; Mon, 11 Jun 2012 08:15:52 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D5416238056; Mon, 11 Jun 2012 08:15:51 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 11 Jun 2012 08:15:51 +0200 From: To: "sarikaya@ieee.org" Date: Mon, 11 Jun 2012 08:15:50 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1FjD8JIuEeUJK+SUaPNml9jhzG5wCDOmYw Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FE855@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.6.11.45416 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 11 Jun 2012 06:15:53 -0000 Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lit= e serviced customers * we rely on multicast capabilities, as such no AMT-like considerations are= included * the proposed solution is generic and can be deployed in any 4-6-4 use cas= e What should be revised? Thanks for your help. Cheers, Med=20 >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : vendredi 8 juin 2012 17:35 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-dslite-multicast-02 > >Hi Med, > >I agree with Woj. > >I do not favor moving this draft to somewhere else. > >Instead this draft should be revised to make it >Multicast extensions to DS-Lite as in the charter. > >There is enough time to do it. > >Regards, > >Behcet > >On Fri, Jun 8, 2012 at 3:43 AM, wrote: >> Hi Woj, >> >> Your comment is valid. >> >> The point I wanted to make is to recall the initial=20 >motivation of this >> draft: solve an issue raised by DS-Lite people. >> >> Evidently, the proposed approach can be deployed in any=20 >4-6-4 scenario. This >> will be reflected in the updated version of the draft. >> >> Cheers, >> Med >> >> ________________________________ >> De=A0: Wojciech Dec [mailto:wdec.ietf@gmail.com] >> Envoy=E9=A0: vendredi 8 juin 2012 09:57 >> =C0=A0: BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc=A0: sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui >> >> Objet=A0: Re: [Softwires] WG last call on >> draft-ietf-softwire-dslite-multicast-02 >> >> Hello Med, >> >> there is no dependency here on ds-lite, ie This has all the=20 >hallmarks of a >> standalone solution, which will almost certainly be=20 >implemented as such, and >> one that will work with or without ds-lite for unicast. >> >> Regards, >> Woj. >> >> On 8 June 2012 07:48, wrote: >>> >>> Re-, >>> >>> May I re-iterate: >>> >>> * The draft is designed to allow the delivery of multicast=20 >services to >>> DS-Lite serviced customers. >>> * The draft proposes multicast extensions and not unicast ones. >>> >>> Cheers, >>> Med >>> >>> >-----Message d'origine----- >>> >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>> >Envoy=E9 : jeudi 7 juin 2012 20:20 >>> >=C0 : Stig Venaas >>> >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >>> >Objet : Re: [Softwires] WG last call on >>> >draft-ietf-softwire-dslite-multicast-02 >>> > >>> >On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas=20 > wrote: >>> >> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>> >>> >>> >>> On Thu, Jun 7, 2012 at 8:07 >>> >AM, =A0wrote: >>> >>>> >>> > >>> >>> So you are saying that this draft does not correspond to >>> >>> Multicast extensions for DS-Lite? >>> >> >>> >> >>> >> I sent a separate review, but anyway, it is not an extension to >>> >> DS-Lite as I see it. It is a completely generic approach for >>> >> tunneling v6 through v4. It can certainly be deployed in DS-Lite >>> >> scenarios, but it is much more generic. I would like the=20 >title and >>> >> the text to reflect that. >>> > >>> >So it means that this draft does not correspond to Softwire charter >>> >item and we discover this quite late in the process. >>> > >>> >My recommendation to the chairs is to read and double=20 >check the draft >>> >before making an adoption call, especially if there is choice. >>> > >>> >As I mentioned in my mboned mail, in multicast transition=20 >I think the >>> >right approach is to agree to the fact that most of the host's >>> >communication will be unicast. For unicast, v4-v6 transition has >>> >already been well analyzed and several protocols have been=20 >specified. >>> >Multicast extensions to those protocols are what we need. >>> > >>> >Regards, >>> > >>> >Behcet >>> > >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> >> >= From maxpassion@gmail.com Mon Jun 11 00:10: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 819D721F846D for ; Mon, 11 Jun 2012 00:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WuKPQc1mkpk for ; Mon, 11 Jun 2012 00:10:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB29721F846A for ; Mon, 11 Jun 2012 00:10:44 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8936660obb.31 for ; Mon, 11 Jun 2012 00:10:44 -0700 (PDT) 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:content-transfer-encoding; bh=S/vXzDqnxtEgJEua/zHXtZ3yAId3C9KJ0QfWZvzvL5I=; b=edcbD/xLjPinRunhbSNAzDg11fwJSoVom0UkNE14EOzW1h1jBsOnDjFVU6qP1RNgbo wFShxJY/FzWp3ggURwMBcCqPIGe5mKLYEOemK/75CNNaDbhGBCk5+qPT/WwnqMtn37/J hn9+RN2dVo10j3Tu8aL4GILwhXlDHrlXs8/gEU82z5ypOX8TKUu4tEbtafbtFnxYJFLF AQnynCv3jrWOfDlI0wa7zdduwg9EzyUe9uwXyK0kTRgKliZdvmaCgqXHg3PqGfoC5EOA mBieQq1ibYBIylH74NPP2CSEHWF/5HXo/bJ3LbTYYXyWPYa+wxxuc+DB3pUH+s6KdL6r mj6w== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr15268029oeg.37.1339398644446; Mon, 11 Jun 2012 00:10:44 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Mon, 11 Jun 2012 00:10:44 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 11 Jun 2012 15:10:44 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 07:10:45 -0000 Hi Med, "end to end argument" is different from" stateful/stateless" principally, "end to end argument" recommend state in the end point(host), but it doesn'= t say it is stateless, it is still stateful. Based on this, I still believe that we need update the current document with the last comment. Regards, Dapeng Liu 2012/6/11, liu dapeng : > Hi Med: > > 2012/6/8, mohamed.boucadair@orange.com : >> Dear Dapeng, >> >> Please see inline. >> >> Cheers, >> >>>-----Message d'origine----- >>>De : liu dapeng [mailto:maxpassion@gmail.com] >>>Envoy=E9 : vendredi 8 juin 2012 13:49 >>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>Cc : Yong Cui; softwires@ietf.org >>>Objet : Re: [Softwires] WG last call on >>>draft-ietf-softwire-stateless-4v6-motivation-01 >>> >>>> >>>> Med: We have already this text in the introduction: >>>> >>>> Current standardization effort that is meant to address this IPv4 >>>> service continuity issue focuses mainly on stateful >>>mechanisms that >>>> assume the sharing of any global IPv4 address that is left between >>>> several customers, based upon the deployment of NAT >>>(Network Address >>>> Translation) capabilities in the network. Because of >>>some caveats of >>>> such stateful approaches the Service Provider community >>>feels that a >>>> companion effort is required to specify stateless IPv4 over IPv6 >>>> approaches. This document provides elaboration on such need. >>>> >>>> Isn't this text sufficient enough? If not, it would helpful >>>to propose a >>>> sentence you want to be added to the introduction. >>> >>>How about adding the following sentences: >>> >>>------- >>>In many networks today, NAT44 functions is equipped on >>>customer-edge device. >>>It may impact IPv4 over IPv6 solution to be a stateful solution from >>>end-to-end perspectives. The stateless solution also may subject to >>>NAT44 state. >>>In this document, we mainly refer this stateless paradigm to >>>large-scale address Sharing, i.e. carrier-side stateless IPv4 over >>>IPv6, which resolve the concern of "stateless" terminology. This >>>document provides elaboration on such need. >>>------- >>> >> >> Med: Thanks for the proposal. I shortened your proposal and updated the >> text >> to: >> >> >> Current standardization effort that is meant to address this IPv4 >> service continuity issue focuses mainly on stateful mechanisms that >> assume the sharing of any global IPv4 address that is left between >> several customers, based upon the deployment of NAT (Network Address >> Translation) capabilities in the network. Because of some caveats of >> such stateful approaches the Service Provider community feels that a >> companion effort is required to specify stateless IPv4 over IPv6 >> approaches. Note stateless IPv4 over IPv6 solutions may be enabled >> in conjunction with a port-restricted NAT44 function located in the >> customer premises. >> >> This document provides elaboration on the need for carrier-side >> stateless IPv4 over IPv6 solution. >> >> >> Are you OK with this new text? > > [Dapeng]=3D=3D> > I make a minor change of the last two sentences: > --------- > Because of some caveats of such stateful approaches the Service > Provider community feels that a companion effort is required to > specify carrier-side stateless IPv4 over IPv6 approaches. Note > carrier-side stateless IPv4 over IPv6 solutions may be enabled in > conjunction with a port-restricted NAT44 function located in the > customer premises or port translation in the host and that is still > stateful in the whole. > --------- > > Besides, how about changing all the terminology "stateless" to > "carrier-side stateless" in the document? > > > Thanks, > Best Regards, > Dapeng Liu > > > > >> >> > > > -- > > ------ > Best Regards, > Dapeng Liu > --=20 ------ Best Regards, Dapeng Liu From mohamed.boucadair@orange.com Mon Jun 11 00:21:26 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 19E5B21F8483 for ; Mon, 11 Jun 2012 00:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5KLmz6ZDFJ8 for ; Mon, 11 Jun 2012 00:21:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3B80F21F847F for ; Mon, 11 Jun 2012 00:21:25 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id A38D826425A; Mon, 11 Jun 2012 09:21:23 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 84DFE35C060; Mon, 11 Jun 2012 09:21:23 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 11 Jun 2012 09:21:23 +0200 From: To: liu dapeng Date: Mon, 11 Jun 2012 09:21:21 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Thread-Index: Ac1HoVP2jj6hfViYTP6kwxPKAtW18AAAO1aQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FE887@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.6.10.62745 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 07:21:26 -0000 Re-, I was answering to your last proposed wording to include the port translati= on in the host. Except that change, all your proposed changes are included = in my local copy: * The title has been updated as your requested * The introduction has been updated. Cheers, Med=20 >-----Message d'origine----- >De : liu dapeng [mailto:maxpassion@gmail.com]=20 >Envoy=E9 : lundi 11 juin 2012 09:11 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Yong Cui; softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-stateless-4v6-motivation-01 > >Hi Med, > >"end to end argument" is different from" stateful/stateless"=20 >principally, >"end to end argument" recommend state in the end point(host),=20 >but it doesn't say >it is stateless, it is still stateful. > >Based on this, I still believe that we need update the current >document with the last comment. > >Regards, >Dapeng Liu >2012/6/11, liu dapeng : >> Hi Med: >> >> 2012/6/8, mohamed.boucadair@orange.com=20 >: >>> Dear Dapeng, >>> >>> Please see inline. >>> >>> Cheers, >>> >>>>-----Message d'origine----- >>>>De : liu dapeng [mailto:maxpassion@gmail.com] >>>>Envoy=E9 : vendredi 8 juin 2012 13:49 >>>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>Cc : Yong Cui; softwires@ietf.org >>>>Objet : Re: [Softwires] WG last call on >>>>draft-ietf-softwire-stateless-4v6-motivation-01 >>>> >>>>> >>>>> Med: We have already this text in the introduction: >>>>> >>>>> Current standardization effort that is meant to=20 >address this IPv4 >>>>> service continuity issue focuses mainly on stateful >>>>mechanisms that >>>>> assume the sharing of any global IPv4 address that is=20 >left between >>>>> several customers, based upon the deployment of NAT >>>>(Network Address >>>>> Translation) capabilities in the network. Because of >>>>some caveats of >>>>> such stateful approaches the Service Provider community >>>>feels that a >>>>> companion effort is required to specify stateless IPv4=20 >over IPv6 >>>>> approaches. This document provides elaboration on such need. >>>>> >>>>> Isn't this text sufficient enough? If not, it would helpful >>>>to propose a >>>>> sentence you want to be added to the introduction. >>>> >>>>How about adding the following sentences: >>>> >>>>------- >>>>In many networks today, NAT44 functions is equipped on >>>>customer-edge device. >>>>It may impact IPv4 over IPv6 solution to be a stateful solution from >>>>end-to-end perspectives. The stateless solution also may subject to >>>>NAT44 state. >>>>In this document, we mainly refer this stateless paradigm to >>>>large-scale address Sharing, i.e. carrier-side stateless IPv4 over >>>>IPv6, which resolve the concern of "stateless" terminology. This >>>>document provides elaboration on such need. >>>>------- >>>> >>> >>> Med: Thanks for the proposal. I shortened your proposal and=20 >updated the >>> text >>> to: >>> >>> >>> Current standardization effort that is meant to address this IPv4 >>> service continuity issue focuses mainly on stateful=20 >mechanisms that >>> assume the sharing of any global IPv4 address that is=20 >left between >>> several customers, based upon the deployment of NAT=20 >(Network Address >>> Translation) capabilities in the network. Because of=20 >some caveats of >>> such stateful approaches the Service Provider community=20 >feels that a >>> companion effort is required to specify stateless IPv4 over IPv6 >>> approaches. Note stateless IPv4 over IPv6 solutions may=20 >be enabled >>> in conjunction with a port-restricted NAT44 function=20 >located in the >>> customer premises. >>> >>> This document provides elaboration on the need for carrier-side >>> stateless IPv4 over IPv6 solution. >>> >>> >>> Are you OK with this new text? >> >> [Dapeng]=3D=3D> >> I make a minor change of the last two sentences: >> --------- >> Because of some caveats of such stateful approaches the Service >> Provider community feels that a companion effort is required to >> specify carrier-side stateless IPv4 over IPv6 approaches. Note >> carrier-side stateless IPv4 over IPv6 solutions may be enabled in >> conjunction with a port-restricted NAT44 function located in the >> customer premises or port translation in the host and that is still >> stateful in the whole. >> --------- >> >> Besides, how about changing all the terminology "stateless" to >> "carrier-side stateless" in the document? >> >> >> Thanks, >> Best Regards, >> Dapeng Liu >> >> >> >> >>> >>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> > > >--=20 > >------ >Best Regards, >Dapeng Liu >= From maxpassion@gmail.com Mon Jun 11 00:32: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 CDB0721F8480 for ; Mon, 11 Jun 2012 00:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQLBxwrQGDF4 for ; Mon, 11 Jun 2012 00:32:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDAD221F846A for ; Mon, 11 Jun 2012 00:32:21 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so8971582obb.31 for ; Mon, 11 Jun 2012 00:32:21 -0700 (PDT) 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:content-transfer-encoding; bh=J34cWjG7VRdWmb5XJE2bFM7WVifxCFiNHDfjYV/9Vfw=; b=XCVzFNm1Ct4kJ8/kxgP6Vks0+5VJJGPv2H27BFuTWsYNGB5351QMuyfxDVgk0L0Vcn gVoMONWMJyuZvyvPTXjzn4BwDbigvfXDAR1RB413YXhYJm4q+cowWU5EwJensVfWOEwZ DHxUb5LwfvjmWyj9u9kIh2ghyRqSsEiMv4SP4IotZwo6VPqEJqntvXF9F6BvLSNx3Zfj jnW3HEV3P92jQ/caGzB5y8S1JS21rTo7TtA+yBIc12jAjV6AgIi09Ai0/ei6xc7HMA1z tScl5M9/RRXT7WTYRj603ruRy427tW8bFJALQLldey1cO19aYeLl3Ij5vvDfCIllN4kC p5kQ== MIME-Version: 1.0 Received: by 10.60.28.162 with SMTP id c2mr15465766oeh.3.1339399941287; Mon, 11 Jun 2012 00:32:21 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Mon, 11 Jun 2012 00:32:21 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FE887@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE887@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 11 Jun 2012 15:32:21 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 07:32:22 -0000 Hello Med, Yes, we are almost converged on this final update. As you said here, there still need port translation in the host, that still state in the host. we need clarify that in this document for other readers. Best Regards, Dapeng Liu 2012/6/11, mohamed.boucadair@orange.com : > Re-, > > I was answering to your last proposed wording to include the port > translation in the host. Except that change, all your proposed changes ar= e > included in my local copy: > > * The title has been updated as your requested > * The introduction has been updated. > > Cheers, > Med > >>-----Message d'origine----- >>De : liu dapeng [mailto:maxpassion@gmail.com] >>Envoy=E9 : lundi 11 juin 2012 09:11 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : Yong Cui; softwires@ietf.org >>Objet : Re: [Softwires] WG last call on >>draft-ietf-softwire-stateless-4v6-motivation-01 >> >>Hi Med, >> >>"end to end argument" is different from" stateful/stateless" >>principally, >>"end to end argument" recommend state in the end point(host), >>but it doesn't say >>it is stateless, it is still stateful. >> >>Based on this, I still believe that we need update the current >>document with the last comment. >> >>Regards, >>Dapeng Liu >>2012/6/11, liu dapeng : >>> Hi Med: >>> >>> 2012/6/8, mohamed.boucadair@orange.com >>: >>>> Dear Dapeng, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> >>>>>-----Message d'origine----- >>>>>De : liu dapeng [mailto:maxpassion@gmail.com] >>>>>Envoy=E9 : vendredi 8 juin 2012 13:49 >>>>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>Cc : Yong Cui; softwires@ietf.org >>>>>Objet : Re: [Softwires] WG last call on >>>>>draft-ietf-softwire-stateless-4v6-motivation-01 >>>>> >>>>>> >>>>>> Med: We have already this text in the introduction: >>>>>> >>>>>> Current standardization effort that is meant to >>address this IPv4 >>>>>> service continuity issue focuses mainly on stateful >>>>>mechanisms that >>>>>> assume the sharing of any global IPv4 address that is >>left between >>>>>> several customers, based upon the deployment of NAT >>>>>(Network Address >>>>>> Translation) capabilities in the network. Because of >>>>>some caveats of >>>>>> such stateful approaches the Service Provider community >>>>>feels that a >>>>>> companion effort is required to specify stateless IPv4 >>over IPv6 >>>>>> approaches. This document provides elaboration on such need. >>>>>> >>>>>> Isn't this text sufficient enough? If not, it would helpful >>>>>to propose a >>>>>> sentence you want to be added to the introduction. >>>>> >>>>>How about adding the following sentences: >>>>> >>>>>------- >>>>>In many networks today, NAT44 functions is equipped on >>>>>customer-edge device. >>>>>It may impact IPv4 over IPv6 solution to be a stateful solution from >>>>>end-to-end perspectives. The stateless solution also may subject to >>>>>NAT44 state. >>>>>In this document, we mainly refer this stateless paradigm to >>>>>large-scale address Sharing, i.e. carrier-side stateless IPv4 over >>>>>IPv6, which resolve the concern of "stateless" terminology. This >>>>>document provides elaboration on such need. >>>>>------- >>>>> >>>> >>>> Med: Thanks for the proposal. I shortened your proposal and >>updated the >>>> text >>>> to: >>>> >>>> >>>> Current standardization effort that is meant to address this IPv4 >>>> service continuity issue focuses mainly on stateful >>mechanisms that >>>> assume the sharing of any global IPv4 address that is >>left between >>>> several customers, based upon the deployment of NAT >>(Network Address >>>> Translation) capabilities in the network. Because of >>some caveats of >>>> such stateful approaches the Service Provider community >>feels that a >>>> companion effort is required to specify stateless IPv4 over IPv6 >>>> approaches. Note stateless IPv4 over IPv6 solutions may >>be enabled >>>> in conjunction with a port-restricted NAT44 function >>located in the >>>> customer premises. >>>> >>>> This document provides elaboration on the need for carrier-side >>>> stateless IPv4 over IPv6 solution. >>>> >>>> >>>> Are you OK with this new text? >>> >>> [Dapeng]=3D=3D> >>> I make a minor change of the last two sentences: >>> --------- >>> Because of some caveats of such stateful approaches the Service >>> Provider community feels that a companion effort is required to >>> specify carrier-side stateless IPv4 over IPv6 approaches. Note >>> carrier-side stateless IPv4 over IPv6 solutions may be enabled in >>> conjunction with a port-restricted NAT44 function located in the >>> customer premises or port translation in the host and that is still >>> stateful in the whole. >>> --------- >>> >>> Besides, how about changing all the terminology "stateless" to >>> "carrier-side stateless" in the document? >>> >>> >>> Thanks, >>> Best Regards, >>> Dapeng Liu >>> >>> >>> >>> >>>> >>>> >>> >>> >>> -- >>> >>> ------ >>> Best Regards, >>> Dapeng Liu >>> >> >> >>-- >> >>------ >>Best Regards, >>Dapeng Liu >> --=20 ------ Best Regards, Dapeng Liu From despres.remi@laposte.net Mon Jun 11 00:46: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 898BF21F84DF for ; Mon, 11 Jun 2012 00:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LodLlb5PM9nL for ; Mon, 11 Jun 2012 00:46:02 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9D61F21F84F0 for ; Mon, 11 Jun 2012 00:46:02 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id E6B7270001D9; Mon, 11 Jun 2012 09:46:00 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id C2139700006B; Mon, 11 Jun 2012 09:45:59 +0200 (CEST) X-SFR-UUID: 20120611074559795.C2139700006B@msfrf2502.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 11 Jun 2012 09:45:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE887@PUEXCB1B.nanterre.francetelecom.fr> To: liu dapeng X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 07:46:03 -0000 Le 2012-06-11 =E0 09:32, liu dapeng a =E9crit : > Hello Med, >=20 > Yes, we are almost converged on this final update. >=20 > As you said here, there still need port translation in the host, that > still state in the host. Note that these states are "per-connection", not "per customer". Even a host without NAT has to maintain per-connection states for its = sockets. In this respect, the draft is I think acceptable, and hopefully can now = proceed quickly. Regards, RD > we need clarify that in this document for > other readers. >=20 > Best Regards, > Dapeng Liu > 2012/6/11, mohamed.boucadair@orange.com = : >> Re-, >>=20 >> I was answering to your last proposed wording to include the port >> translation in the host. Except that change, all your proposed = changes are >> included in my local copy: >>=20 >> * The title has been updated as your requested >> * The introduction has been updated. >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : liu dapeng [mailto:maxpassion@gmail.com] >>> Envoy=E9 : lundi 11 juin 2012 09:11 >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc : Yong Cui; softwires@ietf.org >>> Objet : Re: [Softwires] WG last call on >>> draft-ietf-softwire-stateless-4v6-motivation-01 >>>=20 >>> Hi Med, >>>=20 >>> "end to end argument" is different from" stateful/stateless" >>> principally, >>> "end to end argument" recommend state in the end point(host), >>> but it doesn't say >>> it is stateless, it is still stateful. >>>=20 >>> Based on this, I still believe that we need update the current >>> document with the last comment. >>>=20 >>> Regards, >>> Dapeng Liu >>> 2012/6/11, liu dapeng : >>>> Hi Med: >>>>=20 >>>> 2012/6/8, mohamed.boucadair@orange.com >>> : >>>>> Dear Dapeng, >>>>>=20 >>>>> Please see inline. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : liu dapeng [mailto:maxpassion@gmail.com] >>>>>> Envoy=E9 : vendredi 8 juin 2012 13:49 >>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>> Cc : Yong Cui; softwires@ietf.org >>>>>> Objet : Re: [Softwires] WG last call on >>>>>> draft-ietf-softwire-stateless-4v6-motivation-01 >>>>>>=20 >>>>>>>=20 >>>>>>> Med: We have already this text in the introduction: >>>>>>>=20 >>>>>>> Current standardization effort that is meant to >>> address this IPv4 >>>>>>> service continuity issue focuses mainly on stateful >>>>>> mechanisms that >>>>>>> assume the sharing of any global IPv4 address that is >>> left between >>>>>>> several customers, based upon the deployment of NAT >>>>>> (Network Address >>>>>>> Translation) capabilities in the network. Because of >>>>>> some caveats of >>>>>>> such stateful approaches the Service Provider community >>>>>> feels that a >>>>>>> companion effort is required to specify stateless IPv4 >>> over IPv6 >>>>>>> approaches. This document provides elaboration on such need. >>>>>>>=20 >>>>>>> Isn't this text sufficient enough? If not, it would helpful >>>>>> to propose a >>>>>>> sentence you want to be added to the introduction. >>>>>>=20 >>>>>> How about adding the following sentences: >>>>>>=20 >>>>>> ------- >>>>>> In many networks today, NAT44 functions is equipped on >>>>>> customer-edge device. >>>>>> It may impact IPv4 over IPv6 solution to be a stateful solution = from >>>>>> end-to-end perspectives. The stateless solution also may subject = to >>>>>> NAT44 state. >>>>>> In this document, we mainly refer this stateless paradigm to >>>>>> large-scale address Sharing, i.e. carrier-side stateless IPv4 = over >>>>>> IPv6, which resolve the concern of "stateless" terminology. This >>>>>> document provides elaboration on such need. >>>>>> ------- >>>>>>=20 >>>>>=20 >>>>> Med: Thanks for the proposal. I shortened your proposal and >>> updated the >>>>> text >>>>> to: >>>>>=20 >>>>>=20 >>>>> Current standardization effort that is meant to address this = IPv4 >>>>> service continuity issue focuses mainly on stateful >>> mechanisms that >>>>> assume the sharing of any global IPv4 address that is >>> left between >>>>> several customers, based upon the deployment of NAT >>> (Network Address >>>>> Translation) capabilities in the network. Because of >>> some caveats of >>>>> such stateful approaches the Service Provider community >>> feels that a >>>>> companion effort is required to specify stateless IPv4 over IPv6 >>>>> approaches. Note stateless IPv4 over IPv6 solutions may >>> be enabled >>>>> in conjunction with a port-restricted NAT44 function >>> located in the >>>>> customer premises. >>>>>=20 >>>>> This document provides elaboration on the need for carrier-side >>>>> stateless IPv4 over IPv6 solution. >>>>>=20 >>>>>=20 >>>>> Are you OK with this new text? >>>>=20 >>>> [Dapeng]=3D=3D> >>>> I make a minor change of the last two sentences: >>>> --------- >>>> Because of some caveats of such stateful approaches the Service >>>> Provider community feels that a companion effort is required to >>>> specify carrier-side stateless IPv4 over IPv6 approaches. Note >>>> carrier-side stateless IPv4 over IPv6 solutions may be enabled in >>>> conjunction with a port-restricted NAT44 function located in the >>>> customer premises or port translation in the host and that is still >>>> stateful in the whole. >>>> --------- >>>>=20 >>>> Besides, how about changing all the terminology "stateless" to >>>> "carrier-side stateless" in the document? >>>>=20 >>>>=20 >>>> Thanks, >>>> Best Regards, >>>> Dapeng Liu >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> ------ >>>> Best Regards, >>>> Dapeng Liu >>>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> ------ >>> Best Regards, >>> Dapeng Liu >>>=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wdec.ietf@gmail.com Mon Jun 11 01:56: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 7F53521F8505 for ; Mon, 11 Jun 2012 01:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioryV-5khNpc for ; Mon, 11 Jun 2012 01:56:44 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8840221F850B for ; Mon, 11 Jun 2012 01:56:44 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2238537qcs.31 for ; Mon, 11 Jun 2012 01:56:44 -0700 (PDT) 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=BaCXK2IZaaJe2rfngyLL3p9qVkj4QQyEbuKPxk2u4wE=; b=gbW+t6jBZqBs830bgk3TLLXuM008EqDTadeen9FqnyqnDkqgkmvRF4OvS5iVsGdfW/ cC0RtGl2eXod7LTEitMhWNY2HV94ZmE/10nErIAKUi57/GMqWF6Zm2rjalaEhwuSYTpF +1uV2ry10yT/672QL0R+Lq893idbBFLXuCcRAzqAqxeW6ZxtA8kJvXgkKj/fAc8njsjB 6FxnWQAEkqDlcD4beHdZ66XEarNhFbGatM1BFkEjmxdlM+bE0RjltljbfNrdpi04vCKB BjXdZRO5TxFg3TYU3lNssPz6Vk33UUiWLKYMV04RoPVnm5gCHyO3zrdk7DQCjgdLthOM ZjYQ== MIME-Version: 1.0 Received: by 10.229.135.83 with SMTP id m19mr4034423qct.78.1339405003943; Mon, 11 Jun 2012 01:56:43 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Mon, 11 Jun 2012 01:56:43 -0700 (PDT) In-Reply-To: References: <39098095-7D8B-44AA-9492-213283E89A4B@employees.org> <1D677EF2-C5D8-4007-8F46-756C2A3939C4@employees.org> <98E982A8-4730-46A7-9795-A7BB2162D1DC@employees.org> Date: Mon, 11 Jun 2012 10:56:43 +0200 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=00248c6a84d6786f7b04c22e87b7 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 11 Jun 2012 08:56:45 -0000 --00248c6a84d6786f7b04c22e87b7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 9 June 2012 05:35, Qi Sun wrote: > Hi Ole, > > In your previous Email you wrote, > > in MAP you do all of that with one single DHCPv6 > option... > > IMHO, that's because the one DHCPv6 option contains so many KINDS of > information (e.g. PSID, BR's prefix or address, see draft of > map-dhcp-option ). > > And with separate provisoning processes , it's easier to detect > problems if the whole process fails. > Disagree: Figuring out what went wrong in DHCPv6 acquisition followed by DNS resolution to get the DHCPv4 server address, followed by DHCPv4 relaying, followed by DHCPv4 acquisition, has multiple levels of not easy to detect failuires. -Woj. > > Best Regards! > > Qi Sun > > On 6/8/12, Ole Tr=F8an wrote: > > Peng, > > > >> Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, > >> they have respective application scenarios, pros and cons. > >> 1)stateless, 4rd, MAP > >> 2)per-flow stateful: DS-Lite > >> 3)per-user stateful: public 4over6, lightweight 4over6 > >> As Ole said, the problem is that, do we want serveral simple > >> mechanisms, or one super-compatible mechanism with different modes. > >> > >> Now Given that a) the WG has accomplished DS-lite; b)MAP follows the > >> stateless motivation all along the way; c)The signifcant changes to > >> make MAP super-compatible, I vote for we define the third type, > >> per-user stateful mechanisms independently. > > > > actually there are no significant changes to the MAP specification, the > > per-user stateful mechanism is just intrinsically supported by MAP. it > is a > > corner case, and it would be more work in the specification to "ban" th= is > > operational mode, than to support it. > > > > btw, one thing that appears most complicated is provisioning; currently > it > > looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to > get > > provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, > then a > > DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchange > to > > get the IPv4 address, and then a new DHCPv4 option to get the port set. > that > > seems to me to be quite a few moving parts, and quiet a few corner case= s > to > > be specified when one or more of the above fails. in MAP you do all of > that > > with one single DHCPv6 option... > > > > 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 > --00248c6a84d6786f7b04c22e87b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 9 June 2012 05:35, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:
Hi Ole,

In your previous Email you wrote,
> in MAP you do all of that with one single DHCPv6
option...

IMHO, that's because the one DHCPv6 option contains so many KINDS= of
information (e.g. PSID, BR's prefix or address, see draft of
map-dhcp-option ).

And with separate provisoning processes , it's easier to detect
problems if the whole process fails.

Disagree: Fig= uring out what went wrong in DHCPv6 acquisition followed by DNS resolution = to get the DHCPv4 server address, followed by DHCPv4 relaying, followed by = DHCPv4 acquisition, has multiple levels of not easy to detect failuires.
-Woj.

Best Regards!

Qi Sun

On 6/8/12, Ole Tr=F8an <otroan@e= mployees.org> wrote:
> Peng,
>
>> Now there are actually 3 directions for IPv4-over-IPv6 mechanisms,=
>> they have respective application scenarios, pros and cons.
>> 1)stateless, =A04rd, MAP
>> 2)per-flow stateful: DS-Lite
>> 3)per-user stateful: public 4over6, lightweight 4over6
>> As Ole said, the problem is that, do we want serveral simple
>> mechanisms, or one super-compatible mechanism with different modes= .
>>
>> Now Given that a) the WG has accomplished DS-lite; b)MAP follows t= he
>> stateless motivation all along the way; c)The signifcant changes t= o
>> make MAP super-compatible, I vote for we define the third type, >> per-user stateful mechanisms independently.
>
> actually there are no significant changes to the MAP specification, th= e
> per-user stateful mechanism is just intrinsically supported by MAP. it= is a
> corner case, and it would be more work in the specification to "b= an" this
> operational mode, than to support it.
>
> btw, one thing that appears most complicated is provisioning; currentl= y it
> looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options t= o get
> provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, = then a
> DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchang= e to
> get the IPv4 address, and then a new DHCPv4 option to get the port set= . that
> seems to me to be quite a few moving parts, and quiet a few corner cas= es to
> be specified when one or more of the above fails. in MAP you do all of= that
> with one single DHCPv6 option...
>
> 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

--00248c6a84d6786f7b04c22e87b7-- From wdec.ietf@gmail.com Mon Jun 11 02:10:26 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 E83FA21F8535 for ; Mon, 11 Jun 2012 02:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sgu66lIZIjdf for ; Mon, 11 Jun 2012 02:10:25 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id D6CE821F854E for ; Mon, 11 Jun 2012 02:10:24 -0700 (PDT) Received: by qabj40 with SMTP id j40so2312911qab.15 for ; Mon, 11 Jun 2012 02:10:24 -0700 (PDT) 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=1kBT64k6zRcnG6VJtELYt3+obF1CSH3qxmiZkVu7QxE=; b=P/QanlMSrctxUJ0vqM3+jP4Hu6pdtvR2Qf2Pcqxmqm9XfZgz10zlBeFpHncCtfMvHs Su/Ef+DWMqU3qClD/7Q2a2rA3BwLDAL1pfTHSxzClPQN3+fSf6/zL6v8d3zGo5ot/bWh 72LwH191v6th3OoY5QtNjR8HxhthqbJO7ox3b3Ad7OdwAR45BF25fK7+m7A2V1LOtREN neMVf/OrgZlwCWi1j0zqjvLGh1a91j+dN414joSRN+ywczma0wKmGVx4N6HRPJdXSnem 3j1zrGpy6X64DcmJeXsrAOSKK8recfdi5/g44nXlacGyK/oYlLXkkeXwDO943/EaHxNP hBIg== MIME-Version: 1.0 Received: by 10.224.220.145 with SMTP id hy17mr12003194qab.85.1339405824324; Mon, 11 Jun 2012 02:10:24 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Mon, 11 Jun 2012 02:10:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Jun 2012 11:10:24 +0200 Message-ID: From: Wojciech Dec To: Yong Cui Content-Type: multipart/alternative; boundary=20cf3074d7585e748104c22eb8db Cc: softwires@ietf.org Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 11 Jun 2012 09:10:26 -0000 --20cf3074d7585e748104c22eb8db Content-Type: text/plain; charset=ISO-8859-1 There is basic question regarding this draft, one that has also been raised at previous WG meetings: "why is it needed?". I do not think this draft should progress before a thorough review of this space. We do not need another form of a classic dual stack "transition" architecture! Also, at best this draft is an informational one as opposed to standards track. There is a deeper issue here: This draft seems to give the impression that running such a regular public addressed DHCPv4 based overlay on IPv6 is a simple idea, as opposed to native dual stack. It is anything but, given that a) it it requires changes to DHCPv4 processing b) it introduces non trivial dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires changes to CPE d) makes life really a mess if we consider a real dual stack CPE. -Woj. On 27 May 2012 16:30, Yong Cui wrote: > Hi folks, > > This is a wg last call on draft-ietf-softwire-public-4over6-01. > http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ > > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. > > This wg last call will end on 2012 June 10 at 12pm EDT. > > > Yong & Alain > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3074d7585e748104c22eb8db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is basic question regarding this draft, one that has also been raised= at previous WG meetings: "why is it needed?".
I do not think= this draft should progress before a thorough review of=20 this space. We do not need another form of a classic dual stack=20 "transition" architecture!
Also, at best this draft is an informational one as opposed to standards tr= ack.

There is a deeper issue here: This draft seems to give the impr= ession that running such a regular public addressed DHCPv4 based overlay on= IPv6 is a simple idea, as opposed to native dual stack. It is anything but= , given that a) it it requires changes to DHCPv4 processing b) it introduce= s non trivial dependencies between DHCPv6 and DHCPv4 and tunnelling c) requ= ires changes to CPE d) makes life really a mess if we consider a real dual = stack CPE.

-Woj.



On 27 May 2012 16:30, Y= ong Cui <cuiyong@tsinghua.edu.cn> wrote:
Hi folks,

This is a wg last call on draft-ietf-softwire-public-4over6-01.
http://datatracker.ietf.org/doc/draft-ietf-softwire-p= ublic-4over6/

As usual, please send editorial comments to the authors and
substantive comments to the mailing list.

This wg last call will end on 2012 June 10 at 12pm EDT.


Yong & Alain



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

--20cf3074d7585e748104c22eb8db-- From maxpassion@gmail.com Mon Jun 11 03:32: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 0A27C21F858A for ; Mon, 11 Jun 2012 03:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.217 X-Spam-Level: X-Spam-Status: No, score=-3.217 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G+Nomyl4rZw for ; Mon, 11 Jun 2012 03:32:20 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBFB21F8467 for ; Mon, 11 Jun 2012 03:32:20 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so9257879obb.31 for ; Mon, 11 Jun 2012 03:32:19 -0700 (PDT) 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:content-transfer-encoding; bh=tppUHT8xJJtIBEsmt6Kj9D1kFPB8iRl+shavbXITXIc=; b=lNHwUCUqcQIOIPsbQr+bxIQx1tSzQofGQ9+fBk/lurD93ZDt8ziayU7fir9a2lu7Wi M/RdbOHiqbghanqNCasnI701iaIMtCBaw92doaWBeoh7V9W3fhhRDC869R28lmljySYc YoprbOYRKJX+UopUlsn1kyho8unmpe+0U/36lERUyszp4/DhvzczVd7EXXp7Fl7XpD1i w1RXOEyJbdWRUX0IQQOTSQQcVjypo78Hz6OaNGUd7SKoF7M2nDoOcSLvSD6wNrDEPp3S kZroVnOKI2unvspP4K+lnLw2oaalHjHcC1FpVI5CrpYg06BVKhyJFDzF6LCwE3Ewo68x Kx7w== MIME-Version: 1.0 Received: by 10.182.16.102 with SMTP id f6mr15827047obd.48.1339410739567; Mon, 11 Jun 2012 03:32:19 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Mon, 11 Jun 2012 03:32:19 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E32ED1E40@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE887@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 11 Jun 2012 18:32:19 +0800 Message-ID: From: liu dapeng To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 10:32:21 -0000 2012/6/11, R=E9mi Despr=E9s : > > Le 2012-06-11 =E0 09:32, liu dapeng a =E9crit : > >> Hello Med, >> >> Yes, we are almost converged on this final update. >> >> As you said here, there still need port translation in the host, that >> still state in the host. > > Note that these states are "per-connection", not "per customer". > Even a host without NAT has to maintain per-connection states for its > sockets. The state you mentioned here is for application, but we are talking about state on the network layer, they are different. I don't see why we resist on clarifying and helping reader better understanding. Besides, I guess the state referred in this document is not specific to either "per-connection" or "per customer" . AFTR also hold a "per-connection" state, which is treated as a stateful in the document. Best Regards, Dapeng Liu > In this respect, the draft is I think acceptable, and hopefully can now > proceed quickly. > > Regards, > RD > > >> we need clarify that in this document for >> other readers. >> >> Best Regards, >> Dapeng Liu >> 2012/6/11, mohamed.boucadair@orange.com : >>> Re-, >>> >>> I was answering to your last proposed wording to include the port >>> translation in the host. Except that change, all your proposed changes >>> are >>> included in my local copy: >>> >>> * The title has been updated as your requested >>> * The introduction has been updated. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : liu dapeng [mailto:maxpassion@gmail.com] >>>> Envoy=E9 : lundi 11 juin 2012 09:11 >>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : Yong Cui; softwires@ietf.org >>>> Objet : Re: [Softwires] WG last call on >>>> draft-ietf-softwire-stateless-4v6-motivation-01 >>>> >>>> Hi Med, >>>> >>>> "end to end argument" is different from" stateful/stateless" >>>> principally, >>>> "end to end argument" recommend state in the end point(host), >>>> but it doesn't say >>>> it is stateless, it is still stateful. >>>> >>>> Based on this, I still believe that we need update the current >>>> document with the last comment. >>>> >>>> Regards, >>>> Dapeng Liu >>>> 2012/6/11, liu dapeng : >>>>> Hi Med: >>>>> >>>>> 2012/6/8, mohamed.boucadair@orange.com >>>> : >>>>>> Dear Dapeng, >>>>>> >>>>>> Please see inline. >>>>>> >>>>>> Cheers, >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : liu dapeng [mailto:maxpassion@gmail.com] >>>>>>> Envoy=E9 : vendredi 8 juin 2012 13:49 >>>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>>> Cc : Yong Cui; softwires@ietf.org >>>>>>> Objet : Re: [Softwires] WG last call on >>>>>>> draft-ietf-softwire-stateless-4v6-motivation-01 >>>>>>> >>>>>>>> >>>>>>>> Med: We have already this text in the introduction: >>>>>>>> >>>>>>>> Current standardization effort that is meant to >>>> address this IPv4 >>>>>>>> service continuity issue focuses mainly on stateful >>>>>>> mechanisms that >>>>>>>> assume the sharing of any global IPv4 address that is >>>> left between >>>>>>>> several customers, based upon the deployment of NAT >>>>>>> (Network Address >>>>>>>> Translation) capabilities in the network. Because of >>>>>>> some caveats of >>>>>>>> such stateful approaches the Service Provider community >>>>>>> feels that a >>>>>>>> companion effort is required to specify stateless IPv4 >>>> over IPv6 >>>>>>>> approaches. This document provides elaboration on such need. >>>>>>>> >>>>>>>> Isn't this text sufficient enough? If not, it would helpful >>>>>>> to propose a >>>>>>>> sentence you want to be added to the introduction. >>>>>>> >>>>>>> How about adding the following sentences: >>>>>>> >>>>>>> ------- >>>>>>> In many networks today, NAT44 functions is equipped on >>>>>>> customer-edge device. >>>>>>> It may impact IPv4 over IPv6 solution to be a stateful solution fro= m >>>>>>> end-to-end perspectives. The stateless solution also may subject to >>>>>>> NAT44 state. >>>>>>> In this document, we mainly refer this stateless paradigm to >>>>>>> large-scale address Sharing, i.e. carrier-side stateless IPv4 over >>>>>>> IPv6, which resolve the concern of "stateless" terminology. This >>>>>>> document provides elaboration on such need. >>>>>>> ------- >>>>>>> >>>>>> >>>>>> Med: Thanks for the proposal. I shortened your proposal and >>>> updated the >>>>>> text >>>>>> to: >>>>>> >>>>>> >>>>>> Current standardization effort that is meant to address this IPv4 >>>>>> service continuity issue focuses mainly on stateful >>>> mechanisms that >>>>>> assume the sharing of any global IPv4 address that is >>>> left between >>>>>> several customers, based upon the deployment of NAT >>>> (Network Address >>>>>> Translation) capabilities in the network. Because of >>>> some caveats of >>>>>> such stateful approaches the Service Provider community >>>> feels that a >>>>>> companion effort is required to specify stateless IPv4 over IPv6 >>>>>> approaches. Note stateless IPv4 over IPv6 solutions may >>>> be enabled >>>>>> in conjunction with a port-restricted NAT44 function >>>> located in the >>>>>> customer premises. >>>>>> >>>>>> This document provides elaboration on the need for carrier-side >>>>>> stateless IPv4 over IPv6 solution. >>>>>> >>>>>> >>>>>> Are you OK with this new text? >>>>> >>>>> [Dapeng]=3D=3D> >>>>> I make a minor change of the last two sentences: >>>>> --------- >>>>> Because of some caveats of such stateful approaches the Service >>>>> Provider community feels that a companion effort is required to >>>>> specify carrier-side stateless IPv4 over IPv6 approaches. Note >>>>> carrier-side stateless IPv4 over IPv6 solutions may be enabled in >>>>> conjunction with a port-restricted NAT44 function located in the >>>>> customer premises or port translation in the host and that is still >>>>> stateful in the whole. >>>>> --------- >>>>> >>>>> Besides, how about changing all the terminology "stateless" to >>>>> "carrier-side stateless" in the document? >>>>> >>>>> >>>>> Thanks, >>>>> Best Regards, >>>>> Dapeng Liu >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------ >>>>> Best Regards, >>>>> Dapeng Liu >>>>> >>>> >>>> >>>> -- >>>> >>>> ------ >>>> Best Regards, >>>> Dapeng Liu >>>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > --=20 ------ Best Regards, Dapeng Liu From despres.remi@laposte.net Mon Jun 11 06:50:01 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 F055F21F8526 for ; Mon, 11 Jun 2012 06:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ssj1C-J8ynz for ; Mon, 11 Jun 2012 06:50:00 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.121]) by ietfa.amsl.com (Postfix) with ESMTP id 3072321F84FB for ; Mon, 11 Jun 2012 06:49:59 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2501.sfr.fr (SMTP Server) with ESMTP id B0F497000071; Mon, 11 Jun 2012 15:49:58 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2501.sfr.fr (SMTP Server) with ESMTP id DFE82700006F; Mon, 11 Jun 2012 15:49:57 +0200 (CEST) X-SFR-UUID: 20120611134957917.DFE82700006F@msfrf2501.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120608213032.29686.80428.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2012 15:49:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41420625-8EEA-41E9-8695-1C7F63A62B11@laposte.net> References: <20120608213032.29686.80428.idtracker@ietfa.amsl.com> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-00.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: Mon, 11 Jun 2012 13:50:01 -0000 Ole, Thank you for this update on what is meant by MAP today. Which parameters are advertised to CEs will be completely clear, I = suppose, when the DHCPv6 document is also available, but the draft = contains IMHO useful clarifications. Two immediate points: - Last sentence of page 8 is "DNS64 [RFC6147] become required only when = IPv6 servers in the MAP-T domain are expected themselves to initiate = communication to external IPv4-only hosts." IPv4 is AFAIK a typo (should = be IPv6). - A co-author of the 4rd proposal is still listed as main contributor to = this new version. This could mislead readers to believe he renounced to = recommend 4rd. Since AFAIK this isn't the case, a solution should be = found so that, in a next edition, one better knows who recommends what. Also, since some evolutions of substance have been introduced, a list of = these would be highly appreciated, preferably with brief justifications. Cheers, RD =20 After a quick look at the draft 2012-06-08 =E0 23:30, internet-drafts@ietf.org: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Softwires Working Group of = the IETF. >=20 > Title : Mapping of Address and Port (MAP) > Author(s) : Ole Troan > Wojciech Dec > Xing Li > Congxiao Bao > Yu Zhai > Satoru Matsushima > Tetsuya Murakami > Filename : draft-ietf-softwire-map-00.txt > Pages : 33 > Date : 2012-06-01 >=20 > This document describes a mechanism for transporting IPv4 packets > across an IPv6 network, and a generic mechanism for mapping between > IPv6 addresses and IPv4 addresses and transport layer ports. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-map-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-map-00.txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map/ >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Mon Jun 11 07:54: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 6777421F8611 for ; Mon, 11 Jun 2012 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgfMaFBtmq+U for ; Mon, 11 Jun 2012 07:54:15 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id B043E21F8573 for ; Mon, 11 Jun 2012 07:54:15 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.20724411; Mon, 11 Jun 2012 08:37:45 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Mon, 11 Jun 2012 10:54:09 -0400 From: "Lee, Yiu" To: "mohamed.boucadair@orange.com" , liu dapeng Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Thread-Index: AQHNR+IN9ZxdlDBC80OY3bEwshPkJA== Date: Mon, 11 Jun 2012 14:54:08 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [24.40.55.71] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422256847_485888" MIME-Version: 1.0 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 14:54:16 -0000 --B_3422256847_485888 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Med and Dapeng, In order to close the gap, I suggest a slight modification: "Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that sharing of global IPv4 addresses between Customers is based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note that the stateless solution elaborated in this document focuses on the carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer-premises equipment." Thanks, Yiu On 6/8/12 8:12 AM, "mohamed.boucadair@orange.com" wrote: >Med: Thanks for the proposal. I shortened your proposal and updated the >text to: > > > Current standardization effort that is meant to address this IPv4 > service continuity issue focuses mainly on stateful mechanisms that > assume the sharing of any global IPv4 address that is left between > several customers, based upon the deployment of NAT (Network Address > Translation) capabilities in the network. Because of some caveats of > such stateful approaches the Service Provider community feels that a > companion effort is required to specify stateless IPv4 over IPv6 > approaches. Note stateless IPv4 over IPv6 solutions may be enabled > in conjunction with a port-restricted NAT44 function located in the > customer premises. > > This document provides elaboration on the need for carrier-side > stateless IPv4 over IPv6 solution. --B_3422256847_485888 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT3cXR3 QnSWXKklPfhxi91Il6FgNzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MTExNDU0MDVaMA0GCSqGSIb3DQEBAQUABIIBAGv84sziQC6wtwd3vj+Dmxd1 j8Ji2+e7fdrzZwPMBU2TBWyyq1a7KE3GF/OaO+Qq0iyXTycY0vRAvVpuSHt4HdGwKUSkp6At xdvxRzn1b8jq/9sjtG3LuOl5/7a3uVYe4/hsC1Oaph30WlIh4g0p57+axrF+invYJq3JYNGv h13hQ+vRYTQZUIxEfVvwH3jBwi+xBRp4yQh541XIVLAruoT4rIopCISpy3TztKshHjOR68mH GtK16EQ8v0TcIF+DFvfgfWkmtCWLwBgp5zjnu8iuxh48h0wqo+aCfVrEJnpmCVyRzvbC7wZG vZFuHwAyiXFMVIXlKESH2nKiIVfA2J0= --B_3422256847_485888-- From mohamed.boucadair@orange.com Mon Jun 11 08: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 3EF3621F85CC for ; Mon, 11 Jun 2012 08:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOA5bbnTjmEB for ; Mon, 11 Jun 2012 08:37:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 823BB21F855E for ; Mon, 11 Jun 2012 08:37:21 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3B70F22C3E4; Mon, 11 Jun 2012 17:37:20 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 112F14C07C; Mon, 11 Jun 2012 17:37:20 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Mon, 11 Jun 2012 17:37:20 +0200 From: To: "Lee, Yiu" , liu dapeng Date: Mon, 11 Jun 2012 17:37:18 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Thread-Index: AQHNR+IN9ZxdlDBC80OY3bEwshPkJJb1QE7g Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FEBF5@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.6.11.141516 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 11 Jun 2012 15:37:22 -0000 Hi Yiu, Works for me. Thanks. Cheers, Med=20 >-----Message d'origine----- >De : Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 >Envoy=E9 : lundi 11 juin 2012 16:54 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; liu dapeng >Cc : softwires@ietf.org; Yong Cui >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-stateless-4v6-motivation-01 > >Hi Med and Dapeng, > >In order to close the gap, I suggest a slight modification: > >"Current standardization effort that is meant to address this IPv4 > service continuity issue focuses mainly on stateful mechanisms that >sharing of global IPv4 addresses between >Customers is based upon the deployment of NAT (Network Address > Translation) capabilities in the network. Because of some=20 >caveats of > such stateful approaches the Service Provider community feels that a > companion effort is required to specify stateless IPv4 over IPv6 > approaches. Note that the stateless solution elaborated in this >document >focuses on the carrier-side stateless IPv4 over IPv6 solution.=20 >States may >still exist in other equipments such as customer-premises equipment." > >Thanks, >Yiu > > >On 6/8/12 8:12 AM, "mohamed.boucadair@orange.com" > wrote: > >>Med: Thanks for the proposal. I shortened your proposal and=20 >updated the >>text to: >> >> >> Current standardization effort that is meant to address this IPv4 >> service continuity issue focuses mainly on stateful mechanisms that >> assume the sharing of any global IPv4 address that is left between >> several customers, based upon the deployment of NAT=20 >(Network Address >> Translation) capabilities in the network. Because of some=20 >caveats of >> such stateful approaches the Service Provider community=20 >feels that a >> companion effort is required to specify stateless IPv4 over IPv6 >> approaches. Note stateless IPv4 over IPv6 solutions may be enabled >> in conjunction with a port-restricted NAT44 function located in the >> customer premises. >> >> This document provides elaboration on the need for carrier-side >> stateless IPv4 over IPv6 solution. >= From sarikaya2012@gmail.com Mon Jun 11 09:08: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 BE5B621F854C for ; Mon, 11 Jun 2012 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7hObEyD1vXh for ; Mon, 11 Jun 2012 09:08:19 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C087821F859A for ; Mon, 11 Jun 2012 09:08:19 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3122255ggn.31 for ; Mon, 11 Jun 2012 09:08:19 -0700 (PDT) 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:content-transfer-encoding; bh=whWM0/b2eN6OXSG52wZwkdSraxZPlG4UsRxfq5hUVns=; b=0F/Nk0eZ0gaA1iS9G1RqcGDrf3cE7ZKzR29Itj983ZSnm3vjlk1sk1GRafegmCHcQM PeoRkuB/mfOgN7TT7iB60z/OejCp/4Xoat0OS5l+YjtN8O0g0c+N0QPGL8V3U3i9biWX MaZPb6gQHjMNO7NyOLULMP7RsayL5ziZX6Jt7ddeYwCENiB7gqq/vc/YUFik7dv0GIt+ 8jS1mRvBejvdy1U5MSuPIhYnUW9DYZhuqF5OCzKJMAbkLymnPkwW2dGv1v8vUbjnhCrl SVIjgFLbiEGJMgFMyBAvZrVU0zKZHIj7vpTIEyPoMSmcmM7NEltt0+jwNqr8S5mRjXIw oLVw== MIME-Version: 1.0 Received: by 10.50.40.193 with SMTP id z1mr6864964igk.0.1339430899213; Mon, 11 Jun 2012 09:08:19 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Mon, 11 Jun 2012 09:08:19 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FE855@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE855@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 11 Jun 2012 11:08:19 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Mon, 11 Jun 2012 16:08:21 -0000 Hi Med, Thanks for your kind reply. I was talking about http://tools.ietf.org/html/draft-sarikaya-softwire-dslite6rdmulticast-00 (which is now expired, I'll explain why below) Profiting the occasion, let me clarify that the chairs, Alain initially asked the two drafts to be merged. We favored the merger but Med was against. draft-ietf-softwire-dslite-multicast-02 presents a generic v4 to v6 multicast translation technique and as has been indicated such an approach has nothing to do with DS-Lite, i.e. DS-Lite does not translate unicast v4 packets into unicast v6 packets. I hope this is well understood. As such, draft-ietf-softwire-dslite-multicast-02 is suitable for NAT64, (remind you that there is already a multicast solution draft for NAT64). Regards, Behcet On Mon, Jun 11, 2012 at 1:15 AM, wrote: > Hi Behcet, > > I failed to understand the point you are trying to make. > > The current situations is: > > * this document provides multicast extension to deliver multicast to DS-L= ite serviced customers > * we rely on multicast capabilities, as such no AMT-like considerations a= re included > * the proposed solution is generic and can be deployed in any 4-6-4 use c= ase > > What should be revised? > > Thanks for your help. > > Cheers, > Med > >>-----Message d'origine----- >>De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>Envoy=E9 : vendredi 8 juin 2012 17:35 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui >>Objet : Re: [Softwires] WG last call on >>draft-ietf-softwire-dslite-multicast-02 >> >>Hi Med, >> >>I agree with Woj. >> >>I do not favor moving this draft to somewhere else. >> >>Instead this draft should be revised to make it >>Multicast extensions to DS-Lite as in the charter. >> >>There is enough time to do it. >> >>Regards, >> >>Behcet >> >>On Fri, Jun 8, 2012 at 3:43 AM, =A0 wrote: >>> Hi Woj, >>> >>> Your comment is valid. >>> >>> The point I wanted to make is to recall the initial >>motivation of this >>> draft: solve an issue raised by DS-Lite people. >>> >>> Evidently, the proposed approach can be deployed in any >>4-6-4 scenario. This >>> will be reflected in the updated version of the draft. >>> >>> Cheers, >>> Med >>> >>> ________________________________ >>> De=A0: Wojciech Dec [mailto:wdec.ietf@gmail.com] >>> Envoy=E9=A0: vendredi 8 juin 2012 09:57 >>> =C0=A0: BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc=A0: sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui >>> >>> Objet=A0: Re: [Softwires] WG last call on >>> draft-ietf-softwire-dslite-multicast-02 >>> >>> Hello Med, >>> >>> there is no dependency here on ds-lite, ie This has all the >>hallmarks of a >>> standalone solution, which will almost certainly be >>implemented as such, and >>> one that will work with or without ds-lite for unicast. >>> >>> Regards, >>> Woj. >>> >>> On 8 June 2012 07:48, wrote: >>>> >>>> Re-, >>>> >>>> May I re-iterate: >>>> >>>> * The draft is designed to allow the delivery of multicast >>services to >>>> DS-Lite serviced customers. >>>> * The draft proposes multicast extensions and not unicast ones. >>>> >>>> Cheers, >>>> Med >>>> >>>> >-----Message d'origine----- >>>> >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>> >Envoy=E9 : jeudi 7 juin 2012 20:20 >>>> >=C0 : Stig Venaas >>>> >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >>>> >Objet : Re: [Softwires] WG last call on >>>> >draft-ietf-softwire-dslite-multicast-02 >>>> > >>>> >On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas >> wrote: >>>> >> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>>> >>> >>>> >>> On Thu, Jun 7, 2012 at 8:07 >>>> >AM, =A0wrote: >>>> >>>> >>>> > >>>> >>> So you are saying that this draft does not correspond to >>>> >>> Multicast extensions for DS-Lite? >>>> >> >>>> >> >>>> >> I sent a separate review, but anyway, it is not an extension to >>>> >> DS-Lite as I see it. It is a completely generic approach for >>>> >> tunneling v6 through v4. It can certainly be deployed in DS-Lite >>>> >> scenarios, but it is much more generic. I would like the >>title and >>>> >> the text to reflect that. >>>> > >>>> >So it means that this draft does not correspond to Softwire charter >>>> >item and we discover this quite late in the process. >>>> > >>>> >My recommendation to the chairs is to read and double >>check the draft >>>> >before making an adoption call, especially if there is choice. >>>> > >>>> >As I mentioned in my mboned mail, in multicast transition >>I think the >>>> >right approach is to agree to the fact that most of the host's >>>> >communication will be unicast. For unicast, v4-v6 transition has >>>> >already been well analyzed and several protocols have been >>specified. >>>> >Multicast extensions to those protocols are what we need. >>>> > >>>> >Regards, >>>> > >>>> >Behcet >>>> > >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> From pengwu.thu@gmail.com Mon Jun 11 11:38: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 42EAC21F856D for ; Mon, 11 Jun 2012 11:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QqKYxvioXlf for ; Mon, 11 Jun 2012 11:38:39 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF9321F848A for ; Mon, 11 Jun 2012 11:38:39 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2597744qcs.31 for ; Mon, 11 Jun 2012 11:38:39 -0700 (PDT) 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=esCGpRN9Qb+2xJelAFiLMvz+r73SLa//u86RocDnFWA=; b=Btmp5/46XmE/ATtgnPupvNEEC956fz69WrRP91y5iNcPU7aHF5nCvDOTaSe4s6/9He kx4twKiTfPI4/gaLdU81enRrOq96LzhyV9M6DYo7LxAZZ9ffs0dO/THQTTwuUjp9T1a2 /a3W04zxNI808mgW5qpQerh85KnrnjqM70Jyg3R2q7JdSJDs9MIuAnMQWeqtxR4OcKzI w33yjhTWrlyjI53ozVBt+Q749Wrppa5eLvzSPRPkw/T/VLJmWnrre3Av7pWaFFqnUAB0 hunBXD7uOYSGuD7i0bdxX1QmKaKN7Ppi6vvG7YADheCpHd3qxwqts+SYuRAKCcakLxGq 69tw== MIME-Version: 1.0 Received: by 10.229.135.20 with SMTP id l20mr6845520qct.116.1339439919082; Mon, 11 Jun 2012 11:38:39 -0700 (PDT) Received: by 10.229.30.203 with HTTP; Mon, 11 Jun 2012 11:38:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jun 2012 02:38:38 +0800 Message-ID: From: Peng Wu To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 11 Jun 2012 18:38:40 -0000 Woj, On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec wrote: > There is basic question regarding this draft, one that has also been raised > at previous WG meetings: "why is it needed?". It's actually written in section 4 of the draft. > There is a deeper issue here: This draft seems to give the impression that > running such a regular public addressed DHCPv4 based overlay on IPv6 is a > simple idea, as opposed to native dual stack. It is anything but, given that Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar to scenario of DS-Lite and MAP/4rd. I thought the assumption of IPv4-over-IPv6 is that you cannot/do not want to provision native dual-stack? > a) it it requires changes to DHCPv4 processing b) it introduces non trivial > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires changes to > CPE d) makes life really a mess if we consider a real dual stack CPE. a) Simply make DHCPv4 work with IPv6 as underlying transport. No essential changes to protocol processing. b) What really matters here is provisioning the IPv4 address through DHCPv4. Just like in MAP/4rd, you provision the address through DHCPv6. In pb4over6 DHCPv6 is only an *option* to provide the concentrator address. You have similar logic too in MAP. So I don't think it's "non trivial dependancy". They are similar functions for all IPv4-over-IPv6 mechanisms that need provisioning, only different technical paths. c) Any IPv4-over-IPv6 mechanism requires change to CPE From stig@venaas.com Mon Jun 11 12:08: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 E453621F84E1 for ; Mon, 11 Jun 2012 12:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDttz28b8S3L for ; Mon, 11 Jun 2012 12:08:13 -0700 (PDT) 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 AB85B21F843A for ; Mon, 11 Jun 2012 12:08:12 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id C6588802D; Mon, 11 Jun 2012 21:08:09 +0200 (CEST) Message-ID: <4FD641E8.1000803@venaas.com> Date: Mon, 11 Jun 2012 12:07:20 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE855@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FE855@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 11 Jun 2012 19:08:14 -0000 On 6/10/2012 11:15 PM, mohamed.boucadair@orange.com wrote: > Hi Behcet, > > I failed to understand the point you are trying to make. > > The current situations is: > > * this document provides multicast extension to deliver multicast to DS-Lite serviced customers But not only DS-Lite. > * we rely on multicast capabilities, as such no AMT-like considerations are included > * the proposed solution is generic and can be deployed in any 4-6-4 use case Agree it is generic, and I think the draft should be revised to reflect that. Stig > What should be revised? > > Thanks for your help. > > Cheers, > Med > >> -----Message d'origine----- >> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >> Envoyé : vendredi 8 juin 2012 17:35 >> À : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui >> Objet : Re: [Softwires] WG last call on >> draft-ietf-softwire-dslite-multicast-02 >> >> Hi Med, >> >> I agree with Woj. >> >> I do not favor moving this draft to somewhere else. >> >> Instead this draft should be revised to make it >> Multicast extensions to DS-Lite as in the charter. >> >> There is enough time to do it. >> >> Regards, >> >> Behcet >> >> On Fri, Jun 8, 2012 at 3:43 AM, wrote: >>> Hi Woj, >>> >>> Your comment is valid. >>> >>> The point I wanted to make is to recall the initial >> motivation of this >>> draft: solve an issue raised by DS-Lite people. >>> >>> Evidently, the proposed approach can be deployed in any >> 4-6-4 scenario. This >>> will be reflected in the updated version of the draft. >>> >>> Cheers, >>> Med >>> >>> ________________________________ >>> De : Wojciech Dec [mailto:wdec.ietf@gmail.com] >>> Envoyé : vendredi 8 juin 2012 09:57 >>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc : sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui >>> >>> Objet : Re: [Softwires] WG last call on >>> draft-ietf-softwire-dslite-multicast-02 >>> >>> Hello Med, >>> >>> there is no dependency here on ds-lite, ie This has all the >> hallmarks of a >>> standalone solution, which will almost certainly be >> implemented as such, and >>> one that will work with or without ds-lite for unicast. >>> >>> Regards, >>> Woj. >>> >>> On 8 June 2012 07:48, wrote: >>>> >>>> Re-, >>>> >>>> May I re-iterate: >>>> >>>> * The draft is designed to allow the delivery of multicast >> services to >>>> DS-Lite serviced customers. >>>> * The draft proposes multicast extensions and not unicast ones. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>> Envoyé : jeudi 7 juin 2012 20:20 >>>>> À : Stig Venaas >>>>> Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >>>>> Objet : Re: [Softwires] WG last call on >>>>> draft-ietf-softwire-dslite-multicast-02 >>>>> >>>>> On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas >> wrote: >>>>>> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>>>>>> >>>>>>> On Thu, Jun 7, 2012 at 8:07 >>>>> AM, wrote: >>>>>>>> >>>>> >>>>>>> So you are saying that this draft does not correspond to >>>>>>> Multicast extensions for DS-Lite? >>>>>> >>>>>> >>>>>> I sent a separate review, but anyway, it is not an extension to >>>>>> DS-Lite as I see it. It is a completely generic approach for >>>>>> tunneling v6 through v4. It can certainly be deployed in DS-Lite >>>>>> scenarios, but it is much more generic. I would like the >> title and >>>>>> the text to reflect that. >>>>> >>>>> So it means that this draft does not correspond to Softwire charter >>>>> item and we discover this quite late in the process. >>>>> >>>>> My recommendation to the chairs is to read and double >> check the draft >>>>> before making an adoption call, especially if there is choice. >>>>> >>>>> As I mentioned in my mboned mail, in multicast transition >> I think the >>>>> right approach is to agree to the fact that most of the host's >>>>> communication will be unicast. For unicast, v4-v6 transition has >>>>> already been well analyzed and several protocols have been >> specified. >>>>> Multicast extensions to those protocols are what we need. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> From Tina.Tsou.Zouting@huawei.com Mon Jun 11 13:22: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 CF73121F85C7 for ; Mon, 11 Jun 2012 13:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7pe2eKmx9gn for ; Mon, 11 Jun 2012 13:22:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A753F21F85C4 for ; Mon, 11 Jun 2012 13:22:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGV30276; Mon, 11 Jun 2012 16:22:51 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 11 Jun 2012 13:21:21 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Mon, 11 Jun 2012 13:21:17 -0700 From: Tina TSOU To: Stig Venaas Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: AQHNSAWVma8khyqLf0S03e5GHGOzIJb1j3cn Date: Mon, 11 Jun 2012 20:21:16 +0000 Message-ID: <9A327F50-D85B-405A-A6E4-68980C1BB399@huawei.com> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE855@PUEXCB1B.nanterre.francetelecom.fr>, <4FD641E8.1000803@venaas.com> In-Reply-To: <4FD641E8.1000803@venaas.com> Accept-Language: en-US, zh-CN 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 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 11 Jun 2012 20:22:53 -0000 If we r looking for a generic encapsulation for multicast transition, here = it is. http://datatracker.ietf.org/doc/draft-tsou-softwire-encapsulated-multicast/ Tina 408-859-4996 On Jun 11, 2012, at 12:08 PM, "Stig Venaas" wrote: > On 6/10/2012 11:15 PM, mohamed.boucadair@orange.com wrote: >> Hi Behcet, >>=20 >> I failed to understand the point you are trying to make. >>=20 >> The current situations is: >>=20 >> * this document provides multicast extension to deliver multicast to DS-= Lite serviced customers >=20 > But not only DS-Lite. >=20 >> * we rely on multicast capabilities, as such no AMT-like considerations = are included >> * the proposed solution is generic and can be deployed in any 4-6-4 use = case >=20 > Agree it is generic, and I think the draft should be revised to reflect t= hat. >=20 > Stig >=20 >> What should be revised? >>=20 >> Thanks for your help. >>=20 >> Cheers, >> Med >>=20 >>> -----Message d'origine----- >>> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>> Envoy=E9 : vendredi 8 juin 2012 17:35 >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui >>> Objet : Re: [Softwires] WG last call on >>> draft-ietf-softwire-dslite-multicast-02 >>>=20 >>> Hi Med, >>>=20 >>> I agree with Woj. >>>=20 >>> I do not favor moving this draft to somewhere else. >>>=20 >>> Instead this draft should be revised to make it >>> Multicast extensions to DS-Lite as in the charter. >>>=20 >>> There is enough time to do it. >>>=20 >>> Regards, >>>=20 >>> Behcet >>>=20 >>> On Fri, Jun 8, 2012 at 3:43 AM, wrote: >>>> Hi Woj, >>>>=20 >>>> Your comment is valid. >>>>=20 >>>> The point I wanted to make is to recall the initial >>> motivation of this >>>> draft: solve an issue raised by DS-Lite people. >>>>=20 >>>> Evidently, the proposed approach can be deployed in any >>> 4-6-4 scenario. This >>>> will be reflected in the updated version of the draft. >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>> ________________________________ >>>> De : Wojciech Dec [mailto:wdec.ietf@gmail.com] >>>> Envoy=E9 : vendredi 8 juin 2012 09:57 >>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui >>>>=20 >>>> Objet : Re: [Softwires] WG last call on >>>> draft-ietf-softwire-dslite-multicast-02 >>>>=20 >>>> Hello Med, >>>>=20 >>>> there is no dependency here on ds-lite, ie This has all the >>> hallmarks of a >>>> standalone solution, which will almost certainly be >>> implemented as such, and >>>> one that will work with or without ds-lite for unicast. >>>>=20 >>>> Regards, >>>> Woj. >>>>=20 >>>> On 8 June 2012 07:48, wrote: >>>>>=20 >>>>> Re-, >>>>>=20 >>>>> May I re-iterate: >>>>>=20 >>>>> * The draft is designed to allow the delivery of multicast >>> services to >>>>> DS-Lite serviced customers. >>>>> * The draft proposes multicast extensions and not unicast ones. >>>>>=20 >>>>> Cheers, >>>>> Med >>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>>> Envoy=E9 : jeudi 7 juin 2012 20:20 >>>>>> =C0 : Stig Venaas >>>>>> Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >>>>>> Objet : Re: [Softwires] WG last call on >>>>>> draft-ietf-softwire-dslite-multicast-02 >>>>>>=20 >>>>>> On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas >>> wrote: >>>>>>> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>>>>>>>=20 >>>>>>>> On Thu, Jun 7, 2012 at 8:07 >>>>>> AM, wrote: >>>>>>>>>=20 >>>>>>=20 >>>>>>>> So you are saying that this draft does not correspond to >>>>>>>> Multicast extensions for DS-Lite? >>>>>>>=20 >>>>>>>=20 >>>>>>> I sent a separate review, but anyway, it is not an extension to >>>>>>> DS-Lite as I see it. It is a completely generic approach for >>>>>>> tunneling v6 through v4. It can certainly be deployed in DS-Lite >>>>>>> scenarios, but it is much more generic. I would like the >>> title and >>>>>>> the text to reflect that. >>>>>>=20 >>>>>> So it means that this draft does not correspond to Softwire charter >>>>>> item and we discover this quite late in the process. >>>>>>=20 >>>>>> My recommendation to the chairs is to read and double >>> check the draft >>>>>> before making an adoption call, especially if there is choice. >>>>>>=20 >>>>>> As I mentioned in my mboned mail, in multicast transition >>> I think the >>>>>> right approach is to agree to the fact that most of the host's >>>>>> communication will be unicast. For unicast, v4-v6 transition has >>>>>> already been well analyzed and several protocols have been >>> specified. >>>>>> Multicast extensions to those protocols are what we need. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Behcet >>>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>>>=20 >>>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From stig@venaas.com Mon Jun 11 13:31: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 6970711E8096 for ; Mon, 11 Jun 2012 13:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKRgdunTOLYw for ; Mon, 11 Jun 2012 13:31:36 -0700 (PDT) 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 570F211E8094 for ; Mon, 11 Jun 2012 13:31:35 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D4DA77FEE; Mon, 11 Jun 2012 22:31:31 +0200 (CEST) Message-ID: <4FD655A1.6020607@venaas.com> Date: Mon, 11 Jun 2012 13:31:29 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tina TSOU References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE855@PUEXCB1B.nanterre.francetelecom.fr>, <4FD641E8.1000803@venaas.com> <9A327F50-D85B-405A-A6E4-68980C1BB399@huawei.com> In-Reply-To: <9A327F50-D85B-405A-A6E4-68980C1BB399@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 11 Jun 2012 20:31:37 -0000 On 6/11/2012 1:21 PM, Tina TSOU wrote: > If we r looking for a generic encapsulation for multicast transition, here it is. > http://datatracker.ietf.org/doc/draft-tsou-softwire-encapsulated-multicast/ In a way, your draft is even more generic Tina. There are also some differences. You're talking about a stateful mapping function and a protocol for requesting mappings. This is avoided here by using a stateless mapping. But roughly speaking, I think your general description Tina, may also include what this draft does. Stig > Tina > 408-859-4996 > > On Jun 11, 2012, at 12:08 PM, "Stig Venaas" wrote: > >> On 6/10/2012 11:15 PM, mohamed.boucadair@orange.com wrote: >>> Hi Behcet, >>> >>> I failed to understand the point you are trying to make. >>> >>> The current situations is: >>> >>> * this document provides multicast extension to deliver multicast to DS-Lite serviced customers >> >> But not only DS-Lite. >> >>> * we rely on multicast capabilities, as such no AMT-like considerations are included >>> * the proposed solution is generic and can be deployed in any 4-6-4 use case >> >> Agree it is generic, and I think the draft should be revised to reflect that. >> >> Stig >> >>> What should be revised? >>> >>> Thanks for your help. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>> Envoyé : vendredi 8 juin 2012 17:35 >>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui >>>> Objet : Re: [Softwires] WG last call on >>>> draft-ietf-softwire-dslite-multicast-02 >>>> >>>> Hi Med, >>>> >>>> I agree with Woj. >>>> >>>> I do not favor moving this draft to somewhere else. >>>> >>>> Instead this draft should be revised to make it >>>> Multicast extensions to DS-Lite as in the charter. >>>> >>>> There is enough time to do it. >>>> >>>> Regards, >>>> >>>> Behcet >>>> >>>> On Fri, Jun 8, 2012 at 3:43 AM, wrote: >>>>> Hi Woj, >>>>> >>>>> Your comment is valid. >>>>> >>>>> The point I wanted to make is to recall the initial >>>> motivation of this >>>>> draft: solve an issue raised by DS-Lite people. >>>>> >>>>> Evidently, the proposed approach can be deployed in any >>>> 4-6-4 scenario. This >>>>> will be reflected in the updated version of the draft. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> ________________________________ >>>>> De : Wojciech Dec [mailto:wdec.ietf@gmail.com] >>>>> Envoyé : vendredi 8 juin 2012 09:57 >>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>> Cc : sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui >>>>> >>>>> Objet : Re: [Softwires] WG last call on >>>>> draft-ietf-softwire-dslite-multicast-02 >>>>> >>>>> Hello Med, >>>>> >>>>> there is no dependency here on ds-lite, ie This has all the >>>> hallmarks of a >>>>> standalone solution, which will almost certainly be >>>> implemented as such, and >>>>> one that will work with or without ds-lite for unicast. >>>>> >>>>> Regards, >>>>> Woj. >>>>> >>>>> On 8 June 2012 07:48, wrote: >>>>>> >>>>>> Re-, >>>>>> >>>>>> May I re-iterate: >>>>>> >>>>>> * The draft is designed to allow the delivery of multicast >>>> services to >>>>>> DS-Lite serviced customers. >>>>>> * The draft proposes multicast extensions and not unicast ones. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>>>> Envoyé : jeudi 7 juin 2012 20:20 >>>>>>> À : Stig Venaas >>>>>>> Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >>>>>>> Objet : Re: [Softwires] WG last call on >>>>>>> draft-ietf-softwire-dslite-multicast-02 >>>>>>> >>>>>>> On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas >>>> wrote: >>>>>>>> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>>>>>>>> >>>>>>>>> On Thu, Jun 7, 2012 at 8:07 >>>>>>> AM, wrote: >>>>>>>>>> >>>>>>> >>>>>>>>> So you are saying that this draft does not correspond to >>>>>>>>> Multicast extensions for DS-Lite? >>>>>>>> >>>>>>>> >>>>>>>> I sent a separate review, but anyway, it is not an extension to >>>>>>>> DS-Lite as I see it. It is a completely generic approach for >>>>>>>> tunneling v6 through v4. It can certainly be deployed in DS-Lite >>>>>>>> scenarios, but it is much more generic. I would like the >>>> title and >>>>>>>> the text to reflect that. >>>>>>> >>>>>>> So it means that this draft does not correspond to Softwire charter >>>>>>> item and we discover this quite late in the process. >>>>>>> >>>>>>> My recommendation to the chairs is to read and double >>>> check the draft >>>>>>> before making an adoption call, especially if there is choice. >>>>>>> >>>>>>> As I mentioned in my mboned mail, in multicast transition >>>> I think the >>>>>>> right approach is to agree to the fact that most of the host's >>>>>>> communication will be unicast. For unicast, v4-v6 transition has >>>>>>> already been well analyzed and several protocols have been >>>> specified. >>>>>>> Multicast extensions to those protocols are what we need. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 internet-drafts@ietf.org Mon Jun 11 22:43: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 9364A21F85AD; Mon, 11 Jun 2012 22:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFipIrMxvT1V; Mon, 11 Jun 2012 22:43:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F18321F84FC; Mon, 11 Jun 2012 22:43:06 -0700 (PDT) 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.20 Message-ID: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> Date: Mon, 11 Jun 2012 22:43:06 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 05:43: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-02.txt Pages : 16 Date : 2012-06-11 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/submission.filename }}-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateless-4v6-moti= vation-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Mon Jun 11 22:47: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 7CE8D11E8087 for ; Mon, 11 Jun 2012 22:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv2aLlS6Vw-j for ; Mon, 11 Jun 2012 22:47:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9038821F852B for ; Mon, 11 Jun 2012 22:47:53 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3B1BF2642E5 for ; Tue, 12 Jun 2012 07:47:52 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 24ECE35C04E for ; Tue, 12 Jun 2012 07:47:52 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 12 Jun 2012 07:47:52 +0200 From: To: "softwires@ietf.org" Date: Tue, 12 Jun 2012 07:47:50 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: Ac1IXkDwA86aMZTrTqqexTTpxXhhOgAAFi6w Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> References: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> In-Reply-To: <20120612054306.29642.66811.idtracker@ietfa.amsl.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.6.12.35727 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 05:47:54 -0000 Dear WG members, The new version includes the comments received during the WG LC (from Dapen= g). A diff is available here:=20 http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateless-4v6-moti= vation-02 Cheers, Med >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de=20 >internet-drafts@ietf.org >Envoy=E9 : mardi 12 juin 2012 07:43 >=C0 : i-d-announce@ietf.org >Cc : softwires@ietf.org >Objet : [Softwires] I-D Action:=20 >draft-ietf-softwire-stateless-4v6-motivation-02.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Motivations for Carrier-side=20 >Stateless IPv4 over IPv6 Migration Solutions > Author(s) : Mohamed Boucadair > Satoru Matsushima > Yiu Lee > Olaf Bonness > Isabel Borges > Gang Chen > Filename :=20 >draft-ietf-softwire-stateless-4v6-motivation-02.txt > Pages : 16 > Date : 2012-06-11 > >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-motivation > >There's also a htmlized version available at: >http://tools.ietf.org/html/submission.filename }}-02 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >s-4v6-motivation-02 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From maxpassion@gmail.com Mon Jun 11 23:39: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 5742E21F8450 for ; Mon, 11 Jun 2012 23:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW5siwvafDQV for ; Mon, 11 Jun 2012 23:39:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5F0121F844B for ; Mon, 11 Jun 2012 23:39:29 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so10852607obb.31 for ; Mon, 11 Jun 2012 23:39:29 -0700 (PDT) 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=DRtOr5NgToVuEc8DU/Oio+jjFMTuWggx8UcZ+0qdaao=; b=qpJA83Fnxw792HIw7DMGyZ4wRFwWbUZcE+E3e6ps9+6bpCa8BdmdNbK/awFgfWTgOh xmH7IczsFFhAc18yO19cHvMenHbAw49Vwa1/TJmALMMwXJ6WgDZy8Ll8qcgkvI0dfZWP O2gNnkJ+lWJqlMQREYjsoZE+il28QoxzXOSjStpiNZ4jcmAAYKWAceaA3I0akSuqPhu9 0IQsdX72Fq7Ur8CNzL7+hx8jEybVIWzTV+TYqlvgcW+G5DNmR8tKsSCV+Sd7+lIsZJ9+ UTEU13q1ejDdaZucM4cmMHbRpUPLfLkX8er2Dh4Gb7kVqP02l3G8XHH74s+kk4DDPCjV Mkmw== MIME-Version: 1.0 Received: by 10.60.171.135 with SMTP id au7mr19197033oec.62.1339483169118; Mon, 11 Jun 2012 23:39:29 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Mon, 11 Jun 2012 23:39:29 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E331FE64D@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 12 Jun 2012 14:39:29 +0800 Message-ID: From: liu dapeng To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 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, 12 Jun 2012 06:39:30 -0000 Hi Yiu, 2012/6/11, Lee, Yiu : > Hi Med and Dapeng, > > In order to close the gap, I suggest a slight modification: > > "Current standardization effort that is meant to address this IPv4 > service continuity issue focuses mainly on stateful mechanisms that > sharing of global IPv4 addresses between > Customers is based upon the deployment of NAT (Network Address > Translation) capabilities in the network. Because of some caveats of > such stateful approaches the Service Provider community feels that a > companion effort is required to specify stateless IPv4 over IPv6 > approaches. Note that the stateless solution elaborated in this > document > focuses on the carrier-side stateless IPv4 over IPv6 solution. States may > still exist in other equipments such as customer-premises equipment." I am out of office this morning thence miss your mail. I suggest to change "may" to "should" in the above sentence. Regards, Dapeng Liu > Thanks, > Yiu > > > On 6/8/12 8:12 AM, "mohamed.boucadair@orange.com" > wrote: > >>Med: Thanks for the proposal. I shortened your proposal and updated the >>text to: >> >> >> Current standardization effort that is meant to address this IPv4 >> service continuity issue focuses mainly on stateful mechanisms that >> assume the sharing of any global IPv4 address that is left between >> several customers, based upon the deployment of NAT (Network Address >> Translation) capabilities in the network. Because of some caveats of >> such stateful approaches the Service Provider community feels that a >> companion effort is required to specify stateless IPv4 over IPv6 >> approaches. Note stateless IPv4 over IPv6 solutions may be enabled >> in conjunction with a port-restricted NAT44 function located in the >> customer premises. >> This document provides elaboration on the need for carrier-side >> stateless IPv4 over IPv6 solution. > -- ------ Best Regards, Dapeng Liu From maxpassion@gmail.com Tue Jun 12 00:13: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 7FEFB21F8549 for ; Tue, 12 Jun 2012 00:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVt9bPKV-04j for ; Tue, 12 Jun 2012 00:13:51 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5E1721F844A for ; Tue, 12 Jun 2012 00:13:50 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so10903609obb.31 for ; Tue, 12 Jun 2012 00:13:50 -0700 (PDT) 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:content-transfer-encoding; bh=hNHE+HEMoKT0VvKRw/dz5EHTnLMdcepaJNJ+fWs5Gh0=; b=GaDT/E34hp22lUfCiLoi6iu8il9FSqazNRaIfQ+X0O1mxjjtsmzl36aLk9j5kEjwJ3 5Zi6b9E6h/mF9x4/vuaeT4PZlXXkJeVv5IOVZJDCYTzwQ+hJRbkqhG1Gr7BSdZpbb1yH aiOCAEWMD8GmeIY7Yx7NoajQ+n6FMmQLlstZhXg7cMyxMdYxYN0f7gs+K6fD+lQh6iSR 4yY6iHbOHG7qveIMgqnE5l3v5e1wAryRx5+zyuPhmim77nMHVXgkm0Kro0pFh1mt8Y8e TLW7gYtn3RgulV6XK21Qza6zlpa9cvq+KOlrhOeWA0DHDoS8Gj0s62cQJ653+7Q0tEnt RipQ== MIME-Version: 1.0 Received: by 10.182.13.74 with SMTP id f10mr19056132obc.36.1339485230304; Tue, 12 Jun 2012 00:13:50 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Tue, 12 Jun 2012 00:13:50 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> References: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 12 Jun 2012 15:13:50 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 07:13:51 -0000 Hi Med, Thanks for posting this new version but I guess it doesn't reflect all the discussion we had. I suggest to make following modifications. "States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict port numbers within a dedicated range." Please be undestood all the efforts are for precise expression for the read= ers. Thanks, Best Regards, Dapeng Liu 2012/6/12, mohamed.boucadair@orange.com : > Dear WG members, > > The new version includes the comments received during the WG LC (from > Dapeng). > > A diff is available here: > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateless-4v6-mo= tivation-02 > > Cheers, > Med > > >>-----Message d'origine----- >>De : softwires-bounces@ietf.org >>[mailto:softwires-bounces@ietf.org] De la part de >>internet-drafts@ietf.org >>Envoy=E9 : mardi 12 juin 2012 07:43 >>=C0 : i-d-announce@ietf.org >>Cc : softwires@ietf.org >>Objet : [Softwires] I-D Action: >>draft-ietf-softwire-stateless-4v6-motivation-02.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >> This draft is a work item of the Softwires Working Group of the IETF. >> >> Title : Motivations for Carrier-side >>Stateless IPv4 over IPv6 Migration Solutions >> Author(s) : Mohamed Boucadair >> Satoru Matsushima >> Yiu Lee >> Olaf Bonness >> Isabel Borges >> Gang Chen >> Filename : >>draft-ietf-softwire-stateless-4v6-motivation-02.txt >> Pages : 16 >> Date : 2012-06-11 >> >>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-motivation >> >>There's also a htmlized version available at: >>http://tools.ietf.org/html/submission.filename }}-02 >> >>A diff from previous version is available at: >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >>s-4v6-motivation-02 >> >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>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 ------ Best Regards, Dapeng Liu From mohamed.boucadair@orange.com Tue Jun 12 01:12:43 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 4D52921F8501 for ; Tue, 12 Jun 2012 01:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlqGyubfPRr8 for ; Tue, 12 Jun 2012 01:12:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 59AC421F8497 for ; Tue, 12 Jun 2012 01:12:41 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 795F52DC201; Tue, 12 Jun 2012 10:12:40 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 51B894C024; Tue, 12 Jun 2012 10:12:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Tue, 12 Jun 2012 10:12:40 +0200 From: To: liu dapeng Date: Tue, 12 Jun 2012 10:12:38 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: Ac1Iaut76mrtjqrHSxu1soGYAVaWVwABrutA Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FED48@PUEXCB1B.nanterre.francetelecom.fr> References: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.5.24.112414 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 08:12:43 -0000 Hi Dapeng, I can't add the port restriction because stateless IPv4/IPv6 solutions (e.g= ., MAP, 4RD) support also the ability to assign a full IP address. Cheers, Med >-----Message d'origine----- >De : liu dapeng [mailto:maxpassion@gmail.com]=20 >Envoy=E9 : mardi 12 juin 2012 09:14 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : softwires@ietf.org >Objet : Re: [Softwires] I-D Action:=20 >draft-ietf-softwire-stateless-4v6-motivation-02.txt > >Hi Med, > >Thanks for posting this new version but I guess it doesn't reflect all >the discussion we had. I suggest to make following modifications. > >"States still should be maintained in other equipments, e.g. customer >premises equipment or host, in order to restrict port numbers within a >dedicated range." > >Please be undestood all the efforts are for precise expression=20 >for the readers. > >Thanks, > >Best Regards, >Dapeng Liu > >2012/6/12, mohamed.boucadair@orange.com : >> Dear WG members, >> >> The new version includes the comments received during the WG LC (from >> Dapeng). >> >> A diff is available here: >> >>=20 >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles s-4v6-motivation-02 >> >> Cheers, >> Med >> >> >>>-----Message d'origine----- >>>De : softwires-bounces@ietf.org >>>[mailto:softwires-bounces@ietf.org] De la part de >>>internet-drafts@ietf.org >>>Envoy=E9 : mardi 12 juin 2012 07:43 >>>=C0 : i-d-announce@ietf.org >>>Cc : softwires@ietf.org >>>Objet : [Softwires] I-D Action: >>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>> >>> >>>A New Internet-Draft is available from the on-line >>>Internet-Drafts directories. >>> This draft is a work item of the Softwires Working Group of=20 >the IETF. >>> >>> Title : Motivations for Carrier-side >>>Stateless IPv4 over IPv6 Migration Solutions >>> Author(s) : Mohamed Boucadair >>> Satoru Matsushima >>> Yiu Lee >>> Olaf Bonness >>> Isabel Borges >>> Gang Chen >>> Filename : >>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>> Pages : 16 >>> Date : 2012-06-11 >>> >>>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=20 >IPv4 address >>> space. Current standardization effort that addresses IPv4 service >>> continuity focuses on stateful mechanisms. This document=20 >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-motivation >>> >>>There's also a htmlized version available at: >>>http://tools.ietf.org/html/submission.filename }}-02 >>> >>>A diff from previous version is available at: >>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >>>s-4v6-motivation-02 >>> >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>_______________________________________________ >>>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 > >------ >Best Regards, >Dapeng Liu >= From jacni@jacni.com Tue Jun 12 01:34: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 3638321F85B1 for ; Tue, 12 Jun 2012 01:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaWx8+FWI8jc for ; Tue, 12 Jun 2012 01:34:19 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4B521F84FB for ; Tue, 12 Jun 2012 01:34:18 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id F41F63800E5 for ; Tue, 12 Jun 2012 04:34:16 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 6A35D34005D for ; Tue, 12 Jun 2012 16:34:15 +0800 (CST) Received: from [10.140.8.27] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJCrOgUE_9ZPMDY9AQ--.29533S2; Tue, 12 Jun 2012 16:34:13 +0800 (CST) Message-ID: <4FD6FF02.4090503@jacni.com> Date: Tue, 12 Jun 2012 16:34:10 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: multipart/alternative; boundary="------------060700070208060204090308" X-CM-TRANSID: +AWowJCrOgUE_9ZPMDY9AQ--.29533S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJF4rZr1UKFWUAF4rtw4DXFb_yoW5Zw17pF WxWF1UKr48JF1Iy397Cw10vryvvw4vqrW8JF98Ka48Z398Grn5tr1Fvw4rGayUJrs3Cr43 AF4j9r1UW3Z8A3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07jzD73UUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQITEko7lRSF6gBRsM Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 12 Jun 2012 08:34:20 -0000 This is a multi-part message in MIME format. --------------060700070208060204090308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Woj, all, Sorry, my mail box's filter function got some problems, so I missed most of the discussions. I echo Med's comments, it's been stated cleared as below, the scope and the reason why we use that title, thanks! Cheers, Jacni On 6/8/2012 Friday 4:43 PM, mohamed.boucadair@orange.com wrote: > Hi Woj, > Your comment is valid. > The point I wanted to make is to recall the initial motivation of this > draft: solve an issue raised by DS-Lite people. > Evidently, the proposed approach can be deployed in any 4-6-4 > scenario. This will be reflected in the updated version of the draft. > Cheers, > Med > > ------------------------------------------------------------------------ > *De :* Wojciech Dec [mailto:wdec.ietf@gmail.com] > *Envoyé :* vendredi 8 juin 2012 09:57 > *À :* BOUCADAIR Mohamed OLNC/NAD/TIP > *Cc :* sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui > *Objet :* Re: [Softwires] WG last call on > draft-ietf-softwire-dslite-multicast-02 > > Hello Med, > > there is no dependency here on ds-lite, ie This has all the > hallmarks of a standalone solution, which will almost certainly be > implemented as such, and one that will work with or without > ds-lite for unicast. > > Regards, > Woj. > > On 8 June 2012 07:48, > wrote: > > Re-, > > May I re-iterate: > > * The draft is designed to allow the delivery of multicast > services to DS-Lite serviced customers. > * The draft proposes multicast extensions and not unicast ones. > > Cheers, > Med > > >-----Message d'origine----- > >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com > ] > >Envoyé : jeudi 7 juin 2012 20:20 > >À : Stig Venaas > >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org > ; Yong Cui > >Objet : Re: [Softwires] WG last call on > >draft-ietf-softwire-dslite-multicast-02 > > > >On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas > wrote: > >> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: > >>> > >>> On Thu, Jun 7, 2012 at 8:07 > >AM, > wrote: > >>>> > > > >>> So you are saying that this draft does not correspond to > >>> Multicast extensions for DS-Lite? > >> > >> > >> I sent a separate review, but anyway, it is not an extension to > >> DS-Lite as I see it. It is a completely generic approach for > >> tunneling v6 through v4. It can certainly be deployed in > DS-Lite > >> scenarios, but it is much more generic. I would like the > title and > >> the text to reflect that. > > > >So it means that this draft does not correspond to Softwire > charter > >item and we discover this quite late in the process. > > > >My recommendation to the chairs is to read and double check > the draft > >before making an adoption call, especially if there is choice. > > > >As I mentioned in my mboned mail, in multicast transition I > think the > >right approach is to agree to the fact that most of the host's > >communication will be unicast. For unicast, v4-v6 transition has > >already been well analyzed and several protocols have been > specified. > >Multicast extensions to those protocols are what we need. > > > >Regards, > > > >Behcet > > > _______________________________________________ > 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 --------------060700070208060204090308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Woj, all,

Sorry, my mail box's filter function got some problems, so I missed most of the discussions.

I echo Med's comments, it's been stated cleared as below, the scope and the reason why we use that title, thanks!


Cheers,
Jacni

On 6/8/2012 Friday 4:43 PM, mohamed.boucadair@orange.com wrote:
Hi Woj,
 
Your comment is valid.
 
The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people.
 
Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft.
 
Cheers,
Med

De : Wojciech Dec [mailto:wdec.ietf@gmail.com]
Envoyé : vendredi 8 juin 2012 09:57
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui
Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02

Hello Med,

there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast.

Regards,
Woj.

On 8 June 2012 07:48, <mohamed.boucadair@orange.com> wrote:
Re-,

May I re-iterate:

* The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers.
* The draft proposes multicast extensions and not unicast ones.

Cheers,
Med

>-----Message d'origine-----
>De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]
>Envoyé : jeudi 7 juin 2012 20:20
>À : Stig Venaas
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui
>Objet : Re: [Softwires] WG last call on
>draft-ietf-softwire-dslite-multicast-02
>
>On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas <stig@venaas.com> wrote:
>> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote:
>>>
>>> On Thu, Jun 7, 2012 at 8:07
>AM,<mohamed.boucadair@orange.com>  wrote:
>>>>
>
>>> So you are saying that this draft does not correspond to
>>> Multicast extensions for DS-Lite?
>>
>>
>> I sent a separate review, but anyway, it is not an extension to
>> DS-Lite as I see it. It is a completely generic approach for
>> tunneling v6 through v4. It can certainly be deployed in DS-Lite
>> scenarios, but it is much more generic. I would like the title and
>> the text to reflect that.
>
>So it means that this draft does not correspond to Softwire charter
>item and we discover this quite late in the process.
>
>My recommendation to the chairs is to read and double check the draft
>before making an adoption call, especially if there is choice.
>
>As I mentioned in my mboned mail, in multicast transition I think the
>right approach is to agree to the fact that most of the host's
>communication will be unicast. For unicast, v4-v6 transition has
>already been well analyzed and several protocols have been specified.
>Multicast extensions to those protocols are what we need.
>
>Regards,
>
>Behcet
>
_______________________________________________
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
--------------060700070208060204090308-- From jacni@jacni.com Tue Jun 12 01:34: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 F30E021F8618 for ; Tue, 12 Jun 2012 01:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V06km8FCxpMf for ; Tue, 12 Jun 2012 01:34:25 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id B2C3521F8616 for ; Tue, 12 Jun 2012 01:34:25 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id C542D3800CA for ; Tue, 12 Jun 2012 04:34:24 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 6F0AA340008 for ; Tue, 12 Jun 2012 16:34:23 +0800 (CST) Received: from [10.140.8.27] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJD7L40O_9ZPRzY9AQ--.58561S2; Tue, 12 Jun 2012 16:34:23 +0800 (CST) Message-ID: <4FD6FF0C.4080502@jacni.com> Date: Tue, 12 Jun 2012 16:34:20 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stig Venaas References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B5D1.3060803@viagenie.ca> <4FD0E840.1070904@venaas.com> In-Reply-To: <4FD0E840.1070904@venaas.com> Content-Type: multipart/alternative; boundary="------------010207090406010306000901" X-CM-TRANSID: +AWowJD7L40O_9ZPRzY9AQ--.58561S2 X-Coremail-Antispam: 1UD129KBjvJXoW3GryUuFyrtFW5WFWDAF15XFb_yoWxCr1xpa y8KFnxKF4kJrn7CwsrJw1I9a40krs5tw45tF98K34UZ3y5Ga409r18KryrZayDWrZ3W3WY vrs0k3s8Ca1DZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07jfKsbUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQITEko7lRSF6gBSsP Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 12 Jun 2012 08:34:27 -0000 This is a multi-part message in MIME format. --------------010207090406010306000901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stig, Sorry I missed the discussion, and your comments, inline please, hope it won't be too late. On 6/8/2012 Friday 1:43 AM, Stig Venaas wrote: > Here are my last call comments. I think substantial changes are > needed to the draft. > > I understand that this draft is focusing on dslite. But it appears that > it is a generic solution. As it says in the draft: > > An IPv4 receiver accesses IPv4 multicast contents over an IPv6- > only multicast-enabled network. > > Based on this, I think the scope of the draft, the title and > introduction etc should be updated to actually show that it is > a generic approach. And then instead list dslite as one of the > scenarios where this is needed. > > Since it is a generic approach, I think it should also be reviewed, > perhaps an additional WGLC, in mboned. pim wg may also have some > interest in reviewing it. There are some errors regarding pim in > this document. > > In particular, it discussed translation of IGMP/MLD. This is a > topic that has been discussed in mboned/pim, and there is also > another draft discussing this. > > It refers to draft-ietf-mboned-64-multicast-address-format-01. If that > is to stay, I think this draft needs to wait to see what happens with > the address-format draft in 6man. Changes may be needed in this draft > depending on what happens. If only minor changes, the examples in this > draft may need to be updated. > Thanks, it's true. We'll wait for the comments from 6man, and update it accordingly if needed. > > Technical issue: > > In 4.2 it says: > The mB4 uses the G6 (and both S6 and G6 in SSM) to create the > corresponding MLD Report message. The mB4 sends the Report message > to the MLD Querier in the IPv6 network. The MLD Querier (typically > acts as the PIMv6 Designated Router) receives the MLD Report message > and sends the PIMv6 Join to join the IPv6 multicast distribution > tree. The MLD Querier can send either PIMv6 Join (*,G6) in ASM or > PIMv6 Join (S6,G6) in SSM to the mAFTR. > > As is noted, the MLD querier and the DR may be different routers. > It is the DR and not the MLD Querier (if they are different) that > sends the PIM join. Also note that they are often different. If > there are two routers, then the one with the lowest address is the > MLD querier, while the one with the highest address (unless DR > priority is configured) is the DR. > I understand your concern. I guess the Proxying spec solved this issue. > > Near the end of 4.2: > > A branch of the multicast distribution tree is then grafted, > comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 > part (from mAFTR downstream to the mB4). > > It says "is then grafted". So it sounds like the branch is added > to the tree after the procedure has finished. But basically it is > being added to the tree bit by bit as the joins are sent hop by > hop. Maybe it could say "is in this way grafted" or something. > I'm also a bit unsure whether "grafted" is a good term, as "graft" > has a specific meaning for PIM Dense Mode. > Thanks for your suggestion, we'll reword it, and make it clarified. > > At the end of 4.2: > > The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so > as to represent the IPv4-embedded IPv6 source in the IPv6 multicast > network. > > Yes, probably in the IGP. Perhaps say more explicitly that there must > be a route due to PIM's use of RPF. I see this is mentioned in 7.1 > though. > Ok. > > In 6.1 it talks about IGMP messages being translated to MLD. I would > argue that this is not necessarily how this would be done. > Right, I agree with you. Please see my response to Simon, we can update the text to clarify that. > If you look at a pure MLD proxy, you build state for various (*,G) > or (S,G) based on the reports you receive. Then based on this state > you create reports that you send upstream. It is not the message > from downstream that is just sent upstream. In this case, when > receiving downstream IGMP reports, they could be used to create the > IPv6 state. And then independent of whether the state was created > due to IGMP or MLD reports, reports are sent upstream, created from > that state. If you do this, messages are not translated. > > > In 7.1 it says: > > information to discover the source. In order to pass the Reverse > Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on the > interfaces which has the shortest path to the uPrefix64. > > Note that the shortest path might change due to topology changes, links > going down or coming up etc. So one would typically enable PIM on all > the routers. If one wants to constrain multicast to only some of the > topology, there are ways to build a separate multicast RIB for those > routers, and then enable PIM on all of them. > The text just focuses on the special configuration, I understand your concern that it's a little confusing. Maybe we can add some text like "... as prerequisites, basic multicast related configurations should be done accordingly ..." > > In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB > is something different. I think it should say TIB. Check the terms > MRIB and TIB in RFC 4601. > I'll check the terms again. > The draft assumes PIM-SM is used. I think the approach could also > be used with e.g. PIM Bidir (RFC 5015). > Ok, we'll discuss this and come back to you on this point. > > 7.5 talks about scope, and mentions E and 8. Then it says that > this specification does not specify which scope to use. I would > perhaps not mention E and 8 then, it seems now to indicate that > those are the only alternatives. Fine. > > > The security considerations should probably be extended a bit. > E.g. what about scoping? Can one traverse a scoped boundary by > say joining a v4 scoped group using a join for a global v6 > prefix? > Ok, we'll consider that. > > The draft should point out that it is just plain IPv4 in IPv6. At > least that seems to be the intention. However, one might use the > same solution with other tunnel types, e.g. GRE. > We have a similar intention as the DS-Lite spec., we can some text. > > Minor nits: > Thanks, done. > o PIMv4: refers to PIM when deployed in an IPv4 infrastructure > (i.e., IPv4 transfer capabilities are used to exchange PIM > messages). > > o PIMv6: refers to PIM when deployed in an IPv6 infrastructure > (i.e., IPv6 transfer capabilities are used to exchange PIM > messages). > > Replace transfer with transport? > > Section 6.4 starts with this: > > If the mB4 function is implemented in the host which is directly > connected to an IPv6-only network. If an IPv4 application running in > > I'm not exactly sure what the first "if" refers to. This needs to be > reformulated. > > Also in 6.4 there is this typo: "implemntation". > > Stig Thanks again for your careful review and comments. Cheers, Jacni > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --------------010207090406010306000901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stig,

Sorry I missed the discussion, and your comments, inline please, hope it won't be too late.

On 6/8/2012 Friday 1:43 AM, Stig Venaas wrote:
Here are my last call comments. I think substantial changes are
needed to the draft.

I understand that this draft is focusing on dslite. But it appears that
it is a generic solution. As it says in the draft:

   An IPv4 receiver accesses IPv4 multicast contents over an IPv6-
   only multicast-enabled network.

Based on this, I think the scope of the draft, the title and
introduction etc should be updated to actually show that it is
a generic approach. And then instead list dslite as one of the
scenarios where this is needed.

Since it is a generic approach, I think it should also be reviewed,
perhaps an additional WGLC, in mboned. pim wg may also have some
interest in reviewing it. There are some errors regarding pim in
this document.

In particular, it discussed translation of IGMP/MLD. This is a
topic that has been discussed in mboned/pim, and there is also
another draft discussing this.

It refers to draft-ietf-mboned-64-multicast-address-format-01. If that
is to stay, I think this draft needs to wait to see what happens with
the address-format draft in 6man. Changes may be needed in this draft
depending on what happens. If only minor changes, the examples in this
draft may need to be updated.

Thanks, it's true. We'll wait for the comments from 6man, and update it accordingly if needed.


Technical issue:

In 4.2 it says:
   The mB4 uses the G6 (and both S6 and G6 in SSM) to create the
   corresponding MLD Report message.  The mB4 sends the Report message
   to the MLD Querier in the IPv6 network.  The MLD Querier (typically
   acts as the PIMv6 Designated Router) receives the MLD Report message
   and sends the PIMv6 Join to join the IPv6 multicast distribution
   tree.  The MLD Querier can send either PIMv6 Join (*,G6) in ASM or
   PIMv6 Join (S6,G6) in SSM to the mAFTR.

As is noted, the MLD querier and the DR may be different routers.
It is the DR and not the MLD Querier (if they are different) that
sends the PIM join. Also note that they are often different. If
there are two routers, then the one with the lowest address is the
MLD querier, while the one with the highest address (unless DR
priority is configured) is the DR.

I understand your concern. I guess the Proxying spec solved this issue.


Near the end of 4.2:

   A branch of the multicast distribution tree is then grafted,
   comprising both an IPv4 part (from the mAFTR upstream) and an IPv6
   part (from mAFTR downstream to the mB4).

It says "is then grafted". So it sounds like the branch is added
to the tree after the procedure has finished. But basically it is
being added to the tree bit by bit as the joins are sent hop by
hop. Maybe it could say "is in this way grafted" or something.
I'm also a bit unsure whether "grafted" is a good term, as "graft"
has a specific meaning for PIM Dense Mode.

Thanks for your suggestion, we'll reword it, and make it clarified.


At the end of 4.2:

  The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so
  as to represent the IPv4-embedded IPv6 source in the IPv6 multicast
  network.

Yes, probably in the IGP. Perhaps say more explicitly that there must
be a route due to PIM's use of RPF. I see this is mentioned in 7.1
though.

Ok.


In 6.1 it talks about IGMP messages being translated to MLD. I would
argue that this is not necessarily how this would be done.

Right, I agree with you. Please see my response to Simon, we can update the text to clarify that.

If you look at a pure MLD proxy, you build state for various (*,G)
or (S,G) based on the reports you receive. Then based on this state
you create reports that you send upstream. It is not the message
from downstream that is just sent upstream. In this case, when
receiving downstream IGMP reports, they could be used to create the
IPv6 state. And then independent of whether the state was created
due to IGMP or MLD reports, reports are sent upstream, created from
that state. If you do this, messages are not translated.


In 7.1 it says:

   information to discover the source.  In order to pass the Reverse
   Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on the
   interfaces which has the shortest path to the uPrefix64.

Note that the shortest path might change due to topology changes, links
going down or coming up etc. So one would typically enable PIM on all
the routers. If one wants to constrain multicast to only some of the
topology, there are ways to build a separate multicast RIB for those
routers, and then enable PIM on all of them.

The text just focuses on the special configuration, I understand your concern that it's a little confusing.
Maybe we can add some text like "... as prerequisites, basic multicast related configurations should be done accordingly ..."


In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB
is something different. I think it should say TIB. Check the terms
MRIB and TIB in RFC 4601.

I'll check the terms again.

The draft assumes PIM-SM is used. I think the approach could also
be used with e.g. PIM Bidir (RFC 5015).

Ok, we'll discuss this and come back to you on this point.


7.5 talks about scope, and mentions E and 8. Then it says that
this specification does not specify which scope to use. I would
perhaps not mention E and 8 then, it seems now to indicate that
those are the only alternatives.
Fine.



The security considerations should probably be extended a bit.
E.g. what about scoping? Can one traverse a scoped boundary by
say joining a v4 scoped group using a join for a global v6
prefix?

Ok, we'll consider that.


The draft should point out that it is just plain IPv4 in IPv6. At
least that seems to be the intention. However, one might use the
same solution with other tunnel types, e.g. GRE.

We have a similar intention as the DS-Lite spec., we can some text.


Minor nits:

Thanks, done.

 o  PIMv4: refers to PIM when deployed in an IPv4 infrastructure
      (i.e., IPv4 transfer capabilities are used to exchange PIM
      messages).

   o  PIMv6: refers to PIM when deployed in an IPv6 infrastructure
      (i.e., IPv6 transfer capabilities are used to exchange PIM
      messages).

Replace transfer with transport?

Section 6.4 starts with this:

   If the mB4 function is implemented in the host which is directly
   connected to an IPv6-only network.  If an IPv4 application running in

I'm not exactly sure what the first "if" refers to. This needs to be
reformulated.

Also in 6.4 there is this typo: "implemntation".

Stig

Thanks again for your careful review and comments.


Cheers,
Jacni


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


--------------010207090406010306000901-- From maxpassion@gmail.com Tue Jun 12 02:49: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 39A8421F85DF for ; Tue, 12 Jun 2012 02:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu1xh9AH7LCo for ; Tue, 12 Jun 2012 02:49:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6519F21F85CD for ; Tue, 12 Jun 2012 02:49:17 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so11141940obb.31 for ; Tue, 12 Jun 2012 02:49:16 -0700 (PDT) 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:content-transfer-encoding; bh=gQHkqaCy/ij/q51nb/xnSgHYV0R+koWCP8MWwxFh85Y=; b=XacyGXZ0uC/5p5Tsk5ggmXOmWMnaHFqKWgrODcatdHGLII0KJlfbR3BLF24fDeAqLs lqPQRxVZDvGFdnsEzj1ACvBvM29LKFoWG7CDnUkYP5//mXNmhjIaIJrz5G8l4iB0x9CE RQGa7wNvYyQjyN1Gq5KsghraV8jyfRskSR8PPvIA57qYfzfmFJjaWZSnOkiZox4fSMXB fGnZPWkWXgDZiGrDFP0FZ5aIws2Svwh6L26zl/T5wEWDXlWoLZhIxR1Vi3QhV86uCE40 GMb8jxldd2zkH2hdIzuLa/T9MyW9qPQHHN1Ajx7Ja1wudDJ5zKJnPjWUb0wnH4CnsYXw IGeA== MIME-Version: 1.0 Received: by 10.60.28.162 with SMTP id c2mr19745953oeh.3.1339494556747; Tue, 12 Jun 2012 02:49:16 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Tue, 12 Jun 2012 02:49:16 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FED48@PUEXCB1B.nanterre.francetelecom.fr> References: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FED48@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 12 Jun 2012 17:49:16 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 09:49:18 -0000 Ok, then we can make this more clear in our document. "States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict IP address or port number information into the configured context except that a non-shared IPv4 addre= ss is assigned to a standalone host." Best Regards, Dapeng Liu 2012/6/12, mohamed.boucadair@orange.com : > Hi Dapeng, > > I can't add the port restriction because stateless IPv4/IPv6 solutions > (e.g., MAP, 4RD) support also the ability to assign a full IP address. > > Cheers, > Med > >>-----Message d'origine----- >>De : liu dapeng [mailto:maxpassion@gmail.com] >>Envoy=E9 : mardi 12 juin 2012 09:14 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : softwires@ietf.org >>Objet : Re: [Softwires] I-D Action: >>draft-ietf-softwire-stateless-4v6-motivation-02.txt >> >>Hi Med, >> >>Thanks for posting this new version but I guess it doesn't reflect all >>the discussion we had. I suggest to make following modifications. >> >>"States still should be maintained in other equipments, e.g. customer >>premises equipment or host, in order to restrict port numbers within a >>dedicated range." >> >>Please be undestood all the efforts are for precise expression >>for the readers. >> >>Thanks, >> >>Best Regards, >>Dapeng Liu >> >>2012/6/12, mohamed.boucadair@orange.com : >>> Dear WG members, >>> >>> The new version includes the comments received during the WG LC (from >>> Dapeng). >>> >>> A diff is available here: >>> >>> >>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles > s-4v6-motivation-02 >>> >>> Cheers, >>> Med >>> >>> >>>>-----Message d'origine----- >>>>De : softwires-bounces@ietf.org >>>>[mailto:softwires-bounces@ietf.org] De la part de >>>>internet-drafts@ietf.org >>>>Envoy=E9 : mardi 12 juin 2012 07:43 >>>>=C0 : i-d-announce@ietf.org >>>>Cc : softwires@ietf.org >>>>Objet : [Softwires] I-D Action: >>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> >>>> >>>>A New Internet-Draft is available from the on-line >>>>Internet-Drafts directories. >>>> This draft is a work item of the Softwires Working Group of >>the IETF. >>>> >>>> Title : Motivations for Carrier-side >>>>Stateless IPv4 over IPv6 Migration Solutions >>>> Author(s) : Mohamed Boucadair >>>> Satoru Matsushima >>>> Yiu Lee >>>> Olaf Bonness >>>> Isabel Borges >>>> Gang Chen >>>> Filename : >>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> Pages : 16 >>>> Date : 2012-06-11 >>>> >>>>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-motivation >>>> >>>>There's also a htmlized version available at: >>>>http://tools.ietf.org/html/submission.filename }}-02 >>>> >>>>A diff from previous version is available at: >>>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >>>>s-4v6-motivation-02 >>>> >>>> >>>>Internet-Drafts are also available by anonymous FTP at: >>>>ftp://ftp.ietf.org/internet-drafts/ >>>> >>>>_______________________________________________ >>>>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 >>> >> >> >>-- >> >>------ >>Best Regards, >>Dapeng Liu >> --=20 ------ Best Regards, Dapeng Liu From ichiroumakino@gmail.com Tue Jun 12 02:51:23 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 59EA421F862F for ; Tue, 12 Jun 2012 02:51:23 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yVI4LMIDWrZ for ; Tue, 12 Jun 2012 02:51:22 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6823021F8628 for ; Tue, 12 Jun 2012 02:51:22 -0700 (PDT) Received: by eekd4 with SMTP id d4so3002097eek.31 for ; Tue, 12 Jun 2012 02:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DtxgFtu1wZG8qjvf6UbSCXnAUwNUWFfFKqf4jsfKk5k=; b=NdfsUzA/G3tzmL6nBP1R4VmwoMd203k+5bZUKV1ryJQeAVtlx3oCB9YuD138qcr9OU T28bUZzg6HT/OJyn4HWwARl4yeGjWIyKXblXBNyxLHpqQ2EomuFOWvwDb4TvSuME43Ti s7ColLwdiv4OLlDbAkXgzzj1KILWXe3D2eA2NYWX1B8xXLhnfh9ATMSGoQvp4ll61PYG 5X1R7Ire1oz3XwKB8nlk+lf3fp6HnPJMoHWdQura64fQ7EN9UN1RYeEHSsJHHXfhKOzf puGmnOpTJetXvBTnWg+w0ThtnxL/PrMJicSitMGMd9w1vpXwxC6VoWye5WKwFyKR1JhH 1teQ== Received: by 10.14.27.204 with SMTP id e52mr6374022eea.53.1339494681368; Tue, 12 Jun 2012 02:51:21 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id g46sm34093682eea.14.2012.06.12.02.51.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jun 2012 02:51:20 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Tue, 12 Jun 2012 11:51:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FED48@PUEXCB1B.nanterre.francetelecom.fr> To: liu dapeng X-Mailer: Apple Mail (2.1278) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 09:51:23 -0000 > Ok, then we can make this more clear in our document. >=20 > "States still should be maintained in other equipments, e.g. customer > premises equipment or host, in order to restrict IP address or port = number > information into the configured context except that a non-shared IPv4 = address is > assigned to a standalone host." I think this is just adding confusion. the NAT44 on the CPE already does this. I suggest we instead talk about no _additional_ state in the network. = there is no need to mention the CPE, apart from stating that no = additional state is required. cheers, Ole From wdec.ietf@gmail.com Tue Jun 12 02:52: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 AC9BA21F84B6 for ; Tue, 12 Jun 2012 02:52:48 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbXomOY3NLoq for ; Tue, 12 Jun 2012 02:52:48 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2A8321F8493 for ; Tue, 12 Jun 2012 02:52:47 -0700 (PDT) Received: by qadz3 with SMTP id z3so2500181qad.10 for ; Tue, 12 Jun 2012 02:52:47 -0700 (PDT) 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=jig99C0/rMOqRSNWPSDeJEwCsLtx4eyYVEQBcGhyrXI=; b=MQQC/isdT+2t6T+Bykr4oqeVYU/XlyIH1DBqM+tqv7mlAkAcTTP8kAImuYo44r4uSI 9RpcYbak6n4J/Q4iO4nYy+omLjq5tlFossrJRi1Hid2J+bONGsnVA0ZDSBy9JwgqxeOo DofCaPK4eVW/Dp9Qx+9bSNngrGJkKsd4If6toMaFlzacyx6Qg5/aYVAYERdcG13Pl6TX 3HAL8t2/R8MUJ96NcVu4M/khK2Kf3wFN354MtLCV7WCc++t23qtfKZnIFaVpoYmTI/lh sIAOTM3PMt9mY3AUllSZ4Oc+L/tvflXLJoMBIAMu45L6LUUqMYxVxBMfVH4ZzLSJxLYw yGZg== MIME-Version: 1.0 Received: by 10.229.136.82 with SMTP id q18mr7980286qct.147.1339494767056; Tue, 12 Jun 2012 02:52:47 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Tue, 12 Jun 2012 02:52:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jun 2012 11:52:46 +0200 Message-ID: From: Wojciech Dec To: Peng Wu Content-Type: multipart/alternative; boundary=00248c769136c4d6cf04c2436dba Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 12 Jun 2012 09:52:48 -0000 --00248c769136c4d6cf04c2436dba Content-Type: text/plain; charset=ISO-8859-1 Peng, On 11 June 2012 20:38, Peng Wu wrote: > Woj, > > On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec wrote: > > There is basic question regarding this draft, one that has also been > raised > > at previous WG meetings: "why is it needed?". > It's actually written in section 4 of the draft. > > > There is a deeper issue here: This draft seems to give the impression > that > > running such a regular public addressed DHCPv4 based overlay on IPv6 is a > > simple idea, as opposed to native dual stack. It is anything but, given > that > Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar > to scenario of DS-Lite and MAP/4rd. > I thought the assumption of IPv4-over-IPv6 is that you cannot/do not > want to provision native dual-stack? > To put it simply: This draft describes a scenario where public v4 addresses are available. The "classic" v6 migration scenario is in this case "dual stack" and is what I believe has been advised for years by the IETF, and continues to be the recommended approach. Why would one want to run in this case dual-stack over a tunnel infra is the question? Is this intended as an academic draft (as in "we can do it, but don't know why")? > > > a) it it requires changes to DHCPv4 processing b) it introduces non > trivial > > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires > changes to > > CPE d) makes life really a mess if we consider a real dual stack CPE. > a) Simply make DHCPv4 work with IPv6 as underlying transport. No > essential changes to protocol processing. > Woj> That's not what the draft DHCPv4overv6 indicates, unless one assumes a very specific and limiting deployment scenario. In any case it's quite clear that it is not possible to use regular DHCPv4 clients for this, or a regular DHCPv4 server (there is no mention of how the broadcast flags should be handled, mapped to IPv6, etc). > b) What really matters here is provisioning the IPv4 address through > DHCPv4. Just like in MAP/4rd, you provision the address through > DHCPv6. > In pb4over6 DHCPv6 is only an *option* to provide the concentrator > address. You have similar logic too in MAP. > So I don't think it's "non trivial dependancy". They are similar > functions for all IPv4-over-IPv6 mechanisms that need provisioning, > only different technical paths. > There are several components/parts that all need to play together in this solution, many more than apparently required, and the failure of one is not obvious to anyone looking at another. As in any such multi-part system design, the overall complexity is higher. > c) Any IPv4-over-IPv6 mechanism requires change to CPE > Yes, but in the case of this draft, the changes that are proposed do not lead to anything over and above what plain dual stack accomplishes, except extra complexity. --00248c769136c4d6cf04c2436dba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peng,

On 11 June 2012 20:38, Peng Wu <pengwu.thu@gmail.com> wrote:
Woj,

On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> There is basic question regarding this draft, one that has also been r= aised
> at previous WG meetings: "why is it needed?".
It's actually written in section 4 of the draft.

> There is a deeper issue here: This draft seems to give the impression = that
> running such a regular public addressed DHCPv4 based overlay on IPv6 i= s a
> simple idea, as opposed to native dual stack. It is anything but, give= n that
Why is it opposed to native dual-stack? It's IPv4-over-IPv6, simi= lar
to scenario of DS-Lite and MAP/4rd.
I thought the assumption of IPv4-over-IPv6 is that you cannot/do not
want to provision native dual-stack?

To put it sim= ply: This draft describes a scenario where public v4 addresses are availabl= e. The "classic" v6 migration scenario is in this case "dual= stack" and is what I believe has been advised for years by the IETF, = and continues to be the recommended approach. Why would one want to run in = this case dual-stack over a tunnel infra is the question? Is this intended = as an academic draft (as in "we can do it, but don't know why"= ;)?

> a) it it requires changes to DHCPv4 processing b) it introduces non tr= ivial
> dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires chan= ges to
> CPE d) makes life really a mess if we consider a real dual stack CPE.<= br>
a) Simply make DHCPv4 work with IPv6 as underlying transport. No
essential changes to protocol processing.

Woj> = That's not what the draft DHCPv4overv6 indicates, unless one assumes a = very specific and limiting deployment scenario. In any case it's quite = clear that it is not possible to use regular DHCPv4 clients for this, or a = regular DHCPv4 server (there is no mention of how the broadcast flags shoul= d be handled, mapped to IPv6, etc).
=A0
b) What really matters here is provisioning the IPv4 address through
DHCPv4. Just like in MAP/4rd, you provision the address through
DHCPv6.
In pb4over6 DHCPv6 is only an *option* to provide the concentrator
address. You have similar logic too in MAP.
So I don't think it's "non trivial dependancy". They are = similar
functions for all IPv4-over-IPv6 mechanisms that need provisioning,
only different technical paths.

There are several = components/parts that all need to play together in this solution, many more= than apparently required, and the failure of one is not obvious to anyone = looking at another. As in any such multi-part system design, the overall co= mplexity is higher.
=A0
c) Any IPv4-over-IPv6 mechanism requires change to CPE

Yes, but in the case of this draft, the changes that are proposed do n= ot lead to anything over and above what plain dual stack accomplishes, exce= pt extra complexity.

--00248c769136c4d6cf04c2436dba-- From maxpassion@gmail.com Tue Jun 12 03:22:00 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 43A3521F8562 for ; Tue, 12 Jun 2012 03:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.314 X-Spam-Level: X-Spam-Status: No, score=-3.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIOKbMivv1i7 for ; Tue, 12 Jun 2012 03:21:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E38FC21F855F for ; Tue, 12 Jun 2012 03:21:58 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so11188976obb.31 for ; Tue, 12 Jun 2012 03:21:57 -0700 (PDT) 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:content-transfer-encoding; bh=XkfpCdUEix8AebJRDiTwFq9+Be5V7x+9+9KOikFv/BA=; b=LuFydy/uZznxqFGUZSbpg8M8gBcD8IrA0B7lbIa4g3YaCmIEvVcTTaaPVPx4JKnpzH mIQJqqJ8KqiXEYaLBRRQ5kVbsbupDUfw5sWQw6mkmXcaiXiOU1L+6lW65Bm3u8JPcttQ CSZY5qhVsVHB6ncpcMW2/af5BeGYztdkKjxkXTlm9rqAn+nTNNohBzwX4zmMF1lfN9+d l+2O3Q9IKPu2Nvq+lrTThvEuxxq4CSCHw2xY8csUuNnh+sGLhQX8mYuJQfDsV0FdBjnp NRTqrCcex7Ac3HeB5bHKeWl0Lg7adPynTqowsjn74/vfpnJk+KyZFCbAHwfBqkg4Y8Oh BaLQ== MIME-Version: 1.0 Received: by 10.60.171.135 with SMTP id au7mr19843047oec.62.1339496517021; Tue, 12 Jun 2012 03:21:57 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Tue, 12 Jun 2012 03:21:56 -0700 (PDT) In-Reply-To: References: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FED48@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 12 Jun 2012 18:21:56 +0800 Message-ID: From: liu dapeng To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 10:22:00 -0000 2012/6/12, Ole Tr=F8an : >> Ok, then we can make this more clear in our document. >> >> "States still should be maintained in other equipments, e.g. customer >> premises equipment or host, in order to restrict IP address or port >> number >> information into the configured context except that a non-shared IPv4 >> address is >> assigned to a standalone host." > > I think this is just adding confusion. > the NAT44 on the CPE already does this. =3D>First off, we are not only talking about NAT44 here, but port translation and non-shared address. Secondly, NAT44 on the CPE is not doing what today NAT44 does. For example, override ID in ICMP with port information. that reminds me to update the proposed text a bit, "States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict L3 or L4 information into the configured context except that a non-shared IPv4 address is assigned to a standalone host." > I suggest we instead talk about no _additional_ state in the network. the= re > is no need to mention the CPE, apart from stating that no additional stat= e > is required. =3D>I believe the above is clear for reader and designer. I don't see why we resist on clarifying and helping reader better understanding. Regards, Dapeng Liu > cheers, > Ole > > > --=20 ------ Best Regards, Dapeng Liu From mohamed.boucadair@orange.com Tue Jun 12 04:45: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 661C021F84B4 for ; Tue, 12 Jun 2012 04:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj0VBzvT2nKB for ; Tue, 12 Jun 2012 04:45:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15921F858F for ; Tue, 12 Jun 2012 04:45:05 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B237A2DC16C; Tue, 12 Jun 2012 13:44:57 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 990114C015; Tue, 12 Jun 2012 13:44:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Tue, 12 Jun 2012 13:44:57 +0200 From: To: liu dapeng Date: Tue, 12 Jun 2012 13:44:56 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: Ac1IgKMM2nF1GJlpRbaPcqUAlAd4fgADw0dA Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FEE4A@PUEXCB1B.nanterre.francetelecom.fr> References: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FED48@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.5.24.112414 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 11:45:13 -0000 Re-, Please see inline. Cheers, Med =20 >-----Message d'origine----- >De : liu dapeng [mailto:maxpassion@gmail.com]=20 >Envoy=E9 : mardi 12 juin 2012 11:49 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : softwires@ietf.org >Objet : Re: [Softwires] I-D Action:=20 >draft-ietf-softwire-stateless-4v6-motivation-02.txt > > Ok, then we can make this more clear in our document. > >"States still should be maintained in other equipments, Med: Why "should"? The NAT is not mandatory and even if port restriction is= needed, a host may just restrict its port to be within the range. So, I do= n't see a reason to change "may" to "should". e.g. customer >premises equipment or host, in order to restrict IP address or=20 >port number >information into the configured context except that a=20 >non-shared IPv4 address is >assigned to a standalone host." Med: No need to elaborate what the state is about. You asked to add a sente= nce to say a state may exist in the LAN side, I updated the text to cover y= our comment:=20 "States may still exist in other equipments such as customer premises equip= ment." > > >Best Regards, >Dapeng Liu > >2012/6/12, mohamed.boucadair@orange.com : >> Hi Dapeng, >> >> I can't add the port restriction because stateless IPv4/IPv6=20 >solutions >> (e.g., MAP, 4RD) support also the ability to assign a full=20 >IP address. >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : liu dapeng [mailto:maxpassion@gmail.com] >>>Envoy=E9 : mardi 12 juin 2012 09:14 >>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>Cc : softwires@ietf.org >>>Objet : Re: [Softwires] I-D Action: >>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>> >>>Hi Med, >>> >>>Thanks for posting this new version but I guess it doesn't=20 >reflect all >>>the discussion we had. I suggest to make following modifications. >>> >>>"States still should be maintained in other equipments, e.g.=20 > customer >>>premises equipment or host, in order to restrict port=20 >numbers within a >>>dedicated range." >>> >>>Please be undestood all the efforts are for precise expression >>>for the readers. >>> >>>Thanks, >>> >>>Best Regards, >>>Dapeng Liu >>> >>>2012/6/12, mohamed.boucadair@orange.com=20 >: >>>> Dear WG members, >>>> >>>> The new version includes the comments received during the=20 >WG LC (from >>>> Dapeng). >>>> >>>> A diff is available here: >>>> >>>> >>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >> s-4v6-motivation-02 >>>> >>>> Cheers, >>>> Med >>>> >>>> >>>>>-----Message d'origine----- >>>>>De : softwires-bounces@ietf.org >>>>>[mailto:softwires-bounces@ietf.org] De la part de >>>>>internet-drafts@ietf.org >>>>>Envoy=E9 : mardi 12 juin 2012 07:43 >>>>>=C0 : i-d-announce@ietf.org >>>>>Cc : softwires@ietf.org >>>>>Objet : [Softwires] I-D Action: >>>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>> >>>>> >>>>>A New Internet-Draft is available from the on-line >>>>>Internet-Drafts directories. >>>>> This draft is a work item of the Softwires Working Group of >>>the IETF. >>>>> >>>>> Title : Motivations for Carrier-side >>>>>Stateless IPv4 over IPv6 Migration Solutions >>>>> Author(s) : Mohamed Boucadair >>>>> Satoru Matsushima >>>>> Yiu Lee >>>>> Olaf Bonness >>>>> Isabel Borges >>>>> Gang Chen >>>>> Filename : >>>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>> Pages : 16 >>>>> Date : 2012-06-11 >>>>> >>>>>Abstract: >>>>> IPv4 service continuity is one of the most pressing=20 >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=20 >IPv4 service >>>>> continuity focuses on stateful mechanisms. This document >>>elaborates >>>>> on the motivations for the need to undertake a=20 >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-motivation >>>>> >>>>>There's also a htmlized version available at: >>>>>http://tools.ietf.org/html/submission.filename }}-02 >>>>> >>>>>A diff from previous version is available at: >>>>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >>>>>s-4v6-motivation-02 >>>>> >>>>> >>>>>Internet-Drafts are also available by anonymous FTP at: >>>>>ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>>_______________________________________________ >>>>>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 >>>> >>> >>> >>>-- >>> >>>------ >>>Best Regards, >>>Dapeng Liu >>> > > >--=20 > >------ >Best Regards, >Dapeng Liu >= From yiu_lee@cable.comcast.com Tue Jun 12 05:46: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 B967521F8547 for ; Tue, 12 Jun 2012 05:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQyEaNGu1wCh for ; Tue, 12 Jun 2012 05:46:19 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id E20E121F8532 for ; Tue, 12 Jun 2012 05:46:18 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.20860374; Tue, 12 Jun 2012 06:29:42 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 08:46:14 -0400 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: AQHNSJlZpXK6odl3xUusf1L2LJvHbg== Date: Tue, 12 Jun 2012 12:46:13 +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.2.120421 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422335569_43787" MIME-Version: 1.0 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 12:46:19 -0000 --B_3422335569_43787 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. The focus of it is about the carrier network, CPE is never the focal point. I think the current statement "States may still exist in other equipments such as customer premises equipment." is enough. Adding more text only causes confusion. Thanks, Yiu On 6/12/12 6:21 AM, "liu dapeng" wrote: >2012/6/12, Ole Tr=F8an : >>> Ok, then we can make this more clear in our document. >>> >>> "States still should be maintained in other equipments, e.g. customer >>> premises equipment or host, in order to restrict IP address or port >>> number >>> information into the configured context except that a non-shared IPv4 >>> address is >>> assigned to a standalone host." >> >> I think this is just adding confusion. >> the NAT44 on the CPE already does this. > >=3D>First off, we are not only talking about NAT44 here, but port >translation and non-shared address. Secondly, NAT44 on the CPE is not >doing what today NAT44 does. For example, override ID in ICMP with >port information. > >that reminds me to update the proposed text a bit, > >"States still should be maintained in other equipments, e.g. customer >premises equipment or host, in order to restrict L3 or L4 information >into the configured context except that a non-shared IPv4 address is >assigned to a standalone host." > >> I suggest we instead talk about no _additional_ state in the network. >>there >> is no need to mention the CPE, apart from stating that no additional >>state >> is required. > >=3D>I believe the above is clear for reader and designer. I don't see why >we resist on clarifying and helping reader better understanding. > >Regards, >Dapeng Liu > > >> cheers, >> Ole >> >> >> > > >--=20 > >------ >Best Regards, >Dapeng Liu >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3422335569_43787 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT58n7d vILrPYhpNoEvLvNg2qgzUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MTIxMjQ2MDhaMA0GCSqGSIb3DQEBAQUABIIBAFodw0jEUVyN4StqbtnB3cwS goOqHZhNRdaslbmgYXZ4TyhavAakhFSfZl7ST30EEY3w8BOiRVQQcCF+5Yjd2A546NKKJEWy PBM4NbeFcPt3FISsEoyrTSAuin4nSEPSVO5wgiY8qTv1gD2XZu4I0ajegHOLH3kSCM57E3ts 15O7qYKzstp8O8RT3UM8jLZmdq7t320Z+BTwxDdi3hatoDBfOYWaOwlDReHVhS4r6uA22ahD n+aK2DQUkL/Mbz4Z7HEWteA935wGNWVabTMvBloi5OULM5WUMMoxrPJHNCNR+dT0IP0OEipZ PYKyZTuPmq7qfhBTmfDFcJMH7RpMA14= --B_3422335569_43787-- From maxpassion@gmail.com Tue Jun 12 08:36: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 D6EA021F86EA for ; Tue, 12 Jun 2012 08:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.462 X-Spam-Level: X-Spam-Status: No, score=-3.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dojWgJ4E5yfH for ; Tue, 12 Jun 2012 08:36:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF0B521F86C9 for ; Tue, 12 Jun 2012 08:36:05 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so11603841obb.31 for ; Tue, 12 Jun 2012 08:36:05 -0700 (PDT) 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:content-transfer-encoding; bh=QB/QIhhZltzWLcHSiHMu40miawmO2GX0MeTA74ZvTng=; b=wo6LcIIOy+w9+GvPwZCMGX7PabHSyZa5QNSR3UqXh05aSc/0lKBSaDipI63r2KYQXT R6AE8Lq/c3d9eNxelCaA6x5pmcuoivNZ3+OOpNBeiTyyF4bAq28zX00ZxW/jahNw7Auh 8/6gkaNAjh6jO2GgbB9MePkmh4AQBltydUYCjgcG2Rdo5EBMQHVSr2eO1D1EXCf6fZb8 m44WDWlHOwHLdxZCPuIj/s2CT9rZ0ipfTzsq4NvSQpTvKGPHc1LRyE2j2hCBl7O7LvzA XdVr6bjttW/9Y3UWnK19VU4zC8/izTdLHOdXm5LCnOOqed3O9/ddmEpRBQyJh1oyU5hE c6Vg== MIME-Version: 1.0 Received: by 10.182.207.106 with SMTP id lv10mr3610397obc.48.1339515365031; Tue, 12 Jun 2012 08:36:05 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Tue, 12 Jun 2012 08:36:04 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FEE4A@PUEXCB1B.nanterre.francetelecom.fr> References: <20120612054306.29642.66811.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36E331FEC8A@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FED48@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FEE4A@PUEXCB1B.nanterre.francetelecom.fr> Date: Tue, 12 Jun 2012 23:36:04 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 15:36:07 -0000 2012/6/12, mohamed.boucadair@orange.com : > Re-, > > Please see inline. > > Cheers, > Med > > >>-----Message d'origine----- >>De : liu dapeng [mailto:maxpassion@gmail.com] >>Envoy=E9 : mardi 12 juin 2012 11:49 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : softwires@ietf.org >>Objet : Re: [Softwires] I-D Action: >>draft-ietf-softwire-stateless-4v6-motivation-02.txt >> >> Ok, then we can make this more clear in our document. >> >>"States still should be maintained in other equipments, > > Med: Why "should"? The NAT is not mandatory =3D>Current candidate solutions told me the NAT44 is mandatory part i.e. "The NAPT MUST in turn be connected to a MAP aware forwarding function, that does encapsulation/ decapsulation or translation to IPv6." and even if port restriction is > needed, a host may just restrict its port to be within the range. =3D> This part we had discussed yesterday. That is a step back for our discussion, since you have acknowledged that is a state. So, I > don't see a reason to change "may" to "should". =3D> depending on above, I think it should change "may" to "should" > > e.g. customer >>premises equipment or host, in order to restrict IP address or >>port number >>information into the configured context except that a >>non-shared IPv4 address is >>assigned to a standalone host." > > Med: No need to elaborate what the state is about. You asked to add a > sentence to say a state may exist in the LAN side, I updated the text to > cover your comment: > > "States may still exist in other equipments such as customer premises > equipment." =3D> We have already figured out what state is about, why not stated. If th= ere is any flawed bug, I'm happy to fix it. But I can't accept push back withou= t any reasonable justification. Regards, Dapeng > >> >> >>Best Regards, >>Dapeng Liu >> >>2012/6/12, mohamed.boucadair@orange.com : >>> Hi Dapeng, >>> >>> I can't add the port restriction because stateless IPv4/IPv6 >>solutions >>> (e.g., MAP, 4RD) support also the ability to assign a full >>IP address. >>> >>> Cheers, >>> Med >>> >>>>-----Message d'origine----- >>>>De : liu dapeng [mailto:maxpassion@gmail.com] >>>>Envoy=E9 : mardi 12 juin 2012 09:14 >>>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>Cc : softwires@ietf.org >>>>Objet : Re: [Softwires] I-D Action: >>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> >>>>Hi Med, >>>> >>>>Thanks for posting this new version but I guess it doesn't >>reflect all >>>>the discussion we had. I suggest to make following modifications. >>>> >>>>"States still should be maintained in other equipments, e.g. >> customer >>>>premises equipment or host, in order to restrict port >>numbers within a >>>>dedicated range." >>>> >>>>Please be undestood all the efforts are for precise expression >>>>for the readers. >>>> >>>>Thanks, >>>> >>>>Best Regards, >>>>Dapeng Liu >>>> >>>>2012/6/12, mohamed.boucadair@orange.com >>: >>>>> Dear WG members, >>>>> >>>>> The new version includes the comments received during the >>WG LC (from >>>>> Dapeng). >>>>> >>>>> A diff is available here: >>>>> >>>>> >>>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >>> s-4v6-motivation-02 >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> >>>>>>-----Message d'origine----- >>>>>>De : softwires-bounces@ietf.org >>>>>>[mailto:softwires-bounces@ietf.org] De la part de >>>>>>internet-drafts@ietf.org >>>>>>Envoy=E9 : mardi 12 juin 2012 07:43 >>>>>>=C0 : i-d-announce@ietf.org >>>>>>Cc : softwires@ietf.org >>>>>>Objet : [Softwires] I-D Action: >>>>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>> >>>>>> >>>>>>A New Internet-Draft is available from the on-line >>>>>>Internet-Drafts directories. >>>>>> This draft is a work item of the Softwires Working Group of >>>>the IETF. >>>>>> >>>>>> Title : Motivations for Carrier-side >>>>>>Stateless IPv4 over IPv6 Migration Solutions >>>>>> Author(s) : Mohamed Boucadair >>>>>> Satoru Matsushima >>>>>> Yiu Lee >>>>>> Olaf Bonness >>>>>> Isabel Borges >>>>>> Gang Chen >>>>>> Filename : >>>>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>> Pages : 16 >>>>>> Date : 2012-06-11 >>>>>> >>>>>>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-motivation >>>>>> >>>>>>There's also a htmlized version available at: >>>>>>http://tools.ietf.org/html/submission.filename }}-02 >>>>>> >>>>>>A diff from previous version is available at: >>>>>>http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >>>>>>s-4v6-motivation-02 >>>>>> >>>>>> >>>>>>Internet-Drafts are also available by anonymous FTP at: >>>>>>ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>>_______________________________________________ >>>>>>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 >>>>> >>>> >>>> >>>>-- >>>> >>>>------ >>>>Best Regards, >>>>Dapeng Liu >>>> >> >> >>-- >> >>------ >>Best Regards, >>Dapeng Liu >> --=20 ------ Best Regards, Dapeng Liu From maxpassion@gmail.com Tue Jun 12 08:45: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 98FE221F86AF for ; Tue, 12 Jun 2012 08:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzW8O-C-DPTK for ; Tue, 12 Jun 2012 08:45:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5B6121F86AB for ; Tue, 12 Jun 2012 08:45:21 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so11615256obb.31 for ; Tue, 12 Jun 2012 08:45:21 -0700 (PDT) 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:content-transfer-encoding; bh=aYuk7lu8LwgFP7y2vS41nSkvEWrpqKvhDxVmKfFSDDo=; b=RYeJg78c6h86cN1KBnLdPsjM+dCMoLBhf9AVLEqFC/L24rmohAf7K3xL5AlFkz8X8s BKa0H9OeUv945/pF1GHDT9jC98XpWPytz9FNh5fhJvpiPgpzjfeQOPaTa2iwitM/MwsT Z9eWqIltwu0CR2bxg18XNBwo6poy4XE8sAO8+M5Nm7ZZL50UEwwactdb6WuoJWdD/PaU Ajq/oKjhhCxBxX8bHPqw6AZjRKxCw+kEv3LF8f8t3Q5uS60HkvxPO/EfKgPm8haVbPns MfiHntiXCFasPA2cabE3++DJcO40qgQC8smrTt+Fzy3AbY0qq2Q1xs7GuIljD79hZPgy bYhQ== MIME-Version: 1.0 Received: by 10.182.36.102 with SMTP id p6mr20748486obj.77.1339515921194; Tue, 12 Jun 2012 08:45:21 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Tue, 12 Jun 2012 08:45:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jun 2012 23:45:21 +0800 Message-ID: From: liu dapeng To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 15:45:22 -0000 2012/6/12, Lee, Yiu : > Hi Dapeng., > > This is not a specification draft. This is a draft to discuss the > motivations. IMHO, people who are working in this area would be able to > understand this draft. =3D> I guess the audience is not only designer of protocol, but also operat= ors who want to evaluate and adopt such technology. Intentional hiding the trut= h for me is really bad. The focus of it is about the carrier network, CPE > is never the focal point. I think the current statement "States may still > exist in other equipments such as customer premises equipment." is enough= . =3D>Please see my reply in previous mail. "may" is not sufficient. > Adding more text only causes confusion. =3D>What I do is objectively to elaborate what we are. Why would that cause confusion? Regards, Dapeng > Thanks, > Yiu > > On 6/12/12 6:21 AM, "liu dapeng" wrote: > >>2012/6/12, Ole Tr=F8an : >>>> Ok, then we can make this more clear in our document. >>>> >>>> "States still should be maintained in other equipments, e.g. customer >>>> premises equipment or host, in order to restrict IP address or port >>>> number >>>> information into the configured context except that a non-shared IPv4 >>>> address is >>>> assigned to a standalone host." >>> >>> I think this is just adding confusion. >>> the NAT44 on the CPE already does this. >> >>=3D>First off, we are not only talking about NAT44 here, but port >>translation and non-shared address. Secondly, NAT44 on the CPE is not >>doing what today NAT44 does. For example, override ID in ICMP with >>port information. >> >>that reminds me to update the proposed text a bit, >> >>"States still should be maintained in other equipments, e.g. customer >>premises equipment or host, in order to restrict L3 or L4 information >>into the configured context except that a non-shared IPv4 address is >>assigned to a standalone host." >> >>> I suggest we instead talk about no _additional_ state in the network. >>>there >>> is no need to mention the CPE, apart from stating that no additional >>>state >>> is required. >> >>=3D>I believe the above is clear for reader and designer. I don't see why >>we resist on clarifying and helping reader better understanding. >> >>Regards, >>Dapeng Liu >> >> >>> cheers, >>> Ole >>> >>> >>> >> >> >>-- >> >>------ >>Best Regards, >>Dapeng Liu >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires > --=20 ------ Best Regards, Dapeng Liu From mohamed.boucadair@orange.com Tue Jun 12 09:14: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 CCBB521F8646 for ; Tue, 12 Jun 2012 09:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaM2-j6a-x9S for ; Tue, 12 Jun 2012 09:14:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id BEBC721F8597 for ; Tue, 12 Jun 2012 09:14:39 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id CAC073B444C; Tue, 12 Jun 2012 18:14:38 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id AFDF535C045; Tue, 12 Jun 2012 18:14:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 12 Jun 2012 18:14:38 +0200 From: To: "Lee, Yiu" , "softwires@ietf.org" Date: Tue, 12 Jun 2012 18:14:37 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: AQHNSJlZpXK6odl3xUusf1L2LJvHbpb225qQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FF021@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.5.24.112414 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 16:14:40 -0000 Hi Yiu, +1. Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Lee, Yiu >Envoy=E9 : mardi 12 juin 2012 14:46 >=C0 : softwires@ietf.org >Objet : Re: [Softwires] I-D Action:=20 >draft-ietf-softwire-stateless-4v6-motivation-02.txt > >Hi Dapeng., > >This is not a specification draft. This is a draft to discuss the >motivations. IMHO, people who are working in this area would be able to >understand this draft. The focus of it is about the carrier=20 >network, CPE >is never the focal point. I think the current statement=20 >"States may still >exist in other equipments such as customer premises=20 >equipment." is enough. >Adding more text only causes confusion. > >Thanks, >Yiu > >On 6/12/12 6:21 AM, "liu dapeng" wrote: > >>2012/6/12, Ole Tr=F8an : >>>> Ok, then we can make this more clear in our document. >>>> >>>> "States still should be maintained in other equipments,=20 >e.g. customer >>>> premises equipment or host, in order to restrict IP address or port >>>> number >>>> information into the configured context except that a=20 >non-shared IPv4 >>>> address is >>>> assigned to a standalone host." >>> >>> I think this is just adding confusion. >>> the NAT44 on the CPE already does this. >> >>=3D>First off, we are not only talking about NAT44 here, but port >>translation and non-shared address. Secondly, NAT44 on the CPE is not >>doing what today NAT44 does. For example, override ID in ICMP with >>port information. >> >>that reminds me to update the proposed text a bit, >> >>"States still should be maintained in other equipments, e.g. customer >>premises equipment or host, in order to restrict L3 or L4 information >>into the configured context except that a non-shared IPv4 address is >>assigned to a standalone host." >> >>> I suggest we instead talk about no _additional_ state in=20 >the network. >>>there >>> is no need to mention the CPE, apart from stating that no additional >>>state >>> is required. >> >>=3D>I believe the above is clear for reader and designer. I=20 >don't see why >>we resist on clarifying and helping reader better understanding. >> >>Regards, >>Dapeng Liu >> >> >>> cheers, >>> Ole >>> >>> >>> >> >> >>--=20 >> >>------ >>Best Regards, >>Dapeng Liu >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires >= From rajiva@cisco.com Tue Jun 12 09:17: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 2F01221F8513 for ; Tue, 12 Jun 2012 09:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.566 X-Spam-Level: X-Spam-Status: No, score=-9.566 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wk5OsHl4DaHK for ; Tue, 12 Jun 2012 09:17:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C1C2121F854E for ; Tue, 12 Jun 2012 09:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4130; q=dns/txt; s=iport; t=1339517831; x=1340727431; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=3HK/+WcjI1ijoe8VgZP9McFy6yOzLxCyPTZpXOeqIpc=; b=UIVAUAxIpG7EwvfLNPjPIwh7tZh1AIe/JfRqeat6b9NhL5Bro6Lg8b2m kdJNjbDeLPEJeGCuyZJJmWuhrI+/Sm1cdYV0r/TQUY2YR/11Kfr0rskzw ILlefEar9oz6jYHuR0OQ3CwQMf+qnFek66K3N5G05eHnw6y32wep2aqeR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUFAPFp10+tJXG+/2dsb2JhbABFhVeuP4EfAoEHghgBAQEDAQEBAQ8BEBEzBwsQAgEIGAICIwMCAgIfBh8RAQEEEyKHWwMGBQuZNY0WiQQNiUoEgSCJJWKCdoIJMmADiECMX4p+gxeBZoMA X-IronPort-AV: E=Sophos;i="4.75,758,1330905600"; d="scan'208";a="88769347" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jun 2012 16:17:11 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5CGHBGA005660; Tue, 12 Jun 2012 16:17:11 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 11:17:10 -0500 Received: from 72.163.62.219 ([72.163.62.219]) by XMB-RCD-212.cisco.com ([72.163.62.219]) with Microsoft Exchange Server HTTP-DAV ; Tue, 12 Jun 2012 16:17:10 +0000 References: <94C682931C08B048B7A8645303FDC9F36E331FF021@PUEXCB1B.nanterre.francetelecom.fr> Content-Transfer-Encoding: base64 From: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset="utf-8" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: Ac1IttG099dmacWERTeGufeFn47Sew== In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FF021@PUEXCB1B.nanterre.francetelecom.fr> Message-ID: <48E221AE-AA51-4B01-9E8F-20FC43D18EE1@cisco.com> Date: Tue, 12 Jun 2012 09:16:52 -0700 To: MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 12 Jun 2012 16:17:10.0889 (UTC) FILETIME=[D20C6D90:01CD48B6] Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 16:17:13 -0000 KzENCg0KQ2hlZXJzLA0KUmFqaXYNCg0KU2VudCBmcm9tIG15IFBob25lDQoNCk9uIEp1biAxMiwg MjAxMiwgYXQgOToxNCBBTSwgIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIDxtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPiANCj4gSGkgWWl1LA0KPiANCj4gDQo+ ICsxLg0KPiANCj4gDQo+IENoZWVycywNCj4gTWVkIA0KPiANCj4+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPj4gRGUgOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyANCj4+IFttYWls dG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTGVlLCBZaXUNCj4+ IEVudm95w6kgOiBtYXJkaSAxMiBqdWluIDIwMTIgMTQ6NDYNCj4+IMOAIDogc29mdHdpcmVzQGll dGYub3JnDQo+PiBPYmpldCA6IFJlOiBbU29mdHdpcmVzXSBJLUQgQWN0aW9uOiANCj4+IGRyYWZ0 LWlldGYtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uLTAyLnR4dA0KPj4gDQo+PiBI aSBEYXBlbmcuLA0KPj4gDQo+PiBUaGlzIGlzIG5vdCBhIHNwZWNpZmljYXRpb24gZHJhZnQuIFRo aXMgaXMgYSBkcmFmdCB0byBkaXNjdXNzIHRoZQ0KPj4gbW90aXZhdGlvbnMuIElNSE8sIHBlb3Bs ZSB3aG8gYXJlIHdvcmtpbmcgaW4gdGhpcyBhcmVhIHdvdWxkIGJlIGFibGUgdG8NCj4+IHVuZGVy c3RhbmQgdGhpcyBkcmFmdC4gVGhlIGZvY3VzIG9mIGl0IGlzIGFib3V0IHRoZSBjYXJyaWVyIA0K Pj4gbmV0d29yaywgQ1BFDQo+PiBpcyBuZXZlciB0aGUgZm9jYWwgcG9pbnQuIEkgdGhpbmsgdGhl IGN1cnJlbnQgc3RhdGVtZW50IA0KPj4gIlN0YXRlcyBtYXkgc3RpbGwNCj4+IGV4aXN0IGluIG90 aGVyIGVxdWlwbWVudHMgc3VjaCBhcyBjdXN0b21lciBwcmVtaXNlcyANCj4+IGVxdWlwbWVudC4i IGlzIGVub3VnaC4NCj4+IEFkZGluZyBtb3JlIHRleHQgb25seSBjYXVzZXMgY29uZnVzaW9uLg0K Pj4gDQo+PiBUaGFua3MsDQo+PiBZaXUNCj4+IA0KPj4gT24gNi8xMi8xMiA2OjIxIEFNLCAibGl1 IGRhcGVuZyIgPG1heHBhc3Npb25AZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4+IDIwMTIvNi8x MiwgT2xlIFRyw7hhbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+Og0KPj4+Pj4gT2ssIHRoZW4gd2Ug Y2FuIG1ha2UgdGhpcyBtb3JlIGNsZWFyIGluIG91ciBkb2N1bWVudC4NCj4+Pj4+IA0KPj4+Pj4g IlN0YXRlcyBzdGlsbCBzaG91bGQgYmUgbWFpbnRhaW5lZCBpbiBvdGhlciBlcXVpcG1lbnRzLCAN Cj4+IGUuZy4gY3VzdG9tZXINCj4+Pj4+IHByZW1pc2VzIGVxdWlwbWVudCBvciBob3N0LCBpbiBv cmRlciB0byByZXN0cmljdCBJUCBhZGRyZXNzIG9yIHBvcnQNCj4+Pj4+IG51bWJlcg0KPj4+Pj4g aW5mb3JtYXRpb24gaW50byB0aGUgY29uZmlndXJlZCBjb250ZXh0IGV4Y2VwdCB0aGF0IGEgDQo+ PiBub24tc2hhcmVkIElQdjQNCj4+Pj4+IGFkZHJlc3MgaXMNCj4+Pj4+IGFzc2lnbmVkIHRvIGEg c3RhbmRhbG9uZSBob3N0LiINCj4+Pj4gDQo+Pj4+IEkgdGhpbmsgdGhpcyBpcyBqdXN0IGFkZGlu ZyBjb25mdXNpb24uDQo+Pj4+IHRoZSBOQVQ0NCBvbiB0aGUgQ1BFIGFscmVhZHkgZG9lcyB0aGlz Lg0KPj4+IA0KPj4+ID0+Rmlyc3Qgb2ZmLCB3ZSBhcmUgbm90IG9ubHkgdGFsa2luZyBhYm91dCBO QVQ0NCBoZXJlLCBidXQgcG9ydA0KPj4+IHRyYW5zbGF0aW9uIGFuZCBub24tc2hhcmVkIGFkZHJl c3MuIFNlY29uZGx5LCBOQVQ0NCBvbiB0aGUgQ1BFIGlzIG5vdA0KPj4+IGRvaW5nIHdoYXQgdG9k YXkgTkFUNDQgZG9lcy4gRm9yIGV4YW1wbGUsIG92ZXJyaWRlIElEIGluIElDTVAgd2l0aA0KPj4+ IHBvcnQgaW5mb3JtYXRpb24uDQo+Pj4gDQo+Pj4gdGhhdCByZW1pbmRzIG1lIHRvIHVwZGF0ZSB0 aGUgcHJvcG9zZWQgdGV4dCBhIGJpdCwNCj4+PiANCj4+PiAiU3RhdGVzIHN0aWxsIHNob3VsZCBi ZSBtYWludGFpbmVkIGluIG90aGVyIGVxdWlwbWVudHMsIGUuZy4gY3VzdG9tZXINCj4+PiBwcmVt aXNlcyBlcXVpcG1lbnQgb3IgaG9zdCwgaW4gb3JkZXIgdG8gcmVzdHJpY3QgTDMgb3IgTDQgaW5m b3JtYXRpb24NCj4+PiBpbnRvIHRoZSBjb25maWd1cmVkIGNvbnRleHQgZXhjZXB0IHRoYXQgYSBu b24tc2hhcmVkIElQdjQgYWRkcmVzcyBpcw0KPj4+IGFzc2lnbmVkIHRvIGEgc3RhbmRhbG9uZSBo b3N0LiINCj4+PiANCj4+Pj4gSSBzdWdnZXN0IHdlIGluc3RlYWQgdGFsayBhYm91dCBubyBfYWRk aXRpb25hbF8gc3RhdGUgaW4gDQo+PiB0aGUgbmV0d29yay4NCj4+Pj4gdGhlcmUNCj4+Pj4gaXMg bm8gbmVlZCB0byBtZW50aW9uIHRoZSBDUEUsIGFwYXJ0IGZyb20gc3RhdGluZyB0aGF0IG5vIGFk ZGl0aW9uYWwNCj4+Pj4gc3RhdGUNCj4+Pj4gaXMgcmVxdWlyZWQuDQo+Pj4gDQo+Pj4gPT5JIGJl bGlldmUgdGhlIGFib3ZlIGlzIGNsZWFyIGZvciByZWFkZXIgYW5kIGRlc2lnbmVyLiBJIA0KPj4g ZG9uJ3Qgc2VlIHdoeQ0KPj4+IHdlIHJlc2lzdCBvbiBjbGFyaWZ5aW5nIGFuZCBoZWxwaW5nIHJl YWRlciBiZXR0ZXIgdW5kZXJzdGFuZGluZy4NCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IERhcGVu ZyBMaXUNCj4+PiANCj4+PiANCj4+Pj4gY2hlZXJzLA0KPj4+PiBPbGUNCj4+Pj4gDQo+Pj4+IA0K Pj4+PiANCj4+PiANCj4+PiANCj4+PiAtLSANCj4+PiANCj4+PiAtLS0tLS0NCj4+PiBCZXN0IFJl Z2FyZHMsDQo+Pj4gRGFwZW5nIExpdQ0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPj4+IFNvZnR3 aXJlc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c29mdHdpcmVzDQo+PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiBTb2Z0d2lyZXNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg== From sarikaya2012@gmail.com Tue Jun 12 13:11: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 97D9121F8599 for ; Tue, 12 Jun 2012 13:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUR-5j1lCqaF for ; Tue, 12 Jun 2012 13:11:08 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58B1B21F858F for ; Tue, 12 Jun 2012 13:11:08 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4420710ghb.31 for ; Tue, 12 Jun 2012 13:11:07 -0700 (PDT) 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:content-transfer-encoding; bh=GexvgMtLhbLK3rqP7IZ9uVJ2d590XHgtl0YGp9yQ2kc=; b=N8r6vYmXwuC89dUqENJR0QcKUVMr8rP4q/ttIz+XI+DCQw/8+1Ye8oVpMC6A8Me3YJ c1rCi+gsGjEgVHXE974aTHpXfxAespRAPv4Owoc9SgtewC4HuBCglR3p9DAfB2ZNtV1K shFhNtkh8lFDMJW/7G5Y7CwlssU9RxDIGf2DOVFt5ndYo1reZM4gqAt3Ofn1DCNHodVp rogChcLKLDAzCpXQRC3b1H86VzgrmotVRC4S5ImChKAJuu7DZ8naTONdOVmlq6uPUU8k opavQ/+CwoQgOO0eYsqKn6/U3su9QJpHPo2tAALHr/nGLyMXon1Fp8kFyW+Zuafl9Qzh /Nmg== MIME-Version: 1.0 Received: by 10.50.159.135 with SMTP id xc7mr9419818igb.9.1339531867587; Tue, 12 Jun 2012 13:11:07 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Tue, 12 Jun 2012 13:11:07 -0700 (PDT) In-Reply-To: <4FD6FF0C.4080502@jacni.com> References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B5D1.3060803@viagenie.ca> <4FD0E840.1070904@venaas.com> <4FD6FF0C.4080502@jacni.com> Date: Tue, 12 Jun 2012 15:11:07 -0500 Message-ID: From: Behcet Sarikaya To: Jacni Qin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Tue, 12 Jun 2012 20:11:12 -0000 I think that a decision should be made on this draft. If it is going to present a generic solution it could be fine but then such a draft does not meet Softwire charter item so it can not stay in Softwire. My suggestion is to make it specific to DS-Lite so that it stays in Softwire and meets the charter item. I believe this was Alain's intention when he asked the two drafts to be mer= ged. Regards, Behcet On Tue, Jun 12, 2012 at 3:34 AM, Jacni Qin wrote: > Hi Stig, > > Sorry I missed the discussion, and your comments, inline please, hope it > won't be too late. > > On 6/8/2012 Friday 1:43 AM, Stig Venaas wrote: > > Here are my last call comments. I think substantial changes are > needed to the draft. > > I understand that this draft is focusing on dslite. But it appears that > it is a generic solution. As it says in the draft: > > =A0=A0 An IPv4 receiver accesses IPv4 multicast contents over an IPv6- > =A0=A0 only multicast-enabled network. > > Based on this, I think the scope of the draft, the title and > introduction etc should be updated to actually show that it is > a generic approach. And then instead list dslite as one of the > scenarios where this is needed. > > Since it is a generic approach, I think it should also be reviewed, > perhaps an additional WGLC, in mboned. pim wg may also have some > interest in reviewing it. There are some errors regarding pim in > this document. > > > In particular, it discussed translation of IGMP/MLD. This is a > topic that has been discussed in mboned/pim, and there is also > another draft discussing this. > > It refers to draft-ietf-mboned-64-multicast-address-format-01. If that > is to stay, I think this draft needs to wait to see what happens with > the address-format draft in 6man. Changes may be needed in this draft > depending on what happens. If only minor changes, the examples in this > draft may need to be updated. > > Thanks, it's true. We'll wait for the comments from 6man, and update it > accordingly if needed. > > > > Technical issue: > > In 4.2 it says: > =A0=A0 The mB4 uses the G6 (and both S6 and G6 in SSM) to create the > =A0=A0 corresponding MLD Report message.=A0 The mB4 sends the Report mess= age > =A0=A0 to the MLD Querier in the IPv6 network.=A0 The MLD Querier (typica= lly > =A0=A0 acts as the PIMv6 Designated Router) receives the MLD Report messa= ge > =A0=A0 and sends the PIMv6 Join to join the IPv6 multicast distribution > =A0=A0 tree.=A0 The MLD Querier can send either PIMv6 Join (*,G6) in ASM = or > =A0=A0 PIMv6 Join (S6,G6) in SSM to the mAFTR. > > As is noted, the MLD querier and the DR may be different routers. > It is the DR and not the MLD Querier (if they are different) that > sends the PIM join. Also note that they are often different. If > there are two routers, then the one with the lowest address is the > MLD querier, while the one with the highest address (unless DR > priority is configured) is the DR. > > I understand your concern. I guess the Proxying spec solved this issue. > > > > Near the end of 4.2: > > =A0=A0 A branch of the multicast distribution tree is then grafted, > =A0=A0 comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 > =A0=A0 part (from mAFTR downstream to the mB4). > > It says "is then grafted". So it sounds like the branch is added > to the tree after the procedure has finished. But basically it is > being added to the tree bit by bit as the joins are sent hop by > hop. Maybe it could say "is in this way grafted" or something. > I'm also a bit unsure whether "grafted" is a good term, as "graft" > has a specific meaning for PIM Dense Mode. > > Thanks for your suggestion, we'll reword it, and make it clarified. > > > > At the end of 4.2: > > =A0 The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so > =A0 as to represent the IPv4-embedded IPv6 source in the IPv6 multicast > =A0 network. > > Yes, probably in the IGP. Perhaps say more explicitly that there must > be a route due to PIM's use of RPF. I see this is mentioned in 7.1 > though. > > Ok. > > > > In 6.1 it talks about IGMP messages being translated to MLD. I would > argue that this is not necessarily how this would be done. > > Right, I agree with you. Please see my response to Simon, we can update t= he > text to clarify that. > > > If you look at a pure MLD proxy, you build state for various (*,G) > or (S,G) based on the reports you receive. Then based on this state > you create reports that you send upstream. It is not the message > from downstream that is just sent upstream. In this case, when > receiving downstream IGMP reports, they could be used to create the > IPv6 state. And then independent of whether the state was created > due to IGMP or MLD reports, reports are sent upstream, created from > that state. If you do this, messages are not translated. > > > In 7.1 it says: > > =A0=A0 information to discover the source.=A0 In order to pass the Revers= e > =A0=A0 Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on t= he > =A0=A0 interfaces which has the shortest path to the uPrefix64. > > Note that the shortest path might change due to topology changes, links > going down or coming up etc. So one would typically enable PIM on all > the routers. If one wants to constrain multicast to only some of the > topology, there are ways to build a separate multicast RIB for those > routers, and then enable PIM on all of them. > > The text just focuses on the special configuration, I understand your > concern that it's a little confusing. > Maybe we can add some text like "... as prerequisites, basic multicast > related configurations should be done accordingly ..." > > > > In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB > is something different. I think it should say TIB. Check the terms > MRIB and TIB in RFC 4601. > > I'll check the terms again. > > > The draft assumes PIM-SM is used. I think the approach could also > be used with e.g. PIM Bidir (RFC 5015). > > Ok, we'll discuss this and come back to you on this point. > > > > 7.5 talks about scope, and mentions E and 8. Then it says that > this specification does not specify which scope to use. I would > perhaps not mention E and 8 then, it seems now to indicate that > those are the only alternatives. > > Fine. > > > > > The security considerations should probably be extended a bit. > E.g. what about scoping? Can one traverse a scoped boundary by > say joining a v4 scoped group using a join for a global v6 > prefix? > > Ok, we'll consider that. > > > > The draft should point out that it is just plain IPv4 in IPv6. At > least that seems to be the intention. However, one might use the > same solution with other tunnel types, e.g. GRE. > > We have a similar intention as the DS-Lite spec., we can some text. > > > Minor nits: > > Thanks, done. > > > =A0o=A0 PIMv4: refers to PIM when deployed in an IPv4 infrastructure > =A0=A0=A0=A0=A0 (i.e., IPv4 transfer capabilities are used to exchange PI= M > =A0=A0=A0=A0=A0 messages). > > =A0=A0 o=A0 PIMv6: refers to PIM when deployed in an IPv6 infrastructure > =A0=A0=A0=A0=A0 (i.e., IPv6 transfer capabilities are used to exchange PI= M > =A0=A0=A0=A0=A0 messages). > > Replace transfer with transport? > > Section 6.4 starts with this: > > =A0=A0 If the mB4 function is implemented in the host which is directly > =A0=A0 connected to an IPv6-only network.=A0 If an IPv4 application runni= ng in > > I'm not exactly sure what the first "if" refers to. This needs to be > reformulated. > > Also in 6.4 there is this typo: "implemntation". > > Stig > > > Thanks again for your careful review and comments. > > > Cheers, > Jacni > > > > _______________________________________________ > 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 tom.taylor.stds@gmail.com Tue Jun 12 13:16: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 1D92621F85E7 for ; Tue, 12 Jun 2012 13:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfF0A+3rxPis for ; Tue, 12 Jun 2012 13:16:16 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA13821F85C7 for ; Tue, 12 Jun 2012 13:16:10 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so898703lbb.31 for ; Tue, 12 Jun 2012 13:16:09 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=Lfl1vZk+lnrlx50IfRrii0fmuA64bKHAmdp7gTG5lFc=; b=g2aiTnc2rffbOwfMTpbg50PnbJ+LW5FZCxMOpvPJOsiSePXEedG8eiSu8YlSovq/Oa wDgZdN/9RMXx2uSc1D700bpk6fswF6h/3cVIyuq5j/SrFmKU8fUUZ5+WYZBo+E52BF2i gW6/CCN5tcopjhjvn53VjtbqZCVTayDu+lFstVHoB+0shKDCDR2JjuqwAuR4Wy1D0DAr vktjtMbed7QS4pI7RI7RCNcuq5/iUeq44HZz2U8DwaPuz4iPFJMJhwO6tVbrduhlPA6p W4e8NXy1AHz7wVOBUpgE2voJZAAIf4Un/N8JMnifmbRtYZo/aDUlFXdpKnbWbczb8dHa 1+EQ== Received: by 10.112.49.100 with SMTP id t4mr5221598lbn.10.1339532169493; Tue, 12 Jun 2012 13:16:09 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-85-206.tor.primus.ca. [173.206.85.206]) by mx.google.com with ESMTPS id h9sm1458245lbi.9.2012.06.12.13.16.06 (version=SSLv3 cipher=OTHER); Tue, 12 Jun 2012 13:16:08 -0700 (PDT) Message-ID: <4FD7A384.7080501@gmail.com> Date: Tue, 12 Jun 2012 16:16:04 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B5D1.3060803@viagenie.ca> <4FD0E840.1070904@venaas.com> <4FD6FF0C.4080502@jacni.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120612-0, 12/06/2012), Outbound message X-Antivirus-Status: Clean Cc: "softwires@ietf.org" , Behcet Sarikaya Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 12 Jun 2012 20:16:17 -0000 Well, it is still in the Softwires domain if it tunnels the multicast data, is it not? On 12/06/2012 4:11 PM, Behcet Sarikaya wrote: > I think that a decision should be made on this draft. If it is going > to present a generic solution it could be fine but then such a draft > does not meet Softwire charter item so it can not stay in Softwire. > > My suggestion is to make it specific to DS-Lite so that it stays in > Softwire and meets the charter item. > > I believe this was Alain's intention when he asked the two drafts to be merged. > > Regards, > > Behcet > ... From sarikaya2012@gmail.com Tue Jun 12 13:30:41 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 1D04611E8073 for ; Tue, 12 Jun 2012 13:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ho+bVp581hL for ; Tue, 12 Jun 2012 13:30:39 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE7AF11E8072 for ; Tue, 12 Jun 2012 13:30:37 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4438947ghb.31 for ; Tue, 12 Jun 2012 13:30:37 -0700 (PDT) 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=I1HplmwBPDRC99b0Il7ECvh/KHuQbh8OI3tn5YQI3o0=; b=Kz23N0pLtMcWU8Z2J94aKsWak2kFUS5QVKlbE4gKPY4MyhAue80N3PQamRf42e6zC8 s0jm0co+sfLhocXbfNnuG6BLmFB8lFeactJOqQ5zU6XZFaeuNgUSfyD5xEeQJGJKe/RP z+fS8Ad1/8COS0JpkqJO4M4OhDpW9K/nv7wfK43PQMI+gp+/aJMv6UyqU+fjWzXNxg1A S/swYTsKkJNU2CPnwtuv30ebJU8edQyyprG1cte69/ICVWfvVJpjhEWeBpY2XZQ40DtC AkCofc1EREpHZoY6PAqImNmXUKp7baP7MjX+c6jJ/dHhwWNAVN8+0KXpEp0niH8w338Z 5E1g== MIME-Version: 1.0 Received: by 10.50.6.229 with SMTP id e5mr9483214iga.9.1339533037295; Tue, 12 Jun 2012 13:30:37 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Tue, 12 Jun 2012 13:30:37 -0700 (PDT) In-Reply-To: <4FD7A384.7080501@gmail.com> References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B5D1.3060803@viagenie.ca> <4FD0E840.1070904@venaas.com> <4FD6FF0C.4080502@jacni.com> <4FD7A384.7080501@gmail.com> Date: Tue, 12 Jun 2012 15:30:37 -0500 Message-ID: From: Behcet Sarikaya To: Tom Taylor Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Tue, 12 Jun 2012 20:30:41 -0000 On Tue, Jun 12, 2012 at 3:16 PM, Tom Taylor wrote: > Well, it is still in the Softwires domain if it tunnels the multicast data, > is it not? It is not the case in the draft currently, check Sections 4.3 & 6.2. Behcet > > > On 12/06/2012 4:11 PM, Behcet Sarikaya wrote: >> >> I think that a decision should be made on this draft. If it is going >> to present a generic solution it could be fine but then such a draft >> does not meet Softwire charter item so it can not stay in Softwire. >> >> My suggestion is to make it specific to DS-Lite so that it stays in >> Softwire and meets the charter item. >> >> I believe this was Alain's intention when he asked the two drafts to be >> merged. >> >> Regards, >> >> Behcet >> > ... From stig@venaas.com Tue Jun 12 13:46: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 17E9A11E8073 for ; Tue, 12 Jun 2012 13:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxXSuO1Sxq6S for ; Tue, 12 Jun 2012 13:46:27 -0700 (PDT) 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 590F421F86B7 for ; Tue, 12 Jun 2012 13:46:25 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id A7011803F; Tue, 12 Jun 2012 22:46:18 +0200 (CEST) Message-ID: <4FD7AA97.8010401@venaas.com> Date: Tue, 12 Jun 2012 13:46:15 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B5D1.3060803@viagenie.ca> <4FD0E840.1070904@venaas.com> <4FD6FF0C.4080502@jacni.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , Behcet Sarikaya Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 12 Jun 2012 20:46:28 -0000 On 6/12/2012 1:11 PM, Behcet Sarikaya wrote: > I think that a decision should be made on this draft. If it is going > to present a generic solution it could be fine but then such a draft > does not meet Softwire charter item so it can not stay in Softwire. > > My suggestion is to make it specific to DS-Lite so that it stays in > Softwire and meets the charter item. What do you mean by making it specific to DS-Lite? Are you talking about a different technical solution, or just wording? Right now the technical solution is generic, and I think that is great. While the wording seems DS-Lite specific to me. I don't like the idea of doing something DS-Lite specific, unless one can come up with a better technical solution that way. I think the technical solution in this draft is fine. Please let's not change it into a poor technical solution just to satisfy possible charter considerations. Stig > I believe this was Alain's intention when he asked the two drafts to be merged. > > Regards, > > Behcet > > On Tue, Jun 12, 2012 at 3:34 AM, Jacni Qin wrote: >> Hi Stig, >> >> Sorry I missed the discussion, and your comments, inline please, hope it >> won't be too late. >> >> On 6/8/2012 Friday 1:43 AM, Stig Venaas wrote: >> >> Here are my last call comments. I think substantial changes are >> needed to the draft. >> >> I understand that this draft is focusing on dslite. But it appears that >> it is a generic solution. As it says in the draft: >> >> An IPv4 receiver accesses IPv4 multicast contents over an IPv6- >> only multicast-enabled network. >> >> Based on this, I think the scope of the draft, the title and >> introduction etc should be updated to actually show that it is >> a generic approach. And then instead list dslite as one of the >> scenarios where this is needed. >> >> Since it is a generic approach, I think it should also be reviewed, >> perhaps an additional WGLC, in mboned. pim wg may also have some >> interest in reviewing it. There are some errors regarding pim in >> this document. >> >> >> In particular, it discussed translation of IGMP/MLD. This is a >> topic that has been discussed in mboned/pim, and there is also >> another draft discussing this. >> >> It refers to draft-ietf-mboned-64-multicast-address-format-01. If that >> is to stay, I think this draft needs to wait to see what happens with >> the address-format draft in 6man. Changes may be needed in this draft >> depending on what happens. If only minor changes, the examples in this >> draft may need to be updated. >> >> Thanks, it's true. We'll wait for the comments from 6man, and update it >> accordingly if needed. >> >> >> >> Technical issue: >> >> In 4.2 it says: >> The mB4 uses the G6 (and both S6 and G6 in SSM) to create the >> corresponding MLD Report message. The mB4 sends the Report message >> to the MLD Querier in the IPv6 network. The MLD Querier (typically >> acts as the PIMv6 Designated Router) receives the MLD Report message >> and sends the PIMv6 Join to join the IPv6 multicast distribution >> tree. The MLD Querier can send either PIMv6 Join (*,G6) in ASM or >> PIMv6 Join (S6,G6) in SSM to the mAFTR. >> >> As is noted, the MLD querier and the DR may be different routers. >> It is the DR and not the MLD Querier (if they are different) that >> sends the PIM join. Also note that they are often different. If >> there are two routers, then the one with the lowest address is the >> MLD querier, while the one with the highest address (unless DR >> priority is configured) is the DR. >> >> I understand your concern. I guess the Proxying spec solved this issue. >> >> >> >> Near the end of 4.2: >> >> A branch of the multicast distribution tree is then grafted, >> comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 >> part (from mAFTR downstream to the mB4). >> >> It says "is then grafted". So it sounds like the branch is added >> to the tree after the procedure has finished. But basically it is >> being added to the tree bit by bit as the joins are sent hop by >> hop. Maybe it could say "is in this way grafted" or something. >> I'm also a bit unsure whether "grafted" is a good term, as "graft" >> has a specific meaning for PIM Dense Mode. >> >> Thanks for your suggestion, we'll reword it, and make it clarified. >> >> >> >> At the end of 4.2: >> >> The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so >> as to represent the IPv4-embedded IPv6 source in the IPv6 multicast >> network. >> >> Yes, probably in the IGP. Perhaps say more explicitly that there must >> be a route due to PIM's use of RPF. I see this is mentioned in 7.1 >> though. >> >> Ok. >> >> >> >> In 6.1 it talks about IGMP messages being translated to MLD. I would >> argue that this is not necessarily how this would be done. >> >> Right, I agree with you. Please see my response to Simon, we can update the >> text to clarify that. >> >> >> If you look at a pure MLD proxy, you build state for various (*,G) >> or (S,G) based on the reports you receive. Then based on this state >> you create reports that you send upstream. It is not the message >> from downstream that is just sent upstream. In this case, when >> receiving downstream IGMP reports, they could be used to create the >> IPv6 state. And then independent of whether the state was created >> due to IGMP or MLD reports, reports are sent upstream, created from >> that state. If you do this, messages are not translated. >> >> >> In 7.1 it says: >> >> information to discover the source. In order to pass the Reverse >> Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on the >> interfaces which has the shortest path to the uPrefix64. >> >> Note that the shortest path might change due to topology changes, links >> going down or coming up etc. So one would typically enable PIM on all >> the routers. If one wants to constrain multicast to only some of the >> topology, there are ways to build a separate multicast RIB for those >> routers, and then enable PIM on all of them. >> >> The text just focuses on the special configuration, I understand your >> concern that it's a little confusing. >> Maybe we can add some text like "... as prerequisites, basic multicast >> related configurations should be done accordingly ..." >> >> >> >> In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB >> is something different. I think it should say TIB. Check the terms >> MRIB and TIB in RFC 4601. >> >> I'll check the terms again. >> >> >> The draft assumes PIM-SM is used. I think the approach could also >> be used with e.g. PIM Bidir (RFC 5015). >> >> Ok, we'll discuss this and come back to you on this point. >> >> >> >> 7.5 talks about scope, and mentions E and 8. Then it says that >> this specification does not specify which scope to use. I would >> perhaps not mention E and 8 then, it seems now to indicate that >> those are the only alternatives. >> >> Fine. >> >> >> >> >> The security considerations should probably be extended a bit. >> E.g. what about scoping? Can one traverse a scoped boundary by >> say joining a v4 scoped group using a join for a global v6 >> prefix? >> >> Ok, we'll consider that. >> >> >> >> The draft should point out that it is just plain IPv4 in IPv6. At >> least that seems to be the intention. However, one might use the >> same solution with other tunnel types, e.g. GRE. >> >> We have a similar intention as the DS-Lite spec., we can some text. >> >> >> Minor nits: >> >> Thanks, done. >> >> >> o PIMv4: refers to PIM when deployed in an IPv4 infrastructure >> (i.e., IPv4 transfer capabilities are used to exchange PIM >> messages). >> >> o PIMv6: refers to PIM when deployed in an IPv6 infrastructure >> (i.e., IPv6 transfer capabilities are used to exchange PIM >> messages). >> >> Replace transfer with transport? >> >> Section 6.4 starts with this: >> >> If the mB4 function is implemented in the host which is directly >> connected to an IPv6-only network. If an IPv4 application running in >> >> I'm not exactly sure what the first "if" refers to. This needs to be >> reformulated. >> >> Also in 6.4 there is this typo: "implemntation". >> >> Stig >> >> >> Thanks again for your careful review and comments. >> >> >> Cheers, >> Jacni >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> From yiu_lee@cable.comcast.com Tue Jun 12 13: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 4677711E8073 for ; Tue, 12 Jun 2012 13:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtajoMAwb+uv for ; Tue, 12 Jun 2012 13:51:28 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBF221F86B1 for ; Tue, 12 Jun 2012 13:51:28 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.20970738; Tue, 12 Jun 2012 14:34:58 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 16:51:23 -0400 From: "Lee, Yiu" To: liu dapeng Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: AQHNSN0gFHJFO2o5GU2LzTg9ZchidQ== Date: Tue, 12 Jun 2012 20:51:23 +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.2.120421 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422364682_1368046" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 12 Jun 2012 20:51:29 -0000 --B_3422364682_1368046 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we "intentionally hide the truth". Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, "liu dapeng" wrote: >2012/6/12, Lee, Yiu : >> Hi Dapeng., >> >> This is not a specification draft. This is a draft to discuss the >> motivations. IMHO, people who are working in this area would be able to >> understand this draft. > >=3D> I guess the audience is not only designer of protocol, but also >operators >who want to evaluate and adopt such technology. Intentional hiding the >truth >for me is really bad. > > > >The focus of it is about the carrier network, CPE >> is never the focal point. I think the current statement "States may >>still >> exist in other equipments such as customer premises equipment." is >>enough. > >=3D>Please see my reply in previous mail. "may" is not sufficient. > >> Adding more text only causes confusion. > >=3D>What I do is objectively to elaborate what we are. Why would that cause >confusion? > >Regards, >Dapeng > > >> Thanks, >> Yiu >> >> On 6/12/12 6:21 AM, "liu dapeng" wrote: >> >>>2012/6/12, Ole Tr=F8an : >>>>> Ok, then we can make this more clear in our document. >>>>> >>>>> "States still should be maintained in other equipments, e.g. customer >>>>> premises equipment or host, in order to restrict IP address or port >>>>> number >>>>> information into the configured context except that a non-shared IPv4 >>>>> address is >>>>> assigned to a standalone host." >>>> >>>> I think this is just adding confusion. >>>> the NAT44 on the CPE already does this. >>> >>>=3D>First off, we are not only talking about NAT44 here, but port >>>translation and non-shared address. Secondly, NAT44 on the CPE is not >>>doing what today NAT44 does. For example, override ID in ICMP with >>>port information. >>> >>>that reminds me to update the proposed text a bit, >>> >>>"States still should be maintained in other equipments, e.g. customer >>>premises equipment or host, in order to restrict L3 or L4 information >>>into the configured context except that a non-shared IPv4 address is >>>assigned to a standalone host." >>> >>>> I suggest we instead talk about no _additional_ state in the network. >>>>there >>>> is no need to mention the CPE, apart from stating that no additional >>>>state >>>> is required. >>> >>>=3D>I believe the above is clear for reader and designer. I don't see why >>>we resist on clarifying and helping reader better understanding. >>> >>>Regards, >>>Dapeng Liu >>> >>> >>>> cheers, >>>> Ole >>>> >>>> >>>> >>> >>> >>>-- >>> >>>------ >>>Best Regards, >>>Dapeng Liu >>>_______________________________________________ >>>Softwires mailing list >>>Softwires@ietf.org >>>https://www.ietf.org/mailman/listinfo/softwires >> > > >--=20 > >------ >Best Regards, >Dapeng Liu --B_3422364682_1368046 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQchuKQ QXZ5O0lfLq1B5bfrW3Fn3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MTIyMDUxMjBaMA0GCSqGSIb3DQEBAQUABIIBALG/e2ffuk2+Rgxghqx9gkyy tUi7/SaqB4cKHqpizbtyDKZGZze/vls+jOkL6Cbvfppcr9aNJQ4LNBheTbGlQaJ533dhUm4l c71IgD6dpOxwRyaDM/jt0W45dESmeWx1IjJFFXolCWGy8Hv6XaMVne+6AS9YKh/PR5ZCjh9v I7BUm6BI1UeW1S4r4A8lmizawCqCG+TFOtApbBhomm5fTbq1nfhG31nMyu5rSyI0AQegyXJ0 lHQewLcDm1E325s3ITRrkvgmvYvlM05zwywdmebacfo7cUA8lsCXsftFiHDd0hn51Ytuh/82 v0oVSj9Ms4whrRjPBy4nBFJ4ccpUD/0= --B_3422364682_1368046-- From yiu_lee@cable.comcast.com Tue Jun 12 13:56:14 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 9968911E80CD for ; Tue, 12 Jun 2012 13:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 482CEtRh4WhD for ; Tue, 12 Jun 2012 13:56:14 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id D1DCE11E80C5 for ; Tue, 12 Jun 2012 13:56:13 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.15729484; Tue, 12 Jun 2012 16:46:54 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 16:56:07 -0400 From: "Lee, Yiu" To: "sarikaya@ieee.org" , Tom Taylor Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: AQHNSN3JSap6YxVtK0K05lFEo0Opyw== Date: Tue, 12 Jun 2012 20:56:07 +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.2.120421 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422364967_1413297" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 12 Jun 2012 20:56:14 -0000 --B_3422364967_1413297 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Behect, You confuse me. 4.3 said this: "When the mAFTR receives an IPv4 multicast packet, it will encapsulate the packet into an IPv6 multicast packet using the IPv4-embedded IPv6 multicast address as the destination address and an IPv4-embedded IPv6 unicast address as the source address." The data packets are tunneled over IPv6 hub by hub. That said, the tunnel isn't end-to-end. Thanks, Yiu On 6/12/12 4:30 PM, "Behcet Sarikaya" wrote: >It is not the case in the draft currently, check Sections 4.3 & 6.2. > >Behcet --B_3422364967_1413297 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRbVZoF WsLTOlsOtueGCfBMQOmRNzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MTIyMDU2MDVaMA0GCSqGSIb3DQEBAQUABIIBAGoPGr7AL6+5F9KJ3cGdBa4D QJpJMhWLld342Y5Fo0Rfyza47bndvaGlDe/9V6+WKrFTxI7skBDmY/nXfFUFA+cYz79astYZ B3VXC4XvjpCaahM439GJDcaFuHuvZy2a3k9jn0Cmjp6qv+gLYff8ikQ/pkVwnTeteDmYOGUB BfTzLKgipHS6nwHNyGheCx8bPLKcCfTDKzevs+TXrt9wozTQ3EsIVuz+6p9dNvteky2rXMzx 83FAX1z1zeI3pw/gnck9W3VBJ7eDsPJYHpyAc/cZ9RWXYRsewVUPF2EWQlYdZpDPgkxc9TOK RetYPX/Zj41F+i6hSLVbf3BsCNlYflI= --B_3422364967_1413297-- From yiu_lee@cable.comcast.com Tue Jun 12 14:49:38 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 8D17F11E8073 for ; Tue, 12 Jun 2012 14:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TABmOiiTJUFo for ; Tue, 12 Jun 2012 14:49:37 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4B59E21F847D for ; Tue, 12 Jun 2012 14:49:37 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.15737373; Tue, 12 Jun 2012 17:40:14 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Tue, 12 Jun 2012 17:49:27 -0400 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: AQHNSOU9gfYt116V3EOI2WSxUJ10fQ== Date: Tue, 12 Jun 2012 21:49:27 +0000 Message-ID: In-Reply-To: <4FD7AA97.8010401@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422368167_40812" MIME-Version: 1.0 Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 12 Jun 2012 21:49:38 -0000 --B_3422368167_40812 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 On 6/12/12 4:46 PM, "Stig Venaas" wrote: >On 6/12/2012 1:11 PM, Behcet Sarikaya wrote: >> I think that a decision should be made on this draft. If it is going >> to present a generic solution it could be fine but then such a draft >> does not meet Softwire charter item so it can not stay in Softwire. >> >> My suggestion is to make it specific to DS-Lite so that it stays in >> Softwire and meets the charter item. > >What do you mean by making it specific to DS-Lite? Are you talking >about a different technical solution, or just wording? Right now the >technical solution is generic, and I think that is great. While the >wording seems DS-Lite specific to me. > >I don't like the idea of doing something DS-Lite specific, unless one >can come up with a better technical solution that way. > >I think the technical solution in this draft is fine. Please let's not >change it into a poor technical solution just to satisfy possible >charter considerations. > >Stig > >> I believe this was Alain's intention when he asked the two drafts to be >>merged. >> >> Regards, >> >> Behcet >> >> On Tue, Jun 12, 2012 at 3:34 AM, Jacni Qin wrote: >>> Hi Stig, >>> >>> Sorry I missed the discussion, and your comments, inline please, hope >>>it >>> won't be too late. >>> >>> On 6/8/2012 Friday 1:43 AM, Stig Venaas wrote: >>> >>> Here are my last call comments. I think substantial changes are >>> needed to the draft. >>> >>> I understand that this draft is focusing on dslite. But it appears that >>> it is a generic solution. As it says in the draft: >>> >>> An IPv4 receiver accesses IPv4 multicast contents over an IPv6- >>> only multicast-enabled network. >>> >>> Based on this, I think the scope of the draft, the title and >>> introduction etc should be updated to actually show that it is >>> a generic approach. And then instead list dslite as one of the >>> scenarios where this is needed. >>> >>> Since it is a generic approach, I think it should also be reviewed, >>> perhaps an additional WGLC, in mboned. pim wg may also have some >>> interest in reviewing it. There are some errors regarding pim in >>> this document. >>> >>> >>> In particular, it discussed translation of IGMP/MLD. This is a >>> topic that has been discussed in mboned/pim, and there is also >>> another draft discussing this. >>> >>> It refers to draft-ietf-mboned-64-multicast-address-format-01. If that >>> is to stay, I think this draft needs to wait to see what happens with >>> the address-format draft in 6man. Changes may be needed in this draft >>> depending on what happens. If only minor changes, the examples in this >>> draft may need to be updated. >>> >>> Thanks, it's true. We'll wait for the comments from 6man, and update it >>> accordingly if needed. >>> >>> >>> >>> Technical issue: >>> >>> In 4.2 it says: >>> The mB4 uses the G6 (and both S6 and G6 in SSM) to create the >>> corresponding MLD Report message. The mB4 sends the Report message >>> to the MLD Querier in the IPv6 network. The MLD Querier (typically >>> acts as the PIMv6 Designated Router) receives the MLD Report >>>message >>> and sends the PIMv6 Join to join the IPv6 multicast distribution >>> tree. The MLD Querier can send either PIMv6 Join (*,G6) in ASM or >>> PIMv6 Join (S6,G6) in SSM to the mAFTR. >>> >>> As is noted, the MLD querier and the DR may be different routers. >>> It is the DR and not the MLD Querier (if they are different) that >>> sends the PIM join. Also note that they are often different. If >>> there are two routers, then the one with the lowest address is the >>> MLD querier, while the one with the highest address (unless DR >>> priority is configured) is the DR. >>> >>> I understand your concern. I guess the Proxying spec solved this issue. >>> >>> >>> >>> Near the end of 4.2: >>> >>> A branch of the multicast distribution tree is then grafted, >>> comprising both an IPv4 part (from the mAFTR upstream) and an IPv6 >>> part (from mAFTR downstream to the mB4). >>> >>> It says "is then grafted". So it sounds like the branch is added >>> to the tree after the procedure has finished. But basically it is >>> being added to the tree bit by bit as the joins are sent hop by >>> hop. Maybe it could say "is in this way grafted" or something. >>> I'm also a bit unsure whether "grafted" is a good term, as "graft" >>> has a specific meaning for PIM Dense Mode. >>> >>> Thanks for your suggestion, we'll reword it, and make it clarified. >>> >>> >>> >>> At the end of 4.2: >>> >>> The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so >>> as to represent the IPv4-embedded IPv6 source in the IPv6 multicast >>> network. >>> >>> Yes, probably in the IGP. Perhaps say more explicitly that there must >>> be a route due to PIM's use of RPF. I see this is mentioned in 7.1 >>> though. >>> >>> Ok. >>> >>> >>> >>> In 6.1 it talks about IGMP messages being translated to MLD. I would >>> argue that this is not necessarily how this would be done. >>> >>> Right, I agree with you. Please see my response to Simon, we can >>>update the >>> text to clarify that. >>> >>> >>> If you look at a pure MLD proxy, you build state for various (*,G) >>> or (S,G) based on the reports you receive. Then based on this state >>> you create reports that you send upstream. It is not the message >>> from downstream that is just sent upstream. In this case, when >>> receiving downstream IGMP reports, they could be used to create the >>> IPv6 state. And then independent of whether the state was created >>> due to IGMP or MLD reports, reports are sent upstream, created from >>> that state. If you do this, messages are not translated. >>> >>> >>> In 7.1 it says: >>> >>> information to discover the source. In order to pass the Reverse >>> Path Forwarding (RPF) check, the IPv6 routers MUST enable PIM on >>>the >>> interfaces which has the shortest path to the uPrefix64. >>> >>> Note that the shortest path might change due to topology changes, links >>> going down or coming up etc. So one would typically enable PIM on all >>> the routers. If one wants to constrain multicast to only some of the >>> topology, there are ways to build a separate multicast RIB for those >>> routers, and then enable PIM on all of them. >>> >>> The text just focuses on the special configuration, I understand your >>> concern that it's a little confusing. >>> Maybe we can add some text like "... as prerequisites, basic multicast >>> related configurations should be done accordingly ..." >>> >>> >>> >>> In 7.2 it says something about (*,G6) in mRIB6. The multicast RIB >>> is something different. I think it should say TIB. Check the terms >>> MRIB and TIB in RFC 4601. >>> >>> I'll check the terms again. >>> >>> >>> The draft assumes PIM-SM is used. I think the approach could also >>> be used with e.g. PIM Bidir (RFC 5015). >>> >>> Ok, we'll discuss this and come back to you on this point. >>> >>> >>> >>> 7.5 talks about scope, and mentions E and 8. Then it says that >>> this specification does not specify which scope to use. I would >>> perhaps not mention E and 8 then, it seems now to indicate that >>> those are the only alternatives. >>> >>> Fine. >>> >>> >>> >>> >>> The security considerations should probably be extended a bit. >>> E.g. what about scoping? Can one traverse a scoped boundary by >>> say joining a v4 scoped group using a join for a global v6 >>> prefix? >>> >>> Ok, we'll consider that. >>> >>> >>> >>> The draft should point out that it is just plain IPv4 in IPv6. At >>> least that seems to be the intention. However, one might use the >>> same solution with other tunnel types, e.g. GRE. >>> >>> We have a similar intention as the DS-Lite spec., we can some text. >>> >>> >>> Minor nits: >>> >>> Thanks, done. >>> >>> >>> o PIMv4: refers to PIM when deployed in an IPv4 infrastructure >>> (i.e., IPv4 transfer capabilities are used to exchange PIM >>> messages). >>> >>> o PIMv6: refers to PIM when deployed in an IPv6 infrastructure >>> (i.e., IPv6 transfer capabilities are used to exchange PIM >>> messages). >>> >>> Replace transfer with transport? >>> >>> Section 6.4 starts with this: >>> >>> If the mB4 function is implemented in the host which is directly >>> connected to an IPv6-only network. If an IPv4 application running >>>in >>> >>> I'm not exactly sure what the first "if" refers to. This needs to be >>> reformulated. >>> >>> Also in 6.4 there is this typo: "implemntation". >>> >>> Stig >>> >>> >>> Thanks again for your careful review and comments. >>> >>> >>> Cheers, >>> Jacni >>> >>> >>> >>> _______________________________________________ >>> 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 >>> > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3422368167_40812 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTZMTEx O1MEP7Z+B7qN2m7dKP+LkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MTIyMTQ5MjRaMA0GCSqGSIb3DQEBAQUABIIBAMWPZUsj4NHvjeP8NIt8Zg12 TXkzDIk8IPrW94KTfo6+90K1VRcXVzevtiVv3tWhUfK6ngB8zwPNa5BPmasYrC3gx3/gOdlj JJhDyRN+Kv+T8JinfnfgF4hzvo//rtB5kcmJJsAD0/IatigKHeB5ugupwrn2dm6Yl6UNCNQ1 CnYdZNJLITNWRqzS9btkjniqwVhsNwE+iW5wI79Al2La+WPRT0Ntx496nXFbxpN1WcFS8YR/ TtqdmXLJew9WNYuNMkJ/FKWLMjKBuIlaedcL6zZdcZy9i3GxpSi4XiVJKXfBjNXHCcJfglyV MGCcgNVJvMn4qVBk/9hOxzXgDADFjRQ= --B_3422368167_40812-- From sarikaya2012@gmail.com Tue Jun 12 15:22: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 3A88421F85CC for ; Tue, 12 Jun 2012 15:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZ+D1ntlCRpw for ; Tue, 12 Jun 2012 15:22:50 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54B6721F8592 for ; Tue, 12 Jun 2012 15:22:50 -0700 (PDT) Received: by yhq56 with SMTP id 56so54741yhq.31 for ; Tue, 12 Jun 2012 15:22:50 -0700 (PDT) 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:content-transfer-encoding; bh=6UM+rjQZ1xnv5iY1noLAx/dQpXLKGlgJ42UFy60HVhs=; b=igafmR73gBDACAYjU4IuxwoVT+ni4ILM18pfmQn8Tq/LkthCJHmxxHgniOSN6OtdHr oxqImdoIhrS6zdmojlY0LBmQYzUptEUT7V4VuF1RW2YNthggJY57+vkefVfui7Zcmvrq 1AKPHr+8HJ67x2MZ4pbne2QmVwD/RrKKmQ2ryn1AVh1DaJSNTCMiMOVnc0zcsx6ILX1D 4o1W3fmZsYDCIcifSL4LgHnmjbMUM9zYarHuBKSYcXn1IRnl5zSum5IEWi6dLc7QnrYR 6FCGShAgXSAUR82aKiwdvgxiQHxcfFeCpPtn99otnQV664lz9q8+qTX8mBgoICY4tyzR /dFg== MIME-Version: 1.0 Received: by 10.50.159.135 with SMTP id xc7mr9547723igb.9.1339539769709; Tue, 12 Jun 2012 15:22:49 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Tue, 12 Jun 2012 15:22:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jun 2012 17:22:49 -0500 Message-ID: From: Behcet Sarikaya To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Tue, 12 Jun 2012 22:22:51 -0000 Hi Yiu, The solution in this draft is generic, it simply leaves DS-Lite aside and builds its own stuff. I think this fact has been alluded to by the co-authors. This should change. Saying that a solution that integrates with DS-Lite is technically poor solution is saying that DS-Lite is technically poor solution. Behcet On Tue, Jun 12, 2012 at 3:56 PM, Lee, Yiu wrote= : > Hi Behect, > > You confuse me. 4.3 said this: > > "When the mAFTR receives an IPv4 multicast packet, it will encapsulate > =A0 the packet into an IPv6 multicast packet using the IPv4-embedded IPv6 > =A0 multicast address as the destination address and an IPv4-embedded > =A0 IPv6 unicast address as the source address." > > The data packets are tunneled over IPv6 hub by hub. That said, the tunnel > isn't end-to-end. > > Thanks, > Yiu > > > On 6/12/12 4:30 PM, "Behcet Sarikaya" wrote: > >>It is not the case in the draft currently, check Sections 4.3 & 6.2. >> >>Behcet From maxpassion@gmail.com Tue Jun 12 20:39: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 947EC11E8098 for ; Tue, 12 Jun 2012 20:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRA2MX70j9Rk for ; Tue, 12 Jun 2012 20:39:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9BF211E808D for ; Tue, 12 Jun 2012 20:39:57 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so255084obb.31 for ; Tue, 12 Jun 2012 20:39:57 -0700 (PDT) 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:content-transfer-encoding; bh=Z5Kgiy6LaykfWxyROLdYJaMqauX1EPtCojKwy9TGHpY=; b=n5HL56u+9lb9kwKBpcp9cVvWOcN5/QB0B5UYqHs16Ls+ehhkbRNGQERnnZ0IprJJhe c3qrtko/igNq8xkMHNKD6kRxyBkT+p13WKt13SQDciXG+9DVWTjmeqokJ2jQGMKwz7fU 06gpNohPtnh0I9XggRQq2wrYxO+bvDbWA6fEwS09urlmIJ2XPMZK3mJ1bRbbV+FksYIS XlowG5rrY8Cuz2o2dCdIKGZ6ZLN+H5LurxQV5OWcpqhjuzqu0diCYa9ACXTv7rK5sBMj oZtFg2rr6OUi/ZqscsICmHg/50CuX6JC/cj/WHO4aqvvyTswVtU4pChYtCsuhJ+ypRrf hjog== MIME-Version: 1.0 Received: by 10.60.27.6 with SMTP id p6mr22795628oeg.37.1339558797336; Tue, 12 Jun 2012 20:39:57 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Tue, 12 Jun 2012 20:39:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Jun 2012 11:39:57 +0800 Message-ID: From: liu dapeng To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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: Wed, 13 Jun 2012 03:39:58 -0000 As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiu : > Hi Dapeng, > > This draft was written by operators, we do not have any problem > understanding it. Besides, I disagree we "intentionally hide the truth". > Please explain to the WG what truth we are trying to hide in this draft? = I > am not convinced we need to say anymore than what we have stated in the > new version. > > > Thanks, > Yiu > > > On 6/12/12 11:45 AM, "liu dapeng" wrote: > >>2012/6/12, Lee, Yiu : >>> Hi Dapeng., >>> >>> This is not a specification draft. This is a draft to discuss the >>> motivations. IMHO, people who are working in this area would be able to >>> understand this draft. >> >>=3D> I guess the audience is not only designer of protocol, but also >>operators >>who want to evaluate and adopt such technology. Intentional hiding the >>truth >>for me is really bad. >> >> >> >>The focus of it is about the carrier network, CPE >>> is never the focal point. I think the current statement "States may >>>still >>> exist in other equipments such as customer premises equipment." is >>>enough. >> >>=3D>Please see my reply in previous mail. "may" is not sufficient. >> >>> Adding more text only causes confusion. >> >>=3D>What I do is objectively to elaborate what we are. Why would that cau= se >>confusion? >> >>Regards, >>Dapeng >> >> >>> Thanks, >>> Yiu >>> >>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>> >>>>2012/6/12, Ole Tr=F8an : >>>>>> Ok, then we can make this more clear in our document. >>>>>> >>>>>> "States still should be maintained in other equipments, e.g. custome= r >>>>>> premises equipment or host, in order to restrict IP address or port >>>>>> number >>>>>> information into the configured context except that a non-shared IPv= 4 >>>>>> address is >>>>>> assigned to a standalone host." >>>>> >>>>> I think this is just adding confusion. >>>>> the NAT44 on the CPE already does this. >>>> >>>>=3D>First off, we are not only talking about NAT44 here, but port >>>>translation and non-shared address. Secondly, NAT44 on the CPE is not >>>>doing what today NAT44 does. For example, override ID in ICMP with >>>>port information. >>>> >>>>that reminds me to update the proposed text a bit, >>>> >>>>"States still should be maintained in other equipments, e.g. customer >>>>premises equipment or host, in order to restrict L3 or L4 information >>>>into the configured context except that a non-shared IPv4 address is >>>>assigned to a standalone host." >>>> >>>>> I suggest we instead talk about no _additional_ state in the network. >>>>>there >>>>> is no need to mention the CPE, apart from stating that no additional >>>>>state >>>>> is required. >>>> >>>>=3D>I believe the above is clear for reader and designer. I don't see w= hy >>>>we resist on clarifying and helping reader better understanding. >>>> >>>>Regards, >>>>Dapeng Liu >>>> >>>> >>>>> cheers, >>>>> Ole >>>>> >>>>> >>>>> >>>> >>>> >>>>-- >>>> >>>>------ >>>>Best Regards, >>>>Dapeng Liu >>>>_______________________________________________ >>>>Softwires mailing list >>>>Softwires@ietf.org >>>>https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >>-- >> >>------ >>Best Regards, >>Dapeng Liu > --=20 ------ Best Regards, Dapeng Liu From pengwu.thu@gmail.com Tue Jun 12 21:36:55 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 865A021F8628 for ; Tue, 12 Jun 2012 21:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKD+g2jAY1xx for ; Tue, 12 Jun 2012 21:36:54 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 709DB21F8638 for ; Tue, 12 Jun 2012 21:36:54 -0700 (PDT) Received: by qcsq13 with SMTP id q13so100897qcs.31 for ; Tue, 12 Jun 2012 21:36:53 -0700 (PDT) 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=5aF0Mjbo6SD9CrwcsfaaoKq3mhRESXCuBPTOlqwp7Fk=; b=aZL57yOuPs1Gx6sHS9HCZCrx2OBxu0Tvrh0BLRRZgy0GZZ8nY/gf9C7fbsiagQXi+s Um7PAqQhL5/c5GspXMkWDdlsUr+37qdCq6PloFvuFC2J0dslbJ0AEO9Bf2X90nP70Lso sZx0fbTusxRj5KVQgv/OUhoTPmCd6B4CrNTWX8ALzekOj6H6WI/KNm4PsuuEJNX+iqra wO8fxXSHtORkUKKyaAJy4OO/KyThJJ/3W4DIJBps2Fk376R/YDO3H5xm1VWHnWypW+nf B1552vuFOkiPFcX803nSOsWvEcKBtX5L6VKmHzPukzuUSErh9dBNoEsKXFNQbDNRlDdq IJFw== MIME-Version: 1.0 Received: by 10.229.136.17 with SMTP id p17mr9860608qct.26.1339562213871; Tue, 12 Jun 2012 21:36:53 -0700 (PDT) Received: by 10.229.30.203 with HTTP; Tue, 12 Jun 2012 21:36:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Jun 2012 12:36:53 +0800 Message-ID: From: Peng Wu To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 13 Jun 2012 04:36:55 -0000 Woj, On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec wrote: > Peng, > > On 11 June 2012 20:38, Peng Wu wrote: >> >> Woj, >> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec wrote: >> > There is basic question regarding this draft, one that has also been >> > raised >> > at previous WG meetings: "why is it needed?". >> It's actually written in section 4 of the draft. >> >> > There is a deeper issue here: This draft seems to give the impression >> > that >> > running such a regular public addressed DHCPv4 based overlay on IPv6 is >> > a >> > simple idea, as opposed to native dual stack. It is anything but, given >> > that >> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar >> to scenario of DS-Lite and MAP/4rd. >> I thought the assumption of IPv4-over-IPv6 is that you cannot/do not >> want to provision native dual-stack? > > > To put it simply: This draft describes a scenario where public v4 addresses > are available. The "classic" v6 migration scenario is in this case "dual > stack" and is what I believe has been advised for years by the IETF, and > continues to be the recommended approach. Why would one want to run in this > case dual-stack over a tunnel infra is the question? Is this intended as an > academic draft (as in "we can do it, but don't know why")? [Peng] That's not always the case. Now to be more precise, with pb 4over6 1.Concentrator can be in a high position, and we don't have to IPv4 every where 2.Provision IPv4 in a flexible, on-demand way 3.It can be deployed along with DS-lite to provide a value-added service These points are already written in the draft >> >> > a) it it requires changes to DHCPv4 processing b) it introduces non >> > trivial >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires >> > changes to >> > CPE d) makes life really a mess if we consider a real dual stack CPE. >> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >> essential changes to protocol processing. > > > Woj> That's not what the draft DHCPv4overv6 indicates, unless one assumes a > very specific and limiting deployment scenario. In any case it's quite clear > that it is not possible to use regular DHCPv4 clients for this, or a regular > DHCPv4 server (there is no mention of how the broadcast flags should be > handled, mapped to IPv6, etc). [Peng]Actually we can use regular DHCPv4 client, with the help of a CRA function planted on the same host, that's a very fundamental point of the DHCPv4over6v6 draft. Server side need modification, yes. But only on the step of sending/receiving DHCP messages (sockets). That's what I wanted to express in last mail. FYI, it only uses IPv6 unicast, with the aid of CRA. >> >> b) What really matters here is provisioning the IPv4 address through >> DHCPv4. Just like in MAP/4rd, you provision the address through >> DHCPv6. >> In pb4over6 DHCPv6 is only an *option* to provide the concentrator >> address. You have similar logic too in MAP. >> So I don't think it's "non trivial dependancy". They are similar >> functions for all IPv4-over-IPv6 mechanisms that need provisioning, >> only different technical paths. > > > There are several components/parts that all need to play together in this > solution, many more than apparently required, and the failure of one is not > obvious to anyone looking at another. As in any such multi-part system > design, the overall complexity is higher. Sorry but I simply don't buy that it's *significant* more complexity. As to failure, it's more like a sequencial rather than " the failure of one is not obvious to anyone looking at another". If I cannot get the concentrator or the DHCPv4 server address, I stop the rest steps. >> >> c) Any IPv4-over-IPv6 mechanism requires change to CPE > > > Yes, but in the case of this draft, the changes that are proposed do not > lead to anything over and above what plain dual stack accomplishes, except > extra complexity. See above Cheers~ From mohamed.boucadair@orange.com Tue Jun 12 22:57: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 3A7D321F8711 for ; Tue, 12 Jun 2012 22:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZ5AbayyrlEv for ; Tue, 12 Jun 2012 22:57:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF5421F8679 for ; Tue, 12 Jun 2012 22:57:47 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 0454332444E; Wed, 13 Jun 2012 07:57:46 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id DCDBA35C048; Wed, 13 Jun 2012 07:57:45 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Wed, 13 Jun 2012 07:57:45 +0200 From: To: liu dapeng , "Lee, Yiu" Date: Wed, 13 Jun 2012 07:57:43 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: Ac1JFjdL9eUV2z9zSR6QmTk/Au2GNgAEqoow Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.5.24.112414 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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: Wed, 13 Jun 2012 05:57:57 -0000 Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side * focus is on carrier-side stateless solutions As an editor of the document, I believe the new version solves your concern= s.=20 Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de liu dapeng >Envoy=E9 : mercredi 13 juin 2012 05:40 >=C0 : Lee, Yiu >Cc : softwires@ietf.org >Objet : Re: [Softwires] I-D Action:=20 >draft-ietf-softwire-stateless-4v6-motivation-02.txt > >As a reader of the document, not co-author any related document, I >believe people who is not involved the whole process (e.g. edit the >documents, design the solutions,etc) couldn't understand the story >behind that. I personally have sincerely heard some people presenting >and evaluating this technology incorrectly somewhere before because of >ambiguous understanding on the term. > >My purpose is that IETF has the responsibility to clarify what we are >documenting clearly to prevent from misleading. > >I'm thankful to your discussion that made all things clear than before. > >And I don't understand why we don't document something we already >agreed on, but let the misleading to continue. > >Regards, >Dapeng Liu > >2012/6/13, Lee, Yiu : >> Hi Dapeng, >> >> This draft was written by operators, we do not have any problem >> understanding it. Besides, I disagree we "intentionally hide=20 >the truth". >> Please explain to the WG what truth we are trying to hide in=20 >this draft? I >> am not convinced we need to say anymore than what we have=20 >stated in the >> new version. >> >> >> Thanks, >> Yiu >> >> >> On 6/12/12 11:45 AM, "liu dapeng" wrote: >> >>>2012/6/12, Lee, Yiu : >>>> Hi Dapeng., >>>> >>>> This is not a specification draft. This is a draft to discuss the >>>> motivations. IMHO, people who are working in this area=20 >would be able to >>>> understand this draft. >>> >>>=3D> I guess the audience is not only designer of protocol, but also >>>operators >>>who want to evaluate and adopt such technology. Intentional=20 >hiding the >>>truth >>>for me is really bad. >>> >>> >>> >>>The focus of it is about the carrier network, CPE >>>> is never the focal point. I think the current statement "States may >>>>still >>>> exist in other equipments such as customer premises equipment." is >>>>enough. >>> >>>=3D>Please see my reply in previous mail. "may" is not sufficient. >>> >>>> Adding more text only causes confusion. >>> >>>=3D>What I do is objectively to elaborate what we are. Why=20 >would that cause >>>confusion? >>> >>>Regards, >>>Dapeng >>> >>> >>>> Thanks, >>>> Yiu >>>> >>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>> >>>>>2012/6/12, Ole Tr=F8an : >>>>>>> Ok, then we can make this more clear in our document. >>>>>>> >>>>>>> "States still should be maintained in other equipments,=20 >e.g. customer >>>>>>> premises equipment or host, in order to restrict IP=20 >address or port >>>>>>> number >>>>>>> information into the configured context except that a=20 >non-shared IPv4 >>>>>>> address is >>>>>>> assigned to a standalone host." >>>>>> >>>>>> I think this is just adding confusion. >>>>>> the NAT44 on the CPE already does this. >>>>> >>>>>=3D>First off, we are not only talking about NAT44 here, but port >>>>>translation and non-shared address. Secondly, NAT44 on the=20 >CPE is not >>>>>doing what today NAT44 does. For example, override ID in ICMP with >>>>>port information. >>>>> >>>>>that reminds me to update the proposed text a bit, >>>>> >>>>>"States still should be maintained in other equipments,=20 >e.g. customer >>>>>premises equipment or host, in order to restrict L3 or L4=20 >information >>>>>into the configured context except that a non-shared IPv4=20 >address is >>>>>assigned to a standalone host." >>>>> >>>>>> I suggest we instead talk about no _additional_ state in=20 >the network. >>>>>>there >>>>>> is no need to mention the CPE, apart from stating that=20 >no additional >>>>>>state >>>>>> is required. >>>>> >>>>>=3D>I believe the above is clear for reader and designer. I=20 >don't see why >>>>>we resist on clarifying and helping reader better understanding. >>>>> >>>>>Regards, >>>>>Dapeng Liu >>>>> >>>>> >>>>>> cheers, >>>>>> Ole >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>>-- >>>>> >>>>>------ >>>>>Best Regards, >>>>>Dapeng Liu >>>>>_______________________________________________ >>>>>Softwires mailing list >>>>>Softwires@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >>> >>>-- >>> >>>------ >>>Best Regards, >>>Dapeng Liu >> > > >--=20 > >------ >Best Regards, >Dapeng Liu >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From mohamed.boucadair@orange.com Tue Jun 12 23:04: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 B4EC921F874C for ; Tue, 12 Jun 2012 23:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf5gmQJfjElo for ; Tue, 12 Jun 2012 23:04:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EFF7E21F8731 for ; Tue, 12 Jun 2012 23:04:11 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 10B832DC35B; Wed, 13 Jun 2012 08:04:11 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E5DB523804B; Wed, 13 Jun 2012 08:04:10 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Wed, 13 Jun 2012 08:04:10 +0200 From: To: "sarikaya@ieee.org" , Tom Taylor Date: Wed, 13 Jun 2012 08:04:09 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1I2j5di7MnhWrCQNiM/5bUBj03cAAT6t5g Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FF060@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1E8F@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B0E9.4020206@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EED@PUEXCB1B.nanterre.francetelecom.fr> <4FD0B5D1.3060803@viagenie.ca> <4FD0E840.1070904@venaas.com> <4FD6FF0C.4080502@jacni.com> <4FD7A384.7080501@gmail.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: 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.6.13.44528 Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 13 Jun 2012 06:04:12 -0000 Behcet, What is wrong with those sections?=20 Can you provide the excerpt you are referring to? Thanks. The section you are pointing to describes exclusively encapsulation/decapsu= lation. Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Behcet Sarikaya >Envoy=E9 : mardi 12 juin 2012 22:31 >=C0 : Tom Taylor >Cc : softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-dslite-multicast-02 > >On Tue, Jun 12, 2012 at 3:16 PM, Tom Taylor=20 > wrote: >> Well, it is still in the Softwires domain if it tunnels the=20 >multicast data, >> is it not? > >It is not the case in the draft currently, check Sections 4.3 & 6.2. > >Behcet > >> >> >> On 12/06/2012 4:11 PM, Behcet Sarikaya wrote: >>> >>> I think that a decision should be made on this draft. If it is going >>> to present a generic solution it could be fine but then such a draft >>> does not meet Softwire charter item so it can not stay in Softwire. >>> >>> My suggestion is to make it specific to DS-Lite so that it stays in >>> Softwire and meets the charter item. >>> >>> I believe this was Alain's intention when he asked the two=20 >drafts to be >>> merged. >>> >>> Regards, >>> >>> Behcet >>> >> ... >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From mohamed.boucadair@orange.com Tue Jun 12 23:54:10 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 0C57221F869A for ; Tue, 12 Jun 2012 23:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_MEDS=2.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EVb7ScVBhtW for ; Tue, 12 Jun 2012 23:54:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id EA92A21F867B for ; Tue, 12 Jun 2012 23:54:08 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 27C3F22C433; Wed, 13 Jun 2012 08:54:07 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F2EB84C015; Wed, 13 Jun 2012 08:54:06 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Wed, 13 Jun 2012 08:54:07 +0200 From: To: "sarikaya@ieee.org" , "Lee, Yiu" Date: Wed, 13 Jun 2012 08:54:05 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1I6eoskpRFV+/1Sr+8NeWk3gjXkQARcnwg Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.6.13.44528 Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 13 Jun 2012 06:54:10 -0000 Behcet, If you are suggesting we need get rid of multicast capabilities and use uni= cast between the AFTR and B4, I still claim this is a bad design choice. Th= e rationale for the design documented in the draft is as follows (excerpt f= rom the draft): " If customers have to access IPv4 multicast-based services through DS- Lite environment, Address Family Transition Router (AFTR) devices will have to process all the IGMP Report messages [RFC2236] [RFC3376] that have been forwarded by the CPE into the IPv4-in-IPv6 tunnels. From that standpoint, AFTR devices are likely to behave as a replication point for downstream multicast traffic. And the multicast packets will be replicated for each tunnel endpoint where IPv4 receivers are connected to. This kind of DS-Lite environment raises two major issues: 1. The IPv6 network loses the benefits of the multicast traffic forwarding efficiency because it is unable to deterministically replicate the data as close to the receivers as possible. As a consequence, the downstream bandwidth in the IPv6 network will be vastly consumed by sending multicast data over a unicast infrastructure. 2. The AFTR is responsible for replicating multicast traffic and forwarding it into each tunnel endpoint connecting IPv4 receivers that have explicitly asked for the corresponding contents. This process may greatly consume AFTR's resources and overload the AFTR. This document specifies an extension to the DS-Lite model to deliver IPv4 multicast services to IPv4 clients over an IPv6 multicast- enabled network. " For me, DS-Lite model is not only what is documented in RFC6333 but covers = also stateless A+P including MAP and 4rd.=20 Hope this clarifies your concern. Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Behcet Sarikaya >Envoy=E9 : mercredi 13 juin 2012 00:23 >=C0 : Lee, Yiu >Cc : softwires@ietf.org >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-dslite-multicast-02 > >Hi Yiu, > >The solution in this draft is generic, it simply leaves DS-Lite aside >and builds its own stuff. >I think this fact has been alluded to by the co-authors. > >This should change. Saying that a solution that integrates with >DS-Lite is technically poor solution is saying that DS-Lite is >technically poor solution. > >Behcet > >On Tue, Jun 12, 2012 at 3:56 PM, Lee, Yiu=20 > wrote: >> Hi Behect, >> >> You confuse me. 4.3 said this: >> >> "When the mAFTR receives an IPv4 multicast packet, it will=20 >encapsulate >> =A0 the packet into an IPv6 multicast packet using the=20 >IPv4-embedded IPv6 >> =A0 multicast address as the destination address and an IPv4-embedded >> =A0 IPv6 unicast address as the source address." >> >> The data packets are tunneled over IPv6 hub by hub. That=20 >said, the tunnel >> isn't end-to-end. >> >> Thanks, >> Yiu >> >> >> On 6/12/12 4:30 PM, "Behcet Sarikaya" wrote: >> >>>It is not the case in the draft currently, check Sections 4.3 & 6.2. >>> >>>Behcet >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From mohamed.boucadair@orange.com Wed Jun 13 00:03: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 9B8FD21F86FD for ; Wed, 13 Jun 2012 00:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOwBg-OBdHDS for ; Wed, 13 Jun 2012 00:03:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B2C6321F86FF for ; Wed, 13 Jun 2012 00:03:47 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 305F426440A; Wed, 13 Jun 2012 09:03:46 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 13C9935C05A; Wed, 13 Jun 2012 09:03:46 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 13 Jun 2012 09:03:46 +0200 From: To: "sarikaya@ieee.org" Date: Wed, 13 Jun 2012 09:03:44 +0200 Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: Ac1H7GxFuWrj53/LTKOdLTC2tYmK0wBRapFA Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FF0A1@PUEXCB1B.nanterre.francetelecom.fr> References: <4FC38782.8020207@viagenie.ca> <4FCD6B5E.3060408@jacni.com> <4FCE051B.3060003@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E32ED1EAB@PUEXCB1B.nanterre.francetelecom.fr> <4FD0E989.90801@venaas.com> <94C682931C08B048B7A8645303FDC9F36E32ED1FDA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E32ED20B4@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FE855@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.6.13.44528 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 13 Jun 2012 07:03:48 -0000 Re-, Did you read draft-ietf-softwire-dslite-multicast?=20 I have some doubts given your message below.=20 Cheers, Med >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : lundi 11 juin 2012 18:08 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : softwires@ietf.org; Yong Cui >Objet : Re: [Softwires] WG last call on=20 >draft-ietf-softwire-dslite-multicast-02 > >Hi Med, > >Thanks for your kind reply. I was talking about > >http://tools.ietf.org/html/draft-sarikaya-softwire-dslite6rdmul >ticast-00 >(which is now expired, I'll explain why below) > >Profiting the occasion, let me clarify that the chairs, Alain >initially asked the two drafts to be merged. >We favored the merger but Med was against. > >draft-ietf-softwire-dslite-multicast-02 presents a generic v4 to v6 >multicast translation technique and as has been indicated such an >approach has nothing to do with DS-Lite, i.e. DS-Lite does not >translate unicast v4 packets into unicast v6 packets. I hope this is >well understood. > >As such, draft-ietf-softwire-dslite-multicast-02 is suitable for >NAT64, (remind you that there is already a multicast solution draft >for NAT64). > >Regards, > >Behcet > > > >On Mon, Jun 11, 2012 at 1:15 AM, wrote: >> Hi Behcet, >> >> I failed to understand the point you are trying to make. >> >> The current situations is: >> >> * this document provides multicast extension to deliver=20 >multicast to DS-Lite serviced customers >> * we rely on multicast capabilities, as such no AMT-like=20 >considerations are included >> * the proposed solution is generic and can be deployed in=20 >any 4-6-4 use case >> >> What should be revised? >> >> Thanks for your help. >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>Envoy=E9 : vendredi 8 juin 2012 17:35 >>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui >>>Objet : Re: [Softwires] WG last call on >>>draft-ietf-softwire-dslite-multicast-02 >>> >>>Hi Med, >>> >>>I agree with Woj. >>> >>>I do not favor moving this draft to somewhere else. >>> >>>Instead this draft should be revised to make it >>>Multicast extensions to DS-Lite as in the charter. >>> >>>There is enough time to do it. >>> >>>Regards, >>> >>>Behcet >>> >>>On Fri, Jun 8, 2012 at 3:43 AM, =A0 > wrote: >>>> Hi Woj, >>>> >>>> Your comment is valid. >>>> >>>> The point I wanted to make is to recall the initial >>>motivation of this >>>> draft: solve an issue raised by DS-Lite people. >>>> >>>> Evidently, the proposed approach can be deployed in any >>>4-6-4 scenario. This >>>> will be reflected in the updated version of the draft. >>>> >>>> Cheers, >>>> Med >>>> >>>> ________________________________ >>>> De=A0: Wojciech Dec [mailto:wdec.ietf@gmail.com] >>>> Envoy=E9=A0: vendredi 8 juin 2012 09:57 >>>> =C0=A0: BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc=A0: sarikaya@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui >>>> >>>> Objet=A0: Re: [Softwires] WG last call on >>>> draft-ietf-softwire-dslite-multicast-02 >>>> >>>> Hello Med, >>>> >>>> there is no dependency here on ds-lite, ie This has all the >>>hallmarks of a >>>> standalone solution, which will almost certainly be >>>implemented as such, and >>>> one that will work with or without ds-lite for unicast. >>>> >>>> Regards, >>>> Woj. >>>> >>>> On 8 June 2012 07:48, wrote: >>>>> >>>>> Re-, >>>>> >>>>> May I re-iterate: >>>>> >>>>> * The draft is designed to allow the delivery of multicast >>>services to >>>>> DS-Lite serviced customers. >>>>> * The draft proposes multicast extensions and not unicast ones. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> >-----Message d'origine----- >>>>> >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>>>> >Envoy=E9 : jeudi 7 juin 2012 20:20 >>>>> >=C0 : Stig Venaas >>>>> >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui >>>>> >Objet : Re: [Softwires] WG last call on >>>>> >draft-ietf-softwire-dslite-multicast-02 >>>>> > >>>>> >On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas >>> wrote: >>>>> >> On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: >>>>> >>> >>>>> >>> On Thu, Jun 7, 2012 at 8:07 >>>>> >AM, =A0wrote: >>>>> >>>> >>>>> > >>>>> >>> So you are saying that this draft does not correspond to >>>>> >>> Multicast extensions for DS-Lite? >>>>> >> >>>>> >> >>>>> >> I sent a separate review, but anyway, it is not an extension to >>>>> >> DS-Lite as I see it. It is a completely generic approach for >>>>> >> tunneling v6 through v4. It can certainly be deployed=20 >in DS-Lite >>>>> >> scenarios, but it is much more generic. I would like the >>>title and >>>>> >> the text to reflect that. >>>>> > >>>>> >So it means that this draft does not correspond to=20 >Softwire charter >>>>> >item and we discover this quite late in the process. >>>>> > >>>>> >My recommendation to the chairs is to read and double >>>check the draft >>>>> >before making an adoption call, especially if there is choice. >>>>> > >>>>> >As I mentioned in my mboned mail, in multicast transition >>>I think the >>>>> >right approach is to agree to the fact that most of the host's >>>>> >communication will be unicast. For unicast, v4-v6 transition has >>>>> >already been well analyzed and several protocols have been >>>specified. >>>>> >Multicast extensions to those protocols are what we need. >>>>> > >>>>> >Regards, >>>>> > >>>>> >Behcet >>>>> > >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>>> >>> >= From maxpassion@gmail.com Wed Jun 13 03:09: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 ABFA321F8615 for ; Wed, 13 Jun 2012 03:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCFLg6GeE1-L for ; Wed, 13 Jun 2012 03:09:07 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B728221F8624 for ; Wed, 13 Jun 2012 03:09:07 -0700 (PDT) Received: by ggnc4 with SMTP id c4so283035ggn.31 for ; Wed, 13 Jun 2012 03:09:07 -0700 (PDT) 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:content-transfer-encoding; bh=7/aufqh/2UgQgMnDBxOrjnK2qUzjYxYcR7fbxeaSrAM=; b=bRZkaOfR+AQTMjqRsMvGulHC+JmYN7ZeswzfCbk1BXPWH1B0c1FD6ao7cdo417tZnT d5g9NoyeK/VFsBGiiR/SuZ2PL+igJTX/TVYeyVQbPoYwncgrZsPtSDbGAVZd5yxZFMEH tq3c80E5VOnel2je7nq1+EAPyT9ez+AkAMWZtkMopYYsrHeR4WGZ65OIgJ9g1YXYZ5+C nLL+LRTJwmDMnoHmY/cbLQXxCkrlZCGAeub92ASLv3eUlyp8+oOd6/13Sfr7aorU1iRI lPD5NrRfFrc8qf6NrJCPZWUml/m1hQCmL5ak1sLrlImKgVXjHAlFoDVas4MlGbq8Bv2Y sBdg== MIME-Version: 1.0 Received: by 10.60.2.138 with SMTP id 10mr23973009oeu.58.1339582147154; Wed, 13 Jun 2012 03:09:07 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Wed, 13 Jun 2012 03:09:07 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 13 Jun 2012 18:09:07 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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: Wed, 13 Jun 2012 10:09:08 -0000 Dear Med: 2012/6/13, mohamed.boucadair@orange.com : > Dear Dapeng, > > The current text says: > > * no state in the (provider) network side > * state may exist in the customer premises side =3D> I raised the concern yesterday for the term =93may=94 But didn=92t get response so far: > Med: Why "should"? The NAT is not mandatory =3D>Current candidate solutions told me that the NAT44 is mandatory part i.e. "The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6." http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don=92t think we should move forward. > * focus is on carrier-side stateless solutions =3D=3D>Carrier side stateless solution doesn=92t mean solution doesn=92t co= ver CPE. We need to clarify definitely. Regards, Dapeng > As an editor of the document, I believe the new version solves your > concerns. > > Cheers, > Med > >>-----Message d'origine----- >>De : softwires-bounces@ietf.org >>[mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>Envoy=E9 : mercredi 13 juin 2012 05:40 >>=C0 : Lee, Yiu >>Cc : softwires@ietf.org >>Objet : Re: [Softwires] I-D Action: >>draft-ietf-softwire-stateless-4v6-motivation-02.txt >> >>As a reader of the document, not co-author any related document, I >>believe people who is not involved the whole process (e.g. edit the >>documents, design the solutions,etc) couldn't understand the story >>behind that. I personally have sincerely heard some people presenting >>and evaluating this technology incorrectly somewhere before because of >>ambiguous understanding on the term. >> >>My purpose is that IETF has the responsibility to clarify what we are >>documenting clearly to prevent from misleading. >> >>I'm thankful to your discussion that made all things clear than before. >> >>And I don't understand why we don't document something we already >>agreed on, but let the misleading to continue. >> >>Regards, >>Dapeng Liu >> >>2012/6/13, Lee, Yiu : >>> Hi Dapeng, >>> >>> This draft was written by operators, we do not have any problem >>> understanding it. Besides, I disagree we "intentionally hide >>the truth". >>> Please explain to the WG what truth we are trying to hide in >>this draft? I >>> am not convinced we need to say anymore than what we have >>stated in the >>> new version. >>> >>> >>> Thanks, >>> Yiu >>> >>> >>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>> >>>>2012/6/12, Lee, Yiu : >>>>> Hi Dapeng., >>>>> >>>>> This is not a specification draft. This is a draft to discuss the >>>>> motivations. IMHO, people who are working in this area >>would be able to >>>>> understand this draft. >>>> >>>>=3D> I guess the audience is not only designer of protocol, but also >>>>operators >>>>who want to evaluate and adopt such technology. Intentional >>hiding the >>>>truth >>>>for me is really bad. >>>> >>>> >>>> >>>>The focus of it is about the carrier network, CPE >>>>> is never the focal point. I think the current statement "States may >>>>>still >>>>> exist in other equipments such as customer premises equipment." is >>>>>enough. >>>> >>>>=3D>Please see my reply in previous mail. "may" is not sufficient. >>>> >>>>> Adding more text only causes confusion. >>>> >>>>=3D>What I do is objectively to elaborate what we are. Why >>would that cause >>>>confusion? >>>> >>>>Regards, >>>>Dapeng >>>> >>>> >>>>> Thanks, >>>>> Yiu >>>>> >>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>> >>>>>>2012/6/12, Ole Tr=F8an : >>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>> >>>>>>>> "States still should be maintained in other equipments, >>e.g. customer >>>>>>>> premises equipment or host, in order to restrict IP >>address or port >>>>>>>> number >>>>>>>> information into the configured context except that a >>non-shared IPv4 >>>>>>>> address is >>>>>>>> assigned to a standalone host." >>>>>>> >>>>>>> I think this is just adding confusion. >>>>>>> the NAT44 on the CPE already does this. >>>>>> >>>>>>=3D>First off, we are not only talking about NAT44 here, but port >>>>>>translation and non-shared address. Secondly, NAT44 on the >>CPE is not >>>>>>doing what today NAT44 does. For example, override ID in ICMP with >>>>>>port information. >>>>>> >>>>>>that reminds me to update the proposed text a bit, >>>>>> >>>>>>"States still should be maintained in other equipments, >>e.g. customer >>>>>>premises equipment or host, in order to restrict L3 or L4 >>information >>>>>>into the configured context except that a non-shared IPv4 >>address is >>>>>>assigned to a standalone host." >>>>>> >>>>>>> I suggest we instead talk about no _additional_ state in >>the network. >>>>>>>there >>>>>>> is no need to mention the CPE, apart from stating that >>no additional >>>>>>>state >>>>>>> is required. >>>>>> >>>>>>=3D>I believe the above is clear for reader and designer. I >>don't see why >>>>>>we resist on clarifying and helping reader better understanding. >>>>>> >>>>>>Regards, >>>>>>Dapeng Liu >>>>>> >>>>>> >>>>>>> cheers, >>>>>>> Ole >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>> >>>>>>------ >>>>>>Best Regards, >>>>>>Dapeng Liu >>>>>>_______________________________________________ >>>>>>Softwires mailing list >>>>>>Softwires@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> >>>> >>>>-- >>>> >>>>------ >>>>Best Regards, >>>>Dapeng Liu >>> >> >> >>-- >> >>------ >>Best Regards, >>Dapeng Liu >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires >> --=20 ------ Best Regards, Dapeng Liu From mohamed.boucadair@orange.com Wed Jun 13 04:42: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 86F1021F854D for ; Wed, 13 Jun 2012 04:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRhzRY7zXELr for ; Wed, 13 Jun 2012 04:42:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 058AA21F867D for ; Wed, 13 Jun 2012 04:42:18 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 69FEF3242DD; Wed, 13 Jun 2012 13:42:17 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 4F51635C045; Wed, 13 Jun 2012 13:42:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 13 Jun 2012 13:42:17 +0200 From: To: liu dapeng Date: Wed, 13 Jun 2012 13:42:16 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: Ac1JTJO+DxKX5cjsQ+GvoVnO0wfrgwAC1kmA Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: 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.6.13.101524 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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: Wed, 13 Jun 2012 11:42:24 -0000 Re-, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : liu dapeng [mailto:maxpassion@gmail.com]=20 >Envoy=E9 : mercredi 13 juin 2012 12:09 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : softwires@ietf.org >Objet : Re: [Softwires] I-D Action:=20 >draft-ietf-softwire-stateless-4v6-motivation-02.txt > >Dear Med: > > >2012/6/13, mohamed.boucadair@orange.com : >> Dear Dapeng, >> >> The current text says: >> >> * no state in the (provider) network side >> * state may exist in the customer premises side > >=3D> I raised the concern yesterday for the term "may" >But didn't get response so far: > >> Med: Why "should"? The NAT is not mandatory > >=3D>Current candidate solutions told me that the NAT44 is mandatory part >i.e. > "The NAPT MUST in turn be connectedto a MAP aware forwarding >function, that does encapsulation/decapsulation or translation to >IPv6." > >http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html >please read that. Otherwise, I don't think we should move forward. > Med: You didn't answered my question. Pointing to a particular candidate so= lution is not a justification per se. I can change "may" to "should" to ple= ase you but it really does make sense. NAT is an optional feature in statel= ess solutions (e.g., host assigned with port restricted IPv4 address, host = assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses= , etc.).=20 > >> * focus is on carrier-side stateless solutions > >=3D=3D>Carrier side stateless solution doesn't mean solution doesn't cover >CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. > >Regards, >Dapeng > >> As an editor of the document, I believe the new version solves your >> concerns. >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : softwires-bounces@ietf.org >>>[mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>Envoy=E9 : mercredi 13 juin 2012 05:40 >>>=C0 : Lee, Yiu >>>Cc : softwires@ietf.org >>>Objet : Re: [Softwires] I-D Action: >>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>> >>>As a reader of the document, not co-author any related document, I >>>believe people who is not involved the whole process (e.g. edit the >>>documents, design the solutions,etc) couldn't understand the story >>>behind that. I personally have sincerely heard some people presenting >>>and evaluating this technology incorrectly somewhere before=20 >because of >>>ambiguous understanding on the term. >>> >>>My purpose is that IETF has the responsibility to clarify what we are >>>documenting clearly to prevent from misleading. >>> >>>I'm thankful to your discussion that made all things clear=20 >than before. >>> >>>And I don't understand why we don't document something we already >>>agreed on, but let the misleading to continue. >>> >>>Regards, >>>Dapeng Liu >>> >>>2012/6/13, Lee, Yiu : >>>> Hi Dapeng, >>>> >>>> This draft was written by operators, we do not have any problem >>>> understanding it. Besides, I disagree we "intentionally hide >>>the truth". >>>> Please explain to the WG what truth we are trying to hide in >>>this draft? I >>>> am not convinced we need to say anymore than what we have >>>stated in the >>>> new version. >>>> >>>> >>>> Thanks, >>>> Yiu >>>> >>>> >>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>> >>>>>2012/6/12, Lee, Yiu : >>>>>> Hi Dapeng., >>>>>> >>>>>> This is not a specification draft. This is a draft to discuss the >>>>>> motivations. IMHO, people who are working in this area >>>would be able to >>>>>> understand this draft. >>>>> >>>>>=3D> I guess the audience is not only designer of protocol, but also >>>>>operators >>>>>who want to evaluate and adopt such technology. Intentional >>>hiding the >>>>>truth >>>>>for me is really bad. >>>>> >>>>> >>>>> >>>>>The focus of it is about the carrier network, CPE >>>>>> is never the focal point. I think the current statement=20 >"States may >>>>>>still >>>>>> exist in other equipments such as customer premises=20 >equipment." is >>>>>>enough. >>>>> >>>>>=3D>Please see my reply in previous mail. "may" is not sufficient. >>>>> >>>>>> Adding more text only causes confusion. >>>>> >>>>>=3D>What I do is objectively to elaborate what we are. Why >>>would that cause >>>>>confusion? >>>>> >>>>>Regards, >>>>>Dapeng >>>>> >>>>> >>>>>> Thanks, >>>>>> Yiu >>>>>> >>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>> >>>>>>>2012/6/12, Ole Tr=F8an : >>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>> >>>>>>>>> "States still should be maintained in other equipments, >>>e.g. customer >>>>>>>>> premises equipment or host, in order to restrict IP >>>address or port >>>>>>>>> number >>>>>>>>> information into the configured context except that a >>>non-shared IPv4 >>>>>>>>> address is >>>>>>>>> assigned to a standalone host." >>>>>>>> >>>>>>>> I think this is just adding confusion. >>>>>>>> the NAT44 on the CPE already does this. >>>>>>> >>>>>>>=3D>First off, we are not only talking about NAT44 here, but port >>>>>>>translation and non-shared address. Secondly, NAT44 on the >>>CPE is not >>>>>>>doing what today NAT44 does. For example, override ID in=20 >ICMP with >>>>>>>port information. >>>>>>> >>>>>>>that reminds me to update the proposed text a bit, >>>>>>> >>>>>>>"States still should be maintained in other equipments, >>>e.g. customer >>>>>>>premises equipment or host, in order to restrict L3 or L4 >>>information >>>>>>>into the configured context except that a non-shared IPv4 >>>address is >>>>>>>assigned to a standalone host." >>>>>>> >>>>>>>> I suggest we instead talk about no _additional_ state in >>>the network. >>>>>>>>there >>>>>>>> is no need to mention the CPE, apart from stating that >>>no additional >>>>>>>>state >>>>>>>> is required. >>>>>>> >>>>>>>=3D>I believe the above is clear for reader and designer. I >>>don't see why >>>>>>>we resist on clarifying and helping reader better understanding. >>>>>>> >>>>>>>Regards, >>>>>>>Dapeng Liu >>>>>>> >>>>>>> >>>>>>>> cheers, >>>>>>>> Ole >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>-- >>>>>>> >>>>>>>------ >>>>>>>Best Regards, >>>>>>>Dapeng Liu >>>>>>>_______________________________________________ >>>>>>>Softwires mailing list >>>>>>>Softwires@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>> >>>>> >>>>>-- >>>>> >>>>>------ >>>>>Best Regards, >>>>>Dapeng Liu >>>> >>> >>> >>>-- >>> >>>------ >>>Best Regards, >>>Dapeng Liu >>>_______________________________________________ >>>Softwires mailing list >>>Softwires@ietf.org >>>https://www.ietf.org/mailman/listinfo/softwires >>> > > >--=20 > >------ >Best Regards, >Dapeng Liu >= From tom.taylor.stds@gmail.com Wed Jun 13 08:44: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 8978621F85C2 for ; Wed, 13 Jun 2012 08:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEKIsYpe6hHD for ; Wed, 13 Jun 2012 08:44:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF4A21F85A8 for ; Wed, 13 Jun 2012 08:44:03 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1619912lbb.31 for ; Wed, 13 Jun 2012 08:44:03 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=OK3zSd6V1Ow8aM75XRhlUl/T/t/PkDftQWaI9SBWpzs=; b=cyNsalOweBD1p/3DKoQJzVLkVPPSXYENZgSFpwexXz/B2OTRags75IwX6G13Py6gos qwh/qwdqzuRjRcvc111heaM9FoYSJdYsXEJwZt6w0hscMTFBrp3BT1e191RmPn8dvfk/ +CEHXa9FhSCXrt7tvjRcE3N5NI5dUCuWb88Q5o4pf00xHOtjUCnH5chLI8XPUMgj+kI5 PdGo5UUBpgvVbmhJwAzkSgmzlw6U//rnXJqyvP8BCvMWdgtnb27r4bBefMMAFs7RpHSm QJvmCqL6Q1+Y5k4FZcR8d2SN9SvJ72JIFUQAOEvzkhLRWvi3FiDWLaob5cGZC4snf15K lMbg== Received: by 10.112.40.36 with SMTP id u4mr6534383lbk.70.1339602243018; Wed, 13 Jun 2012 08:44:03 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-85-206.tor.primus.ca. [173.206.85.206]) by mx.google.com with ESMTPS id fy10sm2999910lab.0.2012.06.13.08.43.58 (version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 08:44:00 -0700 (PDT) Message-ID: <4FD8B53C.9070900@gmail.com> Date: Wed, 13 Jun 2012 11:43:56 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120613-0, 13/06/2012), Outbound message X-Antivirus-Status: Clean Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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: Wed, 13 Jun 2012 15:44:05 -0000 I think what Dapeng wants to convey would be achieved if you changed the "may" to "will typically": "... state will typically exist in the customer premises side" Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucadair@orange.com wrote: > Re-, > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : liu dapeng [mailto:maxpassion@gmail.com] >> Envoyé : mercredi 13 juin 2012 12:09 >> À : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : softwires@ietf.org >> Objet : Re: [Softwires] I-D Action: >> draft-ietf-softwire-stateless-4v6-motivation-02.txt >> >> Dear Med: >> >> >> 2012/6/13, mohamed.boucadair@orange.com: >>> Dear Dapeng, >>> >>> The current text says: >>> >>> * no state in the (provider) network side >>> * state may exist in the customer premises side >> >> => I raised the concern yesterday for the term "may" >> But didn't get response so far: >> >>> Med: Why "should"? The NAT is not mandatory >> >> =>Current candidate solutions told me that the NAT44 is mandatory part >> i.e. >> "The NAPT MUST in turn be connectedto a MAP aware forwarding >> function, that does encapsulation/decapsulation or translation to >> IPv6." >> >> http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html >> please read that. Otherwise, I don't think we should move forward. >> > > Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change "may" to "should" to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). > >> >>> * focus is on carrier-side stateless solutions >> >> ==>Carrier side stateless solution doesn't mean solution doesn't cover >> CPE. We need to clarify definitely. > > Med: Clarify what? The document already says: > > carrier-side stateless IPv4 over IPv6 solution. States may still > exist in other equipments such as customer premises equipment. > > >> >> Regards, >> Dapeng >> >>> As an editor of the document, I believe the new version solves your >>> concerns. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : softwires-bounces@ietf.org >>>> [mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>> Envoyé : mercredi 13 juin 2012 05:40 >>>> À : Lee, Yiu >>>> Cc : softwires@ietf.org >>>> Objet : Re: [Softwires] I-D Action: >>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> >>>> As a reader of the document, not co-author any related document, I >>>> believe people who is not involved the whole process (e.g. edit the >>>> documents, design the solutions,etc) couldn't understand the story >>>> behind that. I personally have sincerely heard some people presenting >>>> and evaluating this technology incorrectly somewhere before >> because of >>>> ambiguous understanding on the term. >>>> >>>> My purpose is that IETF has the responsibility to clarify what we are >>>> documenting clearly to prevent from misleading. >>>> >>>> I'm thankful to your discussion that made all things clear >> than before. >>>> >>>> And I don't understand why we don't document something we already >>>> agreed on, but let the misleading to continue. >>>> >>>> Regards, >>>> Dapeng Liu >>>> >>>> 2012/6/13, Lee, Yiu: >>>>> Hi Dapeng, >>>>> >>>>> This draft was written by operators, we do not have any problem >>>>> understanding it. Besides, I disagree we "intentionally hide >>>> the truth". >>>>> Please explain to the WG what truth we are trying to hide in >>>> this draft? I >>>>> am not convinced we need to say anymore than what we have >>>> stated in the >>>>> new version. >>>>> >>>>> >>>>> Thanks, >>>>> Yiu >>>>> >>>>> >>>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>>> >>>>>> 2012/6/12, Lee, Yiu: >>>>>>> Hi Dapeng., >>>>>>> >>>>>>> This is not a specification draft. This is a draft to discuss the >>>>>>> motivations. IMHO, people who are working in this area >>>> would be able to >>>>>>> understand this draft. >>>>>> >>>>>> => I guess the audience is not only designer of protocol, but also >>>>>> operators >>>>>> who want to evaluate and adopt such technology. Intentional >>>> hiding the >>>>>> truth >>>>>> for me is really bad. >>>>>> >>>>>> >>>>>> >>>>>> The focus of it is about the carrier network, CPE >>>>>>> is never the focal point. I think the current statement >> "States may >>>>>>> still >>>>>>> exist in other equipments such as customer premises >> equipment." is >>>>>>> enough. >>>>>> >>>>>> =>Please see my reply in previous mail. "may" is not sufficient. >>>>>> >>>>>>> Adding more text only causes confusion. >>>>>> >>>>>> =>What I do is objectively to elaborate what we are. Why >>>> would that cause >>>>>> confusion? >>>>>> >>>>>> Regards, >>>>>> Dapeng >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Yiu >>>>>>> >>>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>>> >>>>>>>> 2012/6/12, Ole Trøan: >>>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>>> >>>>>>>>>> "States still should be maintained in other equipments, >>>> e.g. customer >>>>>>>>>> premises equipment or host, in order to restrict IP >>>> address or port >>>>>>>>>> number >>>>>>>>>> information into the configured context except that a >>>> non-shared IPv4 >>>>>>>>>> address is >>>>>>>>>> assigned to a standalone host." >>>>>>>>> >>>>>>>>> I think this is just adding confusion. >>>>>>>>> the NAT44 on the CPE already does this. >>>>>>>> >>>>>>>> =>First off, we are not only talking about NAT44 here, but port >>>>>>>> translation and non-shared address. Secondly, NAT44 on the >>>> CPE is not >>>>>>>> doing what today NAT44 does. For example, override ID in >> ICMP with >>>>>>>> port information. >>>>>>>> >>>>>>>> that reminds me to update the proposed text a bit, >>>>>>>> >>>>>>>> "States still should be maintained in other equipments, >>>> e.g. customer >>>>>>>> premises equipment or host, in order to restrict L3 or L4 >>>> information >>>>>>>> into the configured context except that a non-shared IPv4 >>>> address is >>>>>>>> assigned to a standalone host." >>>>>>>> >>>>>>>>> I suggest we instead talk about no _additional_ state in >>>> the network. >>>>>>>>> there >>>>>>>>> is no need to mention the CPE, apart from stating that >>>> no additional >>>>>>>>> state >>>>>>>>> is required. >>>>>>>> >>>>>>>> =>I believe the above is clear for reader and designer. I >>>> don't see why >>>>>>>> we resist on clarifying and helping reader better understanding. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Dapeng Liu >>>>>>>> >>>>>>>> >>>>>>>>> cheers, >>>>>>>>> Ole >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> ------ >>>>>>>> Best Regards, >>>>>>>> Dapeng Liu >>>>>>>> _______________________________________________ >>>>>>>> Softwires mailing list >>>>>>>> Softwires@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> ------ >>>>>> Best Regards, >>>>>> Dapeng Liu >>>>> >>>> >>>> >>>> -- >>>> >>>> ------ >>>> Best Regards, >>>> Dapeng Liu >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From maxpassion@gmail.com Wed Jun 13 09:38:25 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 4160121F85D2 for ; Wed, 13 Jun 2012 09:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93Xz2tSD+DGd for ; Wed, 13 Jun 2012 09:38:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D26FE21F85B8 for ; Wed, 13 Jun 2012 09:38:23 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so1278434obb.31 for ; Wed, 13 Jun 2012 09:38:23 -0700 (PDT) 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:content-transfer-encoding; bh=41IADDcUHLrsMRnbG5adgFzHKwM8xHF4MuBT6zzWEQE=; b=aS0B8aTVCnK+n2VdZy+wx1RJqzq0KSHF6IO3sccASHSuzAbD+zNrtqTOvhJJVPs689 0QSYede2gJx2WUVBkpY9fKeBXKAdH+J1VXTuRBSWmPF7plv/9KGnJoMiswkiorgr5pHL iXEPfBmr4uA0EkBINtFfHQb3XgxIeNR8yH4G1id5LYdJL9f6nYd/YxONF5W5nRnxIpxx 6BNpeVnKmoU7FNgZyoMUWuOc7c0CodYX4yn6icVup/5jzseIJBoA2JE+rHzPAFOyJ12G N8EjjZcHw8OJjqnrJNQs3u+llDmyik1RNx2PURwM5aYFYFn9TmWhAFBHrJIG/sSxng5/ jeSw== MIME-Version: 1.0 Received: by 10.182.146.84 with SMTP id ta20mr25327426obb.19.1339605503072; Wed, 13 Jun 2012 09:38:23 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Wed, 13 Jun 2012 09:38:22 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 14 Jun 2012 00:38:22 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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: Wed, 13 Jun 2012 16:38:25 -0000 2012/6/13, mohamed.boucadair@orange.com : > Re-, > > Please see inline. > > Cheers, > Med > >>-----Message d'origine----- >>De : liu dapeng [mailto:maxpassion@gmail.com] >>Envoy=E9 : mercredi 13 juin 2012 12:09 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : softwires@ietf.org >>Objet : Re: [Softwires] I-D Action: >>draft-ietf-softwire-stateless-4v6-motivation-02.txt >> >>Dear Med: >> >> >>2012/6/13, mohamed.boucadair@orange.com : >>> Dear Dapeng, >>> >>> The current text says: >>> >>> * no state in the (provider) network side >>> * state may exist in the customer premises side >> >>=3D> I raised the concern yesterday for the term "may" >>But didn't get response so far: >> >>> Med: Why "should"? The NAT is not mandatory >> >>=3D>Current candidate solutions told me that the NAT44 is mandatory part >>i.e. >> "The NAPT MUST in turn be connectedto a MAP aware forwarding >>function, that does encapsulation/decapsulation or translation to >>IPv6." >> >>http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html >>please read that. Otherwise, I don't think we should move forward. >> > > Med: You didn't answered my question. Pointing to a particular candidate > solution is not a justification per se. =3D>OK. there are great algorithms and working group agreed solutions but you don't care. I can change "may" to "should" to > please you but it really does make sense. =3D> thanks NAT is an optional feature in > stateless solutions (e.g., host assigned with port restricted IPv4 addres= s, =3D>Please don't change subjects. We are talking about states. In my proposal, recommended the text is "state should be ..." NAT is only one sort of states. Port restriction is another. I already clarify that two days ago. http://www.ietf.org/mail-archive/web/softwires/current/msg04351.html > host assigned with a full IPv4 address, =3D>Please read last sentence in my proposal, that case was covered "States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict L3 or L4 information into the configured context EXCEPT that a non-shared IPv4 address is assigned to a standalone host." CPE assigned with pool of IPv4 > addresses, etc.). If operator could assign IPv4 pool which is big enought to locate one public IPv4 address to each user, I would challenge the motivation per se. Even you could assign IPv4 pool, NAT state is unavoidable. >> >>> * focus is on carrier-side stateless solutions >> >>=3D=3D>Carrier side stateless solution doesn't mean solution doesn't cove= r >>CPE. We need to clarify definitely. > > Med: Clarify what? The document already says: > > carrier-side stateless IPv4 over IPv6 solution. States may still > exist in other equipments such as customer premises equipment. =3D> Depending on above, please change "may" to "should". And clarify state on CPE and host. (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). =3D=3D> quite clear that you have three type cases in your mind already, I don't see why we reluctant to explain them correctly in the document. Regards, Dapeng > >> >>Regards, >>Dapeng >> >>> As an editor of the document, I believe the new version solves your >>> concerns. >>> >>> Cheers, >>> Med >>> >>>>-----Message d'origine----- >>>>De : softwires-bounces@ietf.org >>>>[mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>>Envoy=E9 : mercredi 13 juin 2012 05:40 >>>>=C0 : Lee, Yiu >>>>Cc : softwires@ietf.org >>>>Objet : Re: [Softwires] I-D Action: >>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> >>>>As a reader of the document, not co-author any related document, I >>>>believe people who is not involved the whole process (e.g. edit the >>>>documents, design the solutions,etc) couldn't understand the story >>>>behind that. I personally have sincerely heard some people presenting >>>>and evaluating this technology incorrectly somewhere before >>because of >>>>ambiguous understanding on the term. >>>> >>>>My purpose is that IETF has the responsibility to clarify what we are >>>>documenting clearly to prevent from misleading. >>>> >>>>I'm thankful to your discussion that made all things clear >>than before. >>>> >>>>And I don't understand why we don't document something we already >>>>agreed on, but let the misleading to continue. >>>> >>>>Regards, >>>>Dapeng Liu >>>> >>>>2012/6/13, Lee, Yiu : >>>>> Hi Dapeng, >>>>> >>>>> This draft was written by operators, we do not have any problem >>>>> understanding it. Besides, I disagree we "intentionally hide >>>>the truth". >>>>> Please explain to the WG what truth we are trying to hide in >>>>this draft? I >>>>> am not convinced we need to say anymore than what we have >>>>stated in the >>>>> new version. >>>>> >>>>> >>>>> Thanks, >>>>> Yiu >>>>> >>>>> >>>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>>> >>>>>>2012/6/12, Lee, Yiu : >>>>>>> Hi Dapeng., >>>>>>> >>>>>>> This is not a specification draft. This is a draft to discuss the >>>>>>> motivations. IMHO, people who are working in this area >>>>would be able to >>>>>>> understand this draft. >>>>>> >>>>>>=3D> I guess the audience is not only designer of protocol, but also >>>>>>operators >>>>>>who want to evaluate and adopt such technology. Intentional >>>>hiding the >>>>>>truth >>>>>>for me is really bad. >>>>>> >>>>>> >>>>>> >>>>>>The focus of it is about the carrier network, CPE >>>>>>> is never the focal point. I think the current statement >>"States may >>>>>>>still >>>>>>> exist in other equipments such as customer premises >>equipment." is >>>>>>>enough. >>>>>> >>>>>>=3D>Please see my reply in previous mail. "may" is not sufficient. >>>>>> >>>>>>> Adding more text only causes confusion. >>>>>> >>>>>>=3D>What I do is objectively to elaborate what we are. Why >>>>would that cause >>>>>>confusion? >>>>>> >>>>>>Regards, >>>>>>Dapeng >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Yiu >>>>>>> >>>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>>> >>>>>>>>2012/6/12, Ole Tr=F8an : >>>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>>> >>>>>>>>>> "States still should be maintained in other equipments, >>>>e.g. customer >>>>>>>>>> premises equipment or host, in order to restrict IP >>>>address or port >>>>>>>>>> number >>>>>>>>>> information into the configured context except that a >>>>non-shared IPv4 >>>>>>>>>> address is >>>>>>>>>> assigned to a standalone host." >>>>>>>>> >>>>>>>>> I think this is just adding confusion. >>>>>>>>> the NAT44 on the CPE already does this. >>>>>>>> >>>>>>>>=3D>First off, we are not only talking about NAT44 here, but port >>>>>>>>translation and non-shared address. Secondly, NAT44 on the >>>>CPE is not >>>>>>>>doing what today NAT44 does. For example, override ID in >>ICMP with >>>>>>>>port information. >>>>>>>> >>>>>>>>that reminds me to update the proposed text a bit, >>>>>>>> >>>>>>>>"States still should be maintained in other equipments, >>>>e.g. customer >>>>>>>>premises equipment or host, in order to restrict L3 or L4 >>>>information >>>>>>>>into the configured context except that a non-shared IPv4 >>>>address is >>>>>>>>assigned to a standalone host." >>>>>>>> >>>>>>>>> I suggest we instead talk about no _additional_ state in >>>>the network. >>>>>>>>>there >>>>>>>>> is no need to mention the CPE, apart from stating that >>>>no additional >>>>>>>>>state >>>>>>>>> is required. >>>>>>>> >>>>>>>>=3D>I believe the above is clear for reader and designer. I >>>>don't see why >>>>>>>>we resist on clarifying and helping reader better understanding. >>>>>>>> >>>>>>>>Regards, >>>>>>>>Dapeng Liu >>>>>>>> >>>>>>>> >>>>>>>>> cheers, >>>>>>>>> Ole >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-- >>>>>>>> >>>>>>>>------ >>>>>>>>Best Regards, >>>>>>>>Dapeng Liu >>>>>>>>_______________________________________________ >>>>>>>>Softwires mailing list >>>>>>>>Softwires@ietf.org >>>>>>>>https://www.ietf.org/mailman/listinfo/softwires >>>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>> >>>>>>------ >>>>>>Best Regards, >>>>>>Dapeng Liu >>>>> >>>> >>>> >>>>-- >>>> >>>>------ >>>>Best Regards, >>>>Dapeng Liu >>>>_______________________________________________ >>>>Softwires mailing list >>>>Softwires@ietf.org >>>>https://www.ietf.org/mailman/listinfo/softwires >>>> >> >> >>-- >> >>------ >>Best Regards, >>Dapeng Liu >> --=20 ------ Best Regards, Dapeng Liu From adurand@juniper.net Wed Jun 13 10:32: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 1CA3221F864D for ; Wed, 13 Jun 2012 10:32:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj+1Ef1uPwIE for ; Wed, 13 Jun 2012 10:32:23 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4642721F8637 for ; Wed, 13 Jun 2012 10:32:23 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT9jOpr0CQRFEIik7XmupncYqGgXjvTBp@postini.com; Wed, 13 Jun 2012 10:32:23 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 13 Jun 2012 10:27:44 -0700 From: Alain Durand To: "softwires@ietf.org WG" Date: Wed, 13 Jun 2012 10:27:43 -0700 Thread-Topic: WG chair change Thread-Index: Ac1JidcwynK5OQlNTGmbxjUpO44hYw== Message-ID: <43C00F20-664D-4552-8D19-3D26E18BC228@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yong Cui Subject: [Softwires] WG chair change 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, 13 Jun 2012 17:32:24 -0000 Effective today, I'm stepping down from the position of Softwire wg co-chai= r. I'd like to thank all of you that have been participating to this working g= roup since its creation in 2006. A lot of very good work came out it. Ralph Droms, our AD, has started the process to find a replacement. Alain.= From yiu_lee@cable.comcast.com Wed Jun 13 12: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 6773D21F85B8 for ; Wed, 13 Jun 2012 12:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.364 X-Spam-Level: X-Spam-Status: No, score=-104.364 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YT41BVq0f3cU for ; Wed, 13 Jun 2012 12:50:43 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id BFEC621F85B1 for ; Wed, 13 Jun 2012 12:50:40 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.21124725; Wed, 13 Jun 2012 13:34:05 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Wed, 13 Jun 2012 15:50:35 -0400 From: "Lee, Yiu" To: liu dapeng , "mohamed.boucadair@orange.com" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: AQHNSZ3Ld97getMBoEibP8aAqkYxhw== Date: Wed, 13 Jun 2012 19:50:34 +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.2.120421 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422447433_1446146" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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: Wed, 13 Jun 2012 19:50:44 -0000 --B_3422447433_1446146 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I prefer Tom suggestion. It is typical to have a NAT but not a must or should. On 6/13/12 12:38 PM, "liu dapeng" wrote: >I can change "may" to "should" to >>please you but it really does make sense. > >=> thanks > --B_3422447433_1446146 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTZs+6b Ugzzwwb1rloUG4a/r+/m4DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MTMxOTUwMzJaMA0GCSqGSIb3DQEBAQUABIIBAIukCbVX1WgE3AaM8vzwVNnd r1ohJL6GfXu0wLjz9notP7uNpZ7ZF2lAI+do6hQuYclKpG2T1G5CZT7wYkyjykIk5W87QFz6 TXJAuOdubE2ta6SzJlvj/aFq2M6/alzHjNiKzmyACcmoPsU8h/JhMWG/Bw9NrHh00vbxxeuc c34+hiRelyBFf507mL7Y5n3JcdsbPiKXZw/4faDZsgS/tdKLzYzotCMLhDOtP9A8x7kz40S7 UkZr5TuHZ5sEfR0Uj0nGeBSCdCRd40g5jx/DowVA/5/STSiW21lcsCM2hIOgF3qJjuRBHx5Z fLBo1sCtdmISChkHm77ln8isxXCxdwc= --B_3422447433_1446146-- From sarikaya2012@gmail.com Wed Jun 13 13:18:23 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 B90AA21F854F for ; Wed, 13 Jun 2012 13:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-1.129, BAYES_00=-2.599, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2nY5uRFWsG6 for ; Wed, 13 Jun 2012 13:18:23 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C504521F8469 for ; Wed, 13 Jun 2012 13:18:22 -0700 (PDT) Received: by ghbg16 with SMTP id g16so888316ghb.31 for ; Wed, 13 Jun 2012 13:18:22 -0700 (PDT) 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:content-transfer-encoding; bh=NmZ8AW25v+Nl3j2gMIkOU2gs7xAuIPto7t1QXfhUHeM=; b=vWsdVXOHgiW5jdcFSP2o/SSpD5xdeZq2jF5U8xCQA2jiXJgE5Axv/PCZ2mMsudPRtC JGbRRdmOh8PjaG9FS+h+gVJ7NSAUsxxgNOJRo7dzgTqqBxnUfO93/7TELwKs96hPIreA uimmcoL9covxp7lbkbk6pu1BslAZl+EcHSNmu9FUNho8Bgvmk1nerur+VMAZ0218AMcJ T77z8FO3taaMKWR/wbl8uHGaTNypqj1wZm9TGH61PBnsZ4sJ9UGK57jVhSi8Gq37QBIS +qrgVVzMEBbKREtaG4jjlO8mGWpDD2cTPIgBXh+jDhAdngs38mtjZylO3ekjefgSGIdl FgrA== MIME-Version: 1.0 Received: by 10.50.194.132 with SMTP id hw4mr11819103igc.63.1339618701778; Wed, 13 Jun 2012 13:18:21 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Wed, 13 Jun 2012 13:18:21 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 13 Jun 2012 15:18:21 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 13 Jun 2012 20:18:23 -0000 Hi Med, On Wed, Jun 13, 2012 at 1:54 AM, wrote: > Behcet, > > If you are suggesting we need get rid of multicast capabilities and use u= nicast between the AFTR and B4, I still claim this is a bad design choice. = The rationale for the design documented in the draft is as follows (excerpt= from the draft): > > " > =A0 If customers have to access IPv4 multicast-based services through DS- > =A0 Lite environment, Address Family Transition Router (AFTR) devices > =A0 will have to process all the IGMP Report messages [RFC2236] [RFC3376] > =A0 that have been forwarded by the CPE into the IPv4-in-IPv6 tunnels. > =A0 From that standpoint, AFTR devices are likely to behave as a > =A0 replication point for downstream multicast traffic. =A0And the > =A0 multicast packets will be replicated for each tunnel endpoint where > =A0 IPv4 receivers are connected to. > > =A0 This kind of DS-Lite environment raises two major issues: > > =A0 1. =A0The IPv6 network loses the benefits of the multicast traffic > =A0 =A0 =A0 forwarding efficiency because it is unable to deterministical= ly > =A0 =A0 =A0 replicate the data as close to the receivers as possible. =A0= As a > =A0 =A0 =A0 consequence, the downstream bandwidth in the IPv6 network wil= l be > =A0 =A0 =A0 vastly consumed by sending multicast data over a unicast > =A0 =A0 =A0 infrastructure. > > =A0 2. =A0The AFTR is responsible for replicating multicast traffic and > =A0 =A0 =A0 forwarding it into each tunnel endpoint connecting IPv4 recei= vers > =A0 =A0 =A0 that have explicitly asked for the corresponding contents. = =A0This > =A0 =A0 =A0 process may greatly consume AFTR's resources and overload the > =A0 =A0 =A0 AFTR. > > =A0 This document specifies an extension to the DS-Lite model to deliver > =A0 IPv4 multicast services to IPv4 clients over an IPv6 multicast- > =A0 enabled network. > " > There is a price for this. Many operators are willing to deploy IPv6 unicast only. If they deploy both unicast multicast IPv6 then they prefer to deploy dual stack network in which case there is no transition problem, see the discussion on Mboned list. > For me, DS-Lite model is not only what is documented in RFC6333 but cover= s also stateless A+P including MAP and 4rd. > Well, that is a different problem that requires a different solution. You are confirming again that your draft does not care about DS-Lite. You are looking at anything else but DS-Lite. > Hope this clarifies your concern. > If you don't like unicast DS-Lite solution, it is not the job of multicast DS-Lite solution to resolve it. Regards, Behcet > Cheers, > Med > >>-----Message d'origine----- >>De : softwires-bounces@ietf.org >>[mailto:softwires-bounces@ietf.org] De la part de Behcet Sarikaya >>Envoy=E9 : mercredi 13 juin 2012 00:23 >>=C0 : Lee, Yiu >>Cc : softwires@ietf.org >>Objet : Re: [Softwires] WG last call on >>draft-ietf-softwire-dslite-multicast-02 >> >>Hi Yiu, >> >>The solution in this draft is generic, it simply leaves DS-Lite aside >>and builds its own stuff. >>I think this fact has been alluded to by the co-authors. >> >>This should change. Saying that a solution that integrates with >>DS-Lite is technically poor solution is saying that DS-Lite is >>technically poor solution. >> >>Behcet >> >>On Tue, Jun 12, 2012 at 3:56 PM, Lee, Yiu >> wrote: >>> Hi Behect, >>> >>> You confuse me. 4.3 said this: >>> >>> "When the mAFTR receives an IPv4 multicast packet, it will >>encapsulate >>> =A0 the packet into an IPv6 multicast packet using the >>IPv4-embedded IPv6 >>> =A0 multicast address as the destination address and an IPv4-embedded >>> =A0 IPv6 unicast address as the source address." >>> >>> The data packets are tunneled over IPv6 hub by hub. That >>said, the tunnel >>> isn't end-to-end. >>> >>> Thanks, >>> Yiu >>> >>> >>> On 6/12/12 4:30 PM, "Behcet Sarikaya" wrote: >>> >>>>It is not the case in the draft currently, check Sections 4.3 & 6.2. >>>> >>>>Behcet >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires >> From yong@csnet1.cs.tsinghua.edu.cn Wed Jun 13 22:37: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 D51D221F8643 for ; Wed, 13 Jun 2012 22:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1-xamLjvq1w for ; Wed, 13 Jun 2012 22:37:35 -0700 (PDT) Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3A49E21F863E for ; Wed, 13 Jun 2012 22:37:08 -0700 (PDT) Received: from [10.1.1.243] (unknown [219.243.220.10]) by mail.csnet1.cs.tsinghua.edu.cn (Tsinghua University (Postfix)) with ESMTPA id C42411588028; Thu, 14 Jun 2012 13:33:46 +0800 (CST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 14 Jun 2012 13:35:54 +0800 From: Yong Cui To: Alain Durand , "softwires@ietf.org WG" Message-ID: Thread-Topic: [Softwires] WG chair change In-Reply-To: <43C00F20-664D-4552-8D19-3D26E18BC228@juniper.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Softwires] WG chair change 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, 14 Jun 2012 05:37:35 -0000 Hi Alain, Thank you very much for your great contribution during the past years. Back to 2006, you helped chairing the BOF meetings and several interim meetings. Based on those activities, we got great success to setup the softwire WG. After that, you still devotes to our Softwire WG during the years. Now we have more than 10 RFCs addressing the important issues for IPv4/IPv6 coexistence in our WG with your contribution. Although you decided to step down from the busy position of chairing the WG, we still hope you can share your valuable time with us in Softwire and act as one of the most active contributors here. Thank you again, Yong -----Original Message----- From: Alain Durand Date: Wed, 13 Jun 2012 10:27:43 -0700 To: "softwires@ietf.org WG" Cc: Yong Cui Subject: [Softwires] WG chair change >Effective today, I'm stepping down from the position of Softwire wg >co-chair. >I'd like to thank all of you that have been participating to this working >group since its >creation in 2006. A lot of very good work came out it. > >Ralph Droms, our AD, has started the process to find a replacement. > >Alain. >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > From mohamed.boucadair@orange.com Wed Jun 13 22:53: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 19B3E21F8648 for ; Wed, 13 Jun 2012 22:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSUi4BsZ1TnS for ; Wed, 13 Jun 2012 22:53:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E2F8521F863E for ; Wed, 13 Jun 2012 22:53:13 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 16A1E22C50B; Thu, 14 Jun 2012 07:53:12 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id EFC8935C045; Thu, 14 Jun 2012 07:53:11 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 14 Jun 2012 07:53:11 +0200 From: To: Tom Taylor Date: Thu, 14 Jun 2012 07:53:09 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: Ac1Je10XsF6Q6rYSQYqLSReM2oQmyAAdbXvg Message-ID: <94C682931C08B048B7A8645303FDC9F36E331FF3C3@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> <4FD8B53C.9070900@gmail.com> In-Reply-To: <4FD8B53C.9070900@gmail.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.5.24.112414 Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 14 Jun 2012 05:53:15 -0000 Hi Tom, Thank for the proposal. I can update the text with your proposed wording if= Dapeng is OK. Dapeng, are you happy with the text proposed by Tom? Cheers, Med=20 >-----Message d'origine----- >De : Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20 >Envoy=E9 : mercredi 13 juin 2012 17:44 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : liu dapeng; softwires@ietf.org >Objet : Re: [Softwires] I-D Action:=20 >draft-ietf-softwire-stateless-4v6-motivation-02.txt > >I think what Dapeng wants to convey would be achieved if you=20 >changed the=20 >"may" to "will typically": > "... state will typically exist in the customer premises side" > >Is this acceptable? > >On the second point, I agree with the existing text. > >Tom Taylor > >On 13/06/2012 7:42 AM, mohamed.boucadair@orange.com wrote: >> Re-, >> >> Please see inline. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : liu dapeng [mailto:maxpassion@gmail.com] >>> Envoy=E9 : mercredi 13 juin 2012 12:09 >>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>> Cc : softwires@ietf.org >>> Objet : Re: [Softwires] I-D Action: >>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>> >>> Dear Med: >>> >>> >>> 2012/6/13,=20 >mohamed.boucadair@orange.com: >>>> Dear Dapeng, >>>> >>>> The current text says: >>>> >>>> * no state in the (provider) network side >>>> * state may exist in the customer premises side >>> >>> =3D> I raised the concern yesterday for the term "may" >>> But didn't get response so far: >>> >>>> Med: Why "should"? The NAT is not mandatory >>> >>> =3D>Current candidate solutions told me that the NAT44 is=20 >mandatory part >>> i.e. >>> "The NAPT MUST in turn be connectedto a MAP aware forwarding >>> function, that does encapsulation/decapsulation or translation to >>> IPv6." >>> >>> http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html >>> please read that. Otherwise, I don't think we should move forward. >>> >> >> Med: You didn't answered my question. Pointing to a=20 >particular candidate solution is not a justification per se. I=20 >can change "may" to "should" to please you but it really does=20 >make sense. NAT is an optional feature in stateless solutions=20 >(e.g., host assigned with port restricted IPv4 address, host=20 >assigned with a full IPv4 address, CPE assigned with pool of=20 >IPv4 addresses, etc.). >> >>> >>>> * focus is on carrier-side stateless solutions >>> >>> =3D=3D>Carrier side stateless solution doesn't mean solution=20 >doesn't cover >>> CPE. We need to clarify definitely. >> >> Med: Clarify what? The document already says: >> >> carrier-side stateless IPv4 over IPv6 solution. States may still >> exist in other equipments such as customer premises equipment. >> >> >>> >>> Regards, >>> Dapeng >>> >>>> As an editor of the document, I believe the new version solves your >>>> concerns. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : softwires-bounces@ietf.org >>>>> [mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>>> Envoy=E9 : mercredi 13 juin 2012 05:40 >>>>> =C0 : Lee, Yiu >>>>> Cc : softwires@ietf.org >>>>> Objet : Re: [Softwires] I-D Action: >>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>> >>>>> As a reader of the document, not co-author any related document, I >>>>> believe people who is not involved the whole process=20 >(e.g. edit the >>>>> documents, design the solutions,etc) couldn't understand the story >>>>> behind that. I personally have sincerely heard some=20 >people presenting >>>>> and evaluating this technology incorrectly somewhere before >>> because of >>>>> ambiguous understanding on the term. >>>>> >>>>> My purpose is that IETF has the responsibility to clarify=20 >what we are >>>>> documenting clearly to prevent from misleading. >>>>> >>>>> I'm thankful to your discussion that made all things clear >>> than before. >>>>> >>>>> And I don't understand why we don't document something we already >>>>> agreed on, but let the misleading to continue. >>>>> >>>>> Regards, >>>>> Dapeng Liu >>>>> >>>>> 2012/6/13, Lee, Yiu: >>>>>> Hi Dapeng, >>>>>> >>>>>> This draft was written by operators, we do not have any problem >>>>>> understanding it. Besides, I disagree we "intentionally hide >>>>> the truth". >>>>>> Please explain to the WG what truth we are trying to hide in >>>>> this draft? I >>>>>> am not convinced we need to say anymore than what we have >>>>> stated in the >>>>>> new version. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Yiu >>>>>> >>>>>> >>>>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>>>> >>>>>>> 2012/6/12, Lee, Yiu: >>>>>>>> Hi Dapeng., >>>>>>>> >>>>>>>> This is not a specification draft. This is a draft to=20 >discuss the >>>>>>>> motivations. IMHO, people who are working in this area >>>>> would be able to >>>>>>>> understand this draft. >>>>>>> >>>>>>> =3D> I guess the audience is not only designer of=20 >protocol, but also >>>>>>> operators >>>>>>> who want to evaluate and adopt such technology. Intentional >>>>> hiding the >>>>>>> truth >>>>>>> for me is really bad. >>>>>>> >>>>>>> >>>>>>> >>>>>>> The focus of it is about the carrier network, CPE >>>>>>>> is never the focal point. I think the current statement >>> "States may >>>>>>>> still >>>>>>>> exist in other equipments such as customer premises >>> equipment." is >>>>>>>> enough. >>>>>>> >>>>>>> =3D>Please see my reply in previous mail. "may" is not sufficient. >>>>>>> >>>>>>>> Adding more text only causes confusion. >>>>>>> >>>>>>> =3D>What I do is objectively to elaborate what we are. Why >>>>> would that cause >>>>>>> confusion? >>>>>>> >>>>>>> Regards, >>>>>>> Dapeng >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Yiu >>>>>>>> >>>>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>>>> >>>>>>>>> 2012/6/12, Ole Tr=F8an: >>>>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>>>> >>>>>>>>>>> "States still should be maintained in other equipments, >>>>> e.g. customer >>>>>>>>>>> premises equipment or host, in order to restrict IP >>>>> address or port >>>>>>>>>>> number >>>>>>>>>>> information into the configured context except that a >>>>> non-shared IPv4 >>>>>>>>>>> address is >>>>>>>>>>> assigned to a standalone host." >>>>>>>>>> >>>>>>>>>> I think this is just adding confusion. >>>>>>>>>> the NAT44 on the CPE already does this. >>>>>>>>> >>>>>>>>> =3D>First off, we are not only talking about NAT44=20 >here, but port >>>>>>>>> translation and non-shared address. Secondly, NAT44 on the >>>>> CPE is not >>>>>>>>> doing what today NAT44 does. For example, override ID in >>> ICMP with >>>>>>>>> port information. >>>>>>>>> >>>>>>>>> that reminds me to update the proposed text a bit, >>>>>>>>> >>>>>>>>> "States still should be maintained in other equipments, >>>>> e.g. customer >>>>>>>>> premises equipment or host, in order to restrict L3 or L4 >>>>> information >>>>>>>>> into the configured context except that a non-shared IPv4 >>>>> address is >>>>>>>>> assigned to a standalone host." >>>>>>>>> >>>>>>>>>> I suggest we instead talk about no _additional_ state in >>>>> the network. >>>>>>>>>> there >>>>>>>>>> is no need to mention the CPE, apart from stating that >>>>> no additional >>>>>>>>>> state >>>>>>>>>> is required. >>>>>>>>> >>>>>>>>> =3D>I believe the above is clear for reader and designer. I >>>>> don't see why >>>>>>>>> we resist on clarifying and helping reader better=20 >understanding. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Dapeng Liu >>>>>>>>> >>>>>>>>> >>>>>>>>>> cheers, >>>>>>>>>> Ole >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> ------ >>>>>>>>> Best Regards, >>>>>>>>> Dapeng Liu >>>>>>>>> _______________________________________________ >>>>>>>>> Softwires mailing list >>>>>>>>> Softwires@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ------ >>>>>>> Best Regards, >>>>>>> Dapeng Liu >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------ >>>>> Best Regards, >>>>> Dapeng Liu >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>> >>> >>> -- >>> >>> ------ >>> Best Regards, >>> Dapeng Liu >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >= From satoru.matsushima@gmail.com Thu Jun 14 01:04: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 96D3421F867B for ; Thu, 14 Jun 2012 01:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl8NUtrHwagj for ; Thu, 14 Jun 2012 01:04:23 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28ECE21F8595 for ; Thu, 14 Jun 2012 01:04:04 -0700 (PDT) Received: by dacx6 with SMTP id x6so2195822dac.31 for ; Thu, 14 Jun 2012 01:04:04 -0700 (PDT) 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=xYx4yXgBLBFhZ/1iz1wbhJwuaj59ddCaSifG+6la8w0=; b=sWMWdGCzbjI2rQn44vm6Yw0/u0sfLTqbaakuj6F2iqod002nSjFAlao5yDjHmEqoFa iez5veLd090HFVKY5Cr5VaPcyCXBwxbVkJSlsFa4wuAYGoeZ1Odt+SFCkeYtdjJazVlk SwsCN1aCnPP+gG1zlm2Mt/fKZ6eWA0HHWveAvCeNaDlbaQEasnJzSDXsaG+oZgehpXqJ yjpLn3B9VEkXChXWWoVSr8rlrGfMJJLmw2Y9l80LNpMUjff943wKcTWXPASgow6CiVi0 IcFeudWu2lhDZWtdPPBsy6qg3Duu1qRqRbUgtMUUATu/C0PUjjL04n5H/UfV4B57fSYt hV/A== Received: by 10.68.194.4 with SMTP id hs4mr5103626pbc.128.1339661044531; Thu, 14 Jun 2012 01:04:04 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id jz4sm8703574pbc.17.2012.06.14.01.04.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jun 2012 01:04:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FF3C3@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 14 Jun 2012 17:03:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <90921E25-CA1E-4E48-997C-C9FF39DD2375@gmail.com> References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> <4FD8B53C.9070900@gmail.com> <94C682931C08B048B7A8645303FDC9F36E331FF3C3@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1278) Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 14 Jun 2012 08:04:24 -0000 As a co-author, I'm comfortable with this. --satoru On 2012/06/14, at 14:53, wrote: > Hi Tom, >=20 > Thank for the proposal. I can update the text with your proposed = wording if Dapeng is OK. >=20 > Dapeng, are you happy with the text proposed by Tom? >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20 >> Envoy=E9 : mercredi 13 juin 2012 17:44 >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : liu dapeng; softwires@ietf.org >> Objet : Re: [Softwires] I-D Action:=20 >> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>=20 >> I think what Dapeng wants to convey would be achieved if you=20 >> changed the=20 >> "may" to "will typically": >> "... state will typically exist in the customer premises side" >>=20 >> Is this acceptable? >>=20 >> On the second point, I agree with the existing text. >>=20 >> Tom Taylor >>=20 >> On 13/06/2012 7:42 AM, mohamed.boucadair@orange.com wrote: >>> Re-, >>>=20 >>> Please see inline. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : liu dapeng [mailto:maxpassion@gmail.com] >>>> Envoy=E9 : mercredi 13 juin 2012 12:09 >>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : softwires@ietf.org >>>> Objet : Re: [Softwires] I-D Action: >>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>=20 >>>> Dear Med: >>>>=20 >>>>=20 >>>> 2012/6/13,=20 >> mohamed.boucadair@orange.com: >>>>> Dear Dapeng, >>>>>=20 >>>>> The current text says: >>>>>=20 >>>>> * no state in the (provider) network side >>>>> * state may exist in the customer premises side >>>>=20 >>>> =3D> I raised the concern yesterday for the term "may" >>>> But didn't get response so far: >>>>=20 >>>>> Med: Why "should"? The NAT is not mandatory >>>>=20 >>>> =3D>Current candidate solutions told me that the NAT44 is=20 >> mandatory part >>>> i.e. >>>> "The NAPT MUST in turn be connectedto a MAP aware forwarding >>>> function, that does encapsulation/decapsulation or translation to >>>> IPv6." >>>>=20 >>>> = http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html >>>> please read that. Otherwise, I don't think we should move forward. >>>>=20 >>>=20 >>> Med: You didn't answered my question. Pointing to a=20 >> particular candidate solution is not a justification per se. I=20 >> can change "may" to "should" to please you but it really does=20 >> make sense. NAT is an optional feature in stateless solutions=20 >> (e.g., host assigned with port restricted IPv4 address, host=20 >> assigned with a full IPv4 address, CPE assigned with pool of=20 >> IPv4 addresses, etc.). >>>=20 >>>>=20 >>>>> * focus is on carrier-side stateless solutions >>>>=20 >>>> =3D=3D>Carrier side stateless solution doesn't mean solution=20 >> doesn't cover >>>> CPE. We need to clarify definitely. >>>=20 >>> Med: Clarify what? The document already says: >>>=20 >>> carrier-side stateless IPv4 over IPv6 solution. States may still >>> exist in other equipments such as customer premises equipment. >>>=20 >>>=20 >>>>=20 >>>> Regards, >>>> Dapeng >>>>=20 >>>>> As an editor of the document, I believe the new version solves = your >>>>> concerns. >>>>>=20 >>>>> Cheers, >>>>> Med >>>>>=20 >>>>>> -----Message d'origine----- >>>>>> De : softwires-bounces@ietf.org >>>>>> [mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>>>> Envoy=E9 : mercredi 13 juin 2012 05:40 >>>>>> =C0 : Lee, Yiu >>>>>> Cc : softwires@ietf.org >>>>>> Objet : Re: [Softwires] I-D Action: >>>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>>=20 >>>>>> As a reader of the document, not co-author any related document, = I >>>>>> believe people who is not involved the whole process=20 >> (e.g. edit the >>>>>> documents, design the solutions,etc) couldn't understand the = story >>>>>> behind that. I personally have sincerely heard some=20 >> people presenting >>>>>> and evaluating this technology incorrectly somewhere before >>>> because of >>>>>> ambiguous understanding on the term. >>>>>>=20 >>>>>> My purpose is that IETF has the responsibility to clarify=20 >> what we are >>>>>> documenting clearly to prevent from misleading. >>>>>>=20 >>>>>> I'm thankful to your discussion that made all things clear >>>> than before. >>>>>>=20 >>>>>> And I don't understand why we don't document something we already >>>>>> agreed on, but let the misleading to continue. >>>>>>=20 >>>>>> Regards, >>>>>> Dapeng Liu >>>>>>=20 >>>>>> 2012/6/13, Lee, Yiu: >>>>>>> Hi Dapeng, >>>>>>>=20 >>>>>>> This draft was written by operators, we do not have any problem >>>>>>> understanding it. Besides, I disagree we "intentionally hide >>>>>> the truth". >>>>>>> Please explain to the WG what truth we are trying to hide in >>>>>> this draft? I >>>>>>> am not convinced we need to say anymore than what we have >>>>>> stated in the >>>>>>> new version. >>>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Yiu >>>>>>>=20 >>>>>>>=20 >>>>>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>>>>>=20 >>>>>>>> 2012/6/12, Lee, Yiu: >>>>>>>>> Hi Dapeng., >>>>>>>>>=20 >>>>>>>>> This is not a specification draft. This is a draft to=20 >> discuss the >>>>>>>>> motivations. IMHO, people who are working in this area >>>>>> would be able to >>>>>>>>> understand this draft. >>>>>>>>=20 >>>>>>>> =3D> I guess the audience is not only designer of=20 >> protocol, but also >>>>>>>> operators >>>>>>>> who want to evaluate and adopt such technology. Intentional >>>>>> hiding the >>>>>>>> truth >>>>>>>> for me is really bad. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The focus of it is about the carrier network, CPE >>>>>>>>> is never the focal point. I think the current statement >>>> "States may >>>>>>>>> still >>>>>>>>> exist in other equipments such as customer premises >>>> equipment." is >>>>>>>>> enough. >>>>>>>>=20 >>>>>>>> =3D>Please see my reply in previous mail. "may" is not = sufficient. >>>>>>>>=20 >>>>>>>>> Adding more text only causes confusion. >>>>>>>>=20 >>>>>>>> =3D>What I do is objectively to elaborate what we are. Why >>>>>> would that cause >>>>>>>> confusion? >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>> Dapeng >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Yiu >>>>>>>>>=20 >>>>>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>>>>>=20 >>>>>>>>>> 2012/6/12, Ole Tr=F8an: >>>>>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>>>>>=20 >>>>>>>>>>>> "States still should be maintained in other equipments, >>>>>> e.g. customer >>>>>>>>>>>> premises equipment or host, in order to restrict IP >>>>>> address or port >>>>>>>>>>>> number >>>>>>>>>>>> information into the configured context except that a >>>>>> non-shared IPv4 >>>>>>>>>>>> address is >>>>>>>>>>>> assigned to a standalone host." >>>>>>>>>>>=20 >>>>>>>>>>> I think this is just adding confusion. >>>>>>>>>>> the NAT44 on the CPE already does this. >>>>>>>>>>=20 >>>>>>>>>> =3D>First off, we are not only talking about NAT44=20 >> here, but port >>>>>>>>>> translation and non-shared address. Secondly, NAT44 on the >>>>>> CPE is not >>>>>>>>>> doing what today NAT44 does. For example, override ID in >>>> ICMP with >>>>>>>>>> port information. >>>>>>>>>>=20 >>>>>>>>>> that reminds me to update the proposed text a bit, >>>>>>>>>>=20 >>>>>>>>>> "States still should be maintained in other equipments, >>>>>> e.g. customer >>>>>>>>>> premises equipment or host, in order to restrict L3 or L4 >>>>>> information >>>>>>>>>> into the configured context except that a non-shared IPv4 >>>>>> address is >>>>>>>>>> assigned to a standalone host." >>>>>>>>>>=20 >>>>>>>>>>> I suggest we instead talk about no _additional_ state in >>>>>> the network. >>>>>>>>>>> there >>>>>>>>>>> is no need to mention the CPE, apart from stating that >>>>>> no additional >>>>>>>>>>> state >>>>>>>>>>> is required. >>>>>>>>>>=20 >>>>>>>>>> =3D>I believe the above is clear for reader and designer. I >>>>>> don't see why >>>>>>>>>> we resist on clarifying and helping reader better=20 >> understanding. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Dapeng Liu >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> cheers, >>>>>>>>>>> Ole >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>>=20 >>>>>>>>>> ------ >>>>>>>>>> Best Regards, >>>>>>>>>> Dapeng Liu >>>>>>>>>> _______________________________________________ >>>>>>>>>> Softwires mailing list >>>>>>>>>> Softwires@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>>=20 >>>>>>>> ------ >>>>>>>> Best Regards, >>>>>>>> Dapeng Liu >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> ------ >>>>>> Best Regards, >>>>>> Dapeng Liu >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> ------ >>>> Best Regards, >>>> Dapeng Liu >>>>=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 From maxpassion@gmail.com Thu Jun 14 03:17: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 B69C121F86A7 for ; Thu, 14 Jun 2012 03:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEtLm7nuZZGT for ; Thu, 14 Jun 2012 03:17:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9CE21F8673 for ; Thu, 14 Jun 2012 03:17:52 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1121845obb.31 for ; Thu, 14 Jun 2012 03:17:50 -0700 (PDT) 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:content-transfer-encoding; bh=cPuKYcWAXQ7u3s/+vMe0byJwdWpcamBD+0PuCmK6/jk=; b=SBH1Dt7SvE8BG9yjRrLBwoCtmCR+k4f05xM+4QHPwEZLlDeFS5NTH4VqyE4GHclSDN KlkfTH52CI4YuLwjKs6C1CA9E6GZH/aTIalZsJilx/JQeWPHgLKfVtmXj1yUgLagfZ1l 2F+2+G+zaWk1f6/ewTHGWr3CD3KzryOa/LnSMFRtk7BBhiCql2U0v+khnaT3lC2HdCjR x5Y9TcHc3oANGfF/42EPsW9U8xFaggwovljXemPdS2fbTRtEiNS0W1g97CiaaaMDdKjZ dxxCMpAMVFTmMGyuPwCtyWHCZuoEjPhpfMEVX+T6WJN9sDsXx2+NwMJb0/I1ZwfqKHDN IDWw== MIME-Version: 1.0 Received: by 10.182.146.84 with SMTP id ta20mr1212333obb.19.1339669070726; Thu, 14 Jun 2012 03:17:50 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Thu, 14 Jun 2012 03:17:50 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E331FF3C3@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> <4FD8B53C.9070900@gmail.com> <94C682931C08B048B7A8645303FDC9F36E331FF3C3@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 14 Jun 2012 18:17:50 +0800 Message-ID: From: liu dapeng To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 14 Jun 2012 10:17:53 -0000 Hello Med and all, I don't agree we move like this way, as yourself said yesterday. "(e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.)." It isquite clear that you have three type cases in your mind already, I don't see why we reluctant to explain them correctly in the document. Please kindly help to let readers understand what is your thought. Thanks a lot for your help. Best Regards, -Dapeng 2012/6/14, mohamed.boucadair@orange.com : > Hi Tom, > > Thank for the proposal. I can update the text with your proposed wording = if > Dapeng is OK. > > Dapeng, are you happy with the text proposed by Tom? > > Cheers, > Med > >>-----Message d'origine----- >>De : Tom Taylor [mailto:tom.taylor.stds@gmail.com] >>Envoy=E9 : mercredi 13 juin 2012 17:44 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : liu dapeng; softwires@ietf.org >>Objet : Re: [Softwires] I-D Action: >>draft-ietf-softwire-stateless-4v6-motivation-02.txt >> >>I think what Dapeng wants to convey would be achieved if you >>changed the >>"may" to "will typically": >> "... state will typically exist in the customer premises side" >> >>Is this acceptable? >> >>On the second point, I agree with the existing text. >> >>Tom Taylor >> >>On 13/06/2012 7:42 AM, mohamed.boucadair@orange.com wrote: >>> Re-, >>> >>> Please see inline. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : liu dapeng [mailto:maxpassion@gmail.com] >>>> Envoy=E9 : mercredi 13 juin 2012 12:09 >>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>> Cc : softwires@ietf.org >>>> Objet : Re: [Softwires] I-D Action: >>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> >>>> Dear Med: >>>> >>>> >>>> 2012/6/13, >>mohamed.boucadair@orange.com: >>>>> Dear Dapeng, >>>>> >>>>> The current text says: >>>>> >>>>> * no state in the (provider) network side >>>>> * state may exist in the customer premises side >>>> >>>> =3D> I raised the concern yesterday for the term "may" >>>> But didn't get response so far: >>>> >>>>> Med: Why "should"? The NAT is not mandatory >>>> >>>> =3D>Current candidate solutions told me that the NAT44 is >>mandatory part >>>> i.e. >>>> "The NAPT MUST in turn be connectedto a MAP aware forwarding >>>> function, that does encapsulation/decapsulation or translation to >>>> IPv6." >>>> >>>> http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html >>>> please read that. Otherwise, I don't think we should move forward. >>>> >>> >>> Med: You didn't answered my question. Pointing to a >>particular candidate solution is not a justification per se. I >>can change "may" to "should" to please you but it really does >>make sense. NAT is an optional feature in stateless solutions >>(e.g., host assigned with port restricted IPv4 address, host >>assigned with a full IPv4 address, CPE assigned with pool of >>IPv4 addresses, etc.). >>> >>>> >>>>> * focus is on carrier-side stateless solutions >>>> >>>> =3D=3D>Carrier side stateless solution doesn't mean solution >>doesn't cover >>>> CPE. We need to clarify definitely. >>> >>> Med: Clarify what? The document already says: >>> >>> carrier-side stateless IPv4 over IPv6 solution. States may still >>> exist in other equipments such as customer premises equipment. >>> >>> >>>> >>>> Regards, >>>> Dapeng >>>> >>>>> As an editor of the document, I believe the new version solves your >>>>> concerns. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : softwires-bounces@ietf.org >>>>>> [mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>>>> Envoy=E9 : mercredi 13 juin 2012 05:40 >>>>>> =C0 : Lee, Yiu >>>>>> Cc : softwires@ietf.org >>>>>> Objet : Re: [Softwires] I-D Action: >>>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>> >>>>>> As a reader of the document, not co-author any related document, I >>>>>> believe people who is not involved the whole process >>(e.g. edit the >>>>>> documents, design the solutions,etc) couldn't understand the story >>>>>> behind that. I personally have sincerely heard some >>people presenting >>>>>> and evaluating this technology incorrectly somewhere before >>>> because of >>>>>> ambiguous understanding on the term. >>>>>> >>>>>> My purpose is that IETF has the responsibility to clarify >>what we are >>>>>> documenting clearly to prevent from misleading. >>>>>> >>>>>> I'm thankful to your discussion that made all things clear >>>> than before. >>>>>> >>>>>> And I don't understand why we don't document something we already >>>>>> agreed on, but let the misleading to continue. >>>>>> >>>>>> Regards, >>>>>> Dapeng Liu >>>>>> >>>>>> 2012/6/13, Lee, Yiu: >>>>>>> Hi Dapeng, >>>>>>> >>>>>>> This draft was written by operators, we do not have any problem >>>>>>> understanding it. Besides, I disagree we "intentionally hide >>>>>> the truth". >>>>>>> Please explain to the WG what truth we are trying to hide in >>>>>> this draft? I >>>>>>> am not convinced we need to say anymore than what we have >>>>>> stated in the >>>>>>> new version. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Yiu >>>>>>> >>>>>>> >>>>>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>>>>> >>>>>>>> 2012/6/12, Lee, Yiu: >>>>>>>>> Hi Dapeng., >>>>>>>>> >>>>>>>>> This is not a specification draft. This is a draft to >>discuss the >>>>>>>>> motivations. IMHO, people who are working in this area >>>>>> would be able to >>>>>>>>> understand this draft. >>>>>>>> >>>>>>>> =3D> I guess the audience is not only designer of >>protocol, but also >>>>>>>> operators >>>>>>>> who want to evaluate and adopt such technology. Intentional >>>>>> hiding the >>>>>>>> truth >>>>>>>> for me is really bad. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The focus of it is about the carrier network, CPE >>>>>>>>> is never the focal point. I think the current statement >>>> "States may >>>>>>>>> still >>>>>>>>> exist in other equipments such as customer premises >>>> equipment." is >>>>>>>>> enough. >>>>>>>> >>>>>>>> =3D>Please see my reply in previous mail. "may" is not sufficient. >>>>>>>> >>>>>>>>> Adding more text only causes confusion. >>>>>>>> >>>>>>>> =3D>What I do is objectively to elaborate what we are. Why >>>>>> would that cause >>>>>>>> confusion? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Dapeng >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Yiu >>>>>>>>> >>>>>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>>>>> >>>>>>>>>> 2012/6/12, Ole Tr=F8an: >>>>>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>>>>> >>>>>>>>>>>> "States still should be maintained in other equipments, >>>>>> e.g. customer >>>>>>>>>>>> premises equipment or host, in order to restrict IP >>>>>> address or port >>>>>>>>>>>> number >>>>>>>>>>>> information into the configured context except that a >>>>>> non-shared IPv4 >>>>>>>>>>>> address is >>>>>>>>>>>> assigned to a standalone host." >>>>>>>>>>> >>>>>>>>>>> I think this is just adding confusion. >>>>>>>>>>> the NAT44 on the CPE already does this. >>>>>>>>>> >>>>>>>>>> =3D>First off, we are not only talking about NAT44 >>here, but port >>>>>>>>>> translation and non-shared address. Secondly, NAT44 on the >>>>>> CPE is not >>>>>>>>>> doing what today NAT44 does. For example, override ID in >>>> ICMP with >>>>>>>>>> port information. >>>>>>>>>> >>>>>>>>>> that reminds me to update the proposed text a bit, >>>>>>>>>> >>>>>>>>>> "States still should be maintained in other equipments, >>>>>> e.g. customer >>>>>>>>>> premises equipment or host, in order to restrict L3 or L4 >>>>>> information >>>>>>>>>> into the configured context except that a non-shared IPv4 >>>>>> address is >>>>>>>>>> assigned to a standalone host." >>>>>>>>>> >>>>>>>>>>> I suggest we instead talk about no _additional_ state in >>>>>> the network. >>>>>>>>>>> there >>>>>>>>>>> is no need to mention the CPE, apart from stating that >>>>>> no additional >>>>>>>>>>> state >>>>>>>>>>> is required. >>>>>>>>>> >>>>>>>>>> =3D>I believe the above is clear for reader and designer. I >>>>>> don't see why >>>>>>>>>> we resist on clarifying and helping reader better >>understanding. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Dapeng Liu >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> cheers, >>>>>>>>>>> Ole >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> ------ >>>>>>>>>> Best Regards, >>>>>>>>>> Dapeng Liu >>>>>>>>>> _______________________________________________ >>>>>>>>>> Softwires mailing list >>>>>>>>>> Softwires@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> ------ >>>>>>>> Best Regards, >>>>>>>> Dapeng Liu >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> ------ >>>>>> Best Regards, >>>>>> Dapeng Liu >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>> >>>> >>>> -- >>>> >>>> ------ >>>> Best Regards, >>>> Dapeng Liu >>>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> --=20 ------ Best Regards, Dapeng Liu From phdgang@gmail.com Thu Jun 14 04:00:41 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 F2D6121F8663 for ; Thu, 14 Jun 2012 04:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMXyyglI1RUj for ; Thu, 14 Jun 2012 04:00:40 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9645E21F8644 for ; Thu, 14 Jun 2012 04:00:39 -0700 (PDT) Received: by werb13 with SMTP id b13so1394955wer.31 for ; Thu, 14 Jun 2012 04:00:38 -0700 (PDT) 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:content-transfer-encoding; bh=7z/L9511rbHZEf+/NnogjWORgXPyN5yJswRMHIO/Lbk=; b=XPVtKraYv7VigC9b3rEuZ6i4VKme3nXN+paSn5RWEKarjJy2z6VRHjDgbZvfcQC1dZ HXO7Ws8wPgZEKUtOPhwJrzdi/Qvj/dzsECt7kQS0mQG9QHqK7taFHou4kug6QuHN9epl 3+sY7p7XV12wNoNuMoVfcfaxpZIi1KMGiw+Kj1jO4JoOjYOCLDoB45gIg5w9syhDZMko qup0bbf6eiduDpAq8OXbXQTrEi5uWjXJSgPnXGGE7ePVYEdZoba2ub3tfCZfVPgjJmHs jJximhdI/ScDc7X86nn1D2oUs6pfjNyOuvl+gJwV9VOOjoKuXcqXmZwWYOmI9AxvQa/j ee3Q== MIME-Version: 1.0 Received: by 10.180.74.193 with SMTP id w1mr3479538wiv.4.1339671638612; Thu, 14 Jun 2012 04:00:38 -0700 (PDT) Received: by 10.180.104.136 with HTTP; Thu, 14 Jun 2012 04:00:38 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> <4FD8B53C.9070900@gmail.com> <94C682931C08B048B7A8645303FDC9F36E331FF3C3@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 14 Jun 2012 19:00:38 +0800 Message-ID: From: GangChen To: liu dapeng Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 14 Jun 2012 11:00:41 -0000 Hello Dapeng and all, I agreed Med explained three different cases and also understood Dapeng's desire. Trying to clarify cases and converge the discussion, I suggest following wo= rds. Hopefully, that could eliminate your concerns. "States should be maintained on other equipments, e.g. customer premises equipment or host, in ADDRESS SHARING CONTEXT" BRs Gang 2012/6/14, liu dapeng : > Hello Med and all, > > I don't agree we move like this way, as yourself said yesterday. > "(e.g., host assigned with port restricted IPv4 address, host assigned > with a full IPv4 address, CPE assigned with pool of IPv4 addresses, > etc.)." > > It isquite clear that you have three type cases in your mind already, > I don't see why we reluctant to explain them correctly in the > document. > > Please kindly help to let readers understand what is your thought. > Thanks a lot for your help. > > Best Regards, > -Dapeng > > > 2012/6/14, mohamed.boucadair@orange.com : >> Hi Tom, >> >> Thank for the proposal. I can update the text with your proposed wording >> if >> Dapeng is OK. >> >> Dapeng, are you happy with the text proposed by Tom? >> >> Cheers, >> Med >> >>>-----Message d'origine----- >>>De : Tom Taylor [mailto:tom.taylor.stds@gmail.com] >>>Envoy=E9 : mercredi 13 juin 2012 17:44 >>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>Cc : liu dapeng; softwires@ietf.org >>>Objet : Re: [Softwires] I-D Action: >>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>> >>>I think what Dapeng wants to convey would be achieved if you >>>changed the >>>"may" to "will typically": >>> "... state will typically exist in the customer premises side" >>> >>>Is this acceptable? >>> >>>On the second point, I agree with the existing text. >>> >>>Tom Taylor >>> >>>On 13/06/2012 7:42 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : liu dapeng [mailto:maxpassion@gmail.com] >>>>> Envoy=E9 : mercredi 13 juin 2012 12:09 >>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>> Cc : softwires@ietf.org >>>>> Objet : Re: [Softwires] I-D Action: >>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>> >>>>> Dear Med: >>>>> >>>>> >>>>> 2012/6/13, >>>mohamed.boucadair@orange.com: >>>>>> Dear Dapeng, >>>>>> >>>>>> The current text says: >>>>>> >>>>>> * no state in the (provider) network side >>>>>> * state may exist in the customer premises side >>>>> >>>>> =3D> I raised the concern yesterday for the term "may" >>>>> But didn't get response so far: >>>>> >>>>>> Med: Why "should"? The NAT is not mandatory >>>>> >>>>> =3D>Current candidate solutions told me that the NAT44 is >>>mandatory part >>>>> i.e. >>>>> "The NAPT MUST in turn be connectedto a MAP aware forwarding >>>>> function, that does encapsulation/decapsulation or translation to >>>>> IPv6." >>>>> >>>>> http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html >>>>> please read that. Otherwise, I don't think we should move forward. >>>>> >>>> >>>> Med: You didn't answered my question. Pointing to a >>>particular candidate solution is not a justification per se. I >>>can change "may" to "should" to please you but it really does >>>make sense. NAT is an optional feature in stateless solutions >>>(e.g., host assigned with port restricted IPv4 address, host >>>assigned with a full IPv4 address, CPE assigned with pool of >>>IPv4 addresses, etc.). >>>> >>>>> >>>>>> * focus is on carrier-side stateless solutions >>>>> >>>>> =3D=3D>Carrier side stateless solution doesn't mean solution >>>doesn't cover >>>>> CPE. We need to clarify definitely. >>>> >>>> Med: Clarify what? The document already says: >>>> >>>> carrier-side stateless IPv4 over IPv6 solution. States may still >>>> exist in other equipments such as customer premises equipment. >>>> >>>> >>>>> >>>>> Regards, >>>>> Dapeng >>>>> >>>>>> As an editor of the document, I believe the new version solves your >>>>>> concerns. >>>>>> >>>>>> Cheers, >>>>>> Med >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : softwires-bounces@ietf.org >>>>>>> [mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>>>>> Envoy=E9 : mercredi 13 juin 2012 05:40 >>>>>>> =C0 : Lee, Yiu >>>>>>> Cc : softwires@ietf.org >>>>>>> Objet : Re: [Softwires] I-D Action: >>>>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>>> >>>>>>> As a reader of the document, not co-author any related document, I >>>>>>> believe people who is not involved the whole process >>>(e.g. edit the >>>>>>> documents, design the solutions,etc) couldn't understand the story >>>>>>> behind that. I personally have sincerely heard some >>>people presenting >>>>>>> and evaluating this technology incorrectly somewhere before >>>>> because of >>>>>>> ambiguous understanding on the term. >>>>>>> >>>>>>> My purpose is that IETF has the responsibility to clarify >>>what we are >>>>>>> documenting clearly to prevent from misleading. >>>>>>> >>>>>>> I'm thankful to your discussion that made all things clear >>>>> than before. >>>>>>> >>>>>>> And I don't understand why we don't document something we already >>>>>>> agreed on, but let the misleading to continue. >>>>>>> >>>>>>> Regards, >>>>>>> Dapeng Liu >>>>>>> >>>>>>> 2012/6/13, Lee, Yiu: >>>>>>>> Hi Dapeng, >>>>>>>> >>>>>>>> This draft was written by operators, we do not have any problem >>>>>>>> understanding it. Besides, I disagree we "intentionally hide >>>>>>> the truth". >>>>>>>> Please explain to the WG what truth we are trying to hide in >>>>>>> this draft? I >>>>>>>> am not convinced we need to say anymore than what we have >>>>>>> stated in the >>>>>>>> new version. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yiu >>>>>>>> >>>>>>>> >>>>>>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>>>>>> >>>>>>>>> 2012/6/12, Lee, Yiu: >>>>>>>>>> Hi Dapeng., >>>>>>>>>> >>>>>>>>>> This is not a specification draft. This is a draft to >>>discuss the >>>>>>>>>> motivations. IMHO, people who are working in this area >>>>>>> would be able to >>>>>>>>>> understand this draft. >>>>>>>>> >>>>>>>>> =3D> I guess the audience is not only designer of >>>protocol, but also >>>>>>>>> operators >>>>>>>>> who want to evaluate and adopt such technology. Intentional >>>>>>> hiding the >>>>>>>>> truth >>>>>>>>> for me is really bad. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The focus of it is about the carrier network, CPE >>>>>>>>>> is never the focal point. I think the current statement >>>>> "States may >>>>>>>>>> still >>>>>>>>>> exist in other equipments such as customer premises >>>>> equipment." is >>>>>>>>>> enough. >>>>>>>>> >>>>>>>>> =3D>Please see my reply in previous mail. "may" is not sufficient= . >>>>>>>>> >>>>>>>>>> Adding more text only causes confusion. >>>>>>>>> >>>>>>>>> =3D>What I do is objectively to elaborate what we are. Why >>>>>>> would that cause >>>>>>>>> confusion? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Dapeng >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Yiu >>>>>>>>>> >>>>>>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>>>>>> >>>>>>>>>>> 2012/6/12, Ole Tr=F8an: >>>>>>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>>>>>> >>>>>>>>>>>>> "States still should be maintained in other equipments, >>>>>>> e.g. customer >>>>>>>>>>>>> premises equipment or host, in order to restrict IP >>>>>>> address or port >>>>>>>>>>>>> number >>>>>>>>>>>>> information into the configured context except that a >>>>>>> non-shared IPv4 >>>>>>>>>>>>> address is >>>>>>>>>>>>> assigned to a standalone host." >>>>>>>>>>>> >>>>>>>>>>>> I think this is just adding confusion. >>>>>>>>>>>> the NAT44 on the CPE already does this. >>>>>>>>>>> >>>>>>>>>>> =3D>First off, we are not only talking about NAT44 >>>here, but port >>>>>>>>>>> translation and non-shared address. Secondly, NAT44 on the >>>>>>> CPE is not >>>>>>>>>>> doing what today NAT44 does. For example, override ID in >>>>> ICMP with >>>>>>>>>>> port information. >>>>>>>>>>> >>>>>>>>>>> that reminds me to update the proposed text a bit, >>>>>>>>>>> >>>>>>>>>>> "States still should be maintained in other equipments, >>>>>>> e.g. customer >>>>>>>>>>> premises equipment or host, in order to restrict L3 or L4 >>>>>>> information >>>>>>>>>>> into the configured context except that a non-shared IPv4 >>>>>>> address is >>>>>>>>>>> assigned to a standalone host." >>>>>>>>>>> >>>>>>>>>>>> I suggest we instead talk about no _additional_ state in >>>>>>> the network. >>>>>>>>>>>> there >>>>>>>>>>>> is no need to mention the CPE, apart from stating that >>>>>>> no additional >>>>>>>>>>>> state >>>>>>>>>>>> is required. >>>>>>>>>>> >>>>>>>>>>> =3D>I believe the above is clear for reader and designer. I >>>>>>> don't see why >>>>>>>>>>> we resist on clarifying and helping reader better >>>understanding. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Dapeng Liu >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> cheers, >>>>>>>>>>>> Ole >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> ------ >>>>>>>>>>> Best Regards, >>>>>>>>>>> Dapeng Liu >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Softwires mailing list >>>>>>>>>>> Softwires@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> ------ >>>>>>>>> Best Regards, >>>>>>>>> Dapeng Liu >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> ------ >>>>>>> Best Regards, >>>>>>> Dapeng Liu >>>>>>> _______________________________________________ >>>>>>> Softwires mailing list >>>>>>> Softwires@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> ------ >>>>> Best Regards, >>>>> Dapeng Liu >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> > > > -- > > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From wdec.ietf@gmail.com Thu Jun 14 06:07:10 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 8A83821F8671 for ; Thu, 14 Jun 2012 06:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcA0hcxaVKmk for ; Thu, 14 Jun 2012 06:07:09 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57CF121F8658 for ; Thu, 14 Jun 2012 06:07:09 -0700 (PDT) Received: by qadz3 with SMTP id z3so4025620qad.10 for ; Thu, 14 Jun 2012 06:07:08 -0700 (PDT) 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=/E3nWc7ylLZpU8JB24Nq2euGPUwOiTyYQybcFrcs3AQ=; b=pZlUPnM0JKyLl3QTUlFfzO224UExxTADvguTyYlXjkG5QGA2G5F0Ky2Hx7lO8nUtXe bRURLf2fMwJXxvEJS61fuYvKAj3+9cIrMcryW264sD5+ul14fIM6pH7XqVld87F309E4 7riMrk+1BPLtoLQEwHtT2wFXbE6CxUO2Z0PrLikM8F3mSsQigDgv+DkuxdJFt7P1fimj gH8X9J2LZ1A4/3UUmgPBrT4KLS0hL7fleQjnj40Rqrkio4ztKkyb2cYmsfDXSmsz6EvQ 85yvPb6eTE44WgscAwW/eBZgws/MpBEhV3u4zvyV5bwMrdljJpEE4Fl8Zd/0E33XZQlL ucFg== MIME-Version: 1.0 Received: by 10.224.183.17 with SMTP id ce17mr4202646qab.8.1339679228689; Thu, 14 Jun 2012 06:07:08 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Thu, 14 Jun 2012 06:07:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Jun 2012 15:07:08 +0200 Message-ID: From: Wojciech Dec To: Peng Wu Content-Type: multipart/alternative; boundary=20cf303a2c0f89fbed04c26e6002 Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 14 Jun 2012 13:07:10 -0000 --20cf303a2c0f89fbed04c26e6002 Content-Type: text/plain; charset=ISO-8859-1 Peng, your answers do not address the key concerns: - Why is this needed, besides that it can be done, as opposed to classic dual stack? - It requires changes to the client/relay, thus it cannot be simply used with regular DHCPv4 implementations (note: it doesn't matter that you're putting a CRA element, that's an implementation detail). It is thus invesement in legacy IPv4 technology, not migration to IPv6. - It is more complicated to get through failures, to anyone who looks at it all objectively (Basic example: A dhcpv4 user will have no idea that the failure to get an ipv4 address is because in the CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a wrong AAAA for some host name that happens to be a dhcpv4 server, or because dhcpv6 is not providing the right option or name). - DHCPv4 servers need to be modified to take into account IPv6. -Woj. On 13 June 2012 06:36, Peng Wu wrote: > Woj, > > On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec wrote: > > Peng, > > > > On 11 June 2012 20:38, Peng Wu wrote: > >> > >> Woj, > >> > >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec > wrote: > >> > There is basic question regarding this draft, one that has also been > >> > raised > >> > at previous WG meetings: "why is it needed?". > >> It's actually written in section 4 of the draft. > >> > >> > There is a deeper issue here: This draft seems to give the impression > >> > that > >> > running such a regular public addressed DHCPv4 based overlay on IPv6 > is > >> > a > >> > simple idea, as opposed to native dual stack. It is anything but, > given > >> > that > >> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar > >> to scenario of DS-Lite and MAP/4rd. > >> I thought the assumption of IPv4-over-IPv6 is that you cannot/do not > >> want to provision native dual-stack? > > > > > > To put it simply: This draft describes a scenario where public v4 > addresses > > are available. The "classic" v6 migration scenario is in this case "dual > > stack" and is what I believe has been advised for years by the IETF, and > > continues to be the recommended approach. Why would one want to run in > this > > case dual-stack over a tunnel infra is the question? Is this intended as > an > > academic draft (as in "we can do it, but don't know why")? > [Peng] That's not always the case. Now to be more precise, with pb 4over6 > 1.Concentrator can be in a high position, and we don't have to IPv4 every > where > 2.Provision IPv4 in a flexible, on-demand way > 3.It can be deployed along with DS-lite to provide a value-added service > These points are already written in the draft > > >> > >> > a) it it requires changes to DHCPv4 processing b) it introduces non > >> > trivial > >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires > >> > changes to > >> > CPE d) makes life really a mess if we consider a real dual stack CPE. > >> a) Simply make DHCPv4 work with IPv6 as underlying transport. No > >> essential changes to protocol processing. > > > > > > Woj> That's not what the draft DHCPv4overv6 indicates, unless one > assumes a > > very specific and limiting deployment scenario. In any case it's quite > clear > > that it is not possible to use regular DHCPv4 clients for this, or a > regular > > DHCPv4 server (there is no mention of how the broadcast flags should be > > handled, mapped to IPv6, etc). > [Peng]Actually we can use regular DHCPv4 client, with the help of a > CRA function planted on the same host, that's a very fundamental point > of the DHCPv4over6v6 draft. > Server side need modification, yes. But only on the step of > sending/receiving DHCP messages (sockets). That's what I wanted to > express in last mail. > FYI, it only uses IPv6 unicast, with the aid of CRA. > > >> > >> b) What really matters here is provisioning the IPv4 address through > >> DHCPv4. Just like in MAP/4rd, you provision the address through > >> DHCPv6. > >> In pb4over6 DHCPv6 is only an *option* to provide the concentrator > >> address. You have similar logic too in MAP. > >> So I don't think it's "non trivial dependancy". They are similar > >> functions for all IPv4-over-IPv6 mechanisms that need provisioning, > >> only different technical paths. > > > > > > There are several components/parts that all need to play together in this > > solution, many more than apparently required, and the failure of one is > not > > obvious to anyone looking at another. As in any such multi-part system > > design, the overall complexity is higher. > Sorry but I simply don't buy that it's *significant* more complexity. > As to failure, it's more like a sequencial rather than " the failure > of one is not obvious to anyone looking at another". If I cannot get > the concentrator or the DHCPv4 server address, I stop the rest steps. > > > >> > >> c) Any IPv4-over-IPv6 mechanism requires change to CPE > > > > > > Yes, but in the case of this draft, the changes that are proposed do not > > lead to anything over and above what plain dual stack accomplishes, > except > > extra complexity. > See above > > Cheers~ > --20cf303a2c0f89fbed04c26e6002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peng,

your answers do not address the key concerns:
- Why is this= needed, besides that it can be done, as opposed to classic dual stack?
= - It requires changes to the client/relay, thus it cannot be simply used wi= th regular DHCPv4 implementations (note: it doesn't matter that you'= ;re putting a CRA element, that's an implementation detail). It is thus= invesement in legacy IPv4 technology, not migration to IPv6.
- It is more complicated to get through failures, to anyone who looks at it= all objectively (Basic example: A dhcpv4 user will have no idea that the f= ailure to get an ipv4 address is because in the CRA/whatever-stuff-is-combb= led-to-make-this-work DNSv6 is returning a wrong AAAA for some host name th= at happens to be a dhcpv4 server, or because dhcpv6 is not providing the ri= ght option or name).
- DHCPv4 servers need to be modified to take into account IPv6.

-Woj= .


On 13 June 2012 06:36, Peng Wu <pengwu.thu@gmail.com> wrote:
Woj,

On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Peng,
>
> On 11 June 2012 20:38, Peng Wu <pengwu.thu@gmail.com> wrote:
>>
>> Woj,
>>
>> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> > There is basic question regarding this draft, one that has al= so been
>> > raised
>> > at previous WG meetings: "why is it needed?".
>> It's actually written in section 4 of the draft.
>>
>> > There is a deeper issue here: This draft seems to give the im= pression
>> > that
>> > running such a regular public addressed DHCPv4 based overlay = on IPv6 is
>> > a
>> > simple idea, as opposed to native dual stack. It is anything = but, given
>> > that
>> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, s= imilar
>> to scenario of DS-Lite and MAP/4rd.
>> I thought the assumption of IPv4-over-IPv6 is that you cannot/do n= ot
>> want to provision native dual-stack?
>
>
> To put it simply: This draft describes a scenario where public v4 addr= esses
> are available. The "classic" v6 migration scenario is in thi= s case "dual
> stack" and is what I believe has been advised for years by the IE= TF, and
> continues to be the recommended approach. Why would one want to run in= this
> case dual-stack over a tunnel infra is the question? Is this intended = as an
> academic draft (as in "we can do it, but don't know why"= )?
[Peng] That's not always the case. Now to be more precise, = with pb 4over6
1.Concentrator can be in a high position, and we don't have to IPv4 eve= ry where
2.Provision IPv4 in a flexible, on-demand way
3.It can be deployed along with DS-lite to provide a value-added service These points are already written in the draft

>>
>> > a) it it requires changes to DHCPv4 processing b) it introduc= es non
>> > trivial
>> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requ= ires
>> > changes to
>> > CPE d) makes life really a mess if we consider a real dual st= ack CPE.
>> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >> essential changes to protocol processing.
>
>
> Woj> That's not what the draft DHCPv4overv6 indicates, unless o= ne assumes a
> very specific and limiting deployment scenario. In any case it's q= uite clear
> that it is not possible to use regular DHCPv4 clients for this, or a r= egular
> DHCPv4 server (there is no mention of how the broadcast flags should b= e
> handled, mapped to IPv6, etc).
[Peng]Actually we can use regular DHCPv4 client, with the help of a CRA function planted on the same host, that's a very fundamental point<= br> of the DHCPv4over6v6 draft.
Server side need modification, yes. But only on the step of
sending/receiving DHCP messages (sockets). That's what I wanted to
express in last mail.
FYI, it only uses IPv6 unicast, with the aid of CRA.

>>
>> b) What really matters here is provisioning the IPv4 address throu= gh
>> DHCPv4. Just like in MAP/4rd, you provision the address through >> DHCPv6.
>> In pb4over6 DHCPv6 is only an *option* to provide the concentrator=
>> address. You have similar logic too in MAP.
>> So I don't think it's "non trivial dependancy". = They are similar
>> functions for all IPv4-over-IPv6 mechanisms that need provisioning= ,
>> only different technical paths.
>
>
> There are several components/parts that all need to play together in t= his
> solution, many more than apparently required, and the failure of one i= s not
> obvious to anyone looking at another. As in any such multi-part system=
> design, the overall complexity is higher.
Sorry but I simply don't buy that it's *significant* more com= plexity.
As to failure, it's more like a sequencial rather than " the failu= re
of one is not obvious to anyone looking at another". If I cannot get the concentrator or the DHCPv4 server address, I stop the rest steps.


>>
>> c) Any IPv4-over-IPv6 mechanism requires change to CPE
>
>
> Yes, but in the case of this draft, the changes that are proposed do n= ot
> lead to anything over and above what plain dual stack accomplishes, ex= cept
> extra complexity.
See above

Cheers~

--20cf303a2c0f89fbed04c26e6002-- From maxpassion@gmail.com Thu Jun 14 14:50:43 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 85FC821F85F6 for ; Thu, 14 Jun 2012 14:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syXpRo4UALHq for ; Thu, 14 Jun 2012 14:50:42 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9155621F85DA for ; Thu, 14 Jun 2012 14:50:41 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2020996ggn.31 for ; Thu, 14 Jun 2012 14:50:41 -0700 (PDT) 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:content-transfer-encoding; bh=CEZWrm3tahxI1oJ4aHBeARTg7Fot6rtOvk2evbE6iIA=; b=gp3pv/c6O/OrmoL5MCd43raoYOVAaH5O+VcxKQwqlEbAP37IhmB0HYMMiohVQRXVaU 3UUU4qiEdYmYT8ryTq0s3B+T4z9wCBAPH9wJgSMRFhL68KF6eRwDl/+R6vL+xlf8HdoA f6lDH84jwCr3iI0/BpajTIr0FwL3o+yoCvigt34imwtXdv84wijEJHa6/gkm6fxcoQSd leG81CquMnxrw4jWwcUtL3PrDDLV/laUvd8ffHvkU5tLi6w1qL2wnbNdIAgQSgAirJUt fDYDuvv3V05ETnNXbRhA/JMYipkChkD2X9OBEBlPIHwbS4bKoO6S8qHCD5800ONlQ8P0 8Kiw== MIME-Version: 1.0 Received: by 10.60.1.165 with SMTP id 5mr3442965oen.36.1339710640867; Thu, 14 Jun 2012 14:50:40 -0700 (PDT) Received: by 10.76.1.46 with HTTP; Thu, 14 Jun 2012 14:50:40 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> <4FD8B53C.9070900@gmail.com> <94C682931C08B048B7A8645303FDC9F36E331FF3C3@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 15 Jun 2012 05:50:40 +0800 Message-ID: From: liu dapeng To: GangChen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 14 Jun 2012 21:50:43 -0000 Hi Gang, This works for me, thanks. Best Regards, Dapeng 2012/6/14, GangChen : > Hello Dapeng and all, > > I agreed Med explained three different cases and also understood > Dapeng's desire. > > Trying to clarify cases and converge the discussion, I suggest following > words. > Hopefully, that could eliminate your concerns. > > "States should be maintained on other equipments, e.g. customer > premises equipment or host, in ADDRESS SHARING CONTEXT" > > BRs > > Gang > > 2012/6/14, liu dapeng : >> Hello Med and all, >> >> I don't agree we move like this way, as yourself said yesterday. >> "(e.g., host assigned with port restricted IPv4 address, host assigned >> with a full IPv4 address, CPE assigned with pool of IPv4 addresses, >> etc.)." >> >> It isquite clear that you have three type cases in your mind already, >> I don't see why we reluctant to explain them correctly in the >> document. >> >> Please kindly help to let readers understand what is your thought. >> Thanks a lot for your help. >> >> Best Regards, >> -Dapeng >> >> >> 2012/6/14, mohamed.boucadair@orange.com : >>> Hi Tom, >>> >>> Thank for the proposal. I can update the text with your proposed wordin= g >>> if >>> Dapeng is OK. >>> >>> Dapeng, are you happy with the text proposed by Tom? >>> >>> Cheers, >>> Med >>> >>>>-----Message d'origine----- >>>>De : Tom Taylor [mailto:tom.taylor.stds@gmail.com] >>>>Envoy=E9 : mercredi 13 juin 2012 17:44 >>>>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>Cc : liu dapeng; softwires@ietf.org >>>>Objet : Re: [Softwires] I-D Action: >>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>> >>>>I think what Dapeng wants to convey would be achieved if you >>>>changed the >>>>"may" to "will typically": >>>> "... state will typically exist in the customer premises side" >>>> >>>>Is this acceptable? >>>> >>>>On the second point, I agree with the existing text. >>>> >>>>Tom Taylor >>>> >>>>On 13/06/2012 7:42 AM, mohamed.boucadair@orange.com wrote: >>>>> Re-, >>>>> >>>>> Please see inline. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : liu dapeng [mailto:maxpassion@gmail.com] >>>>>> Envoy=E9 : mercredi 13 juin 2012 12:09 >>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>> Cc : softwires@ietf.org >>>>>> Objet : Re: [Softwires] I-D Action: >>>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>> >>>>>> Dear Med: >>>>>> >>>>>> >>>>>> 2012/6/13, >>>>mohamed.boucadair@orange.com: >>>>>>> Dear Dapeng, >>>>>>> >>>>>>> The current text says: >>>>>>> >>>>>>> * no state in the (provider) network side >>>>>>> * state may exist in the customer premises side >>>>>> >>>>>> =3D> I raised the concern yesterday for the term "may" >>>>>> But didn't get response so far: >>>>>> >>>>>>> Med: Why "should"? The NAT is not mandatory >>>>>> >>>>>> =3D>Current candidate solutions told me that the NAT44 is >>>>mandatory part >>>>>> i.e. >>>>>> "The NAPT MUST in turn be connectedto a MAP aware forwarding >>>>>> function, that does encapsulation/decapsulation or translation to >>>>>> IPv6." >>>>>> >>>>>> http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html >>>>>> please read that. Otherwise, I don't think we should move forward. >>>>>> >>>>> >>>>> Med: You didn't answered my question. Pointing to a >>>>particular candidate solution is not a justification per se. I >>>>can change "may" to "should" to please you but it really does >>>>make sense. NAT is an optional feature in stateless solutions >>>>(e.g., host assigned with port restricted IPv4 address, host >>>>assigned with a full IPv4 address, CPE assigned with pool of >>>>IPv4 addresses, etc.). >>>>> >>>>>> >>>>>>> * focus is on carrier-side stateless solutions >>>>>> >>>>>> =3D=3D>Carrier side stateless solution doesn't mean solution >>>>doesn't cover >>>>>> CPE. We need to clarify definitely. >>>>> >>>>> Med: Clarify what? The document already says: >>>>> >>>>> carrier-side stateless IPv4 over IPv6 solution. States may still >>>>> exist in other equipments such as customer premises equipment. >>>>> >>>>> >>>>>> >>>>>> Regards, >>>>>> Dapeng >>>>>> >>>>>>> As an editor of the document, I believe the new version solves your >>>>>>> concerns. >>>>>>> >>>>>>> Cheers, >>>>>>> Med >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : softwires-bounces@ietf.org >>>>>>>> [mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>>>>>> Envoy=E9 : mercredi 13 juin 2012 05:40 >>>>>>>> =C0 : Lee, Yiu >>>>>>>> Cc : softwires@ietf.org >>>>>>>> Objet : Re: [Softwires] I-D Action: >>>>>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>>>> >>>>>>>> As a reader of the document, not co-author any related document, I >>>>>>>> believe people who is not involved the whole process >>>>(e.g. edit the >>>>>>>> documents, design the solutions,etc) couldn't understand the story >>>>>>>> behind that. I personally have sincerely heard some >>>>people presenting >>>>>>>> and evaluating this technology incorrectly somewhere before >>>>>> because of >>>>>>>> ambiguous understanding on the term. >>>>>>>> >>>>>>>> My purpose is that IETF has the responsibility to clarify >>>>what we are >>>>>>>> documenting clearly to prevent from misleading. >>>>>>>> >>>>>>>> I'm thankful to your discussion that made all things clear >>>>>> than before. >>>>>>>> >>>>>>>> And I don't understand why we don't document something we already >>>>>>>> agreed on, but let the misleading to continue. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Dapeng Liu >>>>>>>> >>>>>>>> 2012/6/13, Lee, Yiu: >>>>>>>>> Hi Dapeng, >>>>>>>>> >>>>>>>>> This draft was written by operators, we do not have any problem >>>>>>>>> understanding it. Besides, I disagree we "intentionally hide >>>>>>>> the truth". >>>>>>>>> Please explain to the WG what truth we are trying to hide in >>>>>>>> this draft? I >>>>>>>>> am not convinced we need to say anymore than what we have >>>>>>>> stated in the >>>>>>>>> new version. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Yiu >>>>>>>>> >>>>>>>>> >>>>>>>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>>>>>>> >>>>>>>>>> 2012/6/12, Lee, Yiu: >>>>>>>>>>> Hi Dapeng., >>>>>>>>>>> >>>>>>>>>>> This is not a specification draft. This is a draft to >>>>discuss the >>>>>>>>>>> motivations. IMHO, people who are working in this area >>>>>>>> would be able to >>>>>>>>>>> understand this draft. >>>>>>>>>> >>>>>>>>>> =3D> I guess the audience is not only designer of >>>>protocol, but also >>>>>>>>>> operators >>>>>>>>>> who want to evaluate and adopt such technology. Intentional >>>>>>>> hiding the >>>>>>>>>> truth >>>>>>>>>> for me is really bad. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The focus of it is about the carrier network, CPE >>>>>>>>>>> is never the focal point. I think the current statement >>>>>> "States may >>>>>>>>>>> still >>>>>>>>>>> exist in other equipments such as customer premises >>>>>> equipment." is >>>>>>>>>>> enough. >>>>>>>>>> >>>>>>>>>> =3D>Please see my reply in previous mail. "may" is not sufficien= t. >>>>>>>>>> >>>>>>>>>>> Adding more text only causes confusion. >>>>>>>>>> >>>>>>>>>> =3D>What I do is objectively to elaborate what we are. Why >>>>>>>> would that cause >>>>>>>>>> confusion? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Dapeng >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Yiu >>>>>>>>>>> >>>>>>>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>>>>>>> >>>>>>>>>>>> 2012/6/12, Ole Tr=F8an: >>>>>>>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>>>>>>> >>>>>>>>>>>>>> "States still should be maintained in other equipments, >>>>>>>> e.g. customer >>>>>>>>>>>>>> premises equipment or host, in order to restrict IP >>>>>>>> address or port >>>>>>>>>>>>>> number >>>>>>>>>>>>>> information into the configured context except that a >>>>>>>> non-shared IPv4 >>>>>>>>>>>>>> address is >>>>>>>>>>>>>> assigned to a standalone host." >>>>>>>>>>>>> >>>>>>>>>>>>> I think this is just adding confusion. >>>>>>>>>>>>> the NAT44 on the CPE already does this. >>>>>>>>>>>> >>>>>>>>>>>> =3D>First off, we are not only talking about NAT44 >>>>here, but port >>>>>>>>>>>> translation and non-shared address. Secondly, NAT44 on the >>>>>>>> CPE is not >>>>>>>>>>>> doing what today NAT44 does. For example, override ID in >>>>>> ICMP with >>>>>>>>>>>> port information. >>>>>>>>>>>> >>>>>>>>>>>> that reminds me to update the proposed text a bit, >>>>>>>>>>>> >>>>>>>>>>>> "States still should be maintained in other equipments, >>>>>>>> e.g. customer >>>>>>>>>>>> premises equipment or host, in order to restrict L3 or L4 >>>>>>>> information >>>>>>>>>>>> into the configured context except that a non-shared IPv4 >>>>>>>> address is >>>>>>>>>>>> assigned to a standalone host." >>>>>>>>>>>> >>>>>>>>>>>>> I suggest we instead talk about no _additional_ state in >>>>>>>> the network. >>>>>>>>>>>>> there >>>>>>>>>>>>> is no need to mention the CPE, apart from stating that >>>>>>>> no additional >>>>>>>>>>>>> state >>>>>>>>>>>>> is required. >>>>>>>>>>>> >>>>>>>>>>>> =3D>I believe the above is clear for reader and designer. I >>>>>>>> don't see why >>>>>>>>>>>> we resist on clarifying and helping reader better >>>>understanding. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Dapeng Liu >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> cheers, >>>>>>>>>>>>> Ole >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> ------ >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> Dapeng Liu >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Softwires mailing list >>>>>>>>>>>> Softwires@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> ------ >>>>>>>>>> Best Regards, >>>>>>>>>> Dapeng Liu >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> ------ >>>>>>>> Best Regards, >>>>>>>> Dapeng Liu >>>>>>>> _______________________________________________ >>>>>>>> Softwires mailing list >>>>>>>> Softwires@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> ------ >>>>>> Best Regards, >>>>>> Dapeng Liu >>>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > --=20 ------ Best Regards, Dapeng Liu From yiu_lee@cable.comcast.com Thu Jun 14 15:00: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 7996011E8098 for ; Thu, 14 Jun 2012 15:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxSiZZSTE9xE for ; Thu, 14 Jun 2012 15:00:23 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 440E921F85AD for ; Thu, 14 Jun 2012 15:00:23 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.16019717; Thu, 14 Jun 2012 17:51:00 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Thu, 14 Jun 2012 18:00:18 -0400 From: "Lee, Yiu" To: liu dapeng Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Thread-Index: AQHNSnfDRbXmOZxwyUKCOdEEyQnz6pb6XTwK Date: Thu, 14 Jun 2012 22:00:18 +0000 Message-ID: <05F66B92-F145-4856-9DC3-5F09C6DA0B7C@Cable.Comcast.com> References: <94C682931C08B048B7A8645303FDC9F36E331FF05D@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E331FF22F@PUEXCB1B.nanterre.francetelecom.fr> <4FD8B53C.9070900@gmail.com> <94C682931C08B048B7A8645303FDC9F36E331FF3C3@PUEXCB1B.nanterre.francetelecom.fr> , In-Reply-To: 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: "softwires@ietf.org" Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.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, 14 Jun 2012 22:00:24 -0000 Great! We will add it.=20 On Jun 14, 2012, at 5:50 PM, "liu dapeng" wrote: > Hi Gang, >=20 > This works for me, thanks. >=20 > Best Regards, > Dapeng >=20 > 2012/6/14, GangChen : >> Hello Dapeng and all, >>=20 >> I agreed Med explained three different cases and also understood >> Dapeng's desire. >>=20 >> Trying to clarify cases and converge the discussion, I suggest following >> words. >> Hopefully, that could eliminate your concerns. >>=20 >> "States should be maintained on other equipments, e.g. customer >> premises equipment or host, in ADDRESS SHARING CONTEXT" >>=20 >> BRs >>=20 >> Gang >>=20 >> 2012/6/14, liu dapeng : >>> Hello Med and all, >>>=20 >>> I don't agree we move like this way, as yourself said yesterday. >>> "(e.g., host assigned with port restricted IPv4 address, host assigned >>> with a full IPv4 address, CPE assigned with pool of IPv4 addresses, >>> etc.)." >>>=20 >>> It isquite clear that you have three type cases in your mind already, >>> I don't see why we reluctant to explain them correctly in the >>> document. >>>=20 >>> Please kindly help to let readers understand what is your thought. >>> Thanks a lot for your help. >>>=20 >>> Best Regards, >>> -Dapeng >>>=20 >>>=20 >>> 2012/6/14, mohamed.boucadair@orange.com : >>>> Hi Tom, >>>>=20 >>>> Thank for the proposal. I can update the text with your proposed wordi= ng >>>> if >>>> Dapeng is OK. >>>>=20 >>>> Dapeng, are you happy with the text proposed by Tom? >>>>=20 >>>> Cheers, >>>> Med >>>>=20 >>>>> -----Message d'origine----- >>>>> De : Tom Taylor [mailto:tom.taylor.stds@gmail.com] >>>>> Envoy=E9 : mercredi 13 juin 2012 17:44 >>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>> Cc : liu dapeng; softwires@ietf.org >>>>> Objet : Re: [Softwires] I-D Action: >>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>=20 >>>>> I think what Dapeng wants to convey would be achieved if you >>>>> changed the >>>>> "may" to "will typically": >>>>> "... state will typically exist in the customer premises side" >>>>>=20 >>>>> Is this acceptable? >>>>>=20 >>>>> On the second point, I agree with the existing text. >>>>>=20 >>>>> Tom Taylor >>>>>=20 >>>>> On 13/06/2012 7:42 AM, mohamed.boucadair@orange.com wrote: >>>>>> Re-, >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>> Cheers, >>>>>> Med >>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : liu dapeng [mailto:maxpassion@gmail.com] >>>>>>> Envoy=E9 : mercredi 13 juin 2012 12:09 >>>>>>> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>>> Cc : softwires@ietf.org >>>>>>> Objet : Re: [Softwires] I-D Action: >>>>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>>>=20 >>>>>>> Dear Med: >>>>>>>=20 >>>>>>>=20 >>>>>>> 2012/6/13, >>>>> mohamed.boucadair@orange.com: >>>>>>>> Dear Dapeng, >>>>>>>>=20 >>>>>>>> The current text says: >>>>>>>>=20 >>>>>>>> * no state in the (provider) network side >>>>>>>> * state may exist in the customer premises side >>>>>>>=20 >>>>>>> =3D> I raised the concern yesterday for the term "may" >>>>>>> But didn't get response so far: >>>>>>>=20 >>>>>>>> Med: Why "should"? The NAT is not mandatory >>>>>>>=20 >>>>>>> =3D>Current candidate solutions told me that the NAT44 is >>>>> mandatory part >>>>>>> i.e. >>>>>>> "The NAPT MUST in turn be connectedto a MAP aware forwarding >>>>>>> function, that does encapsulation/decapsulation or translation to >>>>>>> IPv6." >>>>>>>=20 >>>>>>> http://www.ietf.org/mail-archive/web/softwires/current/msg04379.htm= l >>>>>>> please read that. Otherwise, I don't think we should move forward. >>>>>>>=20 >>>>>>=20 >>>>>> Med: You didn't answered my question. Pointing to a >>>>> particular candidate solution is not a justification per se. I >>>>> can change "may" to "should" to please you but it really does >>>>> make sense. NAT is an optional feature in stateless solutions >>>>> (e.g., host assigned with port restricted IPv4 address, host >>>>> assigned with a full IPv4 address, CPE assigned with pool of >>>>> IPv4 addresses, etc.). >>>>>>=20 >>>>>>>=20 >>>>>>>> * focus is on carrier-side stateless solutions >>>>>>>=20 >>>>>>> =3D=3D>Carrier side stateless solution doesn't mean solution >>>>> doesn't cover >>>>>>> CPE. We need to clarify definitely. >>>>>>=20 >>>>>> Med: Clarify what? The document already says: >>>>>>=20 >>>>>> carrier-side stateless IPv4 over IPv6 solution. States may still >>>>>> exist in other equipments such as customer premises equipment. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Regards, >>>>>>> Dapeng >>>>>>>=20 >>>>>>>> As an editor of the document, I believe the new version solves you= r >>>>>>>> concerns. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Med >>>>>>>>=20 >>>>>>>>> -----Message d'origine----- >>>>>>>>> De : softwires-bounces@ietf.org >>>>>>>>> [mailto:softwires-bounces@ietf.org] De la part de liu dapeng >>>>>>>>> Envoy=E9 : mercredi 13 juin 2012 05:40 >>>>>>>>> =C0 : Lee, Yiu >>>>>>>>> Cc : softwires@ietf.org >>>>>>>>> Objet : Re: [Softwires] I-D Action: >>>>>>>>> draft-ietf-softwire-stateless-4v6-motivation-02.txt >>>>>>>>>=20 >>>>>>>>> As a reader of the document, not co-author any related document, = I >>>>>>>>> believe people who is not involved the whole process >>>>> (e.g. edit the >>>>>>>>> documents, design the solutions,etc) couldn't understand the stor= y >>>>>>>>> behind that. I personally have sincerely heard some >>>>> people presenting >>>>>>>>> and evaluating this technology incorrectly somewhere before >>>>>>> because of >>>>>>>>> ambiguous understanding on the term. >>>>>>>>>=20 >>>>>>>>> My purpose is that IETF has the responsibility to clarify >>>>> what we are >>>>>>>>> documenting clearly to prevent from misleading. >>>>>>>>>=20 >>>>>>>>> I'm thankful to your discussion that made all things clear >>>>>>> than before. >>>>>>>>>=20 >>>>>>>>> And I don't understand why we don't document something we already >>>>>>>>> agreed on, but let the misleading to continue. >>>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Dapeng Liu >>>>>>>>>=20 >>>>>>>>> 2012/6/13, Lee, Yiu: >>>>>>>>>> Hi Dapeng, >>>>>>>>>>=20 >>>>>>>>>> This draft was written by operators, we do not have any problem >>>>>>>>>> understanding it. Besides, I disagree we "intentionally hide >>>>>>>>> the truth". >>>>>>>>>> Please explain to the WG what truth we are trying to hide in >>>>>>>>> this draft? I >>>>>>>>>> am not convinced we need to say anymore than what we have >>>>>>>>> stated in the >>>>>>>>>> new version. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>> Yiu >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 6/12/12 11:45 AM, "liu dapeng" wrote: >>>>>>>>>>=20 >>>>>>>>>>> 2012/6/12, Lee, Yiu: >>>>>>>>>>>> Hi Dapeng., >>>>>>>>>>>>=20 >>>>>>>>>>>> This is not a specification draft. This is a draft to >>>>> discuss the >>>>>>>>>>>> motivations. IMHO, people who are working in this area >>>>>>>>> would be able to >>>>>>>>>>>> understand this draft. >>>>>>>>>>>=20 >>>>>>>>>>> =3D> I guess the audience is not only designer of >>>>> protocol, but also >>>>>>>>>>> operators >>>>>>>>>>> who want to evaluate and adopt such technology. Intentional >>>>>>>>> hiding the >>>>>>>>>>> truth >>>>>>>>>>> for me is really bad. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The focus of it is about the carrier network, CPE >>>>>>>>>>>> is never the focal point. I think the current statement >>>>>>> "States may >>>>>>>>>>>> still >>>>>>>>>>>> exist in other equipments such as customer premises >>>>>>> equipment." is >>>>>>>>>>>> enough. >>>>>>>>>>>=20 >>>>>>>>>>> =3D>Please see my reply in previous mail. "may" is not sufficie= nt. >>>>>>>>>>>=20 >>>>>>>>>>>> Adding more text only causes confusion. >>>>>>>>>>>=20 >>>>>>>>>>> =3D>What I do is objectively to elaborate what we are. Why >>>>>>>>> would that cause >>>>>>>>>>> confusion? >>>>>>>>>>>=20 >>>>>>>>>>> Regards, >>>>>>>>>>> Dapeng >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Yiu >>>>>>>>>>>>=20 >>>>>>>>>>>> On 6/12/12 6:21 AM, "liu dapeng" wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> 2012/6/12, Ole Tr=F8an: >>>>>>>>>>>>>>> Ok, then we can make this more clear in our document. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> "States still should be maintained in other equipments, >>>>>>>>> e.g. customer >>>>>>>>>>>>>>> premises equipment or host, in order to restrict IP >>>>>>>>> address or port >>>>>>>>>>>>>>> number >>>>>>>>>>>>>>> information into the configured context except that a >>>>>>>>> non-shared IPv4 >>>>>>>>>>>>>>> address is >>>>>>>>>>>>>>> assigned to a standalone host." >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I think this is just adding confusion. >>>>>>>>>>>>>> the NAT44 on the CPE already does this. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =3D>First off, we are not only talking about NAT44 >>>>> here, but port >>>>>>>>>>>>> translation and non-shared address. Secondly, NAT44 on the >>>>>>>>> CPE is not >>>>>>>>>>>>> doing what today NAT44 does. For example, override ID in >>>>>>> ICMP with >>>>>>>>>>>>> port information. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> that reminds me to update the proposed text a bit, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> "States still should be maintained in other equipments, >>>>>>>>> e.g. customer >>>>>>>>>>>>> premises equipment or host, in order to restrict L3 or L4 >>>>>>>>> information >>>>>>>>>>>>> into the configured context except that a non-shared IPv4 >>>>>>>>> address is >>>>>>>>>>>>> assigned to a standalone host." >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I suggest we instead talk about no _additional_ state in >>>>>>>>> the network. >>>>>>>>>>>>>> there >>>>>>>>>>>>>> is no need to mention the CPE, apart from stating that >>>>>>>>> no additional >>>>>>>>>>>>>> state >>>>>>>>>>>>>> is required. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =3D>I believe the above is clear for reader and designer. I >>>>>>>>> don't see why >>>>>>>>>>>>> we resist on clarifying and helping reader better >>>>> understanding. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Dapeng Liu >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> cheers, >>>>>>>>>>>>>> Ole >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- >>>>>>>>>>>>>=20 >>>>>>>>>>>>> ------ >>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>> Dapeng Liu >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Softwires mailing list >>>>>>>>>>>>> Softwires@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>>=20 >>>>>>>>>>> ------ >>>>>>>>>>> Best Regards, >>>>>>>>>>> Dapeng Liu >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>>=20 >>>>>>>>> ------ >>>>>>>>> Best Regards, >>>>>>>>> Dapeng Liu >>>>>>>>> _______________________________________________ >>>>>>>>> Softwires mailing list >>>>>>>>> Softwires@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>>=20 >>>>>>> ------ >>>>>>> Best Regards, >>>>>>> Dapeng Liu >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>=20 >>>>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> ------ >>> Best Regards, >>> Dapeng Liu >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Thu Jun 14 19:51: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 CF4A411E8098 for ; Thu, 14 Jun 2012 19:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.604 X-Spam-Level: X-Spam-Status: No, score=-103.604 tagged_above=-999 required=5 tests=[AWL=0.230, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00F3H-WpP3kB for ; Thu, 14 Jun 2012 19:51:32 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE3F11E8089 for ; Thu, 14 Jun 2012 19:51:32 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.21328082; Thu, 14 Jun 2012 20:34:54 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.02.0283.003; Thu, 14 Jun 2012 22:51:27 -0400 From: "Lee, Yiu" To: Wojciech Dec , Peng Wu Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Thread-Index: AQHNSqHBnuJmRlUVdkKBEaVagu+jTQ== Date: Fri, 15 Jun 2012 02:51:26 +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.2.120421 x-originating-ip: [24.40.55.71] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422559084_988468" MIME-Version: 1.0 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 15 Jun 2012 02:51:33 -0000 --B_3422559084_988468 Content-type: multipart/alternative; boundary="B_3422559083_1021910" --B_3422559083_1021910 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Woj, Let me try to answer some of your questions: From: Wojciech Dec Date: Thursday, June 14, 2012 9:07 AM To: Peng Wu Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Peng, your answers do not address the key concerns: - Why is this needed, besides that it can be done, as opposed to classic dual stack? [YL] The scenario is addressing IPv6-only access network. If the access network is DS, yes, you don't need this technology. - It requires changes to the client/relay, thus it cannot be simply used with regular DHCPv4 implementations (note: it doesn't matter that you're putting a CRA element, that's an implementation detail). It is thus invesement in legacy IPv4 technology, not migration to IPv6. [YL] AFAIK, the client won't change but will require CRA. This technology is to support legacy v4 service while migrating to IPv6. The client will have both v4 and v6 addresses. This is given. So I fail to see why this is only an investment in legacy IPv4 technology. - It is more complicated to get through failures, to anyone who looks at it all objectively (Basic example: A dhcpv4 user will have no idea that the failure to get an ipv4 address is because in the CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a wrong AAAA for some host name that happens to be a dhcpv4 server, or because dhcpv6 is not providing the right option or name). [YL] I am sorry, I can't follow this. Can you explain more please? - DHCPv4 servers need to be modified to take into account IPv6. [YL] Yes or we need to deploy TRA. Thanks, Yiu -Woj. On 13 June 2012 06:36, Peng Wu wrote: > Woj, > > On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec wrote: >> > Peng, >> > >> > On 11 June 2012 20:38, Peng Wu wrote: >>> >> >>> >> Woj, >>> >> >>> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec >>> wrote: >>>> >> > There is basic question regarding this draft, one that has also been >>>> >> > raised >>>> >> > at previous WG meetings: "why is it needed?". >>> >> It's actually written in section 4 of the draft. >>> >> >>>> >> > There is a deeper issue here: This draft seems to give the impression >>>> >> > that >>>> >> > running such a regular public addressed DHCPv4 based overlay on IPv6 is >>>> >> > a >>>> >> > simple idea, as opposed to native dual stack. It is anything but, >>>> given >>>> >> > that >>> >> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar >>> >> to scenario of DS-Lite and MAP/4rd. >>> >> I thought the assumption of IPv4-over-IPv6 is that you cannot/do not >>> >> want to provision native dual-stack? >> > >> > >> > To put it simply: This draft describes a scenario where public v4 addresses >> > are available. The "classic" v6 migration scenario is in this case "dual >> > stack" and is what I believe has been advised for years by the IETF, and >> > continues to be the recommended approach. Why would one want to run in this >> > case dual-stack over a tunnel infra is the question? Is this intended as an >> > academic draft (as in "we can do it, but don't know why")? > [Peng] That's not always the case. Now to be more precise, with pb 4over6 > 1.Concentrator can be in a high position, and we don't have to IPv4 every > where > 2.Provision IPv4 in a flexible, on-demand way > 3.It can be deployed along with DS-lite to provide a value-added service > These points are already written in the draft > >>> >> >>>> >> > a) it it requires changes to DHCPv4 processing b) it introduces non >>>> >> > trivial >>>> >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires >>>> >> > changes to >>>> >> > CPE d) makes life really a mess if we consider a real dual stack CPE. >>> >> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >>> >> essential changes to protocol processing. >> > >> > >> > Woj> That's not what the draft DHCPv4overv6 indicates, unless one assumes a >> > very specific and limiting deployment scenario. In any case it's quite >> clear >> > that it is not possible to use regular DHCPv4 clients for this, or a >> regular >> > DHCPv4 server (there is no mention of how the broadcast flags should be >> > handled, mapped to IPv6, etc). > [Peng]Actually we can use regular DHCPv4 client, with the help of a > CRA function planted on the same host, that's a very fundamental point > of the DHCPv4over6v6 draft. > Server side need modification, yes. But only on the step of > sending/receiving DHCP messages (sockets). That's what I wanted to > express in last mail. > FYI, it only uses IPv6 unicast, with the aid of CRA. > >>> >> >>> >> b) What really matters here is provisioning the IPv4 address through >>> >> DHCPv4. Just like in MAP/4rd, you provision the address through >>> >> DHCPv6. >>> >> In pb4over6 DHCPv6 is only an *option* to provide the concentrator >>> >> address. You have similar logic too in MAP. >>> >> So I don't think it's "non trivial dependancy". They are similar >>> >> functions for all IPv4-over-IPv6 mechanisms that need provisioning, >>> >> only different technical paths. >> > >> > >> > There are several components/parts that all need to play together in this >> > solution, many more than apparently required, and the failure of one is not >> > obvious to anyone looking at another. As in any such multi-part system >> > design, the overall complexity is higher. > Sorry but I simply don't buy that it's *significant* more complexity. > As to failure, it's more like a sequencial rather than " the failure > of one is not obvious to anyone looking at another". If I cannot get > the concentrator or the DHCPv4 server address, I stop the rest steps. > > >>> >> >>> >> c) Any IPv4-over-IPv6 mechanism requires change to CPE >> > >> > >> > Yes, but in the case of this draft, the changes that are proposed do not >> > lead to anything over and above what plain dual stack accomplishes, except >> > extra complexity. > See above > > Cheers~ --B_3422559083_1021910 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Woj,

=
Let me try to answer some of your questions:

From: Wojciech Dec <wdec.ietf@gmail.com>
= Date: Thursday, June 14, 2012 9:07 AM
To: Peng Wu <pengwu.thu= @gmail.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Softwires] WG last call on draft-ietf-softwi= re-public-4over6-01

Peng,

your answers do not address the key concerns:
- Why is this needed, besides that it can be done, as opposed to classic du= al stack?

[YL]  The scenario is a= ddressing IPv6-only access network. If the access network is DS, yes, you do= n't need this technology.
- It requires changes to the client/relay, thus it cannot be simply used wi= th regular DHCPv4 implementations (note: it doesn't matter that you're putti= ng a CRA element, that's an implementation detail). It is thus invesement in= legacy IPv4 technology, not migration to IPv6.

[YL] AFAIK, the client won'= t change but will require CRA. This technology is to support legacy v4 servi= ce while migrating to IPv6. The client will have both v4 and v6 addresses. T= his is given. So I fail to see why this is only an investment in legacy IPv4= technology.

- It is more complicated to get through failures, to anyone who looks at it= all objectively (Basic example: A dhcpv4 user will have no idea that the fa= ilure to get an ipv4 address is because in the CRA/whatever-stuff-is-combble= d-to-make-this-work DNSv6 is returning a wrong AAAA for some host name that happens to be a dhcpv4 server, or bec= ause dhcpv6 is not providing the right option or name).

[YL] I am sorry, I can't follow this. Can you explain more= please?

- DHCPv4 servers need to be modified to take into account IPv6.
=

[YL] Yes or we need to deploy TRA.

=
Thanks,
Yiu
<= div>
-Woj.


On 13 June 2012 06:36, Peng Wu <peng= wu.thu@gmail.com> wrote:
Woj,

On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Peng,
>
> On 11 June 2012 20:38, Peng Wu <pengwu.thu@gmail.com> wrote:
>>
>> Woj,
>>
>> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> > There is basic question regarding this draft, one that has al= so been
>> > raised
>> > at previous WG meetings: "why is it needed?".
>> It's actually written in section 4 of the draft.
>>
>> > There is a deeper issue here: This draft seems to give the im= pression
>> > that
>> > running such a regular public addressed DHCPv4 based overlay = on IPv6 is
>> > a
>> > simple idea, as opposed to native dual stack. It is anything = but, given
>> > that
>> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, simil= ar
>> to scenario of DS-Lite and MAP/4rd.
>> I thought the assumption of IPv4-over-IPv6 is that you cannot/do n= ot
>> want to provision native dual-stack?
>
>
> To put it simply: This draft describes a scenario where public v4 addr= esses
> are available. The "classic" v6 migration scenario is in this case "du= al
> stack" and is what I believe has been advised for years by the IETF, a= nd
> continues to be the recommended approach. Why would one want to run in= this
> case dual-stack over a tunnel infra is the question? Is this intended = as an
> academic draft (as in "we can do it, but don't know why")?
[Peng] That's not always the case. Now to be more precise, with pb 4over6 1.Concentrator can be in a high position, and we don't have to IPv4 every w= here
2.Provision IPv4 in a flexible, on-demand way
3.It can be deployed along with DS-lite to provide a value-added service These points are already written in the draft

>>
>> > a) it it requires changes to DHCPv4 processing b) it introduc= es non
>> > trivial
>> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requ= ires
>> > changes to
>> > CPE d) makes life really a mess if we consider a real dual st= ack CPE.
>> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >> essential changes to protocol processing.
>
>
> Woj> That's not what the draft DHCPv4overv6 indicates, unless one a= ssumes a
> very specific and limiting deployment scenario. In any case it's quite= clear
> that it is not possible to use regular DHCPv4 clients for this, or a r= egular
> DHCPv4 server (there is no mention of how the broadcast flags should b= e
> handled, mapped to IPv6, etc).
[Peng]Actually we can use regular DHCPv4 client, with the help of a
CRA function planted on the same host, that's a very fundamental point
of the DHCPv4over6v6 draft.
Server side need modification, yes. But only on the step of
sending/receiving DHCP messages (sockets). That's what I wanted to
express in last mail.
FYI, it only uses IPv6 unicast, with the aid of CRA.
>>
>> b) What really matters here is provisioning the IPv4 address throu= gh
>> DHCPv4. Just like in MAP/4rd, you provision the address through >> DHCPv6.
>> In pb4over6 DHCPv6 is only an *option* to provide the concentrator=
>> address. You have similar logic too in MAP.
>> So I don't think it's "non trivial dependancy". They are similar >> functions for all IPv4-over-IPv6 mechanisms that need provisioning= ,
>> only different technical paths.
>
>
> There are several components/parts that all need to play together in t= his
> solution, many more than apparently required, and the failure of one i= s not
> obvious to anyone looking at another. As in any such multi-part system=
> design, the overall complexity is higher.
Sorry but I simply don't buy that it's *significant* more complexity.
As to failure, it's more like a sequencial rather than " the failure
of one is not obvious to anyone looking at another". If I cannot get
the concentrator or the DHCPv4 server address, I stop the rest steps.


>>
>> c) Any IPv4-over-IPv6 mechanism requires change to CPE
>
>
> Yes, but in the case of this draft, the changes that are proposed do n= ot
> lead to anything over and above what plain dual stack accomplishes, ex= cept
> extra complexity.
See above

Cheers~

 --B_3422559083_1021910-- --B_3422559084_988468 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSwSNyc FetTxp6MxImNxFGtw+T28jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MTUwMjUxMjNaMA0GCSqGSIb3DQEBAQUABIIBAA+qbAfNhDWJbtn0JTNYqdGE mbON81ypk2SC0SsfGR+zyfqidRQykGeI1ehSURvhBa+aSpggc3SPB6C3G4FOEax64vkQC9rq c9VCycyP3T7XU+Wt/YowY4+ubSjYj9xOq/hpf9PG1RsqCVl+BmWCftu9H//JFS8XjremGH6v Fm7uhfwn7jL3kitdAat3Yyn7h70zh3ZsbaNaC9Lb3wm6NM0NNAd9lZdtPe/aAECIOaZmuR7e Zae0tkYVx7DqQbC4gpaeGWV2ylUIFSWHlZcXuwfoWsOGPNZj+gyRbFg/IoW51/Dh+ul9j1hP US17QCfPh9kTPnhJi6Y6TeKZvGvWPy8= --B_3422559084_988468-- From internet-drafts@ietf.org Thu Jun 14 22:34: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 2ADBF21F85E7; Thu, 14 Jun 2012 22:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMSK-p2pR2Bf; Thu, 14 Jun 2012 22:34:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7518F21F85C6; Thu, 14 Jun 2012 22:34:20 -0700 (PDT) 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.20 Message-ID: <20120615053420.21282.23952.idtracker@ietfa.amsl.com> Date: Thu, 14 Jun 2012 22:34:20 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-03.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, 15 Jun 2012 05:34:21 -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-03.txt Pages : 16 Date : 2012-06-14 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-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateless-4v6-moti= vation-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Thu Jun 14 22:38: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 CB02C21F860F for ; Thu, 14 Jun 2012 22:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WieNQzyrPoCf for ; Thu, 14 Jun 2012 22:38:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E7A2421F85E6 for ; Thu, 14 Jun 2012 22:38:33 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 3F3A63B4816 for ; Fri, 15 Jun 2012 07:38:32 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 24E4F4C017 for ; Fri, 15 Jun 2012 07:38:32 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 15 Jun 2012 07:38:31 +0200 From: To: "softwires@ietf.org" Date: Fri, 15 Jun 2012 07:38:30 +0200 Thread-Topic: I-D Action: draft-ietf-softwire-stateless-4v6-motivation-03.txt Thread-Index: Ac1KuJWQDVie4kr5S1K1LNeWak7dkQAAEcWA Message-ID: <94C682931C08B048B7A8645303FDC9F36E332DF793@PUEXCB1B.nanterre.francetelecom.fr> References: <20120615053420.21282.23952.idtracker@ietfa.amsl.com> In-Reply-To: <20120615053420.21282.23952.idtracker@ietfa.amsl.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.5.24.112414 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-03.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, 15 Jun 2012 05:38:34 -0000 Dear all, I updated the text with the sentence proposed by Gang and agreed by Dapeng.= =20 Cheers, Med >-----Message d'origine----- >De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] De la part de=20 >internet-drafts@ietf.org >Envoy=E9 : vendredi 15 juin 2012 07:34 >=C0 : i-d-announce@ietf.org >Cc : softwires@ietf.org >Objet : I-D Action: draft-ietf-softwire-stateless-4v6-motivation-03.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Motivations for Carrier-side=20 >Stateless IPv4 over IPv6 Migration Solutions > Author(s) : Mohamed Boucadair > Satoru Matsushima > Yiu Lee > Olaf Bonness > Isabel Borges > Gang Chen > Filename :=20 >draft-ietf-softwire-stateless-4v6-motivation-03.txt > Pages : 16 > Date : 2012-06-14 > >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-motivation > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-mo >tivation-03 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-stateles >s-4v6-motivation-03 > > >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 Jun 15 03:42: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 AF15021F85C2 for ; Fri, 15 Jun 2012 03:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCvjf7Iv-bus for ; Fri, 15 Jun 2012 03:42:39 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7A21F85C0 for ; Fri, 15 Jun 2012 03:42:38 -0700 (PDT) Received: by qafl39 with SMTP id l39so351063qaf.2 for ; Fri, 15 Jun 2012 03:42:38 -0700 (PDT) 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=MdppJcKquMz4uS6PdST243loberG9iZVMFS0kYTo1to=; b=OEcsgUYcfSdlyX396FZeyin60MU4ibaHb5ZO1B2qzTtyRBcwk17xp7nFnJOvMgItc2 ZYfImUZJaRWDotLDgoK38aFXDWM2cvxUtur//Im1IAH++RAeTYzAxz55dcB9Q1Adr1cD cyVbij239krZbT0QrP2wqdhq9kcIpHGVP7XIamaHrBj5ws2TRkQ0CX0tBXX6N7w3e+GC Zcdgjm8KwsBcqBOYVIcGDqMHj6jn3Zx7CfUPDnHFNGvUFCieJXu9OD0Gruuk/HpiAulF HMCneLeCN24dZJtNDF4kMUOIVJjwi3B0y5lN0372knGHk6rF3jGx372LWZZ7xAw7euei RjBA== MIME-Version: 1.0 Received: by 10.224.179.18 with SMTP id bo18mr10187805qab.93.1339756958077; Fri, 15 Jun 2012 03:42:38 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Fri, 15 Jun 2012 03:42:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 12:42:37 +0200 Message-ID: From: Wojciech Dec To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=20cf302ef92292517e04c2807919 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 15 Jun 2012 10:42:40 -0000 --20cf302ef92292517e04c2807919 Content-Type: text/plain; charset=ISO-8859-1 Lee, On 15 June 2012 04:51, Lee, Yiu wrote: > Hi Woj, > > Let me try to answer some of your questions: > > From: Wojciech Dec > Date: Thursday, June 14, 2012 9:07 AM > To: Peng Wu > Cc: "softwires@ietf.org" , Yong Cui < > cuiyong@tsinghua.edu.cn> > > Subject: Re: [Softwires] WG last call on > draft-ietf-softwire-public-4over6-01 > > Peng, > > your answers do not address the key concerns: > - Why is this needed, besides that it can be done, as opposed to classic > dual stack? > > [YL] The scenario is addressing IPv6-only access network. If the access > network is DS, yes, you don't need this technology. > Woj> This draft proposes using public IPv4 addressing to deliver a dual stack service to the end-user. Even on a future IPv6-only network, in the selective cases where such a dual stack service is to be offered, using existing IPv4 functionality, one that all operators use today, that is mature, and requires NO client or server or relay changes, is way simpler than investing in new intricate functionality. I see this scheme directly leading into changing this scenario to one of IPv4 address sharing, which brings this work into direct overlap with other work in softwires. As such I can only re-iterate what I said before; IMO we need a thorough review of this solution space, including this draft, before progressing. > - It requires changes to the client/relay, thus it cannot be simply used > with regular DHCPv4 implementations (note: it doesn't matter that you're > putting a CRA element, that's an implementation detail). It is thus > invesement in legacy IPv4 technology, not migration to IPv6. > > [YL] AFAIK, the client won't change but will require CRA. This technology > is to support legacy v4 service while migrating to IPv6. The client will > have both v4 and v6 addresses. This is given. So I fail to see why this is > only an investment in legacy IPv4 technology. > Woj> The fact that there is a CRA means a client change, or a CPE change. The fact that you call it CRA, and not DHCP-client change, even though this function is specific to DHCPv4, does not change that fact. > > - It is more complicated to get through failures, to anyone who looks at > it all objectively (Basic example: A dhcpv4 user will have no idea that the > failure to get an ipv4 address is because in the > CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a wrong > AAAA for some host name that happens to be a dhcpv4 server, or because > dhcpv6 is not providing the right option or name). > > [YL] I am sorry, I can't follow this. Can you explain more please? > Woj> The sequence of events leading to a client acquiring a v4 address is complex and not intuitive to anyone who deals with DHCPv4. There are numerous points at which the whole thing could fail even before dhcpv4. -Woj. > - DHCPv4 servers need to be modified to take into account IPv6. > > [YL] Yes or we need to deploy TRA. > > Thanks, > Yiu > > -Woj. > > > On 13 June 2012 06:36, Peng Wu wrote: > >> Woj, >> >> On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec >> wrote: >> > Peng, >> > >> > On 11 June 2012 20:38, Peng Wu wrote: >> >> >> >> Woj, >> >> >> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec >> wrote: >> >> > There is basic question regarding this draft, one that has also been >> >> > raised >> >> > at previous WG meetings: "why is it needed?". >> >> It's actually written in section 4 of the draft. >> >> >> >> > There is a deeper issue here: This draft seems to give the impression >> >> > that >> >> > running such a regular public addressed DHCPv4 based overlay on IPv6 >> is >> >> > a >> >> > simple idea, as opposed to native dual stack. It is anything but, >> given >> >> > that >> >> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar >> >> to scenario of DS-Lite and MAP/4rd. >> >> I thought the assumption of IPv4-over-IPv6 is that you cannot/do not >> >> want to provision native dual-stack? >> > >> > >> > To put it simply: This draft describes a scenario where public v4 >> addresses >> > are available. The "classic" v6 migration scenario is in this case "dual >> > stack" and is what I believe has been advised for years by the IETF, and >> > continues to be the recommended approach. Why would one want to run in >> this >> > case dual-stack over a tunnel infra is the question? Is this intended >> as an >> > academic draft (as in "we can do it, but don't know why")? >> [Peng] That's not always the case. Now to be more precise, with pb 4over6 >> 1.Concentrator can be in a high position, and we don't have to IPv4 every >> where >> 2.Provision IPv4 in a flexible, on-demand way >> 3.It can be deployed along with DS-lite to provide a value-added service >> These points are already written in the draft >> >> >> >> >> > a) it it requires changes to DHCPv4 processing b) it introduces non >> >> > trivial >> >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires >> >> > changes to >> >> > CPE d) makes life really a mess if we consider a real dual stack CPE. >> >> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >> >> essential changes to protocol processing. >> > >> > >> > Woj> That's not what the draft DHCPv4overv6 indicates, unless one >> assumes a >> > very specific and limiting deployment scenario. In any case it's quite >> clear >> > that it is not possible to use regular DHCPv4 clients for this, or a >> regular >> > DHCPv4 server (there is no mention of how the broadcast flags should be >> > handled, mapped to IPv6, etc). >> [Peng]Actually we can use regular DHCPv4 client, with the help of a >> CRA function planted on the same host, that's a very fundamental point >> of the DHCPv4over6v6 draft. >> Server side need modification, yes. But only on the step of >> sending/receiving DHCP messages (sockets). That's what I wanted to >> express in last mail. >> FYI, it only uses IPv6 unicast, with the aid of CRA. >> >> >> >> >> b) What really matters here is provisioning the IPv4 address through >> >> DHCPv4. Just like in MAP/4rd, you provision the address through >> >> DHCPv6. >> >> In pb4over6 DHCPv6 is only an *option* to provide the concentrator >> >> address. You have similar logic too in MAP. >> >> So I don't think it's "non trivial dependancy". They are similar >> >> functions for all IPv4-over-IPv6 mechanisms that need provisioning, >> >> only different technical paths. >> > >> > >> > There are several components/parts that all need to play together in >> this >> > solution, many more than apparently required, and the failure of one is >> not >> > obvious to anyone looking at another. As in any such multi-part system >> > design, the overall complexity is higher. >> Sorry but I simply don't buy that it's *significant* more complexity. >> As to failure, it's more like a sequencial rather than " the failure >> of one is not obvious to anyone looking at another". If I cannot get >> the concentrator or the DHCPv4 server address, I stop the rest steps. >> >> >> >> >> >> c) Any IPv4-over-IPv6 mechanism requires change to CPE >> > >> > >> > Yes, but in the case of this draft, the changes that are proposed do not >> > lead to anything over and above what plain dual stack accomplishes, >> except >> > extra complexity. >> See above >> >> Cheers~ >> > > --20cf302ef92292517e04c2807919 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lee,

On 15 June 2012 04:51, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Hi Woj,

Let me try to answer some of y= our questions:

From: Wojciech Dec <wdec.ietf@gmail.com>Date: Thursday, June 14, 2012 9:= 07 AM
To: Peng Wu <pengwu.thu@gmail.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>, Yong= Cui <cuiyo= ng@tsinghua.edu.cn>

Subject: Re: [Softwires] WG la= st call on draft-ietf-softwire-public-4over6-01

Peng,

your answers do not address the key concerns:
- Why is this needed, besides that it can be done, as opposed to classic du= al stack?

[YL] =A0The scenario = is addressing IPv6-only access network. If the access network is DS, yes, y= ou don't need this technology.

Woj> This draft proposes using public IPv4 a= ddressing to deliver a dual stack service to the end-user. Even on a future= IPv6-only network, in the selective cases where such a dual stack service = is to be offered, using existing IPv4 functionality, one that all operators= use today, that is mature, and requires NO client or server or relay chang= es, is way simpler than investing in new intricate functionality.
I see this scheme directly leading into changing this scenario to one of IP= v4 address sharing, which brings this work into direct overlap with other w= ork in softwires.
As such I can only re-iterate what I said before; IMO= we need a thorough review of this solution space, including this draft, be= fore progressing.


- It requires changes to the client/relay, thus it cannot be simply used wi= th regular DHCPv4 implementations (note: it doesn't matter that you'= ;re putting a CRA element, that's an implementation detail). It is thus= invesement in legacy IPv4 technology, not migration to IPv6.

[YL] AFAIK, the clien= t won't change but will require CRA. This technology is to support lega= cy v4 service while migrating to IPv6. The client will have both v4 and v6 = addresses. This is given. So I fail to see why this is only an investment i= n legacy IPv4 technology.

Woj> The fact that there is a CRA means a cl= ient change, or a CPE change. The fact that you call it CRA, and not DHCP-c= lient change, even though this function is specific to DHCPv4, does not cha= nge that fact.

- It is more complicated to get through failures, to anyone who looks at it= all objectively (Basic example: A dhcpv4 user will have no idea that the f= ailure to get an ipv4 address is because in the CRA/whatever-stuff-is-combb= led-to-make-this-work DNSv6 is returning a wrong AAAA for some host name that happens to be a dhcpv4 server, or bec= ause dhcpv6 is not providing the right option or name).
<= div>
[YL] I am sorry, I can't follow this. Can you = explain more please?

Woj> The sequence of events leading to a cli= ent acquiring a v4 address is complex and not intuitive to anyone who deals= with DHCPv4. There are numerous points at which the whole thing could fail= even before dhcpv4.

-Woj.



- DHCPv4 servers need to be modified to take into account IPv6.
=

[YL] Yes or we need to deploy TRA.

Thanks,
Yiu
<= div>

-Woj.


On 13 June 2012 06:36, Peng Wu = <pengwu.thu@gmail.com> wrote:
Woj,

On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Peng,
>
> On 11 June 2012 20:38, Peng Wu <pengwu.thu@gmail.com> wrote:
>>
>> Woj,
>>
>> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:=
>> > There is basic question regarding this draft, one that has al= so been
>> > raised
>> > at previous WG meetings: "why is it needed?".
>> It's actually written in section 4 of the draft.
>>
>> > There is a deeper issue here: This draft seems to give the im= pression
>> > that
>> > running such a regular public addressed DHCPv4 based overlay = on IPv6 is
>> > a
>> > simple idea, as opposed to native dual stack. It is anything = but, given
>> > that
>> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, s= imilar
>> to scenario of DS-Lite and MAP/4rd.
>> I thought the assumption of IPv4-over-IPv6 is that you cannot/do n= ot
>> want to provision native dual-stack?
>
>
> To put it simply: This draft describes a scenario where public v4 addr= esses
> are available. The "classic" v6 migration scenario is in thi= s case "dual
> stack" and is what I believe has been advised for years by the IE= TF, and
> continues to be the recommended approach. Why would one want to run in= this
> case dual-stack over a tunnel infra is the question? Is this intended = as an
> academic draft (as in "we can do it, but don't know why"= )?
[Peng] That's not always the case. Now to be more precise, with pb 4ove= r6
1.Concentrator can be in a high position, and we don't have to IPv4 eve= ry where
2.Provision IPv4 in a flexible, on-demand way
3.It can be deployed along with DS-lite to provide a value-added service These points are already written in the draft

>>
>> > a) it it requires changes to DHCPv4 processing b) it introduc= es non
>> > trivial
>> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requ= ires
>> > changes to
>> > CPE d) makes life really a mess if we consider a real dual st= ack CPE.
>> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >> essential changes to protocol processing.
>
>
> Woj> That's not what the draft DHCPv4overv6 indicates, unless o= ne assumes a
> very specific and limiting deployment scenario. In any case it's q= uite clear
> that it is not possible to use regular DHCPv4 clients for this, or a r= egular
> DHCPv4 server (there is no mention of how the broadcast flags should b= e
> handled, mapped to IPv6, etc).
[Peng]Actually we can use regular DHCPv4 client, with the help of a
CRA function planted on the same host, that's a very fundamental point<= br> of the DHCPv4over6v6 draft.
Server side need modification, yes. But only on the step of
sending/receiving DHCP messages (sockets). That's what I wanted to
express in last mail.
FYI, it only uses IPv6 unicast, with the aid of CRA.

>>
>> b) What really matters here is provisioning the IPv4 address throu= gh
>> DHCPv4. Just like in MAP/4rd, you provision the address through >> DHCPv6.
>> In pb4over6 DHCPv6 is only an *option* to provide the concentrator=
>> address. You have similar logic too in MAP.
>> So I don't think it's "non trivial dependancy". = They are similar
>> functions for all IPv4-over-IPv6 mechanisms that need provisioning= ,
>> only different technical paths.
>
>
> There are several components/parts that all need to play together in t= his
> solution, many more than apparently required, and the failure of one i= s not
> obvious to anyone looking at another. As in any such multi-part system=
> design, the overall complexity is higher.
Sorry but I simply don't buy that it's *significant* more complexit= y.
As to failure, it's more like a sequencial rather than " the failu= re
of one is not obvious to anyone looking at another". If I cannot get the concentrator or the DHCPv4 server address, I stop the rest steps.


>>
>> c) Any IPv4-over-IPv6 mechanism requires change to CPE
>
>
> Yes, but in the case of this draft, the changes that are proposed do n= ot
> lead to anything over and above what plain dual stack accomplishes, ex= cept
> extra complexity.
See above

Cheers~


--20cf302ef92292517e04c2807919-- From sunqi.csnet.thu@gmail.com Sat Jun 16 00:17:32 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 0BBC411E8098 for ; Sat, 16 Jun 2012 00:17:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdfFdoH8UkXQ for ; Sat, 16 Jun 2012 00:17:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAA521F84A1 for ; Sat, 16 Jun 2012 00:17:30 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6197668pbc.31 for ; Sat, 16 Jun 2012 00:17:30 -0700 (PDT) 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=ygWDvA9WDlDviAHHm0Nnh3+XZ8QJnN8QsP/9XJKpYpk=; b=vxl9xSXu/TvAjHOw8rhUgPpbrW/FZ2lbxhHjDgVCsr0xggmlcBg4UWgL6+3xawqp8e da5G55NISOQ0DLBMy8z1iESYffXHdkGCnPVAMG9HC7iueqBG/bN6KD6Ohd+WT/Bcd6Ue /emjPH7Hs75Scfe2LjnDTRMIzDWg3hY3CnjXEg842A5t8bXH09FmyYG0MG+eobnf13ck 2MNezD8MgxUxCrkOia6qyHDdz5rbNuPRCxfCAJ+apygII9kuAVO0aFqm6GpTokO3v3fq rZ4vUDVpFCyxJzMQjVatqyslIdWMFHdzKfmfc750ZNU8maelvNoW1Sq4YUYdwVPJ1+Uk yQfw== MIME-Version: 1.0 Received: by 10.68.225.6 with SMTP id rg6mr28528889pbc.100.1339831049848; Sat, 16 Jun 2012 00:17:29 -0700 (PDT) Received: by 10.142.105.1 with HTTP; Sat, 16 Jun 2012 00:17:29 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Jun 2012 15:17:29 +0800 Message-ID: From: Qi Sun To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7b2ee27bc9062e04c291b9b4 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 16 Jun 2012 07:17:32 -0000 --047d7b2ee27bc9062e04c291b9b4 Content-Type: text/plain; charset=ISO-8859-1 Hi Woj, Please see inline. On Fri, Jun 15, 2012 at 6:42 PM, Wojciech Dec wrote: > Lee, > > On 15 June 2012 04:51, Lee, Yiu wrote: > >> Hi Woj, >> >> Let me try to answer some of your questions: >> >> From: Wojciech Dec >> Date: Thursday, June 14, 2012 9:07 AM >> To: Peng Wu >> Cc: "softwires@ietf.org" , Yong Cui < >> cuiyong@tsinghua.edu.cn> >> >> Subject: Re: [Softwires] WG last call on >> draft-ietf-softwire-public-4over6-01 >> >> Peng, >> >> your answers do not address the key concerns: >> - Why is this needed, besides that it can be done, as opposed to classic >> dual stack? >> >> [YL] The scenario is addressing IPv6-only access network. If the access >> network is DS, yes, you don't need this technology. >> > > Woj> This draft proposes using public IPv4 addressing to deliver a dual > stack service to the end-user. Even on a future IPv6-only network, in the > selective cases where such a dual stack service is to be offered, using > existing IPv4 functionality, one that all operators use today, that is > mature, and requires NO client or server or relay changes, is way simpler > than investing in new intricate functionality. > [Qi]Because it is difficult for the operators to deploy native dual stack in such a short period when the IPv4 address resource is running out, here comes stateful mechanisms DS-lite and pb4over6 to solve the transition problems, with/without CGN on the AFTR/concentrator. IMHO, they do not compete with native dual stack for the reason above. > I see this scheme directly leading into changing this scenario to one of > IPv4 address sharing, which brings this work into direct overlap with other > work in softwires. > [Qi] Pb4over6 is a stateful mechanism without CGN. It's different from other work. As such I can only re-iterate what I said before; IMO we need a thorough > review of this solution space, including this draft, before progressing. > > [Qi] IMO we should progress the draft, instead of blocking the IPv4/IPv6 transition progress. > >> - It requires changes to the client/relay, thus it cannot be simply used >> with regular DHCPv4 implementations (note: it doesn't matter that you're >> putting a CRA element, that's an implementation detail). It is thus >> invesement in legacy IPv4 technology, not migration to IPv6. >> >> [YL] AFAIK, the client won't change but will require CRA. This technology >> is to support legacy v4 service while migrating to IPv6. The client will >> have both v4 and v6 addresses. This is given. So I fail to see why this is >> only an investment in legacy IPv4 technology. >> > > Woj> The fact that there is a CRA means a client change, or a CPE change. > The fact that you call it CRA, and not DHCP-client change, even though this > function is specific to DHCPv4, does not change that fact. > >> >> [Qi] CRA is short for Client Relay Agent. AFAIK, we don't take DHCP relay agent as a change to DHCP server, but a separate part. So I'm not sure if it's proper to call CRA a client change. > - It is more complicated to get through failures, to anyone who looks at >> it all objectively (Basic example: A dhcpv4 user will have no idea that the >> failure to get an ipv4 address is because in the >> CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a wrong >> AAAA for some host name that happens to be a dhcpv4 server, or because >> dhcpv6 is not providing the right option or name). >> >> [YL] I am sorry, I can't follow this. Can you explain more please? >> > > Woj> The sequence of events leading to a client acquiring a v4 address is > complex and not intuitive to anyone who deals with DHCPv4. There are > numerous points at which the whole thing could fail even before dhcpv4. > [Qi] I think you ignored a fact that the DHCPv4 server is likely to be collocated with the concentrator, as Peng stated before. IMHO , in MAP, you put many kinds of information in one DHCPv6 option. The client and CPE need to be modified to pick out what they need. And there are some other process to make the mechanism work. I think it is not simpler than pb4over6. > > -Woj. > > > >> >> - DHCPv4 servers need to be modified to take into account IPv6. >> > >> [YL] Yes or we need to deploy TRA. >> >> Thanks, >> Yiu >> >> -Woj. >> >> >> On 13 June 2012 06:36, Peng Wu wrote: >> >>> Woj, >>> >>> On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec >>> wrote: >>> > Peng, >>> > >>> > On 11 June 2012 20:38, Peng Wu wrote: >>> >> >>> >> Woj, >>> >> >>> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec >>> wrote: >>> >> > There is basic question regarding this draft, one that has also been >>> >> > raised >>> >> > at previous WG meetings: "why is it needed?". >>> >> It's actually written in section 4 of the draft. >>> >> >>> >> > There is a deeper issue here: This draft seems to give the >>> impression >>> >> > that >>> >> > running such a regular public addressed DHCPv4 based overlay on >>> IPv6 is >>> >> > a >>> >> > simple idea, as opposed to native dual stack. It is anything but, >>> given >>> >> > that >>> >> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar >>> >> to scenario of DS-Lite and MAP/4rd. >>> >> I thought the assumption of IPv4-over-IPv6 is that you cannot/do not >>> >> want to provision native dual-stack? >>> > >>> > >>> > To put it simply: This draft describes a scenario where public v4 >>> addresses >>> > are available. The "classic" v6 migration scenario is in this case >>> "dual >>> > stack" and is what I believe has been advised for years by the IETF, >>> and >>> > continues to be the recommended approach. Why would one want to run in >>> this >>> > case dual-stack over a tunnel infra is the question? Is this intended >>> as an >>> > academic draft (as in "we can do it, but don't know why")? >>> [Peng] That's not always the case. Now to be more precise, with pb 4over6 >>> 1.Concentrator can be in a high position, and we don't have to IPv4 >>> every where >>> 2.Provision IPv4 in a flexible, on-demand way >>> 3.It can be deployed along with DS-lite to provide a value-added service >>> These points are already written in the draft >>> >>> >> >>> >> > a) it it requires changes to DHCPv4 processing b) it introduces non >>> >> > trivial >>> >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires >>> >> > changes to >>> >> > CPE d) makes life really a mess if we consider a real dual stack >>> CPE. >>> >> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >>> >> essential changes to protocol processing. >>> > >>> > >>> > Woj> That's not what the draft DHCPv4overv6 indicates, unless one >>> assumes a >>> > very specific and limiting deployment scenario. In any case it's quite >>> clear >>> > that it is not possible to use regular DHCPv4 clients for this, or a >>> regular >>> > DHCPv4 server (there is no mention of how the broadcast flags should be >>> > handled, mapped to IPv6, etc). >>> [Peng]Actually we can use regular DHCPv4 client, with the help of a >>> CRA function planted on the same host, that's a very fundamental point >>> of the DHCPv4over6v6 draft. >>> Server side need modification, yes. But only on the step of >>> sending/receiving DHCP messages (sockets). That's what I wanted to >>> express in last mail. >>> FYI, it only uses IPv6 unicast, with the aid of CRA. >>> >>> >> >>> >> b) What really matters here is provisioning the IPv4 address through >>> >> DHCPv4. Just like in MAP/4rd, you provision the address through >>> >> DHCPv6. >>> >> In pb4over6 DHCPv6 is only an *option* to provide the concentrator >>> >> address. You have similar logic too in MAP. >>> >> So I don't think it's "non trivial dependancy". They are similar >>> >> functions for all IPv4-over-IPv6 mechanisms that need provisioning, >>> >> only different technical paths. >>> > >>> > >>> > There are several components/parts that all need to play together in >>> this >>> > solution, many more than apparently required, and the failure of one >>> is not >>> > obvious to anyone looking at another. As in any such multi-part system >>> > design, the overall complexity is higher. >>> Sorry but I simply don't buy that it's *significant* more complexity. >>> As to failure, it's more like a sequencial rather than " the failure >>> of one is not obvious to anyone looking at another". If I cannot get >>> the concentrator or the DHCPv4 server address, I stop the rest steps. >>> >>> >>> >> >>> >> c) Any IPv4-over-IPv6 mechanism requires change to CPE >>> > >>> > >>> > Yes, but in the case of this draft, the changes that are proposed do >>> not >>> > lead to anything over and above what plain dual stack accomplishes, >>> except >>> > extra complexity. >>> See above >>> >>> Cheers~ >>> >> >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --047d7b2ee27bc9062e04c291b9b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Woj,

=A0 =A0 =A0Please see inline.

On Fri, Jun 15, 2012 at 6:42 PM, Wojciech Dec <wdec.iet= f@gmail.com> wrote:
Lee,

= On 15 June 2012 04:51, Lee, Yiu <Yiu_Lee@cable.comcast.com>= wrote:
Hi Woj,

Let me try to answer some of y= our questions:

From: Wojciech Dec <wdec.ietf@gmail.com>Date: Thursday, June 14, 2012 9:= 07 AM
To: Peng Wu <pengwu.thu@gmail.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>, Yong= Cui <cuiyo= ng@tsinghua.edu.cn>

Subject: Re: [Softwires] WG la= st call on draft-ietf-softwire-public-4over6-01
Peng,

your answers do not address the key concerns:
- Why is this needed, besides that it can be done, as opposed to classic du= al stack?

[YL] =A0The scenario = is addressing IPv6-only access network. If the access network is DS, yes, y= ou don't need this technology.

Woj> This draft proposes using public = IPv4 addressing to deliver a dual stack service to the end-user. Even on a = future IPv6-only network, in the selective cases where such a dual stack se= rvice is to be offered, using existing IPv4 functionality, one that all ope= rators use today, that is mature, and requires NO client or server or relay= changes, is way simpler than investing in new intricate functionality.

[Qi]Because it is difficult fo= r the operators to deploy native dual stack in such a short period when the= IPv4 address resource is running out, here comes stateful mechanisms DS-li= te and pb4over6 to solve the transition problems, with/without CGN on the A= FTR/concentrator. IMHO, they do not compete with native dual stack for the = reason above.
=A0
I see this scheme directly leading into changing this scenario to one of IP= v4 address sharing, which brings this work into direct overlap with other w= ork in softwires.

[Qi] Pb4= over6 is a stateful mechanism without CGN. It's different from other wo= rk.

As such I can only re-iterate what I said before; IMO we need a thorough= review of this solution space, including this draft, before progressing. <= br>
[Qi] IMO we should progress the draft, in= stead of blocking the IPv4/IPv6 transition progress.
=A0

- It requires changes to the client/relay, thus it cannot be simply used wi= th regular DHCPv4 implementations (note: it doesn't matter that you'= ;re putting a CRA element, that's an implementation detail). It is thus= invesement in legacy IPv4 technology, not migration to IPv6.

[YL] AFAIK, the clien= t won't change but will require CRA. This technology is to support lega= cy v4 service while migrating to IPv6. The client will have both v4 and v6 = addresses. This is given. So I fail to see why this is only an investment i= n legacy IPv4 technology.

Woj> The fact that there is a CRA mean= s a client change, or a CPE change. The fact that you call it CRA, and not = DHCP-client change, even though this function is specific to DHCPv4, does n= ot change that fact.

[Qi] CRA is short for Client Relay Agent. AFAIK, we don&= #39;t take DHCP relay agent as a change to DHCP server, but a separate part= . So I'm not sure if it's proper to call CRA a client change.
=A0
- It is more complicated to get through failures, to anyone who looks at it= all objectively (Basic example: A dhcpv4 user will have no idea that the f= ailure to get an ipv4 address is because in the CRA/whatever-stuff-is-combb= led-to-make-this-work DNSv6 is returning a wrong AAAA for some host name that happens to be a dhcpv4 server, or bec= ause dhcpv6 is not providing the right option or name).
<= div>
[YL] I am sorry, I can't follow this. Can you = explain more please?

Woj> The sequence of events leading to= a client acquiring a v4 address is complex and not intuitive to anyone who= deals with DHCPv4. There are numerous points at which the whole thing coul= d fail even before dhcpv4.

[Qi] =A0I think you ignored a = fact that the DHCPv4 server is likely to be collocated with the concentrato= r, as Peng stated before. =A0IMHO , in MAP, you put many kinds of informati= on in one DHCPv6 option. The client and CPE need to be modified to pick out= what they need. And there are some other process to make the mechanism wor= k. I think it is not simpler than pb4over6.

-Woj.


=A0

- DHCPv4 servers need to be modified to take into account IPv6.
=

[YL] Yes or we need to deploy TRA.

Thanks,
Yiu

-Woj.


On 13 June 2012 06:36, Peng Wu = <pengwu.thu@gmail.com> wrote:
Woj,

On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Peng,
>
> On 11 June 2012 20:38, Peng Wu <pengwu.thu@gmail.com> wrote:
>>
>> Woj,
>>
>> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:=
>> > There is basic question regarding this draft, one that has al= so been
>> > raised
>> > at previous WG meetings: "why is it needed?".
>> It's actually written in section 4 of the draft.
>>
>> > There is a deeper issue here: This draft seems to give the im= pression
>> > that
>> > running such a regular public addressed DHCPv4 based overlay = on IPv6 is
>> > a
>> > simple idea, as opposed to native dual stack. It is anything = but, given
>> > that
>> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, s= imilar
>> to scenario of DS-Lite and MAP/4rd.
>> I thought the assumption of IPv4-over-IPv6 is that you cannot/do n= ot
>> want to provision native dual-stack?
>
>
> To put it simply: This draft describes a scenario where public v4 addr= esses
> are available. The "classic" v6 migration scenario is in thi= s case "dual
> stack" and is what I believe has been advised for years by the IE= TF, and
> continues to be the recommended approach. Why would one want to run in= this
> case dual-stack over a tunnel infra is the question? Is this intended = as an
> academic draft (as in "we can do it, but don't know why"= )?
[Peng] That's not always the case. Now to be more precise, with pb 4ove= r6
1.Concentrator can be in a high position, and we don't have to IPv4 eve= ry where
2.Provision IPv4 in a flexible, on-demand way
3.It can be deployed along with DS-lite to provide a value-added service These points are already written in the draft

>>
>> > a) it it requires changes to DHCPv4 processing b) it introduc= es non
>> > trivial
>> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requ= ires
>> > changes to
>> > CPE d) makes life really a mess if we consider a real dual st= ack CPE.
>> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >> essential changes to protocol processing.
>
>
> Woj> That's not what the draft DHCPv4overv6 indicates, unless o= ne assumes a
> very specific and limiting deployment scenario. In any case it's q= uite clear
> that it is not possible to use regular DHCPv4 clients for this, or a r= egular
> DHCPv4 server (there is no mention of how the broadcast flags should b= e
> handled, mapped to IPv6, etc).
[Peng]Actually we can use regular DHCPv4 client, with the help of a
CRA function planted on the same host, that's a very fundamental point<= br> of the DHCPv4over6v6 draft.
Server side need modification, yes. But only on the step of
sending/receiving DHCP messages (sockets). That's what I wanted to
express in last mail.
FYI, it only uses IPv6 unicast, with the aid of CRA.

>>
>> b) What really matters here is provisioning the IPv4 address throu= gh
>> DHCPv4. Just like in MAP/4rd, you provision the address through >> DHCPv6.
>> In pb4over6 DHCPv6 is only an *option* to provide the concentrator=
>> address. You have similar logic too in MAP.
>> So I don't think it's "non trivial dependancy". = They are similar
>> functions for all IPv4-over-IPv6 mechanisms that need provisioning= ,
>> only different technical paths.
>
>
> There are several components/parts that all need to play together in t= his
> solution, many more than apparently required, and the failure of one i= s not
> obvious to anyone looking at another. As in any such multi-part system=
> design, the overall complexity is higher.
Sorry but I simply don't buy that it's *significant* more complexit= y.
As to failure, it's more like a sequencial rather than " the failu= re
of one is not obvious to anyone looking at another". If I cannot get the concentrator or the DHCPv4 server address, I stop the rest steps.


>>
>> c) Any IPv4-over-IPv6 mechanism requires change to CPE
>
>
> Yes, but in the case of this draft, the changes that are proposed do n= ot
> lead to anything over and above what plain dual stack accomplishes, ex= cept
> extra complexity.
See above

Cheers~



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


--047d7b2ee27bc9062e04c291b9b4-- From wdec.ietf@gmail.com Sat Jun 16 02:25: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 3AC7521F85DF for ; Sat, 16 Jun 2012 02:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0At9JOweGUhu for ; Sat, 16 Jun 2012 02:25:20 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 56DAA21F85D3 for ; Sat, 16 Jun 2012 02:25:20 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2478237qcs.31 for ; Sat, 16 Jun 2012 02:25:19 -0700 (PDT) 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=cyckEWIq1ZG5R5/JkaTwOoV0twm16Fr4+ZAIoZA4w+k=; b=ydIRAZ2KeT4uKQd5cT/k46J60RnTB32DmwHHn1ZxsWxORhR41kMaJMJWIhjIfzMAL/ +dqXgHXMNv9lcChf63qTRXa4Pa5J38X9+LNl3jmYzirCnx9wF6YK4p2TNCjVYywh4CgY 4dX8SFif2QsVmchRVkwuTqRP85lnmtOF7u3YFfEEMjIueaIQT9n6PArzD2f2pfQyCU2Y uGnK33Zp444ekFwIpjkCpMCrMbo0xU+88w/Bl1+veAruR6P1Si2HpxkUDO3tJYx7IbgZ 5N0D4IY0rZbVpV50u+8Vyq0eFklLjOpRHo63BRXVOEv/di5Vz8uZne/P/OgEGxxmgOa0 2jkA== MIME-Version: 1.0 Received: by 10.224.179.18 with SMTP id bo18mr16196460qab.93.1339838719535; Sat, 16 Jun 2012 02:25:19 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Sat, 16 Jun 2012 02:25:19 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Jun 2012 11:25:19 +0200 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=20cf302ef922ef2b1d04c293827a Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 16 Jun 2012 09:25:22 -0000 --20cf302ef922ef2b1d04c293827a Content-Type: text/plain; charset=ISO-8859-1 Qi, On 16 June 2012 09:17, Qi Sun wrote: > Hi Woj, > > Please see inline. > > On Fri, Jun 15, 2012 at 6:42 PM, Wojciech Dec wrote: > >> Lee, >> >> On 15 June 2012 04:51, Lee, Yiu wrote: >> >>> Hi Woj, >>> >>> Let me try to answer some of your questions: >>> >>> From: Wojciech Dec >>> Date: Thursday, June 14, 2012 9:07 AM >>> To: Peng Wu >>> Cc: "softwires@ietf.org" , Yong Cui < >>> cuiyong@tsinghua.edu.cn> >>> >>> Subject: Re: [Softwires] WG last call on >>> draft-ietf-softwire-public-4over6-01 >>> >>> Peng, >>> >>> your answers do not address the key concerns: >>> - Why is this needed, besides that it can be done, as opposed to classic >>> dual stack? >>> >>> [YL] The scenario is addressing IPv6-only access network. If the access >>> network is DS, yes, you don't need this technology. >>> >> >> Woj> This draft proposes using public IPv4 addressing to deliver a dual >> stack service to the end-user. Even on a future IPv6-only network, in the >> selective cases where such a dual stack service is to be offered, using >> existing IPv4 functionality, one that all operators use today, that is >> mature, and requires NO client or server or relay changes, is way simpler >> than investing in new intricate functionality. >> > > [Qi]Because it is difficult for the operators to deploy native dual stack > in such a short period when the IPv4 address resource is running out, here > comes stateful mechanisms DS-lite and pb4over6 to solve the transition > problems, with/without CGN on the AFTR/concentrator. IMHO, they do not > compete with native dual stack for the reason above. > This statement confirms all the concerns regarding this draft; it mentiones IPv4 address run-out in the context of a draft whose sole purpose is to hand out public IPv4 addresses,; it also mentions the difficulty of deploying dual stack, yet, this draft requires IPv6 to be deployed (presumably in existing networks) along with an IPv4 overlay too. > > >> I see this scheme directly leading into changing this scenario to one of >> IPv4 address sharing, which brings this work into direct overlap with other >> work in softwires. >> > > [Qi] Pb4over6 is a stateful mechanism without CGN. It's different from > other work. > > As such I can only re-iterate what I said before; IMO we need a thorough >> review of this solution space, including this draft, before progressing. >> >> [Qi] IMO we should progress the draft, instead of blocking the IPv4/IPv6 > transition progress. > Woj> The last thing we need is another transition mechanism, and this draft appears to claim being one and nobody's blocking here deployment of IPv6. As stated earlier, we need a review of the whole solution space in softwires, rather than spin up more drafts that are of questionable use. -Woj. > > >> >>> - It requires changes to the client/relay, thus it cannot be simply used >>> with regular DHCPv4 implementations (note: it doesn't matter that you're >>> putting a CRA element, that's an implementation detail). It is thus >>> invesement in legacy IPv4 technology, not migration to IPv6. >>> >>> [YL] AFAIK, the client won't change but will require CRA. This >>> technology is to support legacy v4 service while migrating to IPv6. The >>> client will have both v4 and v6 addresses. This is given. So I fail to see >>> why this is only an investment in legacy IPv4 technology. >>> >> >> Woj> The fact that there is a CRA means a client change, or a CPE change. >> The fact that you call it CRA, and not DHCP-client change, even though this >> function is specific to DHCPv4, does not change that fact. >> >>> >>> [Qi] CRA is short for Client Relay Agent. AFAIK, we don't take DHCP > relay agent as a change to DHCP server, but a separate part. So I'm not > sure if it's proper to call CRA a client change. > > >> - It is more complicated to get through failures, to anyone who looks at >>> it all objectively (Basic example: A dhcpv4 user will have no idea that the >>> failure to get an ipv4 address is because in the >>> CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a wrong >>> AAAA for some host name that happens to be a dhcpv4 server, or because >>> dhcpv6 is not providing the right option or name). >>> >>> [YL] I am sorry, I can't follow this. Can you explain more please? >>> >> >> Woj> The sequence of events leading to a client acquiring a v4 address is >> complex and not intuitive to anyone who deals with DHCPv4. There are >> numerous points at which the whole thing could fail even before dhcpv4. >> > > [Qi] I think you ignored a fact that the DHCPv4 server is likely to be > collocated with the concentrator, as Peng stated before. IMHO , in MAP, > you put many kinds of information in one DHCPv6 option. The client and CPE > need to be modified to pick out what they need. And there are some other > process to make the mechanism work. I think it is not simpler than pb4over6. > >> >> -Woj. >> >> >> >>> >>> - DHCPv4 servers need to be modified to take into account IPv6. >>> >> >>> [YL] Yes or we need to deploy TRA. >>> >>> Thanks, >>> Yiu >>> >>> -Woj. >>> >>> >>> On 13 June 2012 06:36, Peng Wu wrote: >>> >>>> Woj, >>>> >>>> On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec >>>> wrote: >>>> > Peng, >>>> > >>>> > On 11 June 2012 20:38, Peng Wu wrote: >>>> >> >>>> >> Woj, >>>> >> >>>> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec >>>> wrote: >>>> >> > There is basic question regarding this draft, one that has also >>>> been >>>> >> > raised >>>> >> > at previous WG meetings: "why is it needed?". >>>> >> It's actually written in section 4 of the draft. >>>> >> >>>> >> > There is a deeper issue here: This draft seems to give the >>>> impression >>>> >> > that >>>> >> > running such a regular public addressed DHCPv4 based overlay on >>>> IPv6 is >>>> >> > a >>>> >> > simple idea, as opposed to native dual stack. It is anything but, >>>> given >>>> >> > that >>>> >> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar >>>> >> to scenario of DS-Lite and MAP/4rd. >>>> >> I thought the assumption of IPv4-over-IPv6 is that you cannot/do not >>>> >> want to provision native dual-stack? >>>> > >>>> > >>>> > To put it simply: This draft describes a scenario where public v4 >>>> addresses >>>> > are available. The "classic" v6 migration scenario is in this case >>>> "dual >>>> > stack" and is what I believe has been advised for years by the IETF, >>>> and >>>> > continues to be the recommended approach. Why would one want to run >>>> in this >>>> > case dual-stack over a tunnel infra is the question? Is this intended >>>> as an >>>> > academic draft (as in "we can do it, but don't know why")? >>>> [Peng] That's not always the case. Now to be more precise, with pb >>>> 4over6 >>>> 1.Concentrator can be in a high position, and we don't have to IPv4 >>>> every where >>>> 2.Provision IPv4 in a flexible, on-demand way >>>> 3.It can be deployed along with DS-lite to provide a value-added service >>>> These points are already written in the draft >>>> >>>> >> >>>> >> > a) it it requires changes to DHCPv4 processing b) it introduces non >>>> >> > trivial >>>> >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires >>>> >> > changes to >>>> >> > CPE d) makes life really a mess if we consider a real dual stack >>>> CPE. >>>> >> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >>>> >> essential changes to protocol processing. >>>> > >>>> > >>>> > Woj> That's not what the draft DHCPv4overv6 indicates, unless one >>>> assumes a >>>> > very specific and limiting deployment scenario. In any case it's >>>> quite clear >>>> > that it is not possible to use regular DHCPv4 clients for this, or a >>>> regular >>>> > DHCPv4 server (there is no mention of how the broadcast flags should >>>> be >>>> > handled, mapped to IPv6, etc). >>>> [Peng]Actually we can use regular DHCPv4 client, with the help of a >>>> CRA function planted on the same host, that's a very fundamental point >>>> of the DHCPv4over6v6 draft. >>>> Server side need modification, yes. But only on the step of >>>> sending/receiving DHCP messages (sockets). That's what I wanted to >>>> express in last mail. >>>> FYI, it only uses IPv6 unicast, with the aid of CRA. >>>> >>>> >> >>>> >> b) What really matters here is provisioning the IPv4 address through >>>> >> DHCPv4. Just like in MAP/4rd, you provision the address through >>>> >> DHCPv6. >>>> >> In pb4over6 DHCPv6 is only an *option* to provide the concentrator >>>> >> address. You have similar logic too in MAP. >>>> >> So I don't think it's "non trivial dependancy". They are similar >>>> >> functions for all IPv4-over-IPv6 mechanisms that need provisioning, >>>> >> only different technical paths. >>>> > >>>> > >>>> > There are several components/parts that all need to play together in >>>> this >>>> > solution, many more than apparently required, and the failure of one >>>> is not >>>> > obvious to anyone looking at another. As in any such multi-part system >>>> > design, the overall complexity is higher. >>>> Sorry but I simply don't buy that it's *significant* more complexity. >>>> As to failure, it's more like a sequencial rather than " the failure >>>> of one is not obvious to anyone looking at another". If I cannot get >>>> the concentrator or the DHCPv4 server address, I stop the rest steps. >>>> >>>> >>>> >> >>>> >> c) Any IPv4-over-IPv6 mechanism requires change to CPE >>>> > >>>> > >>>> > Yes, but in the case of this draft, the changes that are proposed do >>>> not >>>> > lead to anything over and above what plain dual stack accomplishes, >>>> except >>>> > extra complexity. >>>> See above >>>> >>>> Cheers~ >>>> >>> >>> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --20cf302ef922ef2b1d04c293827a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Qi,

On 16 June 2012 09:17, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:
Hi Woj,

=A0 =A0 =A0Please see inline.

On Fri, Jun 15, 2012 at 6:42 PM, Wojciec= h Dec <wdec.ietf@gmail.com> wrote:
Lee,

= On 15 June 2012 04:51, Lee, Yiu <Yiu_Lee@cable.comcast.com>= wrote:
Hi Woj,

Let me try to answer some of y= our questions:

From: Wojciech Dec <wdec.ietf@gmail.com>Date: Thursday, June 14, 2012 9:= 07 AM
To: Peng Wu <pengwu.thu@gmail.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>, Yong= Cui <cuiyo= ng@tsinghua.edu.cn>

Subject: Re: [Softwires] WG la= st call on draft-ietf-softwire-public-4over6-01
Peng,

your answers do not address the key concerns:
- Why is this needed, besides that it can be done, as opposed to classic du= al stack?

[YL] =A0The scenario = is addressing IPv6-only access network. If the access network is DS, yes, y= ou don't need this technology.

Woj> This draft proposes using public = IPv4 addressing to deliver a dual stack service to the end-user. Even on a = future IPv6-only network, in the selective cases where such a dual stack se= rvice is to be offered, using existing IPv4 functionality, one that all ope= rators use today, that is mature, and requires NO client or server or relay= changes, is way simpler than investing in new intricate functionality.

[Qi]Because it is diffic= ult for the operators to deploy native dual stack in such a short period wh= en the IPv4 address resource is running out, here comes stateful mechanisms= DS-lite and pb4over6 to solve the transition problems, with/without CGN on= the AFTR/concentrator. IMHO, they do not compete with native dual stack fo= r the reason above.

This statement confirms all the concerns = regarding this draft; it mentiones IPv4 address run-out in the context of a= draft whose sole purpose is to hand out public IPv4 addresses,; it also me= ntions the difficulty of deploying dual stack, yet, this draft requires IPv= 6 to be deployed (presumably in existing networks) along with an IPv4 overl= ay too.
=A0
I see this scheme directly leading into changing this scenario to one of IP= v4 address sharing, which brings this work into direct overlap with other w= ork in softwires.

[Qi] Pb4over6 is a stateful mechanism without CGN. It's different from = other work.

As such I can only re-iterate what I said before; IMO we need a thorough= review of this solution space, including this draft, before progressing. <= br>
[Qi] IMO we should progress the dra= ft, instead of blocking the IPv4/IPv6 transition progress.

Woj> The last thing we need is another transition= mechanism, and this draft appears to claim being one and nobody's bloc= king here deployment of IPv6.
As stated earlier, we need a review of the whole solution space in softwire= s, rather than spin up more drafts that are of questionable use.

-Wo= j.
=A0

- It requires changes to the client/relay, thus it cannot be simply used wi= th regular DHCPv4 implementations (note: it doesn't matter that you'= ;re putting a CRA element, that's an implementation detail). It is thus= invesement in legacy IPv4 technology, not migration to IPv6.

[YL] AFAIK, the clien= t won't change but will require CRA. This technology is to support lega= cy v4 service while migrating to IPv6. The client will have both v4 and v6 = addresses. This is given. So I fail to see why this is only an investment i= n legacy IPv4 technology.

Woj> The fact that there is a CRA mean= s a client change, or a CPE change. The fact that you call it CRA, and not = DHCP-client change, even though this function is specific to DHCPv4, does n= ot change that fact.

[Qi] CRA is short for Client Relay Agent. AFAIK, w= e don't take DHCP relay agent as a change to DHCP server, but a separat= e part. So I'm not sure if it's proper to call CRA a client change.=
=A0
- It is more complicated to get through failures, to anyone who looks at it= all objectively (Basic example: A dhcpv4 user will have no idea that the f= ailure to get an ipv4 address is because in the CRA/whatever-stuff-is-combb= led-to-make-this-work DNSv6 is returning a wrong AAAA for some host name that happens to be a dhcpv4 server, or bec= ause dhcpv6 is not providing the right option or name).
<= div>
[YL] I am sorry, I can't follow this. Can you = explain more please?

Woj> The sequence of events leading to= a client acquiring a v4 address is complex and not intuitive to anyone who= deals with DHCPv4. There are numerous points at which the whole thing coul= d fail even before dhcpv4.

[Qi] =A0I think you igno= red a fact that the DHCPv4 server is likely to be collocated with the conce= ntrator, as Peng stated before. =A0IMHO , in MAP, you put many kinds of inf= ormation in one DHCPv6 option. The client and CPE need to be modified to pi= ck out what they need. And there are some other process to make the mechani= sm work. I think it is not simpler than pb4over6.

-Woj.


=A0

- DHCPv4 servers need to be modified to take into account IPv6.
=
=

[YL] Yes or we need to deploy TRA.

Thanks,
Yiu

-Woj.


On 13 June 2012 06:36, Peng Wu = <pengwu.thu@gmail.com> wrote:
Woj,

On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Peng,
>
> On 11 June 2012 20:38, Peng Wu <pengwu.thu@gmail.com> wrote:
>>
>> Woj,
>>
>> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:=
>> > There is basic question regarding this draft, one that has al= so been
>> > raised
>> > at previous WG meetings: "why is it needed?".
>> It's actually written in section 4 of the draft.
>>
>> > There is a deeper issue here: This draft seems to give the im= pression
>> > that
>> > running such a regular public addressed DHCPv4 based overlay = on IPv6 is
>> > a
>> > simple idea, as opposed to native dual stack. It is anything = but, given
>> > that
>> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, s= imilar
>> to scenario of DS-Lite and MAP/4rd.
>> I thought the assumption of IPv4-over-IPv6 is that you cannot/do n= ot
>> want to provision native dual-stack?
>
>
> To put it simply: This draft describes a scenario where public v4 addr= esses
> are available. The "classic" v6 migration scenario is in thi= s case "dual
> stack" and is what I believe has been advised for years by the IE= TF, and
> continues to be the recommended approach. Why would one want to run in= this
> case dual-stack over a tunnel infra is the question? Is this intended = as an
> academic draft (as in "we can do it, but don't know why"= )?
[Peng] That's not always the case. Now to be more precise, with pb 4ove= r6
1.Concentrator can be in a high position, and we don't have to IPv4 eve= ry where
2.Provision IPv4 in a flexible, on-demand way
3.It can be deployed along with DS-lite to provide a value-added service These points are already written in the draft

>>
>> > a) it it requires changes to DHCPv4 processing b) it introduc= es non
>> > trivial
>> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requ= ires
>> > changes to
>> > CPE d) makes life really a mess if we consider a real dual st= ack CPE.
>> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >> essential changes to protocol processing.
>
>
> Woj> That's not what the draft DHCPv4overv6 indicates, unless o= ne assumes a
> very specific and limiting deployment scenario. In any case it's q= uite clear
> that it is not possible to use regular DHCPv4 clients for this, or a r= egular
> DHCPv4 server (there is no mention of how the broadcast flags should b= e
> handled, mapped to IPv6, etc).
[Peng]Actually we can use regular DHCPv4 client, with the help of a
CRA function planted on the same host, that's a very fundamental point<= br> of the DHCPv4over6v6 draft.
Server side need modification, yes. But only on the step of
sending/receiving DHCP messages (sockets). That's what I wanted to
express in last mail.
FYI, it only uses IPv6 unicast, with the aid of CRA.

>>
>> b) What really matters here is provisioning the IPv4 address throu= gh
>> DHCPv4. Just like in MAP/4rd, you provision the address through >> DHCPv6.
>> In pb4over6 DHCPv6 is only an *option* to provide the concentrator=
>> address. You have similar logic too in MAP.
>> So I don't think it's "non trivial dependancy". = They are similar
>> functions for all IPv4-over-IPv6 mechanisms that need provisioning= ,
>> only different technical paths.
>
>
> There are several components/parts that all need to play together in t= his
> solution, many more than apparently required, and the failure of one i= s not
> obvious to anyone looking at another. As in any such multi-part system=
> design, the overall complexity is higher.
Sorry but I simply don't buy that it's *significant* more complexit= y.
As to failure, it's more like a sequencial rather than " the failu= re
of one is not obvious to anyone looking at another". If I cannot get the concentrator or the DHCPv4 server address, I stop the rest steps.


>>
>> c) Any IPv4-over-IPv6 mechanism requires change to CPE
>
>
> Yes, but in the case of this draft, the changes that are proposed do n= ot
> lead to anything over and above what plain dual stack accomplishes, ex= cept
> extra complexity.
See above

Cheers~



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



--20cf302ef922ef2b1d04c293827a-- From sunqi.csnet.thu@gmail.com Sat Jun 16 07:02: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 8D0EB21F858F for ; Sat, 16 Jun 2012 07:02:39 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbcHEsu7oL7x for ; Sat, 16 Jun 2012 07:02:38 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2E721F8593 for ; Sat, 16 Jun 2012 07:02:38 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6449629pbc.31 for ; Sat, 16 Jun 2012 07:02:38 -0700 (PDT) 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=ZRQdbFK54/Ocydy9UuzL8TcYl500qF4UmB9EHAYjGo8=; b=fznAHKUT6n3N15I5x9YuYoTlDFObjJgNR+a9QURRMMUwYpnbwN49N1oOYgijkt5avw +5EJmH6flEcVFDDvL4LRlSb4AH3cwso7oAan21NKzfb3b/bd91yLSyNakgZHnlsI1kPW rrZPfDtDlW+cisp7Z6jV2OylRHZoQy98Ces0+PieQS2WzTzT/toqVZGW9+P8DgoeZnR/ HOGYzXXPPaJ7QLf8AurWH3kHMZDaoxQ0QNN+LcaGZAElWcQqI3HpX9mwDntglDZ8Svca DPnDVy8850U3w2ZVLGi8ZRMDq6gRXbxJEXreGCsjKRsrdAAZivbSS2l3EU4UeCTvXyLO WvsA== MIME-Version: 1.0 Received: by 10.68.217.234 with SMTP id pb10mr31643811pbc.79.1339855357713; Sat, 16 Jun 2012 07:02:37 -0700 (PDT) Received: by 10.142.105.1 with HTTP; Sat, 16 Jun 2012 07:02:37 -0700 (PDT) In-Reply-To: References: Date: Sat, 16 Jun 2012 22:02:37 +0800 Message-ID: From: Qi Sun To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 16 Jun 2012 14:02:39 -0000 Hi Woj, In your previous mail you wrote : > This statement confirms all the concerns regarding this draft; it mentiones IPv4 address run-out in the context of a draft whose sole purpose is to hand out public IPv4 addresses,; it also mentions the difficulty of deploying dual stack, yet, this draft requires IPv6 to be deployed (presumably in existing networks) along with an IPv4 overlay too. [Qi] Operators still have IPv4 address space to assign. that's why IPv4 Internet is still growing. And if we don't hand out IPv4 address , how can we achieve IPv4-over-IPv6(such as DS-Lite and MAP)? And handing out public IPv4 address can achieve e2e transparency. In the mechanism, there are dual stack nodes, which contribute to achieve IPv4-over-IPv6. This is different from the so called 'native' dual stack in which every node is dual stack. > Woj> The last thing we need is another transition mechanism, and this draft appears to claim being one and nobody's blocking here deployment of IPv6. As stated earlier, we need a review of the whole solution space in softwires, rather than spin up more drafts that are of questionable use. [Qi] This mechanism has its senario which has been stated in the draft andof previous mails. what's more, this draft is now a WG draft , NOT a new draft. So I don't think it is of 'questionable' use. Best Regards! Qi On 6/16/12, Wojciech Dec wrote: > Qi, > > On 16 June 2012 09:17, Qi Sun wrote: > >> Hi Woj, >> >> Please see inline. >> >> On Fri, Jun 15, 2012 at 6:42 PM, Wojciech Dec >> wrote: >> >>> Lee, >>> >>> On 15 June 2012 04:51, Lee, Yiu wrote: >>> >>>> Hi Woj, >>>> >>>> Let me try to answer some of your questions: >>>> >>>> From: Wojciech Dec >>>> Date: Thursday, June 14, 2012 9:07 AM >>>> To: Peng Wu >>>> Cc: "softwires@ietf.org" , Yong Cui < >>>> cuiyong@tsinghua.edu.cn> >>>> >>>> Subject: Re: [Softwires] WG last call on >>>> draft-ietf-softwire-public-4over6-01 >>>> >>>> Peng, >>>> >>>> your answers do not address the key concerns: >>>> - Why is this needed, besides that it can be done, as opposed to >>>> classic >>>> dual stack? >>>> >>>> [YL] The scenario is addressing IPv6-only access network. If the >>>> access >>>> network is DS, yes, you don't need this technology. >>>> >>> >>> Woj> This draft proposes using public IPv4 addressing to deliver a dual >>> stack service to the end-user. Even on a future IPv6-only network, in >>> the >>> selective cases where such a dual stack service is to be offered, using >>> existing IPv4 functionality, one that all operators use today, that is >>> mature, and requires NO client or server or relay changes, is way >>> simpler >>> than investing in new intricate functionality. >>> >> >> [Qi]Because it is difficult for the operators to deploy native dual stack >> in such a short period when the IPv4 address resource is running out, >> here >> comes stateful mechanisms DS-lite and pb4over6 to solve the transition >> problems, with/without CGN on the AFTR/concentrator. IMHO, they do not >> compete with native dual stack for the reason above. >> > > This statement confirms all the concerns regarding this draft; it mentiones > IPv4 address run-out in the context of a draft whose sole purpose is to > hand out public IPv4 addresses,; it also mentions the difficulty of > deploying dual stack, yet, this draft requires IPv6 to be deployed > (presumably in existing networks) along with an IPv4 overlay too. > >> >> >>> I see this scheme directly leading into changing this scenario to one of >>> IPv4 address sharing, which brings this work into direct overlap with >>> other >>> work in softwires. >>> >> >> [Qi] Pb4over6 is a stateful mechanism without CGN. It's different from >> other work. >> >> As such I can only re-iterate what I said before; IMO we need a thorough >>> review of this solution space, including this draft, before progressing. >>> >>> [Qi] IMO we should progress the draft, instead of blocking the IPv4/IPv6 >> transition progress. >> > > Woj> The last thing we need is another transition mechanism, and this draft > appears to claim being one and nobody's blocking here deployment of IPv6. > As stated earlier, we need a review of the whole solution space in > softwires, rather than spin up more drafts that are of questionable use. > > -Woj. > >> >> >>> >>>> - It requires changes to the client/relay, thus it cannot be simply >>>> used >>>> with regular DHCPv4 implementations (note: it doesn't matter that >>>> you're >>>> putting a CRA element, that's an implementation detail). It is thus >>>> invesement in legacy IPv4 technology, not migration to IPv6. >>>> >>>> [YL] AFAIK, the client won't change but will require CRA. This >>>> technology is to support legacy v4 service while migrating to IPv6. The >>>> client will have both v4 and v6 addresses. This is given. So I fail to >>>> see >>>> why this is only an investment in legacy IPv4 technology. >>>> >>> >>> Woj> The fact that there is a CRA means a client change, or a CPE >>> change. >>> The fact that you call it CRA, and not DHCP-client change, even though >>> this >>> function is specific to DHCPv4, does not change that fact. >>> >>>> >>>> [Qi] CRA is short for Client Relay Agent. AFAIK, we don't take DHCP >> relay agent as a change to DHCP server, but a separate part. So I'm not >> sure if it's proper to call CRA a client change. >> >> >>> - It is more complicated to get through failures, to anyone who looks >>> at >>>> it all objectively (Basic example: A dhcpv4 user will have no idea that >>>> the >>>> failure to get an ipv4 address is because in the >>>> CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a >>>> wrong >>>> AAAA for some host name that happens to be a dhcpv4 server, or because >>>> dhcpv6 is not providing the right option or name). >>>> >>>> [YL] I am sorry, I can't follow this. Can you explain more please? >>>> >>> >>> Woj> The sequence of events leading to a client acquiring a v4 address >>> is >>> complex and not intuitive to anyone who deals with DHCPv4. There are >>> numerous points at which the whole thing could fail even before dhcpv4. >>> >> >> [Qi] I think you ignored a fact that the DHCPv4 server is likely to be >> collocated with the concentrator, as Peng stated before. IMHO , in MAP, >> you put many kinds of information in one DHCPv6 option. The client and >> CPE >> need to be modified to pick out what they need. And there are some other >> process to make the mechanism work. I think it is not simpler than >> pb4over6. >> >>> >>> -Woj. >>> >>> >>> >>>> >>>> - DHCPv4 servers need to be modified to take into account IPv6. >>>> >>> >>>> [YL] Yes or we need to deploy TRA. >>>> >>>> Thanks, >>>> Yiu >>>> >>>> -Woj. >>>> >>>> >>>> On 13 June 2012 06:36, Peng Wu wrote: >>>> >>>>> Woj, >>>>> >>>>> On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec >>>>> wrote: >>>>> > Peng, >>>>> > >>>>> > On 11 June 2012 20:38, Peng Wu wrote: >>>>> >> >>>>> >> Woj, >>>>> >> >>>>> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec >>>>> wrote: >>>>> >> > There is basic question regarding this draft, one that has also >>>>> been >>>>> >> > raised >>>>> >> > at previous WG meetings: "why is it needed?". >>>>> >> It's actually written in section 4 of the draft. >>>>> >> >>>>> >> > There is a deeper issue here: This draft seems to give the >>>>> impression >>>>> >> > that >>>>> >> > running such a regular public addressed DHCPv4 based overlay on >>>>> IPv6 is >>>>> >> > a >>>>> >> > simple idea, as opposed to native dual stack. It is anything but, >>>>> given >>>>> >> > that >>>>> >> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, >>>>> >> similar >>>>> >> to scenario of DS-Lite and MAP/4rd. >>>>> >> I thought the assumption of IPv4-over-IPv6 is that you cannot/do >>>>> >> not >>>>> >> want to provision native dual-stack? >>>>> > >>>>> > >>>>> > To put it simply: This draft describes a scenario where public v4 >>>>> addresses >>>>> > are available. The "classic" v6 migration scenario is in this case >>>>> "dual >>>>> > stack" and is what I believe has been advised for years by the IETF, >>>>> and >>>>> > continues to be the recommended approach. Why would one want to run >>>>> in this >>>>> > case dual-stack over a tunnel infra is the question? Is this >>>>> > intended >>>>> as an >>>>> > academic draft (as in "we can do it, but don't know why")? >>>>> [Peng] That's not always the case. Now to be more precise, with pb >>>>> 4over6 >>>>> 1.Concentrator can be in a high position, and we don't have to IPv4 >>>>> every where >>>>> 2.Provision IPv4 in a flexible, on-demand way >>>>> 3.It can be deployed along with DS-lite to provide a value-added >>>>> service >>>>> These points are already written in the draft >>>>> >>>>> >> >>>>> >> > a) it it requires changes to DHCPv4 processing b) it introduces >>>>> >> > non >>>>> >> > trivial >>>>> >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires >>>>> >> > changes to >>>>> >> > CPE d) makes life really a mess if we consider a real dual stack >>>>> CPE. >>>>> >> a) Simply make DHCPv4 work with IPv6 as underlying transport. No >>>>> >> essential changes to protocol processing. >>>>> > >>>>> > >>>>> > Woj> That's not what the draft DHCPv4overv6 indicates, unless one >>>>> assumes a >>>>> > very specific and limiting deployment scenario. In any case it's >>>>> quite clear >>>>> > that it is not possible to use regular DHCPv4 clients for this, or a >>>>> regular >>>>> > DHCPv4 server (there is no mention of how the broadcast flags should >>>>> be >>>>> > handled, mapped to IPv6, etc). >>>>> [Peng]Actually we can use regular DHCPv4 client, with the help of a >>>>> CRA function planted on the same host, that's a very fundamental point >>>>> of the DHCPv4over6v6 draft. >>>>> Server side need modification, yes. But only on the step of >>>>> sending/receiving DHCP messages (sockets). That's what I wanted to >>>>> express in last mail. >>>>> FYI, it only uses IPv6 unicast, with the aid of CRA. >>>>> >>>>> >> >>>>> >> b) What really matters here is provisioning the IPv4 address >>>>> >> through >>>>> >> DHCPv4. Just like in MAP/4rd, you provision the address through >>>>> >> DHCPv6. >>>>> >> In pb4over6 DHCPv6 is only an *option* to provide the concentrator >>>>> >> address. You have similar logic too in MAP. >>>>> >> So I don't think it's "non trivial dependancy". They are similar >>>>> >> functions for all IPv4-over-IPv6 mechanisms that need provisioning, >>>>> >> only different technical paths. >>>>> > >>>>> > >>>>> > There are several components/parts that all need to play together in >>>>> this >>>>> > solution, many more than apparently required, and the failure of one >>>>> is not >>>>> > obvious to anyone looking at another. As in any such multi-part >>>>> > system >>>>> > design, the overall complexity is higher. >>>>> Sorry but I simply don't buy that it's *significant* more complexity. >>>>> As to failure, it's more like a sequencial rather than " the failure >>>>> of one is not obvious to anyone looking at another". If I cannot get >>>>> the concentrator or the DHCPv4 server address, I stop the rest steps. >>>>> >>>>> >>>>> >> >>>>> >> c) Any IPv4-over-IPv6 mechanism requires change to CPE >>>>> > >>>>> > >>>>> > Yes, but in the case of this draft, the changes that are proposed do >>>>> not >>>>> > lead to anything over and above what plain dual stack accomplishes, >>>>> except >>>>> > extra complexity. >>>>> See above >>>>> >>>>> Cheers~ >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> > From wdec.ietf@gmail.com Mon Jun 18 11:19: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 03C4521F86F0 for ; Mon, 18 Jun 2012 11:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAPI1JK7-HtH for ; Mon, 18 Jun 2012 11:19:55 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id A24A221F86EA for ; Mon, 18 Jun 2012 11:19:55 -0700 (PDT) Received: by qafi31 with SMTP id i31so1426489qaf.15 for ; Mon, 18 Jun 2012 11:19:55 -0700 (PDT) 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=cw1a+OREsy7MwNMO9dq+3mrkNqUcg5vnxVsQKPOPIsI=; b=eoPATLWa7h++70SSztDxi3NIbukH9yqvPXJbJD9pq2E6itnDxSjT5W6yz9TmMP3kW1 82LGlcxr2b8STcBA3eJfL2QDaXbcosMb9JyalSWaYORkehvEOwLws/tv30sFr1q9ix4P ykCEaJfaLYiILj4sPIUsEQ5s/1x6+ULugbkZcM7006ror/igjgwWcKMLcI5/RcP4U3/Y zq4BbBC89l6vlZaGYFuQDqkZtz3w2HVogebXb5/Cm1aSqVYUmRUdrjBSJkQrUjAVkdiX oHzLb9BeX97anGylyoi/IiEKYeu2s6vzewHbPGVwjREz25RgT/bh0zz2VRbLX0RLA3oT dNdw== MIME-Version: 1.0 Received: by 10.224.18.146 with SMTP id w18mr28742250qaa.96.1340043594942; Mon, 18 Jun 2012 11:19:54 -0700 (PDT) Received: by 10.229.136.136 with HTTP; Mon, 18 Jun 2012 11:19:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Jun 2012 20:19:54 +0200 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=bcaec51b15f975c9a204c2c33623 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 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, 18 Jun 2012 18:19:58 -0000 --bcaec51b15f975c9a204c2c33623 Content-Type: text/plain; charset=ISO-8859-1 Qi, On 16 June 2012 16:02, Qi Sun wrote: > Hi Woj, > > In your previous mail you wrote : > > This statement confirms all the concerns > regarding this draft; it mentiones IPv4 address > run-out in the context of a draft whose sole > purpose is to hand out public IPv4 addresses,; it > also mentions the difficulty of deploying dual > stack, yet, this draft requires IPv6 to be > deployed (presumably in existing networks) along > with an IPv4 overlay too. > > [Qi] Operators still have IPv4 address space to assign. that's why > IPv4 Internet is still growing. And if we don't hand out IPv4 address > , how can we achieve IPv4-over-IPv6(such as DS-Lite and MAP)? And > handing out public IPv4 address can achieve e2e transparency. > Woj> As was previously indicated there are numerous solutions in this area, and a review of this space is needed. > > In the mechanism, there are dual stack nodes, which contribute to > achieve IPv4-over-IPv6. This is different from the so called 'native' > dual stack in which every node is dual stack. > > > Woj> The last thing we need is another > transition mechanism, and this draft appears to > claim being one and nobody's blocking here > deployment of IPv6. > As stated earlier, we need a review of the whole > solution space in softwires, rather than spin up > more drafts that are of questionable use. > > [Qi] This mechanism has its senario which has been stated in the draft > andof previous mails. what's more, this draft is now a WG draft , NOT > a new draft. So I don't think it is of 'questionable' use. > Woj> The fact that this is WG draft does not mean anything except that at some point there was interest in working on a solution to a problem. Currently it appears that there are multiple solutions to this problem, some perhaps more flexible and practical than others. We won't know that until we take stock of the whole space, rather than publishing RFCs that (in this case) IMO bring little value. -Woj. > > Best Regards! > > Qi > > On 6/16/12, Wojciech Dec wrote: > > Qi, > > > > On 16 June 2012 09:17, Qi Sun wrote: > > > >> Hi Woj, > >> > >> Please see inline. > >> > >> On Fri, Jun 15, 2012 at 6:42 PM, Wojciech Dec > >> wrote: > >> > >>> Lee, > >>> > >>> On 15 June 2012 04:51, Lee, Yiu wrote: > >>> > >>>> Hi Woj, > >>>> > >>>> Let me try to answer some of your questions: > >>>> > >>>> From: Wojciech Dec > >>>> Date: Thursday, June 14, 2012 9:07 AM > >>>> To: Peng Wu > >>>> Cc: "softwires@ietf.org" , Yong Cui < > >>>> cuiyong@tsinghua.edu.cn> > >>>> > >>>> Subject: Re: [Softwires] WG last call on > >>>> draft-ietf-softwire-public-4over6-01 > >>>> > >>>> Peng, > >>>> > >>>> your answers do not address the key concerns: > >>>> - Why is this needed, besides that it can be done, as opposed to > >>>> classic > >>>> dual stack? > >>>> > >>>> [YL] The scenario is addressing IPv6-only access network. If the > >>>> access > >>>> network is DS, yes, you don't need this technology. > >>>> > >>> > >>> Woj> This draft proposes using public IPv4 addressing to deliver a dual > >>> stack service to the end-user. Even on a future IPv6-only network, in > >>> the > >>> selective cases where such a dual stack service is to be offered, using > >>> existing IPv4 functionality, one that all operators use today, that is > >>> mature, and requires NO client or server or relay changes, is way > >>> simpler > >>> than investing in new intricate functionality. > >>> > >> > >> [Qi]Because it is difficult for the operators to deploy native dual > stack > >> in such a short period when the IPv4 address resource is running out, > >> here > >> comes stateful mechanisms DS-lite and pb4over6 to solve the transition > >> problems, with/without CGN on the AFTR/concentrator. IMHO, they do not > >> compete with native dual stack for the reason above. > >> > > > > This statement confirms all the concerns regarding this draft; it > mentiones > > IPv4 address run-out in the context of a draft whose sole purpose is to > > hand out public IPv4 addresses,; it also mentions the difficulty of > > deploying dual stack, yet, this draft requires IPv6 to be deployed > > (presumably in existing networks) along with an IPv4 overlay too. > > > >> > >> > >>> I see this scheme directly leading into changing this scenario to one > of > >>> IPv4 address sharing, which brings this work into direct overlap with > >>> other > >>> work in softwires. > >>> > >> > >> [Qi] Pb4over6 is a stateful mechanism without CGN. It's different from > >> other work. > >> > >> As such I can only re-iterate what I said before; IMO we need a thorough > >>> review of this solution space, including this draft, before > progressing. > >>> > >>> [Qi] IMO we should progress the draft, instead of blocking the > IPv4/IPv6 > >> transition progress. > >> > > > > Woj> The last thing we need is another transition mechanism, and this > draft > > appears to claim being one and nobody's blocking here deployment of IPv6. > > As stated earlier, we need a review of the whole solution space in > > softwires, rather than spin up more drafts that are of questionable use. > > > > -Woj. > > > >> > >> > >>> > >>>> - It requires changes to the client/relay, thus it cannot be simply > >>>> used > >>>> with regular DHCPv4 implementations (note: it doesn't matter that > >>>> you're > >>>> putting a CRA element, that's an implementation detail). It is thus > >>>> invesement in legacy IPv4 technology, not migration to IPv6. > >>>> > >>>> [YL] AFAIK, the client won't change but will require CRA. This > >>>> technology is to support legacy v4 service while migrating to IPv6. > The > >>>> client will have both v4 and v6 addresses. This is given. So I fail to > >>>> see > >>>> why this is only an investment in legacy IPv4 technology. > >>>> > >>> > >>> Woj> The fact that there is a CRA means a client change, or a CPE > >>> change. > >>> The fact that you call it CRA, and not DHCP-client change, even though > >>> this > >>> function is specific to DHCPv4, does not change that fact. > >>> > >>>> > >>>> [Qi] CRA is short for Client Relay Agent. AFAIK, we don't take DHCP > >> relay agent as a change to DHCP server, but a separate part. So I'm not > >> sure if it's proper to call CRA a client change. > >> > >> > >>> - It is more complicated to get through failures, to anyone who looks > >>> at > >>>> it all objectively (Basic example: A dhcpv4 user will have no idea > that > >>>> the > >>>> failure to get an ipv4 address is because in the > >>>> CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is returning a > >>>> wrong > >>>> AAAA for some host name that happens to be a dhcpv4 server, or because > >>>> dhcpv6 is not providing the right option or name). > >>>> > >>>> [YL] I am sorry, I can't follow this. Can you explain more please? > >>>> > >>> > >>> Woj> The sequence of events leading to a client acquiring a v4 address > >>> is > >>> complex and not intuitive to anyone who deals with DHCPv4. There are > >>> numerous points at which the whole thing could fail even before dhcpv4. > >>> > >> > >> [Qi] I think you ignored a fact that the DHCPv4 server is likely to be > >> collocated with the concentrator, as Peng stated before. IMHO , in MAP, > >> you put many kinds of information in one DHCPv6 option. The client and > >> CPE > >> need to be modified to pick out what they need. And there are some other > >> process to make the mechanism work. I think it is not simpler than > >> pb4over6. > >> > >>> > >>> -Woj. > >>> > >>> > >>> > >>>> > >>>> - DHCPv4 servers need to be modified to take into account IPv6. > >>>> > >>> > >>>> [YL] Yes or we need to deploy TRA. > >>>> > >>>> Thanks, > >>>> Yiu > >>>> > >>>> -Woj. > >>>> > >>>> > >>>> On 13 June 2012 06:36, Peng Wu wrote: > >>>> > >>>>> Woj, > >>>>> > >>>>> On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec > >>>>> wrote: > >>>>> > Peng, > >>>>> > > >>>>> > On 11 June 2012 20:38, Peng Wu wrote: > >>>>> >> > >>>>> >> Woj, > >>>>> >> > >>>>> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec < > wdec.ietf@gmail.com> > >>>>> wrote: > >>>>> >> > There is basic question regarding this draft, one that has also > >>>>> been > >>>>> >> > raised > >>>>> >> > at previous WG meetings: "why is it needed?". > >>>>> >> It's actually written in section 4 of the draft. > >>>>> >> > >>>>> >> > There is a deeper issue here: This draft seems to give the > >>>>> impression > >>>>> >> > that > >>>>> >> > running such a regular public addressed DHCPv4 based overlay on > >>>>> IPv6 is > >>>>> >> > a > >>>>> >> > simple idea, as opposed to native dual stack. It is anything > but, > >>>>> given > >>>>> >> > that > >>>>> >> Why is it opposed to native dual-stack? It's IPv4-over-IPv6, > >>>>> >> similar > >>>>> >> to scenario of DS-Lite and MAP/4rd. > >>>>> >> I thought the assumption of IPv4-over-IPv6 is that you cannot/do > >>>>> >> not > >>>>> >> want to provision native dual-stack? > >>>>> > > >>>>> > > >>>>> > To put it simply: This draft describes a scenario where public v4 > >>>>> addresses > >>>>> > are available. The "classic" v6 migration scenario is in this case > >>>>> "dual > >>>>> > stack" and is what I believe has been advised for years by the > IETF, > >>>>> and > >>>>> > continues to be the recommended approach. Why would one want to run > >>>>> in this > >>>>> > case dual-stack over a tunnel infra is the question? Is this > >>>>> > intended > >>>>> as an > >>>>> > academic draft (as in "we can do it, but don't know why")? > >>>>> [Peng] That's not always the case. Now to be more precise, with pb > >>>>> 4over6 > >>>>> 1.Concentrator can be in a high position, and we don't have to IPv4 > >>>>> every where > >>>>> 2.Provision IPv4 in a flexible, on-demand way > >>>>> 3.It can be deployed along with DS-lite to provide a value-added > >>>>> service > >>>>> These points are already written in the draft > >>>>> > >>>>> >> > >>>>> >> > a) it it requires changes to DHCPv4 processing b) it introduces > >>>>> >> > non > >>>>> >> > trivial > >>>>> >> > dependencies between DHCPv6 and DHCPv4 and tunnelling c) > requires > >>>>> >> > changes to > >>>>> >> > CPE d) makes life really a mess if we consider a real dual stack > >>>>> CPE. > >>>>> >> a) Simply make DHCPv4 work with IPv6 as underlying transport. No > >>>>> >> essential changes to protocol processing. > >>>>> > > >>>>> > > >>>>> > Woj> That's not what the draft DHCPv4overv6 indicates, unless one > >>>>> assumes a > >>>>> > very specific and limiting deployment scenario. In any case it's > >>>>> quite clear > >>>>> > that it is not possible to use regular DHCPv4 clients for this, or > a > >>>>> regular > >>>>> > DHCPv4 server (there is no mention of how the broadcast flags > should > >>>>> be > >>>>> > handled, mapped to IPv6, etc). > >>>>> [Peng]Actually we can use regular DHCPv4 client, with the help of a > >>>>> CRA function planted on the same host, that's a very fundamental > point > >>>>> of the DHCPv4over6v6 draft. > >>>>> Server side need modification, yes. But only on the step of > >>>>> sending/receiving DHCP messages (sockets). That's what I wanted to > >>>>> express in last mail. > >>>>> FYI, it only uses IPv6 unicast, with the aid of CRA. > >>>>> > >>>>> >> > >>>>> >> b) What really matters here is provisioning the IPv4 address > >>>>> >> through > >>>>> >> DHCPv4. Just like in MAP/4rd, you provision the address through > >>>>> >> DHCPv6. > >>>>> >> In pb4over6 DHCPv6 is only an *option* to provide the concentrator > >>>>> >> address. You have similar logic too in MAP. > >>>>> >> So I don't think it's "non trivial dependancy". They are similar > >>>>> >> functions for all IPv4-over-IPv6 mechanisms that need > provisioning, > >>>>> >> only different technical paths. > >>>>> > > >>>>> > > >>>>> > There are several components/parts that all need to play together > in > >>>>> this > >>>>> > solution, many more than apparently required, and the failure of > one > >>>>> is not > >>>>> > obvious to anyone looking at another. As in any such multi-part > >>>>> > system > >>>>> > design, the overall complexity is higher. > >>>>> Sorry but I simply don't buy that it's *significant* more complexity. > >>>>> As to failure, it's more like a sequencial rather than " the failure > >>>>> of one is not obvious to anyone looking at another". If I cannot get > >>>>> the concentrator or the DHCPv4 server address, I stop the rest steps. > >>>>> > >>>>> > >>>>> >> > >>>>> >> c) Any IPv4-over-IPv6 mechanism requires change to CPE > >>>>> > > >>>>> > > >>>>> > Yes, but in the case of this draft, the changes that are proposed > do > >>>>> not > >>>>> > lead to anything over and above what plain dual stack accomplishes, > >>>>> except > >>>>> > extra complexity. > >>>>> See above > >>>>> > >>>>> Cheers~ > >>>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Softwires mailing list > >>> Softwires@ietf.org > >>> https://www.ietf.org/mailman/listinfo/softwires > >>> > >>> > >> > > > --bcaec51b15f975c9a204c2c33623 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Qi,

On 16 June 2012 16:02, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:
Hi Woj,

In your previous mail you wrote :
> This statement confirms all the concerns
regarding this draft; it mentiones IPv4 address
run-out in the context of a draft whose sole
purpose is to hand out public IPv4 addresses,; it
also mentions the difficulty of deploying dual
stack, yet, this draft requires IPv6 to be
deployed (presumably in existing networks) along
with an IPv4 overlay too.

[Qi] Operators still have IPv4 address space to assign. that's wh= y
IPv4 Internet is still growing. And if we don't hand out IPv4 address , how can we achieve IPv4-over-IPv6(such as DS-Lite and MAP)? And
handing out public IPv4 address can achieve e2e transparency.

Woj> As was previously indicated there are numerous solution= s in this area, and a review of this space is needed.

In the mechanism, there are dual stack nodes, which contribute to
achieve IPv4-over-IPv6. This is different from the so called 'native= 9;
dual stack in which every node is dual stack.

> Woj> The last thing we need is another
transition mechanism, and this draft appears to
claim being one and nobody's blocking here
deployment of IPv6.
As stated earlier, we need a review of the whole
solution space in softwires, rather than spin up
more drafts that are of questionable use.

[Qi] This mechanism has its senario which has been stated in the draf= t
andof previous mails. what's more, this draft is now a WG =A0draft , NO= T
a new draft. =A0So I don't think it is of 'questionable' use.

Woj> The fact that this is WG draft does not mea= n anything except that at some point there was interest in working on a sol= ution to a problem. Currently it appears that there are multiple solutions = to this problem, some perhaps more flexible and practical than others. We w= on't know that until we take stock of the whole space, rather than publ= ishing RFCs that (in this case) IMO bring little value.

-Woj.

Best Regards!

Qi

On 6/16/12, Wojciech Dec <wdec.ie= tf@gmail.com> wrote:
> Qi,
>
> On 16 June 2012 09:17, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:
>
>> Hi Woj,
>>
>> =A0 =A0 =A0Please see inline.
>>
>> On Fri, Jun 15, 2012 at 6:42 PM, Wojciech Dec <wdec.ietf@gmail.com>
>> wrote:
>>
>>> Lee,
>>>
>>> On 15 June 2012 04:51, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
>>>
>>>> Hi Woj,
>>>>
>>>> Let me try to answer some of your questions:
>>>>
>>>> From: Wojciech Dec <wdec.ietf@gmail.com>
>>>> Date: Thursday, June 14, 2012 9:07 AM
>>>> To: Peng Wu <pe= ngwu.thu@gmail.com>
>>>> Cc: "softwires@= ietf.org" <softwires@ietf= .org>, Yong Cui <
>>>> cuiyong@tsinghu= a.edu.cn>
>>>>
>>>> Subject: Re: [Softwires] WG last call on
>>>> draft-ietf-softwire-public-4over6-01
>>>>
>>>> Peng,
>>>>
>>>> your answers do not address the key concerns:
>>>> - Why is this needed, besides that it can be done, as oppo= sed to
>>>> classic
>>>> dual stack?
>>>>
>>>> [YL] =A0The scenario is addressing IPv6-only access networ= k. If the
>>>> access
>>>> network is DS, yes, you don't need this technology. >>>>
>>>
>>> Woj> This draft proposes using public IPv4 addressing to de= liver a dual
>>> stack service to the end-user. Even on a future IPv6-only netw= ork, in
>>> the
>>> selective cases where such a dual stack service is to be offer= ed, using
>>> existing IPv4 functionality, one that all operators use today,= that is
>>> mature, and requires NO client or server or relay changes, is = way
>>> simpler
>>> than investing in new intricate functionality.
>>>
>>
>> [Qi]Because it is difficult for the operators to deploy native dua= l stack
>> in such a short period when the IPv4 address resource is running o= ut,
>> here
>> comes stateful mechanisms DS-lite and pb4over6 to solve the transi= tion
>> problems, with/without CGN on the AFTR/concentrator. IMHO, they do= not
>> compete with native dual stack for the reason above.
>>
>
> This statement confirms all the concerns regarding this draft; it ment= iones
> IPv4 address run-out in the context of a draft whose sole purpose is t= o
> hand out public IPv4 addresses,; it also mentions the difficulty of > deploying dual stack, yet, this draft requires IPv6 to be deployed
> (presumably in existing networks) along with an IPv4 overlay too.
>
>>
>>
>>> I see this scheme directly leading into changing this scenario= to one of
>>> IPv4 address sharing, which brings this work into direct overl= ap with
>>> other
>>> work in softwires.
>>>
>>
>> [Qi] Pb4over6 is a stateful mechanism without CGN. It's differ= ent from
>> other work.
>>
>> As such I can only re-iterate what I said before; IMO we need a th= orough
>>> review of this solution space, including this draft, before pr= ogressing.
>>>
>>> [Qi] IMO we should progress the draft, instead of blocking the= IPv4/IPv6
>> transition progress.
>>
>
> Woj> The last thing we need is another transition mechanism, and th= is draft
> appears to claim being one and nobody's blocking here deployment o= f IPv6.
> As stated earlier, we need a review of the whole solution space in
> softwires, rather than spin up more drafts that are of questionable us= e.
>
> -Woj.
>
>>
>>
>>>
>>>> - It requires changes to the client/relay, thus it cannot = be simply
>>>> used
>>>> with regular DHCPv4 implementations (note: it doesn't = matter that
>>>> you're
>>>> putting a CRA element, that's an implementation detail= ). It is thus
>>>> invesement in legacy IPv4 technology, not migration to IPv= 6.
>>>>
>>>> [YL] AFAIK, the client won't change but will require C= RA. This
>>>> technology is to support legacy v4 service while migrating= to IPv6. The
>>>> client will have both v4 and v6 addresses. This is given. = So I fail to
>>>> see
>>>> why this is only an investment in legacy IPv4 technology.<= br> >>>>
>>>
>>> Woj> The fact that there is a CRA means a client change, or= a CPE
>>> change.
>>> The fact that you call it CRA, and not DHCP-client change, eve= n though
>>> this
>>> function is specific to DHCPv4, does not change that fact.
>>>
>>>>
>>>> [Qi] CRA is short for Client Relay Agent. AFAIK, we don= 9;t take DHCP
>> relay agent as a change to DHCP server, but a separate part. So I&= #39;m not
>> sure if it's proper to call CRA a client change.
>>
>>
>>> =A0- It is more complicated to get through failures, to anyone= who looks
>>> at
>>>> it all objectively (Basic example: A dhcpv4 user will have= no idea that
>>>> the
>>>> failure to get an ipv4 address is because in the
>>>> CRA/whatever-stuff-is-combbled-to-make-this-work DNSv6 is = returning a
>>>> wrong
>>>> AAAA for some host name that happens to be a dhcpv4 server= , or because
>>>> dhcpv6 is not providing the right option or name).
>>>>
>>>> [YL] I am sorry, I can't follow this. Can you explain = more please?
>>>>
>>>
>>> Woj> The sequence of events leading to a client acquiring a= v4 address
>>> is
>>> complex and not intuitive to anyone who deals with DHCPv4. The= re are
>>> numerous points at which the whole thing could fail even befor= e dhcpv4.
>>>
>>
>> [Qi] =A0I think you ignored a fact that the DHCPv4 server is likel= y to be
>> collocated with the concentrator, as Peng stated before. =A0IMHO ,= in MAP,
>> you put many kinds of information in one DHCPv6 option. The client= and
>> CPE
>> need to be modified to pick out what they need. And there are some= other
>> process to make the mechanism work. I think it is not simpler than=
>> pb4over6.
>>
>>>
>>> -Woj.
>>>
>>>
>>>
>>>>
>>>> - DHCPv4 servers need to be modified to take into account = IPv6.
>>>>
>>>
>>>> [YL] Yes or we need to deploy TRA.
>>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> -Woj.
>>>>
>>>>
>>>> On 13 June 2012 06:36, Peng Wu <pengwu.thu@gmail.com> wrote:
>>>>
>>>>> Woj,
>>>>>
>>>>> On Tue, Jun 12, 2012 at 5:52 PM, Wojciech Dec <wdec.ietf@gmail.com>
>>>>> wrote:
>>>>> > Peng,
>>>>> >
>>>>> > On 11 June 2012 20:38, Peng Wu <pengwu.thu@gmail.com> wrote:
>>>>> >>
>>>>> >> Woj,
>>>>> >>
>>>>> >> On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec= <wdec.ietf@gmail.com>
>>>>> wrote:
>>>>> >> > There is basic question regarding this d= raft, one that has also
>>>>> been
>>>>> >> > raised
>>>>> >> > at previous WG meetings: "why is it= needed?".
>>>>> >> It's actually written in section 4 of the= draft.
>>>>> >>
>>>>> >> > There is a deeper issue here: This draft= seems to give the
>>>>> impression
>>>>> >> > that
>>>>> >> > running such a regular public addressed = DHCPv4 based overlay on
>>>>> IPv6 is
>>>>> >> > a
>>>>> >> > simple idea, as opposed to native dual s= tack. It is anything but,
>>>>> given
>>>>> >> > that
>>>>> >> Why is it opposed to native dual-stack? It= 9;s IPv4-over-IPv6,
>>>>> >> similar
>>>>> >> to scenario of DS-Lite and MAP/4rd.
>>>>> >> I thought the assumption of IPv4-over-IPv6 is= that you cannot/do
>>>>> >> not
>>>>> >> want to provision native dual-stack?
>>>>> >
>>>>> >
>>>>> > To put it simply: This draft describes a scenario= where public v4
>>>>> addresses
>>>>> > are available. The "classic" v6 migrati= on scenario is in this case
>>>>> "dual
>>>>> > stack" and is what I believe has been advise= d for years by the IETF,
>>>>> and
>>>>> > continues to be the recommended approach. Why wou= ld one want to run
>>>>> in this
>>>>> > case dual-stack over a tunnel infra is the questi= on? Is this
>>>>> > intended
>>>>> as an
>>>>> > academic draft (as in "we can do it, but don= 't know why")?
>>>>> [Peng] That's not always the case. Now to be more = precise, with pb
>>>>> 4over6
>>>>> 1.Concentrator can be in a high position, and we don&#= 39;t have to IPv4
>>>>> every where
>>>>> 2.Provision IPv4 in a flexible, on-demand way
>>>>> 3.It can be deployed along with DS-lite to provide a v= alue-added
>>>>> service
>>>>> These points are already written in the draft
>>>>>
>>>>> >>
>>>>> >> > a) it it requires changes to DHCPv4 proc= essing b) it introduces
>>>>> >> > non
>>>>> >> > trivial
>>>>> >> > dependencies between DHCPv6 and DHCPv4 a= nd tunnelling c) requires
>>>>> >> > changes to
>>>>> >> > CPE d) makes life really a mess if we co= nsider a real dual stack
>>>>> CPE.
>>>>> >> a) Simply make DHCPv4 work with IPv6 as under= lying transport. No
>>>>> >> essential changes to protocol processing.
>>>>> >
>>>>> >
>>>>> > Woj> That's not what the draft DHCPv4overv= 6 indicates, unless one
>>>>> assumes a
>>>>> > very specific and limiting deployment scenario. I= n any case it's
>>>>> quite clear
>>>>> > that it is not possible to use regular DHCPv4 cli= ents for this, or a
>>>>> regular
>>>>> > DHCPv4 server (there is no mention of how the bro= adcast flags should
>>>>> be
>>>>> > handled, mapped to IPv6, etc).
>>>>> [Peng]Actually we can use regular DHCPv4 client, with = the help of a
>>>>> CRA function planted on the same host, that's a ve= ry fundamental point
>>>>> of the DHCPv4over6v6 draft.
>>>>> Server side need modification, yes. But only on the st= ep of
>>>>> sending/receiving DHCP messages (sockets). That's = what I wanted to
>>>>> express in last mail.
>>>>> FYI, it only uses IPv6 unicast, with the aid of CRA. >>>>>
>>>>> >>
>>>>> >> b) What really matters here is provisioning t= he IPv4 address
>>>>> >> through
>>>>> >> DHCPv4. Just like in MAP/4rd, you provision t= he address through
>>>>> >> DHCPv6.
>>>>> >> In pb4over6 DHCPv6 is only an *option* to pro= vide the concentrator
>>>>> >> address. You have similar logic too in MAP. >>>>> >> So I don't think it's "non trivi= al dependancy". They are similar
>>>>> >> functions for all IPv4-over-IPv6 mechanisms t= hat need provisioning,
>>>>> >> only different technical paths.
>>>>> >
>>>>> >
>>>>> > There are several components/parts that all need = to play together in
>>>>> this
>>>>> > solution, many more than apparently required, and= the failure of one
>>>>> is not
>>>>> > obvious to anyone looking at another. As in any s= uch multi-part
>>>>> > system
>>>>> > design, the overall complexity is higher.
>>>>> Sorry but I simply don't buy that it's *signif= icant* more complexity.
>>>>> As to failure, it's more like a sequencial rather = than " the failure
>>>>> of one is not obvious to anyone looking at another&quo= t;. If I cannot get
>>>>> the concentrator or the DHCPv4 server address, I stop = the rest steps.
>>>>>
>>>>>
>>>>> >>
>>>>> >> c) Any IPv4-over-IPv6 mechanism requires chan= ge to CPE
>>>>> >
>>>>> >
>>>>> > Yes, but in the case of this draft, the changes t= hat are proposed do
>>>>> not
>>>>> > lead to anything over and above what plain dual s= tack accomplishes,
>>>>> except
>>>>> > extra complexity.
>>>>> See above
>>>>>
>>>>> Cheers~
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>>
>

--bcaec51b15f975c9a204c2c33623-- From internet-drafts@ietf.org Tue Jun 19 05:45: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 9CE0C21F8596; Tue, 19 Jun 2012 05:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbkcgCivNQdz; Tue, 19 Jun 2012 05:45:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCE621F858A; Tue, 19 Jun 2012 05:45:28 -0700 (PDT) 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.20 Message-ID: <20120619124528.3943.70226.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2012 05:45:28 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-4rd-01.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, 19 Jun 2012 12:45:29 -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 : IPv4 Residual Deployment via IPv6 - a Stateless Solution= (4rd) Author(s) : Remi Despres Reinaldo Penno Yiu Lee Gang Chen Sheng Jiang Filename : draft-ietf-softwire-4rd-01.txt Pages : 41 Date : 2012-06-19 Abstract: The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of [RFC6145]). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-4rd-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-4rd-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From despres.remi@laposte.net Tue Jun 19 06:28: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 DC9CA21F85C3 for ; Tue, 19 Jun 2012 06:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNf+dQ9lc8Tv for ; Tue, 19 Jun 2012 06:28:28 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2E91021F85AC for ; Tue, 19 Jun 2012 06:28:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 78FD9700024C for ; Tue, 19 Jun 2012 15:28:26 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 5A770700012E for ; Tue, 19 Jun 2012 15:28:26 +0200 (CEST) X-SFR-UUID: 20120619132826370.5A770700012E@msfrf2412.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2012 15:28:21 +0200 Message-Id: To: Softwires WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] Novelty in draft-ietf-softwire-4rd-01 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, 19 Jun 2012 13:28:29 -0000 Dear all, The main difference between -00 and -O1 concerns protection against = address or protocol corruption during 4rd-domain traversal: Problem: the CNP only protected IPv4 addresses of = full-or-shared-address CEs? In particular, they didn't protect IPv4 = addresses embedded in BR-destined IPv6 addresses (an overlook)=20 Solution: include a checksum of IPv4 addresses and protocol in the flow = label field=20 . It provides the desirable protection in a simple and intuitive way . It remains compatible with the flow-label specification (see below) Relationship with FLs of RFC6437 is analyzed as follows: a) RFC6437 says "A node that forwards a flow whose flow label value in = arriving packets is zero MAY change the flow label value. In that case, = it is RECOMMENDED that the forwarding node sets the flow label field for = a flow to a uniformly distributed value as just described for source = nodes. ... In such cases, a flow can be defined by fewer IPv6 header = fields, typically using only the 2-tuple {dest addr, source addr}." b) In CEs and BRs, arriving packets are IPv4, i.e. equivalent to packets = without FLs.=20 c) In RFC2119, "RECOMMENDED" means that "there may exist valid reasons = in particular circumstances to ignore a particular item, but the full = implications must be understood and carefully weighed before choosing a = different course". d) Implications, which have been well understood, have also been well = weighted: - With this, FLs of 5-tuple flows aren't evenly distributed FLs, = contrary to what is recommended - BUT this maintains IPv4 addresses-and-port protection without needing = any extra header between the IPv6 header and the unchanged IP payload, a = desirable feature of 4rd.=20 Comments on all aspects of the proposal are welcome. Regards, RD= From mark@townsley.net Tue Jun 19 07:25: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 87E7C21F85E6 for ; Tue, 19 Jun 2012 07:25:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ztu7TyJ-SgpX for ; Tue, 19 Jun 2012 07:25:23 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 558B421F8594 for ; Tue, 19 Jun 2012 07:25:23 -0700 (PDT) Received: by eaaq13 with SMTP id q13so2259421eaa.31 for ; Tue, 19 Jun 2012 07:25:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer:x-gm-message-state; bh=ptwyrUKIqz2RYV2VYdLo9u4GLj/qYDy4aIDYIG3WWGY=; b=XdQnNe7YvJZevtDwLlT8IA4vsd8XkUKmnuECux4olbi3sG2eAu8doG8DO4VSJcmooR RyV/KmC00pC9ad/1vWgtNqU6NJ9EHBF8gL6/2xI1sNqF+n6rN9nYfhM9QFkSe8DqCKlO ZvXSNt5+iggadX6/b+KWs2qeqHZ3CgFxsiHuYl8Cl0SIQbCawj2OOQleu/yqg++seeo2 D3KJKEG/7k2UKcm/p1gWMPdFfrhAK+o8rA+rr7hOjA+JC8qfYQak4EB+2eL7O4JZcyux kGEJrt7uFq6Cc4ny0hnjMnzIwes2y5c7i1MGqN0aUEWEoKYCTfmFthHe9f/QKCxEfnVk LDXQ== Received: by 10.14.188.10 with SMTP id z10mr4562998eem.28.1340115922416; Tue, 19 Jun 2012 07:25:22 -0700 (PDT) Received: from dhcp-144-254-56-191.cisco.com (dhcp-144-254-56-191.cisco.com. [144.254.56.191]) by mx.google.com with ESMTPS id c42sm76758357eeb.2.2012.06.19.07.25.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 07:25:21 -0700 (PDT) From: Mark Townsley Content-Type: multipart/alternative; boundary="Apple-Mail=_7DF8854B-E37C-444A-A8FE-B1DF489D88D6" Date: Tue, 19 Jun 2012 16:25:11 +0200 Message-Id: To: Softwires WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQke6vxbl+guOcxdqRdW8GQdUYCTMCrZAFMBD0QxWRkz+q+8Cw/9JvLi6GB3eKf0nDqGnt7N Cc: map46-tool-feedback@external.cisco.com Subject: [Softwires] Tool for Visualizing MAP Rules 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, 19 Jun 2012 14:25:24 -0000 --Apple-Mail=_7DF8854B-E37C-444A-A8FE-B1DF489D88D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Good day all, I asked a student of mine from Ecole Polytechnique that Cisco hired as = an intern for the summer to create a tool to help visualize IPv4 to IPv6 = address + port mapping. He's done a great job, and I thought we should = begin sharing the results. An Android and iPhone version is in the = works, but you'll have to wait a bit longer for that.=20 This is of course in "Beta", and comments/suggestions/etc. are welcome.=20= Please send feedback to map46-tool-feedback@external.cisco.com, cc'd on = this email. Here's the link: http://map46.cisco.com/ If its not obvious, the idea is that you can drag the prefix block = "borders" left and right to adjust the MAP parameters, while reporting = the sharing ratio and such in real time. You can add as many rules as = you like, save them in text form or in a link for emailing to your = friends, etc. You can even type in your own specific prefix, play around = with the "Advanced" mode for more information, or type in an address in = "Example" mode to show the precise mapping for a given rule.=20 The student's name is Arthur Lacoste, and is on the list above at least = until his internship is finished at the end of July.=20 Enjoy, - Mark --Apple-Mail=_7DF8854B-E37C-444A-A8FE-B1DF489D88D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Please send = feedback to map46-tool-feedback= @external.cisco.com, cc'd on this = email.

Here's the link:  http://map46.cisco.com/
If its not obvious, the idea is that you can drag the prefix = block "borders" left and right to adjust the MAP parameters, while = reporting the sharing ratio and such in real time. You can add as many = rules as you like, save them in text form or in a link for emailing to = your friends, etc. You can even type in your own specific prefix, play = around with the "Advanced" mode for more information, or type in an = address in "Example" mode to show the precise mapping for a given = rule. 

The student's name is Arthur = Lacoste, and is on the list above at least until his internship is = finished at the end of = July. 

Enjoy,

- = Mark

= --Apple-Mail=_7DF8854B-E37C-444A-A8FE-B1DF489D88D6-- From despres.remi@laposte.net Tue Jun 19 10:12: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 A6FE911E80B7 for ; Tue, 19 Jun 2012 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkAF0bQij9TA for ; Tue, 19 Jun 2012 10:12:44 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0111E8095 for ; Tue, 19 Jun 2012 10:12:43 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id EB6ED70000BC for ; Tue, 19 Jun 2012 19:12:41 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id BC1F970000D2 for ; Tue, 19 Jun 2012 19:12:41 +0200 (CEST) X-SFR-UUID: 20120619171241770.BC1F970000D2@msfrf2117.sfr.fr Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 19 Jun 2012 19:12:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C97157E-8EB1-4502-8FBC-6DBA2814CD29@laposte.net> References: To: Softwires WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Softwires] Novelty in draft-ietf-softwire-4rd-01 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, 19 Jun 2012 17:12:44 -0000 OOPS, Joel Hapern signaled me that the normal procedure hadn't been followed = (WG consensus _before_ posting a newly edited version).=20 Thanks to you, Joel, and sorry for this, due to my inexperience (first = time in this situation).=20 Please take version -01 as just one particular proposal, approved by = only the 5 authors so far. All comments, including objections, remain more than ever welcome. Regards, RD =20 =20 Le 2012-06-19 =E0 15:28, R=E9mi Despr=E9s a =E9crit : > Dear all, >=20 > The main difference between -00 and -O1 concerns protection against = address or protocol corruption during 4rd-domain traversal: > Problem: the CNP only protected IPv4 addresses of = full-or-shared-address CEs? In particular, they didn't protect IPv4 = addresses embedded in BR-destined IPv6 addresses (an overlook)=20 > Solution: include a checksum of IPv4 addresses and protocol in the = flow label field=20 > . It provides the desirable protection in a simple and intuitive way > . It remains compatible with the flow-label specification (see below) >=20 >=20 > Relationship with FLs of RFC6437 is analyzed as follows: >=20 > a) RFC6437 says "A node that forwards a flow whose flow label value in = arriving packets is zero MAY change the flow label value. In that case, = it is RECOMMENDED that the forwarding node sets the flow label field for = a flow to a uniformly distributed value as just described for source = nodes. ... In such cases, a flow can be defined by fewer IPv6 header = fields, typically using only the 2-tuple {dest addr, source addr}." >=20 > b) In CEs and BRs, arriving packets are IPv4, i.e. equivalent to = packets without FLs.=20 >=20 > c) In RFC2119, "RECOMMENDED" means that "there may exist valid reasons = in particular circumstances to ignore a particular item, but the full = implications must be understood and carefully weighed before choosing a = different course". >=20 > d) Implications, which have been well understood, have also been well = weighted: > - With this, FLs of 5-tuple flows aren't evenly distributed FLs, = contrary to what is recommended > - BUT this maintains IPv4 addresses-and-port protection without = needing any extra header between the IPv6 header and the unchanged IP = payload, a desirable feature of 4rd.=20 >=20 > Comments on all aspects of the proposal are welcome. >=20 > Regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From rdroms.ietf@gmail.com Tue Jun 19 17:20: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 8FA0C11E8149 for ; Tue, 19 Jun 2012 17:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3z-HhtOi5MM for ; Tue, 19 Jun 2012 17:20:28 -0700 (PDT) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id E63CA11E8141 for ; Tue, 19 Jun 2012 17:20:27 -0700 (PDT) Received: by qafl39 with SMTP id l39so3066369qaf.2 for ; Tue, 19 Jun 2012 17:20:27 -0700 (PDT) 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=bbzDLb/DNN8vTjx8mhAsSdMflTBbYkhvTVny0NeYBfk=; b=wfs5rqdsPPCElVcGASuDYo6bwGNDB08ghN5SnHpIHDOH0G/6vuTQQi1wseHbA1RgHU SBQLCmvg5RDWHRzPLXGJf5BUQ9cTvUkMK/Pvr5wWWPFbx+s1VS4FJrkL8nvWDtacrw8C zhPgAzAZwGnqCi+WhVDdHUsHtUINylKATHiPSQFykFBD/lHd6ZSESS+Wk395IO/bp8uB 7QNT9YfY9mtFT6FhAhL3sF6BJ/cpllQXtZEqzWJtlNYbirwjqCWm1zE4QSHk21pVAM8u 7frYdXgiBq2TN8A2pdystsE5e/tJqYXU9boqpP+wd0BiWQDIv0CB0g+RMlUo3+GhrbEm uJNA== Received: by 10.229.137.84 with SMTP id v20mr11042379qct.128.1340151627331; Tue, 19 Jun 2012 17:20:27 -0700 (PDT) Received: from che-vpn-cluster-2-352.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id ev6sm30057551qab.4.2012.06.19.17.20.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 17:20:25 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2012 18:20:23 -0600 Message-Id: <0F3914D4-A456-4B6C-B51C-ACBAA61B7C88@gmail.com> To: Softwires WG Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Softwires] New WG co-chair 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, 20 Jun 2012 00:20:28 -0000 After talking with several volunteers, I've selected Suresh Krishnan to = be softwires co-chair. Suresh has been a long term participant in the = IETF process and is the author of several RFCs. He has previously = chaired the dna working group in the IETF, and the mobopts research = group in the IRTF. He has also served as the chair of the IETF = nominations committee. He currently chairs the intarea working group. Thanks to all those who volunteered for the co-chair job, who gave me = the luxury of choosing the new co-chair from a pool of well-qualified = candidates. And, many thanks and gratitude to Alain for his efforts over many years = in organizing and guiding the WG through the production of several = protocols and 13 RFCs. - Ralph From bingxuere@gmail.com Wed Jun 20 00:28:04 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 A114821F8705 for ; Wed, 20 Jun 2012 00:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NR1SKtZwSs4C for ; Wed, 20 Jun 2012 00:28:03 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9831921F8707 for ; Wed, 20 Jun 2012 00:28:03 -0700 (PDT) Received: by yenq13 with SMTP id q13so6057646yen.31 for ; Wed, 20 Jun 2012 00:28:02 -0700 (PDT) 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=M/L9KPB8UAhbGBYi7fSboc/ukxNc4ebZvkmBrNouhgI=; b=D/na1n3Vi1EmPY1aQJArixn2oAaWozS9VNLRBeSHtO+hfU0aSkudiQfxYRLhMWtW55 D+5omSE5X4fCjbER+McVQe0aQ2IRHjsZEZxU+F05qKUh8vZf8As8eC00YEB1nUr3+xI9 PbQ1FwqzsrUyoQELN2v2ZQqKfpDFhOLxnoGzY3Tvjv2gatMl3Ghkrh4rER9oytoVHrQ5 tEOUz4/TvtPIe9TCprJHvIk/iwDm4U+h0XD8LksKheckF+5uU2C5bCosZm3qBTlqHwC/ iNu9QQ/2nsKrGLRNXhDCRE0/HO2Htgjf6y0fRjlWX1Wuqo6z4ITC+t2ylVwsJS2QSVMq HaKw== Received: by 10.50.208.106 with SMTP id md10mr3624807igc.54.1340177282494; Wed, 20 Jun 2012 00:28:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 20 Jun 2012 00:27:22 -0700 (PDT) In-Reply-To: References: <20120519141238.4345.1501.idtracker@ietfa.amsl.com> From: Qiong Date: Wed, 20 Jun 2012 15:27:22 +0800 Message-ID: To: Peng Wu Content-Type: multipart/alternative; boundary=14dae9340881dbf18f04c2e2565c Cc: Softwires WG Subject: Re: [Softwires] Fwd: New Version Notification for draft-cui-softwire-b4-translated-ds-lite-06.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: Wed, 20 Jun 2012 07:28:04 -0000 --14dae9340881dbf18f04c2e2565c Content-Type: text/plain; charset=UTF-8 Hi all, We have published the source code of lightweight 4over6 in sourceforge, for both TI and TC.: http://sourceforge.net/projects/laft6/ And there is an example for your configuration. You are welcome to run a test or redistribute it further, and please contact me if you have any problem : ) Best wishes Qiong On Thu, May 24, 2012 at 5:42 PM, Peng Wu wrote: > Hi all, > > We have pubished a new version of the lightweight 4over6 draft. The > draft describes a per-subscriber IPv4-over-IPv6 Hub & Spoke mechanism > with port-set provisioning support. > > The -06 version merges with draft-penno-softwire-sdnat-02 and makes > the draft compatible with both use cases. Among different provisoning > protocols, the authors choose DHCP as the mandated method, based on > the comments from IETF83 Softwire meeting. In this version, various > issues are settled and the preciseness of the mechanism description is > improved . > > The draft is available at > http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-06 > Please feel free to provide your comments:) > > Cheers~ > > ---------- Forwarded message ---------- > > > A new version of I-D, draft-cui-softwire-b4-translated-ds-lite-06.txt > has been successfully posted to the IETF repository. > > Filename: draft-cui-softwire-b4-translated-ds-lite > Revision: 06 > Title: Lightweight 4over6: An Extension to the DS-Lite > Architecture > Creation date: 2012-05-19 > WG ID: Individual Submission > Number of pages: 16 > > Abstract: > This document specifies an extension to DS-Lite called Lightweight > 4over6. This mechanism moves the translation function from the > tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the > mapping scale on the concentrator to a per-subscriber level. To > delegate the NAPT function to the initiators, port-restricted IPv4 > addresses are allocated to the initiators. > > > > > The IETF Secretariat > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --14dae9340881dbf18f04c2e2565c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,

We have published the source code of lightweight 4over6 in s= ourceforge, for both TI and TC.:
http://sourceforge.net/projects/laft6/

And there i= s an example for your=20 configuration.

You are welcome to run a test or redistribute it fur= ther, and please contact me if you have any problem : )

Best wishes<= br>Qiong

On Thu, May 24, 2012 at 5:42 PM,= Peng Wu <pengwu.thu@gmail.com> wrote:
Hi all,

We have pubished a new version of the lightweight 4over6 draft. The
draft describes a per-subscriber IPv4-over-IPv6 Hub & Spoke mechanism with port-set provisioning support.

The -06 version merges with draft-penno-softwire-sdnat-02 and makes
the draft compatible with both use cases. Among different provisoning
protocols, the authors choose DHCP as the mandated method, based on
the comments from IETF83 Softwire meeting. In this version, various
issues are settled and the preciseness of the mechanism description is
improved .

The draft is available at
http://tools.ietf.org/html/draft-cui-softwire-b4-= translated-ds-lite-06
Please feel free to provide your comments:)

Cheers~

---------- Forwarded message ----------


A new version of I-D, draft-cui-softwire-b4-translated-ds-lite-06.txt
has been successfully posted to the IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-cui-softwire-b4-translated-ds-li= te
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A006
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lightweight 4over6: An Extension = to the DS-Lite Architecture
Creation date: =C2=A0 2012-05-19
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 16

Abstract:
=C2=A0 This document specifies an extension to DS-Lite called Lightweight =C2=A0 4over6. =C2=A0This mechanism moves the translation function from the=
=C2=A0 tunnel concentrator (AFTR) to initiators (B4s), and hence reduces th= e
=C2=A0 mapping scale on the concentrator to a per-subscriber level. =C2=A0T= o
=C2=A0 delegate the NAPT function to the initiators, port-restricted IPv4 =C2=A0 addresses are allocated to the initiators.




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

--14dae9340881dbf18f04c2e2565c-- From ichiroumakino@gmail.com Wed Jun 20 05:47: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 C31A621F85E1 for ; Wed, 20 Jun 2012 05:47:05 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRw+geDhNkEC for ; Wed, 20 Jun 2012 05:47:05 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9F21F85DD for ; Wed, 20 Jun 2012 05:47:04 -0700 (PDT) Received: by eaaq13 with SMTP id q13so2676541eaa.31 for ; Wed, 20 Jun 2012 05:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PflXST+J8ivgROjP7TYzkRyqHIsTR6d+BZB6a0gtOUg=; b=R9zSnF/s8ww2ITlrP9B+BfsgfAuOz5Uje7+Ou9JlRId1wmMr4HGtfogy2R3QeQh9CB eali2FacWd9fxDBo2mEv0rUuS/ul0OH1VXQFSgbzhz6vvkmAaP9si9YPgYKosOWVQ4Jn hETg10klZyeWV53s3sfNyGuXv5w1iBJVZkr/Z5gb9+sqcxnn4P+fuXJtdt9TRlCiMTwf vdsppBCje0D91hreJCEwQdLzqMCZJ2DBH7Fcx0kZPBMIQnFZ6bXRd3hg2Gp0jYl8dGj4 2Rt5G1ssZqIgVJIi5bn7c4ib7hnYhmEBQ81B+msWiTaM0ZHnr3VcJHzoLJKeEcK89dGD x2sw== Received: by 10.14.47.129 with SMTP id t1mr4983775eeb.179.1340196424157; Wed, 20 Jun 2012 05:47:04 -0700 (PDT) Received: from ?IPv6:2001:420:44ff:fd17:b45a:9a74:ca16:15c8? ([2001:420:44ff:fd17:b45a:9a74:ca16:15c8]) by mx.google.com with ESMTPS id x52sm90128115eea.11.2012.06.20.05.47.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jun 2012 05:47:03 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <0F3914D4-A456-4B6C-B51C-ACBAA61B7C88@gmail.com> Date: Wed, 20 Jun 2012 14:46:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E693E04-884C-460D-95B8-32C49216EBD9@employees.org> References: <0F3914D4-A456-4B6C-B51C-ACBAA61B7C88@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1278) Cc: Softwires WG Subject: Re: [Softwires] New WG co-chair 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, 20 Jun 2012 12:47:05 -0000 > After talking with several volunteers, I've selected Suresh Krishnan = to be softwires co-chair. Suresh has been a long term participant in = the IETF process and is the author of several RFCs. He has previously = chaired the dna working group in the IETF, and the mobopts research = group in the IRTF. He has also served as the chair of the IETF = nominations committee. He currently chairs the intarea working group. a grand choice indeed! cheers, Ole= From mark@townsley.net Wed Jun 20 15:56: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 59A6721F8542 for ; Wed, 20 Jun 2012 15:56:16 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFhkvLqe9RU3 for ; Wed, 20 Jun 2012 15:56:15 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3B7E11E80A5 for ; Wed, 20 Jun 2012 15:56:14 -0700 (PDT) Received: by eaaq13 with SMTP id q13so73eaa.31 for ; Wed, 20 Jun 2012 15:56:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=cW79uO3s343eFo79wpYsNvW6+ZAxN0EFu9hU8QSVFYE=; b=Xq4wzc20INKxJJLeLy2EgJaSmqsCS2aeSij+p/3xJYBIThpzHWVWeW+7sRKMs9IaZ0 WLLhH8m9o3X6KxPyIGwcbZnCBH9lYY07RYK6x2hVTM/c0MphoSMHdpnvlUwvy/205Wh6 Bdts+tJmyenlEMIaVaCsG69MTNamgri84hkCpUfdOtkzNR4MTSJX8VK3uGG8P2DsdUNH A0n/+NAeJwDTnoz23VZ4enAk79VzhGfenbLg5Ng5IJHVszpEZLGTgLvAFw8NnZJsAAlk +RztDijXWRJY6uB1zW550kaMQb+TOHL8SngvcrNlc5HeJe/Ry1YfyjZ1JDHWWERSUG7Q ROCg== Received: by 10.14.22.67 with SMTP id s43mr5279459ees.153.1340232973719; Wed, 20 Jun 2012 15:56:13 -0700 (PDT) Received: from ams-townsley-8918.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id q53sm96527517eef.8.2012.06.20.15.56.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jun 2012 15:56:13 -0700 (PDT) From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_9756387B-D881-486A-8AC4-5ECCEA5D63AF" Date: Thu, 21 Jun 2012 00:56:10 +0200 In-Reply-To: To: Softwires WG References: Message-Id: <1561736C-CBAA-4219-8B69-AD48362CDAFA@townsley.net> X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlSqqJhdfYnp98AniWBa1aLmaTFz4SF87yWYXlMEzmYYNudTV/RWgQXSq1Xcn2NDwt3E/vS Subject: Re: [Softwires] Tool for Visualizing MAP Rules 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, 20 Jun 2012 22:56:16 -0000 --Apple-Mail=_9756387B-D881-486A-8AC4-5ECCEA5D63AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 A video showing the tool in action: http://www.youtube.com/watch?v=3DCqHBjO-QbSQ - Mark On Jun 19, 2012, at 4:25 PM, Mark Townsley wrote: >=20 > Good day all, >=20 > I asked a student of mine from Ecole Polytechnique that Cisco hired as = an intern for the summer to create a tool to help visualize IPv4 to IPv6 = address + port mapping. He's done a great job, and I thought we should = begin sharing the results. An Android and iPhone version is in the = works, but you'll have to wait a bit longer for that.=20 >=20 > This is of course in "Beta", and comments/suggestions/etc. are = welcome.=20 > Please send feedback to map46-tool-feedback@external.cisco.com, cc'd = on this email. >=20 > Here's the link: http://map46.cisco.com/ >=20 > If its not obvious, the idea is that you can drag the prefix block = "borders" left and right to adjust the MAP parameters, while reporting = the sharing ratio and such in real time. You can add as many rules as = you like, save them in text form or in a link for emailing to your = friends, etc. You can even type in your own specific prefix, play around = with the "Advanced" mode for more information, or type in an address in = "Example" mode to show the precise mapping for a given rule.=20 >=20 > The student's name is Arthur Lacoste, and is on the list above at = least until his internship is finished at the end of July.=20 >=20 > Enjoy, >=20 > - Mark >=20 --Apple-Mail=_9756387B-D881-486A-8AC4-5ECCEA5D63AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =
A video showing the tool in = action:


- = Mark

On Jun 19, 2012, at 4:25 PM, Mark Townsley = wrote:


Good = day all,

I asked a student of mine from Ecole = Polytechnique that Cisco hired as an intern for the summer to create a = tool to help visualize IPv4 to IPv6 address + port mapping. He's done a = great job, and I thought we should begin sharing the results. An Android = and iPhone version is in the works, but you'll have to wait a bit longer = for that. 

This is of course in "Beta", = and comments/suggestions/etc. are welcome. 
Please send = feedback to map46-tool-feedback= @external.cisco.com, cc'd on this = email.

Here's the link:  http://map46.cisco.com/
If its not obvious, the idea is that you can drag the prefix = block "borders" left and right to adjust the MAP parameters, while = reporting the sharing ratio and such in real time. You can add as many = rules as you like, save them in text form or in a link for emailing to = your friends, etc. You can even type in your own specific prefix, play = around with the "Advanced" mode for more information, or type in an = address in "Example" mode to show the precise mapping for a given = rule. 

The student's name is Arthur = Lacoste, and is on the list above at least until his internship is = finished at the end of = July. 

Enjoy,

- = Mark


= --Apple-Mail=_9756387B-D881-486A-8AC4-5ECCEA5D63AF-- From despres.remi@laposte.net Thu Jun 21 06:26:46 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 4B22E21F84D6 for ; Thu, 21 Jun 2012 06:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFW9Im3MlLOT for ; Thu, 21 Jun 2012 06:26:45 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id B798C21F8617 for ; Thu, 21 Jun 2012 06:26:43 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id A08F77000043; Thu, 21 Jun 2012 15:26:42 +0200 (CEST) Received: from [192.168.1.73] (150.204.170.89.rev.sfr.net [89.170.204.150]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 5A13B7000081; Thu, 21 Jun 2012 15:26:40 +0200 (CEST) X-SFR-UUID: 20120621132642369.5A13B7000081@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FE310FF.4080407@gmail.com> Date: Thu, 21 Jun 2012 15:26:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9145DA09-F2C1-4BAE-B64C-9E51A50132EE@laposte.net> References: <2D9BB595-FAF1-4830-A41C-29C05E4F25A7@laposte.net> <4FE310FF.4080407@gmail.com> To: Softwires WG X-Mailer: Apple Mail (2.1084) Subject: [Softwires] 3-tuple based FL in 4rd tunnels 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, 21 Jun 2012 13:26:46 -0000 Hi, all, Brian reacted privately to the proposed use of flow labels in 4rd. Since his comments below are IMHO of general interest, here they are = with my own reaction (and with his permission) =20 2012-06-21 14:18, Brian E Carpenter: > R=E9mi, >=20 > As I understand it, this flow label value would exist only for > the portion of the path that is in fact a v4-in-v6 tunnel, > localised to the ISP infrastructure. That seems OK. >=20 > The checksum value will be constant for a given traffic flow. It > will be somewhat random because that is the nature of a > checksum. Thus, it seems to me that it will be useful if the ISP > has any ECMP or LAG in place (RFC 6438). ... > you could choose to put a 4 bit pseudorandom number in > the remaining 4 bits, generated by a further stateless hash of > the IPv4 5-tuple. That would improve the distribution of the > flow label values, and would be very close to RFC 6437 and 6438, > if not fully conformant. Interesting IMHO, with two comments: - It would be applicable only to a list of L4 protocols known to have = ports at the beginning of IP payloads. - It could be added as a MAY, to avoid imposing its complexity to all = implementations. ... > (You can copy this to softwire if useful.) More opinions from the WG? Regards, RD > On 2012-06-19 08:36, R=E9mi Despr=E9s wrote: >> Hi, Brian, >>=20 >> In the still progressing 4rd design, flow labels happen to be >> a convenient tool to maintain, after 4rd domain traversal, >> IPv4-like protection of addresses and protocol. For this, >> each tunnel packet has an address-and-protocol checksum set >> in its FL. >>=20 >> This is understood to be compatible with RFC6437 because: >>=20 >> a) RFC6437 says "A node that forwards a flow whose flow label >> value in arriving packets is zero MAY change the flow label >> value. In that case, it is RECOMMENDED that the forwarding >> node sets the flow label field for a flow to a uniformly >> distributed value as just described for source nodes. ... In >> such cases, a flow can be defined by fewer IPv6 header >> fields, typically using only the 2-tuple {dest addr, source >> addr}." >>=20 >> b) In CEs and BRs, arriving packets are IPv4, i.e. equivalent >> to packets without FLs. >>=20 >> c) In RFC2119, "RECOMMENDED" means that "there may exist >> valid reasons in particular circumstances to ignore a >> particular item, but the full implications must be understood >> and carefully weighed before choosing a different course". >>=20 >> d) Implications, which are are well understood, are also well >> weighted (5-tuple flows aren't distinguished, which isn't >> recommended, but this is to maintain IPv4 addresses-and-port >> protection without extra header between IPv6 header and IP >> payload). >>=20 >>=20 >> Is this for you a correct interpretation? >>=20 >> Thanks, RD >>=20 >=20 From sarikaya2012@gmail.com Thu Jun 21 11:23: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 A5DED21F8781 for ; Thu, 21 Jun 2012 11:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDdCy-05R1xv for ; Thu, 21 Jun 2012 11:23:35 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0C23A21F8659 for ; Thu, 21 Jun 2012 11:23:34 -0700 (PDT) Received: by yhp26 with SMTP id 26so1305409yhp.26 for ; Thu, 21 Jun 2012 11:23:34 -0700 (PDT) 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:content-type; bh=HgJOvLMbELdSvrbCQfWLvXSYUgDaxyTNPDuGoB1ygrI=; b=DQbB8kQRFU4EI/oUcXqKd4kwICqlGDA0FzR59aN/SbN2TlvrdNVghUdYO1Mmp0/Urf vP6j+9hk1CuWzkR3JYsLhoJVQ751UlViG4XyPioH+qQO1ij63ZIfr0triujrwLpaN4mM fDezXi9Fi1TI2FuQ8c6PnjC30MlVrrbE8KN9I+jShqRgzqiP2i5tt9rim8zUmoatWUiG nAko/V8QD3vPWai3bw0Pg8HIPBg3q27m7k8vLw/Wvs2K6PKl1fj+y4Y+WbtXtwxVC/Ya gZONP7rRKRLKmV1NyH/WOozW9vC1Vhhdsc7aA/1owcnsqkvhtZhm9o5HM/rOqMOT8n47 IUjQ== MIME-Version: 1.0 Received: by 10.50.40.193 with SMTP id z1mr8611855igk.0.1340303014322; Thu, 21 Jun 2012 11:23:34 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Thu, 21 Jun 2012 11:23:34 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 21 Jun 2012 13:23:34 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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: Thu, 21 Jun 2012 18:23:37 -0000 Folks, We have published revised version of our draft on multicast extensions to DS-Lite at http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt We think that this draft should be part of draft-ietf-softwire-dslite-multicast. Regards, Behcet From despres.remi@laposte.net Fri Jun 22 09:52: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 0F53721F86BD for ; Fri, 22 Jun 2012 09:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XfgjaoNigTF for ; Fri, 22 Jun 2012 09:52:29 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3076721F86B4 for ; Fri, 22 Jun 2012 09:52:28 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2203.sfr.fr (SMTP Server) with ESMTP id BEFEF7000098; Fri, 22 Jun 2012 18:52:25 +0200 (CEST) Received: from [192.168.1.73] (80.204.170.89.rev.sfr.net [89.170.204.80]) by msfrf2203.sfr.fr (SMTP Server) with ESMTP id ED392700008C; Fri, 22 Jun 2012 18:52:24 +0200 (CEST) X-SFR-UUID: 20120622165224971.ED392700008C@msfrf2203.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Jun 2012 18:52:24 +0200 Message-Id: To: Yong Cui , Suresh Krishnan , Ralph Droms Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Ole Troan Subject: [Softwires] A new consensus opportunity with a MAP-bis 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, 22 Jun 2012 16:52:30 -0000 Yong, Suresh, Ralph, For mesh stateless v4/v6, we have so far a choice between only two = solutions, MAP as is and 4rd. On can hope that the consensus that couldn't be reached in Paris will be = achievable in Vancouver, but this isn't sure, each "camp" keeping its = own expectation. Looking at recent history, we can remember that, not long ago, the = chair's approach was to have 3 specifications completed (MAP-T, MAP-E, = and MAP-H, as Alain called it with H for Hybrid), and then to choose = only one for standardization. After that, promoters of either -T and -E decided to merge -T and -E in = a non-separable specification, as reflected in = draft-ietf-softwire-map-00.=20 Thus, the choice has become between a "two-variants" specification (MAP) = and a "single-variant" specification (4rd). In this context, a larger choice might well be the best chance for a WG = consensus. It would include a MAP specification in which the forwarding = mode of 4rd would be added as 3rd, say a "MAP-bis" .=20 With this MAP-bis: - vendors have to support 3 forwarding modes, which isn't ideal, but = most of the design, in particular in what concerns mapping rules, = remains common (Alain once said, possibly with optimism, the three were = 99% identical!)=20 - operators have a free choice between T, E, or H, based on their = operational preferences. - we have (at last) a stabilized design with no one badly frustrated. If this approach makes sense for the WG, I can do the work of editing a = MAP-bis proposal (taking the current MAP specification, adding a section = that describes the hybrid forwarding mode, and adding a third variant in = the address-format section).=20 My personal preference remains for 4rd as single standard, but a choice = between MAP-as-is, MAP-bis, and 4rd, is IMHO a sounder choice for the WG = than just between MAP-as-is and 4rd. Hoping that this will be found constructive, Best regards, RD From satoru.matsushima@gmail.com Sat Jun 23 01:52:10 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 4252721F8517 for ; Sat, 23 Jun 2012 01:52:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-sSQcg1MGex for ; Sat, 23 Jun 2012 01:52:09 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3582621F8514 for ; Sat, 23 Jun 2012 01:52:09 -0700 (PDT) Received: by dacx6 with SMTP id x6so3329331dac.31 for ; Sat, 23 Jun 2012 01:52:09 -0700 (PDT) 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=+ZH/xvUOTii2/iw7ZLfUi/m03acGylc8EcIT4/DoLhU=; b=DvE/V0Sv64O17gJB0fn4mstgNxOBuad/XmGzaqAWw3k5DWOLLT3PMv2dKvoxMb3kLH dVFgSPbpPrnEfx6SY7N8eZiWaqRrPeNtyJbn8USgccaTXujpEojIysKR3Q0OTanCk1vS 9FbgtgYirOwBR+JK6BP9iul5gYg8UwZD/OplLdHazYc9oVC/P4DUD9uSXrBQ2rfgvu4U Yc++Sxl7p5pKpw3Rz0YkjZoxYCkIiAjbpF41uZj0XooVZ8q8wK60iW7oiN97k54O2usO NrGXGHha8PnI7swsktkzPq/kwVTBV71yIeMemvOT6Jm9HPqf6eDYYDV/XNpUQGyGJR7j +EYQ== Received: by 10.68.132.166 with SMTP id ov6mr19364916pbb.24.1340441528955; Sat, 23 Jun 2012 01:52:08 -0700 (PDT) Received: from [192.168.3.3] (softbank126044192158.bbtec.net. [126.44.192.158]) by mx.google.com with ESMTPS id ny10sm1768780pbb.38.2012.06.23.01.52.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jun 2012 01:52:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: Date: Sat, 23 Jun 2012 17:52:03 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= X-Mailer: Apple Mail (2.1278) Cc: Ole Troan , Ralph Droms , Yong Cui , Softwires WG Subject: Re: [Softwires] A new consensus opportunity with a MAP-bis 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, 23 Jun 2012 08:52:10 -0000 Dear Remi, Thank you for a kind offer. It would be a very positive compromise for = us. However, in the context of making another new stream document, which = MAP-bis as you said, I decline it. Nevertheless, if you abandon 4rd = work, I'm very welcome you as an author of MAP. Best regards, --satoru On 2012/06/23, at 1:52, R=C3=A9mi Despr=C3=A9s wrote: > Yong, Suresh, Ralph, >=20 > For mesh stateless v4/v6, we have so far a choice between only two = solutions, MAP as is and 4rd. > On can hope that the consensus that couldn't be reached in Paris will = be achievable in Vancouver, but this isn't sure, each "camp" keeping its = own expectation. >=20 > Looking at recent history, we can remember that, not long ago, the = chair's approach was to have 3 specifications completed (MAP-T, MAP-E, = and MAP-H, as Alain called it with H for Hybrid), and then to choose = only one for standardization. >=20 > After that, promoters of either -T and -E decided to merge -T and -E = in a non-separable specification, as reflected in = draft-ietf-softwire-map-00.=20 > Thus, the choice has become between a "two-variants" specification = (MAP) and a "single-variant" specification (4rd). >=20 > In this context, a larger choice might well be the best chance for a = WG consensus. It would include a MAP specification in which the = forwarding mode of 4rd would be added as 3rd, say a "MAP-bis" .=20 > With this MAP-bis: > - vendors have to support 3 forwarding modes, which isn't ideal, but = most of the design, in particular in what concerns mapping rules, = remains common (Alain once said, possibly with optimism, the three were = 99% identical!)=20 > - operators have a free choice between T, E, or H, based on their = operational preferences. > - we have (at last) a stabilized design with no one badly frustrated. >=20 > If this approach makes sense for the WG, I can do the work of editing = a MAP-bis proposal (taking the current MAP specification, adding a = section that describes the hybrid forwarding mode, and adding a third = variant in the address-format section).=20 >=20 > My personal preference remains for 4rd as single standard, but a = choice between MAP-as-is, MAP-bis, and 4rd, is IMHO a sounder choice for = the WG than just between MAP-as-is and 4rd. >=20 > Hoping that this will be found constructive, > Best regards, > RD >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From bingxuere@gmail.com Sat Jun 23 22: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 49F9321F86D1 for ; Sat, 23 Jun 2012 22:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-1.373, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-3QXLyTvwQ4 for ; Sat, 23 Jun 2012 22:36:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1821F86C7 for ; Sat, 23 Jun 2012 22:36:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5169763obb.31 for ; Sat, 23 Jun 2012 22:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=A5u5HR8Qd1vxjHg82OJ+N6chpZVGuwPA5JTm8T9+ZR0=; b=M9ZXICRTyqHQyIPyB6Bz5/NQZLeiuFshBDSaEOOJfVQ46fZ0iOAJOVbE+9eCNAg7+A gyntf98NVVHEJwaDwyq5sfqHsyodBM6Nr0xH5Z816Q68GS0JXJQ3YExDWLpzcA0Q4JI/ 8IStqobEuhACLYjhhB4iS28x8tnmMnaClGWWtn5DaxJbIQQoZB0lVqLan6ugC8HpqiUq GAu4J7YjQNcGdKJFxQbANAZjo8QsiMhdei8JdLoNCkaFDq41W00Bst9B4E45b4ZV1gFe rL1G80xI58jkEksGLkA6LS01N8X1Zx26biC58qheLvgn3VQqgsRqKIoaaN2o52s3om7R 9SHA== Received: by 10.50.149.198 with SMTP id uc6mr5240248igb.2.1340516193147; Sat, 23 Jun 2012 22:36:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Sat, 23 Jun 2012 22:35:53 -0700 (PDT) From: Qiong Date: Sun, 24 Jun 2012 13:35:53 +0800 Message-ID: To: softwires@ietf.org Content-Type: multipart/alternative; boundary=e89a8f3ba30d821cf904c3313f18 Cc: Yong Cui Subject: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 24 Jun 2012 05:36:35 -0000 --e89a8f3ba30d821cf904c3313f18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, As we all know, once an individual draft is adopted as a WG draft, it is owned by the whole WG, rather than just the editors. Just as Remi said, the normal procedure to follow is to reach WG consensus _before_ posting a newly edited version. >From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf-softwire-map-00, there are several changes between them. In particular, the newly introduced "1:1 mode", which decouples IPv4 and IPv6 addressing, has never been discussed openly in the WG mailing list, or even in the MAP design team eit= her. Actually, this "1:1 mode" is against the stateless-4v6-motivation draft. The motivation draft has clearly defines the "Stateless 4/6 solution" as follows: Stateless 4/6 solution denotes a solution which does not require any per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. AFAIK what the WG has adopted MAP related draft is draft-mdt-softwire-mapping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the stateless solution should =E2=80=9Cresponse to the solution motivation document=E2=80=9D according to= the Softwire charter. That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. We can all recall that our softwire WG has worked on stateless solutions for more than one and a half years, and we have achieved a lot of work which has been documented in charter, stateless motivation, 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic "stateless" principle and the MAP design team is also working on it together to find a better algorithm, address format, etc. So it is really not appropriate to make such changes when MAP is adopted as a WG item in such a short time. >From this perspective, draft-ietf-softwire-map-00 can only be regarded as draft-XX-softwire-mapping-address-and-port-04. It is not even the output of MAP design team. Best wishes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 --e89a8f3ba30d821cf904c3313f18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj4KPGRpdj5IacKgYWxsLDwvZGl2Pgo8ZGl2PsKgPC9kaXY+CjxkaXY+QXPCoHdlwqBhbGzC oGtub3cswqBvbmNlwqBhbsKgaW5kaXZpZHVhbMKgZHJhZnTCoGlzwqBhZG9wdGVkwqBhc8KgYcKg V0fCoGRyYWZ0LMKgaXTCoGlzwqBvd25lZMKgYnnCoHRoZcKgd2hvbGXCoFdHLMKgcmF0aGVywqB0 aGFuwqBqdXN0wqB0aGXCoGVkaXRvcnMuwqBKdXN0wqBhc8KgUmVtacKgc2FpZCzCoHRoZcKgbm9y bWFswqBwcm9jZWR1cmXCoHRvwqBmb2xsb3fCoGlzwqB0b8KgcmVhY2jCoFdHwqBjb25zZW5zdXPC oF9iZWZvcmVfwqBwb3N0aW5nwqBhwqBuZXdsecKgZWRpdGVkwqB2ZXJzaW9uLsKgPC9kaXY+CgoK PGRpdj7CoDwvZGl2Pgo8ZGl2PkZyb23CoGRyYWZ0LW1kdC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJl c3MtYW5kLXBvcnQtMDPCoHRvwqBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCzCoHRoZXJlwqBh cmXCoHNldmVyYWzCoGNoYW5nZXPCoGJldHdlZW7CoHRoZW0uwqBJbsKgcGFydGljdWxhcizCoHRo ZcKgbmV3bHnCoGludHJvZHVjZWTCoCZxdW90OzE6McKgbW9kZSZxdW90OyzCoHdoaWNowqBkZWNv dXBsZXPCoElQdjTCoGFuZMKgSVB2NsKgYWRkcmVzc2luZyzCoGhhcyBuZXZlciBiZWVuIGRpc2N1 c3NlZMKgb3Blbmx5wqBpbsKgdGhlwqBXR8KgbWFpbGluZ8KgbGlzdCzCoG9ywqBldmVuwqBpbsKg dGhlwqBNQVDCoGRlc2lnbsKgdGVhbcKgZWl0aGVyLjwvZGl2PgoKCjxkaXY+wqA8L2Rpdj4KPGRp dj5BY3R1YWxseSzCoHRoaXPCoCZxdW90OzE6McKgbW9kZSZxdW90O8KgaXPCoGFnYWluc3TCoHRo ZcKgc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uwqBkcmFmdC7CoFRoZcKgbW90aXZhdGlvbsKgZHJh ZnTCoGhhc8KgY2xlYXJsecKgZGVmaW5lc8KgdGhlwqAmcXVvdDtTdGF0ZWxlc3PCoDQvNsKgc29s dXRpb24mcXVvdDvCoGFzwqBmb2xsb3dzOjwvZGl2PgoKPGRpdj48YnI+U3RhdGVsZXNzwqA0LzbC oHNvbHV0aW9uwqBkZW5vdGVzwqBhwqBzb2x1dGlvbsKgd2hpY2jCoGRvZXPCoG5vdMKgcmVxdWly ZcKgYW55wqBwZXItdXNlcsKgc3RhdGXCoChzZWXCoFNlY3Rpb27CoDIuM8Kgb2bCoFtSRkMxOTU4 XSnCoHRvwqBiZcKgbWFpbnRhaW5lZMKgYnnCoGFuecKgSVDCoGFkZHJlc3PCoHNoYXJpbmfCoGZ1 bmN0aW9uwqBpbsKgdGhlwqBTZXJ2aWNlwqBQcm92aWRlciYjMzk7c8KgbmV0d29yay7CoFRoaXPC oGNhdGVnb3J5wqBvZsKgc29sdXRpb25zwqBhc3N1bWVzwqBhwqBkZXBlbmRlbmN5wqBiZXR3ZWVu wqBhbsKgSVB2NsKgcHJlZml4wqBhbmTCoElQdjTCoGFkZHJlc3MuPC9kaXY+CgoKPGRpdj7CoDwv ZGl2Pgo8ZGl2PkFGQUlLwqB3aGF0wqB0aGXCoFdHwqBoYXPCoGFkb3B0ZWTCoE1BUMKgcmVsYXRl ZMKgZHJhZnTCoGlzwqBkcmFmdC1tZHQtc29mdHdpcmUtbWFwcGluZy1hZGRyZXNzLWFuZC1wb3J0 LTAzLMKgTk9UwqBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMC7CoEFuZMKgdGhlwqBzdGF0ZWxl c3PCoHNvbHV0aW9uwqBzaG91bGTCoOKAnHJlc3BvbnNlwqB0b8KgdGhlwqBzb2x1dGlvbsKgbW90 aXZhdGlvbsKgZG9jdW1lbnTigJ3CoGFjY29yZGluZ8KgdG/CoHRoZcKgU29mdHdpcmXCoGNoYXJ0 ZXIuwqBUaGF0wqBtZWFuc8KgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDDCoElTwqBOT1TCoFFV QUxJRklFRMKgdG/CoGJlwqBhwqBXR8KgZHJhZnQuwqA8L2Rpdj4KCgo8ZGl2PsKgPC9kaXY+Cjxk aXY+V2XCoGNhbsKgYWxswqByZWNhbGzCoHRoYXTCoG91csKgc29mdHdpcmXCoFdHwqBoYXPCoHdv cmtlZMKgb27CoHN0YXRlbGVzc8Kgc29sdXRpb25zwqBmb3LCoG1vcmXCoHRoYW7CoG9uZcKgYW5k wqBhwqBoYWxmwqB5ZWFycyzCoGFuZMKgd2XCoGhhdmXCoGFjaGlldmVkwqBhwqBsb3TCoG9mwqB3 b3JrwqB3aGljaMKgaGFzwqBiZWVuwqBkb2N1bWVudGVkwqBpbsKgY2hhcnRlcizCoHN0YXRlbGVz c8KgbW90aXZhdGlvbizCoDRyZC12YXJpZW50cyzCoE1BUC0wMyzCoGV0Yy7CoEFGQUlLwqBhbGzC oHRoZcKgYXV0aG9yc8KgaGF2ZcKga2VwdMKgdGhlwqBiYXNpY8KgJnF1b3Q7c3RhdGVsZXNzJnF1 b3Q7wqBwcmluY2lwbGXCoGFuZMKgdGhlwqBNQVDCoGRlc2lnbsKgdGVhbcKgaXPCoGFsc2/CoHdv cmtpbmfCoG9uwqBpdMKgdG9nZXRoZXLCoHRvwqBmaW5kwqBhwqBiZXR0ZXLCoGFsZ29yaXRobSzC oGFkZHJlc3PCoGZvcm1hdCzCoGV0Yy7CoFNvwqBpdMKgaXPCoHJlYWxsecKgbm90wqBhcHByb3By aWF0ZcKgdG/CoG1ha2XCoHN1Y2jCoGNoYW5nZXPCoHdoZW7CoE1BUMKgaXPCoGFkb3B0ZWTCoGFz wqBhwqBXR8KgaXRlbcKgaW7CoHN1Y2jCoGHCoHNob3J0wqB0aW1lLsKgPC9kaXY+CgoKPGRpdj7C oDwvZGl2Pgo8ZGl2PkZyb23CoHRoaXPCoHBlcnNwZWN0aXZlLMKgZHJhZnQtaWV0Zi1zb2Z0d2ly ZS1tYXAtMDDCoGNhbsKgb25secKgYmXCoHJlZ2FyZGVkwqBhc8KgZHJhZnQtWFgtc29mdHdpcmUt bWFwcGluZy1hZGRyZXNzLWFuZC1wb3J0LTA0LsKgSXTCoGlzwqBub3TCoGV2ZW4gdGhlIG91dHB1 dCBvZsKgTUFQwqBkZXNpZ27CoHRlYW0uPC9kaXY+PC9kaXY+PGJyPkJlc3Qgd2lzaGVzPGJyPjxi cj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPgoKUWlv bmcgU3VuPGJyPkNoaW5hIFRlbGVjb20gQmVpamluZyBSZXNlYXJjaCBJbnN0aXR1ZGU8YnI+PGJy Pjxicj5PcGVuIHNvdXJjZSBjb2RlOjxicj5saWdodHdlaWdodCA0b3ZlcjY6IDxpPjxhIGhyZWY9 Imh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni88L2E+PC9pPjxicj4KClBDUC1u YXRjb29yZDo8aT4gPGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9wY3Bw b3J0c2V0ZGVtby8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2pl Y3RzL3BjcHBvcnRzZXRkZW1vLzwvYT4gPC9pPjxicj49PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTxicj48YnI+PGJyPgo= --e89a8f3ba30d821cf904c3313f18-- From satoru.matsushima@gmail.com Sat Jun 23 23:00: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 B19C921F8657 for ; Sat, 23 Jun 2012 23:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP1KmcvKNJmY for ; Sat, 23 Jun 2012 23:00:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7E5621F86BA for ; Sat, 23 Jun 2012 23:00:27 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5272028pbc.31 for ; Sat, 23 Jun 2012 23:00:27 -0700 (PDT) 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=QR2N+EDbJbWLMMqC4U5q60pxADvhdFLrrRzAYEeuTmc=; b=S8eyAEJF1/smdkxRvYQIiM+3jx0NLKlJmoAWdUJOsG3AKq1sDiaNmoywRL2LPh/YS/ EvPNDZjpx7g3cw297zSbuSkcFtWBDV0hQA3Cq/GlHGgHnzkw1wpbj2qyOFl6iySZEor9 B2np7UI6aMhoop64ksyKuZZENfvOx89qHt2gfV/9mejdPJ4JHA3HGydR4HfioVBLtjAd CH01eKxqOJ8tiGcDn/lqEvBsy17FzNrJrAc95v+nLgM583eE/BTUMNPsjtOBUiF5iTHP MOrpf0c6jHtanPETsmLWF9dtT+3kzd2qdpkqqcwe2NdlVdEWsAkuJK/w8q9nAW+U/KXk AVwg== Received: by 10.68.195.167 with SMTP id if7mr27671194pbc.16.1340517627498; Sat, 23 Jun 2012 23:00:27 -0700 (PDT) Received: from [192.168.3.14] (softbank126044192158.bbtec.net. [126.44.192.158]) by mx.google.com with ESMTPS id rg9sm4413408pbc.67.2012.06.23.23.00.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 23 Jun 2012 23:00:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-2022-jp From: Satoru Matsushima In-Reply-To: Date: Sun, 24 Jun 2012 15:00:22 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> References: To: Qiong X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 24 Jun 2012 06:00:29 -0000 Hi Qiong, I'm disagree with your opinion. 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in = the DT. 2. MAP just covers so called '1:1 mode' with most granular mapping rule = for CEs provisioning, which is as one of its characteristics. 3. The motivation draft does not restrict that as you stated, just = 'assumed', it's neither 'MUST' nor 'SHOULD'. Best regards, --satoru On 2012/06/24, at 14:35, Qiong wrote: > Hi all, > =20 > As we all know, once an individual draft is adopted as a WG draft, it = is owned by the whole WG, rather than just the editors. Just as Remi = said, the normal procedure to follow is to reach WG consensus _before_ = posting a newly edited version.=20 > =20 > =46rom draft-mdt-softwire-mapping-address-and-port-03 to = draft-ietf-softwire-map-00, there are several changes between them. In = particular, the newly introduced "1:1 mode", which decouples IPv4 and = IPv6 addressing, has never been discussed openly in the WG mailing list, = or even in the MAP design team either. > =20 > Actually, this "1:1 mode" is against the stateless-4v6-motivation = draft. The motivation draft has clearly defines the "Stateless 4/6 = solution" as follows: >=20 > Stateless 4/6 solution denotes a solution which does not require any = per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP = address sharing function in the Service Provider's network. This = category of solutions assumes a dependency between an IPv6 prefix and = IPv4 address. > =20 > AFAIK what the WG has adopted MAP related draft is = draft-mdt-softwire-mapping-address-and-port-03, NOT = draft-ietf-softwire-map-00. And the stateless solution should = =1B$B!H=1B(Bresponse to the solution motivation document=1B$B!I=1B(B = according to the Softwire charter. That means draft-ietf-softwire-map-00 = IS NOT QUALIFIED to be a WG draft.=20 > =20 > We can all recall that our softwire WG has worked on stateless = solutions for more than one and a half years, and we have achieved a lot = of work which has been documented in charter, stateless motivation, = 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic = "stateless" principle and the MAP design team is also working on it = together to find a better algorithm, address format, etc. So it is = really not appropriate to make such changes when MAP is adopted as a WG = item in such a short time.=20 > =20 > =46rom this perspective, draft-ietf-softwire-map-00 can only be = regarded as draft-XX-softwire-mapping-address-and-port-04. It is not = even the output of MAP design team. >=20 > Best wishes >=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 From sunqi.csnet.thu@gmail.com Sun Jun 24 01:52:41 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 4F4EF21F8625 for ; Sun, 24 Jun 2012 01:52:41 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK3IWFkIHkRp for ; Sun, 24 Jun 2012 01:52:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE4B21F8624 for ; Sun, 24 Jun 2012 01:52:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5354476pbc.31 for ; Sun, 24 Jun 2012 01:52:35 -0700 (PDT) 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:content-transfer-encoding; bh=Zh+ZCVm1NC/Zsp05RWnsmMJTL6puIZwTJAbFYhPGcYY=; b=mRC4Mc6ombHU9+Gk1uw+fxPVHAI386NoXu9TKJOYshH5zbUBnTQGjGV34M10hKdxTL mf69u61DRb44Yd4Nyb4VTy0e8yei7IAUXAgBdwmv6fDlngIbZQKVgGBUUFE8p+4Xoa57 z4hcVniJyhxCHuezIOQ1TdaLO50o89vXsQHqunoozpeKzd1iurL0nBgSaoozMOISUTjn dP0juCYS8uj88AiAzfO8abYOg0AHZRoXUOsjRRu6KweZExrQNq+paljA/glwMLsjkv1s 6c7IYoJm6naiNJRa5GyPKc/bQVmsQ4sp6bHsX3fYnj9av/GsS373nzBWrThPKpmH28cq JEUg== MIME-Version: 1.0 Received: by 10.68.225.6 with SMTP id rg6mr28450504pbc.100.1340527955007; Sun, 24 Jun 2012 01:52:35 -0700 (PDT) Received: by 10.142.105.1 with HTTP; Sun, 24 Jun 2012 01:52:34 -0700 (PDT) In-Reply-To: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> Date: Sun, 24 Jun 2012 16:52:34 +0800 Message-ID: From: Qi Sun To: Satoru Matsushima Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 24 Jun 2012 08:52:41 -0000 Hi Satoru, 1. I don't know whether the new draft has been discussed in DT, but has it achieved consensus within the DT? what's more, this draft hasn't got the consensus in the softwires WG where the mdt-map-03 draft was adopted as WG draft before it was submitted. l'm wondering how this draft-XX-softwire-mapping-address-and-port-04 got adopted as a WG draft. 2. From the draft, I can feel that this mode is NOT the kind with other rules. it is stated separately with others unnaturally. 3. AFAIK, stateless solutions are featured with decouple of IPv4 and ipv6 addredssing, which leads to no states kept on the carrier side. once you abandon the feature using so called 1:1 mode which has to maitain state (no matter how you try to hide the fact), MAP will become neither total stateless nor stateful. this does no good to promote MAP for further development. BRs! Qi Sun On 6/24/12, Satoru Matsushima wrote: > Hi Qiong, > > I'm disagree with your opinion. > > 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in the > DT. > 2. MAP just covers so called '1:1 mode' with most granular mapping rule f= or > CEs provisioning, which is as one of its characteristics. > 3. The motivation draft does not restrict that as you stated, just > 'assumed', it's neither 'MUST' nor 'SHOULD'. > > Best regards, > --satoru > > > On 2012/06/24, at 14:35, Qiong wrote: > >> Hi all, >> >> As we all know, once an individual draft is adopted as a WG draft, it is >> owned by the whole WG, rather than just the editors. Just as Remi said, >> the normal procedure to follow is to reach WG consensus _before_ posting= a >> newly edited version. >> >> From draft-mdt-softwire-mapping-address-and-port-03 to >> draft-ietf-softwire-map-00, there are several changes between them. In >> particular, the newly introduced "1:1 mode", which decouples IPv4 and IP= v6 >> addressing, has never been discussed openly in the WG mailing list, or >> even in the MAP design team either. >> >> Actually, this "1:1 mode" is against the stateless-4v6-motivation draft. >> The motivation draft has clearly defines the "Stateless 4/6 solution" as >> follows: >> >> Stateless 4/6 solution denotes a solution which does not require any >> per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP >> address sharing function in the Service Provider's network. This categor= y >> of solutions assumes a dependency between an IPv6 prefix and IPv4 >> address. >> >> AFAIK what the WG has adopted MAP related draft is >> draft-mdt-softwire-mapping-address-and-port-03, NOT >> draft-ietf-softwire-map-00. And the stateless solution should =93respons= e to >> the solution motivation document=94 according to the Softwire charter. T= hat >> means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. >> >> We can all recall that our softwire WG has worked on stateless solutions >> for more than one and a half years, and we have achieved a lot of work >> which has been documented in charter, stateless motivation, 4rd-varients= , >> MAP-03, etc. AFAIK all the authors have kept the basic "stateless" >> principle and the MAP design team is also working on it together to find= a >> better algorithm, address format, etc. So it is really not appropriate t= o >> make such changes when MAP is adopted as a WG item in such a short time. >> >> From this perspective, draft-ietf-softwire-map-00 can only be regarded a= s >> draft-XX-softwire-mapping-address-and-port-04. It is not even the output >> of MAP design team. >> >> Best wishes >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > From bingxuere@gmail.com Sun Jun 24 08:14: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 7372121F85AD for ; Sun, 24 Jun 2012 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LK+jKWuqiJ1 for ; Sun, 24 Jun 2012 08:14:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3A21F85AA for ; Sun, 24 Jun 2012 08:14:36 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5862778obb.31 for ; Sun, 24 Jun 2012 08:14:36 -0700 (PDT) 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=0Oi1X0NxzUTBzxYFWMofgCFprqbMtheEn6zrkgFMEAE=; b=Al5uNUYRNKni4Bmv+fKNU5iNad74lW7dqJwzHqhJCk8haOPqDS0YiUcJyHwqbEYuzr mps5QtFkAUJXrtbxfwwQEA/0a6RoAlbMbRwBB0eLWPuKD6Sb+qcw71v3bY58n2W+zejh 90Zu8Al93JFDo2DQnzgyjhT3hTdMcOdE4S1BvyOc26F8SJy5z7DaNrqXp3o7s/AgmriX a2cumlCtWV+W2uqUfzJDiaJskEnquUlqA6tOTgKRByC+EbwfruYBtmh+i2punFbrO5cF cCvFpLWrXs5x/WWYlv+JB9yQJiuizR0BcoHQjDx6Bl5WqaR11IiBLE6Q4ppcNQv6Mxuz 12EA== Received: by 10.50.154.201 with SMTP id vq9mr6132357igb.2.1340550875680; Sun, 24 Jun 2012 08:14:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Sun, 24 Jun 2012 08:13:55 -0700 (PDT) In-Reply-To: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> From: Qiong Date: Sun, 24 Jun 2012 23:13:55 +0800 Message-ID: To: Satoru Matsushima Content-Type: multipart/alternative; boundary=14dae934081dbf8fb904c3395223 Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 24 Jun 2012 15:14:37 -0000 --14dae934081dbf8fb904c3395223 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Satoru, Every solution has its solution space with respective application scenarios as well as pros and cons. The essence of stateless solution, which follows the stateless motivation approved by the WG, is to achieve efficient address mapping by algorithmic embedding part of IPv4 address+port set into IPv6 address/prefix, while the essence of stateful solution is to maintain the subscriber-based state on-demand. IPv4 address and IPv6 address is not coupled, and there is no requirement on IPv6 addressing format. It is twisty to mix them together in one document as in the current draft-ietf-softwire-map. It is not clear for vendors to implement and for operators to deploy, and will lose the features for both. I'm not saying I'm against the work of stateless solutions, but it is really not fair to just extend one solution arbitrarily to cover another one without the permission from the WG and the authors. In particular, lightweight 4over6 is a collaborative work of 15 co-authors for more than one and a half years, including operators from China Telecom, Tsinghua, Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and also the vendors from Huawei, Juniper and Cisco. Our WG or DT has never reached the consensus to have one unified document for both stateful and stateless sotluion. And the motivation draft has never been extended to include the stateful features as well. So unless we reach the consensus first in the WG, we can then move forward with this document. Best wishes On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hi Qiong, > > I'm disagree with your opinion. > > 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in the > DT. > 2. MAP just covers so called '1:1 mode' with most granular mapping rule > for CEs provisioning, which is as one of its characteristics. > 3. The motivation draft does not restrict that as you stated, just > 'assumed', it's neither 'MUST' nor 'SHOULD'. > > Best regards, > --satoru > > > On 2012/06/24, at 14:35, Qiong wrote: > > > Hi all, > > > > As we all know, once an individual draft is adopted as a WG draft, it i= s > owned by the whole WG, rather than just the editors. Just as Remi said, t= he > normal procedure to follow is to reach WG consensus _before_ posting a > newly edited version. > > > > From draft-mdt-softwire-mapping-address-and-port-03 to > draft-ietf-softwire-map-00, there are several changes between them. In > particular, the newly introduced "1:1 mode", which decouples IPv4 and IPv= 6 > addressing, has never been discussed openly in the WG mailing list, or ev= en > in the MAP design team either. > > > > Actually, this "1:1 mode" is against the stateless-4v6-motivation draft= . > The motivation draft has clearly defines the "Stateless 4/6 solution" as > follows: > > > > Stateless 4/6 solution denotes a solution which does not require any > per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP > address sharing function in the Service Provider's network. This category > of solutions assumes a dependency between an IPv6 prefix and IPv4 address= . > > > > AFAIK what the WG has adopted MAP related draft is > draft-mdt-softwire-mapping-address-and-port-03, NOT > draft-ietf-softwire-map-00. And the stateless solution should =E2=80=9Cre= sponse to > the solution motivation document=E2=80=9D according to the Softwire chart= er. That > means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. > > > > We can all recall that our softwire WG has worked on stateless solution= s > for more than one and a half years, and we have achieved a lot of work > which has been documented in charter, stateless motivation, 4rd-varients, > MAP-03, etc. AFAIK all the authors have kept the basic "stateless" > principle and the MAP design team is also working on it together to find = a > better algorithm, address format, etc. So it is really not appropriate to > make such changes when MAP is adopted as a WG item in such a short time. > > > > From this perspective, draft-ietf-softwire-map-00 can only be regarded > as draft-XX-softwire-mapping-address-and-port-04. It is not even the outp= ut > of MAP design team. > > > > Best wishes > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > > --=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 --14dae934081dbf8fb904c3395223 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Satoru,

Every solution has its solution space with respective app= lication scenarios as well as pros and cons.
The essence of stateless s= olution, which follows the stateless motivation approved by the WG, is to a= chieve efficient address mapping by algorithmic embedding part of IPv4 addr= ess+port set into IPv6 address/prefix, while the essence of stateful soluti= on is to maintain the subscriber-based state on-demand. IPv4 address and IP= v6 address is not coupled, and there is no requirement on IPv6 addressing f= ormat. It is twisty to mix them together in one document as in the current = draft-ietf-softwire-map. It is not clear for vendors to implement and for o= perators to deploy, and will lose the features for both.

I'm not saying I'm against the work of stateless solutions, but= it is really not fair to just extend one solution arbitrarily to cover ano= ther one without the permission from the WG and the authors. In particular,= =C2=A0 lightweight 4over6 is a collaborative work of 15 co-authors for mor= e than one and a half years, including operators from China Telecom, Tsingh= ua, Comcast,=20 France telecom, Deutsche Telekom, Bouygues Telecom, etc., and=20 also the vendors from Huawei, Juniper and Cisco.

Our WG or DT has ne= ver reached the consensus to have one unified document for both stateful an= d stateless sotluion. And the motivation draft has never been extended to i= nclude the stateful features as well. So unless we reach the consensus firs= t in the WG, we can then move forward with this document.

Best wishes

On Sun, Jun 24, 2012 at 2= :00 PM, Satoru Matsushima <satoru.matsushima@gmail.com> wrote:
Hi Qiong,

I'm disagree with your opinion.

1. Recent changes in draft-ietf-softwire-map-00 has been discussed in the D= T.
2. MAP just covers so called '1:1 mode' with most granular mapping = rule for CEs provisioning, which is as one of its characteristics.
3. The motivation draft does not restrict that as you stated, just 'ass= umed', it's neither 'MUST' nor 'SHOULD'.

Best regards,
--satoru


On 2012/06/24, at 14:35, Qiong wrote:

> Hi all,
>
> As we all know, once an individual draft is adopted as a WG draft, it = is owned by the whole WG, rather than just the editors. Just as Remi said, = the normal procedure to follow is to reach WG consensus _before_ posting a = newly edited version.
>
> From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf-soft= wire-map-00, there are several changes between them. In particular, the new= ly introduced "1:1 mode", which decouples IPv4 and IPv6 addressin= g, has never been discussed openly in the WG mailing list, or even in the M= AP design team either.
>
> Actually, this "1:1 mode" is against the stateless-4v6-motiv= ation draft. The motivation draft has clearly defines the "Stateless 4= /6 solution" as follows:
>
> Stateless 4/6 solution denotes a solution which does not require any p= er-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP add= ress sharing function in the Service Provider's network. This category = of solutions assumes a dependency between an IPv6 prefix and IPv4 address.<= br> >
> AFAIK what the WG has adopted MAP related draft is draft-mdt-softwire-= mapping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the statel= ess solution should =E2=80=9Cresponse to the solution motivation document= =E2=80=9D according to the Softwire charter. That means draft-ietf-softwire= -map-00 IS NOT QUALIFIED to be a WG draft.
>
> We can all recall that our softwire WG has worked on stateless solutio= ns for more than one and a half years, and we have achieved a lot of work w= hich has been documented in charter, stateless motivation, 4rd-varients, MA= P-03, etc. AFAIK all the authors have kept the basic "stateless" = principle and the MAP design team is also working on it together to find a = better algorithm, address format, etc. So it is really not appropriate to m= ake such changes when MAP is adopted as a WG item in such a short time.
>
> From this perspective, draft-ietf-softwire-map-00 can only be regarded= as draft-XX-softwire-mapping-address-and-port-04. It is not even the outpu= t of MAP design team.
>
> Best wishes
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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




--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

--14dae934081dbf8fb904c3395223-- From pengwu.thu@gmail.com Sun Jun 24 09:21:04 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 67FC821F85F2 for ; Sun, 24 Jun 2012 09:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54Fdiax0dx87 for ; Sun, 24 Jun 2012 09:21:03 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 857E521F85EA for ; Sun, 24 Jun 2012 09:21:03 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1799209vcq.31 for ; Sun, 24 Jun 2012 09:21:03 -0700 (PDT) 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:content-transfer-encoding; bh=wL0mSJG6r7up4FSrOou1MzeeZYAcGrZSGDhKQrt8FS4=; b=NzaDIcfkLYT18Enun15peVLB3h4We/BLT/WerNi0cQzbfASrlyF0fX7tLuqlj7xTGM N7I3vDD49X+qIH8Isr16Nd89HU+TUEj/T9zcTdkEmhhwTkmNdL/WlTCpVW4cgUKuQxqC AC87a8ZXvGSNQShoNxpkJj1DngI0RrH3XlimlUNazWaHw9ISDBC818iKy9HCA37+UUvw AwJVHvP+JabssR41Uw3JZplYO191Iu+WYzNghm9Gx6m2PpbkEaXejVC+NS59MAqHxdLm tuF3bPg1N/NoINS0qyJQ+8bXCnVHxM9DtfbSHqXglv5/o6/w2JiSIyi2bXQ8vRDqX0rs A1YA== MIME-Version: 1.0 Received: by 10.220.248.83 with SMTP id mf19mr5756413vcb.50.1340554862775; Sun, 24 Jun 2012 09:21:02 -0700 (PDT) Received: by 10.52.28.84 with HTTP; Sun, 24 Jun 2012 09:21:02 -0700 (PDT) In-Reply-To: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> Date: Mon, 25 Jun 2012 00:21:02 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 24 Jun 2012 16:21:04 -0000 Hi Qiong, Satoru and all, I should thank Qiong for pointing this out. I gotta say I'm a bit shocked. If I understand the procedures of IETF correctly, a WG document should reflect the consensus of the WG. MAP is approved by the WG as a stateless solution. As a participator in Softwire, I didn't get the information anywhere that the MAP WG document would cover the so-called 1:1, in fact per-user stateful mode before it was released, not to say discuss in the WG. Don't the WG need to approve such big change anymore? Now let me provide my impression as an outsider of the MAP DT. You guys make great effort to build the solution, The address composition, the GMA algorithm, the different types of address mapping rules. should be quite difficult to pull together such sophisticated ideas. I guess that's what it takes to achieve the benifits of statelessness. And I admire that, bravo. Then, all of a sudden, you guys are saying, let's apply this sophisticated method to the different problem, by dropping quite some comlexity and twistting the mechanism a bit, seems it may work. Considering the problem are now solved in a more pure and clear way, I'm sorry but I CANNOT follow the logic here. On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima wrote: > Hi Qiong, > > I'm disagree with your opinion. > > 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in the= DT. > 2. MAP just covers so called '1:1 mode' with most granular mapping rule f= or CEs provisioning, which is as one of its characteristics. > 3. The motivation draft does not restrict that as you stated, just 'assum= ed', it's neither 'MUST' nor 'SHOULD'. > > Best regards, > --satoru > > > On 2012/06/24, at 14:35, Qiong wrote: > >> Hi all, >> >> As we all know, once an individual draft is adopted as a WG draft, it is= owned by the whole WG, rather than just the editors. Just as Remi said, th= e normal procedure to follow is to reach WG consensus _before_ posting a ne= wly edited version. >> >> From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf-softwi= re-map-00, there are several changes between them. In particular, the newly= introduced "1:1 mode", which decouples IPv4 and IPv6 addressing, has never= been discussed openly in the WG mailing list, or even in the MAP design te= am either. >> >> Actually, this "1:1 mode" is against the stateless-4v6-motivation draft.= The motivation draft has clearly defines the "Stateless 4/6 solution" as f= ollows: >> >> Stateless 4/6 solution denotes a solution which does not require any per= -user state (see Section 2.3 of [RFC1958]) to be maintained by any IP addre= ss sharing function in the Service Provider's network. This category of sol= utions assumes a dependency between an IPv6 prefix and IPv4 address. >> >> AFAIK what the WG has adopted MAP related draft is draft-mdt-softwire-ma= pping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the stateles= s solution should =93response to the solution motivation document=94 accord= ing to the Softwire charter. That means draft-ietf-softwire-map-00 IS NOT Q= UALIFIED to be a WG draft. >> >> We can all recall that our softwire WG has worked on stateless solutions= for more than one and a half years, and we have achieved a lot of work whi= ch has been documented in charter, stateless motivation, 4rd-varients, MAP-= 03, etc. AFAIK all the authors have kept the basic "stateless" principle an= d the MAP design team is also working on it together to find a better algor= ithm, address format, etc. So it is really not appropriate to make such cha= nges when MAP is adopted as a WG item in such a short time. >> >> From this perspective, draft-ietf-softwire-map-00 can only be regarded a= s draft-XX-softwire-mapping-address-and-port-04. It is not even the output = of MAP design team. >> >> Best wishes >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 From yiu_lee@cable.comcast.com Sun Jun 24 10:32: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 3568121F85E1 for ; Sun, 24 Jun 2012 10:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.633 X-Spam-Level: X-Spam-Status: No, score=-103.633 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnSnbIpOWrPW for ; Sun, 24 Jun 2012 10:32:48 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id D682821F85D4 for ; Sun, 24 Jun 2012 10:32:44 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.22469472; Sun, 24 Jun 2012 11:15:29 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Sun, 24 Jun 2012 13:32:33 -0400 From: "Lee, Yiu" To: Peng Wu , Satoru Matsushima , "suresh.krishnan@ericsson.com" , Yong Cui Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNUi9W0IiVxM+YrUqU8bk2bTixvg== Date: Sun, 24 Jun 2012 17:32:33 +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.2.120421 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3423389553_4459427" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 24 Jun 2012 17:32:49 -0000 --B_3423389553_4459427 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Dear Satoru and MAP-DT I echo what Peng and Qiong said. When the WG agreed working on the stateless solution, it was very clear stated that the solution would not maintain states in the network. If the 1:1 mode changed this, this no longer matched the requirements stated in the stateless motivation draft, thus, it would disqualify MAP as a solution for the motivation draft. AFAIK, the MAP Design Team could propose a change, but such a dramatic change by introducing states in the network would require WG approval. I would like the chairs to clarify this. Thanks, Yiu On 6/24/12 12:21 PM, "Peng Wu" wrote: >Hi Qiong, Satoru and all, > >I should thank Qiong for pointing this out. I gotta say I'm a bit shocked. >If I understand the procedures of IETF correctly, a WG document should >reflect the consensus of the WG. MAP is approved by the WG as a >stateless solution. As a participator in Softwire, I didn't get the >information anywhere that the MAP WG document would cover the >so-called 1:1, in fact per-user stateful mode before it was released, >not to say discuss in the WG. Don't the WG need to approve such big >change anymore? > >Now let me provide my impression as an outsider of the MAP DT. You >guys make great effort to build the solution, The address composition, >the GMA algorithm, the different types of address mapping rules. >should be quite difficult to pull together such sophisticated ideas. I >guess that's what it takes to achieve the benifits of statelessness. >And I admire that, bravo. Then, all of a sudden, you guys are saying, >let's apply this sophisticated method to the different problem, by >dropping quite some comlexity and twistting the mechanism a bit, seems >it may work. Considering the problem are now solved in a more pure and >clear way, I'm sorry but I CANNOT follow the logic here. > >On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima > wrote: >> Hi Qiong, >> >> I'm disagree with your opinion. >> >> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in >>the DT. >> 2. MAP just covers so called '1:1 mode' with most granular mapping rule >>for CEs provisioning, which is as one of its characteristics. >> 3. The motivation draft does not restrict that as you stated, just >>'assumed', it's neither 'MUST' nor 'SHOULD'. >> >> Best regards, >> --satoru >> >> >> On 2012/06/24, at 14:35, Qiong wrote: >> >>> Hi all, >>> >>> As we all know, once an individual draft is adopted as a WG draft, it >>>is owned by the whole WG, rather than just the editors. Just as Remi >>>said, the normal procedure to follow is to reach WG consensus _before_ >>>posting a newly edited version. >>> >>> From draft-mdt-softwire-mapping-address-and-port-03 to >>>draft-ietf-softwire-map-00, there are several changes between them. In >>>particular, the newly introduced "1:1 mode", which decouples IPv4 and >>>IPv6 addressing, has never been discussed openly in the WG mailing >>>list, or even in the MAP design team either. >>> >>> Actually, this "1:1 mode" is against the stateless-4v6-motivation >>>draft. The motivation draft has clearly defines the "Stateless 4/6 >>>solution" as follows: >>> >>> Stateless 4/6 solution denotes a solution which does not require any >>>per-user state (see Section 2.3 of [RFC1958]) to be maintained by any >>>IP address sharing function in the Service Provider's network. This >>>category of solutions assumes a dependency between an IPv6 prefix and >>>IPv4 address. >>> >>> AFAIK what the WG has adopted MAP related draft is >>>draft-mdt-softwire-mapping-address-and-port-03, NOT >>>draft-ietf-softwire-map-00. And the stateless solution should =B3response >>>to the solution motivation document=B2 according to the Softwire charter. >>>That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. >>> >>> We can all recall that our softwire WG has worked on stateless >>>solutions for more than one and a half years, and we have achieved a >>>lot of work which has been documented in charter, stateless motivation, >>>4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic >>>"stateless" principle and the MAP design team is also working on it >>>together to find a better algorithm, address format, etc. So it is >>>really not appropriate to make such changes when MAP is adopted as a WG >>>item in such a short time. >>> >>> From this perspective, draft-ietf-softwire-map-00 can only be regarded >>>as draft-XX-softwire-mapping-address-and-port-04. It is not even the >>>output of MAP design team. >>> >>> Best wishes >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3423389553_4459427 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQVPrc7 JwIM7d8EVLwlnKanHMTDDTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MjQxNzMyMzJaMA0GCSqGSIb3DQEBAQUABIIBAGuAlMtHNZC5lcFpzn5FFnMO MWoc6SmOaHXMZ1cm/YG59GmRxXFkKcbLaGMFVmcbyYvpRAQou/pCu117nBDEz0Cw8s27xR+D HRuvErSjEKxgk3RPHDaWXZOIcfKeb2WpjV12ixDKJ2g4EK8MGSZmVAULq0Bj0UOVNSdyVkLN uyXhTBlw0oRfwvFyBb5rMi6gZSw5iyNj59QPqlksKFdtu0TLpD23xup1xf4QPV2Z1Owa2V7e LHaa/u/O5cjMHv38p5PZBv3cRw7qdG114RpH9FMs61Rz1rqNgRWHChp3NGvhKYkjNDktT8I4 UShyPB61aGpX5Ik3EW+TfaNHGxIoEvU= --B_3423389553_4459427-- From xiechf01@gmail.com Sun Jun 24 16:48:04 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 8AD2921F8659 for ; Sun, 24 Jun 2012 16:48:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcGu8qNtGaxY for ; Sun, 24 Jun 2012 16:48:03 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42E0721F861C for ; Sun, 24 Jun 2012 16:48:03 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5826663pbc.31 for ; Sun, 24 Jun 2012 16:48:03 -0700 (PDT) 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-has-attach :x-mailer:mime-version:message-id:content-type; bh=eR9AME2pk7GnVc/b4cUtVT161NvKtvSfESxTXEJz8GE=; b=vTMnIv3Ttsjx9GI1fTu4X4nlwrnsdn4nz5xTfweGYGKOwbJ9EuJqW4JcnTilLivG6u oFpuQ1pdvkVKW6Ih1lywFXaS4X0G/FtN4nGhQCXUH1fFF2ZQ0hky0buvxPO8IUdnpVqE ZMbGyU8mytGgzVTIq8moYdmIGVYh+gFQjLdehQ4Ktx3fZRF7n/zVAMDCInZxChTG6w6p uGY6YkmeM1K3Cf4UeIyKFsxhCY79BXCIRoC+H7NadRC9idannwEFzHlRdOOg1rcz18P0 nhx/tvjg+C9OXmLquJfYx+AANP0dMhFkfOkErsrQPLGGfRt2A1UqS1TwoPb5utdgOqFB akag== Received: by 10.68.135.201 with SMTP id pu9mr32993979pbb.146.1340581682792; Sun, 24 Jun 2012 16:48:02 -0700 (PDT) Received: from xiechf-PC ([219.142.69.76]) by mx.google.com with ESMTPS id ip5sm6616967pbc.3.2012.06.24.16.47.57 (version=SSLv3 cipher=OTHER); Sun, 24 Jun 2012 16:48:01 -0700 (PDT) Date: Mon, 25 Jun 2012 07:47:55 +0800 From: xiechf01 To: =?utf-8?B?TGVlLCBZaXU=?= , "Peng Wu" , "Satoru Matsushima" , suresh.krishnan , "Yong Cui" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201206250747524686693@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart214560000811_=----" Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiechf01 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2012 23:48:04 -0000 This is a multi-part message in MIME format. ------=_001_NextPart214560000811_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGFncmVlIHdpdGggUWlvbmcsIFBlbmcgYW5kIFlpdSwgIHNpbmNlIHRoaXMgYmlnIGNoYW5n ZSBoYXMgbmV2ZXIgYmVlbiBkaXNjdXNzZWQgIGluIHRoZSBXRywgIGl0IGlzIGluYXBwcm9wcmlh dGUgZm9yIE1BUCBiZWluZyBhY2NlcHRlZCBhcyBXRyBkb2N1bWVudC4gIA0KDQpDaG9uZ2ZlbmcN Cg0KDQoNCg0KDQpGcm9tOiBMZWUsIFlpdQ0KRGF0ZTogMjAxMi0wNi0yNSAwMTozMg0KVG86IFBl bmcgV3U7IFNhdG9ydSBNYXRzdXNoaW1hOyBzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tOyBZ b25nIEN1aQ0KQ0M6IHNvZnR3aXJlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNd IFtTb2Z0d2lyZV0gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgZG9lcyBOT1QgcmVmbGVjdCB0 aGUgY29uc2Vuc3VzIGZyb20gdGhlIFdHDQpEZWFyIFNhdG9ydSBhbmQgTUFQLURUDQoNCkkgZWNo byB3aGF0IFBlbmcgYW5kIFFpb25nIHNhaWQuIFdoZW4gdGhlIFdHIGFncmVlZCB3b3JraW5nIG9u IHRoZQ0Kc3RhdGVsZXNzIHNvbHV0aW9uLCBpdCB3YXMgdmVyeSBjbGVhciBzdGF0ZWQgdGhhdCB0 aGUgc29sdXRpb24gd291bGQgbm90DQptYWludGFpbiBzdGF0ZXMgaW4gdGhlIG5ldHdvcmsuIElm IHRoZSAxOjEgbW9kZSBjaGFuZ2VkIHRoaXMsIHRoaXMgbm8NCmxvbmdlciBtYXRjaGVkIHRoZSBy ZXF1aXJlbWVudHMgc3RhdGVkIGluIHRoZSBzdGF0ZWxlc3MgbW90aXZhdGlvbiBkcmFmdCwNCnRo dXMsIGl0IHdvdWxkIGRpc3F1YWxpZnkgTUFQIGFzIGEgc29sdXRpb24gZm9yIHRoZSBtb3RpdmF0 aW9uIGRyYWZ0Lg0KDQpBRkFJSywgdGhlIE1BUCBEZXNpZ24gVGVhbSBjb3VsZCBwcm9wb3NlIGEg Y2hhbmdlLCBidXQgc3VjaCBhIGRyYW1hdGljDQpjaGFuZ2UgYnkgaW50cm9kdWNpbmcgc3RhdGVz IGluIHRoZSBuZXR3b3JrIHdvdWxkIHJlcXVpcmUgV0cgYXBwcm92YWwuIEkNCndvdWxkIGxpa2Ug dGhlIGNoYWlycyB0byBjbGFyaWZ5IHRoaXMuDQoNClRoYW5rcywNCllpdQ0KDQoNCk9uIDYvMjQv MTIgMTI6MjEgUE0sICJQZW5nIFd1IiA8cGVuZ3d1LnRodUBnbWFpbC5jb20+IHdyb3RlOg0KDQo+ SGkgUWlvbmcsIFNhdG9ydSBhbmQgYWxsLA0KPg0KPkkgc2hvdWxkIHRoYW5rIFFpb25nIGZvciBw b2ludGluZyB0aGlzIG91dC4gSSBnb3R0YSBzYXkgSSdtIGEgYml0IHNob2NrZWQuDQo+SWYgSSB1 bmRlcnN0YW5kIHRoZSBwcm9jZWR1cmVzIG9mIElFVEYgY29ycmVjdGx5LCBhIFdHIGRvY3VtZW50 IHNob3VsZA0KPnJlZmxlY3QgdGhlIGNvbnNlbnN1cyBvZiB0aGUgV0cuIE1BUCBpcyBhcHByb3Zl ZCBieSB0aGUgV0cgYXMgYQ0KPnN0YXRlbGVzcyBzb2x1dGlvbi4gQXMgYSBwYXJ0aWNpcGF0b3Ig aW4gU29mdHdpcmUsIEkgZGlkbid0IGdldCB0aGUNCj5pbmZvcm1hdGlvbiBhbnl3aGVyZSB0aGF0 IHRoZSBNQVAgV0cgZG9jdW1lbnQgd291bGQgY292ZXIgdGhlDQo+c28tY2FsbGVkIDE6MSwgaW4g ZmFjdCBwZXItdXNlciBzdGF0ZWZ1bCBtb2RlIGJlZm9yZSBpdCB3YXMgcmVsZWFzZWQsDQo+bm90 IHRvIHNheSBkaXNjdXNzIGluIHRoZSBXRy4gRG9uJ3QgdGhlIFdHIG5lZWQgdG8gYXBwcm92ZSBz dWNoIGJpZw0KPmNoYW5nZSBhbnltb3JlPw0KPg0KPk5vdyBsZXQgbWUgcHJvdmlkZSBteSBpbXBy ZXNzaW9uIGFzIGFuIG91dHNpZGVyIG9mIHRoZSBNQVAgRFQuIFlvdQ0KPmd1eXMgbWFrZSBncmVh dCBlZmZvcnQgdG8gYnVpbGQgdGhlIHNvbHV0aW9uLCBUaGUgYWRkcmVzcyBjb21wb3NpdGlvbiwN Cj50aGUgR01BIGFsZ29yaXRobSwgdGhlIGRpZmZlcmVudCB0eXBlcyBvZiBhZGRyZXNzIG1hcHBp bmcgcnVsZXMuDQo+c2hvdWxkIGJlIHF1aXRlIGRpZmZpY3VsdCB0byBwdWxsIHRvZ2V0aGVyIHN1 Y2ggc29waGlzdGljYXRlZCBpZGVhcy4gSQ0KPmd1ZXNzIHRoYXQncyB3aGF0IGl0IHRha2VzIHRv IGFjaGlldmUgdGhlIGJlbmlmaXRzIG9mIHN0YXRlbGVzc25lc3MuDQo+QW5kIEkgYWRtaXJlIHRo YXQsIGJyYXZvLiBUaGVuLCBhbGwgb2YgYSBzdWRkZW4sIHlvdSBndXlzIGFyZSBzYXlpbmcsDQo+ bGV0J3MgYXBwbHkgdGhpcyBzb3BoaXN0aWNhdGVkIG1ldGhvZCB0byB0aGUgZGlmZmVyZW50IHBy b2JsZW0sIGJ5DQo+ZHJvcHBpbmcgcXVpdGUgc29tZSBjb21sZXhpdHkgYW5kIHR3aXN0dGluZyB0 aGUgbWVjaGFuaXNtIGEgYml0LCBzZWVtcw0KPml0IG1heSB3b3JrLiBDb25zaWRlcmluZyB0aGUg cHJvYmxlbSBhcmUgbm93IHNvbHZlZCBpbiBhIG1vcmUgcHVyZSBhbmQNCj5jbGVhciB3YXksIEkn bSBzb3JyeSBidXQgSSBDQU5OT1QgZm9sbG93IHRoZSBsb2dpYyBoZXJlLg0KPg0KPk9uIFN1biwg SnVuIDI0LCAyMDEyIGF0IDI6MDAgUE0sIFNhdG9ydSBNYXRzdXNoaW1hDQo+PHNhdG9ydS5tYXRz dXNoaW1hQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiBIaSBRaW9uZywNCj4+DQo+PiBJJ20gZGlzYWdy ZWUgd2l0aCB5b3VyIG9waW5pb24uDQo+Pg0KPj4gMS4gUmVjZW50IGNoYW5nZXMgaW4gZHJhZnQt aWV0Zi1zb2Z0d2lyZS1tYXAtMDAgaGFzIGJlZW4gZGlzY3Vzc2VkIGluDQo+PnRoZSBEVC4NCj4+ IDIuIE1BUCBqdXN0IGNvdmVycyBzbyBjYWxsZWQgJzE6MSBtb2RlJyB3aXRoIG1vc3QgZ3JhbnVs YXIgbWFwcGluZyBydWxlDQo+PmZvciBDRXMgcHJvdmlzaW9uaW5nLCB3aGljaCBpcyBhcyBvbmUg b2YgaXRzIGNoYXJhY3RlcmlzdGljcy4NCj4+IDMuIFRoZSBtb3RpdmF0aW9uIGRyYWZ0IGRvZXMg bm90IHJlc3RyaWN0IHRoYXQgYXMgeW91IHN0YXRlZCwganVzdA0KPj4nYXNzdW1lZCcsIGl0J3Mg bmVpdGhlciAnTVVTVCcgbm9yICdTSE9VTEQnLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IC0t c2F0b3J1DQo+Pg0KPj4NCj4+IE9uIDIwMTIvMDYvMjQsIGF0IDE0OjM1LCBRaW9uZyB3cm90ZToN Cj4+DQo+Pj4gSGkgYWxsLA0KPj4+DQo+Pj4gQXMgd2UgYWxsIGtub3csIG9uY2UgYW4gaW5kaXZp ZHVhbCBkcmFmdCBpcyBhZG9wdGVkIGFzIGEgV0cgZHJhZnQsIGl0DQo+Pj5pcyBvd25lZCBieSB0 aGUgd2hvbGUgV0csIHJhdGhlciB0aGFuIGp1c3QgdGhlIGVkaXRvcnMuIEp1c3QgYXMgUmVtaQ0K Pj4+c2FpZCwgdGhlIG5vcm1hbCBwcm9jZWR1cmUgdG8gZm9sbG93IGlzIHRvIHJlYWNoIFdHIGNv bnNlbnN1cyBfYmVmb3JlXw0KPj4+cG9zdGluZyBhIG5ld2x5IGVkaXRlZCB2ZXJzaW9uLg0KPj4+ DQo+Pj4gRnJvbSBkcmFmdC1tZHQtc29mdHdpcmUtbWFwcGluZy1hZGRyZXNzLWFuZC1wb3J0LTAz IHRvDQo+Pj5kcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCwgdGhlcmUgYXJlIHNldmVyYWwgY2hh bmdlcyBiZXR3ZWVuIHRoZW0uIEluDQo+Pj5wYXJ0aWN1bGFyLCB0aGUgbmV3bHkgaW50cm9kdWNl ZCAiMToxIG1vZGUiLCB3aGljaCBkZWNvdXBsZXMgSVB2NCBhbmQNCj4+PklQdjYgYWRkcmVzc2lu ZywgaGFzIG5ldmVyIGJlZW4gZGlzY3Vzc2VkIG9wZW5seSBpbiB0aGUgV0cgbWFpbGluZw0KPj4+ bGlzdCwgb3IgZXZlbiBpbiB0aGUgTUFQIGRlc2lnbiB0ZWFtIGVpdGhlci4NCj4+Pg0KPj4+IEFj dHVhbGx5LCB0aGlzICIxOjEgbW9kZSIgaXMgYWdhaW5zdCB0aGUgc3RhdGVsZXNzLTR2Ni1tb3Rp dmF0aW9uDQo+Pj5kcmFmdC4gVGhlIG1vdGl2YXRpb24gZHJhZnQgaGFzIGNsZWFybHkgZGVmaW5l cyB0aGUgIlN0YXRlbGVzcyA0LzYNCj4+PnNvbHV0aW9uIiBhcyBmb2xsb3dzOg0KPj4+DQo+Pj4g U3RhdGVsZXNzIDQvNiBzb2x1dGlvbiBkZW5vdGVzIGEgc29sdXRpb24gd2hpY2ggZG9lcyBub3Qg cmVxdWlyZSBhbnkNCj4+PnBlci11c2VyIHN0YXRlIChzZWUgU2VjdGlvbiAyLjMgb2YgW1JGQzE5 NThdKSB0byBiZSBtYWludGFpbmVkIGJ5IGFueQ0KPj4+SVAgYWRkcmVzcyBzaGFyaW5nIGZ1bmN0 aW9uIGluIHRoZSBTZXJ2aWNlIFByb3ZpZGVyJ3MgbmV0d29yay4gVGhpcw0KPj4+Y2F0ZWdvcnkg b2Ygc29sdXRpb25zIGFzc3VtZXMgYSBkZXBlbmRlbmN5IGJldHdlZW4gYW4gSVB2NiBwcmVmaXgg YW5kDQo+Pj5JUHY0IGFkZHJlc3MuDQo+Pj4NCj4+PiBBRkFJSyB3aGF0IHRoZSBXRyBoYXMgYWRv cHRlZCBNQVAgcmVsYXRlZCBkcmFmdCBpcw0KPj4+ZHJhZnQtbWR0LXNvZnR3aXJlLW1hcHBpbmct YWRkcmVzcy1hbmQtcG9ydC0wMywgTk9UDQo+Pj5kcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMC4g QW5kIHRoZSBzdGF0ZWxlc3Mgc29sdXRpb24gc2hvdWxkIMKzcmVzcG9uc2UNCj4+PnRvIHRoZSBz b2x1dGlvbiBtb3RpdmF0aW9uIGRvY3VtZW50wrIgYWNjb3JkaW5nIHRvIHRoZSBTb2Z0d2lyZSBj aGFydGVyLg0KPj4+VGhhdCBtZWFucyBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBJUyBOT1Qg UVVBTElGSUVEIHRvIGJlIGEgV0cgZHJhZnQuDQo+Pj4NCj4+PiBXZSBjYW4gYWxsIHJlY2FsbCB0 aGF0IG91ciBzb2Z0d2lyZSBXRyBoYXMgd29ya2VkIG9uIHN0YXRlbGVzcw0KPj4+c29sdXRpb25z IGZvciBtb3JlIHRoYW4gb25lIGFuZCBhIGhhbGYgeWVhcnMsIGFuZCB3ZSBoYXZlIGFjaGlldmVk IGENCj4+PmxvdCBvZiB3b3JrIHdoaWNoIGhhcyBiZWVuIGRvY3VtZW50ZWQgaW4gY2hhcnRlciwg c3RhdGVsZXNzIG1vdGl2YXRpb24sDQo+Pj40cmQtdmFyaWVudHMsIE1BUC0wMywgZXRjLiBBRkFJ SyBhbGwgdGhlIGF1dGhvcnMgaGF2ZSBrZXB0IHRoZSBiYXNpYw0KPj4+InN0YXRlbGVzcyIgcHJp bmNpcGxlIGFuZCB0aGUgTUFQIGRlc2lnbiB0ZWFtIGlzIGFsc28gd29ya2luZyBvbiBpdA0KPj4+ dG9nZXRoZXIgdG8gZmluZCBhIGJldHRlciBhbGdvcml0aG0sIGFkZHJlc3MgZm9ybWF0LCBldGMu IFNvIGl0IGlzDQo+Pj5yZWFsbHkgbm90IGFwcHJvcHJpYXRlIHRvIG1ha2Ugc3VjaCBjaGFuZ2Vz IHdoZW4gTUFQIGlzIGFkb3B0ZWQgYXMgYSBXRw0KPj4+aXRlbSBpbiBzdWNoIGEgc2hvcnQgdGlt ZS4NCj4+Pg0KPj4+IEZyb20gdGhpcyBwZXJzcGVjdGl2ZSwgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1t YXAtMDAgY2FuIG9ubHkgYmUgcmVnYXJkZWQNCj4+PmFzIGRyYWZ0LVhYLXNvZnR3aXJlLW1hcHBp bmctYWRkcmVzcy1hbmQtcG9ydC0wNC4gSXQgaXMgbm90IGV2ZW4gdGhlDQo+Pj5vdXRwdXQgb2Yg TUFQIGRlc2lnbiB0ZWFtLg0KPj4+DQo+Pj4gQmVzdCB3aXNoZXMNCj4+Pg0KPj4+ID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4+PiBRaW9uZyBTdW4NCj4+ PiBDaGluYSBUZWxlY29tIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dWRlDQo+Pj4NCj4+Pg0KPj4+ IE9wZW4gc291cmNlIGNvZGU6DQo+Pj4gbGlnaHR3ZWlnaHQgNG92ZXI2OiBodHRwOi8vc291cmNl Zm9yZ2UubmV0L3Byb2plY3RzL2xhZnQ2Lw0KPj4+IFBDUC1uYXRjb29yZDogaHR0cDovL3NvdXJj ZWZvcmdlLm5ldC9wcm9qZWN0cy9wY3Bwb3J0c2V0ZGVtby8NCj4+PiA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IFNvZnR3aXJlcyBtYWls aW5nIGxpc3QNCj4+PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+ PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc29mdHdpcmVzDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5Tb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+U29mdHdpcmVzQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMg bWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc29mdHdpcmVz ------=_001_NextPart214560000811_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
I agree with Qiong, Peng and Yiu,  since this big change=20 has never been discussed  in the WG,  it is inappropriate f= or MAP=20 being accepted as WG document. 
 
Chongfeng
 
 
Date: 2012-06-25 01:32
To: Peng Wu; = Satoru Matsushima; suresh.krishnan@ericsson.com<= /A>; Yong Cui
CC: softwires@ietf.org
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
Dear Satoru and MAP-DT
 
I echo what Peng and Qiong said. W= hen the WG agreed working on the
stateless solution, it was very clear s= tated that the solution would not
maintain states in the network. If the&= nbsp;1:1 mode changed this, this no
longer matched the requirements stated in&nb= sp;the stateless motivation draft,
thus, it would disqualify MAP as a = ;solution for the motivation draft.
 
AFAIK, the MAP Design Team could propos= e a change, but such a dramatic
change by introducing states in the net= work would require WG approval. I
would like the chairs to clarify this.<= /DIV>
 
Thanks,
Yiu
 
 
On 6/24/12 12:21 PM, "Peng Wu" <peng= wu.thu@gmail.com> wrote:
 
>Hi Qiong, Satoru and all,
>
>I should thank Qiong for pointing t= his out. I gotta say I'm a bit sho= cked.
>If I understand the procedures of I= ETF correctly, a WG document should
>reflect the consensus of the WG. MA= P is approved by the WG as a
>stateless solution. As a participator in=  Softwire, I didn't get the
>information anywhere that the MAP WG&nbs= p;document would cover the
>so-called 1:1, in fact per-user stateful=  mode before it was released,
>not to say discuss in the WG. = Don't the WG need to approve such big
>change anymore?
>
>Now let me provide my impression as=  an outsider of the MAP DT. You
>guys make great effort to build the=  solution, The address composition,
>the GMA algorithm, the different types&n= bsp;of address mapping rules.
>should be quite difficult to pull t= ogether such sophisticated ideas. I
>guess that's what it takes to achie= ve the benifits of statelessness.
>And I admire that, bravo. Then, all=  of a sudden, you guys are saying,
>let's apply this sophisticated method to=  the different problem, by
>dropping quite some comlexity and twistt= ing the mechanism a bit, seems
>it may work. Considering the problem&nbs= p;are now solved in a more pure and
>clear way, I'm sorry but I CANNOT&n= bsp;follow the logic here.
>
>On Sun, Jun 24, 2012 at 2:00 P= M, Satoru Matsushima
><satoru.matsushima@gmail.com> wrote:
>> Hi Qiong,
>>
>> I'm disagree with your opinion.
>>
>> 1. Recent changes in draft-ietf-sof= twire-map-00 has been discussed in
>>the DT.
>> 2. MAP just covers so called&n= bsp;'1:1 mode' with most granular mapping ru= le
>>for CEs provisioning, which is as&nb= sp;one of its characteristics.
>> 3. The motivation draft does n= ot restrict that as you stated, just
>>'assumed', it's neither 'MUST' nor '= SHOULD'.
>>
>> Best regards,
>> --satoru
>>
>>
>> On 2012/06/24, at 14:35, Qiong = ;wrote:
>>
>>> Hi all,
>>>
>>> As we all know, once an&nb= sp;individual draft is adopted as a WG = draft, it
>>>is owned by the whole WG, r= ather than just the editors. Just as Re= mi
>>>said, the normal procedure to fo= llow is to reach WG consensus _before_
>>>posting a newly edited version.
>>>
>>> From draft-mdt-softwire-mapping-address-and-po= rt-03 to
>>>draft-ietf-softwire-map-00, there are seve= ral changes between them. In
>>>particular, the newly introduced "1:1=  mode", which decouples IPv4 and
>>>IPv6 addressing, has never been = discussed openly in the WG mailing
>>>list, or even in the MAP de= sign team either.
>>>
>>> Actually, this "1:1 mode" is&nb= sp;against the stateless-4v6-motivation
>>>draft. The motivation draft has = clearly defines the "Stateless 4/6
>>>solution" as follows:
>>>
>>> Stateless 4/6 solution denotes = a solution which does not require any
>>>per-user state (see Section 2.3 = of [RFC1958]) to be maintained by any
>>>IP address sharing function in t= he Service Provider's network. This
>>>category of solutions assumes a = dependency between an IPv6 prefix and
>>>IPv4 address.
>>>
>>> AFAIK what the WG has adop= ted MAP related draft is
>>>draft-mdt-softwire-mapping-address-and-port-03, NOT<= /DIV>
>>>draft-ietf-softwire-map-00. And the statel= ess solution should =C2=B3response
>>>to the solution motivation document= =C2=B2 according to the Softwire charter.
>>>That means draft-ietf-softwire-map-00 IS&n= bsp;NOT QUALIFIED to be a WG draft.
>>>
>>> We can all recall that our=  softwire WG has worked on stateless
>>>solutions for more than one and&= nbsp;a half years, and we have achieved = ;a
>>>lot of work which has been = documented in charter, stateless motivation,
>>>4rd-varients, MAP-03, etc. AFAIK all&= nbsp;the authors have kept the basic
>>>"stateless" principle and the MAP&nbs= p;design team is also working on it
>>>together to find a better algori= thm, address format, etc. So it is
>>>really not appropriate to make s= uch changes when MAP is adopted as a&nb= sp;WG
>>>item in such a short time.
>>>
>>> From this perspective, draft-ietf-so= ftwire-map-00 can only be regarded
>>>as draft-XX-softwire-mapping-address-and-port-04.&nb= sp;It is not even the
>>>output of MAP design team.
>>>
>>> Best wishes
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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.ne= t/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
>_______________________________________________
>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
 
------=_001_NextPart214560000811_=------ From satoru.matsushima@gmail.com Sun Jun 24 18:55: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 B4D6F21F85FB for ; Sun, 24 Jun 2012 18:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+yWcljEsy0f for ; Sun, 24 Jun 2012 18:55:40 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C17A421F85EF for ; Sun, 24 Jun 2012 18:55:40 -0700 (PDT) Received: by dacx6 with SMTP id x6so4647164dac.31 for ; Sun, 24 Jun 2012 18:55:40 -0700 (PDT) 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=ed+MNCvygR/1/J5JhEUFmyMhyeI0YVf7Yve7W/iwlKo=; b=DdPk5/AeA4GuyW8oStEQ12LGrSeUFYDrO0HCSvGADFcy3dw0S2Z1IB629iFCtJKNFh G681VgfSmTjQPqS42gfpdxDgSJqQYxSdtJPJv6mUJDUNkAYe18bSVOVxzyydJEBLKxwZ JXB+pFeZNz3kB3R3tdO6TN/rh5M9KsS9Srf+r+7Ka5mrCxAsRCROz46OvaQddLa17q8U Jhpk0Z+9MaSRHDWdyJm6opfmO6ogl51vVUPchmOFzUKsq3Ah7QeBDp8OoebB1MN/Au9L KLDNE6odxkE1TALDlp+EZFROfq7C37yXqPIIXJTp0efrPVV6+oVRRLeUGDZcpx+m7NaP G4Ow== Received: by 10.68.223.167 with SMTP id qv7mr34698580pbc.127.1340589340524; Sun, 24 Jun 2012 18:55:40 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id os1sm6888325pbb.49.2012.06.24.18.55.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 18:55:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-2022-jp From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 10:55:36 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> To: Qiong X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 01:55:44 -0000 Hi Qiong, Thanks you to carefully express your thought. I understand that. First point, let me answer for the question, 'Is MAP stateless or = stateful', the answer is: "MAP is *not* stateful solution itself". It = was discussed in the interim meeting in Beijing about 'per-subscriber = mapping' could be one characteristic of MAP solution. It does not = introduce 'per-flow NAT binding' or 'per-subscriber state on demand' on = network side. As MAP specification, there is a case when ea-bits length = indicates zero so that MAP needs explain this case and clearly define = specification that's what we did. Second, I don't have any intention to deprecate those who work hard for = that solutions. I didn't figure out that MAP possibly cover existing = solutions untill you rise this point. Now I remember that = 'multi-protocol socket v2.0', talked from the chair, which has been = deeply engraved in my mind. I believe that it is right direction for the = working group. I agree on that we need discussion. That would be there's another choice = to define in the case of ea-bits length indicates zero. Best regards, --satoru On 2012/06/25, at 0:13, Qiong wrote: > Hi Satoru, >=20 > Every solution has its solution space with respective application = scenarios as well as pros and cons.=20 > The essence of stateless solution, which follows the stateless = motivation approved by the WG, is to achieve efficient address mapping = by algorithmic embedding part of IPv4 address+port set into IPv6 = address/prefix, while the essence of stateful solution is to maintain = the subscriber-based state on-demand. IPv4 address and IPv6 address is = not coupled, and there is no requirement on IPv6 addressing format. It = is twisty to mix them together in one document as in the current = draft-ietf-softwire-map. It is not clear for vendors to implement and = for operators to deploy, and will lose the features for both. >=20 > I'm not saying I'm against the work of stateless solutions, but it is = really not fair to just extend one solution arbitrarily to cover another = one without the permission from the WG and the authors. In particular, = lightweight 4over6 is a collaborative work of 15 co-authors for more = than one and a half years, including operators from China Telecom, = Tsinghua, Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, = etc., and also the vendors from Huawei, Juniper and Cisco. >=20 > Our WG or DT has never reached the consensus to have one unified = document for both stateful and stateless sotluion. And the motivation = draft has never been extended to include the stateful features as well. = So unless we reach the consensus first in the WG, we can then move = forward with this document.=20 >=20 > Best wishes >=20 > On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima = wrote: > Hi Qiong, >=20 > I'm disagree with your opinion. >=20 > 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in = the DT. > 2. MAP just covers so called '1:1 mode' with most granular mapping = rule for CEs provisioning, which is as one of its characteristics. > 3. The motivation draft does not restrict that as you stated, just = 'assumed', it's neither 'MUST' nor 'SHOULD'. >=20 > Best regards, > --satoru >=20 >=20 > On 2012/06/24, at 14:35, Qiong wrote: >=20 > > Hi all, > > > > As we all know, once an individual draft is adopted as a WG draft, = it is owned by the whole WG, rather than just the editors. Just as Remi = said, the normal procedure to follow is to reach WG consensus _before_ = posting a newly edited version. > > > > =46rom draft-mdt-softwire-mapping-address-and-port-03 to = draft-ietf-softwire-map-00, there are several changes between them. In = particular, the newly introduced "1:1 mode", which decouples IPv4 and = IPv6 addressing, has never been discussed openly in the WG mailing list, = or even in the MAP design team either. > > > > Actually, this "1:1 mode" is against the stateless-4v6-motivation = draft. The motivation draft has clearly defines the "Stateless 4/6 = solution" as follows: > > > > Stateless 4/6 solution denotes a solution which does not require any = per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP = address sharing function in the Service Provider's network. This = category of solutions assumes a dependency between an IPv6 prefix and = IPv4 address. > > > > AFAIK what the WG has adopted MAP related draft is = draft-mdt-softwire-mapping-address-and-port-03, NOT = draft-ietf-softwire-map-00. And the stateless solution should = =1B$B!H=1B(Bresponse to the solution motivation document=1B$B!I=1B(B = according to the Softwire charter. That means draft-ietf-softwire-map-00 = IS NOT QUALIFIED to be a WG draft. > > > > We can all recall that our softwire WG has worked on stateless = solutions for more than one and a half years, and we have achieved a lot = of work which has been documented in charter, stateless motivation, = 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic = "stateless" principle and the MAP design team is also working on it = together to find a better algorithm, address format, etc. So it is = really not appropriate to make such changes when MAP is adopted as a WG = item in such a short time. > > > > =46rom this perspective, draft-ietf-softwire-map-00 can only be = regarded as draft-XX-softwire-mapping-address-and-port-04. It is not = even the output of MAP design team. > > > > Best wishes > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >=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: 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 From satoru.matsushima@gmail.com Sun Jun 24 19:27: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 21CC721F8594 for ; Sun, 24 Jun 2012 19:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi56PG5D3Pgx for ; Sun, 24 Jun 2012 19:27:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13DE721F858F for ; Sun, 24 Jun 2012 19:27:50 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5941597pbc.31 for ; Sun, 24 Jun 2012 19:27:49 -0700 (PDT) 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=PdQZMSmQ+dKv7nJyr5lkq0KjEb9GpxhAZ+LEh6H8z6U=; b=cz2g9RnzzQ5MmTxsybagSSdRRfKp8tYww1/kYbpZKxxKTHVE5xu+0jAgpRLmvprerT RUdAwi3I9258OqOjtYRX2fN82OPp+ID75mB/60iBY4m47tLiCVnffLk9j6itFpAk/eHY 9uHU8PN8UgyVlH5PPtFwu6rhLDQ+H7mGxKaCkeP0HRHkBt8n5MlcEnOzUP/xtJoHFHBQ u0JcdeYvc02GyxBcNp/E6M6GMeIK8wLtlq9JDSOKcwp/XfindBcWIPUUjMXXpcXg+xUB XY+3nqzBveKBtgffnn+o+UpX5mVd8t0aHGR6K35eTQsUIHZrt5apchH60ihMjM8oR2FW Fmpg== Received: by 10.68.238.232 with SMTP id vn8mr34961640pbc.78.1340591269862; Sun, 24 Jun 2012 19:27:49 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id sy3sm6976273pbc.18.2012.06.24.19.27.46 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 19:27:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 11:27:44 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1278) Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 02:27:54 -0000 Hi Yiu, No, that's a misunderstanding. Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber = mapping' in stateless manner, not to introduce 'per-flow NAT binding' or = 'per-subscriber state on demand'. cheers, --satoru On 2012/06/25, at 2:32, Lee, Yiu wrote: > Dear Satoru and MAP-DT >=20 > I echo what Peng and Qiong said. When the WG agreed working on the > stateless solution, it was very clear stated that the solution would = not > maintain states in the network. If the 1:1 mode changed this, this no > longer matched the requirements stated in the stateless motivation = draft, > thus, it would disqualify MAP as a solution for the motivation draft. >=20 > AFAIK, the MAP Design Team could propose a change, but such a dramatic > change by introducing states in the network would require WG approval. = I > would like the chairs to clarify this. >=20 > Thanks, > Yiu >=20 >=20 > On 6/24/12 12:21 PM, "Peng Wu" wrote: >=20 >> Hi Qiong, Satoru and all, >>=20 >> I should thank Qiong for pointing this out. I gotta say I'm a bit = shocked. >> If I understand the procedures of IETF correctly, a WG document = should >> reflect the consensus of the WG. MAP is approved by the WG as a >> stateless solution. As a participator in Softwire, I didn't get the >> information anywhere that the MAP WG document would cover the >> so-called 1:1, in fact per-user stateful mode before it was released, >> not to say discuss in the WG. Don't the WG need to approve such big >> change anymore? >>=20 >> Now let me provide my impression as an outsider of the MAP DT. You >> guys make great effort to build the solution, The address = composition, >> the GMA algorithm, the different types of address mapping rules. >> should be quite difficult to pull together such sophisticated ideas. = I >> guess that's what it takes to achieve the benifits of statelessness. >> And I admire that, bravo. Then, all of a sudden, you guys are saying, >> let's apply this sophisticated method to the different problem, by >> dropping quite some comlexity and twistting the mechanism a bit, = seems >> it may work. Considering the problem are now solved in a more pure = and >> clear way, I'm sorry but I CANNOT follow the logic here. >>=20 >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima >> wrote: >>> Hi Qiong, >>>=20 >>> I'm disagree with your opinion. >>>=20 >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed = in >>> the DT. >>> 2. MAP just covers so called '1:1 mode' with most granular mapping = rule >>> for CEs provisioning, which is as one of its characteristics. >>> 3. The motivation draft does not restrict that as you stated, just >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. >>>=20 >>> Best regards, >>> --satoru >>>=20 >>>=20 >>> On 2012/06/24, at 14:35, Qiong wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> As we all know, once an individual draft is adopted as a WG draft, = it >>>> is owned by the whole WG, rather than just the editors. Just as = Remi >>>> said, the normal procedure to follow is to reach WG consensus = _before_ >>>> posting a newly edited version. >>>>=20 >>>> =46rom draft-mdt-softwire-mapping-address-and-port-03 to >>>> draft-ietf-softwire-map-00, there are several changes between them. = In >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 = and >>>> IPv6 addressing, has never been discussed openly in the WG mailing >>>> list, or even in the MAP design team either. >>>>=20 >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation >>>> draft. The motivation draft has clearly defines the "Stateless 4/6 >>>> solution" as follows: >>>>=20 >>>> Stateless 4/6 solution denotes a solution which does not require = any >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by = any >>>> IP address sharing function in the Service Provider's network. This >>>> category of solutions assumes a dependency between an IPv6 prefix = and >>>> IPv4 address. >>>>=20 >>>> AFAIK what the WG has adopted MAP related draft is >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT >>>> draft-ietf-softwire-map-00. And the stateless solution should = =B3response >>>> to the solution motivation document=B2 according to the Softwire = charter. >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG = draft. >>>>=20 >>>> We can all recall that our softwire WG has worked on stateless >>>> solutions for more than one and a half years, and we have achieved = a >>>> lot of work which has been documented in charter, stateless = motivation, >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the = basic >>>> "stateless" principle and the MAP design team is also working on it >>>> together to find a better algorithm, address format, etc. So it is >>>> really not appropriate to make such changes when MAP is adopted as = a WG >>>> item in such a short time. >>>>=20 >>>> =46rom this perspective, draft-ietf-softwire-map-00 can only be = regarded >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even = the >>>> output of MAP design team. >>>>=20 >>>> Best wishes >>>>=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/ >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 >>>=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 pengwu.thu@gmail.com Sun Jun 24 20:06: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 BB69C21F858A for ; Sun, 24 Jun 2012 20:06:26 -0700 (PDT) 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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOEMw-1JAmoD for ; Sun, 24 Jun 2012 20:06:22 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0792621F858E for ; Sun, 24 Jun 2012 20:06:21 -0700 (PDT) Received: by qcmt36 with SMTP id t36so1988487qcm.15 for ; Sun, 24 Jun 2012 20:06:19 -0700 (PDT) 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:content-transfer-encoding; bh=+0hppAhyRTPCVzGE8BLvJ5lQ0PBjV2yFnGMtoSV5OR8=; b=xjjpt8ikdZsXw6Nh2J2PPy48mw/PX3YyAupr4X3t8boBiz2HX7CRJSjmIxvDwWthMf Mp0eKLCB+wdDmqOwnkXlwWHlzLNJbf7MhPuS5WVP+KwVqL11IPxmXgGNl33uVvaJl2vL nO/7vNvETIDKEdI2hncvtJ8oe7IorMy8kGuakrTv5HXLcZNO6ur9jQ2L8MJVyrAssB8y kf3B6eINkrMcdXobRd5+senkFxWXOZz1o3lL32mMGxt4zFD5eWZQ8/1+t6CqNKI0TrgY JL+TxLhnckQNK3qzvGRO/6VikyiFzTnUHghhH2rGph0u5juLtaHYev0kV9cgSu5NCfak ZZfQ== MIME-Version: 1.0 Received: by 10.229.135.11 with SMTP id l11mr4791442qct.116.1340593578922; Sun, 24 Jun 2012 20:06:18 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Sun, 24 Jun 2012 20:06:18 -0700 (PDT) In-Reply-To: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> Date: Mon, 25 Jun 2012 11:06:18 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 03:06:27 -0000 Satoru, Mapping, binding, rule, state,call it whatever you want, essentially it's the same thing: per-user IPv6 address<=3D>IPv4 address+port-set. Or you are saying that this binding is purely static? On Mon, Jun 25, 2012 at 10:27 AM, Satoru Matsushima wrote: > Hi Yiu, > > No, that's a misunderstanding. > Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber = mapping' in stateless manner, not to introduce 'per-flow NAT binding' or 'p= er-subscriber state on demand'. > > cheers, > --satoru > > On 2012/06/25, at 2:32, Lee, Yiu wrote: > >> Dear Satoru and MAP-DT >> >> I echo what Peng and Qiong said. When the WG agreed working on the >> stateless solution, it was very clear stated that the solution would not >> maintain states in the network. If the 1:1 mode changed this, this no >> longer matched the requirements stated in the stateless motivation draft= , >> thus, it would disqualify MAP as a solution for the motivation draft. >> >> AFAIK, the MAP Design Team could propose a change, but such a dramatic >> change by introducing states in the network would require WG approval. I >> would like the chairs to clarify this. >> >> Thanks, >> Yiu >> >> >> On 6/24/12 12:21 PM, "Peng Wu" wrote: >> >>> Hi Qiong, Satoru and all, >>> >>> I should thank Qiong for pointing this out. I gotta say I'm a bit shock= ed. >>> If I understand the procedures of IETF correctly, a WG document should >>> reflect the consensus of the WG. MAP is approved by the WG as a >>> stateless solution. As a participator in Softwire, I didn't get the >>> information anywhere that the MAP WG document would cover the >>> so-called 1:1, in fact per-user stateful mode before it was released, >>> not to say discuss in the WG. Don't the WG need to approve such big >>> change anymore? >>> >>> Now let me provide my impression as an outsider of the MAP DT. You >>> guys make great effort to build the solution, The address composition, >>> the GMA algorithm, the different types of address mapping rules. >>> should be quite difficult to pull together such sophisticated ideas. I >>> guess that's what it takes to achieve the benifits of statelessness. >>> And I admire that, bravo. Then, all of a sudden, you guys are saying, >>> let's apply this sophisticated method to the different problem, by >>> dropping quite some comlexity and twistting the mechanism a bit, seems >>> it may work. Considering the problem are now solved in a more pure and >>> clear way, I'm sorry but I CANNOT follow the logic here. >>> >>> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima >>> wrote: >>>> Hi Qiong, >>>> >>>> I'm disagree with your opinion. >>>> >>>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in >>>> the DT. >>>> 2. MAP just covers so called '1:1 mode' with most granular mapping rul= e >>>> for CEs provisioning, which is as one of its characteristics. >>>> 3. The motivation draft does not restrict that as you stated, just >>>> 'assumed', it's neither 'MUST' nor 'SHOULD'. >>>> >>>> Best regards, >>>> --satoru >>>> >>>> >>>> On 2012/06/24, at 14:35, Qiong wrote: >>>> >>>>> Hi all, >>>>> >>>>> As we all know, once an individual draft is adopted as a WG draft, it >>>>> is owned by the whole WG, rather than just the editors. Just as Remi >>>>> said, the normal procedure to follow is to reach WG consensus _before= _ >>>>> posting a newly edited version. >>>>> >>>>> From draft-mdt-softwire-mapping-address-and-port-03 to >>>>> draft-ietf-softwire-map-00, there are several changes between them. I= n >>>>> particular, the newly introduced "1:1 mode", which decouples IPv4 and >>>>> IPv6 addressing, has never been discussed openly in the WG mailing >>>>> list, or even in the MAP design team either. >>>>> >>>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation >>>>> draft. The motivation draft has clearly defines the "Stateless 4/6 >>>>> solution" as follows: >>>>> >>>>> Stateless 4/6 solution denotes a solution which does not require any >>>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by any >>>>> IP address sharing function in the Service Provider's network. This >>>>> category of solutions assumes a dependency between an IPv6 prefix and >>>>> IPv4 address. >>>>> >>>>> AFAIK what the WG has adopted MAP related draft is >>>>> draft-mdt-softwire-mapping-address-and-port-03, NOT >>>>> draft-ietf-softwire-map-00. And the stateless solution should =B3resp= onse >>>>> to the solution motivation document=B2 according to the Softwire char= ter. >>>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG dra= ft. >>>>> >>>>> We can all recall that our softwire WG has worked on stateless >>>>> solutions for more than one and a half years, and we have achieved a >>>>> lot of work which has been documented in charter, stateless motivatio= n, >>>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic >>>>> "stateless" principle and the MAP design team is also working on it >>>>> together to find a better algorithm, address format, etc. So it is >>>>> really not appropriate to make such changes when MAP is adopted as a = WG >>>>> item in such a short time. >>>>> >>>>> From this perspective, draft-ietf-softwire-map-00 can only be regarde= d >>>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even the >>>>> output of MAP design team. >>>>> >>>>> Best wishes >>>>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires > From fibrib@gmail.com Sun Jun 24 20:07: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 4796811E8079 for ; Sun, 24 Jun 2012 20:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEQKbMQs7gMf for ; Sun, 24 Jun 2012 20:07:40 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id C9B1F11E8073 for ; Sun, 24 Jun 2012 20:07:39 -0700 (PDT) Received: by qcmt36 with SMTP id t36so1988851qcm.15 for ; Sun, 24 Jun 2012 20:07:39 -0700 (PDT) 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=4xjIrd8ZVkbemz/LW1/MLNDF6BQ6mWX6BMUvOJwf7O8=; b=YXmKh7JgGSvRM+dXqAwI6uG+wz8w3os2jMsjzXD3dPsjzTxLZweoheU1NywpJr4j06 iL65UJs81Jzgnhwrs6AOmxRhXiUQCvcSsmkPYHl08YD3+y/S3Rj3hg+nCnNS/U6Ri5HK Dj9IU6Vd66ACIEfB0P6SjIbAHjDk+xh/qB7iBWyQMHRwPe+Nbbt3xyBQhQmJNUfn1BR4 rwXf/p3iuJX3mxzglAEEPTJLRDAGuL96P2PDYtd2oSFRAMHQxMnDef3u+ppw9lgYF3yy 65TU8K0erGDcAnjq4T6SJKv7kePgT5Mlux9HvUUS9fh3uXXARCnS/wdFuGX5fjfwOXZP t80Q== MIME-Version: 1.0 Received: by 10.224.189.17 with SMTP id dc17mr18710470qab.14.1340593659327; Sun, 24 Jun 2012 20:07:39 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Sun, 24 Jun 2012 20:07:39 -0700 (PDT) In-Reply-To: <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> Date: Mon, 25 Jun 2012 12:07:39 +0900 Message-ID: From: Maoke To: Satoru Matsushima Content-Type: multipart/alternative; boundary=20cf30334687da368104c343481d Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 03:07:44 -0000 --20cf30334687da368104c343481d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Satoru-san, Qiong, and all, i think the current 1:1 mode text of the draft should be tuned or, it would be better, to be removed. technically, i expect MAP as a completely per-session, per-subscriber stateless solution and therefore per-subscriber mapping rule is not accepted. in theory, of course, it could be an extension mode of MAP operation but, in practice, it makes the solution quite fuzzy, the code quite heavy. we (me and my company) wouldn't like to have a standard where supporting for both per-subscribe stateless and per-subscribe stateful mappings should be done together within a monolithic implementation. we support the lightweight 4over6 as an independent standard. thanks and regards, maoke 2012/6/25 Satoru Matsushima > Hi Qiong, > > Thanks you to carefully express your thought. I understand that. > > First point, let me answer for the question, 'Is MAP stateless or > stateful', the answer is: "MAP is *not* stateful solution itself". It was > discussed in the interim meeting in Beijing about 'per-subscriber mapping= ' > could be one characteristic of MAP solution. It does not introduce > 'per-flow NAT binding' or 'per-subscriber state on demand' on network sid= e. > As MAP specification, there is a case when ea-bits length indicates zero = so > that MAP needs explain this case and clearly define specification that's > what we did. > > Second, I don't have any intention to deprecate those who work hard for > that solutions. I didn't figure out that MAP possibly cover existing > solutions untill you rise this point. Now I remember that 'multi-protocol > socket v2.0', talked from the chair, which has been deeply engraved in my > mind. I believe that it is right direction for the working group. > > I agree on that we need discussion. That would be there's another choice > to define in the case of ea-bits length indicates zero. > > Best regards, > --satoru > > > On 2012/06/25, at 0:13, Qiong wrote: > > > Hi Satoru, > > > > Every solution has its solution space with respective application > scenarios as well as pros and cons. > > The essence of stateless solution, which follows the stateless > motivation approved by the WG, is to achieve efficient address mapping by > algorithmic embedding part of IPv4 address+port set into IPv6 > address/prefix, while the essence of stateful solution is to maintain the > subscriber-based state on-demand. IPv4 address and IPv6 address is not > coupled, and there is no requirement on IPv6 addressing format. It is > twisty to mix them together in one document as in the current > draft-ietf-softwire-map. It is not clear for vendors to implement and for > operators to deploy, and will lose the features for both. > > > > I'm not saying I'm against the work of stateless solutions, but it is > really not fair to just extend one solution arbitrarily to cover another > one without the permission from the WG and the authors. In particular, > lightweight 4over6 is a collaborative work of 15 co-authors for more tha= n > one and a half years, including operators from China Telecom, Tsinghua, > Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and > also the vendors from Huawei, Juniper and Cisco. > > > > Our WG or DT has never reached the consensus to have one unified > document for both stateful and stateless sotluion. And the motivation dra= ft > has never been extended to include the stateful features as well. So unle= ss > we reach the consensus first in the WG, we can then move forward with thi= s > document. > > > > Best wishes > > > > On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima < > satoru.matsushima@gmail.com> wrote: > > Hi Qiong, > > > > I'm disagree with your opinion. > > > > 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in > the DT. > > 2. MAP just covers so called '1:1 mode' with most granular mapping rule > for CEs provisioning, which is as one of its characteristics. > > 3. The motivation draft does not restrict that as you stated, just > 'assumed', it's neither 'MUST' nor 'SHOULD'. > > > > Best regards, > > --satoru > > > > > > On 2012/06/24, at 14:35, Qiong wrote: > > > > > Hi all, > > > > > > As we all know, once an individual draft is adopted as a WG draft, it > is owned by the whole WG, rather than just the editors. Just as Remi said= , > the normal procedure to follow is to reach WG consensus _before_ posting = a > newly edited version. > > > > > > From draft-mdt-softwire-mapping-address-and-port-03 to > draft-ietf-softwire-map-00, there are several changes between them. In > particular, the newly introduced "1:1 mode", which decouples IPv4 and IPv= 6 > addressing, has never been discussed openly in the WG mailing list, or ev= en > in the MAP design team either. > > > > > > Actually, this "1:1 mode" is against the stateless-4v6-motivation > draft. The motivation draft has clearly defines the "Stateless 4/6 > solution" as follows: > > > > > > Stateless 4/6 solution denotes a solution which does not require any > per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP > address sharing function in the Service Provider's network. This category > of solutions assumes a dependency between an IPv6 prefix and IPv4 address= . > > > > > > AFAIK what the WG has adopted MAP related draft is > draft-mdt-softwire-mapping-address-and-port-03, NOT > draft-ietf-softwire-map-00. And the stateless solution should =93response= to > the solution motivation document=94 according to the Softwire charter. Th= at > means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. > > > > > > We can all recall that our softwire WG has worked on stateless > solutions for more than one and a half years, and we have achieved a lot = of > work which has been documented in charter, stateless motivation, > 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic > "stateless" principle and the MAP design team is also working on it > together to find a better algorithm, address format, etc. So it is really > not appropriate to make such changes when MAP is adopted as a WG item in > such a short time. > > > > > > From this perspective, draft-ietf-softwire-map-00 can only be regarde= d > as draft-XX-softwire-mapping-address-and-port-04. It is not even the outp= ut > of MAP design team. > > > > > > Best wishes > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > > > > > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > --20cf30334687da368104c343481d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
hi Satoru-san, Qiong, and all,=A0

i think= the current 1:1 mode text of the draft should be tuned or, it would be bet= ter, to be removed.

technically, i expect MAP as = a completely per-session, per-subscriber stateless solution and therefore p= er-subscriber mapping rule is not accepted. in theory, of course, it could = be an extension mode of MAP operation but, in practice, it makes the soluti= on quite fuzzy, the code quite heavy. we (me and my company) wouldn't l= ike to have a standard where supporting for both per-subscribe stateless an= d per-subscribe stateful mappings should be done together within a monolith= ic implementation. we support the lightweight 4over6 as an independent stan= dard.=A0

thanks and regards,
maoke

2012/6/25 Satoru Matsushima <satoru.matsushima= @gmail.com>
Hi Qiong,

Thanks you to carefully express your thought. I understand that.

First point, let me answer for the question, 'Is MAP stateless or state= ful', the answer is: "MAP is *not* stateful solution itself".= It was discussed in the interim meeting in Beijing about 'per-subscrib= er mapping' could be one characteristic of MAP solution. It does not in= troduce 'per-flow NAT binding' or 'per-subscriber state on dema= nd' on network side. As MAP specification, there is a case when ea-bits= length indicates zero so that MAP needs explain this case and clearly defi= ne specification that's what we did.

Second, I don't have any intention to deprecate those who work hard for= that solutions. =A0I didn't figure out that MAP possibly cover existin= g solutions untill you rise this point. Now I remember that 'multi-prot= ocol socket v2.0', talked from the chair, which has been deeply engrave= d in my mind. I believe that it is right direction for the working group.
I agree on that we need discussion. That would be there's another choic= e to define in the case of ea-bits length indicates zero.

Best regards,
--satoru


On 2012/06/25, at 0:13, Qiong wrote:

> Hi Satoru,
>
> Every solution has its solution space with respective application scen= arios as well as pros and cons.
> The essence of stateless solution, which follows the stateless motivat= ion approved by the WG, is to achieve efficient address mapping by algorith= mic embedding part of IPv4 address+port set into IPv6 address/prefix, while= the essence of stateful solution is to maintain the subscriber-based state= on-demand. IPv4 address and IPv6 address is not coupled, and there is no r= equirement on IPv6 addressing format. It is twisty to mix them together in = one document as in the current draft-ietf-softwire-map. It is not clear for= vendors to implement and for operators to deploy, and will lose the featur= es for both.
>
> I'm not saying I'm against the work of stateless solutions, bu= t it is really not fair to just extend one solution arbitrarily to cover an= other one without the permission from the WG and the authors. In particular= , =A0lightweight 4over6 is a collaborative work of 15 co-authors for more t= han one and a half years, including operators from China Telecom, Tsinghua,= Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and =A0= also the vendors from Huawei, Juniper and Cisco.
>
> Our WG or DT has never reached the consensus to have one unified docum= ent for both stateful and stateless sotluion. And the motivation draft has = never been extended to include the stateful features as well. So unless we = reach the consensus first in the WG, we can then move forward with this doc= ument.
>
> Best wishes
>
> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima <satoru.matsushima@gmail.com> wrote:<= br> > Hi Qiong,
>
> I'm disagree with your opinion.
>
> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in = the DT.
> 2. MAP just covers so called '1:1 mode' with most granular map= ping rule for CEs provisioning, which is as one of its characteristics.
> 3. The motivation draft does not restrict that as you stated, just = 9;assumed', it's neither 'MUST' nor 'SHOULD'.
>
> Best regards,
> --satoru
>
>
> On 2012/06/24, at 14:35, Qiong wrote:
>
> > Hi all,
> >
> > As we all know, once an individual draft is adopted as a WG draft= , it is owned by the whole WG, rather than just the editors. Just as Remi s= aid, the normal procedure to follow is to reach WG consensus _before_ posti= ng a newly edited version.
> >
> > From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf= -softwire-map-00, there are several changes between them. In particular, th= e newly introduced "1:1 mode", which decouples IPv4 and IPv6 addr= essing, has never been discussed openly in the WG mailing list, or even in = the MAP design team either.
> >
> > Actually, this "1:1 mode" is against the stateless-4v6-= motivation draft. The motivation draft has clearly defines the "Statel= ess 4/6 solution" as follows:
> >
> > Stateless 4/6 solution denotes a solution which does not require = any per-user state (see Section 2.3 of [RFC1958]) to be maintained by any I= P address sharing function in the Service Provider's network. This cate= gory of solutions assumes a dependency between an IPv6 prefix and IPv4 addr= ess.
> >
> > AFAIK what the WG has adopted MAP related draft is draft-mdt-soft= wire-mapping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the s= tateless solution should =93response to the solution motivation document=94= according to the Softwire charter. That means draft-ietf-softwire-map-00 I= S NOT QUALIFIED to be a WG draft.
> >
> > We can all recall that our softwire WG has worked on stateless so= lutions for more than one and a half years, and we have achieved a lot of w= ork which has been documented in charter, stateless motivation, 4rd-varient= s, MAP-03, etc. AFAIK all the authors have kept the basic "stateless&q= uot; principle and the MAP design team is also working on it together to fi= nd a better algorithm, address format, etc. So it is really not appropriate= to make such changes when MAP is adopted as a WG item in such a short time= .
> >
> > From this perspective, draft-ietf-softwire-map-00 can only be reg= arded as draft-XX-softwire-mapping-address-and-port-04. It is not even the = output of MAP design team.
> >
> > Best wishes
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=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/<= /a>
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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
>
>
>
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

--20cf30334687da368104c343481d-- From pengwu.thu@gmail.com Sun Jun 24 20:10: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 9150811E8073 for ; Sun, 24 Jun 2012 20:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3D6GQtmKPZC for ; Sun, 24 Jun 2012 20:10:47 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEBC21F85F6 for ; Sun, 24 Jun 2012 20:10:47 -0700 (PDT) Received: by qadz3 with SMTP id z3so1179557qad.10 for ; Sun, 24 Jun 2012 20:10:46 -0700 (PDT) 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:content-transfer-encoding; bh=XCfAkDgt0HdiHdxCqAGnnwyEjwyke03tVoaXU4x6CDU=; b=dgXKlQN+rkZekApEczdcqBkTkwUwOdWwrn1N2MfrPWWGbSdLAk7JkUkb+7Jh4elhug Yg3pPCT3dCbZ7gJ8w+kDuZQVYlY6I0C07PnrKzM8ZgiuqZEIolFycV/ODkJvGo2IAhwi GMGzxe/7QlpG/jRtyKEDVPDTjRCwkDOKD1Q60zfcO5g3izTPKYfKPmkgvuoZ5YF14Q3k ur2HEESlYT/sBH9XZtDHNY7MngTyI2/WzrqiHMYDQ8lM1L0cJ4WyD9qYBuDBkyrEq20Y G28gNJUBZaoeldwyCw4F3Ty1JdkTEKwwb/MuCpbAV35lpaFSFj0hUS6fS66Mre3H3Maz UeFw== MIME-Version: 1.0 Received: by 10.224.32.205 with SMTP id e13mr18524956qad.69.1340593846055; Sun, 24 Jun 2012 20:10:46 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Sun, 24 Jun 2012 20:10:45 -0700 (PDT) In-Reply-To: <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> Date: Mon, 25 Jun 2012 11:10:45 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 03:10:51 -0000 If I recall correctly, the Interim meeting dicussed the rationality of per-subsriber stateful solutions ASIDE FROM the stateless solutions, rather than " 'per-subscriber mapping' could be one characteristic of MAP solution" On Mon, Jun 25, 2012 at 9:55 AM, Satoru Matsushima wrote: > Hi Qiong, > > Thanks you to carefully express your thought. I understand that. > > First point, let me answer for the question, 'Is MAP stateless or statefu= l', the answer is: "MAP is *not* stateful solution itself". It was discusse= d in the interim meeting in Beijing about 'per-subscriber mapping' could be= one characteristic of MAP solution. It does not introduce 'per-flow NAT bi= nding' or 'per-subscriber state on demand' on network side. As MAP specific= ation, there is a case when ea-bits length indicates zero so that MAP needs= explain this case and clearly define specification that's what we did. > > Second, I don't have any intention to deprecate those who work hard for t= hat solutions. =A0I didn't figure out that MAP possibly cover existing solu= tions untill you rise this point. Now I remember that 'multi-protocol socke= t v2.0', talked from the chair, which has been deeply engraved in my mind. = I believe that it is right direction for the working group. > > I agree on that we need discussion. That would be there's another choice = to define in the case of ea-bits length indicates zero. > > Best regards, > --satoru > > > On 2012/06/25, at 0:13, Qiong wrote: > >> Hi Satoru, >> >> Every solution has its solution space with respective application scenar= ios as well as pros and cons. >> The essence of stateless solution, which follows the stateless motivatio= n approved by the WG, is to achieve efficient address mapping by algorithmi= c embedding part of IPv4 address+port set into IPv6 address/prefix, while t= he essence of stateful solution is to maintain the subscriber-based state o= n-demand. IPv4 address and IPv6 address is not coupled, and there is no req= uirement on IPv6 addressing format. It is twisty to mix them together in on= e document as in the current draft-ietf-softwire-map. It is not clear for v= endors to implement and for operators to deploy, and will lose the features= for both. >> >> I'm not saying I'm against the work of stateless solutions, but it is re= ally not fair to just extend one solution arbitrarily to cover another one = without the permission from the WG and the authors. In particular, =A0light= weight 4over6 is a collaborative work of 15 co-authors for more than one an= d a half years, including operators from China Telecom, Tsinghua, Comcast, = France telecom, Deutsche Telekom, Bouygues Telecom, etc., and =A0also the v= endors from Huawei, Juniper and Cisco. >> >> Our WG or DT has never reached the consensus to have one unified documen= t for both stateful and stateless sotluion. And the motivation draft has ne= ver been extended to include the stateful features as well. So unless we re= ach the consensus first in the WG, we can then move forward with this docum= ent. >> >> Best wishes >> >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima wrote: >> Hi Qiong, >> >> I'm disagree with your opinion. >> >> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in th= e DT. >> 2. MAP just covers so called '1:1 mode' with most granular mapping rule = for CEs provisioning, which is as one of its characteristics. >> 3. The motivation draft does not restrict that as you stated, just 'assu= med', it's neither 'MUST' nor 'SHOULD'. >> >> Best regards, >> --satoru >> >> >> On 2012/06/24, at 14:35, Qiong wrote: >> >> > Hi all, >> > >> > As we all know, once an individual draft is adopted as a WG draft, it = is owned by the whole WG, rather than just the editors. Just as Remi said, = the normal procedure to follow is to reach WG consensus _before_ posting a = newly edited version. >> > >> > From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf-soft= wire-map-00, there are several changes between them. In particular, the new= ly introduced "1:1 mode", which decouples IPv4 and IPv6 addressing, has nev= er been discussed openly in the WG mailing list, or even in the MAP design = team either. >> > >> > Actually, this "1:1 mode" is against the stateless-4v6-motivation draf= t. The motivation draft has clearly defines the "Stateless 4/6 solution" as= follows: >> > >> > Stateless 4/6 solution denotes a solution which does not require any p= er-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP add= ress sharing function in the Service Provider's network. This category of s= olutions assumes a dependency between an IPv6 prefix and IPv4 address. >> > >> > AFAIK what the WG has adopted MAP related draft is draft-mdt-softwire-= mapping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the statel= ess solution should =93response to the solution motivation document=94 acco= rding to the Softwire charter. That means draft-ietf-softwire-map-00 IS NOT= QUALIFIED to be a WG draft. >> > >> > We can all recall that our softwire WG has worked on stateless solutio= ns for more than one and a half years, and we have achieved a lot of work w= hich has been documented in charter, stateless motivation, 4rd-varients, MA= P-03, etc. AFAIK all the authors have kept the basic "stateless" principle = and the MAP design team is also working on it together to find a better alg= orithm, address format, etc. So it is really not appropriate to make such c= hanges when MAP is adopted as a WG item in such a short time. >> > >> > From this perspective, draft-ietf-softwire-map-00 can only be regarded= as draft-XX-softwire-mapping-address-and-port-04. It is not even the outpu= t of MAP design team. >> > >> > Best wishes >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >> >> >> >> >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 From yiu_lee@cable.comcast.com Sun Jun 24 20:40: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 A862E21F8582 for ; Sun, 24 Jun 2012 20:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.187 X-Spam-Level: X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=-1.289, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lbcJExh2iBj for ; Sun, 24 Jun 2012 20:40:50 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 693FB21F84FD for ; Sun, 24 Jun 2012 20:40:49 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.17059006; Sun, 24 Jun 2012 23:30:58 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Sun, 24 Jun 2012 23:40:41 -0400 From: "Lee, Yiu" To: Satoru Matsushima Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNUoRKFkxLa+Lv00yBYy061yskkw== Date: Mon, 25 Jun 2012 03:40:40 +0000 Message-ID: In-Reply-To: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3423426040_6345690" MIME-Version: 1.0 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 03:40:50 -0000 --B_3423426040_6345690 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Satoru, I do not understand how to create "per-subscriber mapping" in a stateless manner. In the end, the BR must contain all mapping rules for all 1:1 subscribers. This is stateful to my understanding. Could you please explain how not to maintain any mapping rule in BR to achieve this? Thanks and regards, Yiu On 6/24/12 10:27 PM, "Satoru Matsushima" wrote: >No, that's a misunderstanding. >Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber >mapping' in stateless manner, not to introduce 'per-flow NAT binding' or >'per-subscriber state on demand'. > --B_3423426040_6345690 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQbHgcJ 7AFafG2cRW0gbj94jr5mADAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MjUwMzQwMzlaMA0GCSqGSIb3DQEBAQUABIIBAI0Lk219kX6GVfKE/oEpt0R+ SbtsBpvedXFto74y5TVHVjY25PQVAzfF6etHV4j0tMn1ZLytCO6g57OrLOgjY4ubYIyNtens DusFER0Q0k2HVTG5uFOLeWg75n+NjQ0lu/cAofIGGopSmOwnqi9nuMsH/eRSWRWpdveatJAV 3KrKPVfJZyYCAsGRGzb3MxDojPQvX0ZmqBlMVpBTS0nXIyA/mCNDEX4ZzrejxlNwdcylrqMa 1ErtiUFDIIHIVMgF4wM+VqfItFNeubOtVTJAXciwswlt1CCpmJGU1065hlCAAl4c/cRms/8x DxCjVZUQjKy6l97TUg5AhrvDgM85hAw= --B_3423426040_6345690-- From satoru.matsushima@gmail.com Sun Jun 24 20:45:14 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 9814C21F8646 for ; Sun, 24 Jun 2012 20:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkjLpqFVj5+B for ; Sun, 24 Jun 2012 20:45:10 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A813821F8639 for ; Sun, 24 Jun 2012 20:45:10 -0700 (PDT) Received: by dacx6 with SMTP id x6so4736284dac.31 for ; Sun, 24 Jun 2012 20:45:10 -0700 (PDT) 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=sJLAtX+NO7WivQ4FzjOI1Gr6gpDxLeICEZxbJHehOnc=; b=Vaz0bYYQ+9NS3UZzXcfKMNWHFoRY68QeG258QGfVAMG2/94zFgbc3CNcaGg+DfKhf0 ZTtMRzVMKI54Zkv7Br19f+8o6c1K1f9etwxKCwgbYmpQyjs6SWumj8gFgNx6bYAeLnNj lfWI1G1fT7FTdoH8eInZpwIFLmRCC17aLXYJj/HbfKzNLknOkhLH6cEAVSbqS3c6DJD1 ZiGs0N2cFf8gjqdI9X0WxwkVjYt0ljZq/QNGi6FvVno9YV73RAP4sUuJZpw/Uq9/P/SW ZynJ6u5AfqmVNgu8VN/OGldMnAiafdbDnkJ8ucexrx1DbxyHBhp4H5AJJlAiV68VtiUs 1zkg== Received: by 10.68.209.197 with SMTP id mo5mr16338268pbc.72.1340595910457; Sun, 24 Jun 2012 20:45:10 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id ny10sm7153321pbb.38.2012.06.24.20.45.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 20:45:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 12:45:04 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 03:45:14 -0000 Peng, On 2012/06/25, at 12:06, Peng Wu wrote: > Satoru, >=20 > Mapping, binding, rule, state,call it whatever you want, essentially > it's the same thing: per-user IPv6 address<=3D>IPv4 address+port-set. > Or you are saying that this binding is purely static? >=20 Static, right. --satoru > On Mon, Jun 25, 2012 at 10:27 AM, Satoru Matsushima > wrote: >> Hi Yiu, >>=20 >> No, that's a misunderstanding. >> Current MAP specify the case for ea-len is 'zero'. It is = 'per-subscriber mapping' in stateless manner, not to introduce 'per-flow = NAT binding' or 'per-subscriber state on demand'. >>=20 >> cheers, >> --satoru >>=20 >> On 2012/06/25, at 2:32, Lee, Yiu wrote: >>=20 >>> Dear Satoru and MAP-DT >>>=20 >>> I echo what Peng and Qiong said. When the WG agreed working on the >>> stateless solution, it was very clear stated that the solution would = not >>> maintain states in the network. If the 1:1 mode changed this, this = no >>> longer matched the requirements stated in the stateless motivation = draft, >>> thus, it would disqualify MAP as a solution for the motivation = draft. >>>=20 >>> AFAIK, the MAP Design Team could propose a change, but such a = dramatic >>> change by introducing states in the network would require WG = approval. I >>> would like the chairs to clarify this. >>>=20 >>> Thanks, >>> Yiu >>>=20 >>>=20 >>> On 6/24/12 12:21 PM, "Peng Wu" wrote: >>>=20 >>>> Hi Qiong, Satoru and all, >>>>=20 >>>> I should thank Qiong for pointing this out. I gotta say I'm a bit = shocked. >>>> If I understand the procedures of IETF correctly, a WG document = should >>>> reflect the consensus of the WG. MAP is approved by the WG as a >>>> stateless solution. As a participator in Softwire, I didn't get the >>>> information anywhere that the MAP WG document would cover the >>>> so-called 1:1, in fact per-user stateful mode before it was = released, >>>> not to say discuss in the WG. Don't the WG need to approve such big >>>> change anymore? >>>>=20 >>>> Now let me provide my impression as an outsider of the MAP DT. You >>>> guys make great effort to build the solution, The address = composition, >>>> the GMA algorithm, the different types of address mapping rules. >>>> should be quite difficult to pull together such sophisticated = ideas. I >>>> guess that's what it takes to achieve the benifits of = statelessness. >>>> And I admire that, bravo. Then, all of a sudden, you guys are = saying, >>>> let's apply this sophisticated method to the different problem, by >>>> dropping quite some comlexity and twistting the mechanism a bit, = seems >>>> it may work. Considering the problem are now solved in a more pure = and >>>> clear way, I'm sorry but I CANNOT follow the logic here. >>>>=20 >>>> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima >>>> wrote: >>>>> Hi Qiong, >>>>>=20 >>>>> I'm disagree with your opinion. >>>>>=20 >>>>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed = in >>>>> the DT. >>>>> 2. MAP just covers so called '1:1 mode' with most granular mapping = rule >>>>> for CEs provisioning, which is as one of its characteristics. >>>>> 3. The motivation draft does not restrict that as you stated, just >>>>> 'assumed', it's neither 'MUST' nor 'SHOULD'. >>>>>=20 >>>>> Best regards, >>>>> --satoru >>>>>=20 >>>>>=20 >>>>> On 2012/06/24, at 14:35, Qiong wrote: >>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> As we all know, once an individual draft is adopted as a WG = draft, it >>>>>> is owned by the whole WG, rather than just the editors. Just as = Remi >>>>>> said, the normal procedure to follow is to reach WG consensus = _before_ >>>>>> posting a newly edited version. >>>>>>=20 >>>>>> =46rom draft-mdt-softwire-mapping-address-and-port-03 to >>>>>> draft-ietf-softwire-map-00, there are several changes between = them. In >>>>>> particular, the newly introduced "1:1 mode", which decouples IPv4 = and >>>>>> IPv6 addressing, has never been discussed openly in the WG = mailing >>>>>> list, or even in the MAP design team either. >>>>>>=20 >>>>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation >>>>>> draft. The motivation draft has clearly defines the "Stateless = 4/6 >>>>>> solution" as follows: >>>>>>=20 >>>>>> Stateless 4/6 solution denotes a solution which does not require = any >>>>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by = any >>>>>> IP address sharing function in the Service Provider's network. = This >>>>>> category of solutions assumes a dependency between an IPv6 prefix = and >>>>>> IPv4 address. >>>>>>=20 >>>>>> AFAIK what the WG has adopted MAP related draft is >>>>>> draft-mdt-softwire-mapping-address-and-port-03, NOT >>>>>> draft-ietf-softwire-map-00. And the stateless solution should = =B3response >>>>>> to the solution motivation document=B2 according to the Softwire = charter. >>>>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG = draft. >>>>>>=20 >>>>>> We can all recall that our softwire WG has worked on stateless >>>>>> solutions for more than one and a half years, and we have = achieved a >>>>>> lot of work which has been documented in charter, stateless = motivation, >>>>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the = basic >>>>>> "stateless" principle and the MAP design team is also working on = it >>>>>> together to find a better algorithm, address format, etc. So it = is >>>>>> really not appropriate to make such changes when MAP is adopted = as a WG >>>>>> item in such a short time. >>>>>>=20 >>>>>> =46rom this perspective, draft-ietf-softwire-map-00 can only be = regarded >>>>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even = the >>>>>> output of MAP design team. >>>>>>=20 >>>>>> Best wishes >>>>>>=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/ >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 >>>>>=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 >>=20 From satoru.matsushima@gmail.com Sun Jun 24 20:47: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 1CF9521F859F for ; Sun, 24 Jun 2012 20:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bRGTk3mO3LO for ; Sun, 24 Jun 2012 20:47:38 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92FDF21F856F for ; Sun, 24 Jun 2012 20:47:38 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6006673pbc.31 for ; Sun, 24 Jun 2012 20:47:38 -0700 (PDT) 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=B/Jvx1NOj9iAkJXkCAgLjKTnIm0x4PaM0ND0iA9oibI=; b=hKNCER/025C24eyMeHzdRMOBT8P/PRnLFm5yovbeI5gcGW6RyQ+dCcGGnJUBuU3j8U bgnJSd9//8ZhtvjCTKIgQlSCLl1TrbfIz3CV+GPwV7l0iCEOgQkHYeqfrn0rtTWaBkg+ Rb28jSJNzhkHerLtFkNCOMr5CGaZ35YII3xBwDGtZdblz7dp5AlSZrVUaq0zdG7/Sp8s 1tBSFaZS+w0uTiqvEsGAGhyCgMko5bV3iB3pi1+QkUtGcZhB/V0NGfDmx5xLrjuiJUT3 jrK0VBZosgK/VRLU6Wbar/ekDValqvZvKuJIaqRYB593C+8kcO5F+7tT+InByNn6N2KE 6JDg== Received: by 10.68.194.105 with SMTP id hv9mr27203683pbc.126.1340596058450; Sun, 24 Jun 2012 20:47:38 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id rd7sm7148972pbc.70.2012.06.24.20.47.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 20:47:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 12:47:34 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1278) Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 03:47:39 -0000 Hi Yiu, On 2012/06/25, at 12:40, Lee, Yiu wrote: > Dear Satoru, >=20 > I do not understand how to create "per-subscriber mapping" in a = stateless > manner. In the end, the BR must contain all mapping rules for all 1:1 > subscribers. This is stateful to my understanding. Could you please > explain how not to maintain any mapping rule in BR to achieve this? This could be same operation with any other, configure FMRs into a map = tunnel. Nothing changed. cheers, --satoru >=20 > Thanks and regards, > Yiu >=20 >=20 > On 6/24/12 10:27 PM, "Satoru Matsushima" > wrote: >=20 >> No, that's a misunderstanding. >> Current MAP specify the case for ea-len is 'zero'. It is = 'per-subscriber >> mapping' in stateless manner, not to introduce 'per-flow NAT binding' = or >> 'per-subscriber state on demand'. >>=20 From yiu_lee@cable.comcast.com Sun Jun 24 20:50: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 0964911E8085 for ; Sun, 24 Jun 2012 20:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e487521sdaUC for ; Sun, 24 Jun 2012 20:50:48 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3A15D21F856F for ; Sun, 24 Jun 2012 20:50:48 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.17059231; Sun, 24 Jun 2012 23:40:59 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%15]) with mapi id 14.02.0283.003; Sun, 24 Jun 2012 23:50:42 -0400 From: "Lee, Yiu" To: Satoru Matsushima Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNUoWxkgQkpVKIO0CmMJbcZZxzaA== Date: Mon, 25 Jun 2012 03:50:42 +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.2.120421 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3423426640_6402548" MIME-Version: 1.0 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 03:50:49 -0000 --B_3423426640_6402548 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Satoru, To me, this changes the stateless operation model. I respectfully disagree your statement "Nothing changed". Regards, Yiu On 6/24/12 11:47 PM, "Satoru Matsushima" wrote: >This could be same operation with any other, configure FMRs into a map >tunnel. >Nothing changed. > >cheers, >--satoru --B_3423426640_6402548 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTe5YQY vNhNOZmI5GUrvpqz/Jdu6DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MjUwMzUwMzlaMA0GCSqGSIb3DQEBAQUABIIBAFmmelM3r82CU7SqaVcIr+C5 JQSqHC/AxGzBKkSC/rgDCsGENv/+jBjsXPQwBBRTeMg0yxCb4mGNv5xhrH2hU9PrVeTBedB2 LyZ6sL9irIF742MquwHAoSwCMQqwyEV1gaxTs0dO47JvK+Ae/sG7M+p8tVnJqUU0H8CXGS8H dmzXv7yf9rKWwo0wxTe2CViTuKyHHyScBANMhD1K1jOdSR0B5ipKkKkUBuDQG1KefxauDLQt y9r8lGCoftHXixRpqvKiLX8tRtMy+t+fojaZgdt5+5xo3+sP2IEGUIQYZvHVNFhSKpAtgt08 /lcbCWnaXNUcQHI+AJTI5C1xdSrRteM= --B_3423426640_6402548-- From pengwu.thu@gmail.com Sun Jun 24 22:13: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 A581221F84EA for ; Sun, 24 Jun 2012 22:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdMIZZjNMtp6 for ; Sun, 24 Jun 2012 22:13:15 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1630221F84B6 for ; Sun, 24 Jun 2012 22:13:14 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2020048qcm.15 for ; Sun, 24 Jun 2012 22:13:14 -0700 (PDT) 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=7gStignIOYoROpvlOeCACoxmTNOVZ+fpLAAiCkh9oAU=; b=sxYQTpgTg2403JBfwujyi59KkrkQjw35wmAqQnGy25xSnWIk7kzFkCS7y6fd9qaWs3 wqT0b/g9i7hjmgbHpm7/yadDovxkSLUV1LEzJDJKoQ4yZwvmlR0TPYoJCss1tArv48Z+ EMLQV4Gl/iB/i7uVE+VuItYuEemPMkmc7P/TMAwYT+1MZD5M3xLl1rYJUwmmrzvRY7uK RKL763oMIuovqcnsteetfkHjrfk+RWJ7FBdlscletqFGnH06WTuSKUe8EVqWWV+gcHNF VR66UU75kkS5Ph4FYbYZ9R0efGzvPkWT5i2Q+obcS6kV+8W/LHaoHU5y48rVz27AF8go NaWw== MIME-Version: 1.0 Received: by 10.224.78.195 with SMTP id m3mr19371237qak.1.1340601194551; Sun, 24 Jun 2012 22:13:14 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Sun, 24 Jun 2012 22:13:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jun 2012 13:13:14 +0800 Message-ID: From: Peng Wu To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 05:13:15 -0000 +1. Exactly. On Mon, Jun 25, 2012 at 11:50 AM, Lee, Yiu wrote: > Hi Satoru, > > To me, this changes the stateless operation model. I respectfully disagree > your statement "Nothing changed". > > Regards, > Yiu > > On 6/24/12 11:47 PM, "Satoru Matsushima" > wrote: > >>This could be same operation with any other, configure FMRs into a map >>tunnel. >>Nothing changed. >> >>cheers, >>--satoru From bingxuere@gmail.com Sun Jun 24 23:07: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 DDAE921F855A for ; Sun, 24 Jun 2012 23:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.122 X-Spam-Level: X-Spam-Status: No, score=-3.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9RgtDerMeaF for ; Sun, 24 Jun 2012 23:07:38 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5BB21F8559 for ; Sun, 24 Jun 2012 23:07:38 -0700 (PDT) Received: by yhp26 with SMTP id 26so4155085yhp.26 for ; Sun, 24 Jun 2012 23:07:38 -0700 (PDT) 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=MQb0Y8W+64b8l2UTbII8X2/C21CPRBV8Qo6+KcuaBaw=; b=jsYlgdIIYHI0QsXUpONlkRRakpez+Ibrr10BwKKwJVDvH6jHnxUF5JfZ5B3q4VCXYe v3AEM8esXCxlnNeAXV8wER7T2FawjxNxnYAhNrhCBRNqNVhIrTlDWaaSqerlmU4saiJb q3mE2ORGl91DV1mhH1pOAkNT9W2ATif19Z509sON9tYbZ4c2+izKCjD7wpaLUeiqyHN3 xBV1E8gbfDW4XxxctbHF2zSmEp1CYl6u6kXWCB3Nr4MRJRNxRionkGZrVcTyxGbx/gDO YPSTjSdHSn2zxEorxwzXHzb/z97Rm4n58McRqgObZnKHklJIkj+7yfZORnvU3/tCPhAg 6Wpw== Received: by 10.50.188.131 with SMTP id ga3mr7198849igc.54.1340604457540; Sun, 24 Jun 2012 23:07:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Sun, 24 Jun 2012 23:06:57 -0700 (PDT) In-Reply-To: <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> From: Qiong Date: Mon, 25 Jun 2012 14:06:57 +0800 Message-ID: To: Satoru Matsushima Content-Type: multipart/alternative; boundary=14dae934115779dc8304c345ccba Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 06:07:43 -0000 --14dae934115779dc8304c345ccba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Satoru, Would you please point out in which presentation in the Beijing Interim meeting illustrated "per-subscriber mapping" as one characteristic of MAP solution? I recall which xiaohong presented was a stateful one. Best wishes On Mon, Jun 25, 2012 at 9:55 AM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hi Qiong, > > Thanks you to carefully express your thought. I understand that. > > First point, let me answer for the question, 'Is MAP stateless or > stateful', the answer is: "MAP is *not* stateful solution itself". It was > discussed in the interim meeting in Beijing about 'per-subscriber mapping= ' > could be one characteristic of MAP solution. It does not introduce > 'per-flow NAT binding' or 'per-subscriber state on demand' on network sid= e. > As MAP specification, there is a case when ea-bits length indicates zero = so > that MAP needs explain this case and clearly define specification that's > what we did. > > Second, I don't have any intention to deprecate those who work hard for > that solutions. I didn't figure out that MAP possibly cover existing > solutions untill you rise this point. Now I remember that 'multi-protocol > socket v2.0', talked from the chair, which has been deeply engraved in my > mind. I believe that it is right direction for the working group. > > I agree on that we need discussion. That would be there's another choice > to define in the case of ea-bits length indicates zero. > > Best regards, > --satoru > > > On 2012/06/25, at 0:13, Qiong wrote: > > > Hi Satoru, > > > > Every solution has its solution space with respective application > scenarios as well as pros and cons. > > The essence of stateless solution, which follows the stateless > motivation approved by the WG, is to achieve efficient address mapping by > algorithmic embedding part of IPv4 address+port set into IPv6 > address/prefix, while the essence of stateful solution is to maintain the > subscriber-based state on-demand. IPv4 address and IPv6 address is not > coupled, and there is no requirement on IPv6 addressing format. It is > twisty to mix them together in one document as in the current > draft-ietf-softwire-map. It is not clear for vendors to implement and for > operators to deploy, and will lose the features for both. > > > > I'm not saying I'm against the work of stateless solutions, but it is > really not fair to just extend one solution arbitrarily to cover another > one without the permission from the WG and the authors. In particular, > lightweight 4over6 is a collaborative work of 15 co-authors for more tha= n > one and a half years, including operators from China Telecom, Tsinghua, > Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and > also the vendors from Huawei, Juniper and Cisco. > > > > Our WG or DT has never reached the consensus to have one unified > document for both stateful and stateless sotluion. And the motivation dra= ft > has never been extended to include the stateful features as well. So unle= ss > we reach the consensus first in the WG, we can then move forward with thi= s > document. > > > > Best wishes > > > > On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima < > satoru.matsushima@gmail.com> wrote: > > Hi Qiong, > > > > I'm disagree with your opinion. > > > > 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in > the DT. > > 2. MAP just covers so called '1:1 mode' with most granular mapping rule > for CEs provisioning, which is as one of its characteristics. > > 3. The motivation draft does not restrict that as you stated, just > 'assumed', it's neither 'MUST' nor 'SHOULD'. > > > > Best regards, > > --satoru > > > > > > On 2012/06/24, at 14:35, Qiong wrote: > > > > > Hi all, > > > > > > As we all know, once an individual draft is adopted as a WG draft, it > is owned by the whole WG, rather than just the editors. Just as Remi said= , > the normal procedure to follow is to reach WG consensus _before_ posting = a > newly edited version. > > > > > > From draft-mdt-softwire-mapping-address-and-port-03 to > draft-ietf-softwire-map-00, there are several changes between them. In > particular, the newly introduced "1:1 mode", which decouples IPv4 and IPv= 6 > addressing, has never been discussed openly in the WG mailing list, or ev= en > in the MAP design team either. > > > > > > Actually, this "1:1 mode" is against the stateless-4v6-motivation > draft. The motivation draft has clearly defines the "Stateless 4/6 > solution" as follows: > > > > > > Stateless 4/6 solution denotes a solution which does not require any > per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP > address sharing function in the Service Provider's network. This category > of solutions assumes a dependency between an IPv6 prefix and IPv4 address= . > > > > > > AFAIK what the WG has adopted MAP related draft is > draft-mdt-softwire-mapping-address-and-port-03, NOT > draft-ietf-softwire-map-00. And the stateless solution should =E2=80=9Cre= sponse to > the solution motivation document=E2=80=9D according to the Softwire chart= er. That > means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. > > > > > > We can all recall that our softwire WG has worked on stateless > solutions for more than one and a half years, and we have achieved a lot = of > work which has been documented in charter, stateless motivation, > 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic > "stateless" principle and the MAP design team is also working on it > together to find a better algorithm, address format, etc. So it is really > not appropriate to make such changes when MAP is adopted as a WG item in > such a short time. > > > > > > From this perspective, draft-ietf-softwire-map-00 can only be regarde= d > as draft-XX-softwire-mapping-address-and-port-04. It is not even the outp= ut > of MAP design team. > > > > > > Best wishes > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > > > > > > > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 --14dae934115779dc8304c345ccba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Satoru,

Would you please point out in which presentation in the B= eijing Interim meeting illustrated "per-subscriber mapping" as on= e characteristic of MAP solution? I recall which xiaohong presented was a s= tateful one.

Best wishes

On Mon, Jun 25, 2012 at 9= :55 AM, Satoru Matsushima <satoru.matsushima@gmail.com> wrote:
Hi Qiong,

Thanks you to carefully express your thought. I understand that.

First point, let me answer for the question, 'Is MAP stateless or state= ful', the answer is: "MAP is *not* stateful solution itself".= It was discussed in the interim meeting in Beijing about 'per-subscrib= er mapping' could be one characteristic of MAP solution. It does not in= troduce 'per-flow NAT binding' or 'per-subscriber state on dema= nd' on network side. As MAP specification, there is a case when ea-bits= length indicates zero so that MAP needs explain this case and clearly defi= ne specification that's what we did.

Second, I don't have any intention to deprecate those who work hard for= that solutions. =C2=A0I didn't figure out that MAP possibly cover exis= ting solutions untill you rise this point. Now I remember that 'multi-p= rotocol socket v2.0', talked from the chair, which has been deeply engr= aved in my mind. I believe that it is right direction for the working group= .

I agree on that we need discussion. That would be there's another choic= e to define in the case of ea-bits length indicates zero.

Best regards,
--satoru


On 2012/06/25, at 0:13, Qiong wrote:

> Hi Satoru,
>
> Every solution has its solution space with respective application scen= arios as well as pros and cons.
> The essence of stateless solution, which follows the stateless motivat= ion approved by the WG, is to achieve efficient address mapping by algorith= mic embedding part of IPv4 address+port set into IPv6 address/prefix, while= the essence of stateful solution is to maintain the subscriber-based state= on-demand. IPv4 address and IPv6 address is not coupled, and there is no r= equirement on IPv6 addressing format. It is twisty to mix them together in = one document as in the current draft-ietf-softwire-map. It is not clear for= vendors to implement and for operators to deploy, and will lose the featur= es for both.
>
> I'm not saying I'm against the work of stateless solutions, bu= t it is really not fair to just extend one solution arbitrarily to cover an= other one without the permission from the WG and the authors. In particular= , =C2=A0lightweight 4over6 is a collaborative work of 15 co-authors for mor= e than one and a half years, including operators from China Telecom, Tsingh= ua, Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and = =C2=A0also the vendors from Huawei, Juniper and Cisco.
>
> Our WG or DT has never reached the consensus to have one unified docum= ent for both stateful and stateless sotluion. And the motivation draft has = never been extended to include the stateful features as well. So unless we = reach the consensus first in the WG, we can then move forward with this doc= ument.
>
> Best wishes
>
> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima <satoru.matsushima@gmail.com> wrote:<= br> > Hi Qiong,
>
> I'm disagree with your opinion.
>
> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in = the DT.
> 2. MAP just covers so called '1:1 mode' with most granular map= ping rule for CEs provisioning, which is as one of its characteristics.
> 3. The motivation draft does not restrict that as you stated, just = 9;assumed', it's neither 'MUST' nor 'SHOULD'.
>
> Best regards,
> --satoru
>
>
> On 2012/06/24, at 14:35, Qiong wrote:
>
> > Hi all,
> >
> > As we all know, once an individual draft is adopted as a WG draft= , it is owned by the whole WG, rather than just the editors. Just as Remi s= aid, the normal procedure to follow is to reach WG consensus _before_ posti= ng a newly edited version.
> >
> > From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf= -softwire-map-00, there are several changes between them. In particular, th= e newly introduced "1:1 mode", which decouples IPv4 and IPv6 addr= essing, has never been discussed openly in the WG mailing list, or even in = the MAP design team either.
> >
> > Actually, this "1:1 mode" is against the stateless-4v6-= motivation draft. The motivation draft has clearly defines the "Statel= ess 4/6 solution" as follows:
> >
> > Stateless 4/6 solution denotes a solution which does not require = any per-user state (see Section 2.3 of [RFC1958]) to be maintained by any I= P address sharing function in the Service Provider's network. This cate= gory of solutions assumes a dependency between an IPv6 prefix and IPv4 addr= ess.
> >
> > AFAIK what the WG has adopted MAP related draft is draft-mdt-soft= wire-mapping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the s= tateless solution should =E2=80=9Cresponse to the solution motivation docum= ent=E2=80=9D according to the Softwire charter. That means draft-ietf-softw= ire-map-00 IS NOT QUALIFIED to be a WG draft.
> >
> > We can all recall that our softwire WG has worked on stateless so= lutions for more than one and a half years, and we have achieved a lot of w= ork which has been documented in charter, stateless motivation, 4rd-varient= s, MAP-03, etc. AFAIK all the authors have kept the basic "stateless&q= uot; principle and the MAP design team is also working on it together to fi= nd a better algorithm, address format, etc. So it is really not appropriate= to make such changes when MAP is adopted as a WG item in such a short time= .
> >
> > From this perspective, draft-ietf-softwire-map-00 can only be reg= arded as draft-XX-softwire-mapping-address-and-port-04. It is not even the = output of MAP design team.
> >
> > Best wishes
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=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/<= /a>
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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
>
>
>
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >
>




--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

--14dae934115779dc8304c345ccba-- From jacni@jacni.com Sun Jun 24 23:09: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 1057A21F855B for ; Sun, 24 Jun 2012 23:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFobCs2kJ5fD for ; Sun, 24 Jun 2012 23:09:09 -0700 (PDT) Received: from srv05.olivemail.cn (unknown [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 7598921F8559 for ; Sun, 24 Jun 2012 23:09:06 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 9D6C5380062 for ; Mon, 25 Jun 2012 02:09:05 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 38925340082 for ; Mon, 25 Jun 2012 14:09:04 +0800 (CST) Received: from [10.79.96.241] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJD72QZ+AOhPm0NtAQ--.55296S2; Mon, 25 Jun 2012 14:09:04 +0800 (CST) Message-ID: <4FE8007D.7000102@jacni.com> Date: Mon, 25 Jun 2012 14:09:01 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: +AWowJD72QZ+AOhPm0NtAQ--.55296S2 X-Coremail-Antispam: 1UD129KBjvdXoW7JryDCr48GFyxCr4UZFy8Grg_yoWfZrgEkF 4kGwn7G3yUJr4Iqw4ft39avwnxurn8Wa1DZrykXrn0qr1Uuws8JrWkZry2v3WUC34xGrnx Gr4xJr1YkFy3KjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUUxYxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJT77k0a2IF6F4UM7kC6x804xWl14AKx2xKxVCjz48v1sIEY20_Gr1l1xkI jI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6x IIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCYjI0S jxkI62AI1cAE67vIY487MxAIw28IcxkI7VAKI48JMI8E67AF67kF1VAFwI0_Jrv_JF1lIx kGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43ZEXa7IUnHKZtUUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEMEko7lRaVVQA5sV Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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, 25 Jun 2012 06:09:12 -0000 Hi Behcet, all, On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: > Folks, > > We have published revised version of our draft on multicast extensions > to DS-Lite at > > http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt > It's been discussed on the list and in the 81st meeting, and concluded quite clearly by the WG why this is abandoned. It tunnels the IGMP packets upwards, replicates the multicast traffic "per tunnel", opposite to the property of multicast technology. And these are problems we're trying to solve. There is no necessity to initiate that kind of discussion once again. Cheers, Jacni > We think that this draft should be part of draft-ietf-softwire-dslite-multicast. > > Regards, > > Behcet > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From Tetsuya.Murakami@ipinfusion.com Sun Jun 24 23:24:14 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 B63BE21F855E for ; Sun, 24 Jun 2012 23:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWuj5y47NVsY for ; Sun, 24 Jun 2012 23:24:10 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9251021F84A2 for ; Sun, 24 Jun 2012 23:24:10 -0700 (PDT) Received: from mail123-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 06:22:33 +0000 Received: from mail123-tx2 (localhost [127.0.0.1]) by mail123-tx2-R.bigfish.com (Postfix) with ESMTP id F337D803C4; Mon, 25 Jun 2012 06:22:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dIc89bh1432I4015Izz1202hzz1033IL8275dhz2fh2a8h668h839h93fhd25he5bhf0ah) Received-SPF: pass (mail123-tx2: domain of ipinfusion.com designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=BY2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail123-tx2 (localhost.localdomain [127.0.0.1]) by mail123-tx2 (MessageSwitch) id 1340605351712273_23824; Mon, 25 Jun 2012 06:22:31 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.235]) by mail123-tx2.bigfish.com (Postfix) with ESMTP id AA9343A0048; Mon, 25 Jun 2012 06:22:31 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 06:22:31 +0000 Received: from BY2PRD0510MB388.namprd05.prod.outlook.com ([169.254.3.207]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0164.004; Mon, 25 Jun 2012 06:24:07 +0000 From: Tetsuya Murakami To: Satoru Matsushima Thread-Topic: [Softwires] A new consensus opportunity with a MAP-bis Thread-Index: AQHNUpsfyTZgdZD6BEyk85Y5XjJpHQ== Date: Mon, 25 Jun 2012 06:24:06 +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="utf-8" Content-ID: <7521B3E87B381A4CA5411B014D47F6DB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: Ole Troan , Ralph Droms , Yong Cui , Softwires WG Subject: Re: [Softwires] A new consensus opportunity with a MAP-bis 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, 25 Jun 2012 06:24:14 -0000 KzEuDQoNCk1ha2luZyBhbm90aGVyIG5ldyBkb2N1bWVudCBtaWdodCBjYXVzZSBtb3JlIGNvbmZ1 c2lvbi4gQnV0IGlmIDRyZCB3b3JrIGlzIHN0b3BwZWQgYW5kIG1lcmdlZCB0byBNQVAsIGl0IG1p Z2h0IGJlIGdvb2QuIEJ1dCBmcm9tIHRoZSBpbXBsZW1lbnRhdGlvbiBwb2ludCBvZiB2aWV3LCBJ IHdvdWxkIGxpa2UgdG8gZWxpbWluYXRlIHRoZSBjb21wbGljYXRlZCBjb2RlIGFzIG11Y2ggYXMg cG9zc2libGUgc3VjaCBhcw0KDQppZiAoTUFQLUUpDQouLi4NCmVsc2UgaWYgKE1BUC1UKQ0KLi4u DQplbHNlIGlmIChNQVAtSCkNCi4uLg0KDQpCdXQgdGhpcyBpcyB0aGUgaW1wbGVtZW50YXRpb24v ZGVwbG95bWVudCBjaG9pY2UuIFNvLCBmcm9tIHRoZSBzdGFuZGFyZCBwZXJzcGVjdGl2ZSwgaXQg bWlnaHQgYmUgZ29vZCB0byBtZXJnZSBIIHNvbHV0aW9uIHRvIE1BUCB3aGljaCBoYXMgYWxyZWFk eSBtZXJnZWQgYm90aCBFIGFuZCBULg0KDQpUaGFua3MsDQpUZXRzdXlhIE11cmFrYW1pDQoNCk9u IDIwMTIvMDYvMjMsIGF0IDE6NTIsIFNhdG9ydSBNYXRzdXNoaW1hIHdyb3RlOg0KDQo+IERlYXIg UmVtaSwNCj4gDQo+IFRoYW5rIHlvdSBmb3IgYSBraW5kIG9mZmVyLiBJdCB3b3VsZCBiZSBhIHZl cnkgcG9zaXRpdmUgY29tcHJvbWlzZSBmb3IgdXMuDQo+IA0KPiBIb3dldmVyLCBpbiB0aGUgY29u dGV4dCBvZiBtYWtpbmcgYW5vdGhlciBuZXcgc3RyZWFtIGRvY3VtZW50LCB3aGljaCBNQVAtYmlz IGFzIHlvdSBzYWlkLCBJIGRlY2xpbmUgaXQuIE5ldmVydGhlbGVzcywgaWYgeW91IGFiYW5kb24g NHJkIHdvcmssIEknbSB2ZXJ5IHdlbGNvbWUgeW91IGFzIGFuIGF1dGhvciBvZiBNQVAuDQo+IA0K PiBCZXN0IHJlZ2FyZHMsDQo+IC0tc2F0b3J1DQo+IA0KPiBPbiAyMDEyLzA2LzIzLCBhdCAxOjUy LCBSw6ltaSBEZXNwcsOpcyB3cm90ZToNCj4gDQo+PiBZb25nLCBTdXJlc2gsIFJhbHBoLA0KPj4g DQo+PiBGb3IgbWVzaCBzdGF0ZWxlc3MgdjQvdjYsIHdlIGhhdmUgc28gZmFyIGEgY2hvaWNlIGJl dHdlZW4gb25seSB0d28gc29sdXRpb25zLCBNQVAgYXMgaXMgYW5kIDRyZC4NCj4+IE9uIGNhbiBo b3BlIHRoYXQgdGhlIGNvbnNlbnN1cyB0aGF0IGNvdWxkbid0IGJlIHJlYWNoZWQgaW4gUGFyaXMg d2lsbCBiZSBhY2hpZXZhYmxlIGluIFZhbmNvdXZlciwgYnV0IHRoaXMgaXNuJ3Qgc3VyZSwgZWFj aCAiY2FtcCIga2VlcGluZyBpdHMgb3duIGV4cGVjdGF0aW9uLg0KPj4gDQo+PiBMb29raW5nIGF0 IHJlY2VudCBoaXN0b3J5LCB3ZSBjYW4gcmVtZW1iZXIgdGhhdCwgbm90IGxvbmcgYWdvLCB0aGUg Y2hhaXIncyBhcHByb2FjaCB3YXMgdG8gaGF2ZSAzIHNwZWNpZmljYXRpb25zIGNvbXBsZXRlZCAo TUFQLVQsIE1BUC1FLCBhbmQgTUFQLUgsIGFzIEFsYWluIGNhbGxlZCBpdCB3aXRoIEggZm9yIEh5 YnJpZCksIGFuZCB0aGVuIHRvIGNob29zZSBvbmx5IG9uZSBmb3Igc3RhbmRhcmRpemF0aW9uLg0K Pj4gDQo+PiBBZnRlciB0aGF0LCBwcm9tb3RlcnMgb2YgZWl0aGVyIC1UIGFuZCAtRSBkZWNpZGVk IHRvIG1lcmdlIC1UIGFuZCAtRSBpbiBhIG5vbi1zZXBhcmFibGUgc3BlY2lmaWNhdGlvbiwgYXMg cmVmbGVjdGVkIGluIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwLiANCj4+IFRodXMsIHRoZSBj aG9pY2UgaGFzIGJlY29tZSBiZXR3ZWVuIGEgInR3by12YXJpYW50cyIgc3BlY2lmaWNhdGlvbiAo TUFQKSBhbmQgYSAic2luZ2xlLXZhcmlhbnQiIHNwZWNpZmljYXRpb24gKDRyZCkuDQo+PiANCj4+ IEluIHRoaXMgY29udGV4dCwgYSBsYXJnZXIgY2hvaWNlIG1pZ2h0IHdlbGwgYmUgdGhlIGJlc3Qg Y2hhbmNlIGZvciBhIFdHIGNvbnNlbnN1cy4gSXQgd291bGQgaW5jbHVkZSBhIE1BUCBzcGVjaWZp Y2F0aW9uIGluIHdoaWNoIHRoZSBmb3J3YXJkaW5nIG1vZGUgb2YgNHJkIHdvdWxkIGJlIGFkZGVk IGFzIDNyZCwgc2F5IGEgIk1BUC1iaXMiIC4gDQo+PiBXaXRoIHRoaXMgTUFQLWJpczoNCj4+IC0g dmVuZG9ycyBoYXZlIHRvIHN1cHBvcnQgMyBmb3J3YXJkaW5nIG1vZGVzLCB3aGljaCBpc24ndCBp ZGVhbCwgYnV0IG1vc3Qgb2YgdGhlIGRlc2lnbiwgaW4gcGFydGljdWxhciBpbiB3aGF0IGNvbmNl cm5zIG1hcHBpbmcgcnVsZXMsIHJlbWFpbnMgY29tbW9uIChBbGFpbiBvbmNlIHNhaWQsIHBvc3Np Ymx5IHdpdGggb3B0aW1pc20sIHRoZSB0aHJlZSB3ZXJlIDk5JSBpZGVudGljYWwhKSANCj4+IC0g b3BlcmF0b3JzIGhhdmUgYSBmcmVlIGNob2ljZSBiZXR3ZWVuIFQsIEUsIG9yIEgsIGJhc2VkIG9u IHRoZWlyIG9wZXJhdGlvbmFsIHByZWZlcmVuY2VzLg0KPj4gLSB3ZSBoYXZlIChhdCBsYXN0KSBh IHN0YWJpbGl6ZWQgZGVzaWduIHdpdGggbm8gb25lIGJhZGx5IGZydXN0cmF0ZWQuDQo+PiANCj4+ IElmIHRoaXMgYXBwcm9hY2ggbWFrZXMgc2Vuc2UgZm9yIHRoZSBXRywgSSBjYW4gZG8gdGhlIHdv cmsgb2YgZWRpdGluZyBhIE1BUC1iaXMgcHJvcG9zYWwgKHRha2luZyB0aGUgY3VycmVudCBNQVAg c3BlY2lmaWNhdGlvbiwgYWRkaW5nIGEgc2VjdGlvbiB0aGF0IGRlc2NyaWJlcyB0aGUgaHlicmlk IGZvcndhcmRpbmcgbW9kZSwgYW5kIGFkZGluZyBhIHRoaXJkIHZhcmlhbnQgaW4gdGhlIGFkZHJl c3MtZm9ybWF0IHNlY3Rpb24pLiANCj4+IA0KPj4gTXkgcGVyc29uYWwgcHJlZmVyZW5jZSByZW1h aW5zIGZvciA0cmQgYXMgc2luZ2xlIHN0YW5kYXJkLCBidXQgYSBjaG9pY2UgYmV0d2VlbiBNQVAt YXMtaXMsIE1BUC1iaXMsIGFuZCA0cmQsIGlzIElNSE8gYSBzb3VuZGVyIGNob2ljZSBmb3IgdGhl IFdHIHRoYW4ganVzdCBiZXR3ZWVuIE1BUC1hcy1pcyBhbmQgNHJkLg0KPj4gDQo+PiBIb3Bpbmcg dGhhdCB0aGlzIHdpbGwgYmUgZm91bmQgY29uc3RydWN0aXZlLA0KPj4gQmVzdCByZWdhcmRzLA0K Pj4gUkQNCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFNvZnR3aXJlcyBtYWlsaW5n IGxpc3QNCj4+IFNvZnR3aXJlc0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4gU29mdHdp cmVzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29m dHdpcmVzDQoNCg== From sunqi.csnet.thu@gmail.com Sun Jun 24 23:52:01 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 9EF6D21F84AF for ; Sun, 24 Jun 2012 23:52:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqDhc5OBKLlc for ; Sun, 24 Jun 2012 23:51:57 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7911421F849B for ; Sun, 24 Jun 2012 23:51:57 -0700 (PDT) Received: by dacx6 with SMTP id x6so4910892dac.31 for ; Sun, 24 Jun 2012 23:51:57 -0700 (PDT) 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-mailer:mime-version:message-id:content-type; bh=+UptQ8a+BzOUMtg4/Fsb5HQSBloB3UfowN1ti1acMtI=; b=cKQa/RXG0Z6ghmd8UoS8udId+rQGAa8zMNp/o8+CCY8ZYCEIRe0reiEmW8jP0IkMza vJJIhhdDbLVKl83CiCL9XsAJdkrKs7/nlFY2+s3ggaXSpUVk+ov98zcMtV1qhvPyFFlk uEC22QxiirCHUwkFH7LaF7L0a4eIizMCQEyXkD1exbZovvdlcAAc/I1ruL3XWQyyROUL sOBGBhueO0KiYudtb10KA2uuOvkjqxUongSg/f/oanDlSXu3731dbMlPRE+1gQcX7RC/ j1cUWkwazaWPfMQ3p+J7RSbuGoeqC/ENP9Lpobfu04MgCcYN6fGaaCEg97j91/lLHb5X KlcA== Received: by 10.68.241.228 with SMTP id wl4mr36810240pbc.51.1340607117008; Sun, 24 Jun 2012 23:51:57 -0700 (PDT) Received: from sunqi ([219.243.220.10]) by mx.google.com with ESMTPS id nh8sm7612239pbc.60.2012.06.24.23.51.50 (version=SSLv3 cipher=OTHER); Sun, 24 Jun 2012 23:51:56 -0700 (PDT) Date: Mon, 25 Jun 2012 14:51:46 +0800 From: "Qi Sun" To: "Satoru Matsushima" References: , <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> X-Priority: 3 X-GUID: A6112275-041B-4023-AD9E-CDF434EE08FB X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012062514514640804415@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart852313112404_=----" Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 06:52:01 -0000 This is a multi-part message in MIME format. ------=_001_NextPart852313112404_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2F0b3J1LA0KDQpJbiBNQVAgMToxIG1vZGUsIGlmIHRoZXJlIGFyZSAxMDAwMDAwMCBzdWJz Y3JpYmVycywgdGhlcmUgd291bGQgYmUgMTAwMDAwMDAgTUFQIGRvbWFpbnMgd2hpY2ggYSBCUiBo YXMgdG8gbWFuYWdlLiBJIHRoaW5rIHRoYXQgd2lsbCBjcmVhdGUgYSBodWdlIG1hcHBpbmcgdGFi bGUgb24gdGhlIEJSLCB3aGljaCBpcyBjYWxsZWQgJ3N0YXRlJyB0aGF0IHN0YXRlZnVsIHNvbHV0 aW9ucyBkZWFsIHdpdGguDQoNCkJlc3QgUmVnYXJkcyENCg0KDQoNCg0KUWkgU3VuDQoNCkZyb206 IFNhdG9ydSBNYXRzdXNoaW1hDQpEYXRlOiAyMDEyLTA2LTI1IDEwOjI3DQpUbzogTGVlLCBZaXUN CkNDOiBzb2Z0d2lyZXNAaWV0Zi5vcmc7IFlvbmcgQ3VpDQpTdWJqZWN0OiBSZTogW1NvZnR3aXJl c10gW1NvZnR3aXJlXSBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBkb2VzIE5PVCByZWZsZWN0 IHRoZSBjb25zZW5zdXMgZnJvbSB0aGUgV0cNCkhpIFlpdSwNCg0KTm8sIHRoYXQncyBhIG1pc3Vu ZGVyc3RhbmRpbmcuDQpDdXJyZW50IE1BUCBzcGVjaWZ5IHRoZSBjYXNlIGZvciBlYS1sZW4gaXMg J3plcm8nLiBJdCBpcyAncGVyLXN1YnNjcmliZXIgbWFwcGluZycgaW4gc3RhdGVsZXNzIG1hbm5l ciwgbm90IHRvIGludHJvZHVjZSAncGVyLWZsb3cgTkFUIGJpbmRpbmcnIG9yICdwZXItc3Vic2Ny aWJlciBzdGF0ZSBvbiBkZW1hbmQnLg0KDQpjaGVlcnMsDQotLXNhdG9ydQ0KDQpPbiAyMDEyLzA2 LzI1LCBhdCAyOjMyLCBMZWUsIFlpdSB3cm90ZToNCg0KPiBEZWFyIFNhdG9ydSBhbmQgTUFQLURU DQo+IA0KPiBJIGVjaG8gd2hhdCBQZW5nIGFuZCBRaW9uZyBzYWlkLiBXaGVuIHRoZSBXRyBhZ3Jl ZWQgd29ya2luZyBvbiB0aGUNCj4gc3RhdGVsZXNzIHNvbHV0aW9uLCBpdCB3YXMgdmVyeSBjbGVh ciBzdGF0ZWQgdGhhdCB0aGUgc29sdXRpb24gd291bGQgbm90DQo+IG1haW50YWluIHN0YXRlcyBp biB0aGUgbmV0d29yay4gSWYgdGhlIDE6MSBtb2RlIGNoYW5nZWQgdGhpcywgdGhpcyBubw0KPiBs b25nZXIgbWF0Y2hlZCB0aGUgcmVxdWlyZW1lbnRzIHN0YXRlZCBpbiB0aGUgc3RhdGVsZXNzIG1v dGl2YXRpb24gZHJhZnQsDQo+IHRodXMsIGl0IHdvdWxkIGRpc3F1YWxpZnkgTUFQIGFzIGEgc29s dXRpb24gZm9yIHRoZSBtb3RpdmF0aW9uIGRyYWZ0Lg0KPiANCj4gQUZBSUssIHRoZSBNQVAgRGVz aWduIFRlYW0gY291bGQgcHJvcG9zZSBhIGNoYW5nZSwgYnV0IHN1Y2ggYSBkcmFtYXRpYw0KPiBj aGFuZ2UgYnkgaW50cm9kdWNpbmcgc3RhdGVzIGluIHRoZSBuZXR3b3JrIHdvdWxkIHJlcXVpcmUg V0cgYXBwcm92YWwuIEkNCj4gd291bGQgbGlrZSB0aGUgY2hhaXJzIHRvIGNsYXJpZnkgdGhpcy4N Cj4gDQo+IFRoYW5rcywNCj4gWWl1DQo+IA0KPiANCj4gT24gNi8yNC8xMiAxMjoyMSBQTSwgIlBl bmcgV3UiIDxwZW5nd3UudGh1QGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPj4gSGkgUWlvbmcsIFNh dG9ydSBhbmQgYWxsLA0KPj4gDQo+PiBJIHNob3VsZCB0aGFuayBRaW9uZyBmb3IgcG9pbnRpbmcg dGhpcyBvdXQuIEkgZ290dGEgc2F5IEknbSBhIGJpdCBzaG9ja2VkLg0KPj4gSWYgSSB1bmRlcnN0 YW5kIHRoZSBwcm9jZWR1cmVzIG9mIElFVEYgY29ycmVjdGx5LCBhIFdHIGRvY3VtZW50IHNob3Vs ZA0KPj4gcmVmbGVjdCB0aGUgY29uc2Vuc3VzIG9mIHRoZSBXRy4gTUFQIGlzIGFwcHJvdmVkIGJ5 IHRoZSBXRyBhcyBhDQo+PiBzdGF0ZWxlc3Mgc29sdXRpb24uIEFzIGEgcGFydGljaXBhdG9yIGlu IFNvZnR3aXJlLCBJIGRpZG4ndCBnZXQgdGhlDQo+PiBpbmZvcm1hdGlvbiBhbnl3aGVyZSB0aGF0 IHRoZSBNQVAgV0cgZG9jdW1lbnQgd291bGQgY292ZXIgdGhlDQo+PiBzby1jYWxsZWQgMToxLCBp biBmYWN0IHBlci11c2VyIHN0YXRlZnVsIG1vZGUgYmVmb3JlIGl0IHdhcyByZWxlYXNlZCwNCj4+ IG5vdCB0byBzYXkgZGlzY3VzcyBpbiB0aGUgV0cuIERvbid0IHRoZSBXRyBuZWVkIHRvIGFwcHJv dmUgc3VjaCBiaWcNCj4+IGNoYW5nZSBhbnltb3JlPw0KPj4gDQo+PiBOb3cgbGV0IG1lIHByb3Zp ZGUgbXkgaW1wcmVzc2lvbiBhcyBhbiBvdXRzaWRlciBvZiB0aGUgTUFQIERULiBZb3UNCj4+IGd1 eXMgbWFrZSBncmVhdCBlZmZvcnQgdG8gYnVpbGQgdGhlIHNvbHV0aW9uLCBUaGUgYWRkcmVzcyBj b21wb3NpdGlvbiwNCj4+IHRoZSBHTUEgYWxnb3JpdGhtLCB0aGUgZGlmZmVyZW50IHR5cGVzIG9m IGFkZHJlc3MgbWFwcGluZyBydWxlcy4NCj4+IHNob3VsZCBiZSBxdWl0ZSBkaWZmaWN1bHQgdG8g cHVsbCB0b2dldGhlciBzdWNoIHNvcGhpc3RpY2F0ZWQgaWRlYXMuIEkNCj4+IGd1ZXNzIHRoYXQn cyB3aGF0IGl0IHRha2VzIHRvIGFjaGlldmUgdGhlIGJlbmlmaXRzIG9mIHN0YXRlbGVzc25lc3Mu DQo+PiBBbmQgSSBhZG1pcmUgdGhhdCwgYnJhdm8uIFRoZW4sIGFsbCBvZiBhIHN1ZGRlbiwgeW91 IGd1eXMgYXJlIHNheWluZywNCj4+IGxldCdzIGFwcGx5IHRoaXMgc29waGlzdGljYXRlZCBtZXRo b2QgdG8gdGhlIGRpZmZlcmVudCBwcm9ibGVtLCBieQ0KPj4gZHJvcHBpbmcgcXVpdGUgc29tZSBj b21sZXhpdHkgYW5kIHR3aXN0dGluZyB0aGUgbWVjaGFuaXNtIGEgYml0LCBzZWVtcw0KPj4gaXQg bWF5IHdvcmsuIENvbnNpZGVyaW5nIHRoZSBwcm9ibGVtIGFyZSBub3cgc29sdmVkIGluIGEgbW9y ZSBwdXJlIGFuZA0KPj4gY2xlYXIgd2F5LCBJJ20gc29ycnkgYnV0IEkgQ0FOTk9UIGZvbGxvdyB0 aGUgbG9naWMgaGVyZS4NCj4+IA0KPj4gT24gU3VuLCBKdW4gMjQsIDIwMTIgYXQgMjowMCBQTSwg U2F0b3J1IE1hdHN1c2hpbWENCj4+IDxzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20+IHdyb3Rl Og0KPj4+IEhpIFFpb25nLA0KPj4+IA0KPj4+IEknbSBkaXNhZ3JlZSB3aXRoIHlvdXIgb3Bpbmlv bi4NCj4+PiANCj4+PiAxLiBSZWNlbnQgY2hhbmdlcyBpbiBkcmFmdC1pZXRmLXNvZnR3aXJlLW1h cC0wMCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4NCj4+PiB0aGUgRFQuDQo+Pj4gMi4gTUFQIGp1c3Qg Y292ZXJzIHNvIGNhbGxlZCAnMToxIG1vZGUnIHdpdGggbW9zdCBncmFudWxhciBtYXBwaW5nIHJ1 bGUNCj4+PiBmb3IgQ0VzIHByb3Zpc2lvbmluZywgd2hpY2ggaXMgYXMgb25lIG9mIGl0cyBjaGFy YWN0ZXJpc3RpY3MuDQo+Pj4gMy4gVGhlIG1vdGl2YXRpb24gZHJhZnQgZG9lcyBub3QgcmVzdHJp Y3QgdGhhdCBhcyB5b3Ugc3RhdGVkLCBqdXN0DQo+Pj4gJ2Fzc3VtZWQnLCBpdCdzIG5laXRoZXIg J01VU1QnIG5vciAnU0hPVUxEJy4NCj4+PiANCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4gLS1zYXRv cnUNCj4+PiANCj4+PiANCj4+PiBPbiAyMDEyLzA2LzI0LCBhdCAxNDozNSwgUWlvbmcgd3JvdGU6 DQo+Pj4gDQo+Pj4+IEhpIGFsbCwNCj4+Pj4gDQo+Pj4+IEFzIHdlIGFsbCBrbm93LCBvbmNlIGFu IGluZGl2aWR1YWwgZHJhZnQgaXMgYWRvcHRlZCBhcyBhIFdHIGRyYWZ0LCBpdA0KPj4+PiBpcyBv d25lZCBieSB0aGUgd2hvbGUgV0csIHJhdGhlciB0aGFuIGp1c3QgdGhlIGVkaXRvcnMuIEp1c3Qg YXMgUmVtaQ0KPj4+PiBzYWlkLCB0aGUgbm9ybWFsIHByb2NlZHVyZSB0byBmb2xsb3cgaXMgdG8g cmVhY2ggV0cgY29uc2Vuc3VzIF9iZWZvcmVfDQo+Pj4+IHBvc3RpbmcgYSBuZXdseSBlZGl0ZWQg dmVyc2lvbi4NCj4+Pj4gDQo+Pj4+IEZyb20gZHJhZnQtbWR0LXNvZnR3aXJlLW1hcHBpbmctYWRk cmVzcy1hbmQtcG9ydC0wMyB0bw0KPj4+PiBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCwgdGhl cmUgYXJlIHNldmVyYWwgY2hhbmdlcyBiZXR3ZWVuIHRoZW0uIEluDQo+Pj4+IHBhcnRpY3VsYXIs IHRoZSBuZXdseSBpbnRyb2R1Y2VkICIxOjEgbW9kZSIsIHdoaWNoIGRlY291cGxlcyBJUHY0IGFu ZA0KPj4+PiBJUHY2IGFkZHJlc3NpbmcsIGhhcyBuZXZlciBiZWVuIGRpc2N1c3NlZCBvcGVubHkg aW4gdGhlIFdHIG1haWxpbmcNCj4+Pj4gbGlzdCwgb3IgZXZlbiBpbiB0aGUgTUFQIGRlc2lnbiB0 ZWFtIGVpdGhlci4NCj4+Pj4gDQo+Pj4+IEFjdHVhbGx5LCB0aGlzICIxOjEgbW9kZSIgaXMgYWdh aW5zdCB0aGUgc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uDQo+Pj4+IGRyYWZ0LiBUaGUgbW90aXZh dGlvbiBkcmFmdCBoYXMgY2xlYXJseSBkZWZpbmVzIHRoZSAiU3RhdGVsZXNzIDQvNg0KPj4+PiBz b2x1dGlvbiIgYXMgZm9sbG93czoNCj4+Pj4gDQo+Pj4+IFN0YXRlbGVzcyA0LzYgc29sdXRpb24g ZGVub3RlcyBhIHNvbHV0aW9uIHdoaWNoIGRvZXMgbm90IHJlcXVpcmUgYW55DQo+Pj4+IHBlci11 c2VyIHN0YXRlIChzZWUgU2VjdGlvbiAyLjMgb2YgW1JGQzE5NThdKSB0byBiZSBtYWludGFpbmVk IGJ5IGFueQ0KPj4+PiBJUCBhZGRyZXNzIHNoYXJpbmcgZnVuY3Rpb24gaW4gdGhlIFNlcnZpY2Ug UHJvdmlkZXIncyBuZXR3b3JrLiBUaGlzDQo+Pj4+IGNhdGVnb3J5IG9mIHNvbHV0aW9ucyBhc3N1 bWVzIGEgZGVwZW5kZW5jeSBiZXR3ZWVuIGFuIElQdjYgcHJlZml4IGFuZA0KPj4+PiBJUHY0IGFk ZHJlc3MuDQo+Pj4+IA0KPj4+PiBBRkFJSyB3aGF0IHRoZSBXRyBoYXMgYWRvcHRlZCBNQVAgcmVs YXRlZCBkcmFmdCBpcw0KPj4+PiBkcmFmdC1tZHQtc29mdHdpcmUtbWFwcGluZy1hZGRyZXNzLWFu ZC1wb3J0LTAzLCBOT1QNCj4+Pj4gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAuIEFuZCB0aGUg c3RhdGVsZXNzIHNvbHV0aW9uIHNob3VsZCDCs3Jlc3BvbnNlDQo+Pj4+IHRvIHRoZSBzb2x1dGlv biBtb3RpdmF0aW9uIGRvY3VtZW50wrIgYWNjb3JkaW5nIHRvIHRoZSBTb2Z0d2lyZSBjaGFydGVy Lg0KPj4+PiBUaGF0IG1lYW5zIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwIElTIE5PVCBRVUFM SUZJRUQgdG8gYmUgYSBXRyBkcmFmdC4NCj4+Pj4gDQo+Pj4+IFdlIGNhbiBhbGwgcmVjYWxsIHRo YXQgb3VyIHNvZnR3aXJlIFdHIGhhcyB3b3JrZWQgb24gc3RhdGVsZXNzDQo+Pj4+IHNvbHV0aW9u cyBmb3IgbW9yZSB0aGFuIG9uZSBhbmQgYSBoYWxmIHllYXJzLCBhbmQgd2UgaGF2ZSBhY2hpZXZl ZCBhDQo+Pj4+IGxvdCBvZiB3b3JrIHdoaWNoIGhhcyBiZWVuIGRvY3VtZW50ZWQgaW4gY2hhcnRl ciwgc3RhdGVsZXNzIG1vdGl2YXRpb24sDQo+Pj4+IDRyZC12YXJpZW50cywgTUFQLTAzLCBldGMu IEFGQUlLIGFsbCB0aGUgYXV0aG9ycyBoYXZlIGtlcHQgdGhlIGJhc2ljDQo+Pj4+ICJzdGF0ZWxl c3MiIHByaW5jaXBsZSBhbmQgdGhlIE1BUCBkZXNpZ24gdGVhbSBpcyBhbHNvIHdvcmtpbmcgb24g aXQNCj4+Pj4gdG9nZXRoZXIgdG8gZmluZCBhIGJldHRlciBhbGdvcml0aG0sIGFkZHJlc3MgZm9y bWF0LCBldGMuIFNvIGl0IGlzDQo+Pj4+IHJlYWxseSBub3QgYXBwcm9wcmlhdGUgdG8gbWFrZSBz dWNoIGNoYW5nZXMgd2hlbiBNQVAgaXMgYWRvcHRlZCBhcyBhIFdHDQo+Pj4+IGl0ZW0gaW4gc3Vj aCBhIHNob3J0IHRpbWUuDQo+Pj4+IA0KPj4+PiBGcm9tIHRoaXMgcGVyc3BlY3RpdmUsIGRyYWZ0 LWlldGYtc29mdHdpcmUtbWFwLTAwIGNhbiBvbmx5IGJlIHJlZ2FyZGVkDQo+Pj4+IGFzIGRyYWZ0 LVhYLXNvZnR3aXJlLW1hcHBpbmctYWRkcmVzcy1hbmQtcG9ydC0wNC4gSXQgaXMgbm90IGV2ZW4g dGhlDQo+Pj4+IG91dHB1dCBvZiBNQVAgZGVzaWduIHRlYW0uDQo+Pj4+IA0KPj4+PiBCZXN0IHdp c2hlcw0KPj4+PiANCj4+Pj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPj4+PiBRaW9uZyBTdW4NCj4+Pj4gQ2hpbmEgVGVsZWNvbSBCZWlqaW5nIFJlc2Vh cmNoIEluc3RpdHVkZQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9wZW4gc291cmNlIGNvZGU6DQo+Pj4+ IGxpZ2h0d2VpZ2h0IDRvdmVyNjogaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0 Ni8NCj4+Pj4gUENQLW5hdGNvb3JkOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL3Bj cHBvcnRzZXRkZW1vLw0KPj4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4+Pj4g U29mdHdpcmVzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc29mdHdpcmVzDQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+Pj4gU29mdHdp cmVzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z b2Z0d2lyZXMNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFp bGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc29mdHdpcmVz ------=_001_NextPart852313112404_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Satoru,
 
In MAP 1:1 mode, if there are 10000000 subscribers, there would be 10= 000000=20 MAP domains which a BR has to manage. I think that will create a huge mapp= ing=20 table on the BR, which is called 'state' that stateful solutions deal=20 with.
 
Best Regards!
 
Qi Sun
 
Date: 2012-06-25 10:27
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
Hi Yiu,
 
No, that's a misunderstanding.
Current MAP specify the case for ea-len=  is 'zero'. It is 'per-subscriber mapping'&n= bsp;in stateless manner, not to introduce 'p= er-flow NAT binding' or 'per-subscriber state&nbs= p;on demand'.
 
cheers,
--satoru
 
On 2012/06/25, at 2:32, Lee, Yiu wrote:=
 
> Dear Satoru and MAP-DT
> 
> I echo what Peng and Qiong sa= id. When the WG agreed working on the
> stateless solution, it was very cl= ear stated that the solution would not
> maintain states in the network. If=  the 1:1 mode changed this, this no
> longer matched the requirements stated&= nbsp;in the stateless motivation draft,
> thus, it would disqualify MAP as&n= bsp;a solution for the motivation draft.
> 
> AFAIK, the MAP Design Team could&n= bsp;propose a change, but such a dramatic
> change by introducing states in th= e network would require WG approval. I
> would like the chairs to clarify&n= bsp;this.
> 
> Thanks,
> Yiu
> 
> 
> On 6/24/12 12:21 PM, "Peng Wu"&nbs= p;<pengwu.thu@gmail.com> wrote:
> 
>> Hi Qiong, Satoru and all,
>> 
>> I should thank Qiong for point= ing this out. I gotta say I'm a bi= t shocked.
>> If I understand the procedures = ;of IETF correctly, a WG document should
>> reflect the consensus of the W= G. MAP is approved by the WG as a<= /DIV>
>> stateless solution. As a participat= or in Softwire, I didn't get the
>> information anywhere that the MAP&n= bsp;WG document would cover the
>> so-called 1:1, in fact per-user&nbs= p;stateful mode before it was released,
>> not to say discuss in the = ;WG. Don't the WG need to approve such&= nbsp;big
>> change anymore?
>> 
>> Now let me provide my impressi= on as an outsider of the MAP DT. Y= ou
>> guys make great effort to buil= d the solution, The address composition,
>> the GMA algorithm, the different&nb= sp;types of address mapping rules.
>> should be quite difficult to p= ull together such sophisticated ideas. I
>> guess that's what it takes to&= nbsp;achieve the benifits of statelessness.
>> And I admire that, bravo. Then= , all of a sudden, you guys are sa= ying,
>> let's apply this sophisticated meth= od to the different problem, by
>> dropping quite some comlexity and&n= bsp;twistting the mechanism a bit, seems
>> it may work. Considering the p= roblem are now solved in a more pure&nb= sp;and
>> clear way, I'm sorry but I&nbs= p;CANNOT follow the logic here.
>> 
>> On Sun, Jun 24, 2012 at 2= :00 PM, Satoru Matsushima
>> <satoru.matsushima@gmail.com> wrote:
>>> Hi Qiong,
>>> 
>>> I'm disagree with your opinion.=
>>> 
>>> 1. Recent changes in draft-ietf= -softwire-map-00 has been discussed in
>>> the DT.
>>> 2. MAP just covers so call= ed '1:1 mode' with most granular mapping&nbs= p;rule
>>> for CEs provisioning, which is&= nbsp;as one of its characteristics.
>>> 3. The motivation draft does&nb= sp;not restrict that as you stated, just
>>> 'assumed', it's neither 'MUST' = nor 'SHOULD'.
>>> 
>>> Best regards,
>>> --satoru
>>> 
>>> 
>>> On 2012/06/24, at 14:35, Qiong&= nbsp;wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> As we all know, once a= n individual draft is adopted as a WG&n= bsp;draft, it
>>>> is owned by the whole = WG, rather than just the editors. Just = as Remi
>>>> said, the normal procedure = to follow is to reach WG consensus _bef= ore_
>>>> posting a newly edited vers= ion.
>>>> 
>>>> From draft-mdt-softwire-mapping-address-an= d-port-03 to
>>>> draft-ietf-softwire-map-00, there are=  several changes between them. In
>>>> particular, the newly introduced=  "1:1 mode", which decouples IPv4 and
>>>> IPv6 addressing, has never = been discussed openly in the WG mailing
>>>> list, or even in the M= AP design team either.
>>>> 
>>>> Actually, this "1:1 mode" i= s against the stateless-4v6-motivation
>>>> draft. The motivation draft = ;has clearly defines the "Stateless 4/6
>>>> solution" as follows:
>>>> 
>>>> Stateless 4/6 solution denotes&n= bsp;a solution which does not require any
>>>> per-user state (see Section = ;2.3 of [RFC1958]) to be maintained by = any
>>>> IP address sharing function = ;in the Service Provider's network. This
>>>> category of solutions assumes&nb= sp;a dependency between an IPv6 prefix and
>>>> IPv4 address.
>>>> 
>>>> AFAIK what the WG has = adopted MAP related draft is
>>>> draft-mdt-softwire-mapping-address-and-port-03,=  NOT
>>>> draft-ietf-softwire-map-00. And the&n= bsp;stateless solution should =C2=B3response
>>>> to the solution motivation = document=C2=B2 according to the Softwire charter.=
>>>> That means draft-ietf-softwire-map-00=  IS NOT QUALIFIED to be a WG draft= .
>>>> 
>>>> We can all recall that = ;our softwire WG has worked on stateless
>>>> solutions for more than one=  and a half years, and we have ach= ieved a
>>>> lot of work which has = been documented in charter, stateless motivation,=
>>>> 4rd-varients, MAP-03, etc. AFAIK=  all the authors have kept the basic
>>>> "stateless" principle and the&nb= sp;MAP design team is also working on i= t
>>>> together to find a better&n= bsp;algorithm, address format, etc. So it is=
>>>> really not appropriate to m= ake such changes when MAP is adopted as=  a WG
>>>> item in such a short t= ime.
>>>> 
>>>> From this perspective, draft-iet= f-softwire-map-00 can only be regarded
>>>> as draft-XX-softwire-mapping-address-and-p= ort-04. It is not even the
>>>> output of MAP design team.<= /DIV>
>>>> 
>>>> Best wishes
>>>> 
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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&n= bsp;Institude
>>>> 
>>>> 
>>>> Open source code:
>>>> lightweight 4over6: http://sourceforg= e.net/projects/laft6/
>>>> PCP-natcoord: http://sourceforge.net/proje= cts/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
>> _______________________________________________
>> 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
------=_001_NextPart852313112404_=------ From satoru.matsushima@gmail.com Sun Jun 24 23:59: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 058B021F851E for ; Sun, 24 Jun 2012 23:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9LtxYJW9rp7 for ; Sun, 24 Jun 2012 23:59:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B63421F850D for ; Sun, 24 Jun 2012 23:59:30 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6188577pbc.31 for ; Sun, 24 Jun 2012 23:59:29 -0700 (PDT) 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=ppJkORrAUvCknyz6V4gXKkJPV3xfNFy/p9KVpBFUjH4=; b=HY0KU+OBSw+1pZHjs8EtkVM0eHoaPYJg8SWZoyig2uF3eSa357zhUx3H1cXBFBtefj 4vXauXGdKOYHWydCld0YQBsQiBZRm66l2xSnkiF5xcavsiG0cRGfuEIdEMqKfqhj3sqc HflneMQFqH652d7+x5McRcCcFeF6e9z0PalK8qFHTnT/qZzVuYAOmAhnXFtgiW3HsHDm JRsyaA0pMrf2UhAxKQhGvvgLTfoJqcyYDdO/AbxtO1jmvhmocUN3EKpJ9kH2XtRkAdoS K2wdfx7rlwVH5px9vYvL+EWLSVZ+9Vof76eK8eFANGcZMu23FJSVTjJHA+E8QneN4aJ4 estg== Received: by 10.68.222.163 with SMTP id qn3mr36963043pbc.135.1340607569841; Sun, 24 Jun 2012 23:59:29 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id sk5sm7650360pbc.7.2012.06.24.23.59.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jun 2012 23:59:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 15:59:08 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <07698BA1-CBEE-45E3-9CE2-B0ED530EFE93@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> To: Qiong X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 06:59:34 -0000 Hi Qiong, On 2012/06/25, at 15:06, Qiong wrote: > Hi Satoru, >=20 > Would you please point out in which presentation in the Beijing = Interim meeting illustrated "per-subscriber mapping" as one = characteristic of MAP solution? I recall which xiaohong presented was a = stateful one. Please find it out on page 14 from following url: http://www.ietf.org/proceedings/82/slides/softwire-2.pdf cheers, --satoru From satoru.matsushima@gmail.com Mon Jun 25 00:02: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 06D4421F8550 for ; Mon, 25 Jun 2012 00:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ewH9EsByPkq for ; Mon, 25 Jun 2012 00:02:10 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92D0921F851E for ; Mon, 25 Jun 2012 00:02:10 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6191817pbc.31 for ; Mon, 25 Jun 2012 00:02:10 -0700 (PDT) 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=e2delE6Bv+oKv7PZ2hO/vbzGK/BVSg3y/jnmeujOp0A=; b=qW0nptG6+JPSUf33cEHAT5xS4iQB+Uq3Bpw0CyhTRktI0CNm4Lq2CliO8KTsWIbUFb GTyxS+etBage0mk4XfB0ZSOY7X/BDztyv4aNulTOvmyWdh+71HBDwJPnpNPDMGcv864A wrDr51dlKjNVq/opfB0vtM2+FDil0Jx7Cy6PA/zmabBoUWsz/j4r9Y36vSwW4xBt5ChT c7967GhTnMjVEntTy8MdV0QIH+nNhEflZQ2MXBJSfY7OiLrTNOt8jj9wtNVPYy5+zjnv 6YBAo5ziThlrk+vDSUAp/XGbK7IRtMZFXfoCNR/O92QfJV2d7zXrUiIWU8Evncn5ryIQ mrsw== Received: by 10.68.136.68 with SMTP id py4mr36743104pbb.151.1340607730320; Mon, 25 Jun 2012 00:02:10 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id of1sm7654694pbb.15.2012.06.25.00.02.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 00:02:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima X-Priority: 3 In-Reply-To: <2012062514514640804415@gmail.com> Date: Mon, 25 Jun 2012 16:01:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6D03A23F-DB70-43FC-A043-88DE7521D534@gmail.com> References: , <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> To: sunqi.csnet.thu X-Mailer: Apple Mail (2.1278) Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 07:02:21 -0000 Hi Qiong, A MAP domain can have several/some/many mapping rules in the domain. How = many is threshold for either stateless or stateful? cheers, --satoru On 2012/06/25, at 15:51, Qi Sun wrote: > Hi Satoru, > =20 > In MAP 1:1 mode, if there are 10000000 subscribers, there would be = 10000000 MAP domains which a BR has to manage. I think that will create = a huge mapping table on the BR, which is called 'state' that stateful = solutions deal with. > =20 > Best Regards! > =20 > Qi Sun > =20 > From: Satoru Matsushima > Date: 2012-06-25 10:27 > To: Lee, Yiu > CC: softwires@ietf.org; Yong Cui > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does = NOT reflect the consensus from the WG > Hi Yiu, > =20 > No, that's a misunderstanding. > Current MAP specify the case for ea-len is 'zero'. It is = 'per-subscriber mapping' in stateless manner, not to introduce 'per-flow = NAT binding' or 'per-subscriber state on demand'. > =20 > cheers, > --satoru > =20 > On 2012/06/25, at 2:32, Lee, Yiu wrote: > =20 > > Dear Satoru and MAP-DT > >=20 > > I echo what Peng and Qiong said. When the WG agreed working on the > > stateless solution, it was very clear stated that the solution would = not > > maintain states in the network. If the 1:1 mode changed this, this = no > > longer matched the requirements stated in the stateless motivation = draft, > > thus, it would disqualify MAP as a solution for the motivation = draft. > >=20 > > AFAIK, the MAP Design Team could propose a change, but such a = dramatic > > change by introducing states in the network would require WG = approval. I > > would like the chairs to clarify this. > >=20 > > Thanks, > > Yiu > >=20 > >=20 > > On 6/24/12 12:21 PM, "Peng Wu" wrote: > >=20 > >> Hi Qiong, Satoru and all, > >>=20 > >> I should thank Qiong for pointing this out. I gotta say I'm a bit = shocked. > >> If I understand the procedures of IETF correctly, a WG document = should > >> reflect the consensus of the WG. MAP is approved by the WG as a > >> stateless solution. As a participator in Softwire, I didn't get the > >> information anywhere that the MAP WG document would cover the > >> so-called 1:1, in fact per-user stateful mode before it was = released, > >> not to say discuss in the WG. Don't the WG need to approve such big > >> change anymore? > >>=20 > >> Now let me provide my impression as an outsider of the MAP DT. You > >> guys make great effort to build the solution, The address = composition, > >> the GMA algorithm, the different types of address mapping rules. > >> should be quite difficult to pull together such sophisticated = ideas. I > >> guess that's what it takes to achieve the benifits of = statelessness. > >> And I admire that, bravo. Then, all of a sudden, you guys are = saying, > >> let's apply this sophisticated method to the different problem, by > >> dropping quite some comlexity and twistting the mechanism a bit, = seems > >> it may work. Considering the problem are now solved in a more pure = and > >> clear way, I'm sorry but I CANNOT follow the logic here. > >>=20 > >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima > >> wrote: > >>> Hi Qiong, > >>>=20 > >>> I'm disagree with your opinion. > >>>=20 > >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed = in > >>> the DT. > >>> 2. MAP just covers so called '1:1 mode' with most granular mapping = rule > >>> for CEs provisioning, which is as one of its characteristics. > >>> 3. The motivation draft does not restrict that as you stated, just > >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. > >>>=20 > >>> Best regards, > >>> --satoru > >>>=20 > >>>=20 > >>> On 2012/06/24, at 14:35, Qiong wrote: > >>>=20 > >>>> Hi all, > >>>>=20 > >>>> As we all know, once an individual draft is adopted as a WG = draft, it > >>>> is owned by the whole WG, rather than just the editors. Just as = Remi > >>>> said, the normal procedure to follow is to reach WG consensus = _before_ > >>>> posting a newly edited version. > >>>>=20 > >>>> =46rom draft-mdt-softwire-mapping-address-and-port-03 to > >>>> draft-ietf-softwire-map-00, there are several changes between = them. In > >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 = and > >>>> IPv6 addressing, has never been discussed openly in the WG = mailing > >>>> list, or even in the MAP design team either. > >>>>=20 > >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation > >>>> draft. The motivation draft has clearly defines the "Stateless = 4/6 > >>>> solution" as follows: > >>>>=20 > >>>> Stateless 4/6 solution denotes a solution which does not require = any > >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by = any > >>>> IP address sharing function in the Service Provider's network. = This > >>>> category of solutions assumes a dependency between an IPv6 prefix = and > >>>> IPv4 address. > >>>>=20 > >>>> AFAIK what the WG has adopted MAP related draft is > >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT > >>>> draft-ietf-softwire-map-00. And the stateless solution should = =C2=B3response > >>>> to the solution motivation document=C2=B2 according to the = Softwire charter. > >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG = draft. > >>>>=20 > >>>> We can all recall that our softwire WG has worked on stateless > >>>> solutions for more than one and a half years, and we have = achieved a > >>>> lot of work which has been documented in charter, stateless = motivation, > >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the = basic > >>>> "stateless" principle and the MAP design team is also working on = it > >>>> together to find a better algorithm, address format, etc. So it = is > >>>> really not appropriate to make such changes when MAP is adopted = as a WG > >>>> item in such a short time. > >>>>=20 > >>>> =46rom this perspective, draft-ietf-softwire-map-00 can only be = regarded > >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even = the > >>>> output of MAP design team. > >>>>=20 > >>>> Best wishes > >>>>=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/ > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 > >>>=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 > =20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Jun 25 00:05: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 592D621F8585 for ; Mon, 25 Jun 2012 00:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSoAPeIviOBD for ; Mon, 25 Jun 2012 00:05:02 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB5B21F855B for ; Mon, 25 Jun 2012 00:05:01 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id 2334D70000BE; Mon, 25 Jun 2012 09:05:00 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id 48E8370000BA; Mon, 25 Jun 2012 09:04:59 +0200 (CEST) X-SFR-UUID: 20120625070459298.48E8370000BA@msfrf2209.sfr.fr Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Mon, 25 Jun 2012 08:58:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6AFFB3B8-CDAD-4ECB-A80B-93694FA73504@laposte.net> References: <41420625-8EEA-41E9-8695-1C7F63A62B11@laposte.net> To: Ole Troan , Wojciech Dec , Xing Li , Congxiao Bao , Yu Zhai , Satoru Matsushima , Tetsuya Murakami X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 07:05:03 -0000 Hi, authors of the last submitted MAP draft, In the context of this discussion on 1:1 mapping, it is even clearer = that an answer to the question below (asked 2 weeks ago) is desirable to = clarify who supports what and why.=20 Thanks, RD D=E9but du message r=E9exp=E9di=E9 : > De : R=E9mi Despr=E9s > Date : 2012-06-11 15:49 > =C0 : Ole Troan > Cc : Softwires WG > Objet : R=E9p : [Softwires] I-D Action: draft-ietf-softwire-map-00.txt ... > Also, since some evolutions of substance have been introduced, a list = of these would be highly appreciated, preferably with brief = justifications. >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Softwires Working Group of = the IETF. >>=20 >> Title : Mapping of Address and Port (MAP) >> Author(s) : Ole Troan >> Wojciech Dec >> Xing Li >> Congxiao Bao >> Yu Zhai >> Satoru Matsushima >> Tetsuya Murakami >> Filename : draft-ietf-softwire-map-00.txt >> Pages : 33 >> Date : 2012-06-01 ... From sunqi.csnet.thu@gmail.com Mon Jun 25 00:13: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 8301821F84DD for ; Mon, 25 Jun 2012 00:13:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo7MURA891pp for ; Mon, 25 Jun 2012 00:13:49 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2851421F84D6 for ; Mon, 25 Jun 2012 00:13:49 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6205796pbc.31 for ; Mon, 25 Jun 2012 00:13:48 -0700 (PDT) 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-mailer:mime-version:message-id:content-type; bh=rxcIt0ioo8HZXd2CGBgypbqMtMp0jE1uDAI5ECpM1HU=; b=S0dwdrUSj0G/nld32fxejJ6kucCfd96v0PSjcMIeO3UaRx/YBwtndgP77ghvnEcMff zfif+gDlDp7PrJPWV8TQA5LGK7uOKY3FLg5eJdBmJkumYfQTJ9jgl8WWB69eb4Nb0yWg tQ+77F+9ghB5fkAGt2AyLDOEwCDrYNLOlpzp2O99klOsF9zNWcUgk2YQTeO2Jl2OIcoW hkIOVteirY/27iBfx6Z7Zp/Bfhuo+PV+kOuVF/UsarUAV3wuWwiXu+twLTdStEby/C1M ArJhBVH1kVND6Llh7QlT2bvzFUTfbJi4nF5Rs6a1LugU1L52pCWLxxPeEYkQcgr2kfSA tx/A== Received: by 10.68.226.131 with SMTP id rs3mr31978248pbc.62.1340608428300; Mon, 25 Jun 2012 00:13:48 -0700 (PDT) Received: from sunqi ([219.243.220.10]) by mx.google.com with ESMTPS id rs4sm7692630pbc.0.2012.06.25.00.13.44 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 00:13:47 -0700 (PDT) Date: Mon, 25 Jun 2012 15:13:40 +0800 From: "Qi Sun" To: "Satoru Matsushima" References: , <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com>, <6D03A23F-DB70-43FC-A043-88DE7521D534@gmail.com> X-Priority: 3 X-GUID: 08DA321F-0BD0-434E-A086-CF37B1628BB4 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012062515134048558525@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart282585533632_=----" Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 07:13:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart282585533632_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2F0b3J1LA0KDQpXaGF0IEkgZW1waGFzaXplIGlzIHRoYXQgd2l0aCBwZXItc3Vic2NyaWJl ciBhcyBhIE1BUCBkb21haW4gKGluIDE6MSBtb2RlKSwgdGhlcmUgd2lsbCBiZSBhIGh1Z2UgbWFw cGluZyB0YWJsZSBmb3IgdGhlIEJSIHRvIG1haW50YWluLiBUaGF0J3Mgc3RhdGUgb24gQlIsIHdo aWNoIGlzIGRpZmZlcmVudCBmcm9tIG5vbi0xOjEtbW9kZS4NCg0KQmVzdCBSZWdhcmRzIQ0KDQpR aSBTdW4NCg0KDQpGcm9tOiBTYXRvcnUgTWF0c3VzaGltYQ0KRGF0ZTogMjAxMi0wNi0yNSAxNTow MQ0KVG86IHN1bnFpLmNzbmV0LnRodQ0KQ0M6IFNhdG9ydSBNYXRzdXNoaW1hOyBzb2Z0d2lyZXMg V0c7IFlvbmcgQ3VpOyBMZWUsIFlpdQ0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIFtTb2Z0d2ly ZV0gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgZG9lcyBOT1QgcmVmbGVjdCB0aGUgY29uc2Vu c3VzIGZyb20gdGhlIFdHDQpIaSBRaW9uZywNCg0KQSBNQVAgZG9tYWluIGNhbiBoYXZlIHNldmVy YWwvc29tZS9tYW55IG1hcHBpbmcgcnVsZXMgaW4gdGhlIGRvbWFpbi4gSG93IG1hbnkgaXMgdGhy ZXNob2xkIGZvciBlaXRoZXIgc3RhdGVsZXNzIG9yIHN0YXRlZnVsPw0KDQpjaGVlcnMsDQotLXNh dG9ydQ0KDQpPbiAyMDEyLzA2LzI1LCBhdCAxNTo1MSwgUWkgU3VuIHdyb3RlOg0KDQo+IEhpIFNh dG9ydSwNCj4gIA0KPiBJbiBNQVAgMToxIG1vZGUsIGlmIHRoZXJlIGFyZSAxMDAwMDAwMCBzdWJz Y3JpYmVycywgdGhlcmUgd291bGQgYmUgMTAwMDAwMDAgTUFQIGRvbWFpbnMgd2hpY2ggYSBCUiBo YXMgdG8gbWFuYWdlLiBJIHRoaW5rIHRoYXQgd2lsbCBjcmVhdGUgYSBodWdlIG1hcHBpbmcgdGFi bGUgb24gdGhlIEJSLCB3aGljaCBpcyBjYWxsZWQgJ3N0YXRlJyB0aGF0IHN0YXRlZnVsIHNvbHV0 aW9ucyBkZWFsIHdpdGguDQo+ICANCj4gQmVzdCBSZWdhcmRzIQ0KPiAgDQo+IFFpIFN1bg0KPiAg DQo+IEZyb206IFNhdG9ydSBNYXRzdXNoaW1hDQo+IERhdGU6IDIwMTItMDYtMjUgMTA6MjcNCj4g VG86IExlZSwgWWl1DQo+IENDOiBzb2Z0d2lyZXNAaWV0Zi5vcmc7IFlvbmcgQ3VpDQo+IFN1Ympl Y3Q6IFJlOiBbU29mdHdpcmVzXSBbU29mdHdpcmVdIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAw IGRvZXMgTk9UIHJlZmxlY3QgdGhlIGNvbnNlbnN1cyBmcm9tIHRoZSBXRw0KPiBIaSBZaXUsDQo+ ICANCj4gTm8sIHRoYXQncyBhIG1pc3VuZGVyc3RhbmRpbmcuDQo+IEN1cnJlbnQgTUFQIHNwZWNp ZnkgdGhlIGNhc2UgZm9yIGVhLWxlbiBpcyAnemVybycuIEl0IGlzICdwZXItc3Vic2NyaWJlciBt YXBwaW5nJyBpbiBzdGF0ZWxlc3MgbWFubmVyLCBub3QgdG8gaW50cm9kdWNlICdwZXItZmxvdyBO QVQgYmluZGluZycgb3IgJ3Blci1zdWJzY3JpYmVyIHN0YXRlIG9uIGRlbWFuZCcuDQo+ICANCj4g Y2hlZXJzLA0KPiAtLXNhdG9ydQ0KPiAgDQo+IE9uIDIwMTIvMDYvMjUsIGF0IDI6MzIsIExlZSwg WWl1IHdyb3RlOg0KPiAgDQo+ID4gRGVhciBTYXRvcnUgYW5kIE1BUC1EVA0KPiA+IA0KPiA+IEkg ZWNobyB3aGF0IFBlbmcgYW5kIFFpb25nIHNhaWQuIFdoZW4gdGhlIFdHIGFncmVlZCB3b3JraW5n IG9uIHRoZQ0KPiA+IHN0YXRlbGVzcyBzb2x1dGlvbiwgaXQgd2FzIHZlcnkgY2xlYXIgc3RhdGVk IHRoYXQgdGhlIHNvbHV0aW9uIHdvdWxkIG5vdA0KPiA+IG1haW50YWluIHN0YXRlcyBpbiB0aGUg bmV0d29yay4gSWYgdGhlIDE6MSBtb2RlIGNoYW5nZWQgdGhpcywgdGhpcyBubw0KPiA+IGxvbmdl ciBtYXRjaGVkIHRoZSByZXF1aXJlbWVudHMgc3RhdGVkIGluIHRoZSBzdGF0ZWxlc3MgbW90aXZh dGlvbiBkcmFmdCwNCj4gPiB0aHVzLCBpdCB3b3VsZCBkaXNxdWFsaWZ5IE1BUCBhcyBhIHNvbHV0 aW9uIGZvciB0aGUgbW90aXZhdGlvbiBkcmFmdC4NCj4gPiANCj4gPiBBRkFJSywgdGhlIE1BUCBE ZXNpZ24gVGVhbSBjb3VsZCBwcm9wb3NlIGEgY2hhbmdlLCBidXQgc3VjaCBhIGRyYW1hdGljDQo+ ID4gY2hhbmdlIGJ5IGludHJvZHVjaW5nIHN0YXRlcyBpbiB0aGUgbmV0d29yayB3b3VsZCByZXF1 aXJlIFdHIGFwcHJvdmFsLiBJDQo+ID4gd291bGQgbGlrZSB0aGUgY2hhaXJzIHRvIGNsYXJpZnkg dGhpcy4NCj4gPiANCj4gPiBUaGFua3MsDQo+ID4gWWl1DQo+ID4gDQo+ID4gDQo+ID4gT24gNi8y NC8xMiAxMjoyMSBQTSwgIlBlbmcgV3UiIDxwZW5nd3UudGh1QGdtYWlsLmNvbT4gd3JvdGU6DQo+ ID4gDQo+ID4+IEhpIFFpb25nLCBTYXRvcnUgYW5kIGFsbCwNCj4gPj4gDQo+ID4+IEkgc2hvdWxk IHRoYW5rIFFpb25nIGZvciBwb2ludGluZyB0aGlzIG91dC4gSSBnb3R0YSBzYXkgSSdtIGEgYml0 IHNob2NrZWQuDQo+ID4+IElmIEkgdW5kZXJzdGFuZCB0aGUgcHJvY2VkdXJlcyBvZiBJRVRGIGNv cnJlY3RseSwgYSBXRyBkb2N1bWVudCBzaG91bGQNCj4gPj4gcmVmbGVjdCB0aGUgY29uc2Vuc3Vz IG9mIHRoZSBXRy4gTUFQIGlzIGFwcHJvdmVkIGJ5IHRoZSBXRyBhcyBhDQo+ID4+IHN0YXRlbGVz cyBzb2x1dGlvbi4gQXMgYSBwYXJ0aWNpcGF0b3IgaW4gU29mdHdpcmUsIEkgZGlkbid0IGdldCB0 aGUNCj4gPj4gaW5mb3JtYXRpb24gYW55d2hlcmUgdGhhdCB0aGUgTUFQIFdHIGRvY3VtZW50IHdv dWxkIGNvdmVyIHRoZQ0KPiA+PiBzby1jYWxsZWQgMToxLCBpbiBmYWN0IHBlci11c2VyIHN0YXRl ZnVsIG1vZGUgYmVmb3JlIGl0IHdhcyByZWxlYXNlZCwNCj4gPj4gbm90IHRvIHNheSBkaXNjdXNz IGluIHRoZSBXRy4gRG9uJ3QgdGhlIFdHIG5lZWQgdG8gYXBwcm92ZSBzdWNoIGJpZw0KPiA+PiBj aGFuZ2UgYW55bW9yZT8NCj4gPj4gDQo+ID4+IE5vdyBsZXQgbWUgcHJvdmlkZSBteSBpbXByZXNz aW9uIGFzIGFuIG91dHNpZGVyIG9mIHRoZSBNQVAgRFQuIFlvdQ0KPiA+PiBndXlzIG1ha2UgZ3Jl YXQgZWZmb3J0IHRvIGJ1aWxkIHRoZSBzb2x1dGlvbiwgVGhlIGFkZHJlc3MgY29tcG9zaXRpb24s DQo+ID4+IHRoZSBHTUEgYWxnb3JpdGhtLCB0aGUgZGlmZmVyZW50IHR5cGVzIG9mIGFkZHJlc3Mg bWFwcGluZyBydWxlcy4NCj4gPj4gc2hvdWxkIGJlIHF1aXRlIGRpZmZpY3VsdCB0byBwdWxsIHRv Z2V0aGVyIHN1Y2ggc29waGlzdGljYXRlZCBpZGVhcy4gSQ0KPiA+PiBndWVzcyB0aGF0J3Mgd2hh dCBpdCB0YWtlcyB0byBhY2hpZXZlIHRoZSBiZW5pZml0cyBvZiBzdGF0ZWxlc3NuZXNzLg0KPiA+ PiBBbmQgSSBhZG1pcmUgdGhhdCwgYnJhdm8uIFRoZW4sIGFsbCBvZiBhIHN1ZGRlbiwgeW91IGd1 eXMgYXJlIHNheWluZywNCj4gPj4gbGV0J3MgYXBwbHkgdGhpcyBzb3BoaXN0aWNhdGVkIG1ldGhv ZCB0byB0aGUgZGlmZmVyZW50IHByb2JsZW0sIGJ5DQo+ID4+IGRyb3BwaW5nIHF1aXRlIHNvbWUg Y29tbGV4aXR5IGFuZCB0d2lzdHRpbmcgdGhlIG1lY2hhbmlzbSBhIGJpdCwgc2VlbXMNCj4gPj4g aXQgbWF5IHdvcmsuIENvbnNpZGVyaW5nIHRoZSBwcm9ibGVtIGFyZSBub3cgc29sdmVkIGluIGEg bW9yZSBwdXJlIGFuZA0KPiA+PiBjbGVhciB3YXksIEknbSBzb3JyeSBidXQgSSBDQU5OT1QgZm9s bG93IHRoZSBsb2dpYyBoZXJlLg0KPiA+PiANCj4gPj4gT24gU3VuLCBKdW4gMjQsIDIwMTIgYXQg MjowMCBQTSwgU2F0b3J1IE1hdHN1c2hpbWENCj4gPj4gPHNhdG9ydS5tYXRzdXNoaW1hQGdtYWls LmNvbT4gd3JvdGU6DQo+ID4+PiBIaSBRaW9uZywNCj4gPj4+IA0KPiA+Pj4gSSdtIGRpc2FncmVl IHdpdGggeW91ciBvcGluaW9uLg0KPiA+Pj4gDQo+ID4+PiAxLiBSZWNlbnQgY2hhbmdlcyBpbiBk cmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4NCj4gPj4+IHRo ZSBEVC4NCj4gPj4+IDIuIE1BUCBqdXN0IGNvdmVycyBzbyBjYWxsZWQgJzE6MSBtb2RlJyB3aXRo IG1vc3QgZ3JhbnVsYXIgbWFwcGluZyBydWxlDQo+ID4+PiBmb3IgQ0VzIHByb3Zpc2lvbmluZywg d2hpY2ggaXMgYXMgb25lIG9mIGl0cyBjaGFyYWN0ZXJpc3RpY3MuDQo+ID4+PiAzLiBUaGUgbW90 aXZhdGlvbiBkcmFmdCBkb2VzIG5vdCByZXN0cmljdCB0aGF0IGFzIHlvdSBzdGF0ZWQsIGp1c3QN Cj4gPj4+ICdhc3N1bWVkJywgaXQncyBuZWl0aGVyICdNVVNUJyBub3IgJ1NIT1VMRCcuDQo+ID4+ PiANCj4gPj4+IEJlc3QgcmVnYXJkcywNCj4gPj4+IC0tc2F0b3J1DQo+ID4+PiANCj4gPj4+IA0K PiA+Pj4gT24gMjAxMi8wNi8yNCwgYXQgMTQ6MzUsIFFpb25nIHdyb3RlOg0KPiA+Pj4gDQo+ID4+ Pj4gSGkgYWxsLA0KPiA+Pj4+IA0KPiA+Pj4+IEFzIHdlIGFsbCBrbm93LCBvbmNlIGFuIGluZGl2 aWR1YWwgZHJhZnQgaXMgYWRvcHRlZCBhcyBhIFdHIGRyYWZ0LCBpdA0KPiA+Pj4+IGlzIG93bmVk IGJ5IHRoZSB3aG9sZSBXRywgcmF0aGVyIHRoYW4ganVzdCB0aGUgZWRpdG9ycy4gSnVzdCBhcyBS ZW1pDQo+ID4+Pj4gc2FpZCwgdGhlIG5vcm1hbCBwcm9jZWR1cmUgdG8gZm9sbG93IGlzIHRvIHJl YWNoIFdHIGNvbnNlbnN1cyBfYmVmb3JlXw0KPiA+Pj4+IHBvc3RpbmcgYSBuZXdseSBlZGl0ZWQg dmVyc2lvbi4NCj4gPj4+PiANCj4gPj4+PiBGcm9tIGRyYWZ0LW1kdC1zb2Z0d2lyZS1tYXBwaW5n LWFkZHJlc3MtYW5kLXBvcnQtMDMgdG8NCj4gPj4+PiBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0w MCwgdGhlcmUgYXJlIHNldmVyYWwgY2hhbmdlcyBiZXR3ZWVuIHRoZW0uIEluDQo+ID4+Pj4gcGFy dGljdWxhciwgdGhlIG5ld2x5IGludHJvZHVjZWQgIjE6MSBtb2RlIiwgd2hpY2ggZGVjb3VwbGVz IElQdjQgYW5kDQo+ID4+Pj4gSVB2NiBhZGRyZXNzaW5nLCBoYXMgbmV2ZXIgYmVlbiBkaXNjdXNz ZWQgb3Blbmx5IGluIHRoZSBXRyBtYWlsaW5nDQo+ID4+Pj4gbGlzdCwgb3IgZXZlbiBpbiB0aGUg TUFQIGRlc2lnbiB0ZWFtIGVpdGhlci4NCj4gPj4+PiANCj4gPj4+PiBBY3R1YWxseSwgdGhpcyAi MToxIG1vZGUiIGlzIGFnYWluc3QgdGhlIHN0YXRlbGVzcy00djYtbW90aXZhdGlvbg0KPiA+Pj4+ IGRyYWZ0LiBUaGUgbW90aXZhdGlvbiBkcmFmdCBoYXMgY2xlYXJseSBkZWZpbmVzIHRoZSAiU3Rh dGVsZXNzIDQvNg0KPiA+Pj4+IHNvbHV0aW9uIiBhcyBmb2xsb3dzOg0KPiA+Pj4+IA0KPiA+Pj4+ IFN0YXRlbGVzcyA0LzYgc29sdXRpb24gZGVub3RlcyBhIHNvbHV0aW9uIHdoaWNoIGRvZXMgbm90 IHJlcXVpcmUgYW55DQo+ID4+Pj4gcGVyLXVzZXIgc3RhdGUgKHNlZSBTZWN0aW9uIDIuMyBvZiBb UkZDMTk1OF0pIHRvIGJlIG1haW50YWluZWQgYnkgYW55DQo+ID4+Pj4gSVAgYWRkcmVzcyBzaGFy aW5nIGZ1bmN0aW9uIGluIHRoZSBTZXJ2aWNlIFByb3ZpZGVyJ3MgbmV0d29yay4gVGhpcw0KPiA+ Pj4+IGNhdGVnb3J5IG9mIHNvbHV0aW9ucyBhc3N1bWVzIGEgZGVwZW5kZW5jeSBiZXR3ZWVuIGFu IElQdjYgcHJlZml4IGFuZA0KPiA+Pj4+IElQdjQgYWRkcmVzcy4NCj4gPj4+PiANCj4gPj4+PiBB RkFJSyB3aGF0IHRoZSBXRyBoYXMgYWRvcHRlZCBNQVAgcmVsYXRlZCBkcmFmdCBpcw0KPiA+Pj4+ IGRyYWZ0LW1kdC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBvcnQtMDMsIE5PVA0KPiA+ Pj4+IGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwLiBBbmQgdGhlIHN0YXRlbGVzcyBzb2x1dGlv biBzaG91bGQgwrNyZXNwb25zZQ0KPiA+Pj4+IHRvIHRoZSBzb2x1dGlvbiBtb3RpdmF0aW9uIGRv Y3VtZW50wrIgYWNjb3JkaW5nIHRvIHRoZSBTb2Z0d2lyZSBjaGFydGVyLg0KPiA+Pj4+IFRoYXQg bWVhbnMgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgSVMgTk9UIFFVQUxJRklFRCB0byBiZSBh IFdHIGRyYWZ0Lg0KPiA+Pj4+IA0KPiA+Pj4+IFdlIGNhbiBhbGwgcmVjYWxsIHRoYXQgb3VyIHNv ZnR3aXJlIFdHIGhhcyB3b3JrZWQgb24gc3RhdGVsZXNzDQo+ID4+Pj4gc29sdXRpb25zIGZvciBt b3JlIHRoYW4gb25lIGFuZCBhIGhhbGYgeWVhcnMsIGFuZCB3ZSBoYXZlIGFjaGlldmVkIGENCj4g Pj4+PiBsb3Qgb2Ygd29yayB3aGljaCBoYXMgYmVlbiBkb2N1bWVudGVkIGluIGNoYXJ0ZXIsIHN0 YXRlbGVzcyBtb3RpdmF0aW9uLA0KPiA+Pj4+IDRyZC12YXJpZW50cywgTUFQLTAzLCBldGMuIEFG QUlLIGFsbCB0aGUgYXV0aG9ycyBoYXZlIGtlcHQgdGhlIGJhc2ljDQo+ID4+Pj4gInN0YXRlbGVz cyIgcHJpbmNpcGxlIGFuZCB0aGUgTUFQIGRlc2lnbiB0ZWFtIGlzIGFsc28gd29ya2luZyBvbiBp dA0KPiA+Pj4+IHRvZ2V0aGVyIHRvIGZpbmQgYSBiZXR0ZXIgYWxnb3JpdGhtLCBhZGRyZXNzIGZv cm1hdCwgZXRjLiBTbyBpdCBpcw0KPiA+Pj4+IHJlYWxseSBub3QgYXBwcm9wcmlhdGUgdG8gbWFr ZSBzdWNoIGNoYW5nZXMgd2hlbiBNQVAgaXMgYWRvcHRlZCBhcyBhIFdHDQo+ID4+Pj4gaXRlbSBp biBzdWNoIGEgc2hvcnQgdGltZS4NCj4gPj4+PiANCj4gPj4+PiBGcm9tIHRoaXMgcGVyc3BlY3Rp dmUsIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwIGNhbiBvbmx5IGJlIHJlZ2FyZGVkDQo+ID4+ Pj4gYXMgZHJhZnQtWFgtc29mdHdpcmUtbWFwcGluZy1hZGRyZXNzLWFuZC1wb3J0LTA0LiBJdCBp cyBub3QgZXZlbiB0aGUNCj4gPj4+PiBvdXRwdXQgb2YgTUFQIGRlc2lnbiB0ZWFtLg0KPiA+Pj4+ IA0KPiA+Pj4+IEJlc3Qgd2lzaGVzDQo+ID4+Pj4gDQo+ID4+Pj4gPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+Pj4+IFFpb25nIFN1bg0KPiA+Pj4+IENo aW5hIFRlbGVjb20gQmVpamluZyBSZXNlYXJjaCBJbnN0aXR1ZGUNCj4gPj4+PiANCj4gPj4+PiAN Cj4gPj4+PiBPcGVuIHNvdXJjZSBjb2RlOg0KPiA+Pj4+IGxpZ2h0d2VpZ2h0IDRvdmVyNjogaHR0 cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni8NCj4gPj4+PiBQQ1AtbmF0Y29vcmQ6 IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvcGNwcG9ydHNldGRlbW8vDQo+ID4+Pj4g PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPj4+PiAN Cj4gPj4+PiANCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+Pj4+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4gPj4+PiBTb2Z0d2lyZXNA aWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nv ZnR3aXJlcw0KPiA+Pj4gDQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiA+Pj4gU29mdHdp cmVzQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NvZnR3aXJlcw0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+ID4+IFNvZnR3aXJlc0BpZXRm Lm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJl cw0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4gU29mdHdpcmVzQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVz ------=_001_NextPart282585533632_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Satoru,
 
What I emphasize is that with per-subscriber as a MAP domain (in 1:1 = mode),=20 there will be a huge mapping table for the BR to maintain. That's state on= BR,=20 which is different from non-1:1-mode.
 
Best Regards!
 
Qi Sun
 
 
Date: 2012-06-25 15:01
To: sunqi.csnet.thu
CC: Satoru= =20 Matsushima; softwires WG; Yong Cui; Lee, Yiu
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
Hi Qiong,
 
A MAP domain can have several/some/many = ;mapping rules in the domain. How many = is threshold for either stateless or statefu= l?
 
cheers,
--satoru
 
On 2012/06/25, at 15:51, Qi Sun wrote:<= /DIV>
 
> Hi Satoru,
>  
> In MAP 1:1 mode, if there are=  10000000 subscribers, there would be 100000= 00 MAP domains which a BR has to m= anage. I think that will create a huge&= nbsp;mapping table on the BR, which is = called 'state' that stateful solutions deal = with.
>  
> Best Regards!
>  
> Qi Sun
>  
> From: Satoru Matsushima
> Date: 2012-06-25 10:27
> To: Lee, Yiu
> CC: softwires@ietf.org; Yong Cui
> Subject: Re: [Softwires] [Softwire] dra= ft-ietf-softwire-map-00 does NOT reflect the cons= ensus from the WG
> Hi Yiu,
>  
> No, that's a misunderstanding.
> Current MAP specify the case for&n= bsp;ea-len is 'zero'. It is 'per-subscriber = mapping' in stateless manner, not to introdu= ce 'per-flow NAT binding' or 'per-subscriber = ;state on demand'.
>  
> cheers,
> --satoru
>  
> On 2012/06/25, at 2:32, Lee, Yiu&n= bsp;wrote:
>  
> > Dear Satoru and MAP-DT
> > 
> > I echo what Peng and Qio= ng said. When the WG agreed working on&= nbsp;the
> > stateless solution, it was ve= ry clear stated that the solution would = ;not
> > maintain states in the networ= k. If the 1:1 mode changed this, this&n= bsp;no
> > longer matched the requirements&nb= sp;stated in the stateless motivation draft,
> > thus, it would disqualify MAP=  as a solution for the motivation draft= .
> > 
> > AFAIK, the MAP Design Team&nb= sp;could propose a change, but such a d= ramatic
> > change by introducing states = in the network would require WG approval.&nb= sp;I
> > would like the chairs to = ;clarify this.
> > 
> > Thanks,
> > Yiu
> > 
> > 
> > On 6/24/12 12:21 PM, "Peng&nb= sp;Wu" <pengwu.thu@gmail.com> wrote:
> > 
> >> Hi Qiong, Satoru and all,=
> >> 
> >> I should thank Qiong for&= nbsp;pointing this out. I gotta say I'm = ;a bit shocked.
> >> If I understand the proce= dures of IETF correctly, a WG document = should
> >> reflect the consensus of = the WG. MAP is approved by the WG = as a
> >> stateless solution. As a = participator in Softwire, I didn't get the
> >> information anywhere that the&= nbsp;MAP WG document would cover the
> >> so-called 1:1, in fact pe= r-user stateful mode before it was released,=
> >> not to say discuss in&nbs= p;the WG. Don't the WG need to approve&= nbsp;such big
> >> change anymore?
> >> 
> >> Now let me provide my&nbs= p;impression as an outsider of the MAP = DT. You
> >> guys make great effort to=  build the solution, The address composition= ,
> >> the GMA algorithm, the di= fferent types of address mapping rules.
> >> should be quite difficult = ;to pull together such sophisticated ideas. = I
> >> guess that's what it take= s to achieve the benifits of statelessness.<= /DIV>
> >> And I admire that, bravo.=  Then, all of a sudden, you guys a= re saying,
> >> let's apply this sophisticated=  method to the different problem, by
> >> dropping quite some comlexity&= nbsp;and twistting the mechanism a bit, seem= s
> >> it may work. Considering = the problem are now solved in a more&nb= sp;pure and
> >> clear way, I'm sorry but&= nbsp;I CANNOT follow the logic here.
> >> 
> >> On Sun, Jun 24, 2012 = ;at 2:00 PM, Satoru Matsushima
> >> <satoru.matsushima@gmail.com> wrot= e:
> >>> Hi Qiong,
> >>> 
> >>> I'm disagree with your&nbs= p;opinion.
> >>> 
> >>> 1. Recent changes in = draft-ietf-softwire-map-00 has been discussed in
> >>> the DT.
> >>> 2. MAP just covers so=  called '1:1 mode' with most granular m= apping rule
> >>> for CEs provisioning, whic= h is as one of its characteristics.
> >>> 3. The motivation draft&nb= sp;does not restrict that as you stated,&nbs= p;just
> >>> 'assumed', it's neither 'M= UST' nor 'SHOULD'.
> >>> 
> >>> Best regards,
> >>> --satoru
> >>> 
> >>> 
> >>> On 2012/06/24, at 14:35,&n= bsp;Qiong wrote:
> >>> 
> >>>> Hi all,
> >>>> 
> >>>> As we all know, o= nce an individual draft is adopted as a=  WG draft, it
> >>>> is owned by the w= hole WG, rather than just the editors. = Just as Remi
> >>>> said, the normal proce= dure to follow is to reach WG consensus=  _before_
> >>>> posting a newly edited=  version.
> >>>> 
> >>>> From draft-mdt-softwire-mapping-= address-and-port-03 to
> >>>> draft-ietf-softwire-map-00, ther= e are several changes between them. In
> >>>> particular, the newly = introduced "1:1 mode", which decouples IPv4 = and
> >>>> IPv6 addressing, has n= ever been discussed openly in the WG ma= iling
> >>>> list, or even in = the MAP design team either.
> >>>> 
> >>>> Actually, this "1:1 mo= de" is against the stateless-4v6-motivation
> >>>> draft. The motivation = draft has clearly defines the "Stateless 4/6=
> >>>> solution" as follows:
> >>>> 
> >>>> Stateless 4/6 solution = ;denotes a solution which does not require&n= bsp;any
> >>>> per-user state (see Se= ction 2.3 of [RFC1958]) to be maintained&nbs= p;by any
> >>>> IP address sharing fun= ction in the Service Provider's network. Thi= s
> >>>> category of solutions = assumes a dependency between an IPv6 prefix&= nbsp;and
> >>>> IPv4 address.
> >>>> 
> >>>> AFAIK what the WG = ;has adopted MAP related draft is
> >>>> draft-mdt-softwire-mapping-address-an= d-port-03, NOT
> >>>> draft-ietf-softwire-map-00. And&= nbsp;the stateless solution should =C2=B3response
> >>>> to the solution motiva= tion document=C2=B2 according to the Softwire&nbs= p;charter.
> >>>> That means draft-ietf-softw= ire-map-00 IS NOT QUALIFIED to be a WG&= nbsp;draft.
> >>>> 
> >>>> We can all recall = ;that our softwire WG has worked on sta= teless
> >>>> solutions for more tha= n one and a half years, and we hav= e achieved a
> >>>> lot of work which = ;has been documented in charter, stateless m= otivation,
> >>>> 4rd-varients, MAP-03, etc.&= nbsp;AFAIK all the authors have kept the&nbs= p;basic
> >>>> "stateless" principle and&n= bsp;the MAP design team is also working = ;on it
> >>>> together to find a&nbs= p;better algorithm, address format, etc. So = it is
> >>>> really not appropriate = ;to make such changes when MAP is adopt= ed as a WG
> >>>> item in such a sh= ort time.
> >>>> 
> >>>> From this perspective, = ;draft-ietf-softwire-map-00 can only be regarded
> >>>> as draft-XX-softwire-mapping-add= ress-and-port-04. It is not even the
> >>>> output of MAP design&n= bsp;team.
> >>>> 
> >>>> Best wishes
> >>>> 
> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/sof= twires
> >> _____________________________________________= __
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.org/mailman/listinfo/softwir= es
>  
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
 
------=_001_NextPart282585533632_=------ From satoru.matsushima@gmail.com Mon Jun 25 00:18: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 64F8B21F853B for ; Mon, 25 Jun 2012 00:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.262 X-Spam-Level: X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awMYQrFzJ5SR for ; Mon, 25 Jun 2012 00:18:53 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED6CF21F853A for ; Mon, 25 Jun 2012 00:18:52 -0700 (PDT) Received: by dacx6 with SMTP id x6so4941703dac.31 for ; Mon, 25 Jun 2012 00:18:52 -0700 (PDT) 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=aT7sb0wK0H3v1G5C/ELbacGSAqwwKbNK5D8jsYFbjIs=; b=0TS3WUEfeXIf/O1XJy627OW3bSbkq8IOcEZskEuqbgtIXz7OrVyuitzkrd/R5OWJWo /Ouk0A+T9dMby9lb3a99JsU3qG1TneRyfxUv7rmiTJzRzuBapSzfoJ4MJxhsOw84GoAn Y+gSoKvtujaNISdL6s8SEW1yPSyauTv60sNINhMVQ77sWqcrGkwGdysyqPio9lSwxkT/ 8Smk3Iqxj81xOqvib6t2geoYpdA67n5MZsqLsb8/18SG94Cv4P8c0p1Q6utGON7uP/ev rpKXAbQ6j7nunCutEeYAG4SLTZ+ntdANq7Ea9QcHQht8HQ7AYKsqwCNs6HGSxNSFAUMC YJBw== Received: by 10.68.220.39 with SMTP id pt7mr38567463pbc.40.1340608732786; Mon, 25 Jun 2012 00:18:52 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id os1sm7682527pbb.49.2012.06.25.00.18.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 00:18:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 16:18:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <97A4D74A-A531-4F83-B281-86973A3139A5@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> To: Maoke X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 07:18:53 -0000 Hi Maoke-san, On 2012/06/25, at 12:07, Maoke wrote: > hi Satoru-san, Qiong, and all,=20 >=20 > i think the current 1:1 mode text of the draft should be tuned or, it = would be better, to be removed. >=20 > technically, i expect MAP as a completely per-session, per-subscriber = stateless solution and therefore per-subscriber mapping rule is not = accepted. in theory, of course, it could be an extension mode of MAP = operation but, in practice, it makes the solution quite fuzzy, the code = quite heavy. we (me and my company) wouldn't like to have a standard = where supporting for both per-subscribe stateless and per-subscribe = stateful mappings should be done together within a monolithic = implementation. we support the lightweight 4over6 as an independent = standard.=20 >=20 Hmm, I've read 'draft-cui-softwire-b4-translated-ds-lite' as you called = 'lightweight 4over6'. LW46 for short, it looks me that MAP just provides = LW46 a provisioning means which would be described in the section 5, or = appendix section because following text described in section 5: "Other optional alternatives to retrieve the public address and port- set also exist. The specific protocol extensions are out of scope in this document, however some alternatives are mentioned in the Appendix section." I think that MAP and LW46 is in relation of mutual complement. MAP = doesn't obsolete LW46, and vice versa. Thought? cheers, --satoru= From mark@townsley.net Mon Jun 25 01:36: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 3E20721F84DD for ; Mon, 25 Jun 2012 01:36:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1KNXH4EUUga for ; Mon, 25 Jun 2012 01:36:24 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E54F21F8475 for ; Mon, 25 Jun 2012 01:36:23 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2551519wgb.13 for ; Mon, 25 Jun 2012 01:36:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=tuumT0u2lyQy7kG9MoUSITEhL9OfUUOJHKYKIwRdGoc=; b=TRN7LOQh52uhrhBAwl9817/VJGl8TAUYRkuD/iEk8qPtbBocPwaFap5DUP4T7X8HSz lEvoz5LwuwF4+4hnOS8ABVep6yP950p/pH2ms7NZQ6+D9EEpu5KaAJMc2VVrEFAy19m4 GJLc56CKeSAe0Uo/+tHLsFP89Tp7UVlQRl6AyPxUJQchYeprvR1sKPrlnJZvz4f7Tz01 0NmbY+MQJh/FH/51u5NF7twIOPdhsav55uSL7eVfSJv0MoEX8dll9yjoZllXTYfowRyE 3rp1vNyw59Fm8xNAUxuQ7FDnpts5zcLHBEnsDDXZUUblVOafwn4FZ80/z/AFPas3/aAj SJsw== Received: by 10.180.93.196 with SMTP id cw4mr22690949wib.11.1340613382492; Mon, 25 Jun 2012 01:36:22 -0700 (PDT) Received: from [10.105.213.114] ([92.90.20.48]) by mx.google.com with ESMTPS id t8sm15688008wiy.3.2012.06.25.01.36.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 01:36:21 -0700 (PDT) References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> In-Reply-To: <2012062514514640804415@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-C09FCC0E-5A7F-4AB3-AE68-1E5BC6D9775C Message-Id: <31C6EABE-E6CE-4422-8EF3-84A6A0EB8C7E@townsley.net> X-Mailer: iPhone Mail (9B206) From: Mark Townsley Date: Mon, 25 Jun 2012 10:35:46 +0200 To: "sunqi.csnet.thu" X-Gm-Message-State: ALoCoQmXn8FxrkNHVZ83NVh/YXjczWrCqm0Ex0O9O089gYLks8lclxq2VT/tPz8SrMMHKsUlIJ8e Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 08:36:28 -0000 --Apple-Mail-C09FCC0E-5A7F-4AB3-AE68-1E5BC6D9775C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A "map domain" that supports a single customer is no more "heavy" than a LW4= 6 mapping table entry that supports a single customer. You are comparing 100= 00000 of this vs. 10000000 of that, where this and that are effectively equa= l in terms of resources necessary for support.=20 There are a lot of people working on this same problem space, attacking it f= rom different directions. We are bound to run into one another, and that's w= hat is happening here. The more we can do to collapse the alternatives into f= ewer things with fewer fancy names, the better.=20 - Mark On Jun 25, 2012, at 8:51, "Qi Sun" wrote: > Hi Satoru, > =20 > In MAP 1:1 mode, if there are 10000000 subscribers, there would be 1000000= 0 MAP domains which a BR has to manage. I think that will create a huge mapp= ing table on the BR, which is called 'state' that stateful solutions deal wi= th. > =20 > Best Regards! > =20 > Qi Sun > =20 > From: Satoru Matsushima > Date: 2012-06-25 10:27 > To: Lee, Yiu > CC: softwires@ietf.org; Yong Cui > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT re= flect the consensus from the WG > Hi Yiu, > =20 > No, that's a misunderstanding. > Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber m= apping' in stateless manner, not to introduce 'per-flow NAT binding' or 'per= -subscriber state on demand'. > =20 > cheers, > --satoru > =20 > On 2012/06/25, at 2:32, Lee, Yiu wrote: > =20 > > Dear Satoru and MAP-DT > >=20 > > I echo what Peng and Qiong said. When the WG agreed working on the > > stateless solution, it was very clear stated that the solution would not= > > maintain states in the network. If the 1:1 mode changed this, this no > > longer matched the requirements stated in the stateless motivation draft= , > > thus, it would disqualify MAP as a solution for the motivation draft. > >=20 > > AFAIK, the MAP Design Team could propose a change, but such a dramatic > > change by introducing states in the network would require WG approval. I= > > would like the chairs to clarify this. > >=20 > > Thanks, > > Yiu > >=20 > >=20 > > On 6/24/12 12:21 PM, "Peng Wu" wrote: > >=20 > >> Hi Qiong, Satoru and all, > >>=20 > >> I should thank Qiong for pointing this out. I gotta say I'm a bit shock= ed. > >> If I understand the procedures of IETF correctly, a WG document should > >> reflect the consensus of the WG. MAP is approved by the WG as a > >> stateless solution. As a participator in Softwire, I didn't get the > >> information anywhere that the MAP WG document would cover the > >> so-called 1:1, in fact per-user stateful mode before it was released, > >> not to say discuss in the WG. Don't the WG need to approve such big > >> change anymore? > >>=20 > >> Now let me provide my impression as an outsider of the MAP DT. You > >> guys make great effort to build the solution, The address composition, > >> the GMA algorithm, the different types of address mapping rules. > >> should be quite difficult to pull together such sophisticated ideas. I > >> guess that's what it takes to achieve the benifits of statelessness. > >> And I admire that, bravo. Then, all of a sudden, you guys are saying, > >> let's apply this sophisticated method to the different problem, by > >> dropping quite some comlexity and twistting the mechanism a bit, seems > >> it may work. Considering the problem are now solved in a more pure and > >> clear way, I'm sorry but I CANNOT follow the logic here. > >>=20 > >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima > >> wrote: > >>> Hi Qiong, > >>>=20 > >>> I'm disagree with your opinion. > >>>=20 > >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in > >>> the DT. > >>> 2. MAP just covers so called '1:1 mode' with most granular mapping rul= e > >>> for CEs provisioning, which is as one of its characteristics. > >>> 3. The motivation draft does not restrict that as you stated, just > >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. > >>>=20 > >>> Best regards, > >>> --satoru > >>>=20 > >>>=20 > >>> On 2012/06/24, at 14:35, Qiong wrote: > >>>=20 > >>>> Hi all, > >>>>=20 > >>>> As we all know, once an individual draft is adopted as a WG draft, it= > >>>> is owned by the whole WG, rather than just the editors. Just as Remi > >>>> said, the normal procedure to follow is to reach WG consensus _before= _ > >>>> posting a newly edited version. > >>>>=20 > >>>> =46rom draft-mdt-softwire-mapping-address-and-port-03 to > >>>> draft-ietf-softwire-map-00, there are several changes between them. I= n > >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 and= > >>>> IPv6 addressing, has never been discussed openly in the WG mailing > >>>> list, or even in the MAP design team either. > >>>>=20 > >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation > >>>> draft. The motivation draft has clearly defines the "Stateless 4/6 > >>>> solution" as follows: > >>>>=20 > >>>> Stateless 4/6 solution denotes a solution which does not require any > >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by any= > >>>> IP address sharing function in the Service Provider's network. This > >>>> category of solutions assumes a dependency between an IPv6 prefix and= > >>>> IPv4 address. > >>>>=20 > >>>> AFAIK what the WG has adopted MAP related draft is > >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT > >>>> draft-ietf-softwire-map-00. And the stateless solution should =C2=B3r= esponse > >>>> to the solution motivation document=C2=B2 according to the Softwire c= harter. > >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG dra= ft. > >>>>=20 > >>>> We can all recall that our softwire WG has worked on stateless > >>>> solutions for more than one and a half years, and we have achieved a > >>>> lot of work which has been documented in charter, stateless motivatio= n, > >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic > >>>> "stateless" principle and the MAP design team is also working on it > >>>> together to find a better algorithm, address format, etc. So it is > >>>> really not appropriate to make such changes when MAP is adopted as a W= G > >>>> item in such a short time. > >>>>=20 > >>>> =46rom this perspective, draft-ietf-softwire-map-00 can only be regar= ded > >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even the > >>>> output of MAP design team. > >>>>=20 > >>>> Best wishes > >>>>=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/ > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 > >>>=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 > =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 --Apple-Mail-C09FCC0E-5A7F-4AB3-AE68-1E5BC6D9775C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

A "map domain" that su= pports a single customer is no more "heavy" than a LW46 mapping table entry t= hat supports a single customer. You are comparing 10000000 of this vs. 10000= 000 of that, where this and that are effectively equal in terms of resources= necessary for support. 

There are a lot of pe= ople working on this same problem space, attacking it from different directi= ons. We are bound to run into one another, and that's what is happening here= . The more we can do to collapse the alternatives into fewer things with few= er fancy names, the better. 

- Mark

On J= un 25, 2012, at 8:51, "Qi Sun" <sunqi.csnet.thu@gmail.com> wrote:

Hi Satoru,
 
In MAP 1:1 mode, if there are 10000000 subscribers, there would be 1000= 0000=20 MAP domains which a BR has to manage. I think that will create a huge mappin= g=20 table on the BR, which is called 'state' that stateful solutions deal=20 with.
 
Best Regards!
 
Qi Sun
 
Date: 2012-06-25 10:27
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map= -00=20 does NOT reflect the consensus from the WG
Hi Yiu,
 
No, that's a misunderstanding.
Current MAP specify the case for ea-len&n= bsp;is 'zero'. It is 'per-subscriber mapping' = in stateless manner, not to introduce 'per-flo= w NAT binding' or 'per-subscriber state on&nbs= p;demand'.
 
cheers,
--satoru
 
On 2012/06/25, at 2:32, Lee, Yiu wrote:
 
> Dear Satoru and MAP-DT
> 
> I echo what Peng and Qiong said= . When the WG agreed working on the
=
> stateless solution, it was very clea= r stated that the solution would not
> maintain states in the network. If&n= bsp;the 1:1 mode changed this, this no
> longer matched the requirements stated&nb= sp;in the stateless motivation draft,
> thus, it would disqualify MAP as&nbs= p;a solution for the motivation draft.
> 
> AFAIK, the MAP Design Team could&nbs= p;propose a change, but such a dramatic
> change by introducing states in the&= nbsp;network would require WG approval. I
> would like the chairs to clarify&nbs= p;this.
> 
> Thanks,
> Yiu
> 
> 
> On 6/24/12 12:21 PM, "Peng Wu" = <pengwu.thu@gmail.com>&nbs= p;wrote:
> 
>> Hi Qiong, Satoru and all,
>> 
>> I should thank Qiong for pointin= g this out. I gotta say I'm a bit&nb= sp;shocked.
>> If I understand the procedures o= f IETF correctly, a WG document should
>> reflect the consensus of the WG.=  MAP is approved by the WG as a
>> stateless solution. As a participator=  in Softwire, I didn't get the
>> information anywhere that the MAP&nbs= p;WG document would cover the
>> so-called 1:1, in fact per-user = stateful mode before it was released,
>> not to say discuss in the W= G. Don't the WG need to approve such = ;big
>> change anymore?
>> 
>> Now let me provide my impression=  as an outsider of the MAP DT. You
>> guys make great effort to build&= nbsp;the solution, The address composition,
>> the GMA algorithm, the different = ;types of address mapping rules.
>> should be quite difficult to pul= l together such sophisticated ideas. I
>> guess that's what it takes to&nb= sp;achieve the benifits of statelessness.
>> And I admire that, bravo. Then,&= nbsp;all of a sudden, you guys are saying= ,
>> let's apply this sophisticated method=  to the different problem, by
>> dropping quite some comlexity and&nbs= p;twistting the mechanism a bit, seems
>> it may work. Considering the pro= blem are now solved in a more pure a= nd
>> clear way, I'm sorry but I = CANNOT follow the logic here.
>> 
>> On Sun, Jun 24, 2012 at 2:0= 0 PM, Satoru Matsushima
>>> Hi Qiong,
>>> 
>>> I'm disagree with your opinion.
>>> 
>>> 1. Recent changes in draft-ietf-s= oftwire-map-00 has been discussed in
>>> the DT.
>>> 2. MAP just covers so called=  '1:1 mode' with most granular mapping ru= le
>>> for CEs provisioning, which is&nb= sp;as one of its characteristics.
>>> 3. The motivation draft does = ;not restrict that as you stated, just
>>> 'assumed', it's neither 'MUST' no= r 'SHOULD'.
>>> 
>>> Best regards,
>>> --satoru
>>> 
>>> 
>>> On 2012/06/24, at 14:35, Qiong&nb= sp;wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> As we all know, once an&= nbsp;individual draft is adopted as a WG = draft, it
>>>> is owned by the whole WG= , rather than just the editors. Just as&n= bsp;Remi
>>>> said, the normal procedure to=  follow is to reach WG consensus _before_=
>>>> posting a newly edited versio= n.
>>>> 
>>>> From draft-mdt-softwire-mapping-address-and-= port-03 to
>>>> draft-ietf-softwire-map-00, there are&n= bsp;several changes between them. In
>>>> particular, the newly introduced&n= bsp;"1:1 mode", which decouples IPv4 and
>>>> IPv6 addressing, has never be= en discussed openly in the WG mailing
>>>> list, or even in the MAP=  design team either.
>>>> 
>>>> Actually, this "1:1 mode" is&= nbsp;against the stateless-4v6-motivation
>>>> draft. The motivation draft h= as clearly defines the "Stateless 4/6
>>>> solution" as follows:
>>>> 
>>>> Stateless 4/6 solution denotes&nbs= p;a solution which does not require any
>>>> per-user state (see Section 2= .3 of [RFC1958]) to be maintained by any<= /div>
>>>> IP address sharing function i= n the Service Provider's network. This
>>>> category of solutions assumes = ;a dependency between an IPv6 prefix and
=
>>>> IPv4 address.
>>>> 
>>>> AFAIK what the WG has ad= opted MAP related draft is
>>>> draft-mdt-softwire-mapping-address-and-port-03,&n= bsp;NOT
>>>> draft-ietf-softwire-map-00. And the&nbs= p;stateless solution should =C2=B3response
>>>> to the solution motivation do= cument=C2=B2 according to the Softwire charter.
>>>> That means draft-ietf-softwire-map-00&n= bsp;IS NOT QUALIFIED to be a WG draft.
>>>> 
>>>> We can all recall that o= ur softwire WG has worked on stateless
>>>> solutions for more than one&n= bsp;and a half years, and we have achieve= d a
>>>> lot of work which has be= en documented in charter, stateless motivation,
>>>> 4rd-varients, MAP-03, etc. AFAIK&n= bsp;all the authors have kept the basic
>>>> "stateless" principle and the = ;MAP design team is also working on it
>>>> together to find a better&nbs= p;algorithm, address format, etc. So it is
>>>> really not appropriate to mak= e such changes when MAP is adopted as&nbs= p;a WG
>>>> item in such a short tim= e.
>>>> 
>>>> From this perspective, draft-ietf-= softwire-map-00 can only be regarded
>>>> as draft-XX-softwire-mapping-address-and-por= t-04. It is not even the
>>>> output of MAP design team.
>>>> 
>>>> Best wishes
>>>> 
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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&nbs= p;Institude
>>>> 
>>>> 
>>>> Open source code:
>>>> lightweight 4over6: http://sourceforge.net/projects/laft6/
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=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 mailing list
>> _______________________________________________
>> Softwires mailing list
 
_______________________________________________
Softwires mailing list
____________________= ___________________________
Softwires mailing listSoftwires@ietf.orghttps://= www.ietf.org/mailman/listinfo/softwires
= --Apple-Mail-C09FCC0E-5A7F-4AB3-AE68-1E5BC6D9775C-- From pengwu.thu@gmail.com Mon Jun 25 01: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 C724721F8480 for ; Mon, 25 Jun 2012 01:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcQb76U-oNmI for ; Mon, 25 Jun 2012 01:37:53 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3056B21F848A for ; Mon, 25 Jun 2012 01:37:53 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2084949qcm.15 for ; Mon, 25 Jun 2012 01:37:52 -0700 (PDT) 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:content-transfer-encoding; bh=/Q37B4cs9Z4ySXz9OK/9GaYfDNF9qjDB0v5hHDUobdE=; b=hJra6hdVv09KQ83sDx6Brdvmu7OtlYQBxqQrByT/13YGyDSGxgXnk5ZZvRSSA9f2fz vloF+INo1tS4r7onWLdS9lACdZMJHlYFCeRWmhKD+H6Cmvxvx6tvgcQM9lDp6gztrEDy +eQpN1GI9PTMfuYKqEqTxmI9cw+3Wa9APkTNsDeVSxaQZHO/r1oBjdw7jqyYNzJtcbII KfGZvvoQIp2zIV3y+RW64mAjq8sBpdhNx2kIrbOjS/qJ2v3W1jW/tnZqyUL3dSL9VgSG EDvDnk+p8GWcIRpZWdkXS23CJLJbKeqBd80T1/N1NGsys4kmudtqvXzZUlvBMWcWKvgB YYRA== MIME-Version: 1.0 Received: by 10.229.135.140 with SMTP id n12mr3674344qct.139.1340613472469; Mon, 25 Jun 2012 01:37:52 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Mon, 25 Jun 2012 01:37:52 -0700 (PDT) In-Reply-To: <07698BA1-CBEE-45E3-9CE2-B0ED530EFE93@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <07698BA1-CBEE-45E3-9CE2-B0ED530EFE93@gmail.com> Date: Mon, 25 Jun 2012 16:37:52 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 08:37:57 -0000 Hi Satoru, On Mon, Jun 25, 2012 at 2:59 PM, Satoru Matsushima wrote: > Hi Qiong, > > On 2012/06/25, at 15:06, Qiong wrote: > >> Hi Satoru, >> >> Would you please point out in which presentation in the Beijing Interim = meeting illustrated "per-subscriber mapping" as one characteristic of MAP s= olution? I recall which xiaohong presented was a stateful one. > > Please find it out on page 14 from following url: > > http://www.ietf.org/proceedings/82/slides/softwire-2.pdf I think that's not what Alain meant. If you look back and forth a bit, you can see that: B1 stands for per-subscriber stateufl/mapping/binding... B2 stand for stateless Hub & Spoke (in MAP case, FMRs not provisoned to CE) B3 stand for stateless Mesh (in MAP case, FMRs provisoned to CE) The confusion comes from the use of per-=ADsubscriber in the slides. It's not the sementic we took in this thread. > > cheers, > --satoru > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From mark@townsley.net Mon Jun 25 01:40: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 2FB5921F8480 for ; Mon, 25 Jun 2012 01:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yMIdM+QOIxH for ; Mon, 25 Jun 2012 01:40:01 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD88A21F84D6 for ; Mon, 25 Jun 2012 01:40:00 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2553501wgb.13 for ; Mon, 25 Jun 2012 01:40:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=OpwcE8HmLTjvgSLX9ZqSHGJkegPCBgxksPjaV85ppP0=; b=KMHBMNeC1Qg23+xahWIphq+dJcmByoh7Xn7HMrx9hh5TPq0OtmVV3FQoW+gzm3q3vT rJoMmTClBQ/3iNALBtoq07r765h7ho5bSMvRW6XlTgdz5VSfEl6FKGEICGx1uLKvvjfc yjVDYifL25VZ2v/qwr5a1/e39/nE7Gs5gfQ4aGkWhQtgS+dCzhzOXYUqwtyarKnBoX5P 6O1hP6qLqVgL9pmfH4ACk2r+fjWso6lWbdnoNhdtaFvKk07W2RWy/FgS/GiIMMR84o46 WqSRgkgZiI98EO4zmOSjXGyZH0iGNPegkPu1OFfmWu0aX4XyvvlCDRxgr/pgZ561jeO1 ubjA== Received: by 10.216.194.196 with SMTP id m46mr6201189wen.197.1340613599698; Mon, 25 Jun 2012 01:39:59 -0700 (PDT) Received: from [10.105.213.114] ([92.90.20.48]) by mx.google.com with ESMTPS id z8sm31732268wiy.1.2012.06.25.01.39.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 01:39:58 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <74609DDF-FBDA-4F3D-89E0-01D46683B51C@townsley.net> X-Mailer: iPhone Mail (9B206) From: Mark Townsley Date: Mon, 25 Jun 2012 10:39:53 +0200 To: Tetsuya Murakami X-Gm-Message-State: ALoCoQmxio+rvgzcSxjdrISTPe9TElbXYY+ASqZ3Q57jEyn9NVVJg8qiq/SV4NNDrTWKsaGF1IgD Cc: Softwires WG , Ole Troan , Yong Cui , Ralph Droms Subject: Re: [Softwires] A new consensus opportunity with a MAP-bis 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, 25 Jun 2012 08:40:05 -0000 If we can find a way to collapse H and T such that we are back to one "encap= /decap" and one "entrans/detrans" version, I think this would be significant= progress. 3 options here just seems ridiculous though.=20 - Mark On Jun 25, 2012, at 8:24, Tetsuya Murakami = wrote: > +1. >=20 > Making another new document might cause more confusion. But if 4rd work is= stopped and merged to MAP, it might be good. But from the implementation po= int of view, I would like to eliminate the complicated code as much as possi= ble such as >=20 > if (MAP-E) > ... > else if (MAP-T) > ... > else if (MAP-H) > ... >=20 > But this is the implementation/deployment choice. So, from the standard pe= rspective, it might be good to merge H solution to MAP which has already mer= ged both E and T. >=20 > Thanks, > Tetsuya Murakami >=20 > On 2012/06/23, at 1:52, Satoru Matsushima wrote: >=20 >> Dear Remi, >>=20 >> Thank you for a kind offer. It would be a very positive compromise for us= . >>=20 >> However, in the context of making another new stream document, which MAP-= bis as you said, I decline it. Nevertheless, if you abandon 4rd work, I'm ve= ry welcome you as an author of MAP. >>=20 >> Best regards, >> --satoru >>=20 >> On 2012/06/23, at 1:52, R=C3=A9mi Despr=C3=A9s wrote: >>=20 >>> Yong, Suresh, Ralph, >>>=20 >>> For mesh stateless v4/v6, we have so far a choice between only two solut= ions, MAP as is and 4rd. >>> On can hope that the consensus that couldn't be reached in Paris will be= achievable in Vancouver, but this isn't sure, each "camp" keeping its own e= xpectation. >>>=20 >>> Looking at recent history, we can remember that, not long ago, the chair= 's approach was to have 3 specifications completed (MAP-T, MAP-E, and MAP-H,= as Alain called it with H for Hybrid), and then to choose only one for stan= dardization. >>>=20 >>> After that, promoters of either -T and -E decided to merge -T and -E in a= non-separable specification, as reflected in draft-ietf-softwire-map-00.=20= >>> Thus, the choice has become between a "two-variants" specification (MAP)= and a "single-variant" specification (4rd). >>>=20 >>> In this context, a larger choice might well be the best chance for a WG c= onsensus. It would include a MAP specification in which the forwarding mode o= f 4rd would be added as 3rd, say a "MAP-bis" .=20 >>> With this MAP-bis: >>> - vendors have to support 3 forwarding modes, which isn't ideal, but mos= t of the design, in particular in what concerns mapping rules, remains commo= n (Alain once said, possibly with optimism, the three were 99% identical!)=20= >>> - operators have a free choice between T, E, or H, based on their operat= ional preferences. >>> - we have (at last) a stabilized design with no one badly frustrated. >>>=20 >>> If this approach makes sense for the WG, I can do the work of editing a M= AP-bis proposal (taking the current MAP specification, adding a section that= describes the hybrid forwarding mode, and adding a third variant in the add= ress-format section).=20 >>>=20 >>> My personal preference remains for 4rd as single standard, but a choice b= etween MAP-as-is, MAP-bis, and 4rd, is IMHO a sounder choice for the WG than= just between MAP-as-is and 4rd. >>>=20 >>> Hoping that this will be found constructive, >>> Best regards, >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From pengwu.thu@gmail.com Mon Jun 25 01:50:56 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 9F7B821F84DF for ; Mon, 25 Jun 2012 01:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2zXPufcJapj for ; Mon, 25 Jun 2012 01:50:52 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0D121F84D8 for ; Mon, 25 Jun 2012 01:50:52 -0700 (PDT) Received: by qabj34 with SMTP id j34so1155454qab.4 for ; Mon, 25 Jun 2012 01:50:51 -0700 (PDT) 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:content-transfer-encoding; bh=3ccqLO3PXR7KB46ViJG9PG62QMs4GcjIg8PfN27fP5Y=; b=R//qIc6/Iqj+0YTKpx4C9ytkOj27KJ3vhfV7cs51JhTOch1fVYd7W6J5HsZOu9l3kT xrtLa87R0FefChLWUlpXcOHELHnQ8h0MhEbFsi6mdOW/XRPBRvOnLvA78C4VrZVAQAXn 87wh8R6b9/qlN0rxxNZgzz2t125ZKeCrGIGJ8Ajp2Pt8vpwlhapdD/Ah3dn5CDnP7qKt 85bZqph/QFkVi5+cNO/lvQQ/M1XnrA6dRXccO9xvUMrZnZlvdYhiYdRCn5u2EDmQIY2t x+CMvq76PNJpvMPMn3KWy18cA90JX3hq6eRFwES2XFhcOOvbLTxQYU+xHmqmowz7vhg1 chAQ== MIME-Version: 1.0 Received: by 10.224.176.148 with SMTP id be20mr19577706qab.64.1340614251703; Mon, 25 Jun 2012 01:50:51 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Mon, 25 Jun 2012 01:50:51 -0700 (PDT) In-Reply-To: <97A4D74A-A531-4F83-B281-86973A3139A5@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <97A4D74A-A531-4F83-B281-86973A3139A5@gmail.com> Date: Mon, 25 Jun 2012 16:50:51 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 08:50:56 -0000 Satoru, On Mon, Jun 25, 2012 at 3:18 PM, Satoru Matsushima wrote: > Hi Maoke-san, > > On 2012/06/25, at 12:07, Maoke wrote: > >> hi Satoru-san, Qiong, and all, >> >> i think the current 1:1 mode text of the draft should be tuned or, it wo= uld be better, to be removed. >> >> technically, i expect MAP as a completely per-session, per-subscriber st= ateless solution and therefore per-subscriber mapping rule is not accepted.= in theory, of course, it could be an extension mode of MAP operation but, = in practice, it makes the solution quite fuzzy, the code quite heavy. we (m= e and my company) wouldn't like to have a standard where supporting for bot= h per-subscribe stateless and per-subscribe stateful mappings should be don= e together within a monolithic implementation. we support the lightweight 4= over6 as an independent standard. >> > > Hmm, I've read 'draft-cui-softwire-b4-translated-ds-lite' as you called '= lightweight 4over6'. LW46 for short, it looks me that MAP just provides LW4= 6 a provisioning means which would be described in the section 5, or append= ix section because following text described in section 5: > > "Other optional alternatives to retrieve the public address and port- > =A0set also exist. =A0The specific protocol extensions are out of scope i= n > =A0this document, however some alternatives are mentioned in the Appendix > =A0section." Let me take a step further following your direction: You are saying MAP is a provisioning mean in lw4over6. Then, what exactly? With IPv4-IPv6 addressing independency, you proivde an IPv4 address and port set, within another DHCPv6 option? No BMR, No FMR, No embedding address. Look at what's left. how is this even similar to MAP? > > I think that MAP and LW46 is in relation of mutual complement. MAP doesn'= t obsolete LW46, and vice versa. > Thought? > > cheers, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Mon Jun 25 01:52: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 2363521F846A for ; Mon, 25 Jun 2012 01:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXbcnQOq4f6f for ; Mon, 25 Jun 2012 01:52:53 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2357B21F846E for ; Mon, 25 Jun 2012 01:52:53 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6322038pbc.31 for ; Mon, 25 Jun 2012 01:52:53 -0700 (PDT) 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=azqPru1Kj+fTRoblgIuuFCyl/2MDrjN0Isv821G2nTU=; b=ZtND+gpmvjqF80PMcSpK5NImODcT5RiraJzKZcJKG8WGu4uzsw1apb9ADFgXJPA3Ra R1ET5UJCtMxY1R7p/B/wesbRx845iHTjR0jDTcnOKBuhEJhR2QK7yd9mCJniBdMvCg1u ggk4t4TugcYmWg2CQeDFnwSCMKdGvQS4nvcimDdSvfUGUNim4sPL1EwkZyf94w1FAqZG +r+S0k748IVDgSdldfOGWdkRUJy7u5lEcTyZUgHbVpXC9NxxFW3pIBNMsSo/S3uxGJQM JDq3y0HNnUC4yEw9iv3xxt/2eKvX/KpjIQB2frenOHxQZgaHsV8WRVDYtl+OH1gg7TyT eFMg== Received: by 10.68.221.227 with SMTP id qh3mr37887474pbc.115.1340614372985; Mon, 25 Jun 2012 01:52:52 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id ok6sm7919851pbb.29.2012.06.25.01.52.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 01:52:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 17:52:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <68F1620B-02AC-4AC0-8B3F-A9FE2620BBB3@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <07698BA1-CBEE-45E3-9CE2-B0ED530EFE93@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 08:52:57 -0000 Hi Peng, On 2012/06/25, at 17:37, Peng Wu wrote: >> Please find it out on page 14 from following url: >>=20 >> http://www.ietf.org/proceedings/82/slides/softwire-2.pdf >=20 > I think that's not what Alain meant. If you look back and forth a bit, > you can see that: > B1 stands for per-subscriber stateufl/mapping/binding... > B2 stand for stateless Hub & Spoke (in MAP case, FMRs not provisoned = to CE) > B3 stand for stateless Mesh (in MAP case, FMRs provisoned to CE) > The confusion comes from the use of per-=ADsubscriber in the slides. > It's not the sementic we took in this thread. What's the differences from the semantics in this thread? Since per-subscriber mapping operation should naturally be a = hub-and-spoke means, it is just a case of stateless solution operation. cheers, --satoru= From pengwu.thu@gmail.com Mon Jun 25 01:56: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 A774021F846E for ; Mon, 25 Jun 2012 01:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N-LWAmUrhyS for ; Mon, 25 Jun 2012 01:56:29 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 481DF21F846A for ; Mon, 25 Jun 2012 01:56:29 -0700 (PDT) Received: by qabj34 with SMTP id j34so1158224qab.4 for ; Mon, 25 Jun 2012 01:56:28 -0700 (PDT) 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:content-transfer-encoding; bh=itL3yJP13uaFL8pPaA0t6jUN6gjGNce+8mzGerPoiTw=; b=b0RQYTtqsdQrnZ8fOCK414kSz4fZPPnq8QFtp/sO2inMyihFjzOGIqVZeI2hHJab4V gNWxvpv2O/iWQ1uJGoFq3Q/7gILK9p7iGPWfkdLDseiS0XPFlX3mjMXGxi1srHRrwgLw SMEgbo/0tC84exQHlJM1qnRtistEsvOktk9cXXBxgNX8XBlMgOnYPKNAaQz9D3aLzFQ9 VeDAAG6lVfqSskEAV/bMeg3LLP/WawZOg60cPYj1f5NrTb1O29TxYGht5kPDX24K5rwC 3vMIAZOGXMlIFccyr1Om6c/eDFkFtPgG6QWmieu/nouzP531faRQCbyovp1NzR7I8Hbh +DuA== MIME-Version: 1.0 Received: by 10.224.207.4 with SMTP id fw4mr19512880qab.82.1340614588729; Mon, 25 Jun 2012 01:56:28 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Mon, 25 Jun 2012 01:56:28 -0700 (PDT) In-Reply-To: <31C6EABE-E6CE-4422-8EF3-84A6A0EB8C7E@townsley.net> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <31C6EABE-E6CE-4422-8EF3-84A6A0EB8C7E@townsley.net> Date: Mon, 25 Jun 2012 16:56:28 +0800 Message-ID: From: Peng Wu To: Mark Townsley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 08:56:33 -0000 Mark, On Mon, Jun 25, 2012 at 4:35 PM, Mark Townsley wrote: > > A "map domain" that supports a single customer is no more "heavy" than a > LW46 mapping table entry that supports a single customer. You are compari= ng > 10000000 of this vs. 10000000 of that, where this and that are effectivel= y > equal in terms of resources necessary for support. I think the point is not comparison between the two. The point is MAP loses its essential STATELESS feature in this case > > There are a lot of people working on this same problem space, attacking i= t > from different directions. We are bound to run into one another, and that= 's > what is happening here. The more we can do to collapse the alternatives i= nto > fewer things with fewer fancy names, the better. One targets at the problem directly while the other not developed originally for the case and later twisted to fit the problem space, with loss of its essential feature. > > - Mark > > On Jun 25, 2012, at 8:51, "Qi Sun" wrote: > > Hi Satoru, > > In MAP 1:1 mode, if there are 10000000 subscribers, there would be 100000= 00 > MAP domains which a BR has to manage. I think that will create a huge > mapping table on the BR, which is called 'state' that stateful solutions > deal with. > > Best Regards! > > ________________________________ > Qi Sun > > From:=A0Satoru Matsushima > Date:=A02012-06-25=A010:27 > To:=A0Lee, Yiu > CC:=A0softwires@ietf.org; Yong Cui > Subject:=A0Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT > reflect the consensus from the WG > Hi=A0Yiu, > > No,=A0that's=A0a=A0misunderstanding. > Current=A0MAP=A0specify=A0the=A0case=A0for=A0ea-len=A0is=A0'zero'.=A0It= =A0is=A0'per-subscriber=A0mapping'=A0in=A0stateless=A0manner,=A0not=A0to=A0= introduce=A0'per-flow=A0NAT=A0binding'=A0or=A0'per-subscriber=A0state=A0on= =A0demand'. > > cheers, > --satoru > > On=A02012/06/25,=A0at=A02:32,=A0Lee,=A0Yiu=A0wrote: > >>=A0Dear=A0Satoru=A0and=A0MAP-DT >> >>=A0I=A0echo=A0what=A0Peng=A0and=A0Qiong=A0said.=A0When=A0the=A0WG=A0agree= d=A0working=A0on=A0the >>=A0stateless=A0solution,=A0it=A0was=A0very=A0clear=A0stated=A0that=A0the= =A0solution=A0would=A0not >>=A0maintain=A0states=A0in=A0the=A0network.=A0If=A0the=A01:1=A0mode=A0chan= ged=A0this,=A0this=A0no >>=A0longer=A0matched=A0the=A0requirements=A0stated=A0in=A0the=A0stateless= =A0motivation=A0draft, >>=A0thus,=A0it=A0would=A0disqualify=A0MAP=A0as=A0a=A0solution=A0for=A0the= =A0motivation=A0draft. >> >>=A0AFAIK,=A0the=A0MAP=A0Design=A0Team=A0could=A0propose=A0a=A0change,=A0b= ut=A0such=A0a=A0dramatic >>=A0change=A0by=A0introducing=A0states=A0in=A0the=A0network=A0would=A0requ= ire=A0WG=A0approval.=A0I >>=A0would=A0like=A0the=A0chairs=A0to=A0clarify=A0this. >> >>=A0Thanks, >>=A0Yiu >> >> >>=A0On=A06/24/12=A012:21=A0PM,=A0"Peng=A0Wu"=A0=A0wr= ote: >> >>>=A0Hi=A0Qiong,=A0Satoru=A0and=A0all, >>> >>>=A0I=A0should=A0thank=A0Qiong=A0for=A0pointing=A0this=A0out.=A0I=A0gotta= =A0say=A0I'm=A0a=A0bit=A0shocked. >>>=A0If=A0I=A0understand=A0the=A0procedures=A0of=A0IETF=A0correctly,=A0a= =A0WG=A0document=A0should >>>=A0reflect=A0the=A0consensus=A0of=A0the=A0WG.=A0MAP=A0is=A0approved=A0by= =A0the=A0WG=A0as=A0a >>>=A0stateless=A0solution.=A0As=A0a=A0participator=A0in=A0Softwire,=A0I=A0= didn't=A0get=A0the >>>=A0information=A0anywhere=A0that=A0the=A0MAP=A0WG=A0document=A0would=A0c= over=A0the >>>=A0so-called=A01:1,=A0in=A0fact=A0per-user=A0stateful=A0mode=A0before=A0= it=A0was=A0released, >>>=A0not=A0to=A0say=A0discuss=A0in=A0the=A0WG.=A0Don't=A0the=A0WG=A0need= =A0to=A0approve=A0such=A0big >>>=A0change=A0anymore? >>> >>>=A0Now=A0let=A0me=A0provide=A0my=A0impression=A0as=A0an=A0outsider=A0of= =A0the=A0MAP=A0DT.=A0You >>>=A0guys=A0make=A0great=A0effort=A0to=A0build=A0the=A0solution,=A0The=A0a= ddress=A0composition, >>>=A0the=A0GMA=A0algorithm,=A0the=A0different=A0types=A0of=A0address=A0map= ping=A0rules. >>>=A0should=A0be=A0quite=A0difficult=A0to=A0pull=A0together=A0such=A0sophi= sticated=A0ideas.=A0I >>>=A0guess=A0that's=A0what=A0it=A0takes=A0to=A0achieve=A0the=A0benifits=A0= of=A0statelessness. >>>=A0And=A0I=A0admire=A0that,=A0bravo.=A0Then,=A0all=A0of=A0a=A0sudden,=A0= you=A0guys=A0are=A0saying, >>>=A0let's=A0apply=A0this=A0sophisticated=A0method=A0to=A0the=A0different= =A0problem,=A0by >>>=A0dropping=A0quite=A0some=A0comlexity=A0and=A0twistting=A0the=A0mechani= sm=A0a=A0bit,=A0seems >>>=A0it=A0may=A0work.=A0Considering=A0the=A0problem=A0are=A0now=A0solved= =A0in=A0a=A0more=A0pure=A0and >>>=A0clear=A0way,=A0I'm=A0sorry=A0but=A0I=A0CANNOT=A0follow=A0the=A0logic= =A0here. >>> >>>=A0On=A0Sun,=A0Jun=A024,=A02012=A0at=A02:00=A0PM,=A0Satoru=A0Matsushima >>>=A0=A0wrote: >>>>=A0Hi=A0Qiong, >>>> >>>>=A0I'm=A0disagree=A0with=A0your=A0opinion. >>>> >>>>=A01.=A0Recent=A0changes=A0in=A0draft-ietf-softwire-map-00=A0has=A0been= =A0discussed=A0in >>>>=A0the=A0DT. >>>>=A02.=A0MAP=A0just=A0covers=A0so=A0called=A0'1:1=A0mode'=A0with=A0most= =A0granular=A0mapping=A0rule >>>>=A0for=A0CEs=A0provisioning,=A0which=A0is=A0as=A0one=A0of=A0its=A0chara= cteristics. >>>>=A03.=A0The=A0motivation=A0draft=A0does=A0not=A0restrict=A0that=A0as=A0= you=A0stated,=A0just >>>>=A0'assumed',=A0it's=A0neither=A0'MUST'=A0nor=A0'SHOULD'. >>>> >>>>=A0Best=A0regards, >>>>=A0--satoru >>>> >>>> >>>>=A0On=A02012/06/24,=A0at=A014:35,=A0Qiong=A0wrote: >>>> >>>>>=A0Hi=A0all, >>>>> >>>>>=A0As=A0we=A0all=A0know,=A0once=A0an=A0individual=A0draft=A0is=A0adopt= ed=A0as=A0a=A0WG=A0draft,=A0it >>>>>=A0is=A0owned=A0by=A0the=A0whole=A0WG,=A0rather=A0than=A0just=A0the=A0= editors.=A0Just=A0as=A0Remi >>>>>=A0said,=A0the=A0normal=A0procedure=A0to=A0follow=A0is=A0to=A0reach=A0= WG=A0consensus=A0_before_ >>>>>=A0posting=A0a=A0newly=A0edited=A0version. >>>>> >>>>>=A0From=A0draft-mdt-softwire-mapping-address-and-port-03=A0to >>>>>=A0draft-ietf-softwire-map-00,=A0there=A0are=A0several=A0changes=A0bet= ween=A0them.=A0In >>>>>=A0particular,=A0the=A0newly=A0introduced=A0"1:1=A0mode",=A0which=A0de= couples=A0IPv4=A0and >>>>>=A0IPv6=A0addressing,=A0has=A0never=A0been=A0discussed=A0openly=A0in= =A0the=A0WG=A0mailing >>>>>=A0list,=A0or=A0even=A0in=A0the=A0MAP=A0design=A0team=A0either. >>>>> >>>>>=A0Actually,=A0this=A0"1:1=A0mode"=A0is=A0against=A0the=A0stateless-4v= 6-motivation >>>>>=A0draft.=A0The=A0motivation=A0draft=A0has=A0clearly=A0defines=A0the= =A0"Stateless=A04/6 >>>>>=A0solution"=A0as=A0follows: >>>>> >>>>>=A0Stateless=A04/6=A0solution=A0denotes=A0a=A0solution=A0which=A0does= =A0not=A0require=A0any >>>>>=A0per-user=A0state=A0(see=A0Section=A02.3=A0of=A0[RFC1958])=A0to=A0be= =A0maintained=A0by=A0any >>>>>=A0IP=A0address=A0sharing=A0function=A0in=A0the=A0Service=A0Provider's= =A0network.=A0This >>>>>=A0category=A0of=A0solutions=A0assumes=A0a=A0dependency=A0between=A0an= =A0IPv6=A0prefix=A0and >>>>>=A0IPv4=A0address. >>>>> >>>>>=A0AFAIK=A0what=A0the=A0WG=A0has=A0adopted=A0MAP=A0related=A0draft=A0i= s >>>>>=A0draft-mdt-softwire-mapping-address-and-port-03,=A0NOT >>>>>=A0draft-ietf-softwire-map-00.=A0And=A0the=A0stateless=A0solution=A0sh= ould=A0=B3response >>>>>=A0to=A0the=A0solution=A0motivation=A0document=B2=A0according=A0to=A0t= he=A0Softwire=A0charter. >>>>>=A0That=A0means=A0draft-ietf-softwire-map-00=A0IS=A0NOT=A0QUALIFIED=A0= to=A0be=A0a=A0WG=A0draft. >>>>> >>>>>=A0We=A0can=A0all=A0recall=A0that=A0our=A0softwire=A0WG=A0has=A0worked= =A0on=A0stateless >>>>>=A0solutions=A0for=A0more=A0than=A0one=A0and=A0a=A0half=A0years,=A0and= =A0we=A0have=A0achieved=A0a >>>>>=A0lot=A0of=A0work=A0which=A0has=A0been=A0documented=A0in=A0charter,= =A0stateless=A0motivation, >>>>>=A04rd-varients,=A0MAP-03,=A0etc.=A0AFAIK=A0all=A0the=A0authors=A0have= =A0kept=A0the=A0basic >>>>>=A0"stateless"=A0principle=A0and=A0the=A0MAP=A0design=A0team=A0is=A0al= so=A0working=A0on=A0it >>>>>=A0together=A0to=A0find=A0a=A0better=A0algorithm,=A0address=A0format,= =A0etc.=A0So=A0it=A0is >>>>>=A0really=A0not=A0appropriate=A0to=A0make=A0such=A0changes=A0when=A0MA= P=A0is=A0adopted=A0as=A0a=A0WG >>>>>=A0item=A0in=A0such=A0a=A0short=A0time. >>>>> >>>>>=A0From=A0this=A0perspective,=A0draft-ietf-softwire-map-00=A0can=A0onl= y=A0be=A0regarded >>>>>=A0as=A0draft-XX-softwire-mapping-address-and-port-04.=A0It=A0is=A0not= =A0even=A0the >>>>>=A0output=A0of=A0MAP=A0design=A0team. >>>>> >>>>>=A0Best=A0wishes >>>>> >>>>>=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=A0Qiong=A0Sun >>>>>=A0China=A0Telecom=A0Beijing=A0Research=A0Institude >>>>> >>>>> >>>>>=A0Open=A0source=A0code: >>>>>=A0lightweight=A04over6:=A0http://sourceforge.net/projects/laft6/ >>>>>=A0PCP-natcoord:=A0http://sourceforge.net/projects/pcpportsetdemo/ >>>>>=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>> >>>>> >>>>>=A0_______________________________________________ >>>>>=A0Softwires=A0mailing=A0list >>>>>=A0Softwires@ietf.org >>>>>=A0https://www.ietf.org/mailman/listinfo/softwires >>>> >>>>=A0_______________________________________________ >>>>=A0Softwires=A0mailing=A0list >>>>=A0Softwires@ietf.org >>>>=A0https://www.ietf.org/mailman/listinfo/softwires >>>=A0_______________________________________________ >>>=A0Softwires=A0mailing=A0list >>>=A0Softwires@ietf.org >>>=A0https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires=A0mailing=A0list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > 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 bingxuere@gmail.com Mon Jun 25 02:03: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 11BAF21F84C8 for ; Mon, 25 Jun 2012 02:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BaQtShuEAuw for ; Mon, 25 Jun 2012 02:03:03 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E08B21F84B6 for ; Mon, 25 Jun 2012 02:03:03 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2883056ggn.31 for ; Mon, 25 Jun 2012 02:03:03 -0700 (PDT) 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=hqoVUq1eHq0KTKvSGFhE7UEF4JKrcIfpDzt9B6wAZGo=; b=NDjaMWIJlRHEij3SzqpSR/rifLU0PKBSfLkVQSWB0LpO7aVPgNhlPgslGBEINzoE9H 0fWNuKQp4JNWAQp5xOHoX0gdpYMsFf89ev49JseW6Iez0r/zi+rplPZKXq38agYQyeWe WSI/gBgw7IrbSNRSKtiVCA0xnbvaQj1DzdECIx/2qQqa4MjxLrmv24GR07jPH+88X8Pl OFPnUxN+KM2Ot8zcYOR67NF1v9OIIfm2eFghIbRi7J8+B3pRGk9WzEPFd9cNZlDL/okf Mdu/n4dJHu59xX2r/dpzIfZaQxU7rUfyB01c2G+R7X8+EN+WQmovLFxA4immWQ5wxoE5 gHvg== Received: by 10.50.208.106 with SMTP id md10mr7589248igc.54.1340614982686; Mon, 25 Jun 2012 02:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Mon, 25 Jun 2012 02:02:22 -0700 (PDT) In-Reply-To: <6D03A23F-DB70-43FC-A043-88DE7521D534@gmail.com> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <6D03A23F-DB70-43FC-A043-88DE7521D534@gmail.com> From: Qiong Date: Mon, 25 Jun 2012 17:02:22 +0800 Message-ID: To: Satoru Matsushima Content-Type: multipart/alternative; boundary=14dae9340881d2d74b04c3483fa6 Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:03:08 -0000 --14dae9340881d2d74b04c3483fa6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Satoru, It is not only about the exact number of mapping rules, but also the dynamic feature of it. For the number of mapping rules, it is obviously its objective to keep the least number of mapping rules in stateless solution. See section 3.1.1 in the motivation draft: 3.1.1. Network Dimensioning Because no per-user state [RFC1958] is required, a stateless solution does not need to take into account the maximum number of simultaneous user-sessions and the maximum number of new user-sessions per second to dimension its networking equipment. Like current network dimensioning practices, only considerations related to the customers number, traffic trends and the bandwidth usage need be taken into account. Does it still fit for 1:1 mapping mode ? On Mon, Jun 25, 2012 at 3:01 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hi Qiong, > > A MAP domain can have several/some/many mapping rules in the domain. How > many is threshold for either stateless or stateful? > > cheers, > --satoru > > On 2012/06/25, at 15:51, Qi Sun wrote: > > > Hi Satoru, > > > > In MAP 1:1 mode, if there are 10000000 subscribers, there would be > 10000000 MAP domains which a BR has to manage. I think that will create a > huge mapping table on the BR, which is called 'state' that stateful > solutions deal with. > > > > Best Regards! > > > > Qi Sun > > > > From: Satoru Matsushima > > Date: 2012-06-25 10:27 > > To: Lee, Yiu > > CC: softwires@ietf.org; Yong Cui > > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT > reflect the consensus from the WG > > Hi Yiu, > > > > No, that's a misunderstanding. > > Current MAP specify the case for ea-len is 'zero'. It is 'per-subscribe= r > mapping' in stateless manner, not to introduce 'per-flow NAT binding' or > 'per-subscriber state on demand'. > > > > cheers, > > --satoru > > > > On 2012/06/25, at 2:32, Lee, Yiu wrote: > > > > > Dear Satoru and MAP-DT > > > > > > I echo what Peng and Qiong said. When the WG agreed working on the > > > stateless solution, it was very clear stated that the solution would > not > > > maintain states in the network. If the 1:1 mode changed this, this no > > > longer matched the requirements stated in the stateless motivation > draft, > > > thus, it would disqualify MAP as a solution for the motivation draft. > > > > > > AFAIK, the MAP Design Team could propose a change, but such a dramati= c > > > change by introducing states in the network would require WG approval= . > I > > > would like the chairs to clarify this. > > > > > > Thanks, > > > Yiu > > > > > > > > > On 6/24/12 12:21 PM, "Peng Wu" wrote: > > > > > >> Hi Qiong, Satoru and all, > > >> > > >> I should thank Qiong for pointing this out. I gotta say I'm a bit > shocked. > > >> If I understand the procedures of IETF correctly, a WG document shou= ld > > >> reflect the consensus of the WG. MAP is approved by the WG as a > > >> stateless solution. As a participator in Softwire, I didn't get the > > >> information anywhere that the MAP WG document would cover the > > >> so-called 1:1, in fact per-user stateful mode before it was released= , > > >> not to say discuss in the WG. Don't the WG need to approve such big > > >> change anymore? > > >> > > >> Now let me provide my impression as an outsider of the MAP DT. You > > >> guys make great effort to build the solution, The address compositio= n, > > >> the GMA algorithm, the different types of address mapping rules. > > >> should be quite difficult to pull together such sophisticated ideas.= I > > >> guess that's what it takes to achieve the benifits of statelessness. > > >> And I admire that, bravo. Then, all of a sudden, you guys are saying= , > > >> let's apply this sophisticated method to the different problem, by > > >> dropping quite some comlexity and twistting the mechanism a bit, see= ms > > >> it may work. Considering the problem are now solved in a more pure a= nd > > >> clear way, I'm sorry but I CANNOT follow the logic here. > > >> > > >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima > > >> wrote: > > >>> Hi Qiong, > > >>> > > >>> I'm disagree with your opinion. > > >>> > > >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed = in > > >>> the DT. > > >>> 2. MAP just covers so called '1:1 mode' with most granular mapping > rule > > >>> for CEs provisioning, which is as one of its characteristics. > > >>> 3. The motivation draft does not restrict that as you stated, just > > >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. > > >>> > > >>> Best regards, > > >>> --satoru > > >>> > > >>> > > >>> On 2012/06/24, at 14:35, Qiong wrote: > > >>> > > >>>> Hi all, > > >>>> > > >>>> As we all know, once an individual draft is adopted as a WG draft, > it > > >>>> is owned by the whole WG, rather than just the editors. Just as Re= mi > > >>>> said, the normal procedure to follow is to reach WG consensus > _before_ > > >>>> posting a newly edited version. > > >>>> > > >>>> From draft-mdt-softwire-mapping-address-and-port-03 to > > >>>> draft-ietf-softwire-map-00, there are several changes between them= . > In > > >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 > and > > >>>> IPv6 addressing, has never been discussed openly in the WG mailing > > >>>> list, or even in the MAP design team either. > > >>>> > > >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation > > >>>> draft. The motivation draft has clearly defines the "Stateless 4/6 > > >>>> solution" as follows: > > >>>> > > >>>> Stateless 4/6 solution denotes a solution which does not require a= ny > > >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by > any > > >>>> IP address sharing function in the Service Provider's network. Thi= s > > >>>> category of solutions assumes a dependency between an IPv6 prefix > and > > >>>> IPv4 address. > > >>>> > > >>>> AFAIK what the WG has adopted MAP related draft is > > >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT > > >>>> draft-ietf-softwire-map-00. And the stateless solution should > =C2=B3response > > >>>> to the solution motivation document=C2=B2 according to the Softwir= e > charter. > > >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG > draft. > > >>>> > > >>>> We can all recall that our softwire WG has worked on stateless > > >>>> solutions for more than one and a half years, and we have achieved= a > > >>>> lot of work which has been documented in charter, stateless > motivation, > > >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the bas= ic > > >>>> "stateless" principle and the MAP design team is also working on i= t > > >>>> together to find a better algorithm, address format, etc. So it is > > >>>> really not appropriate to make such changes when MAP is adopted as > a WG > > >>>> item in such a short time. > > >>>> > > >>>> From this perspective, draft-ietf-softwire-map-00 can only be > regarded > > >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even t= he > > >>>> output of MAP design team. > > >>>> > > >>>> Best wishes > > >>>> > > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 > > >> _______________________________________________ > > >> 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 > > _______________________________________________ > 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 --14dae9340881d2d74b04c3483fa6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Satoru,

It is not only about the exact number of mapping rules, b= ut also the dynamic feature of it.

For the number of mapping rules, = it is obviously its objective to keep the least number of mapping rules in = stateless solution. See section 3.1.1 in the motivation draft:

3.1.1.=C2=A0 Network Dimensioning
=C2=A0=C2=A0 Because no per-user s= tate [RFC1958] is required, a stateless solution
=C2=A0=C2=A0 does not n= eed to take into account the maximum number of simultaneous
=C2=A0=C2=A0= user-sessions and the maximum number of new user-sessions per second
=C2=A0=C2=A0 to dimension its networking equipment.=C2=A0 Like current netw= ork
=C2=A0=C2=A0 dimensioning practices, only considerations related to = the customers
=C2=A0=C2=A0 number, traffic trends and the bandwidth usag= e need be taken into
=C2=A0=C2=A0 account.

Does it still fit for 1:1 mapping mode ?

=C2=A0=C2=A0
On Mon, Jun 25, 2012 at 3:01 PM, Satoru Matsushima <satoru.matsushima@gmail.com> wrote:
Hi Qiong,

A MAP domain can have several/some/many mapping rules in the domain. How ma= ny is threshold for either stateless or stateful?

cheers,
--satoru

On 2012/06/25, at 15:51, Qi Sun wrote:

> Hi Satoru,
>
> In MAP 1:1 mode, if there are 10000000 subscribers, there would be 100= 00000 MAP domains which a BR has to manage. I think that will create a huge= mapping table on the BR, which is called 'state' that stateful sol= utions deal with.
>
> Best Regards!
>
> Qi Sun
>
> From: Satoru Matsushima
> Date: 2012-06-25 10:27
> To: Lee, Yiu
> CC: softwires@ietf.org; Yong= Cui
> Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NO= T reflect the consensus from the WG
> Hi Yiu,
>
> No, that's a misunderstanding.
> Current MAP specify the case for ea-len is 'zero'. It is '= per-subscriber mapping' in stateless manner, not to introduce 'per-= flow NAT binding' or 'per-subscriber state on demand'.
>
> cheers,
> --satoru
>
> On 2012/06/25, at 2:32, Lee, Yiu wrote:
>
> > Dear Satoru and MAP-DT
> >
> > I echo what Peng and Qiong said. When the WG agreed working on th= e
> > stateless solution, it was very clear stated that the solution wo= uld not
> > maintain states in the network. If the 1:1 mode changed this, thi= s no
> > longer matched the requirements stated in the stateless motivatio= n draft,
> > thus, it would disqualify MAP as a solution for the motivation dr= aft.
> >
> > AFAIK, the MAP Design Team could propose a change, but such a dra= matic
> > change by introducing states in the network would require WG appr= oval. I
> > would like the chairs to clarify this.
> >
> > Thanks,
> > Yiu
> >
> >
> > On 6/24/12 12:21 PM, "Peng Wu" <pengwu.thu@gmail.com> wrote:
> >
> >> Hi Qiong, Satoru and all,
> >>
> >> I should thank Qiong for pointing this out. I gotta say I'= ;m a bit shocked.
> >> If I understand the procedures of IETF correctly, a WG docume= nt should
> >> reflect the consensus of the WG. MAP is approved by the WG as= a
> >> stateless solution. As a participator in Softwire, I didn'= ;t get the
> >> information anywhere that the MAP WG document would cover the=
> >> so-called 1:1, in fact per-user stateful mode before it was r= eleased,
> >> not to say discuss in the WG. Don't the WG need to approv= e such big
> >> change anymore?
> >>
> >> Now let me provide my impression as an outsider of the MAP DT= . You
> >> guys make great effort to build the solution, The address com= position,
> >> the GMA algorithm, the different types of address mapping rul= es.
> >> should be quite difficult to pull together such sophisticated= ideas. I
> >> guess that's what it takes to achieve the benifits of sta= telessness.
> >> And I admire that, bravo. Then, all of a sudden, you guys are= saying,
> >> let's apply this sophisticated method to the different pr= oblem, by
> >> dropping quite some comlexity and twistting the mechanism a b= it, seems
> >> it may work. Considering the problem are now solved in a more= pure and
> >> clear way, I'm sorry but I CANNOT follow the logic here.<= br> > >>
> >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima
> >> <satoru.mat= sushima@gmail.com> wrote:
> >>> Hi Qiong,
> >>>
> >>> I'm disagree with your opinion.
> >>>
> >>> 1. Recent changes in draft-ietf-softwire-map-00 has been = discussed in
> >>> the DT.
> >>> 2. MAP just covers so called '1:1 mode' with most= granular mapping rule
> >>> for CEs provisioning, which is as one of its characterist= ics.
> >>> 3. The motivation draft does not restrict that as you sta= ted, just
> >>> 'assumed', it's neither 'MUST' nor &#= 39;SHOULD'.
> >>>
> >>> Best regards,
> >>> --satoru
> >>>
> >>>
> >>> On 2012/06/24, at 14:35, Qiong wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> As we all know, once an individual draft is adopted a= s a WG draft, it
> >>>> is owned by the whole WG, rather than just the editor= s. Just as Remi
> >>>> said, the normal procedure to follow is to reach WG c= onsensus _before_
> >>>> posting a newly edited version.
> >>>>
> >>>> From draft-mdt-softwire-mapping-address-and-port-03 t= o
> >>>> draft-ietf-softwire-map-00, there are several changes= between them. In
> >>>> particular, the newly introduced "1:1 mode"= , which decouples IPv4 and
> >>>> IPv6 addressing, has never been discussed openly in t= he WG mailing
> >>>> list, or even in the MAP design team either.
> >>>>
> >>>> Actually, this "1:1 mode" is against the st= ateless-4v6-motivation
> >>>> draft. The motivation draft has clearly defines the &= quot;Stateless 4/6
> >>>> solution" as follows:
> >>>>
> >>>> Stateless 4/6 solution denotes a solution which does = not require any
> >>>> per-user state (see Section 2.3 of [RFC1958]) to be m= aintained by any
> >>>> IP address sharing function in the Service Provider&#= 39;s network. This
> >>>> category of solutions assumes a dependency between an= IPv6 prefix and
> >>>> IPv4 address.
> >>>>
> >>>> AFAIK what the WG has adopted MAP related draft is > >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT > >>>> draft-ietf-softwire-map-00. And the stateless solutio= n should =C2=B3response
> >>>> to the solution motivation document=C2=B2 according t= o the Softwire charter.
> >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIE= D to be a WG draft.
> >>>>
> >>>> We can all recall that our softwire WG has worked on = stateless
> >>>> solutions for more than one and a half years, and we = have achieved a
> >>>> lot of work which has been documented in charter, sta= teless motivation,
> >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have= kept the basic
> >>>> "stateless" principle and the MAP design te= am is also working on it
> >>>> together to find a better algorithm, address format, = etc. So it is
> >>>> really not appropriate to make such changes when MAP = is adopted as a WG
> >>>> item in such a short time.
> >>>>
> >>>> From this perspective, draft-ietf-softwire-map-00 can= only be regarded
> >>>> as draft-XX-softwire-mapping-address-and-port-04. It = is not even the
> >>>> output of MAP design team.
> >>>>
> >>>> Best wishes
> >>>>
> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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/<= /a>
> >>>> PCP-natcoord: http://sourceforge.net/projects/pcpp= ortsetdemo/
> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=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<= /a>
> >>> https://www.ietf.org/mailman/listinfo/softwires > >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org<= br> > >> https://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> 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
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

--14dae9340881d2d74b04c3483fa6-- From sunqi.csnet.thu@gmail.com Mon Jun 25 02:03:43 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 47EC621F84B6 for ; Mon, 25 Jun 2012 02:03:43 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPZIRyh9MtCP for ; Mon, 25 Jun 2012 02:03:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1575221F84DE for ; Mon, 25 Jun 2012 02:03:39 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6335545pbc.31 for ; Mon, 25 Jun 2012 02:03:38 -0700 (PDT) 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-mailer:mime-version:message-id:content-type; bh=CW5ZbAJdsBFyei4b3uZEZehIk7Em7OiEM43J+fawS+U=; b=SLvqcvwkqe4gA+Xf0gjfoMQ5ReWChsA3ENDi1GcbDksj/hUY0PWVIhuKCpSzt+lsv6 tZFFFHW/aDTBQITx52rlN4NRgDrIGzyIdOX3GB5tXJyX90ndVVpKPgC963dJw9qlmSea vKUGUxHCj5AWWewtIqt8VPxlWgBRk/BT7u3oWV6T6+XuZ55RWmQRgWmK91EAfRl4oQB5 qy4nPfLpIsnwBxS1PVfJcINdqcOQkQvcueheAjOo9yZMJHMKKwGOl7b0AfvuiHj29ox3 5PLaoiBAF5LQt+6pWs9mCE3T+InedND3Arn8EZ+3+5ZmwJ9Pt9Kt0riMt/Ilwd3UPOwZ Lb1A== Received: by 10.68.226.226 with SMTP id rv2mr38040440pbc.101.1340615018609; Mon, 25 Jun 2012 02:03:38 -0700 (PDT) Received: from sunqi ([219.243.220.10]) by mx.google.com with ESMTPS id vz9sm7948386pbc.12.2012.06.25.02.03.34 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 02:03:38 -0700 (PDT) Date: Mon, 25 Jun 2012 17:03:26 +0800 From: "Qi Sun" To: "Mark Townsley" References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com>, <31C6EABE-E6CE-4422-8EF3-84A6A0EB8C7E@townsley.net> X-Priority: 3 X-GUID: 8F92E34C-85BF-47FF-8E68-20F12513CD71 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012062517032647675867@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart432485066083_=----" Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 09:03:43 -0000 This is a multi-part message in MIME format. ------=_001_NextPart432485066083_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KUGxlYXNlIHNlZSBpbmxpbmVzIDopDQoNClRoYW5rIHlvdSAhDQoNCg0KDQoN ClFpIFN1bg0KDQpGcm9tOiBNYXJrIFRvd25zbGV5DQpEYXRlOiAyMDEyLTA2LTI1IDE2OjM1DQpU bzogc3VucWkuY3NuZXQudGh1DQpDQzogU2F0b3J1IE1hdHN1c2hpbWE7IHNvZnR3aXJlcyBXRzsg WW9uZyBDdWkNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBbU29mdHdpcmVdIGRyYWZ0LWlldGYt c29mdHdpcmUtbWFwLTAwIGRvZXMgTk9UIHJlZmxlY3QgdGhlIGNvbnNlbnN1cyBmcm9tIHRoZSBX Rw0KDQpBICJtYXAgZG9tYWluIiB0aGF0IHN1cHBvcnRzIGEgc2luZ2xlIGN1c3RvbWVyIGlzIG5v IG1vcmUgImhlYXZ5IiB0aGFuIGEgTFc0NiBtYXBwaW5nIHRhYmxlIGVudHJ5IHRoYXQgc3VwcG9y dHMgYSBzaW5nbGUgY3VzdG9tZXIuIFlvdSBhcmUgY29tcGFyaW5nIDEwMDAwMDAwIG9mIHRoaXMg dnMuIDEwMDAwMDAwIG9mIHRoYXQsIHdoZXJlIHRoaXMgYW5kIHRoYXQgYXJlIGVmZmVjdGl2ZWx5 IGVxdWFsIGluIHRlcm1zIG9mIHJlc291cmNlcyBuZWNlc3NhcnkgZm9yIHN1cHBvcnQuIA0KDQpb UWkgU3VuXSBTb3JyeSBmb3Igbm90IG1ha2luZyBpdCBjbGVhcmx5LiBBcyBzdGF0ZWQgaW4gbXkg cHJldmlvdXMgZW1haWwsIHdoYXQgSSdtIGZvY3VzaW5nIG9uIGlzIE5PVCB3aGV0aGVyIGl0J3Mg J2hlYXZ5JyBmb3IgdGhlIEJSIGJ1dCBCUiB3aWxsIGhhdmUgdG8gbWFpbnRhaW4gYSBtYXBwaW5n IHRhYmxlIHRvIG1hbmFnZSB0aGlzLiBUaGF0J3MgdG8gc2F5LCBzdGF0ZXMgYXJlIG1haW50YWlu ZWQgaGVyZSwgd2hpY2ggaXMgbm90IHRoZSBmZWF0dXJlIG9mIE1BUC4NCiANCg0KVGhlcmUgYXJl IGEgbG90IG9mIHBlb3BsZSB3b3JraW5nIG9uIHRoaXMgc2FtZSBwcm9ibGVtIHNwYWNlLCBhdHRh Y2tpbmcgaXQgZnJvbSBkaWZmZXJlbnQgZGlyZWN0aW9ucy4gV2UgYXJlIGJvdW5kIHRvIHJ1biBp bnRvIG9uZSBhbm90aGVyLCBhbmQgdGhhdCdzIHdoYXQgaXMgaGFwcGVuaW5nIGhlcmUuIFRoZSBt b3JlIHdlIGNhbiBkbyB0byBjb2xsYXBzZSB0aGUgYWx0ZXJuYXRpdmVzIGludG8gZmV3ZXIgdGhp bmdzIHdpdGggZmV3ZXIgZmFuY3kgbmFtZXMsIHRoZSBiZXR0ZXIuIA0KICAgDQpbUWkgU3VuXSAg QWN0dWFsbHksIGknbSBub3QgYXR0YWNraW5nIGFueXRoaW5nIGJ1dCB0cnkgdG8gbWFrZSB0aGlu Z3MgbW9yZSBzcGVjaWZpYy4gSXQncyB0cnVlIHRoYXQgZmV3ZXIgZmFuY3kgbmFtZXMgdGhlIGJl dHRlciwgYnV0IHdoZW4gdGhlIG1lY2hhbmlzbXMgYmVsb25nIHRvIGRpZmZlcmVudCBjYXRlZ29y aWVzIGl0J3MgcHJvcGVyIHRvIGtlZXAgdGhlIHdheSB0aGV5IHdlcmUuDQoNCg0KDQotIE1hcmsN Cg0KT24gSnVuIDI1LCAyMDEyLCBhdCA4OjUxLCAiUWkgU3VuIiA8c3VucWkuY3NuZXQudGh1QGdt YWlsLmNvbT4gd3JvdGU6DQoNCg0KSGkgU2F0b3J1LA0KDQpJbiBNQVAgMToxIG1vZGUsIGlmIHRo ZXJlIGFyZSAxMDAwMDAwMCBzdWJzY3JpYmVycywgdGhlcmUgd291bGQgYmUgMTAwMDAwMDAgTUFQ IGRvbWFpbnMgd2hpY2ggYSBCUiBoYXMgdG8gbWFuYWdlLiBJIHRoaW5rIHRoYXQgd2lsbCBjcmVh dGUgYSBodWdlIG1hcHBpbmcgdGFibGUgb24gdGhlIEJSLCB3aGljaCBpcyBjYWxsZWQgJ3N0YXRl JyB0aGF0IHN0YXRlZnVsIHNvbHV0aW9ucyBkZWFsIHdpdGguDQoNCkJlc3QgUmVnYXJkcyENCg0K DQoNCg0KUWkgU3VuDQoNCkZyb206IFNhdG9ydSBNYXRzdXNoaW1hDQpEYXRlOiAyMDEyLTA2LTI1 IDEwOjI3DQpUbzogTGVlLCBZaXUNCkNDOiBzb2Z0d2lyZXNAaWV0Zi5vcmc7IFlvbmcgQ3VpDQpT dWJqZWN0OiBSZTogW1NvZnR3aXJlc10gW1NvZnR3aXJlXSBkcmFmdC1pZXRmLXNvZnR3aXJlLW1h cC0wMCBkb2VzIE5PVCByZWZsZWN0IHRoZSBjb25zZW5zdXMgZnJvbSB0aGUgV0cNCkhpIFlpdSwN Cg0KTm8sIHRoYXQncyBhIG1pc3VuZGVyc3RhbmRpbmcuDQpDdXJyZW50IE1BUCBzcGVjaWZ5IHRo ZSBjYXNlIGZvciBlYS1sZW4gaXMgJ3plcm8nLiBJdCBpcyAncGVyLXN1YnNjcmliZXIgbWFwcGlu ZycgaW4gc3RhdGVsZXNzIG1hbm5lciwgbm90IHRvIGludHJvZHVjZSAncGVyLWZsb3cgTkFUIGJp bmRpbmcnIG9yICdwZXItc3Vic2NyaWJlciBzdGF0ZSBvbiBkZW1hbmQnLg0KDQpjaGVlcnMsDQot LXNhdG9ydQ0KDQpPbiAyMDEyLzA2LzI1LCBhdCAyOjMyLCBMZWUsIFlpdSB3cm90ZToNCg0KPiBE ZWFyIFNhdG9ydSBhbmQgTUFQLURUDQo+IA0KPiBJIGVjaG8gd2hhdCBQZW5nIGFuZCBRaW9uZyBz YWlkLiBXaGVuIHRoZSBXRyBhZ3JlZWQgd29ya2luZyBvbiB0aGUNCj4gc3RhdGVsZXNzIHNvbHV0 aW9uLCBpdCB3YXMgdmVyeSBjbGVhciBzdGF0ZWQgdGhhdCB0aGUgc29sdXRpb24gd291bGQgbm90 DQo+IG1haW50YWluIHN0YXRlcyBpbiB0aGUgbmV0d29yay4gSWYgdGhlIDE6MSBtb2RlIGNoYW5n ZWQgdGhpcywgdGhpcyBubw0KPiBsb25nZXIgbWF0Y2hlZCB0aGUgcmVxdWlyZW1lbnRzIHN0YXRl ZCBpbiB0aGUgc3RhdGVsZXNzIG1vdGl2YXRpb24gZHJhZnQsDQo+IHRodXMsIGl0IHdvdWxkIGRp c3F1YWxpZnkgTUFQIGFzIGEgc29sdXRpb24gZm9yIHRoZSBtb3RpdmF0aW9uIGRyYWZ0Lg0KPiAN Cj4gQUZBSUssIHRoZSBNQVAgRGVzaWduIFRlYW0gY291bGQgcHJvcG9zZSBhIGNoYW5nZSwgYnV0 IHN1Y2ggYSBkcmFtYXRpYw0KPiBjaGFuZ2UgYnkgaW50cm9kdWNpbmcgc3RhdGVzIGluIHRoZSBu ZXR3b3JrIHdvdWxkIHJlcXVpcmUgV0cgYXBwcm92YWwuIEkNCj4gd291bGQgbGlrZSB0aGUgY2hh aXJzIHRvIGNsYXJpZnkgdGhpcy4NCj4gDQo+IFRoYW5rcywNCj4gWWl1DQo+IA0KPiANCj4gT24g Ni8yNC8xMiAxMjoyMSBQTSwgIlBlbmcgV3UiIDxwZW5nd3UudGh1QGdtYWlsLmNvbT4gd3JvdGU6 DQo+IA0KPj4gSGkgUWlvbmcsIFNhdG9ydSBhbmQgYWxsLA0KPj4gDQo+PiBJIHNob3VsZCB0aGFu ayBRaW9uZyBmb3IgcG9pbnRpbmcgdGhpcyBvdXQuIEkgZ290dGEgc2F5IEknbSBhIGJpdCBzaG9j a2VkLg0KPj4gSWYgSSB1bmRlcnN0YW5kIHRoZSBwcm9jZWR1cmVzIG9mIElFVEYgY29ycmVjdGx5 LCBhIFdHIGRvY3VtZW50IHNob3VsZA0KPj4gcmVmbGVjdCB0aGUgY29uc2Vuc3VzIG9mIHRoZSBX Ry4gTUFQIGlzIGFwcHJvdmVkIGJ5IHRoZSBXRyBhcyBhDQo+PiBzdGF0ZWxlc3Mgc29sdXRpb24u IEFzIGEgcGFydGljaXBhdG9yIGluIFNvZnR3aXJlLCBJIGRpZG4ndCBnZXQgdGhlDQo+PiBpbmZv cm1hdGlvbiBhbnl3aGVyZSB0aGF0IHRoZSBNQVAgV0cgZG9jdW1lbnQgd291bGQgY292ZXIgdGhl DQo+PiBzby1jYWxsZWQgMToxLCBpbiBmYWN0IHBlci11c2VyIHN0YXRlZnVsIG1vZGUgYmVmb3Jl IGl0IHdhcyByZWxlYXNlZCwNCj4+IG5vdCB0byBzYXkgZGlzY3VzcyBpbiB0aGUgV0cuIERvbid0 IHRoZSBXRyBuZWVkIHRvIGFwcHJvdmUgc3VjaCBiaWcNCj4+IGNoYW5nZSBhbnltb3JlPw0KPj4g DQo+PiBOb3cgbGV0IG1lIHByb3ZpZGUgbXkgaW1wcmVzc2lvbiBhcyBhbiBvdXRzaWRlciBvZiB0 aGUgTUFQIERULiBZb3UNCj4+IGd1eXMgbWFrZSBncmVhdCBlZmZvcnQgdG8gYnVpbGQgdGhlIHNv bHV0aW9uLCBUaGUgYWRkcmVzcyBjb21wb3NpdGlvbiwNCj4+IHRoZSBHTUEgYWxnb3JpdGhtLCB0 aGUgZGlmZmVyZW50IHR5cGVzIG9mIGFkZHJlc3MgbWFwcGluZyBydWxlcy4NCj4+IHNob3VsZCBi ZSBxdWl0ZSBkaWZmaWN1bHQgdG8gcHVsbCB0b2dldGhlciBzdWNoIHNvcGhpc3RpY2F0ZWQgaWRl YXMuIEkNCj4+IGd1ZXNzIHRoYXQncyB3aGF0IGl0IHRha2VzIHRvIGFjaGlldmUgdGhlIGJlbmlm aXRzIG9mIHN0YXRlbGVzc25lc3MuDQo+PiBBbmQgSSBhZG1pcmUgdGhhdCwgYnJhdm8uIFRoZW4s IGFsbCBvZiBhIHN1ZGRlbiwgeW91IGd1eXMgYXJlIHNheWluZywNCj4+IGxldCdzIGFwcGx5IHRo aXMgc29waGlzdGljYXRlZCBtZXRob2QgdG8gdGhlIGRpZmZlcmVudCBwcm9ibGVtLCBieQ0KPj4g ZHJvcHBpbmcgcXVpdGUgc29tZSBjb21sZXhpdHkgYW5kIHR3aXN0dGluZyB0aGUgbWVjaGFuaXNt IGEgYml0LCBzZWVtcw0KPj4gaXQgbWF5IHdvcmsuIENvbnNpZGVyaW5nIHRoZSBwcm9ibGVtIGFy ZSBub3cgc29sdmVkIGluIGEgbW9yZSBwdXJlIGFuZA0KPj4gY2xlYXIgd2F5LCBJJ20gc29ycnkg YnV0IEkgQ0FOTk9UIGZvbGxvdyB0aGUgbG9naWMgaGVyZS4NCj4+IA0KPj4gT24gU3VuLCBKdW4g MjQsIDIwMTIgYXQgMjowMCBQTSwgU2F0b3J1IE1hdHN1c2hpbWENCj4+IDxzYXRvcnUubWF0c3Vz aGltYUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IEhpIFFpb25nLA0KPj4+IA0KPj4+IEknbSBkaXNh Z3JlZSB3aXRoIHlvdXIgb3Bpbmlvbi4NCj4+PiANCj4+PiAxLiBSZWNlbnQgY2hhbmdlcyBpbiBk cmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4NCj4+PiB0aGUg RFQuDQo+Pj4gMi4gTUFQIGp1c3QgY292ZXJzIHNvIGNhbGxlZCAnMToxIG1vZGUnIHdpdGggbW9z dCBncmFudWxhciBtYXBwaW5nIHJ1bGUNCj4+PiBmb3IgQ0VzIHByb3Zpc2lvbmluZywgd2hpY2gg aXMgYXMgb25lIG9mIGl0cyBjaGFyYWN0ZXJpc3RpY3MuDQo+Pj4gMy4gVGhlIG1vdGl2YXRpb24g ZHJhZnQgZG9lcyBub3QgcmVzdHJpY3QgdGhhdCBhcyB5b3Ugc3RhdGVkLCBqdXN0DQo+Pj4gJ2Fz c3VtZWQnLCBpdCdzIG5laXRoZXIgJ01VU1QnIG5vciAnU0hPVUxEJy4NCj4+PiANCj4+PiBCZXN0 IHJlZ2FyZHMsDQo+Pj4gLS1zYXRvcnUNCj4+PiANCj4+PiANCj4+PiBPbiAyMDEyLzA2LzI0LCBh dCAxNDozNSwgUWlvbmcgd3JvdGU6DQo+Pj4gDQo+Pj4+IEhpIGFsbCwNCj4+Pj4gDQo+Pj4+IEFz IHdlIGFsbCBrbm93LCBvbmNlIGFuIGluZGl2aWR1YWwgZHJhZnQgaXMgYWRvcHRlZCBhcyBhIFdH IGRyYWZ0LCBpdA0KPj4+PiBpcyBvd25lZCBieSB0aGUgd2hvbGUgV0csIHJhdGhlciB0aGFuIGp1 c3QgdGhlIGVkaXRvcnMuIEp1c3QgYXMgUmVtaQ0KPj4+PiBzYWlkLCB0aGUgbm9ybWFsIHByb2Nl ZHVyZSB0byBmb2xsb3cgaXMgdG8gcmVhY2ggV0cgY29uc2Vuc3VzIF9iZWZvcmVfDQo+Pj4+IHBv c3RpbmcgYSBuZXdseSBlZGl0ZWQgdmVyc2lvbi4NCj4+Pj4gDQo+Pj4+IEZyb20gZHJhZnQtbWR0 LXNvZnR3aXJlLW1hcHBpbmctYWRkcmVzcy1hbmQtcG9ydC0wMyB0bw0KPj4+PiBkcmFmdC1pZXRm LXNvZnR3aXJlLW1hcC0wMCwgdGhlcmUgYXJlIHNldmVyYWwgY2hhbmdlcyBiZXR3ZWVuIHRoZW0u IEluDQo+Pj4+IHBhcnRpY3VsYXIsIHRoZSBuZXdseSBpbnRyb2R1Y2VkICIxOjEgbW9kZSIsIHdo aWNoIGRlY291cGxlcyBJUHY0IGFuZA0KPj4+PiBJUHY2IGFkZHJlc3NpbmcsIGhhcyBuZXZlciBi ZWVuIGRpc2N1c3NlZCBvcGVubHkgaW4gdGhlIFdHIG1haWxpbmcNCj4+Pj4gbGlzdCwgb3IgZXZl biBpbiB0aGUgTUFQIGRlc2lnbiB0ZWFtIGVpdGhlci4NCj4+Pj4gDQo+Pj4+IEFjdHVhbGx5LCB0 aGlzICIxOjEgbW9kZSIgaXMgYWdhaW5zdCB0aGUgc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uDQo+ Pj4+IGRyYWZ0LiBUaGUgbW90aXZhdGlvbiBkcmFmdCBoYXMgY2xlYXJseSBkZWZpbmVzIHRoZSAi U3RhdGVsZXNzIDQvNg0KPj4+PiBzb2x1dGlvbiIgYXMgZm9sbG93czoNCj4+Pj4gDQo+Pj4+IFN0 YXRlbGVzcyA0LzYgc29sdXRpb24gZGVub3RlcyBhIHNvbHV0aW9uIHdoaWNoIGRvZXMgbm90IHJl cXVpcmUgYW55DQo+Pj4+IHBlci11c2VyIHN0YXRlIChzZWUgU2VjdGlvbiAyLjMgb2YgW1JGQzE5 NThdKSB0byBiZSBtYWludGFpbmVkIGJ5IGFueQ0KPj4+PiBJUCBhZGRyZXNzIHNoYXJpbmcgZnVu Y3Rpb24gaW4gdGhlIFNlcnZpY2UgUHJvdmlkZXIncyBuZXR3b3JrLiBUaGlzDQo+Pj4+IGNhdGVn b3J5IG9mIHNvbHV0aW9ucyBhc3N1bWVzIGEgZGVwZW5kZW5jeSBiZXR3ZWVuIGFuIElQdjYgcHJl Zml4IGFuZA0KPj4+PiBJUHY0IGFkZHJlc3MuDQo+Pj4+IA0KPj4+PiBBRkFJSyB3aGF0IHRoZSBX RyBoYXMgYWRvcHRlZCBNQVAgcmVsYXRlZCBkcmFmdCBpcw0KPj4+PiBkcmFmdC1tZHQtc29mdHdp cmUtbWFwcGluZy1hZGRyZXNzLWFuZC1wb3J0LTAzLCBOT1QNCj4+Pj4gZHJhZnQtaWV0Zi1zb2Z0 d2lyZS1tYXAtMDAuIEFuZCB0aGUgc3RhdGVsZXNzIHNvbHV0aW9uIHNob3VsZCDCs3Jlc3BvbnNl DQo+Pj4+IHRvIHRoZSBzb2x1dGlvbiBtb3RpdmF0aW9uIGRvY3VtZW50wrIgYWNjb3JkaW5nIHRv IHRoZSBTb2Z0d2lyZSBjaGFydGVyLg0KPj4+PiBUaGF0IG1lYW5zIGRyYWZ0LWlldGYtc29mdHdp cmUtbWFwLTAwIElTIE5PVCBRVUFMSUZJRUQgdG8gYmUgYSBXRyBkcmFmdC4NCj4+Pj4gDQo+Pj4+ IFdlIGNhbiBhbGwgcmVjYWxsIHRoYXQgb3VyIHNvZnR3aXJlIFdHIGhhcyB3b3JrZWQgb24gc3Rh dGVsZXNzDQo+Pj4+IHNvbHV0aW9ucyBmb3IgbW9yZSB0aGFuIG9uZSBhbmQgYSBoYWxmIHllYXJz LCBhbmQgd2UgaGF2ZSBhY2hpZXZlZCBhDQo+Pj4+IGxvdCBvZiB3b3JrIHdoaWNoIGhhcyBiZWVu IGRvY3VtZW50ZWQgaW4gY2hhcnRlciwgc3RhdGVsZXNzIG1vdGl2YXRpb24sDQo+Pj4+IDRyZC12 YXJpZW50cywgTUFQLTAzLCBldGMuIEFGQUlLIGFsbCB0aGUgYXV0aG9ycyBoYXZlIGtlcHQgdGhl IGJhc2ljDQo+Pj4+ICJzdGF0ZWxlc3MiIHByaW5jaXBsZSBhbmQgdGhlIE1BUCBkZXNpZ24gdGVh bSBpcyBhbHNvIHdvcmtpbmcgb24gaXQNCj4+Pj4gdG9nZXRoZXIgdG8gZmluZCBhIGJldHRlciBh bGdvcml0aG0sIGFkZHJlc3MgZm9ybWF0LCBldGMuIFNvIGl0IGlzDQo+Pj4+IHJlYWxseSBub3Qg YXBwcm9wcmlhdGUgdG8gbWFrZSBzdWNoIGNoYW5nZXMgd2hlbiBNQVAgaXMgYWRvcHRlZCBhcyBh IFdHDQo+Pj4+IGl0ZW0gaW4gc3VjaCBhIHNob3J0IHRpbWUuDQo+Pj4+IA0KPj4+PiBGcm9tIHRo aXMgcGVyc3BlY3RpdmUsIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwIGNhbiBvbmx5IGJlIHJl Z2FyZGVkDQo+Pj4+IGFzIGRyYWZ0LVhYLXNvZnR3aXJlLW1hcHBpbmctYWRkcmVzcy1hbmQtcG9y dC0wNC4gSXQgaXMgbm90IGV2ZW4gdGhlDQo+Pj4+IG91dHB1dCBvZiBNQVAgZGVzaWduIHRlYW0u DQo+Pj4+IA0KPj4+PiBCZXN0IHdpc2hlcw0KPj4+PiANCj4+Pj4gPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4+PiBRaW9uZyBTdW4NCj4+Pj4gQ2hpbmEg VGVsZWNvbSBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHVkZQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IE9w ZW4gc291cmNlIGNvZGU6DQo+Pj4+IGxpZ2h0d2VpZ2h0IDRvdmVyNjogaHR0cDovL3NvdXJjZWZv cmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni8NCj4+Pj4gUENQLW5hdGNvb3JkOiBodHRwOi8vc291cmNl Zm9yZ2UubmV0L3Byb2plY3RzL3BjcHBvcnRzZXRkZW1vLw0KPj4+PiA9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IFNvZnR3aXJl cyBtYWlsaW5nIGxpc3QNCj4+Pj4gU29mdHdpcmVzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo+Pj4gDQo+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBTb2Z0d2lyZXMgbWFp bGluZyBsaXN0DQo+Pj4gU29mdHdpcmVzQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+PiBT b2Z0d2lyZXNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc29mdHdpcmVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlz dA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlcw== ------=_001_NextPart432485066083_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Mark,
 
Please see inlines :)
 
Thank you !
 
Qi Sun
 
Date: 2012-06-25 16:35
To: sunqi.csnet.thu
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG

A "map domain" that supports a single customer is no more "heavy"= than=20 a LW46 mapping table entry that supports a single customer. You are compar= ing=20 10000000 of this vs. 10000000 of that, where this and that are effectively= equal=20 in terms of resources necessary for support. 

[Qi=20 Sun] Sorry for not making it clearly. As stated in my=20 previous email, what I'm focusing on is NOT whether=20 it's 'heavy' for the BR but BR will have to maintain a mapping table = to=20 manage this. That's to say, states are maintained here, which is= not=20 the feature of MAP.
 
There are a lot of people working on this same problem space, attacki= ng it=20 from different directions. We are bound to run into one another, and that'= s what=20 is happening here. The more we can do to collapse the alternatives into fe= wer=20 things with fewer fancy names, the better. 
   
[Qi=20 Sun]  Actually, i'm not attacking anything but try to make t= hings=20 more specific. It's true that fewer fancy names the better, but when the=20 mechanisms belong to different categories it's proper to keep the way they= =20 were.

- Mark

On Jun 25, 2012, at 8:51, "Qi Sun" <sunqi.csnet.thu@gmail.com>= ;=20 wrote:

Hi Satoru,
 
In MAP 1:1 mode, if there are 10000000 subscribers, there would be=20 10000000 MAP domains which a BR has to manage. I think that will create = a huge=20 mapping table on the BR, which is called 'state' that stateful solutions= deal=20 with.
 
Best Regards!
 
Qi Sun
 
Date: 2012-06-25 10:27
CC: softwires@ietf.org; Yong Cui
Subject: Re: [Softwires] [Softwire]=20 draft-ietf-softwire-map-00 does NOT reflect the consensus from the=20 WG
Hi Yiu,
 
No, that's a misunderstanding.
Current MAP specify the case for ea-l= en is 'zero'. It is 'per-subscriber mapping'=  in stateless manner, not to introduce = 'per-flow NAT binding' or 'per-subscriber state&n= bsp;on demand'.
 
cheers,
--satoru
 
On 2012/06/25, at 2:32, Lee, Yiu wrot= e:
 
> Dear Satoru and MAP-DT
> 
> I echo what Peng and Qiong = said. When the WG agreed working on the=
> stateless solution, it was very = clear stated that the solution would not
> maintain states in the network. = If the 1:1 mode changed this, this no
> longer matched the requirements state= d in the stateless motivation draft,
> thus, it would disqualify MAP as=  a solution for the motivation draft.
> 
> AFAIK, the MAP Design Team could=  propose a change, but such a dramatic<= /DIV>
> change by introducing states in = the network would require WG approval. I
> would like the chairs to clarify=  this.
> 
> Thanks,
> Yiu
> 
> 
> On 6/24/12 12:21 PM, "Peng Wu"&n= bsp;<pengwu.thu@gmail.com> w= rote:
> 
>> Hi Qiong, Satoru and all,
>> 
>> I should thank Qiong for poi= nting this out. I gotta say I'm a = bit shocked.
>> If I understand the procedures&nb= sp;of IETF correctly, a WG document should
>> reflect the consensus of the = ;WG. MAP is approved by the WG as = a
>> stateless solution. As a particip= ator in Softwire, I didn't get the
>> information anywhere that the MAP=  WG document would cover the
>> so-called 1:1, in fact per-user&n= bsp;stateful mode before it was released,
>> not to say discuss in the&nb= sp;WG. Don't the WG need to approve suc= h big
>> change anymore?
>> 
>> Now let me provide my impres= sion as an outsider of the MAP DT. = ;You
>> guys make great effort to bu= ild the solution, The address composition,
>> the GMA algorithm, the different&= nbsp;types of address mapping rules.
>> should be quite difficult to = ;pull together such sophisticated ideas. I
>> guess that's what it takes t= o achieve the benifits of statelessness.
>> And I admire that, bravo. Th= en, all of a sudden, you guys are = saying,
>> let's apply this sophisticated me= thod to the different problem, by
>> dropping quite some comlexity and=  twistting the mechanism a bit, seems
>> it may work. Considering the = ;problem are now solved in a more pure&= nbsp;and
>> clear way, I'm sorry but I&n= bsp;CANNOT follow the logic here.
>> 
>> On Sun, Jun 24, 2012 at = ;2:00 PM, Satoru Matsushima
>> <satoru.matsushima@gmail.com<= /A>> wrote:
>>> Hi Qiong,
>>> 
>>> I'm disagree with your opinio= n.
>>> 
>>> 1. Recent changes in draft-ie= tf-softwire-map-00 has been discussed in
>>> the DT.
>>> 2. MAP just covers so ca= lled '1:1 mode' with most granular mapping&n= bsp;rule
>>> for CEs provisioning, which i= s as one of its characteristics.
>>> 3. The motivation draft does&= nbsp;not restrict that as you stated, just
>>> 'assumed', it's neither 'MUST'&nbs= p;nor 'SHOULD'.
>>> 
>>> Best regards,
>>> --satoru
>>> 
>>> 
>>> On 2012/06/24, at 14:35, Qion= g wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> As we all know, once = ;an individual draft is adopted as a WG=  draft, it
>>>> is owned by the whole&nbs= p;WG, rather than just the editors. Just&nbs= p;as Remi
>>>> said, the normal procedure&nbs= p;to follow is to reach WG consensus _b= efore_
>>>> posting a newly edited ve= rsion.
>>>> 
>>>> From draft-mdt-softwire-mapping-address-= and-port-03 to
>>>> draft-ietf-softwire-map-00, there a= re several changes between them. In
>>>> particular, the newly introduc= ed "1:1 mode", which decouples IPv4 and
>>>> IPv6 addressing, has never&nbs= p;been discussed openly in the WG mailing
>>>> list, or even in the = ;MAP design team either.
>>>> 
>>>> Actually, this "1:1 mode" = ;is against the stateless-4v6-motivation
>>>> draft. The motivation draft&nb= sp;has clearly defines the "Stateless 4/6
>>>> solution" as follows:
>>>> 
>>>> Stateless 4/6 solution denotes=  a solution which does not require any<= /DIV>
>>>> per-user state (see Section&nb= sp;2.3 of [RFC1958]) to be maintained by&nbs= p;any
>>>> IP address sharing function&nb= sp;in the Service Provider's network. This
>>>> category of solutions assumes&= nbsp;a dependency between an IPv6 prefix and=
>>>> IPv4 address.
>>>> 
>>>> AFAIK what the WG has&nbs= p;adopted MAP related draft is
>>>> draft-mdt-softwire-mapping-address-and-port-0= 3, NOT
>>>> draft-ietf-softwire-map-00. And the=  stateless solution should =C2=B3response
>>>> to the solution motivation&nbs= p;document=C2=B2 according to the Softwire charte= r.
>>>> That means draft-ietf-softwire-map-= 00 IS NOT QUALIFIED to be a WG dra= ft.
>>>> 
>>>> We can all recall that&nb= sp;our softwire WG has worked on stateless
>>>> solutions for more than o= ne and a half years, and we have a= chieved a
>>>> lot of work which has&nbs= p;been documented in charter, stateless motivatio= n,
>>>> 4rd-varients, MAP-03, etc. AFA= IK all the authors have kept the basic<= /DIV>
>>>> "stateless" principle and the&= nbsp;MAP design team is also working on = ;it
>>>> together to find a better=  algorithm, address format, etc. So it = is
>>>> really not appropriate to = ;make such changes when MAP is adopted = as a WG
>>>> item in such a short = ;time.
>>>> 
>>>> From this perspective, draft-i= etf-softwire-map-00 can only be regarded
>>>> as draft-XX-softwire-mapping-address-and= -port-04. It is not even the
>>>> output of MAP design team= .
>>>> 
>>>> Best wishes
>>>> 
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=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/p= rojects/laft6/
>>>> PCP-natcoord: http://sourcefo= rge.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.iet= f.org/mailman/listinfo/softwires
>>> 
>>> _______________________________________________
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.iet= f.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.iet= f.org/mailman/listinfo/softwires
 
_______________________________________________
Softwires mailing list
https://www.iet= f.org/mailman/listinfo/softwires
_______________________________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.iet= f.org/mailman/listinfo/softwires
------=_001_NextPart432485066083_=------ From satoru.matsushima@gmail.com Mon Jun 25 02:05: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 04BF921F84CE for ; Mon, 25 Jun 2012 02:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgy7hzE3wPac for ; Mon, 25 Jun 2012 02:05:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7670B21F84CD for ; Mon, 25 Jun 2012 02:05:07 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6337403pbc.31 for ; Mon, 25 Jun 2012 02:05:07 -0700 (PDT) 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=y6SACPd4N+fwpONH7B765m/j06RaBsQsDoKqkT+UKQQ=; b=jrxoXlbcy4idiryQStOJzijdXK4IXYWgSqYHAg1Yl9RC5qd7kxBpXYRNtIZcu2j0db KUjvzYmi3E53LNttwdu+bAb/T96v3vdxs9NK8hiN+s7tCv+eFA3P4qkfpujKZy1KRBdS uq+n4wZP1NjTZXa35BgDvohkbQE7z9I9ncEDMJcCtsz0S2frxKljb9hvM3lysgYjsYtZ 8B5qzMA0CYxaS0t6ZpWi+8EqCQtye5eM/ziE7GX5VAew6zDN6PiQaKIQ0200zxtjUci4 EJIDkUGGyhNAOCwqQar8xRtq5WLIJabMTOGrzH3IbqOTQ+veqbbEc7BZDLbzFZT1eYEj wZhA== Received: by 10.68.239.9 with SMTP id vo9mr38923566pbc.41.1340615107313; Mon, 25 Jun 2012 02:05:07 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id rd7sm7931561pbc.70.2012.06.25.02.05.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 02:05:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 18:05:02 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <570C97A3-D641-47EB-B0EB-B75ECD7E9EC4@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <97A4D74A-A531-4F83-B281-86973A3139A5@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:05:08 -0000 Hi Peng, On 2012/06/25, at 17:50, Peng Wu wrote: >> Hmm, I've read 'draft-cui-softwire-b4-translated-ds-lite' as you = called 'lightweight 4over6'. LW46 for short, it looks me that MAP just = provides LW46 a provisioning means which would be described in the = section 5, or appendix section because following text described in = section 5: >>=20 >> "Other optional alternatives to retrieve the public address and port- >> set also exist. The specific protocol extensions are out of scope = in >> this document, however some alternatives are mentioned in the = Appendix >> section." > Let me take a step further following your direction: > You are saying MAP is a provisioning mean in lw4over6. Then, what = exactly? > With IPv4-IPv6 addressing independency, you proivde an IPv4 address > and port set, within another DHCPv6 option? > No BMR, No FMR, No embedding address. Look at what's left. how is this > even similar to MAP? Let's think that a CE provisioned with following BMR comes from MAP = DHCPv6 options. BMR: o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o Rule-ipv4-prefix : x.x.x.x/32 o EA-length : 0 o Port-param option : {PSID/length} This BMR could be a LW46 provisioning means. cheers, --satoru= From pengwu.thu@gmail.com Mon Jun 25 02:08: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 9B36B21F84CD for ; Mon, 25 Jun 2012 02:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43hGyy2xRleY for ; Mon, 25 Jun 2012 02:08:08 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6C01521F846C for ; Mon, 25 Jun 2012 02:08:08 -0700 (PDT) Received: by qabj34 with SMTP id j34so1164084qab.4 for ; Mon, 25 Jun 2012 02:08:08 -0700 (PDT) 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:content-transfer-encoding; bh=3tx46oQ56bmfePWBH+6JXnjKfY30BuHp6nA489lcVKE=; b=HBKWze2b8udPa2cMi6qCV+3YRhev4iqJe5gfMNDkZKpKngwfmEFNeRNDPZ4YS9+jz9 BMcsQPBw2yxHzuhMDRjQUELk/qTu+T2yxg7KdPUu5yyvt5oBPuJVVK1C7khufuOIPnWv HRTsMbSB40Yyzk6kkcMo76EaGrb1q/l5GGXOFNL9Jh9tn0k373Y28+FLWPt7GBUuXjAS CI1qHNg+91n++xsMH6iU31HMBRaUFXLRHzzMQeCyDrGQMs1IE8UEuPwrifxblFEDvdsW tCEXY8PqKn7TLuHBnmnOHgXvVTm6Ba0mL9g5QhnbRxdqY+QE2WR3bBzPO5iJ0aQy5KxQ vo8A== MIME-Version: 1.0 Received: by 10.224.207.4 with SMTP id fw4mr19546159qab.82.1340615287756; Mon, 25 Jun 2012 02:08:07 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Mon, 25 Jun 2012 02:08:07 -0700 (PDT) In-Reply-To: <68F1620B-02AC-4AC0-8B3F-A9FE2620BBB3@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <07698BA1-CBEE-45E3-9CE2-B0ED530EFE93@gmail.com> <68F1620B-02AC-4AC0-8B3F-A9FE2620BBB3@gmail.com> Date: Mon, 25 Jun 2012 17:08:07 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:08:12 -0000 On Mon, Jun 25, 2012 at 4:52 PM, Satoru Matsushima wrote: > Hi Peng, > > On 2012/06/25, at 17:37, Peng Wu wrote: > >>> Please find it out on page 14 from following url: >>> >>> http://www.ietf.org/proceedings/82/slides/softwire-2.pdf >> >> I think that's not what Alain meant. If you look back and forth a bit, >> you can see that: >> B1 stands for per-subscriber stateufl/mapping/binding... >> B2 stand for stateless Hub & Spoke (in MAP case, FMRs not provisoned to = CE) >> B3 stand for stateless Mesh (in MAP case, FMRs provisoned to CE) >> The confusion comes from the use of per-=ADsubscriber in the slides. >> It's not the sementic we took in this thread. > > What's the differences from the semantics in this thread? > Since per-subscriber mapping operation should naturally be a hub-and-spok= e means, it is just a case of stateless solution operation. The discussion in this thread falls in the case of B1. Not the slide you refered to (slide 14) at all. I sincely suggest you look into the slides again, or look at my summary in last mail, copied as following =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D B1 stands for per-subscriber stateufl/mapping/binding... B2 stand for stateless Hub & Spoke (in MAP case, FMRs not provisoned to CE) B3 stand for stateless Mesh (in MAP case, FMRs provisoned to CE) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > cheers, > --satoru From satoru.matsushima@gmail.com Mon Jun 25 02:12: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 0C1FC21F8480 for ; Mon, 25 Jun 2012 02:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.354 X-Spam-Level: X-Spam-Status: No, score=-3.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKDe2dbVfsDj for ; Mon, 25 Jun 2012 02:12:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2017F21F8483 for ; Mon, 25 Jun 2012 02:12:25 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6346715pbc.31 for ; Mon, 25 Jun 2012 02:12:25 -0700 (PDT) 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=b8EIOjOcetBdpeQMM5scwWdika3DgQHnmz5cQIXLmV8=; b=DYaQVmR0E0Qs1/Je7lSNSte7YUHEtlJsFOXK7Qz3maIyMt22KEdq6t7qvvKBZImOoU U/sQJ+otUdbT8WnaVczz1aUkjXYBI60I2yh2UE9vHozZatZqNvf4yB21JqOthPEEIey4 mK2/cywZvgWIhyuBJPpFC5SOLaJYo/DQxI+t/tj14imJVwlvT7HzFo7PHufsj9I/0khE RYtsAfMk+xLARLtXhgS7BPzCikmZm5X1d5GVOn+5idyrpEkZqyy7QKtEzV6Em0aRlerX L98GQbg7NJeZnyMOdRJuhqqfy2BCK+e/DUEn1LMueIP3DcWLLSG5RG9Zre+Rf1PWoBmL 2qhg== Received: by 10.68.134.161 with SMTP id pl1mr5676001pbb.29.1340615544984; Mon, 25 Jun 2012 02:12:24 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id ph1sm7957355pbb.45.2012.06.25.02.12.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 02:12:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 18:12:16 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <07698BA1-CBEE-45E3-9CE2-B0ED530EFE93@gmail.com> <68F1620B-02AC-4AC0-8B3F-A9FE2620BBB3@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:12:28 -0000 Hi Peng, On 2012/06/25, at 18:08, Peng Wu wrote: > The discussion in this thread falls in the case of B1. Not the slide > you refered to (slide 14) at all. Not true. I discuss this thread in the context of B2. Please read the slides, again. cheers, --satoru From pengwu.thu@gmail.com Mon Jun 25 02: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 E7C9221F84B2 for ; Mon, 25 Jun 2012 02:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFgLjWcgQ+TE for ; Mon, 25 Jun 2012 02:22:52 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 638D121F8472 for ; Mon, 25 Jun 2012 02:22:52 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2091352vcq.31 for ; Mon, 25 Jun 2012 02:22:51 -0700 (PDT) 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=ZkmKhjxTjzpSmm9BAdITiPCaec4Jebq82CvlChIA4HM=; b=r3ayGSwGE1fHEJBj/95aWsfXWdhQDKP5CvnyAkcllLwhzzeFRzYGqM8uvonD7fff7K hJKBoLcg663o7ipEENtyEcxIJkpu7s1HUz58/s/kxm0wG/Okv3X9xWT0h8dW2fOuPYrC gdEjwpUN1xMMqMOTwaik+SJKiwc+BVg0Uce3mq7KkAPtzzv2DQ8TrAwJYlEBf6RSsxEo aYzbyt/qjswDVf2XmHDck7xdK59x7zLojrzeNylw4BdqfO9YpjsVnG+JxC637Qesipwj Ks/WE1EVaL9HuGXkGv3JjsflRerVfWTszsfk7wcdAIyMRMoiBNmX3QJvxrBYBAPF0ta0 bABg== MIME-Version: 1.0 Received: by 10.52.90.233 with SMTP id bz9mr6021117vdb.93.1340616171799; Mon, 25 Jun 2012 02:22:51 -0700 (PDT) Received: by 10.52.28.84 with HTTP; Mon, 25 Jun 2012 02:22:51 -0700 (PDT) In-Reply-To: References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <07698BA1-CBEE-45E3-9CE2-B0ED530EFE93@gmail.com> <68F1620B-02AC-4AC0-8B3F-A9FE2620BBB3@gmail.com> Date: Mon, 25 Jun 2012 17:22:51 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:22:53 -0000 This is ... ... Just take a look at the title of slide 15: so you are for the statement of "MAP is a solution of per subscriber mappings on CPE"? On Mon, Jun 25, 2012 at 5:12 PM, Satoru Matsushima wrote:tak > Hi Peng, > > On 2012/06/25, at 18:08, Peng Wu wrote: > >> The discussion in this thread falls in the case of B1. Not the slide >> you refered to (slide 14) at all. > > Not true. I discuss this thread in the context of B2. > Please read the slides, again. > > cheers, > --satoru From Tetsuya.Murakami@ipinfusion.com Mon Jun 25 02:27: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 4CFBE21F846A for ; Mon, 25 Jun 2012 02:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ajnc1z0GHzUX for ; Mon, 25 Jun 2012 02:27:40 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id DFC1D21F8466 for ; Mon, 25 Jun 2012 02:27:39 -0700 (PDT) Received: from mail201-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 09:26:00 +0000 Received: from mail201-ch1 (localhost [127.0.0.1]) by mail201-ch1-R.bigfish.com (Postfix) with ESMTP id A71891200F1; Mon, 25 Jun 2012 09:26:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371Ic89bh936eI1432I1418Ic857h4015I14ffIzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25he5bhf0ahbe3k) Received-SPF: pass (mail201-ch1: domain of ipinfusion.com designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=BY2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail201-ch1 (localhost.localdomain [127.0.0.1]) by mail201-ch1 (MessageSwitch) id 1340616358152263_8572; Mon, 25 Jun 2012 09:25:58 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail201-ch1.bigfish.com (Postfix) with ESMTP id 22EBF3E0045; Mon, 25 Jun 2012 09:25:58 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 09:25:57 +0000 Received: from BY2PRD0510MB388.namprd05.prod.outlook.com ([169.254.3.207]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0164.004; Mon, 25 Jun 2012 09:27:34 +0000 From: Tetsuya Murakami To: sunqi.csnet.thu Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNUrTAvyrmVwhFIES3xCrjSPWSyA== Date: Mon, 25 Jun 2012 09:27:34 +0000 Message-ID: References: , <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> In-Reply-To: <2012062514514640804415@gmail.com> 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: multipart/alternative; boundary="_000_B83EBE2D2D784A1BB83E48946C43A1CDipinfusioncom_" MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:27:44 -0000 --_000_B83EBE2D2D784A1BB83E48946C43A1CDipinfusioncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUWksDQoNCkV2ZW4gdGhvdWdoIHRoZXJlIGFyZSBhIGJ1bmNoIG9mIG1hcHBpbmcgcnVsZXMs IGVhY2ggbWFwcGluZyBydWxlIGhhcyBubyBzdGF0ZS4gU2luY2UgZWFjaCBtYXBwaW5nIHJ1bGVz IGlzIHNldCBtYW51YWxseSwgQlIgZG9lcyBub3QgbWFpbnRhaW4gZWFjaCBtYXBwaW5nIHJ1bGUg YW5kIGp1c3Qgc3RvcmUgdGhlbSBpbiBpdHMgb3duIG1lbW9yeS4gU28sIEkgYW0gbm90IHN1cmUg d2h5IHlvdSBhcmUgY2FsbGluZyB0aGUgInN0YXRlIiBpZiB0aGVyZSBhcmUgYSBidW5jaCBvZiBt YXBwaW5nIHJ1bGVzLiBJZiB5b3UgYXJlIHNheWluZyB0aGF0LCBkbyB5b3UgYXNzdW1lIGhvdyBt YW55IGVudHJpZXMgc2hvdWxkIGJlIGV4aXN0ZWQgaW4gdGhlIHRhYmxlIGluIG9yZGVyIHRvIGNh bGwgaXQgdG8gdGhlICJzdGF0ZSIuIEZyb20gdGhlIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZl LCBldmVuIHRob3VnaCB0aGVyZSBhcmUgMTAwMDAwMDAgZW50cmllcyBpbiB0aGUgdGFibGUsIHRo ZSBwcm9ibGVtIGlzIGp1c3QgaG93IG11Y2ggbWVtb3J5IGlzIG5lZWRlZC4NCg0KVGhhbmtzLA0K VGV0c3V5YSBNdXJha2FtaQ0KDQpPbiAyMDEyLzA2LzI0LCBhdCAyMzo1MSwgUWkgU3VuIHdyb3Rl Og0KDQpIaSBTYXRvcnUsDQoNCkluIE1BUCAxOjEgbW9kZSwgaWYgdGhlcmUgYXJlIDEwMDAwMDAw IHN1YnNjcmliZXJzLCB0aGVyZSB3b3VsZCBiZSAxMDAwMDAwMCBNQVAgZG9tYWlucyB3aGljaCBh IEJSIGhhcyB0byBtYW5hZ2UuIEkgdGhpbmsgdGhhdCB3aWxsIGNyZWF0ZSBhIGh1Z2UgbWFwcGlu ZyB0YWJsZSBvbiB0aGUgQlIsIHdoaWNoIGlzIGNhbGxlZCAnc3RhdGUnIHRoYXQgc3RhdGVmdWwg c29sdXRpb25zIGRlYWwgd2l0aC4NCg0KQmVzdCBSZWdhcmRzIQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KUWkgU3VuDQoNCkZyb206IFNhdG9ydSBNYXRzdXNoaW1hPG1haWx0 bzpzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20+DQpEYXRlOiAyMDEyLTA2LTI1IDEwOjI3DQpU bzogTGVlLCBZaXU8bWFpbHRvOllpdV9MZWVAQ2FibGUuQ29tY2FzdC5jb20+DQpDQzogc29mdHdp cmVzQGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmc+OyBZb25nIEN1aTxtYWlsdG86 Y3VpeW9uZ0BnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gW1NvZnR3aXJlXSBk cmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBkb2VzIE5PVCByZWZsZWN0IHRoZSBjb25zZW5zdXMg ZnJvbSB0aGUgV0cNCkhpIFlpdSwNCg0KTm8sIHRoYXQncyBhIG1pc3VuZGVyc3RhbmRpbmcuDQpD dXJyZW50IE1BUCBzcGVjaWZ5IHRoZSBjYXNlIGZvciBlYS1sZW4gaXMgJ3plcm8nLiBJdCBpcyAn cGVyLXN1YnNjcmliZXIgbWFwcGluZycgaW4gc3RhdGVsZXNzIG1hbm5lciwgbm90IHRvIGludHJv ZHVjZSAncGVyLWZsb3cgTkFUIGJpbmRpbmcnIG9yICdwZXItc3Vic2NyaWJlciBzdGF0ZSBvbiBk ZW1hbmQnLg0KDQpjaGVlcnMsDQotLXNhdG9ydQ0KDQpPbiAyMDEyLzA2LzI1LCBhdCAyOjMyLCBM ZWUsIFlpdSB3cm90ZToNCg0KPiBEZWFyIFNhdG9ydSBhbmQgTUFQLURUDQo+DQo+IEkgZWNobyB3 aGF0IFBlbmcgYW5kIFFpb25nIHNhaWQuIFdoZW4gdGhlIFdHIGFncmVlZCB3b3JraW5nIG9uIHRo ZQ0KPiBzdGF0ZWxlc3Mgc29sdXRpb24sIGl0IHdhcyB2ZXJ5IGNsZWFyIHN0YXRlZCB0aGF0IHRo ZSBzb2x1dGlvbiB3b3VsZCBub3QNCj4gbWFpbnRhaW4gc3RhdGVzIGluIHRoZSBuZXR3b3JrLiBJ ZiB0aGUgMToxIG1vZGUgY2hhbmdlZCB0aGlzLCB0aGlzIG5vDQo+IGxvbmdlciBtYXRjaGVkIHRo ZSByZXF1aXJlbWVudHMgc3RhdGVkIGluIHRoZSBzdGF0ZWxlc3MgbW90aXZhdGlvbiBkcmFmdCwN Cj4gdGh1cywgaXQgd291bGQgZGlzcXVhbGlmeSBNQVAgYXMgYSBzb2x1dGlvbiBmb3IgdGhlIG1v dGl2YXRpb24gZHJhZnQuDQo+DQo+IEFGQUlLLCB0aGUgTUFQIERlc2lnbiBUZWFtIGNvdWxkIHBy b3Bvc2UgYSBjaGFuZ2UsIGJ1dCBzdWNoIGEgZHJhbWF0aWMNCj4gY2hhbmdlIGJ5IGludHJvZHVj aW5nIHN0YXRlcyBpbiB0aGUgbmV0d29yayB3b3VsZCByZXF1aXJlIFdHIGFwcHJvdmFsLiBJDQo+ IHdvdWxkIGxpa2UgdGhlIGNoYWlycyB0byBjbGFyaWZ5IHRoaXMuDQo+DQo+IFRoYW5rcywNCj4g WWl1DQo+DQo+DQo+IE9uIDYvMjQvMTIgMTI6MjEgUE0sICJQZW5nIFd1IiA8cGVuZ3d1LnRodUBn bWFpbC5jb208bWFpbHRvOnBlbmd3dS50aHVAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+PiBIaSBR aW9uZywgU2F0b3J1IGFuZCBhbGwsDQo+Pg0KPj4gSSBzaG91bGQgdGhhbmsgUWlvbmcgZm9yIHBv aW50aW5nIHRoaXMgb3V0LiBJIGdvdHRhIHNheSBJJ20gYSBiaXQgc2hvY2tlZC4NCj4+IElmIEkg dW5kZXJzdGFuZCB0aGUgcHJvY2VkdXJlcyBvZiBJRVRGIGNvcnJlY3RseSwgYSBXRyBkb2N1bWVu dCBzaG91bGQNCj4+IHJlZmxlY3QgdGhlIGNvbnNlbnN1cyBvZiB0aGUgV0cuIE1BUCBpcyBhcHBy b3ZlZCBieSB0aGUgV0cgYXMgYQ0KPj4gc3RhdGVsZXNzIHNvbHV0aW9uLiBBcyBhIHBhcnRpY2lw YXRvciBpbiBTb2Z0d2lyZSwgSSBkaWRuJ3QgZ2V0IHRoZQ0KPj4gaW5mb3JtYXRpb24gYW55d2hl cmUgdGhhdCB0aGUgTUFQIFdHIGRvY3VtZW50IHdvdWxkIGNvdmVyIHRoZQ0KPj4gc28tY2FsbGVk IDE6MSwgaW4gZmFjdCBwZXItdXNlciBzdGF0ZWZ1bCBtb2RlIGJlZm9yZSBpdCB3YXMgcmVsZWFz ZWQsDQo+PiBub3QgdG8gc2F5IGRpc2N1c3MgaW4gdGhlIFdHLiBEb24ndCB0aGUgV0cgbmVlZCB0 byBhcHByb3ZlIHN1Y2ggYmlnDQo+PiBjaGFuZ2UgYW55bW9yZT8NCj4+DQo+PiBOb3cgbGV0IG1l IHByb3ZpZGUgbXkgaW1wcmVzc2lvbiBhcyBhbiBvdXRzaWRlciBvZiB0aGUgTUFQIERULiBZb3UN Cj4+IGd1eXMgbWFrZSBncmVhdCBlZmZvcnQgdG8gYnVpbGQgdGhlIHNvbHV0aW9uLCBUaGUgYWRk cmVzcyBjb21wb3NpdGlvbiwNCj4+IHRoZSBHTUEgYWxnb3JpdGhtLCB0aGUgZGlmZmVyZW50IHR5 cGVzIG9mIGFkZHJlc3MgbWFwcGluZyBydWxlcy4NCj4+IHNob3VsZCBiZSBxdWl0ZSBkaWZmaWN1 bHQgdG8gcHVsbCB0b2dldGhlciBzdWNoIHNvcGhpc3RpY2F0ZWQgaWRlYXMuIEkNCj4+IGd1ZXNz IHRoYXQncyB3aGF0IGl0IHRha2VzIHRvIGFjaGlldmUgdGhlIGJlbmlmaXRzIG9mIHN0YXRlbGVz c25lc3MuDQo+PiBBbmQgSSBhZG1pcmUgdGhhdCwgYnJhdm8uIFRoZW4sIGFsbCBvZiBhIHN1ZGRl biwgeW91IGd1eXMgYXJlIHNheWluZywNCj4+IGxldCdzIGFwcGx5IHRoaXMgc29waGlzdGljYXRl ZCBtZXRob2QgdG8gdGhlIGRpZmZlcmVudCBwcm9ibGVtLCBieQ0KPj4gZHJvcHBpbmcgcXVpdGUg c29tZSBjb21sZXhpdHkgYW5kIHR3aXN0dGluZyB0aGUgbWVjaGFuaXNtIGEgYml0LCBzZWVtcw0K Pj4gaXQgbWF5IHdvcmsuIENvbnNpZGVyaW5nIHRoZSBwcm9ibGVtIGFyZSBub3cgc29sdmVkIGlu IGEgbW9yZSBwdXJlIGFuZA0KPj4gY2xlYXIgd2F5LCBJJ20gc29ycnkgYnV0IEkgQ0FOTk9UIGZv bGxvdyB0aGUgbG9naWMgaGVyZS4NCj4+DQo+PiBPbiBTdW4sIEp1biAyNCwgMjAxMiBhdCAyOjAw IFBNLCBTYXRvcnUgTWF0c3VzaGltYQ0KPj4gPHNhdG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNvbTxt YWlsdG86c2F0b3J1Lm1hdHN1c2hpbWFAZ21haWwuY29tPj4gd3JvdGU6DQo+Pj4gSGkgUWlvbmcs DQo+Pj4NCj4+PiBJJ20gZGlzYWdyZWUgd2l0aCB5b3VyIG9waW5pb24uDQo+Pj4NCj4+PiAxLiBS ZWNlbnQgY2hhbmdlcyBpbiBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBoYXMgYmVlbiBkaXNj dXNzZWQgaW4NCj4+PiB0aGUgRFQuDQo+Pj4gMi4gTUFQIGp1c3QgY292ZXJzIHNvIGNhbGxlZCAn MToxIG1vZGUnIHdpdGggbW9zdCBncmFudWxhciBtYXBwaW5nIHJ1bGUNCj4+PiBmb3IgQ0VzIHBy b3Zpc2lvbmluZywgd2hpY2ggaXMgYXMgb25lIG9mIGl0cyBjaGFyYWN0ZXJpc3RpY3MuDQo+Pj4g My4gVGhlIG1vdGl2YXRpb24gZHJhZnQgZG9lcyBub3QgcmVzdHJpY3QgdGhhdCBhcyB5b3Ugc3Rh dGVkLCBqdXN0DQo+Pj4gJ2Fzc3VtZWQnLCBpdCdzIG5laXRoZXIgJ01VU1QnIG5vciAnU0hPVUxE Jy4NCj4+Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiAtLXNhdG9ydQ0KPj4+DQo+Pj4NCj4+PiBP biAyMDEyLzA2LzI0LCBhdCAxNDozNSwgUWlvbmcgd3JvdGU6DQo+Pj4NCj4+Pj4gSGkgYWxsLA0K Pj4+Pg0KPj4+PiBBcyB3ZSBhbGwga25vdywgb25jZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IGlzIGFk b3B0ZWQgYXMgYSBXRyBkcmFmdCwgaXQNCj4+Pj4gaXMgb3duZWQgYnkgdGhlIHdob2xlIFdHLCBy YXRoZXIgdGhhbiBqdXN0IHRoZSBlZGl0b3JzLiBKdXN0IGFzIFJlbWkNCj4+Pj4gc2FpZCwgdGhl IG5vcm1hbCBwcm9jZWR1cmUgdG8gZm9sbG93IGlzIHRvIHJlYWNoIFdHIGNvbnNlbnN1cyBfYmVm b3JlXw0KPj4+PiBwb3N0aW5nIGEgbmV3bHkgZWRpdGVkIHZlcnNpb24uDQo+Pj4+DQo+Pj4+IEZy b20gZHJhZnQtbWR0LXNvZnR3aXJlLW1hcHBpbmctYWRkcmVzcy1hbmQtcG9ydC0wMyB0bw0KPj4+ PiBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCwgdGhlcmUgYXJlIHNldmVyYWwgY2hhbmdlcyBi ZXR3ZWVuIHRoZW0uIEluDQo+Pj4+IHBhcnRpY3VsYXIsIHRoZSBuZXdseSBpbnRyb2R1Y2VkICIx OjEgbW9kZSIsIHdoaWNoIGRlY291cGxlcyBJUHY0IGFuZA0KPj4+PiBJUHY2IGFkZHJlc3Npbmcs IGhhcyBuZXZlciBiZWVuIGRpc2N1c3NlZCBvcGVubHkgaW4gdGhlIFdHIG1haWxpbmcNCj4+Pj4g bGlzdCwgb3IgZXZlbiBpbiB0aGUgTUFQIGRlc2lnbiB0ZWFtIGVpdGhlci4NCj4+Pj4NCj4+Pj4g QWN0dWFsbHksIHRoaXMgIjE6MSBtb2RlIiBpcyBhZ2FpbnN0IHRoZSBzdGF0ZWxlc3MtNHY2LW1v dGl2YXRpb24NCj4+Pj4gZHJhZnQuIFRoZSBtb3RpdmF0aW9uIGRyYWZ0IGhhcyBjbGVhcmx5IGRl ZmluZXMgdGhlICJTdGF0ZWxlc3MgNC82DQo+Pj4+IHNvbHV0aW9uIiBhcyBmb2xsb3dzOg0KPj4+ Pg0KPj4+PiBTdGF0ZWxlc3MgNC82IHNvbHV0aW9uIGRlbm90ZXMgYSBzb2x1dGlvbiB3aGljaCBk b2VzIG5vdCByZXF1aXJlIGFueQ0KPj4+PiBwZXItdXNlciBzdGF0ZSAoc2VlIFNlY3Rpb24gMi4z IG9mIFtSRkMxOTU4XSkgdG8gYmUgbWFpbnRhaW5lZCBieSBhbnkNCj4+Pj4gSVAgYWRkcmVzcyBz aGFyaW5nIGZ1bmN0aW9uIGluIHRoZSBTZXJ2aWNlIFByb3ZpZGVyJ3MgbmV0d29yay4gVGhpcw0K Pj4+PiBjYXRlZ29yeSBvZiBzb2x1dGlvbnMgYXNzdW1lcyBhIGRlcGVuZGVuY3kgYmV0d2VlbiBh biBJUHY2IHByZWZpeCBhbmQNCj4+Pj4gSVB2NCBhZGRyZXNzLg0KPj4+Pg0KPj4+PiBBRkFJSyB3 aGF0IHRoZSBXRyBoYXMgYWRvcHRlZCBNQVAgcmVsYXRlZCBkcmFmdCBpcw0KPj4+PiBkcmFmdC1t ZHQtc29mdHdpcmUtbWFwcGluZy1hZGRyZXNzLWFuZC1wb3J0LTAzLCBOT1QNCj4+Pj4gZHJhZnQt aWV0Zi1zb2Z0d2lyZS1tYXAtMDAuIEFuZCB0aGUgc3RhdGVsZXNzIHNvbHV0aW9uIHNob3VsZCDC s3Jlc3BvbnNlDQo+Pj4+IHRvIHRoZSBzb2x1dGlvbiBtb3RpdmF0aW9uIGRvY3VtZW50wrIgYWNj b3JkaW5nIHRvIHRoZSBTb2Z0d2lyZSBjaGFydGVyLg0KPj4+PiBUaGF0IG1lYW5zIGRyYWZ0LWll dGYtc29mdHdpcmUtbWFwLTAwIElTIE5PVCBRVUFMSUZJRUQgdG8gYmUgYSBXRyBkcmFmdC4NCj4+ Pj4NCj4+Pj4gV2UgY2FuIGFsbCByZWNhbGwgdGhhdCBvdXIgc29mdHdpcmUgV0cgaGFzIHdvcmtl ZCBvbiBzdGF0ZWxlc3MNCj4+Pj4gc29sdXRpb25zIGZvciBtb3JlIHRoYW4gb25lIGFuZCBhIGhh bGYgeWVhcnMsIGFuZCB3ZSBoYXZlIGFjaGlldmVkIGENCj4+Pj4gbG90IG9mIHdvcmsgd2hpY2gg aGFzIGJlZW4gZG9jdW1lbnRlZCBpbiBjaGFydGVyLCBzdGF0ZWxlc3MgbW90aXZhdGlvbiwNCj4+ Pj4gNHJkLXZhcmllbnRzLCBNQVAtMDMsIGV0Yy4gQUZBSUsgYWxsIHRoZSBhdXRob3JzIGhhdmUg a2VwdCB0aGUgYmFzaWMNCj4+Pj4gInN0YXRlbGVzcyIgcHJpbmNpcGxlIGFuZCB0aGUgTUFQIGRl c2lnbiB0ZWFtIGlzIGFsc28gd29ya2luZyBvbiBpdA0KPj4+PiB0b2dldGhlciB0byBmaW5kIGEg YmV0dGVyIGFsZ29yaXRobSwgYWRkcmVzcyBmb3JtYXQsIGV0Yy4gU28gaXQgaXMNCj4+Pj4gcmVh bGx5IG5vdCBhcHByb3ByaWF0ZSB0byBtYWtlIHN1Y2ggY2hhbmdlcyB3aGVuIE1BUCBpcyBhZG9w dGVkIGFzIGEgV0cNCj4+Pj4gaXRlbSBpbiBzdWNoIGEgc2hvcnQgdGltZS4NCj4+Pj4NCj4+Pj4g RnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBjYW4gb25s eSBiZSByZWdhcmRlZA0KPj4+PiBhcyBkcmFmdC1YWC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3Mt YW5kLXBvcnQtMDQuIEl0IGlzIG5vdCBldmVuIHRoZQ0KPj4+PiBvdXRwdXQgb2YgTUFQIGRlc2ln biB0ZWFtLg0KPj4+Pg0KPj4+PiBCZXN0IHdpc2hlcw0KPj4+Pg0KPj4+PiA9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj4+IFFpb25nIFN1bg0KPj4+PiBD aGluYSBUZWxlY29tIEJlaWppbmcgUmVzZWFyY2ggSW5zdGl0dWRlDQo+Pj4+DQo+Pj4+DQo+Pj4+ IE9wZW4gc291cmNlIGNvZGU6DQo+Pj4+IGxpZ2h0d2VpZ2h0IDRvdmVyNjogaHR0cDovL3NvdXJj ZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni8NCj4+Pj4gUENQLW5hdGNvb3JkOiBodHRwOi8vc291 cmNlZm9yZ2UubmV0L3Byb2plY3RzL3BjcHBvcnRzZXRkZW1vLw0KPj4+PiA9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBTb2Z0d2ly ZXMgbWFpbGluZyBsaXN0DQo+Pj4+IFNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86U29mdHdpcmVz QGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nv ZnR3aXJlcw0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+Pj4gU29mdHdpcmVzQGlldGYu b3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+PiBTb2Z0 d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpT b2Z0d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29m dHdpcmVzQGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KDQo= --_000_B83EBE2D2D784A1BB83E48946C43A1CDipinfusioncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4D773A5D0856264C852179CE25CC2A72@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxiYXNlIGhyZWY9IngtbXNnOi8vMTgzLyI+DQo8 L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+DQpI aSBRaSwNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkV2ZW4gdGhvdWdoIHRoZXJlIGFyZSBhIGJ1 bmNoIG9mIG1hcHBpbmcgcnVsZXMsIGVhY2ggbWFwcGluZyBydWxlIGhhcyBubyBzdGF0ZS4gU2lu Y2UgZWFjaCBtYXBwaW5nIHJ1bGVzIGlzIHNldCBtYW51YWxseSwgQlIgZG9lcyBub3QgbWFpbnRh aW4gZWFjaCBtYXBwaW5nIHJ1bGUgYW5kIGp1c3Qgc3RvcmUgdGhlbSBpbiBpdHMgb3duIG1lbW9y eS4gU28sIEkgYW0gbm90IHN1cmUgd2h5IHlvdSBhcmUgY2FsbGluZyB0aGUgJnF1b3Q7c3RhdGUm cXVvdDsgaWYNCiB0aGVyZSBhcmUgYSBidW5jaCBvZiBtYXBwaW5nIHJ1bGVzLiBJZiB5b3UgYXJl IHNheWluZyB0aGF0LCBkbyB5b3UgYXNzdW1lIGhvdyBtYW55IGVudHJpZXMgc2hvdWxkIGJlIGV4 aXN0ZWQgaW4gdGhlIHRhYmxlIGluIG9yZGVyIHRvIGNhbGwgaXQgdG8gdGhlICZxdW90O3N0YXRl JnF1b3Q7LiBGcm9tIHRoZSBpbXBsZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSwgZXZlbiB0aG91Z2gg dGhlcmUgYXJlIDEwMDAwMDAwIGVudHJpZXMgaW4gdGhlIHRhYmxlLCB0aGUgcHJvYmxlbQ0KIGlz IGp1c3QgaG93IG11Y2ggbWVtb3J5IGlzIG5lZWRlZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+VGV0c3V5YSBNdXJha2FtaSZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5PbiAyMDEyLzA2LzI0LCBhdCAy Mzo1MSwgUWkgU3VuIHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHls ZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgb3JwaGFuczogMjsgdGV4dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29y YXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPg0KPGRp diBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuNTsgZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsgY29s b3I6IHJnYigwLCAwLCAxMjgpOyBmb250LXNpemU6IDEwLjVwdDsgbWFyZ2luLXRvcDogMTBweDsg bWFyZ2luLXJpZ2h0OiAxMHB4OyBtYXJnaW4tYm90dG9tOiAxMHB4OyBtYXJnaW4tbGVmdDogMTBw eDsgIj4NCjxkaXY+SGkgU2F0b3J1LDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SW4g TUFQIDE6MSBtb2RlLCBpZiB0aGVyZSBhcmUgMTAwMDAwMDAgc3Vic2NyaWJlcnMsIHRoZXJlIHdv dWxkIGJlIDEwMDAwMDAwIE1BUCBkb21haW5zIHdoaWNoIGEgQlIgaGFzIHRvIG1hbmFnZS4gSSB0 aGluayB0aGF0IHdpbGwgY3JlYXRlIGEgaHVnZSBtYXBwaW5nIHRhYmxlIG9uIHRoZSBCUiwgd2hp Y2ggaXMgY2FsbGVkICdzdGF0ZScgdGhhdCBzdGF0ZWZ1bCBzb2x1dGlvbnMgZGVhbCB3aXRoLjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+QmVzdCBSZWdhcmRzITwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxociBhbGlnbj0ibGVmdCIgY29sb3I9IiNiNWM0ZGYiIHNpemU9IjEiIHN0 eWxlPSJ3aWR0aDogMjEwcHg7IGhlaWdodDogMXB4OyAiPg0KPGRpdj48c3Bhbj5RaSBTdW48L3Nw YW4+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLWJvdHRvbS13 aWR0aDogbWVkaXVtOyBib3JkZXItYm90dG9tLXN0eWxlOiBub25lOyBib3JkZXItYm90dG9tLWNv bG9yOiBpbml0aWFsOyBib3JkZXItbGVmdC13aWR0aDogbWVkaXVtOyBib3JkZXItbGVmdC1zdHls ZTogbm9uZTsgYm9yZGVyLWxlZnQtY29sb3I6IGluaXRpYWw7IHBhZGRpbmctYm90dG9tOiAwY207 IHBhZGRpbmctbGVmdDogMGNtOyBwYWRkaW5nLXJpZ2h0OiAwY207IGJvcmRlci10b3AtY29sb3I6 IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBib3JkZXItdG9wLXN0 eWxlOiBzb2xpZDsgYm9yZGVyLXJpZ2h0LXdpZHRoOiBtZWRpdW07IGJvcmRlci1yaWdodC1zdHls ZTogbm9uZTsgYm9yZGVyLXJpZ2h0LWNvbG9yOiBpbml0aWFsOyBwYWRkaW5nLXRvcDogM3B0OyAi Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1ib3R0b206IDhweDsgcGFkZGluZy1sZWZ0OiA4cHg7IHBh ZGRpbmctcmlnaHQ6IDhweDsgYmFja2dyb3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1h dHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3Vu ZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjM5LCAyMzksIDIzOSk7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTJweDsgcGFkZGluZy10b3A6IDhweDsgYmFj a2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5p dGlhbCBpbml0aWFsOyAiPg0KPGRpdj48Yj5Gcm9tOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86 c2F0b3J1Lm1hdHN1c2hpbWFAZ21haWwuY29tIj5TYXRvcnUgTWF0c3VzaGltYTwvYT48L2Rpdj4N CjxkaXY+PGI+RGF0ZTo8L2I+Jm5ic3A7MjAxMi0wNi0yNSZuYnNwOzEwOjI3PC9kaXY+DQo8ZGl2 PjxiPlRvOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86WWl1X0xlZUBDYWJsZS5Db21jYXN0LmNv bSI+TGVlLCBZaXU8L2E+PC9kaXY+DQo8ZGl2PjxiPkNDOjwvYj4mbmJzcDs8YSBocmVmPSJtYWls dG86c29mdHdpcmVzQGlldGYub3JnIj5zb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y3Vp eW9uZ0BnbWFpbC5jb20iPllvbmcgQ3VpPC9hPjwvZGl2Pg0KPGRpdj48Yj5TdWJqZWN0OjwvYj4m bmJzcDtSZTogW1NvZnR3aXJlc10gW1NvZnR3aXJlXSBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0w MCBkb2VzIE5PVCByZWZsZWN0IHRoZSBjb25zZW5zdXMgZnJvbSB0aGUgV0c8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj5IaSZuYnNwO1lpdSw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2Pk5vLCZuYnNwO3RoYXQncyZuYnNwO2EmbmJzcDttaXN1bmRlcnN0YW5kaW5nLjwv ZGl2Pg0KPGRpdj5DdXJyZW50Jm5ic3A7TUFQJm5ic3A7c3BlY2lmeSZuYnNwO3RoZSZuYnNwO2Nh c2UmbmJzcDtmb3ImbmJzcDtlYS1sZW4mbmJzcDtpcyZuYnNwOyd6ZXJvJy4mbmJzcDtJdCZuYnNw O2lzJm5ic3A7J3Blci1zdWJzY3JpYmVyJm5ic3A7bWFwcGluZycmbmJzcDtpbiZuYnNwO3N0YXRl bGVzcyZuYnNwO21hbm5lciwmbmJzcDtub3QmbmJzcDt0byZuYnNwO2ludHJvZHVjZSZuYnNwOydw ZXItZmxvdyZuYnNwO05BVCZuYnNwO2JpbmRpbmcnJm5ic3A7b3ImbmJzcDsncGVyLXN1YnNjcmli ZXImbmJzcDtzdGF0ZSZuYnNwO29uJm5ic3A7ZGVtYW5kJy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2PmNoZWVycyw8L2Rpdj4NCjxkaXY+LS1zYXRvcnU8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2Pk9uJm5ic3A7MjAxMi8wNi8yNSwmbmJzcDthdCZuYnNwOzI6MzIsJm5ic3A7 TGVlLCZuYnNwO1lpdSZuYnNwO3dyb3RlOjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+ Jmd0OyZuYnNwO0RlYXImbmJzcDtTYXRvcnUmbmJzcDthbmQmbmJzcDtNQVAtRFQ8L2Rpdj4NCjxk aXY+Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7SSZuYnNwO2VjaG8mbmJzcDt3aGF0 Jm5ic3A7UGVuZyZuYnNwO2FuZCZuYnNwO1Fpb25nJm5ic3A7c2FpZC4mbmJzcDtXaGVuJm5ic3A7 dGhlJm5ic3A7V0cmbmJzcDthZ3JlZWQmbmJzcDt3b3JraW5nJm5ic3A7b24mbmJzcDt0aGU8L2Rp dj4NCjxkaXY+Jmd0OyZuYnNwO3N0YXRlbGVzcyZuYnNwO3NvbHV0aW9uLCZuYnNwO2l0Jm5ic3A7 d2FzJm5ic3A7dmVyeSZuYnNwO2NsZWFyJm5ic3A7c3RhdGVkJm5ic3A7dGhhdCZuYnNwO3RoZSZu YnNwO3NvbHV0aW9uJm5ic3A7d291bGQmbmJzcDtub3Q8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwO21h aW50YWluJm5ic3A7c3RhdGVzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtuZXR3b3JrLiZuYnNwO0lm Jm5ic3A7dGhlJm5ic3A7MToxJm5ic3A7bW9kZSZuYnNwO2NoYW5nZWQmbmJzcDt0aGlzLCZuYnNw O3RoaXMmbmJzcDtubzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7bG9uZ2VyJm5ic3A7bWF0Y2hlZCZu YnNwO3RoZSZuYnNwO3JlcXVpcmVtZW50cyZuYnNwO3N0YXRlZCZuYnNwO2luJm5ic3A7dGhlJm5i c3A7c3RhdGVsZXNzJm5ic3A7bW90aXZhdGlvbiZuYnNwO2RyYWZ0LDwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7dGh1cywmbmJzcDtpdCZuYnNwO3dvdWxkJm5ic3A7ZGlzcXVhbGlmeSZuYnNwO01BUCZu YnNwO2FzJm5ic3A7YSZuYnNwO3NvbHV0aW9uJm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7bW90aXZh dGlvbiZuYnNwO2RyYWZ0LjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsm bmJzcDtBRkFJSywmbmJzcDt0aGUmbmJzcDtNQVAmbmJzcDtEZXNpZ24mbmJzcDtUZWFtJm5ic3A7 Y291bGQmbmJzcDtwcm9wb3NlJm5ic3A7YSZuYnNwO2NoYW5nZSwmbmJzcDtidXQmbmJzcDtzdWNo Jm5ic3A7YSZuYnNwO2RyYW1hdGljPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDtjaGFuZ2UmbmJzcDti eSZuYnNwO2ludHJvZHVjaW5nJm5ic3A7c3RhdGVzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtuZXR3 b3JrJm5ic3A7d291bGQmbmJzcDtyZXF1aXJlJm5ic3A7V0cmbmJzcDthcHByb3ZhbC4mbmJzcDtJ PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDt3b3VsZCZuYnNwO2xpa2UmbmJzcDt0aGUmbmJzcDtjaGFp cnMmbmJzcDt0byZuYnNwO2NsYXJpZnkmbmJzcDt0aGlzLjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7 PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDtUaGFua3MsPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDtZaXU8 L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2 PiZndDsmbmJzcDtPbiZuYnNwOzYvMjQvMTImbmJzcDsxMjoyMSZuYnNwO1BNLCZuYnNwOyZxdW90 O1BlbmcmbmJzcDtXdSZxdW90OyZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86cGVuZ3d1LnRodUBn bWFpbC5jb20iPnBlbmd3dS50aHVAZ21haWwuY29tPC9hPiZndDsmbmJzcDt3cm90ZTo8L2Rpdj4N CjxkaXY+Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO0hpJm5ic3A7UWlvbmcs Jm5ic3A7U2F0b3J1Jm5ic3A7YW5kJm5ic3A7YWxsLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNw OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO0kmbmJzcDtzaG91bGQmbmJzcDt0aGFuayZuYnNw O1Fpb25nJm5ic3A7Zm9yJm5ic3A7cG9pbnRpbmcmbmJzcDt0aGlzJm5ic3A7b3V0LiZuYnNwO0km bmJzcDtnb3R0YSZuYnNwO3NheSZuYnNwO0knbSZuYnNwO2EmbmJzcDtiaXQmbmJzcDtzaG9ja2Vk LjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO0lmJm5ic3A7SSZuYnNwO3VuZGVyc3RhbmQmbmJz cDt0aGUmbmJzcDtwcm9jZWR1cmVzJm5ic3A7b2YmbmJzcDtJRVRGJm5ic3A7Y29ycmVjdGx5LCZu YnNwO2EmbmJzcDtXRyZuYnNwO2RvY3VtZW50Jm5ic3A7c2hvdWxkPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7Jm5ic3A7cmVmbGVjdCZuYnNwO3RoZSZuYnNwO2NvbnNlbnN1cyZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7V0cuJm5ic3A7TUFQJm5ic3A7aXMmbmJzcDthcHByb3ZlZCZuYnNwO2J5Jm5ic3A7dGhl Jm5ic3A7V0cmbmJzcDthcyZuYnNwO2E8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtzdGF0ZWxl c3MmbmJzcDtzb2x1dGlvbi4mbmJzcDtBcyZuYnNwO2EmbmJzcDtwYXJ0aWNpcGF0b3ImbmJzcDtp biZuYnNwO1NvZnR3aXJlLCZuYnNwO0kmbmJzcDtkaWRuJ3QmbmJzcDtnZXQmbmJzcDt0aGU8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2FueXdoZXJlJm5ic3A7dGhh dCZuYnNwO3RoZSZuYnNwO01BUCZuYnNwO1dHJm5ic3A7ZG9jdW1lbnQmbmJzcDt3b3VsZCZuYnNw O2NvdmVyJm5ic3A7dGhlPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7c28tY2FsbGVkJm5ic3A7 MToxLCZuYnNwO2luJm5ic3A7ZmFjdCZuYnNwO3Blci11c2VyJm5ic3A7c3RhdGVmdWwmbmJzcDtt b2RlJm5ic3A7YmVmb3JlJm5ic3A7aXQmbmJzcDt3YXMmbmJzcDtyZWxlYXNlZCw8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmbmJzcDtub3QmbmJzcDt0byZuYnNwO3NheSZuYnNwO2Rpc2N1c3MmbmJzcDtp biZuYnNwO3RoZSZuYnNwO1dHLiZuYnNwO0Rvbid0Jm5ic3A7dGhlJm5ic3A7V0cmbmJzcDtuZWVk Jm5ic3A7dG8mbmJzcDthcHByb3ZlJm5ic3A7c3VjaCZuYnNwO2JpZzwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZuYnNwO2NoYW5nZSZuYnNwO2FueW1vcmU/PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Tm93Jm5ic3A7bGV0Jm5ic3A7bWUmbmJzcDtwcm92 aWRlJm5ic3A7bXkmbmJzcDtpbXByZXNzaW9uJm5ic3A7YXMmbmJzcDthbiZuYnNwO291dHNpZGVy Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtNQVAmbmJzcDtEVC4mbmJzcDtZb3U8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsmbmJzcDtndXlzJm5ic3A7bWFrZSZuYnNwO2dyZWF0Jm5ic3A7ZWZmb3J0Jm5ic3A7 dG8mbmJzcDtidWlsZCZuYnNwO3RoZSZuYnNwO3NvbHV0aW9uLCZuYnNwO1RoZSZuYnNwO2FkZHJl c3MmbmJzcDtjb21wb3NpdGlvbiw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDt0aGUmbmJzcDtH TUEmbmJzcDthbGdvcml0aG0sJm5ic3A7dGhlJm5ic3A7ZGlmZmVyZW50Jm5ic3A7dHlwZXMmbmJz cDtvZiZuYnNwO2FkZHJlc3MmbmJzcDttYXBwaW5nJm5ic3A7cnVsZXMuPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7Jm5ic3A7c2hvdWxkJm5ic3A7YmUmbmJzcDtxdWl0ZSZuYnNwO2RpZmZpY3VsdCZuYnNw O3RvJm5ic3A7cHVsbCZuYnNwO3RvZ2V0aGVyJm5ic3A7c3VjaCZuYnNwO3NvcGhpc3RpY2F0ZWQm bmJzcDtpZGVhcy4mbmJzcDtJPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Z3Vlc3MmbmJzcDt0 aGF0J3MmbmJzcDt3aGF0Jm5ic3A7aXQmbmJzcDt0YWtlcyZuYnNwO3RvJm5ic3A7YWNoaWV2ZSZu YnNwO3RoZSZuYnNwO2JlbmlmaXRzJm5ic3A7b2YmbmJzcDtzdGF0ZWxlc3NuZXNzLjwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZuYnNwO0FuZCZuYnNwO0kmbmJzcDthZG1pcmUmbmJzcDt0aGF0LCZuYnNw O2JyYXZvLiZuYnNwO1RoZW4sJm5ic3A7YWxsJm5ic3A7b2YmbmJzcDthJm5ic3A7c3VkZGVuLCZu YnNwO3lvdSZuYnNwO2d1eXMmbmJzcDthcmUmbmJzcDtzYXlpbmcsPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7Jm5ic3A7bGV0J3MmbmJzcDthcHBseSZuYnNwO3RoaXMmbmJzcDtzb3BoaXN0aWNhdGVkJm5i c3A7bWV0aG9kJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtkaWZmZXJlbnQmbmJzcDtwcm9ibGVtLCZu YnNwO2J5PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7ZHJvcHBpbmcmbmJzcDtxdWl0ZSZuYnNw O3NvbWUmbmJzcDtjb21sZXhpdHkmbmJzcDthbmQmbmJzcDt0d2lzdHRpbmcmbmJzcDt0aGUmbmJz cDttZWNoYW5pc20mbmJzcDthJm5ic3A7Yml0LCZuYnNwO3NlZW1zPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7Jm5ic3A7aXQmbmJzcDttYXkmbmJzcDt3b3JrLiZuYnNwO0NvbnNpZGVyaW5nJm5ic3A7dGhl Jm5ic3A7cHJvYmxlbSZuYnNwO2FyZSZuYnNwO25vdyZuYnNwO3NvbHZlZCZuYnNwO2luJm5ic3A7 YSZuYnNwO21vcmUmbmJzcDtwdXJlJm5ic3A7YW5kPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7 Y2xlYXImbmJzcDt3YXksJm5ic3A7SSdtJm5ic3A7c29ycnkmbmJzcDtidXQmbmJzcDtJJm5ic3A7 Q0FOTk9UJm5ic3A7Zm9sbG93Jm5ic3A7dGhlJm5ic3A7bG9naWMmbmJzcDtoZXJlLjwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO09uJm5ic3A7U3Vu LCZuYnNwO0p1biZuYnNwOzI0LCZuYnNwOzIwMTImbmJzcDthdCZuYnNwOzI6MDAmbmJzcDtQTSwm bmJzcDtTYXRvcnUmbmJzcDtNYXRzdXNoaW1hPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jmx0 OzxhIGhyZWY9Im1haWx0bzpzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20iPnNhdG9ydS5tYXRz dXNoaW1hQGdtYWlsLmNvbTwvYT4mZ3Q7Jm5ic3A7d3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jmd0OyZuYnNwO0hpJm5ic3A7UWlvbmcsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwOzwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmbmJzcDtJJ20mbmJzcDtkaXNhZ3JlZSZuYnNwO3dpdGgm bmJzcDt5b3VyJm5ic3A7b3Bpbmlvbi48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwOzEuJm5ic3A7UmVjZW50Jm5ic3A7Y2hhbmdlcyZu YnNwO2luJm5ic3A7ZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAmbmJzcDtoYXMmbmJzcDtiZWVu Jm5ic3A7ZGlzY3Vzc2VkJm5ic3A7aW48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7dGhl Jm5ic3A7RFQuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwOzIuJm5ic3A7TUFQJm5ic3A7 anVzdCZuYnNwO2NvdmVycyZuYnNwO3NvJm5ic3A7Y2FsbGVkJm5ic3A7JzE6MSZuYnNwO21vZGUn Jm5ic3A7d2l0aCZuYnNwO21vc3QmbmJzcDtncmFudWxhciZuYnNwO21hcHBpbmcmbmJzcDtydWxl PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwO2ZvciZuYnNwO0NFcyZuYnNwO3Byb3Zpc2lv bmluZywmbmJzcDt3aGljaCZuYnNwO2lzJm5ic3A7YXMmbmJzcDtvbmUmbmJzcDtvZiZuYnNwO2l0 cyZuYnNwO2NoYXJhY3RlcmlzdGljcy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7My4m bmJzcDtUaGUmbmJzcDttb3RpdmF0aW9uJm5ic3A7ZHJhZnQmbmJzcDtkb2VzJm5ic3A7bm90Jm5i c3A7cmVzdHJpY3QmbmJzcDt0aGF0Jm5ic3A7YXMmbmJzcDt5b3UmbmJzcDtzdGF0ZWQsJm5ic3A7 anVzdDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmbmJzcDsnYXNzdW1lZCcsJm5ic3A7aXQncyZu YnNwO25laXRoZXImbmJzcDsnTVVTVCcmbmJzcDtub3ImbmJzcDsnU0hPVUxEJy48L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwO0Jlc3Qm bmJzcDtyZWdhcmRzLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmbmJzcDstLXNhdG9ydTwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwO09uJm5ic3A7MjAxMi8wNi8yNCwmbmJzcDth dCZuYnNwOzE0OjM1LCZuYnNwO1Fpb25nJm5ic3A7d3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7SGkmbmJzcDthbGws PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwO0FzJm5ic3A7d2UmbmJzcDthbGwmbmJzcDtrbm93LCZuYnNwO29uY2UmbmJz cDthbiZuYnNwO2luZGl2aWR1YWwmbmJzcDtkcmFmdCZuYnNwO2lzJm5ic3A7YWRvcHRlZCZuYnNw O2FzJm5ic3A7YSZuYnNwO1dHJm5ic3A7ZHJhZnQsJm5ic3A7aXQ8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwO2lzJm5ic3A7b3duZWQmbmJzcDtieSZuYnNwO3RoZSZuYnNwO3dob2xl Jm5ic3A7V0csJm5ic3A7cmF0aGVyJm5ic3A7dGhhbiZuYnNwO2p1c3QmbmJzcDt0aGUmbmJzcDtl ZGl0b3JzLiZuYnNwO0p1c3QmbmJzcDthcyZuYnNwO1JlbWk8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwO3NhaWQsJm5ic3A7dGhlJm5ic3A7bm9ybWFsJm5ic3A7cHJvY2VkdXJlJm5i c3A7dG8mbmJzcDtmb2xsb3cmbmJzcDtpcyZuYnNwO3RvJm5ic3A7cmVhY2gmbmJzcDtXRyZuYnNw O2NvbnNlbnN1cyZuYnNwO19iZWZvcmVfPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJz cDtwb3N0aW5nJm5ic3A7YSZuYnNwO25ld2x5Jm5ic3A7ZWRpdGVkJm5ic3A7dmVyc2lvbi48L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7RnJvbSZuYnNwO2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5k LXBvcnQtMDMmbmJzcDt0bzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ZHJhZnQt aWV0Zi1zb2Z0d2lyZS1tYXAtMDAsJm5ic3A7dGhlcmUmbmJzcDthcmUmbmJzcDtzZXZlcmFsJm5i c3A7Y2hhbmdlcyZuYnNwO2JldHdlZW4mbmJzcDt0aGVtLiZuYnNwO0luPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDtwYXJ0aWN1bGFyLCZuYnNwO3RoZSZuYnNwO25ld2x5Jm5ic3A7 aW50cm9kdWNlZCZuYnNwOyZxdW90OzE6MSZuYnNwO21vZGUmcXVvdDssJm5ic3A7d2hpY2gmbmJz cDtkZWNvdXBsZXMmbmJzcDtJUHY0Jm5ic3A7YW5kPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDtJUHY2Jm5ic3A7YWRkcmVzc2luZywmbmJzcDtoYXMmbmJzcDtuZXZlciZuYnNwO2Jl ZW4mbmJzcDtkaXNjdXNzZWQmbmJzcDtvcGVubHkmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO1dHJm5i c3A7bWFpbGluZzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7bGlzdCwmbmJzcDtv ciZuYnNwO2V2ZW4mbmJzcDtpbiZuYnNwO3RoZSZuYnNwO01BUCZuYnNwO2Rlc2lnbiZuYnNwO3Rl YW0mbmJzcDtlaXRoZXIuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4N CjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO0FjdHVhbGx5LCZuYnNwO3RoaXMmbmJzcDsmcXVv dDsxOjEmbmJzcDttb2RlJnF1b3Q7Jm5ic3A7aXMmbmJzcDthZ2FpbnN0Jm5ic3A7dGhlJm5ic3A7 c3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW9uPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJz cDtkcmFmdC4mbmJzcDtUaGUmbmJzcDttb3RpdmF0aW9uJm5ic3A7ZHJhZnQmbmJzcDtoYXMmbmJz cDtjbGVhcmx5Jm5ic3A7ZGVmaW5lcyZuYnNwO3RoZSZuYnNwOyZxdW90O1N0YXRlbGVzcyZuYnNw OzQvNjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7c29sdXRpb24mcXVvdDsmbmJz cDthcyZuYnNwO2ZvbGxvd3M6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO1N0YXRlbGVzcyZuYnNwOzQvNiZuYnNwO3Nv bHV0aW9uJm5ic3A7ZGVub3RlcyZuYnNwO2EmbmJzcDtzb2x1dGlvbiZuYnNwO3doaWNoJm5ic3A7 ZG9lcyZuYnNwO25vdCZuYnNwO3JlcXVpcmUmbmJzcDthbnk8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwO3Blci11c2VyJm5ic3A7c3RhdGUmbmJzcDsoc2VlJm5ic3A7U2VjdGlvbiZu YnNwOzIuMyZuYnNwO29mJm5ic3A7W1JGQzE5NThdKSZuYnNwO3RvJm5ic3A7YmUmbmJzcDttYWlu dGFpbmVkJm5ic3A7YnkmbmJzcDthbnk8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw O0lQJm5ic3A7YWRkcmVzcyZuYnNwO3NoYXJpbmcmbmJzcDtmdW5jdGlvbiZuYnNwO2luJm5ic3A7 dGhlJm5ic3A7U2VydmljZSZuYnNwO1Byb3ZpZGVyJ3MmbmJzcDtuZXR3b3JrLiZuYnNwO1RoaXM8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO2NhdGVnb3J5Jm5ic3A7b2YmbmJzcDtz b2x1dGlvbnMmbmJzcDthc3N1bWVzJm5ic3A7YSZuYnNwO2RlcGVuZGVuY3kmbmJzcDtiZXR3ZWVu Jm5ic3A7YW4mbmJzcDtJUHY2Jm5ic3A7cHJlZml4Jm5ic3A7YW5kPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7Jmd0OyZndDsmbmJzcDtJUHY0Jm5ic3A7YWRkcmVzcy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QUZBSUsmbmJz cDt3aGF0Jm5ic3A7dGhlJm5ic3A7V0cmbmJzcDtoYXMmbmJzcDthZG9wdGVkJm5ic3A7TUFQJm5i c3A7cmVsYXRlZCZuYnNwO2RyYWZ0Jm5ic3A7aXM8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwO2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBvcnQtMDMsJm5i c3A7Tk9UPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtkcmFmdC1pZXRmLXNvZnR3 aXJlLW1hcC0wMC4mbmJzcDtBbmQmbmJzcDt0aGUmbmJzcDtzdGF0ZWxlc3MmbmJzcDtzb2x1dGlv biZuYnNwO3Nob3VsZCZuYnNwO8KzcmVzcG9uc2U8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7c29sdXRpb24mbmJzcDttb3RpdmF0aW9uJm5ic3A7ZG9j dW1lbnTCsiZuYnNwO2FjY29yZGluZyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7U29mdHdpcmUmbmJz cDtjaGFydGVyLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7VGhhdCZuYnNwO21l YW5zJm5ic3A7ZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAmbmJzcDtJUyZuYnNwO05PVCZuYnNw O1FVQUxJRklFRCZuYnNwO3RvJm5ic3A7YmUmbmJzcDthJm5ic3A7V0cmbmJzcDtkcmFmdC48L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7V2UmbmJzcDtjYW4mbmJzcDthbGwmbmJzcDtyZWNhbGwmbmJzcDt0aGF0Jm5ic3A7 b3VyJm5ic3A7c29mdHdpcmUmbmJzcDtXRyZuYnNwO2hhcyZuYnNwO3dvcmtlZCZuYnNwO29uJm5i c3A7c3RhdGVsZXNzPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtzb2x1dGlvbnMm bmJzcDtmb3ImbmJzcDttb3JlJm5ic3A7dGhhbiZuYnNwO29uZSZuYnNwO2FuZCZuYnNwO2EmbmJz cDtoYWxmJm5ic3A7eWVhcnMsJm5ic3A7YW5kJm5ic3A7d2UmbmJzcDtoYXZlJm5ic3A7YWNoaWV2 ZWQmbmJzcDthPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtsb3QmbmJzcDtvZiZu YnNwO3dvcmsmbmJzcDt3aGljaCZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtkb2N1bWVudGVkJm5i c3A7aW4mbmJzcDtjaGFydGVyLCZuYnNwO3N0YXRlbGVzcyZuYnNwO21vdGl2YXRpb24sPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs0cmQtdmFyaWVudHMsJm5ic3A7TUFQLTAzLCZu YnNwO2V0Yy4mbmJzcDtBRkFJSyZuYnNwO2FsbCZuYnNwO3RoZSZuYnNwO2F1dGhvcnMmbmJzcDto YXZlJm5ic3A7a2VwdCZuYnNwO3RoZSZuYnNwO2Jhc2ljPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsmcXVvdDtzdGF0ZWxlc3MmcXVvdDsmbmJzcDtwcmluY2lwbGUmbmJzcDthbmQm bmJzcDt0aGUmbmJzcDtNQVAmbmJzcDtkZXNpZ24mbmJzcDt0ZWFtJm5ic3A7aXMmbmJzcDthbHNv Jm5ic3A7d29ya2luZyZuYnNwO29uJm5ic3A7aXQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwO3RvZ2V0aGVyJm5ic3A7dG8mbmJzcDtmaW5kJm5ic3A7YSZuYnNwO2JldHRlciZuYnNw O2FsZ29yaXRobSwmbmJzcDthZGRyZXNzJm5ic3A7Zm9ybWF0LCZuYnNwO2V0Yy4mbmJzcDtTbyZu YnNwO2l0Jm5ic3A7aXM8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO3JlYWxseSZu YnNwO25vdCZuYnNwO2FwcHJvcHJpYXRlJm5ic3A7dG8mbmJzcDttYWtlJm5ic3A7c3VjaCZuYnNw O2NoYW5nZXMmbmJzcDt3aGVuJm5ic3A7TUFQJm5ic3A7aXMmbmJzcDthZG9wdGVkJm5ic3A7YXMm bmJzcDthJm5ic3A7V0c8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO2l0ZW0mbmJz cDtpbiZuYnNwO3N1Y2gmbmJzcDthJm5ic3A7c2hvcnQmbmJzcDt0aW1lLjwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtG cm9tJm5ic3A7dGhpcyZuYnNwO3BlcnNwZWN0aXZlLCZuYnNwO2RyYWZ0LWlldGYtc29mdHdpcmUt bWFwLTAwJm5ic3A7Y2FuJm5ic3A7b25seSZuYnNwO2JlJm5ic3A7cmVnYXJkZWQ8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO2FzJm5ic3A7ZHJhZnQtWFgtc29mdHdpcmUtbWFwcGlu Zy1hZGRyZXNzLWFuZC1wb3J0LTA0LiZuYnNwO0l0Jm5ic3A7aXMmbmJzcDtub3QmbmJzcDtldmVu Jm5ic3A7dGhlPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtvdXRwdXQmbmJzcDtv ZiZuYnNwO01BUCZuYnNwO2Rlc2lnbiZuYnNwO3RlYW0uPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO0Jlc3QmbmJzcDt3 aXNoZXM8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7UWlvbmcmbmJzcDtTdW48 L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO0NoaW5hJm5ic3A7VGVsZWNvbSZuYnNw O0JlaWppbmcmbmJzcDtSZXNlYXJjaCZuYnNwO0luc3RpdHVkZTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4N CjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO09wZW4mbmJzcDtzb3VyY2UmbmJzcDtjb2RlOjwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7bGlnaHR3ZWlnaHQmbmJzcDs0b3ZlcjY6 Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni8iPmh0 dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYvPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7UENQLW5hdGNvb3JkOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9zb3Vy Y2Vmb3JnZS5uZXQvcHJvamVjdHMvcGNwcG9ydHNldGRlbW8vIj5odHRwOi8vc291cmNlZm9yZ2Uu bmV0L3Byb2plY3RzL3BjcHBvcnRzZXRkZW1vLzwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwO1NvZnR3aXJlcyZuYnNwO21haWxpbmcmbmJzcDtsaXN0PC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGlldGYu b3JnIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsm bmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3 aXJlcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8L2E+ PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm bmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmbmJzcDtTb2Z0d2lyZXMmbmJzcDttYWlsaW5nJm5ic3A7bGlz dDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmbmJzcDs8YSBocmVmPSJtYWlsdG86U29mdHdpcmVz QGlldGYub3JnIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0 OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29m dHdpcmVzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwv YT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO1NvZnR3aXJlcyZu YnNwO21haWxpbmcmbmJzcDtsaXN0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7PGEgaHJlZj0i bWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVzQGlldGYub3JnPC9hPjwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc29mdHdpcmVzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NvZnR3aXJlczwvYT48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8ZGl2PlNvZnR3aXJl cyZuYnNwO21haWxpbmcmbmJzcDtsaXN0PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Im1haWx0bzpTb2Z0 d2lyZXNAaWV0Zi5vcmciPlNvZnR3aXJlc0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPC9hPjwvZGl2Pg0KPC9k aXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N ClNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGll dGYub3JnIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPC9hPjwvZGl2Pg0KPC9zcGFuPjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B83EBE2D2D784A1BB83E48946C43A1CDipinfusioncom_-- From satoru.matsushima@gmail.com Mon Jun 25 02:28: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 4DD8E21F84B3 for ; Mon, 25 Jun 2012 02:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.375 X-Spam-Level: X-Spam-Status: No, score=-3.375 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEMApffLEnOZ for ; Mon, 25 Jun 2012 02:28:10 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77B0E21F8466 for ; Mon, 25 Jun 2012 02:28:10 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6365947pbc.31 for ; Mon, 25 Jun 2012 02:28:10 -0700 (PDT) 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=79UW1vj6sZuo30e0wFhj7QkeiqpaiuTusgVLYaZcNl0=; b=hGEVIXbM24dsKHuB1j60JJjd8yYrHQcVim5RZ8W3Tom4QvhGb1+JZR0T8paG7lYYqP Bhp1l810VLGUDOYUvIJ++YgFtjxX3/4EQBELIsHthuPRA9Jz2otFqzBqzby4urW92Mw4 7wxh5kewyfmaRNOkbECNfprAn+YKlICI6fOi9nkk2S4hc7CfII20vJ37GdNMs98nvKz2 9vjl/NMghwlP+gvx1Xy+Bv2dcOGeBrs59DUY2Qt3K9NmGVZXCx0kvr3lKKrG42gPXsPe BtrGdoJNtfxGaezp4DP/hcdbEfm2U0jTRFT2ecCT/28bJbUQ/dtfJFghPBREK8nJs009 p4VQ== Received: by 10.68.132.166 with SMTP id ov6mr39531937pbb.24.1340616490337; Mon, 25 Jun 2012 02:28:10 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id na10sm8001101pbc.23.2012.06.25.02.28.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 02:28:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 18:27:55 +0900 Content-Transfer-Encoding: 7bit Message-Id: <3CB66B2A-3462-4415-88D3-4435238AF9F7@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <07698BA1-CBEE-45E3-9CE2-B0ED530EFE93@gmail.com> <68F1620B-02AC-4AC0-8B3F-A9FE2620BBB3@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:28:11 -0000 On 2012/06/25, at 18:22, Peng Wu wrote: > This is ... ... > > Just take a look at the title of slide 15: so you are for the > statement of "MAP is a solution of per subscriber mappings on CPE"? > ??? --satoru From pengwu.thu@gmail.com Mon Jun 25 02:34:01 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 6F89A21F8474 for ; Mon, 25 Jun 2012 02:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QotNXdVjSaCq for ; Mon, 25 Jun 2012 02:34:00 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDA9521F846A for ; Mon, 25 Jun 2012 02:34:00 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2096576vcq.31 for ; Mon, 25 Jun 2012 02:34:00 -0700 (PDT) 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:content-transfer-encoding; bh=9e7s2eINxRLpj93I0vu7gn97HTH3ldiz6U9bfmUkqZI=; b=c2e0whHpS8Z/mx3K2f0JtjPMAwdFCgv4UBnzqzhy7Pu6oB0GNOmuX4tTbpj/0TJJyD L1apjwCNGE/Emuf2gbJ44dvzqR+FzIuQc7TsyhLTur9spwYvZGc1K+DnzUwyntNeB1qk dVzh5TAMC9D5ZYB5JhJvCplaINC0ToehdjrxInRnhifnF4Hfa9xCC9CyoPr8S9PnFrgg peyQlMk2qBhtvHkM5YixCLtotoOd0Jm8jtIag8Heug1GlPEmpmiZeO5h+3XBFJ0YaJNW X0Z1O0VLRQEiQnGcUMqA3c3Vgk1lQBWDl2bwQI+LTX0TFjnUCBYdvv26vYS4LYrwGZ7W nTAg== MIME-Version: 1.0 Received: by 10.52.19.232 with SMTP id i8mr6101111vde.38.1340616840334; Mon, 25 Jun 2012 02:34:00 -0700 (PDT) Received: by 10.52.28.84 with HTTP; Mon, 25 Jun 2012 02:34:00 -0700 (PDT) In-Reply-To: <570C97A3-D641-47EB-B0EB-B75ECD7E9EC4@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <97A4D74A-A531-4F83-B281-86973A3139A5@gmail.com> <570C97A3-D641-47EB-B0EB-B75ECD7E9EC4@gmail.com> Date: Mon, 25 Jun 2012 17:34:00 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:34:01 -0000 Satoru, On Mon, Jun 25, 2012 at 5:05 PM, Satoru Matsushima wrote: > Hi Peng, > > On 2012/06/25, at 17:50, Peng Wu wrote: > >>> Hmm, I've read 'draft-cui-softwire-b4-translated-ds-lite' as you called= 'lightweight 4over6'. LW46 for short, it looks me that MAP just provides L= W46 a provisioning means which would be described in the section 5, or appe= ndix section because following text described in section 5: >>> >>> "Other optional alternatives to retrieve the public address and port- >>> =A0set also exist. =A0The specific protocol extensions are out of scope= in >>> =A0this document, however some alternatives are mentioned in the Append= ix >>> =A0section." >> Let me take a step further following your direction: >> You are saying MAP is a provisioning mean in lw4over6. Then, what exactl= y? >> With IPv4-IPv6 addressing independency, you proivde an IPv4 address >> and port set, within another DHCPv6 option? >> No BMR, No FMR, No embedding address. Look at what's left. how is this >> even similar to MAP? > > Let's think that a CE provisioned with following BMR comes from MAP DHCPv= 6 options. > > BMR: > =A0o Rule-ipv6-prefix =A0: {exact matched with CE's delegated prefix} > =A0o Rule-ipv4-prefix =A0: x.x.x.x/32 > =A0o EA-length =A0 =A0 =A0 =A0 : 0 > =A0o Port-param option : {PSID/length} > > This BMR could be a LW46 provisioning means. Again, all the information needed is the IPv4 address and port set. 1) The item like rule-ipv6-prefix is not needed at all. 2) Port set or PSID still needs extra provisioning (while in regular MAP it's embedded in IPv6 address) So why make it so difficult and obscure From Tetsuya.Murakami@ipinfusion.com Mon Jun 25 02:36:38 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 A14EA21F846A for ; Mon, 25 Jun 2012 02:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxwTfEcEv8hG for ; Mon, 25 Jun 2012 02:36:34 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 47C6C21F8474 for ; Mon, 25 Jun 2012 02:36:34 -0700 (PDT) Received: from mail85-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 09:34:56 +0000 Received: from mail85-tx2 (localhost [127.0.0.1]) by mail85-tx2-R.bigfish.com (Postfix) with ESMTP id 0ADF1160125; Mon, 25 Jun 2012 09:34:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371Ic89bh936eI1432I1418Ic857h4015I14ffIzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25he5bhf0ahbe3k35h) Received-SPF: pass (mail85-tx2: domain of ipinfusion.com designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=BY2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail85-tx2 (localhost.localdomain [127.0.0.1]) by mail85-tx2 (MessageSwitch) id 1340616893254167_1731; Mon, 25 Jun 2012 09:34:53 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.239]) by mail85-tx2.bigfish.com (Postfix) with ESMTP id 313726004B; Mon, 25 Jun 2012 09:34:53 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 09:34:51 +0000 Received: from BY2PRD0510MB388.namprd05.prod.outlook.com ([169.254.3.207]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0164.004; Mon, 25 Jun 2012 09:36:28 +0000 From: Tetsuya Murakami To: Tetsuya Murakami Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNUrX+9LPZDaT6BEm6oFMWf0wOkA== Date: Mon, 25 Jun 2012 09:36:28 +0000 Message-ID: <97C30DD3-6C2B-421B-A0BE-BCA68C9AAF28@ipinfusion.com> References: , <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> 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: multipart/alternative; boundary="_000_97C30DD36C2B421BA0BEBCA68C9AAF28ipinfusioncom_" MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:36:38 -0000 --_000_97C30DD36C2B421BA0BEBCA68C9AAF28ipinfusioncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUWksDQoNCkluIGFkZGl0aW9uLCBvdXIgTUFQIGltcGxlbWVudGF0aW9uIGNhbiBoYW5kbGUg c3VjaCBhIGJ1bmNoIG9mIGVudHJpZXMuIE9mIGNvdXJzZSwgaXQgcmVxdWlyZXMgZW5vdWdoIG1l bW9yeSBpbiBvcmRlciB0byBzdG9yZSBhbGwgb2YgdGhlbSBpbiBpdHMgb3duIG1lbW9yeS4gQnV0 IEkgY291bGQgbm90IHNlZSBhbnkgb3RoZXIgcHJvYmxlbXMgZXhjZXB0IHJlcXVpcmVkIG1lbW9y eSBzaXplLiBBbHNvLCBlYWNoIGVudHJ5IGlzIHN0b3JlZCBzdGF0aWNhbGx5IGFuZCBzbyBNQVAg aW1wbGVtZW50YXRpb24gZG9lcyBub3QgbWFpbnRhaW4gdGhlICJzdGF0ZSIgZm9yIGVhY2ggZW50 cnkuDQoNClRoYW5rcywNClRldHN1eWEgTXVyYWthbWkNCg0KT24gMjAxMi8wNi8yNSwgYXQgMjoy NywgVGV0c3V5YSBNdXJha2FtaSB3cm90ZToNCg0KSGkgUWksDQoNCkV2ZW4gdGhvdWdoIHRoZXJl IGFyZSBhIGJ1bmNoIG9mIG1hcHBpbmcgcnVsZXMsIGVhY2ggbWFwcGluZyBydWxlIGhhcyBubyBz dGF0ZS4gU2luY2UgZWFjaCBtYXBwaW5nIHJ1bGVzIGlzIHNldCBtYW51YWxseSwgQlIgZG9lcyBu b3QgbWFpbnRhaW4gZWFjaCBtYXBwaW5nIHJ1bGUgYW5kIGp1c3Qgc3RvcmUgdGhlbSBpbiBpdHMg b3duIG1lbW9yeS4gU28sIEkgYW0gbm90IHN1cmUgd2h5IHlvdSBhcmUgY2FsbGluZyB0aGUgInN0 YXRlIiBpZiB0aGVyZSBhcmUgYSBidW5jaCBvZiBtYXBwaW5nIHJ1bGVzLiBJZiB5b3UgYXJlIHNh eWluZyB0aGF0LCBkbyB5b3UgYXNzdW1lIGhvdyBtYW55IGVudHJpZXMgc2hvdWxkIGJlIGV4aXN0 ZWQgaW4gdGhlIHRhYmxlIGluIG9yZGVyIHRvIGNhbGwgaXQgdG8gdGhlICJzdGF0ZSIuIEZyb20g dGhlIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlLCBldmVuIHRob3VnaCB0aGVyZSBhcmUgMTAw MDAwMDAgZW50cmllcyBpbiB0aGUgdGFibGUsIHRoZSBwcm9ibGVtIGlzIGp1c3QgaG93IG11Y2gg bWVtb3J5IGlzIG5lZWRlZC4NCg0KVGhhbmtzLA0KVGV0c3V5YSBNdXJha2FtaQ0KDQpPbiAyMDEy LzA2LzI0LCBhdCAyMzo1MSwgUWkgU3VuIHdyb3RlOg0KDQpIaSBTYXRvcnUsDQoNCkluIE1BUCAx OjEgbW9kZSwgaWYgdGhlcmUgYXJlIDEwMDAwMDAwIHN1YnNjcmliZXJzLCB0aGVyZSB3b3VsZCBi ZSAxMDAwMDAwMCBNQVAgZG9tYWlucyB3aGljaCBhIEJSIGhhcyB0byBtYW5hZ2UuIEkgdGhpbmsg dGhhdCB3aWxsIGNyZWF0ZSBhIGh1Z2UgbWFwcGluZyB0YWJsZSBvbiB0aGUgQlIsIHdoaWNoIGlz IGNhbGxlZCAnc3RhdGUnIHRoYXQgc3RhdGVmdWwgc29sdXRpb25zIGRlYWwgd2l0aC4NCg0KQmVz dCBSZWdhcmRzIQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUWkgU3VuDQoN CkZyb206IFNhdG9ydSBNYXRzdXNoaW1hPG1haWx0bzpzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5j b20+DQpEYXRlOiAyMDEyLTA2LTI1IDEwOjI3DQpUbzogTGVlLCBZaXU8bWFpbHRvOllpdV9MZWVA Q2FibGUuQ29tY2FzdC5jb20+DQpDQzogc29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpzb2Z0d2ly ZXNAaWV0Zi5vcmc+OyBZb25nIEN1aTxtYWlsdG86Y3VpeW9uZ0BnbWFpbC5jb20+DQpTdWJqZWN0 OiBSZTogW1NvZnR3aXJlc10gW1NvZnR3aXJlXSBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBk b2VzIE5PVCByZWZsZWN0IHRoZSBjb25zZW5zdXMgZnJvbSB0aGUgV0cNCkhpIFlpdSwNCg0KTm8s IHRoYXQncyBhIG1pc3VuZGVyc3RhbmRpbmcuDQpDdXJyZW50IE1BUCBzcGVjaWZ5IHRoZSBjYXNl IGZvciBlYS1sZW4gaXMgJ3plcm8nLiBJdCBpcyAncGVyLXN1YnNjcmliZXIgbWFwcGluZycgaW4g c3RhdGVsZXNzIG1hbm5lciwgbm90IHRvIGludHJvZHVjZSAncGVyLWZsb3cgTkFUIGJpbmRpbmcn IG9yICdwZXItc3Vic2NyaWJlciBzdGF0ZSBvbiBkZW1hbmQnLg0KDQpjaGVlcnMsDQotLXNhdG9y dQ0KDQpPbiAyMDEyLzA2LzI1LCBhdCAyOjMyLCBMZWUsIFlpdSB3cm90ZToNCg0KPiBEZWFyIFNh dG9ydSBhbmQgTUFQLURUDQo+DQo+IEkgZWNobyB3aGF0IFBlbmcgYW5kIFFpb25nIHNhaWQuIFdo ZW4gdGhlIFdHIGFncmVlZCB3b3JraW5nIG9uIHRoZQ0KPiBzdGF0ZWxlc3Mgc29sdXRpb24sIGl0 IHdhcyB2ZXJ5IGNsZWFyIHN0YXRlZCB0aGF0IHRoZSBzb2x1dGlvbiB3b3VsZCBub3QNCj4gbWFp bnRhaW4gc3RhdGVzIGluIHRoZSBuZXR3b3JrLiBJZiB0aGUgMToxIG1vZGUgY2hhbmdlZCB0aGlz LCB0aGlzIG5vDQo+IGxvbmdlciBtYXRjaGVkIHRoZSByZXF1aXJlbWVudHMgc3RhdGVkIGluIHRo ZSBzdGF0ZWxlc3MgbW90aXZhdGlvbiBkcmFmdCwNCj4gdGh1cywgaXQgd291bGQgZGlzcXVhbGlm eSBNQVAgYXMgYSBzb2x1dGlvbiBmb3IgdGhlIG1vdGl2YXRpb24gZHJhZnQuDQo+DQo+IEFGQUlL LCB0aGUgTUFQIERlc2lnbiBUZWFtIGNvdWxkIHByb3Bvc2UgYSBjaGFuZ2UsIGJ1dCBzdWNoIGEg ZHJhbWF0aWMNCj4gY2hhbmdlIGJ5IGludHJvZHVjaW5nIHN0YXRlcyBpbiB0aGUgbmV0d29yayB3 b3VsZCByZXF1aXJlIFdHIGFwcHJvdmFsLiBJDQo+IHdvdWxkIGxpa2UgdGhlIGNoYWlycyB0byBj bGFyaWZ5IHRoaXMuDQo+DQo+IFRoYW5rcywNCj4gWWl1DQo+DQo+DQo+IE9uIDYvMjQvMTIgMTI6 MjEgUE0sICJQZW5nIFd1IiA8cGVuZ3d1LnRodUBnbWFpbC5jb208bWFpbHRvOnBlbmd3dS50aHVA Z21haWwuY29tPj4gd3JvdGU6DQo+DQo+PiBIaSBRaW9uZywgU2F0b3J1IGFuZCBhbGwsDQo+Pg0K Pj4gSSBzaG91bGQgdGhhbmsgUWlvbmcgZm9yIHBvaW50aW5nIHRoaXMgb3V0LiBJIGdvdHRhIHNh eSBJJ20gYSBiaXQgc2hvY2tlZC4NCj4+IElmIEkgdW5kZXJzdGFuZCB0aGUgcHJvY2VkdXJlcyBv ZiBJRVRGIGNvcnJlY3RseSwgYSBXRyBkb2N1bWVudCBzaG91bGQNCj4+IHJlZmxlY3QgdGhlIGNv bnNlbnN1cyBvZiB0aGUgV0cuIE1BUCBpcyBhcHByb3ZlZCBieSB0aGUgV0cgYXMgYQ0KPj4gc3Rh dGVsZXNzIHNvbHV0aW9uLiBBcyBhIHBhcnRpY2lwYXRvciBpbiBTb2Z0d2lyZSwgSSBkaWRuJ3Qg Z2V0IHRoZQ0KPj4gaW5mb3JtYXRpb24gYW55d2hlcmUgdGhhdCB0aGUgTUFQIFdHIGRvY3VtZW50 IHdvdWxkIGNvdmVyIHRoZQ0KPj4gc28tY2FsbGVkIDE6MSwgaW4gZmFjdCBwZXItdXNlciBzdGF0 ZWZ1bCBtb2RlIGJlZm9yZSBpdCB3YXMgcmVsZWFzZWQsDQo+PiBub3QgdG8gc2F5IGRpc2N1c3Mg aW4gdGhlIFdHLiBEb24ndCB0aGUgV0cgbmVlZCB0byBhcHByb3ZlIHN1Y2ggYmlnDQo+PiBjaGFu Z2UgYW55bW9yZT8NCj4+DQo+PiBOb3cgbGV0IG1lIHByb3ZpZGUgbXkgaW1wcmVzc2lvbiBhcyBh biBvdXRzaWRlciBvZiB0aGUgTUFQIERULiBZb3UNCj4+IGd1eXMgbWFrZSBncmVhdCBlZmZvcnQg dG8gYnVpbGQgdGhlIHNvbHV0aW9uLCBUaGUgYWRkcmVzcyBjb21wb3NpdGlvbiwNCj4+IHRoZSBH TUEgYWxnb3JpdGhtLCB0aGUgZGlmZmVyZW50IHR5cGVzIG9mIGFkZHJlc3MgbWFwcGluZyBydWxl cy4NCj4+IHNob3VsZCBiZSBxdWl0ZSBkaWZmaWN1bHQgdG8gcHVsbCB0b2dldGhlciBzdWNoIHNv cGhpc3RpY2F0ZWQgaWRlYXMuIEkNCj4+IGd1ZXNzIHRoYXQncyB3aGF0IGl0IHRha2VzIHRvIGFj aGlldmUgdGhlIGJlbmlmaXRzIG9mIHN0YXRlbGVzc25lc3MuDQo+PiBBbmQgSSBhZG1pcmUgdGhh dCwgYnJhdm8uIFRoZW4sIGFsbCBvZiBhIHN1ZGRlbiwgeW91IGd1eXMgYXJlIHNheWluZywNCj4+ IGxldCdzIGFwcGx5IHRoaXMgc29waGlzdGljYXRlZCBtZXRob2QgdG8gdGhlIGRpZmZlcmVudCBw cm9ibGVtLCBieQ0KPj4gZHJvcHBpbmcgcXVpdGUgc29tZSBjb21sZXhpdHkgYW5kIHR3aXN0dGlu ZyB0aGUgbWVjaGFuaXNtIGEgYml0LCBzZWVtcw0KPj4gaXQgbWF5IHdvcmsuIENvbnNpZGVyaW5n IHRoZSBwcm9ibGVtIGFyZSBub3cgc29sdmVkIGluIGEgbW9yZSBwdXJlIGFuZA0KPj4gY2xlYXIg d2F5LCBJJ20gc29ycnkgYnV0IEkgQ0FOTk9UIGZvbGxvdyB0aGUgbG9naWMgaGVyZS4NCj4+DQo+ PiBPbiBTdW4sIEp1biAyNCwgMjAxMiBhdCAyOjAwIFBNLCBTYXRvcnUgTWF0c3VzaGltYQ0KPj4g PHNhdG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNvbTxtYWlsdG86c2F0b3J1Lm1hdHN1c2hpbWFAZ21h aWwuY29tPj4gd3JvdGU6DQo+Pj4gSGkgUWlvbmcsDQo+Pj4NCj4+PiBJJ20gZGlzYWdyZWUgd2l0 aCB5b3VyIG9waW5pb24uDQo+Pj4NCj4+PiAxLiBSZWNlbnQgY2hhbmdlcyBpbiBkcmFmdC1pZXRm LXNvZnR3aXJlLW1hcC0wMCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4NCj4+PiB0aGUgRFQuDQo+Pj4g Mi4gTUFQIGp1c3QgY292ZXJzIHNvIGNhbGxlZCAnMToxIG1vZGUnIHdpdGggbW9zdCBncmFudWxh ciBtYXBwaW5nIHJ1bGUNCj4+PiBmb3IgQ0VzIHByb3Zpc2lvbmluZywgd2hpY2ggaXMgYXMgb25l IG9mIGl0cyBjaGFyYWN0ZXJpc3RpY3MuDQo+Pj4gMy4gVGhlIG1vdGl2YXRpb24gZHJhZnQgZG9l cyBub3QgcmVzdHJpY3QgdGhhdCBhcyB5b3Ugc3RhdGVkLCBqdXN0DQo+Pj4gJ2Fzc3VtZWQnLCBp dCdzIG5laXRoZXIgJ01VU1QnIG5vciAnU0hPVUxEJy4NCj4+Pg0KPj4+IEJlc3QgcmVnYXJkcywN Cj4+PiAtLXNhdG9ydQ0KPj4+DQo+Pj4NCj4+PiBPbiAyMDEyLzA2LzI0LCBhdCAxNDozNSwgUWlv bmcgd3JvdGU6DQo+Pj4NCj4+Pj4gSGkgYWxsLA0KPj4+Pg0KPj4+PiBBcyB3ZSBhbGwga25vdywg b25jZSBhbiBpbmRpdmlkdWFsIGRyYWZ0IGlzIGFkb3B0ZWQgYXMgYSBXRyBkcmFmdCwgaXQNCj4+ Pj4gaXMgb3duZWQgYnkgdGhlIHdob2xlIFdHLCByYXRoZXIgdGhhbiBqdXN0IHRoZSBlZGl0b3Jz LiBKdXN0IGFzIFJlbWkNCj4+Pj4gc2FpZCwgdGhlIG5vcm1hbCBwcm9jZWR1cmUgdG8gZm9sbG93 IGlzIHRvIHJlYWNoIFdHIGNvbnNlbnN1cyBfYmVmb3JlXw0KPj4+PiBwb3N0aW5nIGEgbmV3bHkg ZWRpdGVkIHZlcnNpb24uDQo+Pj4+DQo+Pj4+IEZyb20gZHJhZnQtbWR0LXNvZnR3aXJlLW1hcHBp bmctYWRkcmVzcy1hbmQtcG9ydC0wMyB0bw0KPj4+PiBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0w MCwgdGhlcmUgYXJlIHNldmVyYWwgY2hhbmdlcyBiZXR3ZWVuIHRoZW0uIEluDQo+Pj4+IHBhcnRp Y3VsYXIsIHRoZSBuZXdseSBpbnRyb2R1Y2VkICIxOjEgbW9kZSIsIHdoaWNoIGRlY291cGxlcyBJ UHY0IGFuZA0KPj4+PiBJUHY2IGFkZHJlc3NpbmcsIGhhcyBuZXZlciBiZWVuIGRpc2N1c3NlZCBv cGVubHkgaW4gdGhlIFdHIG1haWxpbmcNCj4+Pj4gbGlzdCwgb3IgZXZlbiBpbiB0aGUgTUFQIGRl c2lnbiB0ZWFtIGVpdGhlci4NCj4+Pj4NCj4+Pj4gQWN0dWFsbHksIHRoaXMgIjE6MSBtb2RlIiBp cyBhZ2FpbnN0IHRoZSBzdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb24NCj4+Pj4gZHJhZnQuIFRoZSBt b3RpdmF0aW9uIGRyYWZ0IGhhcyBjbGVhcmx5IGRlZmluZXMgdGhlICJTdGF0ZWxlc3MgNC82DQo+ Pj4+IHNvbHV0aW9uIiBhcyBmb2xsb3dzOg0KPj4+Pg0KPj4+PiBTdGF0ZWxlc3MgNC82IHNvbHV0 aW9uIGRlbm90ZXMgYSBzb2x1dGlvbiB3aGljaCBkb2VzIG5vdCByZXF1aXJlIGFueQ0KPj4+PiBw ZXItdXNlciBzdGF0ZSAoc2VlIFNlY3Rpb24gMi4zIG9mIFtSRkMxOTU4XSkgdG8gYmUgbWFpbnRh aW5lZCBieSBhbnkNCj4+Pj4gSVAgYWRkcmVzcyBzaGFyaW5nIGZ1bmN0aW9uIGluIHRoZSBTZXJ2 aWNlIFByb3ZpZGVyJ3MgbmV0d29yay4gVGhpcw0KPj4+PiBjYXRlZ29yeSBvZiBzb2x1dGlvbnMg YXNzdW1lcyBhIGRlcGVuZGVuY3kgYmV0d2VlbiBhbiBJUHY2IHByZWZpeCBhbmQNCj4+Pj4gSVB2 NCBhZGRyZXNzLg0KPj4+Pg0KPj4+PiBBRkFJSyB3aGF0IHRoZSBXRyBoYXMgYWRvcHRlZCBNQVAg cmVsYXRlZCBkcmFmdCBpcw0KPj4+PiBkcmFmdC1tZHQtc29mdHdpcmUtbWFwcGluZy1hZGRyZXNz LWFuZC1wb3J0LTAzLCBOT1QNCj4+Pj4gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAuIEFuZCB0 aGUgc3RhdGVsZXNzIHNvbHV0aW9uIHNob3VsZCDCs3Jlc3BvbnNlDQo+Pj4+IHRvIHRoZSBzb2x1 dGlvbiBtb3RpdmF0aW9uIGRvY3VtZW50wrIgYWNjb3JkaW5nIHRvIHRoZSBTb2Z0d2lyZSBjaGFy dGVyLg0KPj4+PiBUaGF0IG1lYW5zIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwIElTIE5PVCBR VUFMSUZJRUQgdG8gYmUgYSBXRyBkcmFmdC4NCj4+Pj4NCj4+Pj4gV2UgY2FuIGFsbCByZWNhbGwg dGhhdCBvdXIgc29mdHdpcmUgV0cgaGFzIHdvcmtlZCBvbiBzdGF0ZWxlc3MNCj4+Pj4gc29sdXRp b25zIGZvciBtb3JlIHRoYW4gb25lIGFuZCBhIGhhbGYgeWVhcnMsIGFuZCB3ZSBoYXZlIGFjaGll dmVkIGENCj4+Pj4gbG90IG9mIHdvcmsgd2hpY2ggaGFzIGJlZW4gZG9jdW1lbnRlZCBpbiBjaGFy dGVyLCBzdGF0ZWxlc3MgbW90aXZhdGlvbiwNCj4+Pj4gNHJkLXZhcmllbnRzLCBNQVAtMDMsIGV0 Yy4gQUZBSUsgYWxsIHRoZSBhdXRob3JzIGhhdmUga2VwdCB0aGUgYmFzaWMNCj4+Pj4gInN0YXRl bGVzcyIgcHJpbmNpcGxlIGFuZCB0aGUgTUFQIGRlc2lnbiB0ZWFtIGlzIGFsc28gd29ya2luZyBv biBpdA0KPj4+PiB0b2dldGhlciB0byBmaW5kIGEgYmV0dGVyIGFsZ29yaXRobSwgYWRkcmVzcyBm b3JtYXQsIGV0Yy4gU28gaXQgaXMNCj4+Pj4gcmVhbGx5IG5vdCBhcHByb3ByaWF0ZSB0byBtYWtl IHN1Y2ggY2hhbmdlcyB3aGVuIE1BUCBpcyBhZG9wdGVkIGFzIGEgV0cNCj4+Pj4gaXRlbSBpbiBz dWNoIGEgc2hvcnQgdGltZS4NCj4+Pj4NCj4+Pj4gRnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBkcmFm dC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBjYW4gb25seSBiZSByZWdhcmRlZA0KPj4+PiBhcyBkcmFm dC1YWC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBvcnQtMDQuIEl0IGlzIG5vdCBldmVu IHRoZQ0KPj4+PiBvdXRwdXQgb2YgTUFQIGRlc2lnbiB0ZWFtLg0KPj4+Pg0KPj4+PiBCZXN0IHdp c2hlcw0KPj4+Pg0KPj4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQo+Pj4+IFFpb25nIFN1bg0KPj4+PiBDaGluYSBUZWxlY29tIEJlaWppbmcgUmVzZWFy Y2ggSW5zdGl0dWRlDQo+Pj4+DQo+Pj4+DQo+Pj4+IE9wZW4gc291cmNlIGNvZGU6DQo+Pj4+IGxp Z2h0d2VpZ2h0IDRvdmVyNjogaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni8N Cj4+Pj4gUENQLW5hdGNvb3JkOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL3BjcHBv cnRzZXRkZW1vLw0KPj4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPj4+Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+Pj4+IFNvZnR3 aXJlc0BpZXRmLm9yZzxtYWlsdG86U29mdHdpcmVzQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPj4+DQo+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBTb2Z0d2lyZXMgbWFp bGluZyBsaXN0DQo+Pj4gU29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5v cmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMN Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBT b2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+PiBTb2Z0d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOlNvZnR3 aXJlc0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c29mdHdpcmVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOlNv ZnR3aXJlc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c29mdHdpcmVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpTb2Z0 d2lyZXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nv ZnR3aXJlcw0KDQoNCg== --_000_97C30DD36C2B421BA0BEBCA68C9AAF28ipinfusioncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkhpIFFpLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+SW4gYWRkaXRpb24sIG91ciBNQVAgaW1wbGVtZW50YXRpb24gY2FuIGhhbmRsZSBzdWNoIGEg YnVuY2ggb2YgZW50cmllcy4gT2YgY291cnNlLCBpdCByZXF1aXJlcyBlbm91Z2ggbWVtb3J5IGlu IG9yZGVyIHRvIHN0b3JlIGFsbCBvZiB0aGVtIGluIGl0cyBvd24gbWVtb3J5LiBCdXQgSSBjb3Vs ZCBub3Qgc2VlIGFueSBvdGhlciBwcm9ibGVtcyBleGNlcHQgcmVxdWlyZWQgbWVtb3J5IHNpemUu IEFsc28sIGVhY2ggZW50cnkgaXMgc3RvcmVkDQogc3RhdGljYWxseSBhbmQgc28gTUFQIGltcGxl bWVudGF0aW9uIGRvZXMgbm90IG1haW50YWluIHRoZSAmcXVvdDtzdGF0ZSZxdW90OyBmb3IgZWFj aCBlbnRyeS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxk aXY+VGV0c3V5YSBNdXJha2FtaTwvZGl2Pg0KPGRpdj48YnI+DQo8ZGl2Pg0KPGRpdj5PbiAyMDEy LzA2LzI1LCBhdCAyOjI3LCBUZXRzdXlhIE11cmFrYW1pIHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxi YXNlIGhyZWY9IngtbXNnOi8vMTgzLyI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsgIj4NCkhpIFFpLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RXZlbiB0aG91 Z2ggdGhlcmUgYXJlIGEgYnVuY2ggb2YgbWFwcGluZyBydWxlcywgZWFjaCBtYXBwaW5nIHJ1bGUg aGFzIG5vIHN0YXRlLiBTaW5jZSBlYWNoIG1hcHBpbmcgcnVsZXMgaXMgc2V0IG1hbnVhbGx5LCBC UiBkb2VzIG5vdCBtYWludGFpbiBlYWNoIG1hcHBpbmcgcnVsZSBhbmQganVzdCBzdG9yZSB0aGVt IGluIGl0cyBvd24gbWVtb3J5LiBTbywgSSBhbSBub3Qgc3VyZSB3aHkgeW91IGFyZSBjYWxsaW5n IHRoZSAmcXVvdDtzdGF0ZSZxdW90OyBpZg0KIHRoZXJlIGFyZSBhIGJ1bmNoIG9mIG1hcHBpbmcg cnVsZXMuIElmIHlvdSBhcmUgc2F5aW5nIHRoYXQsIGRvIHlvdSBhc3N1bWUgaG93IG1hbnkgZW50 cmllcyBzaG91bGQgYmUgZXhpc3RlZCBpbiB0aGUgdGFibGUgaW4gb3JkZXIgdG8gY2FsbCBpdCB0 byB0aGUgJnF1b3Q7c3RhdGUmcXVvdDsuIEZyb20gdGhlIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0 aXZlLCBldmVuIHRob3VnaCB0aGVyZSBhcmUgMTAwMDAwMDAgZW50cmllcyBpbiB0aGUgdGFibGUs IHRoZSBwcm9ibGVtDQogaXMganVzdCBob3cgbXVjaCBtZW1vcnkgaXMgbmVlZGVkLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5UZXRzdXlhIE11cmFr YW1pJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pk9u IDIwMTIvMDYvMjQsIGF0IDIzOjUxLCBRaSBTdW4gd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFw cGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4g Y2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRl OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9u dGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZm9udC1zaXpl OiBtZWRpdW07ICI+DQo8ZGl2IHN0eWxlPSJsaW5lLWhlaWdodDogMS41OyBmb250LWZhbWlseTog 5b6u6L2v6ZuF6buROyBjb2xvcjogcmdiKDAsIDAsIDEyOCk7IGZvbnQtc2l6ZTogMTAuNXB0OyBt YXJnaW4tdG9wOiAxMHB4OyBtYXJnaW4tcmlnaHQ6IDEwcHg7IG1hcmdpbi1ib3R0b206IDEwcHg7 IG1hcmdpbi1sZWZ0OiAxMHB4OyAiPg0KPGRpdj5IaSBTYXRvcnUsPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj5JbiBNQVAgMToxIG1vZGUsIGlmIHRoZXJlIGFyZSAxMDAwMDAwMCBzdWJz Y3JpYmVycywgdGhlcmUgd291bGQgYmUgMTAwMDAwMDAgTUFQIGRvbWFpbnMgd2hpY2ggYSBCUiBo YXMgdG8gbWFuYWdlLiBJIHRoaW5rIHRoYXQgd2lsbCBjcmVhdGUgYSBodWdlIG1hcHBpbmcgdGFi bGUgb24gdGhlIEJSLCB3aGljaCBpcyBjYWxsZWQgJ3N0YXRlJyB0aGF0IHN0YXRlZnVsIHNvbHV0 aW9ucyBkZWFsIHdpdGguPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5CZXN0IFJlZ2Fy ZHMhPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGhyIGFsaWduPSJsZWZ0IiBjb2xvcj0iI2I1 YzRkZiIgc2l6ZT0iMSIgc3R5bGU9IndpZHRoOiAyMTBweDsgaGVpZ2h0OiAxcHg7ICI+DQo8ZGl2 PjxzcGFuPlFpIFN1bjwvc3Bhbj48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXItYm90dG9tLXdpZHRoOiBtZWRpdW07IGJvcmRlci1ib3R0b20tc3R5bGU6IG5vbmU7 IGJvcmRlci1ib3R0b20tY29sb3I6IGluaXRpYWw7IGJvcmRlci1sZWZ0LXdpZHRoOiBtZWRpdW07 IGJvcmRlci1sZWZ0LXN0eWxlOiBub25lOyBib3JkZXItbGVmdC1jb2xvcjogaW5pdGlhbDsgcGFk ZGluZy1ib3R0b206IDBjbTsgcGFkZGluZy1sZWZ0OiAwY207IHBhZGRpbmctcmlnaHQ6IDBjbTsg Ym9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAx cHQ7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyBib3JkZXItcmlnaHQtd2lkdGg6IG1lZGl1bTsg Ym9yZGVyLXJpZ2h0LXN0eWxlOiBub25lOyBib3JkZXItcmlnaHQtY29sb3I6IGluaXRpYWw7IHBh ZGRpbmctdG9wOiAzcHQ7ICI+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWJvdHRvbTogOHB4OyBwYWRk aW5nLWxlZnQ6IDhweDsgcGFkZGluZy1yaWdodDogOHB4OyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0 aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBp bml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYigy MzksIDIzOSwgMjM5KTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxMnB4OyBwYWRk aW5nLXRvcDogOHB4OyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tn cm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7ICI+DQo8ZGl2PjxiPkZyb206PC9iPiZuYnNw OzxhIGhyZWY9Im1haWx0bzpzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb20iPlNhdG9ydSBNYXRz dXNoaW1hPC9hPjwvZGl2Pg0KPGRpdj48Yj5EYXRlOjwvYj4mbmJzcDsyMDEyLTA2LTI1Jm5ic3A7 MTA6Mjc8L2Rpdj4NCjxkaXY+PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpZaXVfTGVl QENhYmxlLkNvbWNhc3QuY29tIj5MZWUsIFlpdTwvYT48L2Rpdj4NCjxkaXY+PGI+Q0M6PC9iPiZu YnNwOzxhIGhyZWY9Im1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmciPnNvZnR3aXJlc0BpZXRmLm9y ZzwvYT47PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpjdWl5b25nQGdtYWlsLmNvbSI+WW9uZyBDdWk8L2E+PC9kaXY+DQo8ZGl2 PjxiPlN1YmplY3Q6PC9iPiZuYnNwO1JlOiBbU29mdHdpcmVzXSBbU29mdHdpcmVdIGRyYWZ0LWll dGYtc29mdHdpcmUtbWFwLTAwIGRvZXMgTk9UIHJlZmxlY3QgdGhlIGNvbnNlbnN1cyBmcm9tIHRo ZSBXRzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PkhpJm5ic3A7WWl1LDwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Tm8sJm5ic3A7dGhhdCdzJm5ic3A7YSZuYnNwO21p c3VuZGVyc3RhbmRpbmcuPC9kaXY+DQo8ZGl2PkN1cnJlbnQmbmJzcDtNQVAmbmJzcDtzcGVjaWZ5 Jm5ic3A7dGhlJm5ic3A7Y2FzZSZuYnNwO2ZvciZuYnNwO2VhLWxlbiZuYnNwO2lzJm5ic3A7J3pl cm8nLiZuYnNwO0l0Jm5ic3A7aXMmbmJzcDsncGVyLXN1YnNjcmliZXImbmJzcDttYXBwaW5nJyZu YnNwO2luJm5ic3A7c3RhdGVsZXNzJm5ic3A7bWFubmVyLCZuYnNwO25vdCZuYnNwO3RvJm5ic3A7 aW50cm9kdWNlJm5ic3A7J3Blci1mbG93Jm5ic3A7TkFUJm5ic3A7YmluZGluZycmbmJzcDtvciZu YnNwOydwZXItc3Vic2NyaWJlciZuYnNwO3N0YXRlJm5ic3A7b24mbmJzcDtkZW1hbmQnLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Y2hlZXJzLDwvZGl2Pg0KPGRpdj4tLXNhdG9ydTwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+T24mbmJzcDsyMDEyLzA2LzI1LCZuYnNwO2F0 Jm5ic3A7MjozMiwmbmJzcDtMZWUsJm5ic3A7WWl1Jm5ic3A7d3JvdGU6PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7RGVhciZuYnNwO1NhdG9ydSZuYnNwO2FuZCZuYnNw O01BUC1EVDwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDtJJm5i c3A7ZWNobyZuYnNwO3doYXQmbmJzcDtQZW5nJm5ic3A7YW5kJm5ic3A7UWlvbmcmbmJzcDtzYWlk LiZuYnNwO1doZW4mbmJzcDt0aGUmbmJzcDtXRyZuYnNwO2FncmVlZCZuYnNwO3dvcmtpbmcmbmJz cDtvbiZuYnNwO3RoZTwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7c3RhdGVsZXNzJm5ic3A7c29sdXRp b24sJm5ic3A7aXQmbmJzcDt3YXMmbmJzcDt2ZXJ5Jm5ic3A7Y2xlYXImbmJzcDtzdGF0ZWQmbmJz cDt0aGF0Jm5ic3A7dGhlJm5ic3A7c29sdXRpb24mbmJzcDt3b3VsZCZuYnNwO25vdDwvZGl2Pg0K PGRpdj4mZ3Q7Jm5ic3A7bWFpbnRhaW4mbmJzcDtzdGF0ZXMmbmJzcDtpbiZuYnNwO3RoZSZuYnNw O25ldHdvcmsuJm5ic3A7SWYmbmJzcDt0aGUmbmJzcDsxOjEmbmJzcDttb2RlJm5ic3A7Y2hhbmdl ZCZuYnNwO3RoaXMsJm5ic3A7dGhpcyZuYnNwO25vPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDtsb25n ZXImbmJzcDttYXRjaGVkJm5ic3A7dGhlJm5ic3A7cmVxdWlyZW1lbnRzJm5ic3A7c3RhdGVkJm5i c3A7aW4mbmJzcDt0aGUmbmJzcDtzdGF0ZWxlc3MmbmJzcDttb3RpdmF0aW9uJm5ic3A7ZHJhZnQs PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDt0aHVzLCZuYnNwO2l0Jm5ic3A7d291bGQmbmJzcDtkaXNx dWFsaWZ5Jm5ic3A7TUFQJm5ic3A7YXMmbmJzcDthJm5ic3A7c29sdXRpb24mbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDttb3RpdmF0aW9uJm5ic3A7ZHJhZnQuPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDs8 L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwO0FGQUlLLCZuYnNwO3RoZSZuYnNwO01BUCZuYnNwO0Rlc2ln biZuYnNwO1RlYW0mbmJzcDtjb3VsZCZuYnNwO3Byb3Bvc2UmbmJzcDthJm5ic3A7Y2hhbmdlLCZu YnNwO2J1dCZuYnNwO3N1Y2gmbmJzcDthJm5ic3A7ZHJhbWF0aWM8L2Rpdj4NCjxkaXY+Jmd0OyZu YnNwO2NoYW5nZSZuYnNwO2J5Jm5ic3A7aW50cm9kdWNpbmcmbmJzcDtzdGF0ZXMmbmJzcDtpbiZu YnNwO3RoZSZuYnNwO25ldHdvcmsmbmJzcDt3b3VsZCZuYnNwO3JlcXVpcmUmbmJzcDtXRyZuYnNw O2FwcHJvdmFsLiZuYnNwO0k8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwO3dvdWxkJm5ic3A7bGlrZSZu YnNwO3RoZSZuYnNwO2NoYWlycyZuYnNwO3RvJm5ic3A7Y2xhcmlmeSZuYnNwO3RoaXMuPC9kaXY+ DQo8ZGl2PiZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwO1RoYW5rcyw8L2Rpdj4NCjxk aXY+Jmd0OyZuYnNwO1lpdTwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsm bmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwO09uJm5ic3A7Ni8yNC8xMiZuYnNwOzEyOjIxJm5i c3A7UE0sJm5ic3A7JnF1b3Q7UGVuZyZuYnNwO1d1JnF1b3Q7Jm5ic3A7Jmx0OzxhIGhyZWY9Im1h aWx0bzpwZW5nd3UudGh1QGdtYWlsLmNvbSI+cGVuZ3d1LnRodUBnbWFpbC5jb208L2E+Jmd0OyZu YnNwO3dyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5i c3A7SGkmbmJzcDtRaW9uZywmbmJzcDtTYXRvcnUmbmJzcDthbmQmbmJzcDthbGwsPC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7SSZuYnNwO3Nob3Vs ZCZuYnNwO3RoYW5rJm5ic3A7UWlvbmcmbmJzcDtmb3ImbmJzcDtwb2ludGluZyZuYnNwO3RoaXMm bmJzcDtvdXQuJm5ic3A7SSZuYnNwO2dvdHRhJm5ic3A7c2F5Jm5ic3A7SSdtJm5ic3A7YSZuYnNw O2JpdCZuYnNwO3Nob2NrZWQuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7SWYmbmJzcDtJJm5i c3A7dW5kZXJzdGFuZCZuYnNwO3RoZSZuYnNwO3Byb2NlZHVyZXMmbmJzcDtvZiZuYnNwO0lFVEYm bmJzcDtjb3JyZWN0bHksJm5ic3A7YSZuYnNwO1dHJm5ic3A7ZG9jdW1lbnQmbmJzcDtzaG91bGQ8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtyZWZsZWN0Jm5ic3A7dGhlJm5ic3A7Y29uc2Vuc3Vz Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtXRy4mbmJzcDtNQVAmbmJzcDtpcyZuYnNwO2FwcHJvdmVk Jm5ic3A7YnkmbmJzcDt0aGUmbmJzcDtXRyZuYnNwO2FzJm5ic3A7YTwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZuYnNwO3N0YXRlbGVzcyZuYnNwO3NvbHV0aW9uLiZuYnNwO0FzJm5ic3A7YSZuYnNwO3Bh cnRpY2lwYXRvciZuYnNwO2luJm5ic3A7U29mdHdpcmUsJm5ic3A7SSZuYnNwO2RpZG4ndCZuYnNw O2dldCZuYnNwO3RoZTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO2luZm9ybWF0aW9uJm5ic3A7 YW55d2hlcmUmbmJzcDt0aGF0Jm5ic3A7dGhlJm5ic3A7TUFQJm5ic3A7V0cmbmJzcDtkb2N1bWVu dCZuYnNwO3dvdWxkJm5ic3A7Y292ZXImbmJzcDt0aGU8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJz cDtzby1jYWxsZWQmbmJzcDsxOjEsJm5ic3A7aW4mbmJzcDtmYWN0Jm5ic3A7cGVyLXVzZXImbmJz cDtzdGF0ZWZ1bCZuYnNwO21vZGUmbmJzcDtiZWZvcmUmbmJzcDtpdCZuYnNwO3dhcyZuYnNwO3Jl bGVhc2VkLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO25vdCZuYnNwO3RvJm5ic3A7c2F5Jm5i c3A7ZGlzY3VzcyZuYnNwO2luJm5ic3A7dGhlJm5ic3A7V0cuJm5ic3A7RG9uJ3QmbmJzcDt0aGUm bmJzcDtXRyZuYnNwO25lZWQmbmJzcDt0byZuYnNwO2FwcHJvdmUmbmJzcDtzdWNoJm5ic3A7Ymln PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Y2hhbmdlJm5ic3A7YW55bW9yZT88L2Rpdj4NCjxk aXY+Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtOb3cmbmJzcDtsZXQm bmJzcDttZSZuYnNwO3Byb3ZpZGUmbmJzcDtteSZuYnNwO2ltcHJlc3Npb24mbmJzcDthcyZuYnNw O2FuJm5ic3A7b3V0c2lkZXImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO01BUCZuYnNwO0RULiZuYnNw O1lvdTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO2d1eXMmbmJzcDttYWtlJm5ic3A7Z3JlYXQm bmJzcDtlZmZvcnQmbmJzcDt0byZuYnNwO2J1aWxkJm5ic3A7dGhlJm5ic3A7c29sdXRpb24sJm5i c3A7VGhlJm5ic3A7YWRkcmVzcyZuYnNwO2NvbXBvc2l0aW9uLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZuYnNwO3RoZSZuYnNwO0dNQSZuYnNwO2FsZ29yaXRobSwmbmJzcDt0aGUmbmJzcDtkaWZmZXJl bnQmbmJzcDt0eXBlcyZuYnNwO29mJm5ic3A7YWRkcmVzcyZuYnNwO21hcHBpbmcmbmJzcDtydWxl cy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtzaG91bGQmbmJzcDtiZSZuYnNwO3F1aXRlJm5i c3A7ZGlmZmljdWx0Jm5ic3A7dG8mbmJzcDtwdWxsJm5ic3A7dG9nZXRoZXImbmJzcDtzdWNoJm5i c3A7c29waGlzdGljYXRlZCZuYnNwO2lkZWFzLiZuYnNwO0k8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm bmJzcDtndWVzcyZuYnNwO3RoYXQncyZuYnNwO3doYXQmbmJzcDtpdCZuYnNwO3Rha2VzJm5ic3A7 dG8mbmJzcDthY2hpZXZlJm5ic3A7dGhlJm5ic3A7YmVuaWZpdHMmbmJzcDtvZiZuYnNwO3N0YXRl bGVzc25lc3MuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7QW5kJm5ic3A7SSZuYnNwO2FkbWly ZSZuYnNwO3RoYXQsJm5ic3A7YnJhdm8uJm5ic3A7VGhlbiwmbmJzcDthbGwmbmJzcDtvZiZuYnNw O2EmbmJzcDtzdWRkZW4sJm5ic3A7eW91Jm5ic3A7Z3V5cyZuYnNwO2FyZSZuYnNwO3NheWluZyw8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtsZXQncyZuYnNwO2FwcGx5Jm5ic3A7dGhpcyZuYnNw O3NvcGhpc3RpY2F0ZWQmbmJzcDttZXRob2QmbmJzcDt0byZuYnNwO3RoZSZuYnNwO2RpZmZlcmVu dCZuYnNwO3Byb2JsZW0sJm5ic3A7Ynk8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtkcm9wcGlu ZyZuYnNwO3F1aXRlJm5ic3A7c29tZSZuYnNwO2NvbWxleGl0eSZuYnNwO2FuZCZuYnNwO3R3aXN0 dGluZyZuYnNwO3RoZSZuYnNwO21lY2hhbmlzbSZuYnNwO2EmbmJzcDtiaXQsJm5ic3A7c2VlbXM8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDtpdCZuYnNwO21heSZuYnNwO3dvcmsuJm5ic3A7Q29u c2lkZXJpbmcmbmJzcDt0aGUmbmJzcDtwcm9ibGVtJm5ic3A7YXJlJm5ic3A7bm93Jm5ic3A7c29s dmVkJm5ic3A7aW4mbmJzcDthJm5ic3A7bW9yZSZuYnNwO3B1cmUmbmJzcDthbmQ8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmbmJzcDtjbGVhciZuYnNwO3dheSwmbmJzcDtJJ20mbmJzcDtzb3JyeSZuYnNw O2J1dCZuYnNwO0kmbmJzcDtDQU5OT1QmbmJzcDtmb2xsb3cmbmJzcDt0aGUmbmJzcDtsb2dpYyZu YnNwO2hlcmUuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jm5ic3A7T24mbmJzcDtTdW4sJm5ic3A7SnVuJm5ic3A7MjQsJm5ic3A7MjAxMiZuYnNwO2F0Jm5i c3A7MjowMCZuYnNwO1BNLCZuYnNwO1NhdG9ydSZuYnNwO01hdHN1c2hpbWE8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsmbmJzcDsmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhdG9ydS5tYXRzdXNoaW1hQGdtYWls LmNvbSI+c2F0b3J1Lm1hdHN1c2hpbWFAZ21haWwuY29tPC9hPiZndDsmbmJzcDt3cm90ZTo8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7SGkmbmJzcDtRaW9uZyw8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwO0knbSZuYnNwO2Rp c2FncmVlJm5ic3A7d2l0aCZuYnNwO3lvdXImbmJzcDtvcGluaW9uLjwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7MS4mbmJzcDtSZWNl bnQmbmJzcDtjaGFuZ2VzJm5ic3A7aW4mbmJzcDtkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCZu YnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtkaXNjdXNzZWQmbmJzcDtpbjwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsmbmJzcDt0aGUmbmJzcDtEVC48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7 Mi4mbmJzcDtNQVAmbmJzcDtqdXN0Jm5ic3A7Y292ZXJzJm5ic3A7c28mbmJzcDtjYWxsZWQmbmJz cDsnMToxJm5ic3A7bW9kZScmbmJzcDt3aXRoJm5ic3A7bW9zdCZuYnNwO2dyYW51bGFyJm5ic3A7 bWFwcGluZyZuYnNwO3J1bGU8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7Zm9yJm5ic3A7 Q0VzJm5ic3A7cHJvdmlzaW9uaW5nLCZuYnNwO3doaWNoJm5ic3A7aXMmbmJzcDthcyZuYnNwO29u ZSZuYnNwO29mJm5ic3A7aXRzJm5ic3A7Y2hhcmFjdGVyaXN0aWNzLjwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsmbmJzcDszLiZuYnNwO1RoZSZuYnNwO21vdGl2YXRpb24mbmJzcDtkcmFmdCZuYnNw O2RvZXMmbmJzcDtub3QmbmJzcDtyZXN0cmljdCZuYnNwO3RoYXQmbmJzcDthcyZuYnNwO3lvdSZu YnNwO3N0YXRlZCwmbmJzcDtqdXN0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwOydhc3N1 bWVkJywmbmJzcDtpdCdzJm5ic3A7bmVpdGhlciZuYnNwOydNVVNUJyZuYnNwO25vciZuYnNwOydT SE9VTEQnLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmZ3Q7Jm5ic3A7QmVzdCZuYnNwO3JlZ2FyZHMsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZu YnNwOy0tc2F0b3J1PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7T24mbmJzcDsy MDEyLzA2LzI0LCZuYnNwO2F0Jm5ic3A7MTQ6MzUsJm5ic3A7UWlvbmcmbmJzcDt3cm90ZTo8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsm bmJzcDtIaSZuYnNwO2FsbCw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QXMmbmJzcDt3ZSZuYnNwO2FsbCZuYnNwO2tu b3csJm5ic3A7b25jZSZuYnNwO2FuJm5ic3A7aW5kaXZpZHVhbCZuYnNwO2RyYWZ0Jm5ic3A7aXMm bmJzcDthZG9wdGVkJm5ic3A7YXMmbmJzcDthJm5ic3A7V0cmbmJzcDtkcmFmdCwmbmJzcDtpdDwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7aXMmbmJzcDtvd25lZCZuYnNwO2J5Jm5i c3A7dGhlJm5ic3A7d2hvbGUmbmJzcDtXRywmbmJzcDtyYXRoZXImbmJzcDt0aGFuJm5ic3A7anVz dCZuYnNwO3RoZSZuYnNwO2VkaXRvcnMuJm5ic3A7SnVzdCZuYnNwO2FzJm5ic3A7UmVtaTwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7c2FpZCwmbmJzcDt0aGUmbmJzcDtub3JtYWwm bmJzcDtwcm9jZWR1cmUmbmJzcDt0byZuYnNwO2ZvbGxvdyZuYnNwO2lzJm5ic3A7dG8mbmJzcDty ZWFjaCZuYnNwO1dHJm5ic3A7Y29uc2Vuc3VzJm5ic3A7X2JlZm9yZV88L2Rpdj4NCjxkaXY+Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwO3Bvc3RpbmcmbmJzcDthJm5ic3A7bmV3bHkmbmJzcDtlZGl0ZWQm bmJzcDt2ZXJzaW9uLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtGcm9tJm5ic3A7ZHJhZnQtbWR0LXNvZnR3aXJlLW1h cHBpbmctYWRkcmVzcy1hbmQtcG9ydC0wMyZuYnNwO3RvPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDtkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCwmbmJzcDt0aGVyZSZuYnNwO2Fy ZSZuYnNwO3NldmVyYWwmbmJzcDtjaGFuZ2VzJm5ic3A7YmV0d2VlbiZuYnNwO3RoZW0uJm5ic3A7 SW48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO3BhcnRpY3VsYXIsJm5ic3A7dGhl Jm5ic3A7bmV3bHkmbmJzcDtpbnRyb2R1Y2VkJm5ic3A7JnF1b3Q7MToxJm5ic3A7bW9kZSZxdW90 OywmbmJzcDt3aGljaCZuYnNwO2RlY291cGxlcyZuYnNwO0lQdjQmbmJzcDthbmQ8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO0lQdjYmbmJzcDthZGRyZXNzaW5nLCZuYnNwO2hhcyZu YnNwO25ldmVyJm5ic3A7YmVlbiZuYnNwO2Rpc2N1c3NlZCZuYnNwO29wZW5seSZuYnNwO2luJm5i c3A7dGhlJm5ic3A7V0cmbmJzcDttYWlsaW5nPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsm bmJzcDtsaXN0LCZuYnNwO29yJm5ic3A7ZXZlbiZuYnNwO2luJm5ic3A7dGhlJm5ic3A7TUFQJm5i c3A7ZGVzaWduJm5ic3A7dGVhbSZuYnNwO2VpdGhlci48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7QWN0dWFsbHksJm5i c3A7dGhpcyZuYnNwOyZxdW90OzE6MSZuYnNwO21vZGUmcXVvdDsmbmJzcDtpcyZuYnNwO2FnYWlu c3QmbmJzcDt0aGUmbmJzcDtzdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb248L2Rpdj4NCjxkaXY+Jmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwO2RyYWZ0LiZuYnNwO1RoZSZuYnNwO21vdGl2YXRpb24mbmJzcDtk cmFmdCZuYnNwO2hhcyZuYnNwO2NsZWFybHkmbmJzcDtkZWZpbmVzJm5ic3A7dGhlJm5ic3A7JnF1 b3Q7U3RhdGVsZXNzJm5ic3A7NC82PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtz b2x1dGlvbiZxdW90OyZuYnNwO2FzJm5ic3A7Zm9sbG93czo8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7U3RhdGVsZXNz Jm5ic3A7NC82Jm5ic3A7c29sdXRpb24mbmJzcDtkZW5vdGVzJm5ic3A7YSZuYnNwO3NvbHV0aW9u Jm5ic3A7d2hpY2gmbmJzcDtkb2VzJm5ic3A7bm90Jm5ic3A7cmVxdWlyZSZuYnNwO2FueTwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7cGVyLXVzZXImbmJzcDtzdGF0ZSZuYnNwOyhz ZWUmbmJzcDtTZWN0aW9uJm5ic3A7Mi4zJm5ic3A7b2YmbmJzcDtbUkZDMTk1OF0pJm5ic3A7dG8m bmJzcDtiZSZuYnNwO21haW50YWluZWQmbmJzcDtieSZuYnNwO2FueTwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7SVAmbmJzcDthZGRyZXNzJm5ic3A7c2hhcmluZyZuYnNwO2Z1bmN0 aW9uJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtTZXJ2aWNlJm5ic3A7UHJvdmlkZXIncyZuYnNwO25l dHdvcmsuJm5ic3A7VGhpczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Y2F0ZWdv cnkmbmJzcDtvZiZuYnNwO3NvbHV0aW9ucyZuYnNwO2Fzc3VtZXMmbmJzcDthJm5ic3A7ZGVwZW5k ZW5jeSZuYnNwO2JldHdlZW4mbmJzcDthbiZuYnNwO0lQdjYmbmJzcDtwcmVmaXgmbmJzcDthbmQ8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwO0lQdjQmbmJzcDthZGRyZXNzLjwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDtBRkFJSyZuYnNwO3doYXQmbmJzcDt0aGUmbmJzcDtXRyZuYnNwO2hhcyZuYnNwO2Fk b3B0ZWQmbmJzcDtNQVAmbmJzcDtyZWxhdGVkJm5ic3A7ZHJhZnQmbmJzcDtpczwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ZHJhZnQtbWR0LXNvZnR3aXJlLW1hcHBpbmctYWRkcmVz cy1hbmQtcG9ydC0wMywmbmJzcDtOT1Q8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw O2RyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwLiZuYnNwO0FuZCZuYnNwO3RoZSZuYnNwO3N0YXRl bGVzcyZuYnNwO3NvbHV0aW9uJm5ic3A7c2hvdWxkJm5ic3A7wrNyZXNwb25zZTwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtzb2x1dGlvbiZuYnNwO21v dGl2YXRpb24mbmJzcDtkb2N1bWVudMKyJm5ic3A7YWNjb3JkaW5nJm5ic3A7dG8mbmJzcDt0aGUm bmJzcDtTb2Z0d2lyZSZuYnNwO2NoYXJ0ZXIuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsm bmJzcDtUaGF0Jm5ic3A7bWVhbnMmbmJzcDtkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCZuYnNw O0lTJm5ic3A7Tk9UJm5ic3A7UVVBTElGSUVEJm5ic3A7dG8mbmJzcDtiZSZuYnNwO2EmbmJzcDtX RyZuYnNwO2RyYWZ0LjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtXZSZuYnNwO2NhbiZuYnNwO2FsbCZuYnNwO3JlY2Fs bCZuYnNwO3RoYXQmbmJzcDtvdXImbmJzcDtzb2Z0d2lyZSZuYnNwO1dHJm5ic3A7aGFzJm5ic3A7 d29ya2VkJm5ic3A7b24mbmJzcDtzdGF0ZWxlc3M8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0 OyZuYnNwO3NvbHV0aW9ucyZuYnNwO2ZvciZuYnNwO21vcmUmbmJzcDt0aGFuJm5ic3A7b25lJm5i c3A7YW5kJm5ic3A7YSZuYnNwO2hhbGYmbmJzcDt5ZWFycywmbmJzcDthbmQmbmJzcDt3ZSZuYnNw O2hhdmUmbmJzcDthY2hpZXZlZCZuYnNwO2E8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwO2xvdCZuYnNwO29mJm5ic3A7d29yayZuYnNwO3doaWNoJm5ic3A7aGFzJm5ic3A7YmVlbiZu YnNwO2RvY3VtZW50ZWQmbmJzcDtpbiZuYnNwO2NoYXJ0ZXIsJm5ic3A7c3RhdGVsZXNzJm5ic3A7 bW90aXZhdGlvbiw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzRyZC12YXJpZW50 cywmbmJzcDtNQVAtMDMsJm5ic3A7ZXRjLiZuYnNwO0FGQUlLJm5ic3A7YWxsJm5ic3A7dGhlJm5i c3A7YXV0aG9ycyZuYnNwO2hhdmUmbmJzcDtrZXB0Jm5ic3A7dGhlJm5ic3A7YmFzaWM8L2Rpdj4N CjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZxdW90O3N0YXRlbGVzcyZxdW90OyZuYnNwO3By aW5jaXBsZSZuYnNwO2FuZCZuYnNwO3RoZSZuYnNwO01BUCZuYnNwO2Rlc2lnbiZuYnNwO3RlYW0m bmJzcDtpcyZuYnNwO2Fsc28mbmJzcDt3b3JraW5nJm5ic3A7b24mbmJzcDtpdDwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7dG9nZXRoZXImbmJzcDt0byZuYnNwO2ZpbmQmbmJzcDth Jm5ic3A7YmV0dGVyJm5ic3A7YWxnb3JpdGhtLCZuYnNwO2FkZHJlc3MmbmJzcDtmb3JtYXQsJm5i c3A7ZXRjLiZuYnNwO1NvJm5ic3A7aXQmbmJzcDtpczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7cmVhbGx5Jm5ic3A7bm90Jm5ic3A7YXBwcm9wcmlhdGUmbmJzcDt0byZuYnNwO21h a2UmbmJzcDtzdWNoJm5ic3A7Y2hhbmdlcyZuYnNwO3doZW4mbmJzcDtNQVAmbmJzcDtpcyZuYnNw O2Fkb3B0ZWQmbmJzcDthcyZuYnNwO2EmbmJzcDtXRzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7aXRlbSZuYnNwO2luJm5ic3A7c3VjaCZuYnNwO2EmbmJzcDtzaG9ydCZuYnNwO3Rp bWUuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwO0Zyb20mbmJzcDt0aGlzJm5ic3A7cGVyc3BlY3RpdmUsJm5ic3A7ZHJh ZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAmbmJzcDtjYW4mbmJzcDtvbmx5Jm5ic3A7YmUmbmJzcDty ZWdhcmRlZDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7YXMmbmJzcDtkcmFmdC1Y WC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBvcnQtMDQuJm5ic3A7SXQmbmJzcDtpcyZu YnNwO25vdCZuYnNwO2V2ZW4mbmJzcDt0aGU8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZu YnNwO291dHB1dCZuYnNwO29mJm5ic3A7TUFQJm5ic3A7ZGVzaWduJm5ic3A7dGVhbS48L2Rpdj4N CjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jm5ic3A7QmVzdCZuYnNwO3dpc2hlczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJz cDtRaW9uZyZuYnNwO1N1bjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Q2hpbmEm bmJzcDtUZWxlY29tJm5ic3A7QmVpamluZyZuYnNwO1Jlc2VhcmNoJm5ic3A7SW5zdGl0dWRlPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7T3BlbiZuYnNwO3Nv dXJjZSZuYnNwO2NvZGU6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtsaWdodHdl aWdodCZuYnNwOzRvdmVyNjombmJzcDs8YSBocmVmPSJodHRwOi8vc291cmNlZm9yZ2UubmV0L3By b2plY3RzL2xhZnQ2LyI+aHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9sYWZ0Ni88L2E+ PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDtQQ1AtbmF0Y29vcmQ6Jm5ic3A7PGEg aHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9wY3Bwb3J0c2V0ZGVtby8iPmh0 dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvcGNwcG9ydHNldGRlbW8vPC9hPjwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZn dDsmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7U29mdHdpcmVzJm5ic3A7bWFpbGluZyZu YnNwO2xpc3Q8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxhIGhyZWY9Im1haWx0 bzpTb2Z0d2lyZXNAaWV0Zi5vcmciPlNvZnR3aXJlc0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+ Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc29mdHdpcmVzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlczwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7PC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwO1NvZnR3aXJlcyZuYnNw O21haWxpbmcmbmJzcDtsaXN0PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZuYnNwOzxhIGhyZWY9 Im1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmciPlNvZnR3aXJlc0BpZXRmLm9yZzwvYT48L2Rpdj4N CjxkaXY+Jmd0OyZndDsmZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc29mdHdpcmVzPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwO19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jm5ic3A7U29mdHdpcmVzJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmbmJzcDs8YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGlldGYub3JnIj5Tb2Z0d2lyZXNAaWV0 Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPC9hPjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rp dj4NCjxkaXY+U29mdHdpcmVzJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L2Rpdj4NCjxkaXY+PGEg aHJlZj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVzQGlldGYub3JnPC9hPjwv ZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NvZnR3aXJlcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2ly ZXM8L2E+PC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KU29mdHdpcmVzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmciPlNvZnR3aXJlc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcyI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8L2E+PC9kaXY+DQo8 L3NwYW4+PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_97C30DD36C2B421BA0BEBCA68C9AAF28ipinfusioncom_-- From satoru.matsushima@gmail.com Mon Jun 25 02:46: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 7C52921F84FF for ; Mon, 25 Jun 2012 02:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uelC1SKyzCTN for ; Mon, 25 Jun 2012 02:46:24 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 11BE021F8474 for ; Mon, 25 Jun 2012 02:46:24 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6387720pbc.31 for ; Mon, 25 Jun 2012 02:46:23 -0700 (PDT) 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=2VD0i3Rt3YwI6Ijyv9SY7r78yBiwq8Mwh8mSQKI+2uE=; b=ycYuSpt3Au4G1G1ad6k0wCN8LqlicK4/EtDc3GqM9Q919aEPdDMnzodnvZTrIzAbvg sZTtol1aXoyA45E2gDoTIzBgvKm/AWu60ifQXcOGCCIacgeBl0soiYZjaN7BQhi0/mkV 0culONJQeQF2uI2V5dYi7G/9GF0l0lPyYWYh+aJu6JERuOYo8uoWVZVkqV2cZd274dWZ 1pvm0jMNk0+IJnOBwhWhK27pNRhTViKiqVqKbzfu1eFtsoi5wqZNLmfMVVYbFuJdGG8Z wBeEIcYZt9enaN1sFx3PsrTn8ufWeQMp3r0j1sFTUPymG4DLuDe+KPoI+7bT7Ok56DQ5 23AQ== Received: by 10.68.231.8 with SMTP id tc8mr37643958pbc.140.1340617583901; Mon, 25 Jun 2012 02:46:23 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id ua6sm8041882pbc.20.2012.06.25.02.46.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 02:46:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 18:46:18 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com> References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <97A4D74A-A531-4F83-B281-86973A3139A5@gmail.com> <570C97A3-D641-47EB-B0EB-B75ECD7E9EC4@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 09:46:24 -0000 Hi Peng, On 2012/06/25, at 18:34, Peng Wu wrote: >> Let's think that a CE provisioned with following BMR comes from MAP = DHCPv6 options. >>=20 >> BMR: >> o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} >> o Rule-ipv4-prefix : x.x.x.x/32 >> o EA-length : 0 >> o Port-param option : {PSID/length} >>=20 >> This BMR could be a LW46 provisioning means. >=20 > Again, all the information needed is the IPv4 address and port set. >=20 > 1) The item like rule-ipv6-prefix is not needed at all. > 2) Port set or PSID still needs extra provisioning (while in regular > MAP it's embedded in IPv6 address) >=20 > So why make it so difficult and obscure Not difficult, easy business for CE which implemented MAP. Other = difficulty in operator side in particular provisioning complex, that = should be same with LW46. It also makes to complete MAP spec in the = ea-len zero case. cheers, --satoru= From wdec.ietf@gmail.com Mon Jun 25 05:31:38 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 139D121F853A for ; Mon, 25 Jun 2012 05:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrHjiUSfi7OA for ; Mon, 25 Jun 2012 05:31:33 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id A835F21F8530 for ; Mon, 25 Jun 2012 05:31:33 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2178285qcm.15 for ; Mon, 25 Jun 2012 05:31:33 -0700 (PDT) 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=Ctf4FsVHMVf2l8CNL1SZuvdy1TqSk4NbeATxEx1p0Os=; b=LEM3YpPcDAv7PTfueJwLQ9Sfbeovz3AKQdnnZpbfUR4AXJPvPo76I8du0V+HnSODJr uW3aEa+VSCB6EwB2uosBSTOrkOKqrziy7kOH4fKVk/KE4+iabUwaAJsTV87GA+nG8ZNl SynCPBvDyjdV20uEzp9nCBZbTkJdpZkoLzIMgED6E1rx54b6Iyb4UtggugOsBUXiqPgS LhqNYsr4LOK5kaWDjrnnIUwEJK27XZpQ0nvrb6Et0QidlzdRfrW/XT6BCqt1OAagVYUI QxZuRBnywAjbze6giwx8j9AJRd/APbCLF2AR2se/gYcKUQ6fho5qRGaGWYpWVIoSCvIt 7jvA== MIME-Version: 1.0 Received: by 10.229.114.226 with SMTP id f34mr5313801qcq.36.1340627492862; Mon, 25 Jun 2012 05:31:32 -0700 (PDT) Received: by 10.229.246.6 with HTTP; Mon, 25 Jun 2012 05:31:32 -0700 (PDT) In-Reply-To: References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> Date: Mon, 25 Jun 2012 14:31:32 +0200 Message-ID: From: Wojciech Dec To: Softwires-wg Content-Type: multipart/alternative; boundary=00235446fea07cfc0f04c34b29d0 Cc: Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 12:31:38 -0000 --00235446fea07cfc0f04c34b29d0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Some points for the record: * lightweight 4over6 is not a WG draft nor does it have a monopoly on the shape of final solutions. * Discussion on what lw 4over6 actually solves is still expected. * Nothing in the stateless solution (eg MAP) says that they have to be used with stateful elements, or at what scale they are to be deployed. The fact MAP devices can be used with stateful elements is a basic fact deriving from the use of common IPv6 data-planes. * Lw 4over6 is co-authored by one of the current and also one of the past WG chairs... -Woj. On 24 June 2012 17:13, Qiong wrote: > Hi Satoru, > > Every solution has its solution space with respective application > scenarios as well as pros and cons. > The essence of stateless solution, which follows the stateless motivation > approved by the WG, is to achieve efficient address mapping by algorithmi= c > embedding part of IPv4 address+port set into IPv6 address/prefix, while t= he > essence of stateful solution is to maintain the subscriber-based state > on-demand. IPv4 address and IPv6 address is not coupled, and there is no > requirement on IPv6 addressing format. It is twisty to mix them together = in > one document as in the current draft-ietf-softwire-map. It is not clear f= or > vendors to implement and for operators to deploy, and will lose the > features for both. > > I'm not saying I'm against the work of stateless solutions, but it is > really not fair to just extend one solution arbitrarily to cover another > one without the permission from the WG and the authors. In particular, > lightweight 4over6 is a collaborative work of 15 co-authors for more than > one and a half years, including operators from China Telecom, Tsinghua, > Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and al= so > the vendors from Huawei, Juniper and Cisco. > > Our WG or DT has never reached the consensus to have one unified document > for both stateful and stateless sotluion. And the motivation draft has > never been extended to include the stateful features as well. So unless w= e > reach the consensus first in the WG, we can then move forward with this > document. > > Best wishes > > > On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima < > satoru.matsushima@gmail.com> wrote: > >> Hi Qiong, >> >> I'm disagree with your opinion. >> >> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in th= e >> DT. >> 2. MAP just covers so called '1:1 mode' with most granular mapping rule >> for CEs provisioning, which is as one of its characteristics. >> 3. The motivation draft does not restrict that as you stated, just >> 'assumed', it's neither 'MUST' nor 'SHOULD'. >> >> Best regards, >> --satoru >> >> >> On 2012/06/24, at 14:35, Qiong wrote: >> >> > Hi all, >> > >> > As we all know, once an individual draft is adopted as a WG draft, it >> is owned by the whole WG, rather than just the editors. Just as Remi sai= d, >> the normal procedure to follow is to reach WG consensus _before_ posting= a >> newly edited version. >> > >> > From draft-mdt-softwire-mapping-address-and-port-03 to >> draft-ietf-softwire-map-00, there are several changes between them. In >> particular, the newly introduced "1:1 mode", which decouples IPv4 and IP= v6 >> addressing, has never been discussed openly in the WG mailing list, or e= ven >> in the MAP design team either. >> > >> > Actually, this "1:1 mode" is against the stateless-4v6-motivation >> draft. The motivation draft has clearly defines the "Stateless 4/6 >> solution" as follows: >> > >> > Stateless 4/6 solution denotes a solution which does not require any >> per-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP >> address sharing function in the Service Provider's network. This categor= y >> of solutions assumes a dependency between an IPv6 prefix and IPv4 addres= s. >> > >> > AFAIK what the WG has adopted MAP related draft is >> draft-mdt-softwire-mapping-address-and-port-03, NOT >> draft-ietf-softwire-map-00. And the stateless solution should =93respons= e to >> the solution motivation document=94 according to the Softwire charter. T= hat >> means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. >> > >> > We can all recall that our softwire WG has worked on stateless >> solutions for more than one and a half years, and we have achieved a lot= of >> work which has been documented in charter, stateless motivation, >> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic >> "stateless" principle and the MAP design team is also working on it >> together to find a better algorithm, address format, etc. So it is reall= y >> not appropriate to make such changes when MAP is adopted as a WG item in >> such a short time. >> > >> > From this perspective, draft-ietf-softwire-map-00 can only be regarded >> as draft-XX-softwire-mapping-address-and-port-04. It is not even the out= put >> of MAP design team. >> > >> > Best wishes >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >> >> > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > > --00235446fea07cfc0f04c34b29d0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Some points for the record:

* lightweight 4over6 is not a WG draft = nor does it have a monopoly on the shape of final solutions.

* Discu= ssion on what lw 4over6 actually solves is still expected.

* Nothing= in the stateless solution (eg MAP) says that they have to be used with sta= teful elements, or at what scale they are to be deployed. The fact MAP devi= ces can be used with stateful elements is a basic fact deriving from the us= e of common IPv6 data-planes.

* Lw 4over6 is co-authored by one of the current and also one of the pa= st WG chairs...

-Woj.

On 24 June 2= 012 17:13, Qiong <bingxuere@gmail.com> wrote:
Hi Satoru,

Every solution has its sol= ution space with respective application scenarios as well as pros and cons.=
The essence of stateless solution, which follows the stateless motivation a= pproved by the WG, is to achieve efficient address mapping by algorithmic e= mbedding part of IPv4 address+port set into IPv6 address/prefix, while the = essence of stateful solution is to maintain the subscriber-based state on-d= emand. IPv4 address and IPv6 address is not coupled, and there is no requir= ement on IPv6 addressing format. It is twisty to mix them together in one d= ocument as in the current draft-ietf-softwire-map. It is not clear for vend= ors to implement and for operators to deploy, and will lose the features fo= r both.

I'm not saying I'm against the work of stateless solutions, but= it is really not fair to just extend one solution arbitrarily to cover ano= ther one without the permission from the WG and the authors. In particular,= =A0 lightweight 4over6 is a collaborative work of 15 co-authors for more t= han one and a half years, including operators from China Telecom, Tsinghua,= Comcast,=20 France telecom, Deutsche Telekom, Bouygues Telecom, etc., and=20 also the vendors from Huawei, Juniper and Cisco.

Our WG or DT has ne= ver reached the consensus to have one unified document for both stateful an= d stateless sotluion. And the motivation draft has never been extended to i= nclude the stateful features as well. So unless we reach the consensus firs= t in the WG, we can then move forward with this document.

Best wishes


On Sun, Jun 24,= 2012 at 2:00 PM, Satoru Matsushima <satoru.matsushima@gmail.com= > wrote:
Hi Qiong,

I'm disagree with your opinion.

1. Recent changes in draft-ietf-softwire-map-00 has been discussed in the D= T.
2. MAP just covers so called '1:1 mode' with most granular mapping = rule for CEs provisioning, which is as one of its characteristics.
3. The motivation draft does not restrict that as you stated, just 'ass= umed', it's neither 'MUST' nor 'SHOULD'.

Best regards,
--satoru


On 2012/06/24, at 14:35, Qiong wrote:

> Hi all,
>
> As we all know, once an individual draft is adopted as a WG draft, it = is owned by the whole WG, rather than just the editors. Just as Remi said, = the normal procedure to follow is to reach WG consensus _before_ posting a = newly edited version.
>
> From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf-soft= wire-map-00, there are several changes between them. In particular, the new= ly introduced "1:1 mode", which decouples IPv4 and IPv6 addressin= g, has never been discussed openly in the WG mailing list, or even in the M= AP design team either.
>
> Actually, this "1:1 mode" is against the stateless-4v6-motiv= ation draft. The motivation draft has clearly defines the "Stateless 4= /6 solution" as follows:
>
> Stateless 4/6 solution denotes a solution which does not require any p= er-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP add= ress sharing function in the Service Provider's network. This category = of solutions assumes a dependency between an IPv6 prefix and IPv4 address.<= br> >
> AFAIK what the WG has adopted MAP related draft is draft-mdt-softwire-= mapping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the statel= ess solution should =93response to the solution motivation document=94 acco= rding to the Softwire charter. That means draft-ietf-softwire-map-00 IS NOT= QUALIFIED to be a WG draft.
>
> We can all recall that our softwire WG has worked on stateless solutio= ns for more than one and a half years, and we have achieved a lot of work w= hich has been documented in charter, stateless motivation, 4rd-varients, MA= P-03, etc. AFAIK all the authors have kept the basic "stateless" = principle and the MAP design team is also working on it together to find a = better algorithm, address format, etc. So it is really not appropriate to m= ake such changes when MAP is adopted as a WG item in such a short time.
>
> From this perspective, draft-ietf-softwire-map-00 can only be regarded= as draft-XX-softwire-mapping-address-and-port-04. It is not even the outpu= t of MAP design team.
>
> Best wishes
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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




--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Su= n
China Telecom Beijing Research Institude


Open source code:<= br> 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<= /a>
https://www.ietf.org/mailman/listinfo/softwires


--00235446fea07cfc0f04c34b29d0-- From sunqi.csnet.thu@gmail.com Mon Jun 25 06:01: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 81F1521F858A for ; Mon, 25 Jun 2012 06:01:44 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50Y5DB4Hp2Zb for ; Mon, 25 Jun 2012 06:01:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4729E21F8596 for ; Mon, 25 Jun 2012 06:01:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6609698pbc.31 for ; Mon, 25 Jun 2012 06:01:40 -0700 (PDT) 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-mailer:mime-version:message-id:content-type; bh=HRAIfumJEOzN5LOaL311QnqH+6YdILIwV/VLOQOeT+g=; b=fWf8Jx8c02ZRCr+vjFEJ79+KkcLYl7fgt622aYNsQ2eD/1oAOUykbKstHF04ByHwaE cwN60K5ai/Pz4M1E+dkRxb8TcQyaOkkyz1uc7d6L5ofoCitrj6qjP+yACzwIOvhnU3vW CJkF4m9E1d1kDTL3PDYkfZ5mROAH1DCxlngAK2205HlOUb6UxQAYj9nf/5kpE/beeIup ZPxgB+46zNNHsS3GDdvEo2+z+xfrGCIXRiYGau6545LrkhZgiKu8V11GbiO6B8cxuROg 4dMujLI08g/W3lZxn0qHDRqUjVWlhEKg7TSxaJ2KAbZ9Onbd6n1bb0OijfDfA0ozJEFA KvNQ== Received: by 10.68.201.195 with SMTP id kc3mr41189284pbc.33.1340629299748; Mon, 25 Jun 2012 06:01:39 -0700 (PDT) Received: from sunqi ([166.111.68.233]) by mx.google.com with ESMTPS id pg3sm8493428pbc.2.2012.06.25.06.01.34 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 06:01:38 -0700 (PDT) Date: Mon, 25 Jun 2012 21:01:29 +0800 From: "Qi Sun" To: "Tetsuya Murakami" , "Tetsuya Murakami" References: , <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> , <97C30DD3-6C2B-421B-A0BE-BCA68C9AAF28@ipinfusion.com> X-Priority: 3 X-GUID: 7A72FC57-6844-4C14-B902-E6CA109944A8 X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012062521012980418443@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart643405138514_=----" Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 13:01:44 -0000 This is a multi-part message in MIME format. ------=_001_NextPart643405138514_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVzdHN1eWEsDQoNCg0KMS4gSWYgYSBidW5jaCBvZiBlbnRyaWVzIGZvcm1pbmcgYSBiaW5k aW5nIHRhYmxlIGlzIG5vdCAic3RhdGUiLCBwbGVhc2UgY2xhcmlmeSB3aGF0IGlzICJzdGF0ZSIg PyBBbmQgd2hhdCBpcyBzbyBjYWxsZWQgc3RhdGVsZXNzPw0KDQoyLiBZb3Ugc2FpZCB0aGUgZW50 cmllcyBhcmUgInN0b3JlZCIsIGRvIHlvdSBtZWFuIG9uY2UgaXQgaXMgY3JlYXRlZCBpdCB3aWxs IGJlIG5ldmVyIGNoYW5nZWQ/IA0KSWYgdGhlIG51bWJlciBvZiB1c2VycyBrZWVwcyBncm93aW5n IHNvIHRoYXQgaXQgZXhjZWVkcyB0aGUgbnVtYmVyIG9mIGVudHJpZXMgInN0b3JlZCIsIGRvZXMg QlIgYWRkIG5ldyBlbnRyaWVzPyANCklmIHVzZXJzIGxlYXZlIHRoZSBuZXR3b3JrLCBzaG91bGQg QlIgZGVsZXRlIHRob3NlIHVudXNlZCBlbnRyaWVzIGZvciBzYXZpbmcgYWRkcmVzcyByZXNvdXJj ZXMgPw0KDQozLiBXaGVuIHRoZXJlIGFyZSBwYWNrZXRzIGluYm91bmQgb24gQm9yZGVyIFJlbGF5 KEJSKSwgdGhlIEJSIGhhcyB0byBsb29rIHRocm91Z2ggdGhlIGJpbmRpbmcgdGFibGUgZm9yIHBy b3BlciBkZXN0aW5hdGlvbiBhZGRyZXNzZXMuIFRoYXQgaXMgZXhhY3RseSB3aGF0IGx3NG92ZXI2 IGRvZXMuDQoNClRoYW5rIHlvdSENCg0KDQoNCg0KUWkgU3VuDQoNCkZyb206IFRldHN1eWEgTXVy YWthbWkNCkRhdGU6IDIwMTItMDYtMjUgMTc6MzYNClRvOiBUZXRzdXlhIE11cmFrYW1pDQpDQzog c3VucWkuY3NuZXQudGh1OyBTYXRvcnUgTWF0c3VzaGltYTsgc29mdHdpcmVzIFdHOyBZb25nIEN1 aQ0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIFtTb2Z0d2lyZV0gZHJhZnQtaWV0Zi1zb2Z0d2ly ZS1tYXAtMDAgZG9lcyBOT1QgcmVmbGVjdCB0aGUgY29uc2Vuc3VzIGZyb20gdGhlIFdHDQpIaSBR aSwgDQoNCg0KSW4gYWRkaXRpb24sIG91ciBNQVAgaW1wbGVtZW50YXRpb24gY2FuIGhhbmRsZSBz dWNoIGEgYnVuY2ggb2YgZW50cmllcy4gT2YgY291cnNlLCBpdCByZXF1aXJlcyBlbm91Z2ggbWVt b3J5IGluIG9yZGVyIHRvIHN0b3JlIGFsbCBvZiB0aGVtIGluIGl0cyBvd24gbWVtb3J5LiBCdXQg SSBjb3VsZCBub3Qgc2VlIGFueSBvdGhlciBwcm9ibGVtcyBleGNlcHQgcmVxdWlyZWQgbWVtb3J5 IHNpemUuIEFsc28sIGVhY2ggZW50cnkgaXMgc3RvcmVkIHN0YXRpY2FsbHkgYW5kIHNvIE1BUCBp bXBsZW1lbnRhdGlvbiBkb2VzIG5vdCBtYWludGFpbiB0aGUgInN0YXRlIiBmb3IgZWFjaCBlbnRy eS4NCltRaSBTdW5dIElmIGEgYnVuY2ggb2YgZW50cmllcyBmb3JtaW5nIGEgbWFwcGluZyB0YWJs ZSBpcyBub3QgInN0YXRlIiwgcGxlYXNlIGNsYXJpZnkgd2hhdCBpcyAic3RhdGUiID8gQW5kIHdo YXQgaXMgc28gY2FsbGVkIHN0YXRlbGVzcz8NCltRaSBTdW5dIFlvdSBzYWlkIHRoZSBlbnRyaWVz IGFyZSAic3RvcmVkIiwgZG8geW91IG1lYW4gb25jZSBpdCBpcyBjcmVhdGVkIGl0IHdpbGwgYmUg bmV2ZXIgY2hhbmdlZD8gDQoNCg0KDQpUaGFua3MsDQpUZXRzdXlhIE11cmFrYW1pDQoNCg0KT24g MjAxMi8wNi8yNSwgYXQgMjoyNywgVGV0c3V5YSBNdXJha2FtaSB3cm90ZToNCg0KDQpIaSBRaSwg DQoNCg0KRXZlbiB0aG91Z2ggdGhlcmUgYXJlIGEgYnVuY2ggb2YgbWFwcGluZyBydWxlcywgZWFj aCBtYXBwaW5nIHJ1bGUgaGFzIG5vIHN0YXRlLiBTaW5jZSBlYWNoIG1hcHBpbmcgcnVsZXMgaXMg c2V0IG1hbnVhbGx5LCBCUiBkb2VzIG5vdCBtYWludGFpbiBlYWNoIG1hcHBpbmcgcnVsZSBhbmQg anVzdCBzdG9yZSB0aGVtIGluIGl0cyBvd24gbWVtb3J5LiBTbywgSSBhbSBub3Qgc3VyZSB3aHkg eW91IGFyZSBjYWxsaW5nIHRoZSAic3RhdGUiIGlmIHRoZXJlIGFyZSBhIGJ1bmNoIG9mIG1hcHBp bmcgcnVsZXMuIElmIHlvdSBhcmUgc2F5aW5nIHRoYXQsIGRvIHlvdSBhc3N1bWUgaG93IG1hbnkg ZW50cmllcyBzaG91bGQgYmUgZXhpc3RlZCBpbiB0aGUgdGFibGUgaW4gb3JkZXIgdG8gY2FsbCBp dCB0byB0aGUgInN0YXRlIi4gRnJvbSB0aGUgaW1wbGVtZW50YXRpb24gcGVyc3BlY3RpdmUsIGV2 ZW4gdGhvdWdoIHRoZXJlIGFyZSAxMDAwMDAwMCBlbnRyaWVzIGluIHRoZSB0YWJsZSwgdGhlIHBy b2JsZW0gaXMganVzdCBob3cgbXVjaCBtZW1vcnkgaXMgbmVlZGVkLg0KDQoNClRoYW5rcywNClRl dHN1eWEgTXVyYWthbWkgDQoNCg0KT24gMjAxMi8wNi8yNCwgYXQgMjM6NTEsIFFpIFN1biB3cm90 ZToNCg0KDQpIaSBTYXRvcnUsDQoNCkluIE1BUCAxOjEgbW9kZSwgaWYgdGhlcmUgYXJlIDEwMDAw MDAwIHN1YnNjcmliZXJzLCB0aGVyZSB3b3VsZCBiZSAxMDAwMDAwMCBNQVAgZG9tYWlucyB3aGlj aCBhIEJSIGhhcyB0byBtYW5hZ2UuIEkgdGhpbmsgdGhhdCB3aWxsIGNyZWF0ZSBhIGh1Z2UgbWFw cGluZyB0YWJsZSBvbiB0aGUgQlIsIHdoaWNoIGlzIGNhbGxlZCAnc3RhdGUnIHRoYXQgc3RhdGVm dWwgc29sdXRpb25zIGRlYWwgd2l0aC4NCg0KQmVzdCBSZWdhcmRzIQ0KDQoNCg0KDQpRaSBTdW4N Cg0KRnJvbTogU2F0b3J1IE1hdHN1c2hpbWENCkRhdGU6IDIwMTItMDYtMjUgMTA6MjcNClRvOiBM ZWUsIFlpdQ0KQ0M6IHNvZnR3aXJlc0BpZXRmLm9yZzsgWW9uZyBDdWkNClN1YmplY3Q6IFJlOiBb U29mdHdpcmVzXSBbU29mdHdpcmVdIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwIGRvZXMgTk9U IHJlZmxlY3QgdGhlIGNvbnNlbnN1cyBmcm9tIHRoZSBXRw0KSGkgWWl1LA0KDQpObywgdGhhdCdz IGEgbWlzdW5kZXJzdGFuZGluZy4NCkN1cnJlbnQgTUFQIHNwZWNpZnkgdGhlIGNhc2UgZm9yIGVh LWxlbiBpcyAnemVybycuIEl0IGlzICdwZXItc3Vic2NyaWJlciBtYXBwaW5nJyBpbiBzdGF0ZWxl c3MgbWFubmVyLCBub3QgdG8gaW50cm9kdWNlICdwZXItZmxvdyBOQVQgYmluZGluZycgb3IgJ3Bl ci1zdWJzY3JpYmVyIHN0YXRlIG9uIGRlbWFuZCcuDQoNCmNoZWVycywNCi0tc2F0b3J1DQoNCk9u IDIwMTIvMDYvMjUsIGF0IDI6MzIsIExlZSwgWWl1IHdyb3RlOg0KDQo+IERlYXIgU2F0b3J1IGFu ZCBNQVAtRFQNCj4gDQo+IEkgZWNobyB3aGF0IFBlbmcgYW5kIFFpb25nIHNhaWQuIFdoZW4gdGhl IFdHIGFncmVlZCB3b3JraW5nIG9uIHRoZQ0KPiBzdGF0ZWxlc3Mgc29sdXRpb24sIGl0IHdhcyB2 ZXJ5IGNsZWFyIHN0YXRlZCB0aGF0IHRoZSBzb2x1dGlvbiB3b3VsZCBub3QNCj4gbWFpbnRhaW4g c3RhdGVzIGluIHRoZSBuZXR3b3JrLiBJZiB0aGUgMToxIG1vZGUgY2hhbmdlZCB0aGlzLCB0aGlz IG5vDQo+IGxvbmdlciBtYXRjaGVkIHRoZSByZXF1aXJlbWVudHMgc3RhdGVkIGluIHRoZSBzdGF0 ZWxlc3MgbW90aXZhdGlvbiBkcmFmdCwNCj4gdGh1cywgaXQgd291bGQgZGlzcXVhbGlmeSBNQVAg YXMgYSBzb2x1dGlvbiBmb3IgdGhlIG1vdGl2YXRpb24gZHJhZnQuDQo+IA0KPiBBRkFJSywgdGhl IE1BUCBEZXNpZ24gVGVhbSBjb3VsZCBwcm9wb3NlIGEgY2hhbmdlLCBidXQgc3VjaCBhIGRyYW1h dGljDQo+IGNoYW5nZSBieSBpbnRyb2R1Y2luZyBzdGF0ZXMgaW4gdGhlIG5ldHdvcmsgd291bGQg cmVxdWlyZSBXRyBhcHByb3ZhbC4gSQ0KPiB3b3VsZCBsaWtlIHRoZSBjaGFpcnMgdG8gY2xhcmlm eSB0aGlzLg0KPiANCj4gVGhhbmtzLA0KPiBZaXUNCj4gDQo+IA0KPiBPbiA2LzI0LzEyIDEyOjIx IFBNLCAiUGVuZyBXdSIgPHBlbmd3dS50aHVAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+PiBIaSBR aW9uZywgU2F0b3J1IGFuZCBhbGwsDQo+PiANCj4+IEkgc2hvdWxkIHRoYW5rIFFpb25nIGZvciBw b2ludGluZyB0aGlzIG91dC4gSSBnb3R0YSBzYXkgSSdtIGEgYml0IHNob2NrZWQuDQo+PiBJZiBJ IHVuZGVyc3RhbmQgdGhlIHByb2NlZHVyZXMgb2YgSUVURiBjb3JyZWN0bHksIGEgV0cgZG9jdW1l bnQgc2hvdWxkDQo+PiByZWZsZWN0IHRoZSBjb25zZW5zdXMgb2YgdGhlIFdHLiBNQVAgaXMgYXBw cm92ZWQgYnkgdGhlIFdHIGFzIGENCj4+IHN0YXRlbGVzcyBzb2x1dGlvbi4gQXMgYSBwYXJ0aWNp cGF0b3IgaW4gU29mdHdpcmUsIEkgZGlkbid0IGdldCB0aGUNCj4+IGluZm9ybWF0aW9uIGFueXdo ZXJlIHRoYXQgdGhlIE1BUCBXRyBkb2N1bWVudCB3b3VsZCBjb3ZlciB0aGUNCj4+IHNvLWNhbGxl ZCAxOjEsIGluIGZhY3QgcGVyLXVzZXIgc3RhdGVmdWwgbW9kZSBiZWZvcmUgaXQgd2FzIHJlbGVh c2VkLA0KPj4gbm90IHRvIHNheSBkaXNjdXNzIGluIHRoZSBXRy4gRG9uJ3QgdGhlIFdHIG5lZWQg dG8gYXBwcm92ZSBzdWNoIGJpZw0KPj4gY2hhbmdlIGFueW1vcmU/DQo+PiANCj4+IE5vdyBsZXQg bWUgcHJvdmlkZSBteSBpbXByZXNzaW9uIGFzIGFuIG91dHNpZGVyIG9mIHRoZSBNQVAgRFQuIFlv dQ0KPj4gZ3V5cyBtYWtlIGdyZWF0IGVmZm9ydCB0byBidWlsZCB0aGUgc29sdXRpb24sIFRoZSBh ZGRyZXNzIGNvbXBvc2l0aW9uLA0KPj4gdGhlIEdNQSBhbGdvcml0aG0sIHRoZSBkaWZmZXJlbnQg dHlwZXMgb2YgYWRkcmVzcyBtYXBwaW5nIHJ1bGVzLg0KPj4gc2hvdWxkIGJlIHF1aXRlIGRpZmZp Y3VsdCB0byBwdWxsIHRvZ2V0aGVyIHN1Y2ggc29waGlzdGljYXRlZCBpZGVhcy4gSQ0KPj4gZ3Vl c3MgdGhhdCdzIHdoYXQgaXQgdGFrZXMgdG8gYWNoaWV2ZSB0aGUgYmVuaWZpdHMgb2Ygc3RhdGVs ZXNzbmVzcy4NCj4+IEFuZCBJIGFkbWlyZSB0aGF0LCBicmF2by4gVGhlbiwgYWxsIG9mIGEgc3Vk ZGVuLCB5b3UgZ3V5cyBhcmUgc2F5aW5nLA0KPj4gbGV0J3MgYXBwbHkgdGhpcyBzb3BoaXN0aWNh dGVkIG1ldGhvZCB0byB0aGUgZGlmZmVyZW50IHByb2JsZW0sIGJ5DQo+PiBkcm9wcGluZyBxdWl0 ZSBzb21lIGNvbWxleGl0eSBhbmQgdHdpc3R0aW5nIHRoZSBtZWNoYW5pc20gYSBiaXQsIHNlZW1z DQo+PiBpdCBtYXkgd29yay4gQ29uc2lkZXJpbmcgdGhlIHByb2JsZW0gYXJlIG5vdyBzb2x2ZWQg aW4gYSBtb3JlIHB1cmUgYW5kDQo+PiBjbGVhciB3YXksIEknbSBzb3JyeSBidXQgSSBDQU5OT1Qg Zm9sbG93IHRoZSBsb2dpYyBoZXJlLg0KPj4gDQo+PiBPbiBTdW4sIEp1biAyNCwgMjAxMiBhdCAy OjAwIFBNLCBTYXRvcnUgTWF0c3VzaGltYQ0KPj4gPHNhdG9ydS5tYXRzdXNoaW1hQGdtYWlsLmNv bT4gd3JvdGU6DQo+Pj4gSGkgUWlvbmcsDQo+Pj4gDQo+Pj4gSSdtIGRpc2FncmVlIHdpdGggeW91 ciBvcGluaW9uLg0KPj4+IA0KPj4+IDEuIFJlY2VudCBjaGFuZ2VzIGluIGRyYWZ0LWlldGYtc29m dHdpcmUtbWFwLTAwIGhhcyBiZWVuIGRpc2N1c3NlZCBpbg0KPj4+IHRoZSBEVC4NCj4+PiAyLiBN QVAganVzdCBjb3ZlcnMgc28gY2FsbGVkICcxOjEgbW9kZScgd2l0aCBtb3N0IGdyYW51bGFyIG1h cHBpbmcgcnVsZQ0KPj4+IGZvciBDRXMgcHJvdmlzaW9uaW5nLCB3aGljaCBpcyBhcyBvbmUgb2Yg aXRzIGNoYXJhY3RlcmlzdGljcy4NCj4+PiAzLiBUaGUgbW90aXZhdGlvbiBkcmFmdCBkb2VzIG5v dCByZXN0cmljdCB0aGF0IGFzIHlvdSBzdGF0ZWQsIGp1c3QNCj4+PiAnYXNzdW1lZCcsIGl0J3Mg bmVpdGhlciAnTVVTVCcgbm9yICdTSE9VTEQnLg0KPj4+IA0KPj4+IEJlc3QgcmVnYXJkcywNCj4+ PiAtLXNhdG9ydQ0KPj4+IA0KPj4+IA0KPj4+IE9uIDIwMTIvMDYvMjQsIGF0IDE0OjM1LCBRaW9u ZyB3cm90ZToNCj4+PiANCj4+Pj4gSGkgYWxsLA0KPj4+PiANCj4+Pj4gQXMgd2UgYWxsIGtub3cs IG9uY2UgYW4gaW5kaXZpZHVhbCBkcmFmdCBpcyBhZG9wdGVkIGFzIGEgV0cgZHJhZnQsIGl0DQo+ Pj4+IGlzIG93bmVkIGJ5IHRoZSB3aG9sZSBXRywgcmF0aGVyIHRoYW4ganVzdCB0aGUgZWRpdG9y cy4gSnVzdCBhcyBSZW1pDQo+Pj4+IHNhaWQsIHRoZSBub3JtYWwgcHJvY2VkdXJlIHRvIGZvbGxv dyBpcyB0byByZWFjaCBXRyBjb25zZW5zdXMgX2JlZm9yZV8NCj4+Pj4gcG9zdGluZyBhIG5ld2x5 IGVkaXRlZCB2ZXJzaW9uLg0KPj4+PiANCj4+Pj4gRnJvbSBkcmFmdC1tZHQtc29mdHdpcmUtbWFw cGluZy1hZGRyZXNzLWFuZC1wb3J0LTAzIHRvDQo+Pj4+IGRyYWZ0LWlldGYtc29mdHdpcmUtbWFw LTAwLCB0aGVyZSBhcmUgc2V2ZXJhbCBjaGFuZ2VzIGJldHdlZW4gdGhlbS4gSW4NCj4+Pj4gcGFy dGljdWxhciwgdGhlIG5ld2x5IGludHJvZHVjZWQgIjE6MSBtb2RlIiwgd2hpY2ggZGVjb3VwbGVz IElQdjQgYW5kDQo+Pj4+IElQdjYgYWRkcmVzc2luZywgaGFzIG5ldmVyIGJlZW4gZGlzY3Vzc2Vk IG9wZW5seSBpbiB0aGUgV0cgbWFpbGluZw0KPj4+PiBsaXN0LCBvciBldmVuIGluIHRoZSBNQVAg ZGVzaWduIHRlYW0gZWl0aGVyLg0KPj4+PiANCj4+Pj4gQWN0dWFsbHksIHRoaXMgIjE6MSBtb2Rl IiBpcyBhZ2FpbnN0IHRoZSBzdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb24NCj4+Pj4gZHJhZnQuIFRo ZSBtb3RpdmF0aW9uIGRyYWZ0IGhhcyBjbGVhcmx5IGRlZmluZXMgdGhlICJTdGF0ZWxlc3MgNC82 DQo+Pj4+IHNvbHV0aW9uIiBhcyBmb2xsb3dzOg0KPj4+PiANCj4+Pj4gU3RhdGVsZXNzIDQvNiBz b2x1dGlvbiBkZW5vdGVzIGEgc29sdXRpb24gd2hpY2ggZG9lcyBub3QgcmVxdWlyZSBhbnkNCj4+ Pj4gcGVyLXVzZXIgc3RhdGUgKHNlZSBTZWN0aW9uIDIuMyBvZiBbUkZDMTk1OF0pIHRvIGJlIG1h aW50YWluZWQgYnkgYW55DQo+Pj4+IElQIGFkZHJlc3Mgc2hhcmluZyBmdW5jdGlvbiBpbiB0aGUg U2VydmljZSBQcm92aWRlcidzIG5ldHdvcmsuIFRoaXMNCj4+Pj4gY2F0ZWdvcnkgb2Ygc29sdXRp b25zIGFzc3VtZXMgYSBkZXBlbmRlbmN5IGJldHdlZW4gYW4gSVB2NiBwcmVmaXggYW5kDQo+Pj4+ IElQdjQgYWRkcmVzcy4NCj4+Pj4gDQo+Pj4+IEFGQUlLIHdoYXQgdGhlIFdHIGhhcyBhZG9wdGVk IE1BUCByZWxhdGVkIGRyYWZ0IGlzDQo+Pj4+IGRyYWZ0LW1kdC1zb2Z0d2lyZS1tYXBwaW5nLWFk ZHJlc3MtYW5kLXBvcnQtMDMsIE5PVA0KPj4+PiBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMC4g QW5kIHRoZSBzdGF0ZWxlc3Mgc29sdXRpb24gc2hvdWxkIMKzcmVzcG9uc2UNCj4+Pj4gdG8gdGhl IHNvbHV0aW9uIG1vdGl2YXRpb24gZG9jdW1lbnTCsiBhY2NvcmRpbmcgdG8gdGhlIFNvZnR3aXJl IGNoYXJ0ZXIuDQo+Pj4+IFRoYXQgbWVhbnMgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgSVMg Tk9UIFFVQUxJRklFRCB0byBiZSBhIFdHIGRyYWZ0Lg0KPj4+PiANCj4+Pj4gV2UgY2FuIGFsbCBy ZWNhbGwgdGhhdCBvdXIgc29mdHdpcmUgV0cgaGFzIHdvcmtlZCBvbiBzdGF0ZWxlc3MNCj4+Pj4g c29sdXRpb25zIGZvciBtb3JlIHRoYW4gb25lIGFuZCBhIGhhbGYgeWVhcnMsIGFuZCB3ZSBoYXZl IGFjaGlldmVkIGENCj4+Pj4gbG90IG9mIHdvcmsgd2hpY2ggaGFzIGJlZW4gZG9jdW1lbnRlZCBp biBjaGFydGVyLCBzdGF0ZWxlc3MgbW90aXZhdGlvbiwNCj4+Pj4gNHJkLXZhcmllbnRzLCBNQVAt MDMsIGV0Yy4gQUZBSUsgYWxsIHRoZSBhdXRob3JzIGhhdmUga2VwdCB0aGUgYmFzaWMNCj4+Pj4g InN0YXRlbGVzcyIgcHJpbmNpcGxlIGFuZCB0aGUgTUFQIGRlc2lnbiB0ZWFtIGlzIGFsc28gd29y a2luZyBvbiBpdA0KPj4+PiB0b2dldGhlciB0byBmaW5kIGEgYmV0dGVyIGFsZ29yaXRobSwgYWRk cmVzcyBmb3JtYXQsIGV0Yy4gU28gaXQgaXMNCj4+Pj4gcmVhbGx5IG5vdCBhcHByb3ByaWF0ZSB0 byBtYWtlIHN1Y2ggY2hhbmdlcyB3aGVuIE1BUCBpcyBhZG9wdGVkIGFzIGEgV0cNCj4+Pj4gaXRl bSBpbiBzdWNoIGEgc2hvcnQgdGltZS4NCj4+Pj4gDQo+Pj4+IEZyb20gdGhpcyBwZXJzcGVjdGl2 ZSwgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgY2FuIG9ubHkgYmUgcmVnYXJkZWQNCj4+Pj4g YXMgZHJhZnQtWFgtc29mdHdpcmUtbWFwcGluZy1hZGRyZXNzLWFuZC1wb3J0LTA0LiBJdCBpcyBu b3QgZXZlbiB0aGUNCj4+Pj4gb3V0cHV0IG9mIE1BUCBkZXNpZ24gdGVhbS4NCj4+Pj4gDQo+Pj4+ IEJlc3Qgd2lzaGVzDQo+Pj4+IA0KPj4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQo+Pj4+IFFpb25nIFN1bg0KPj4+PiBDaGluYSBUZWxlY29tIEJlaWpp bmcgUmVzZWFyY2ggSW5zdGl0dWRlDQo+Pj4+IA0KPj4+PiANCj4+Pj4gT3BlbiBzb3VyY2UgY29k ZToNCj4+Pj4gbGlnaHR3ZWlnaHQgNG92ZXI2OiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2pl Y3RzL2xhZnQ2Lw0KPj4+PiBQQ1AtbmF0Y29vcmQ6IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJv amVjdHMvcGNwcG9ydHNldGRlbW8vDQo+Pj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQo+Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gU29mdHdpcmVzIG1haWxpbmcgbGlz dA0KPj4+PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4+ PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NvZnR3aXJlcw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4+IFNvZnR3aXJlc0BpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNvZnR3 aXJlcyBtYWlsaW5nIGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVz ------=_001_NextPart643405138514_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Testsuya,


1. If a=20 bunch of entries forming a binding table is not "state", pl= ease=20 clarify what is "state" ? And what is so called stateless?

2.=20 You said the entries are "stored", do you mea= n once=20 it is created it will be never changed?
If the number of users keeps g= rowing=20 so that it exceeds the number of entries "stored", does BR add new entries= ?=20
If users leave the network, should BR delete those unused entries for = saving=20 address resources ?

3. When there are packets inbound on Border=20 Relay(BR), the BR has to look through the binding table for proper destina= tion=20 addresses. That is exactly what lw4over6=20 does.
Thank you!
 
Qi Sun
 
Date: 2012-06-25 17:36
CC: sunqi.csnet.thu; Satoru Matsushima; softwires WG; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
Hi Qi,=20

In addition, our MAP implementation can handle such a bunch of entrie= s. Of=20 course, it requires enough memory in order to store all of them in its own= =20 memory. But I could not see any other problems except required memory size= .=20 Also, each entry is stored statically and so MAP implementation does not=20 maintain the "state" for each entry.
[Qi=20 Sun] If a bunch of entries forming a mapping table is=20 not "state", please clarify what is "state" ? And what is s= o=20 called stateless?
[Qi Sun] You said the entries are "stored", do you mea= n once=20 it is created it will be never changed?=20

Thanks,
Tetsuya Murakami

On 2012/06/25, at 2:27, Tetsuya Murakami wrote:
Hi=20 Qi,=20

Even though there are a bunch of mapping rules, each mapping rule h= as no=20 state. Since each mapping rules is set manually, BR does not maintain ea= ch=20 mapping rule and just store them in its own memory. So, I am not sure wh= y you=20 are calling the "state" if there are a bunch of mapping rules. If you ar= e=20 saying that, do you assume how many entries should be existed in the tab= le in=20 order to call it to the "state". From the implementation perspective, ev= en=20 though there are 10000000 entries in the table, the problem is just how = much=20 memory is needed.

Thanks,
Tetsuya Murakami 

On 2012/06/24, at 23:51, Qi Sun wrote:
Hi Satoru,
 
In MAP 1:1 mode, if there are 10000000 subscribers, there would b= e=20 10000000 MAP domains which a BR has to manage. I think that will creat= e a=20 huge mapping table on the BR, which is called 'state' that stateful=20 solutions deal with.
 
Best Regards!
 
Qi Sun
 
Date: 2012-06-25 10:27
CC: softwires@ietf.org; Yong Cui
Subject: Re: [Softwires] [Softwire]=20 draft-ietf-softwire-map-00 does NOT reflect the consensus from the=20 WG
Hi Yiu,
 
No, that's a misunderstanding.
Current MAP specify the case for ea= -len is 'zero'. It is 'per-subscriber mappin= g' in stateless manner, not to introduce&nbs= p;'per-flow NAT binding' or 'per-subscriber state=  on demand'.
 
cheers,
--satoru
 
On 2012/06/25, at 2:32, Lee, Yiu wr= ote:
 
> Dear Satoru and MAP-DT
> 
> I echo what Peng and Qiong&nbs= p;said. When the WG agreed working on t= he
> stateless solution, it was very&nbs= p;clear stated that the solution would not
> maintain states in the network.&nbs= p;If the 1:1 mode changed this, this no=
> longer matched the requirements sta= ted in the stateless motivation draft,
> thus, it would disqualify MAP = as a solution for the motivation draft.
> 
> AFAIK, the MAP Design Team cou= ld propose a change, but such a dramati= c
> change by introducing states in&nbs= p;the network would require WG approval. I
> would like the chairs to clari= fy this.
> 
> Thanks,
> Yiu
> 
> 
> On 6/24/12 12:21 PM, "Peng Wu"=  <pengwu.thu@gmail.com> = ;wrote:
> 
>> Hi Qiong, Satoru and all,
>> 
>> I should thank Qiong for p= ointing this out. I gotta say I'm a&nbs= p;bit shocked.
>> If I understand the procedures&= nbsp;of IETF correctly, a WG document should=
>> reflect the consensus of the&nb= sp;WG. MAP is approved by the WG as&nbs= p;a
>> stateless solution. As a partic= ipator in Softwire, I didn't get the
>> information anywhere that the M= AP WG document would cover the
>> so-called 1:1, in fact per-user=  stateful mode before it was released,
>> not to say discuss in the&= nbsp;WG. Don't the WG need to approve s= uch big
>> change anymore?
>> 
>> Now let me provide my impr= ession as an outsider of the MAP DT.&nb= sp;You
>> guys make great effort to = build the solution, The address composition,
>> the GMA algorithm, the differen= t types of address mapping rules.
>> should be quite difficult to&nb= sp;pull together such sophisticated ideas. I
>> guess that's what it takes = ;to achieve the benifits of statelessness.
>> And I admire that, bravo. = Then, all of a sudden, you guys are&nbs= p;saying,
>> let's apply this sophisticated = method to the different problem, by
>> dropping quite some comlexity a= nd twistting the mechanism a bit, seems
>> it may work. Considering the&nb= sp;problem are now solved in a more pur= e and
>> clear way, I'm sorry but I=  CANNOT follow the logic here.
>> 
>> On Sun, Jun 24, 2012 at&nb= sp;2:00 PM, Satoru Matsushima
>> <satoru.matsushima@gmail.co= m> wrote:
>>> Hi Qiong,
>>> 
>>> I'm disagree with your opin= ion.
>>> 
>>> 1. Recent changes in draft-= ietf-softwire-map-00 has been discussed in
>>> the DT.
>>> 2. MAP just covers so = called '1:1 mode' with most granular mapping=  rule
>>> for CEs provisioning, which = ;is as one of its characteristics.
>>> 3. The motivation draft doe= s not restrict that as you stated, just=
>>> 'assumed', it's neither 'MUST'&n= bsp;nor 'SHOULD'.
>>> 
>>> Best regards,
>>> --satoru
>>> 
>>> 
>>> On 2012/06/24, at 14:35, Qi= ong wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> As we all know, once&nb= sp;an individual draft is adopted as a = WG draft, it
>>>> is owned by the whole&n= bsp;WG, rather than just the editors. Just&n= bsp;as Remi
>>>> said, the normal procedure&n= bsp;to follow is to reach WG consensus = _before_
>>>> posting a newly edited = version.
>>>> 
>>>> From draft-mdt-softwire-mapping-addres= s-and-port-03 to
>>>> draft-ietf-softwire-map-00, there = ;are several changes between them. In
>>>> particular, the newly introd= uced "1:1 mode", which decouples IPv4 and
>>>> IPv6 addressing, has never&n= bsp;been discussed openly in the WG mailing<= /DIV>
>>>> list, or even in the&nb= sp;MAP design team either.
>>>> 
>>>> Actually, this "1:1 mode"&nb= sp;is against the stateless-4v6-motivation
>>>> draft. The motivation draft&= nbsp;has clearly defines the "Stateless 4/6
>>>> solution" as follows:
>>>> 
>>>> Stateless 4/6 solution denot= es a solution which does not require an= y
>>>> per-user state (see Section&= nbsp;2.3 of [RFC1958]) to be maintained by&n= bsp;any
>>>> IP address sharing function&= nbsp;in the Service Provider's network. This
>>>> category of solutions assume= s a dependency between an IPv6 prefix a= nd
>>>> IPv4 address.
>>>> 
>>>> AFAIK what the WG has&n= bsp;adopted MAP related draft is
>>>> draft-mdt-softwire-mapping-address-and-port= -03, NOT
>>>> draft-ietf-softwire-map-00. And t= he stateless solution should =C2=B3response
>>>> to the solution motivation&n= bsp;document=C2=B2 according to the Softwire char= ter.
>>>> That means draft-ietf-softwire-ma= p-00 IS NOT QUALIFIED to be a WG d= raft.
>>>> 
>>>> We can all recall that&= nbsp;our softwire WG has worked on stateless=
>>>> solutions for more than = ;one and a half years, and we have = ;achieved a
>>>> lot of work which has&n= bsp;been documented in charter, stateless motivat= ion,
>>>> 4rd-varients, MAP-03, etc. A= FAIK all the authors have kept the basi= c
>>>> "stateless" principle and th= e MAP design team is also working on&nb= sp;it
>>>> together to find a bett= er algorithm, address format, etc. So it&nbs= p;is
>>>> really not appropriate to&nb= sp;make such changes when MAP is adopted&nbs= p;as a WG
>>>> item in such a short&nb= sp;time.
>>>> 
>>>> From this perspective, draft= -ietf-softwire-map-00 can only be regarded
>>>> as draft-XX-softwire-mapping-address-a= nd-port-04. It is not even the
>>>> output of MAP design te= am.
>>>> 
>>>> Best wishes
>>>> 
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=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 Resear= ch Institude
>>>> 
>>>> 
>>>> Open source code:
>>>> lightweight 4over6: http://sourceforge.net= /projects/laft6/
>>>> PCP-natcoord: http://source= forge.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
>>> 
>>> _______________________________________________=
>>> Softwires mailing list
>>> Softwires@ietf.org
>>> https://www.i= etf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.i= etf.org/mailman/listinfo/softwires
 
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires
________________________= _______________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

=

------=_001_NextPart643405138514_=------ From jiangdong345@gmail.com Mon Jun 25 06:16: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 A21A121F85E7 for ; Mon, 25 Jun 2012 06:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJji9MUAakMk for ; Mon, 25 Jun 2012 06:16:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 922BE21F85D9 for ; Mon, 25 Jun 2012 06:16:04 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6627513pbc.31 for ; Mon, 25 Jun 2012 06:16:04 -0700 (PDT) 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=y8qN5hPs7KvvOImbA7juCdf1zkO5ZJh+jWre1nxBTkY=; b=A7rpyAwHrKfFkEIxTPR49mbvfR7sN3F87fDTlI2eDitfPkgVH+DLAKyWFqquZQv6AI FJl77UgyfxYfIoKue35BIRyp+NFXc/bJxYmFyF6EoL8kRgtxSg6L5UGUnAzPeQjxNC4h PC04ZaFMczQa/winJOwPnx6GnKvYgsS+oVpdamd1MSTXCQt6l0wIp6NUYvP7RIEsGVd5 yc/JFcATh56jSeXdlJovlLv1wdp9nzk7v5pmfv2gH9NbnKl7mIPg+b2djMxd+G5bz/0l jfuKW95do/Addxck+E5eTfBIFb73gnjdH6ZiOj50YDegCxGJwArXfV3Ww688ghFxFM4j kcVg== Received: by 10.68.201.9 with SMTP id jw9mr40645196pbc.28.1340630163982; Mon, 25 Jun 2012 06:16:03 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id vp4sm8504067pbc.61.2012.06.25.06.15.59 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 06:16:03 -0700 (PDT) Date: Mon, 25 Jun 2012 21:15:59 +0800 From: "Jiang Dong" To: "Satoru Matsushima" , "Peng Wu" References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <97A4D74A-A531-4F83-B281-86973A3139A5@gmail.com> <570C97A3-D641-47EB-B0EB-B75ECD7E9EC4@gmail.com> , <5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com> X-Priority: 3 X-GUID: E6BC1CEB-94E9-4A63-9C37-278FC0046253 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012062521155424456033@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart547800512353_=----" Cc: Softwires WG , Cui Yong Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 13:16:08 -0000 This is a multi-part message in MIME format. ------=_001_NextPart547800512353_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFNhdG9ydSwNCg0Kc2VlIGluIGxpbmVzLg0KDQpSZWdhcmRzIQ0KSmlhbmcgRG9uZw0KDQpG cm9tOiBTYXRvcnUgTWF0c3VzaGltYQ0KRGF0ZTogMjAxMi0wNi0yNSAxNzo0Ng0KVG86IFBlbmcg V3UNCkNDOiBzb2Z0d2lyZXM7IFlvbmcgQ3VpDQpTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gW1Nv ZnR3aXJlXSBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBkb2VzIE5PVCByZWZsZWN0IHRoZSBj b25zZW5zdXMgZnJvbSB0aGUgV0cNCkhpIFBlbmcsDQoNCk9uIDIwMTIvMDYvMjUsIGF0IDE4OjM0 LCBQZW5nIFd1IHdyb3RlOg0KDQo+PiBMZXQncyB0aGluayB0aGF0IGEgQ0UgcHJvdmlzaW9uZWQg d2l0aCBmb2xsb3dpbmcgQk1SIGNvbWVzIGZyb20gTUFQIERIQ1B2NiBvcHRpb25zLg0KPj4gDQo+ PiBCTVI6DQo+PiAgbyBSdWxlLWlwdjYtcHJlZml4ICA6IHtleGFjdCBtYXRjaGVkIHdpdGggQ0Un cyBkZWxlZ2F0ZWQgcHJlZml4fQ0KPj4gIG8gUnVsZS1pcHY0LXByZWZpeCAgOiB4LngueC54LzMy DQo+PiAgbyBFQS1sZW5ndGggICAgICAgICA6IDANCj4+ICBvIFBvcnQtcGFyYW0gb3B0aW9uIDog e1BTSUQvbGVuZ3RofQ0KPj4gDQo+PiBUaGlzIEJNUiBjb3VsZCBiZSBhIExXNDYgcHJvdmlzaW9u aW5nIG1lYW5zLg0KPiANCj4gQWdhaW4sIGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIGlzIHRo ZSBJUHY0IGFkZHJlc3MgYW5kIHBvcnQgc2V0Lg0KPiANCj4gMSkgVGhlIGl0ZW0gbGlrZSBydWxl LWlwdjYtcHJlZml4IGlzIG5vdCBuZWVkZWQgYXQgYWxsLg0KPiAyKSBQb3J0IHNldCBvciBQU0lE IHN0aWxsIG5lZWRzIGV4dHJhIHByb3Zpc2lvbmluZyAod2hpbGUgaW4gcmVndWxhcg0KPiBNQVAg aXQncyBlbWJlZGRlZCBpbiBJUHY2IGFkZHJlc3MpDQo+IA0KPiBTbyB3aHkgbWFrZSBpdCBzbyBk aWZmaWN1bHQgYW5kIG9ic2N1cmUNCg0KTm90IGRpZmZpY3VsdCwgZWFzeSBidXNpbmVzcyBmb3Ig Q0Ugd2hpY2ggaW1wbGVtZW50ZWQgTUFQLiBPdGhlciBkaWZmaWN1bHR5IGluIG9wZXJhdG9yIHNp ZGUgaW4gcGFydGljdWxhciBwcm92aXNpb25pbmcgY29tcGxleCwgdGhhdCBzaG91bGQgYmUgc2Ft ZSB3aXRoIExXNDYuIEl0IGFsc28gbWFrZXMgdG8gY29tcGxldGUgTUFQIHNwZWMgaW4gdGhlIGVh LWxlbiB6ZXJvIGNhc2UuDQoNCltESl0gSW4gdGhpcyBjYXNlLCBmb3IgdGhlIE1BUCBkcmFmdCwg ZWFjaCBDRSBvbmx5IG5lZWQgdG8ga25vdyB0aGUgSVB2NiBhZGRyZXNzIG9mIEJSLCBhbmQgQlIg bmVlZHMgbWFwcGluZyBydWxlcyBmb3IgZXZlcnkgQ0U7IGZvciB0aGUgbGlnaHR3ZWlnaHQ0b3Zl cjYsIHdoaWNoIGhhcyBiZWVuIHBlcnNpc3RlbnRseSBkZXZlbG9wZWQgZm9yIGFib3V0IHR3byB5 ZWFycyBieSBhIGxhcmdlIG51bWJlciBvZiBleHBlcnRzLCBlYWNoIFRJIGFsc28gbmVlZCB0byBr bm93IHRoZSBJUHY2IGFkZHJlc3Mgb2YgVEMsIGFuZCBUQyBuZWVkcyB0byBtYWludGFpbiB0aGUg cGVyLXN1YnNjcmliZXIgbWFwcGluZyBmb3IgZWFjaCBUSS4gSSByZWFsbHkgY2Fubm90IGZpbmQg d2hhdCdzIHRoZSBkaWZmZXJlbmNlLiBDb3VsZCB5b3UgcGxlYXNlIHRlbGwgbWUgaG93ICJzdGF0 ZWxlc3MiIGNvbWVzIGluIHRoZSAxOjEgbW9kZSBvZiBNQVAgZHJhZnQ/IEFuZCBpZiB0aGUgbnVt YmVyIG9mIG1hcHBpbmcgcnVsZXMgaXMgcHJvcG9ydGlvbmFsIHRvIHRoZSBudW1iZXIgb2Ygc3Vi c2NyaWJlcnMsIEkgd2lsbCB0aGVuIGNvbmZ1c2VkIGJ5IHRoZSBtZWFuaW5nIG9mIHN0YXRlbGVz cy4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0 d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVz ------=_001_NextPart547800512353_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,=20 Satoru,
 
see in lines.
 
Regards!
Jiang Dong
 
Date: 2012-06-25 17:46
To: Peng Wu
CC: softwires; = Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
Hi Peng,
 
On 2012/06/25, at 18:34, Peng Wu wrote:=
 
>> Let's think that a CE provisio= ned with following BMR comes from MAP D= HCPv6 options.
>> 
>> BMR:
>>  o Rule-ipv6-prefix  : {exact&= nbsp;matched with CE's delegated prefix}
>>  o Rule-ipv4-prefix  : x.x.x.x= /32
>>  o EA-length     &nb= sp;   : 0
>>  o Port-param option : {PSID/l= ength}
>> 
>> This BMR could be a LW46 = provisioning means.
> 
> Again, all the information needed = is the IPv4 address and port set.
> 
> 1) The item like rule-ipv6-prefix = is not needed at all.
> 2) Port set or PSID still nee= ds extra provisioning (while in regular
> MAP it's embedded in IPv6 address)=
> 
> So why make it so difficult a= nd obscure
 
Not difficult, easy business for CE whi= ch implemented MAP. Other difficulty in oper= ator side in particular provisioning complex,&nbs= p;that should be same with LW46. It als= o makes to complete MAP spec in the&nbs= p;ea-len zero case.
 
[DJ] In this case, for the MAP draft, each CE only need to know = the=20 IPv6 address of BR, and BR needs mapping rules for every CE; for the=20 lightweight4over6, which has been persistently developed for about two yea= rs by=20 a large number of experts, each TI also need to know the IPv6 address= of TC, and TC needs to maintain the per-subscriber mapping for each TI. I rea= lly=20 cannot find what's the difference. Could you please tell me how "stateless= "=20 comes in the 1:1 mode of MAP draft? And if the number of mapping rules is proportional = to the=20 number of subscribers, I will then confused by the meaning of=20 stateless.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart547800512353_=------ From sunqi.csnet.thu@gmail.com Mon Jun 25 06:31:10 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 85E3F21F8630 for ; Mon, 25 Jun 2012 06:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5t4QquHrMS1 for ; Mon, 25 Jun 2012 06:31:06 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6FA21F8631 for ; Mon, 25 Jun 2012 06:31:06 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6645422pbc.31 for ; Mon, 25 Jun 2012 06:31:06 -0700 (PDT) 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-mailer:mime-version:message-id:content-type; bh=PlI0WgdCqAHEcrELIAz4zuxoN+5r+gHpp9LkG3ZGm/Y=; b=MKgZ87Yljy4WuSddtcg6PTemAUq4G9I1SymaKuF7CoSJ82DQ8ORBnK3aV6+Hii9EVI NrF1DdEZmbn1bjK+9kcSJt/07WXenkxwYj3jDP8+pNtB+u4iEee345KIXBDlAPh/FEoZ LmMTFw3hkgmV/Gm7rvicebDTc3nizd3DRs3Lz7XiCIMid7wbeb44vUNPP4EHVGGtr6xK 9Jt7yVqo3l3v8Kcm8Gm/RWg5mRFLCiGoJZrQuUgCdIOGKJnFgO44aydFQXZGkb7A8wfy ZzIjKgbp6uVFGOLN7s2uKZNEdTYPgJViMdrHs8btfQKChiLPjC555nYyJcVlu9eD6Ffu V7Ew== Received: by 10.68.194.105 with SMTP id hv9mr32128168pbc.126.1340631066258; Mon, 25 Jun 2012 06:31:06 -0700 (PDT) Received: from sunqi ([166.111.68.233]) by mx.google.com with ESMTPS id rv9sm8546514pbc.43.2012.06.25.06.31.01 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 06:31:05 -0700 (PDT) Date: Mon, 25 Jun 2012 21:30:55 +0800 From: "Qi Sun" To: "Satoru Matsushima" References: , <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> X-Priority: 3 X-GUID: BDBB12C2-8442-4F04-AD90-5CCAB36BBD0D X-Mailer: Foxmail 7.0.1.83[cn] Mime-Version: 1.0 Message-ID: <2012062521305550504855@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart521261603713_=----" Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "sunqi.csnet.thu" List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 13:31:10 -0000 This is a multi-part message in MIME format. ------=_001_NextPart521261603713_=---- Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 SGkgU2F0b3J1LCANCg0KQXMgeW91IHNhaWQsIHRoZSBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0w MCAoYWN0dWFsbHkgdGhlIGRyYWZ0LVhYLXNvZnR3aXJlLW1hcHBpbmctYWRkcmVzcy1hbmQtcG9y dC0wNCkgaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBEVC4gQW55IGNvbnNlbnN1cyBoYXMgYmVl biBhY2hpZXZlZCBhbW9uZyB3aXRoaW4gdGhlIERUPyBBbmQgaGFzIHRoZSBzb2Z0d2lyZSB3b3Jr aW5nIGdyb3VwIGFkb3B0ZWQgYWxsIHRoZSBjaGFuZ2VzIHlvdSBoYXZlIHB1dCBpbiB0aGUgIm5l dyIgTUFQIGRyYWZ0Pw0KDQpUaGFuayB5b3UhDQoNCg0KDQoNClFpIFN1bg0KDQpGcm9tOiBTYXRv cnUgTWF0c3VzaGltYQ0KRGF0ZTogMjAxMi0wNi0yNCAxNDowMA0KVG86IFFpb25nDQpDQzogc29m dHdpcmVzOyBZb25nIEN1aQ0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIFtTb2Z0d2lyZV0gZHJh ZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgZG9lcyBOT1QgcmVmbGVjdCB0aGUgY29uc2Vuc3VzIGZy b20gdGhlIFdHDQpIaSBRaW9uZywNCg0KSSdtIGRpc2FncmVlIHdpdGggeW91ciBvcGluaW9uLg0K DQoxLiBSZWNlbnQgY2hhbmdlcyBpbiBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBoYXMgYmVl biBkaXNjdXNzZWQgaW4gdGhlIERULg0KMi4gTUFQIGp1c3QgY292ZXJzIHNvIGNhbGxlZCAnMTox IG1vZGUnIHdpdGggbW9zdCBncmFudWxhciBtYXBwaW5nIHJ1bGUgZm9yIENFcyBwcm92aXNpb25p bmcsIHdoaWNoIGlzIGFzIG9uZSBvZiBpdHMgY2hhcmFjdGVyaXN0aWNzLg0KMy4gVGhlIG1vdGl2 YXRpb24gZHJhZnQgZG9lcyBub3QgcmVzdHJpY3QgdGhhdCBhcyB5b3Ugc3RhdGVkLCBqdXN0ICdh c3N1bWVkJywgaXQncyBuZWl0aGVyICdNVVNUJyBub3IgJ1NIT1VMRCcuDQoNCkJlc3QgcmVnYXJk cywNCi0tc2F0b3J1DQoNCg0KT24gMjAxMi8wNi8yNCwgYXQgMTQ6MzUsIFFpb25nIHdyb3RlOg0K DQo+IEhpIGFsbCwNCj4gIA0KPiBBcyB3ZSBhbGwga25vdywgb25jZSBhbiBpbmRpdmlkdWFsIGRy YWZ0IGlzIGFkb3B0ZWQgYXMgYSBXRyBkcmFmdCwgaXQgaXMgb3duZWQgYnkgdGhlIHdob2xlIFdH LCByYXRoZXIgdGhhbiBqdXN0IHRoZSBlZGl0b3JzLiBKdXN0IGFzIFJlbWkgc2FpZCwgdGhlIG5v cm1hbCBwcm9jZWR1cmUgdG8gZm9sbG93IGlzIHRvIHJlYWNoIFdHIGNvbnNlbnN1cyBfYmVmb3Jl XyBwb3N0aW5nIGEgbmV3bHkgZWRpdGVkIHZlcnNpb24uIA0KPiAgDQo+IEZyb20gZHJhZnQtbWR0 LXNvZnR3aXJlLW1hcHBpbmctYWRkcmVzcy1hbmQtcG9ydC0wMyB0byBkcmFmdC1pZXRmLXNvZnR3 aXJlLW1hcC0wMCwgdGhlcmUgYXJlIHNldmVyYWwgY2hhbmdlcyBiZXR3ZWVuIHRoZW0uIEluIHBh cnRpY3VsYXIsIHRoZSBuZXdseSBpbnRyb2R1Y2VkICIxOjEgbW9kZSIsIHdoaWNoIGRlY291cGxl cyBJUHY0IGFuZCBJUHY2IGFkZHJlc3NpbmcsIGhhcyBuZXZlciBiZWVuIGRpc2N1c3NlZCBvcGVu bHkgaW4gdGhlIFdHIG1haWxpbmcgbGlzdCwgb3IgZXZlbiBpbiB0aGUgTUFQIGRlc2lnbiB0ZWFt IGVpdGhlci4NCj4gIA0KPiBBY3R1YWxseSwgdGhpcyAiMToxIG1vZGUiIGlzIGFnYWluc3QgdGhl IHN0YXRlbGVzcy00djYtbW90aXZhdGlvbiBkcmFmdC4gVGhlIG1vdGl2YXRpb24gZHJhZnQgaGFz IGNsZWFybHkgZGVmaW5lcyB0aGUgIlN0YXRlbGVzcyA0LzYgc29sdXRpb24iIGFzIGZvbGxvd3M6 DQo+IA0KPiBTdGF0ZWxlc3MgNC82IHNvbHV0aW9uIGRlbm90ZXMgYSBzb2x1dGlvbiB3aGljaCBk b2VzIG5vdCByZXF1aXJlIGFueSBwZXItdXNlciBzdGF0ZSAoc2VlIFNlY3Rpb24gMi4zIG9mIFtS RkMxOTU4XSkgdG8gYmUgbWFpbnRhaW5lZCBieSBhbnkgSVAgYWRkcmVzcyBzaGFyaW5nIGZ1bmN0 aW9uIGluIHRoZSBTZXJ2aWNlIFByb3ZpZGVyJ3MgbmV0d29yay4gVGhpcyBjYXRlZ29yeSBvZiBz b2x1dGlvbnMgYXNzdW1lcyBhIGRlcGVuZGVuY3kgYmV0d2VlbiBhbiBJUHY2IHByZWZpeCBhbmQg SVB2NCBhZGRyZXNzLg0KPiAgDQo+IEFGQUlLIHdoYXQgdGhlIFdHIGhhcyBhZG9wdGVkIE1BUCBy ZWxhdGVkIGRyYWZ0IGlzIGRyYWZ0LW1kdC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBv cnQtMDMsIE5PVCBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMC4gQW5kIHRoZSBzdGF0ZWxlc3Mg c29sdXRpb24gc2hvdWxkIBskQiFIGyhCcmVzcG9uc2UgdG8gdGhlIHNvbHV0aW9uIG1vdGl2YXRp b24gZG9jdW1lbnQbJEIhSRsoQiBhY2NvcmRpbmcgdG8gdGhlIFNvZnR3aXJlIGNoYXJ0ZXIuIFRo YXQgbWVhbnMgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgSVMgTk9UIFFVQUxJRklFRCB0byBi ZSBhIFdHIGRyYWZ0LiANCj4gIA0KPiBXZSBjYW4gYWxsIHJlY2FsbCB0aGF0IG91ciBzb2Z0d2ly ZSBXRyBoYXMgd29ya2VkIG9uIHN0YXRlbGVzcyBzb2x1dGlvbnMgZm9yIG1vcmUgdGhhbiBvbmUg YW5kIGEgaGFsZiB5ZWFycywgYW5kIHdlIGhhdmUgYWNoaWV2ZWQgYSBsb3Qgb2Ygd29yayB3aGlj aCBoYXMgYmVlbiBkb2N1bWVudGVkIGluIGNoYXJ0ZXIsIHN0YXRlbGVzcyBtb3RpdmF0aW9uLCA0 cmQtdmFyaWVudHMsIE1BUC0wMywgZXRjLiBBRkFJSyBhbGwgdGhlIGF1dGhvcnMgaGF2ZSBrZXB0 IHRoZSBiYXNpYyAic3RhdGVsZXNzIiBwcmluY2lwbGUgYW5kIHRoZSBNQVAgZGVzaWduIHRlYW0g aXMgYWxzbyB3b3JraW5nIG9uIGl0IHRvZ2V0aGVyIHRvIGZpbmQgYSBiZXR0ZXIgYWxnb3JpdGht LCBhZGRyZXNzIGZvcm1hdCwgZXRjLiBTbyBpdCBpcyByZWFsbHkgbm90IGFwcHJvcHJpYXRlIHRv IG1ha2Ugc3VjaCBjaGFuZ2VzIHdoZW4gTUFQIGlzIGFkb3B0ZWQgYXMgYSBXRyBpdGVtIGluIHN1 Y2ggYSBzaG9ydCB0aW1lLiANCj4gIA0KPiBGcm9tIHRoaXMgcGVyc3BlY3RpdmUsIGRyYWZ0LWll dGYtc29mdHdpcmUtbWFwLTAwIGNhbiBvbmx5IGJlIHJlZ2FyZGVkIGFzIGRyYWZ0LVhYLXNvZnR3 aXJlLW1hcHBpbmctYWRkcmVzcy1hbmQtcG9ydC0wNC4gSXQgaXMgbm90IGV2ZW4gdGhlIG91dHB1 dCBvZiBNQVAgZGVzaWduIHRlYW0uDQo+IA0KPiBCZXN0IHdpc2hlcw0KPiANCj4gPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBRaW9uZyBTdW4NCj4gQ2hp bmEgVGVsZWNvbSBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHVkZQ0KPiANCj4gDQo+IE9wZW4gc291 cmNlIGNvZGU6DQo+IGxpZ2h0d2VpZ2h0IDRvdmVyNjogaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9w cm9qZWN0cy9sYWZ0Ni8NCj4gUENQLW5hdGNvb3JkOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3By b2plY3RzL3BjcHBvcnRzZXRkZW1vLyANCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+IFNvZnR3aXJl c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3 aXJlcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K U29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw== ------=_001_NextPart521261603713_=---- Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi Satoru,
 
As you said, the draft-ietf-softwire-map-00 (actually the=20 draft-XX-softwire-mapping-address-and-port-04) has been discussed in the D= T. Any=20 consensus has been achieved among within the DT? And has the softwire work= ing=20 group adopted all the changes you have put in the "new" MAP draft?
 
Thank you!
 
Qi Sun
 
Date: 2012-06-24 14:00
To: Qiong
CC: softwires; = Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
Hi Qiong,
 
I'm disagree with your opinion.
 
1. Recent changes in draft-ietf-softwire-map-00&n= bsp;has been discussed in the DT.
2. MAP just covers so called '1:1 = mode' with most granular mapping rule for&nb= sp;CEs provisioning, which is as one of = ;its characteristics.
3. The motivation draft does not restri= ct that as you stated, just 'assumed', = it's neither 'MUST' nor 'SHOULD'.
 
Best regards,
--satoru
 
 
On 2012/06/24, at 14:35, Qiong wrote:
 
> Hi all,
>  
> As we all know, once an indiv= idual draft is adopted as a WG draft,&n= bsp;it is owned by the whole WG, rather=  than just the editors. Just as Remi&nb= sp;said, the normal procedure to follow is&n= bsp;to reach WG consensus _before_ posting a=  newly edited version. 
>  
> From draft-mdt-softwire-mapping-address-and-port-03&nb= sp;to draft-ietf-softwire-map-00, there are several&nb= sp;changes between them. In particular, the = newly introduced "1:1 mode", which decouples = ;IPv4 and IPv6 addressing, has never been&nb= sp;discussed openly in the WG mailing list,&= nbsp;or even in the MAP design team eit= her.
>  
> Actually, this "1:1 mode" is again= st the stateless-4v6-motivation draft. The motiva= tion draft has clearly defines the "Stateles= s 4/6 solution" as follows:
> 
> Stateless 4/6 solution denotes a s= olution which does not require any per-user&= nbsp;state (see Section 2.3 of [RFC1958]) to=  be maintained by any IP address sharin= g function in the Service Provider's network= . This category of solutions assumes a = dependency between an IPv6 prefix and IPv4&n= bsp;address.
>  
> AFAIK what the WG has adopted = ;MAP related draft is draft-mdt-softwire-mapping-addre= ss-and-port-03, NOT draft-ietf-softwire-map-00. And th= e stateless solution should =1B$B!H=1B(Bresponse = to the solution motivation document=1B$B!I=1B(B a= ccording to the Softwire charter. That means=  draft-ietf-softwire-map-00 IS NOT QUALIFIED to&n= bsp;be a WG draft. 
>  
> We can all recall that our so= ftwire WG has worked on stateless solutions&= nbsp;for more than one and a half years= , and we have achieved a lot of wo= rk which has been documented in charter,&nbs= p;stateless motivation, 4rd-varients, MAP-03, etc.&nbs= p;AFAIK all the authors have kept the b= asic "stateless" principle and the MAP desig= n team is also working on it together&n= bsp;to find a better algorithm, address form= at, etc. So it is really not appropriat= e to make such changes when MAP is = ;adopted as a WG item in such a sh= ort time. 
>  
> From this perspective, draft-ietf-softwire-m= ap-00 can only be regarded as draft-XX-softw= ire-mapping-address-and-port-04. It is not even t= he output of MAP design team.
> 
> Best wishes
> 
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=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 Institud= e
> 
> 
> Open source code:
> lightweight 4over6: http://sourceforge.net/projec= ts/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpports= etdemo/ 
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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
------=_001_NextPart521261603713_=------ From jmh@joelhalpern.com Mon Jun 25 06:39: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 CEABF21F864F for ; Mon, 25 Jun 2012 06:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.726 X-Spam-Level: X-Spam-Status: No, score=-101.726 tagged_above=-999 required=5 tests=[AWL=-0.753, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3uKouwG3SIw for ; Mon, 25 Jun 2012 06:39:57 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DA27721F8652 for ; Mon, 25 Jun 2012 06:39:56 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id D4C90558005 for ; Mon, 25 Jun 2012 06:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 40C011C07F5 for ; Mon, 25 Jun 2012 06:39:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.105] (pool-71-161-51-121.clppva.btas.verizon.net [71.161.51.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id AD5241C07DC for ; Mon, 25 Jun 2012 06:39:53 -0700 (PDT) Message-ID: <4FE86A26.2030000@joelhalpern.com> Date: Mon, 25 Jun 2012 09:39:50 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 CC: softwires WG References: , <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> In-Reply-To: <2012062514514640804415@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 13:39:57 -0000 This appears to mix different kinds of state. In particular, with regard to state in network resident boxes, there can be: General state covering all subscribers; Per subscriber state provisioned state; Per subscriber dynamic, but not flow specific state; per flow state. All are state. The first is clearly permitted. The fourth is clearly not permitted in a "stateless" solution. Some descriptions of "stateless" have allowed for the middle two, while others have prohibited it. I have no opinion on what the WG "agreement" is on the scoping. But we need to be careful about what we mean about "state". Yours, Joel On 6/25/2012 2:51 AM, Qi Sun wrote: > Hi Satoru, > In MAP 1:1 mode, if there are 10000000 subscribers, there would be > 10000000 MAP domains which a BR has to manage. I think that will create > a huge mapping table on the BR, which is called 'state' that stateful > solutions deal with. > Best Regards! > Qi Sun From bingxuere@gmail.com Mon Jun 25 07:06: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 19E6F11E8079 for ; Mon, 25 Jun 2012 07:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmJ2QJqtxrgK for ; Mon, 25 Jun 2012 07:06:23 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D064A11E807F for ; Mon, 25 Jun 2012 07:06:22 -0700 (PDT) Received: by yenq13 with SMTP id q13so3137840yen.31 for ; Mon, 25 Jun 2012 07:06:21 -0700 (PDT) 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=YJj6c3/Lx0E96BJiq6UZqHlxdP/d5yP8REjDxj2K48M=; b=HobMmn0xsZOLVJ2rBNOpbjjGZDqmY2kcbxwwKsElf+nEiAUyRLHTnjtLwNBOtbmylU tXSNSiGyHITZiEeWZCovTZNnjl8h5YMVjdQiqCCNHT8f/wzdDRiEYLTKNZizP18mvzef BB75QRwf/z9zz6FaVsNdxeAMfgiMsemPQ7BJFxKQu4wPzdkzeEJhfnXna/gC6EBHsOFd aACDzv3pJh30CrHLDwRaEFa2QkJ9JFhP9b5YXeIo9VoqxJvTDf83fmDrji4XkSEogAb0 BHFagmQfFsFaO9vHo5psfImZLC5bBeIPQwEukkpdsmmc7y04dGjHpSftaiEQW4GqVFcB Ndog== Received: by 10.50.188.131 with SMTP id ga3mr8209619igc.54.1340633181307; Mon, 25 Jun 2012 07:06:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Mon, 25 Jun 2012 07:05:41 -0700 (PDT) In-Reply-To: References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> From: Qiong Date: Mon, 25 Jun 2012 22:05:41 +0800 Message-ID: To: Wojciech Dec Content-Type: multipart/alternative; boundary=14dae93411578bc4f204c34c7c21 Cc: Softwires-wg , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 14:06:28 -0000 --14dae93411578bc4f204c34c7c21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Woj, I can not agree with your points. Here is my points: * Lightweight 4over6 is a collaborative work of 15 co-authors for more than one and a half years, including China Telecom, Tsinghua, Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, Freebits, etc., and also the vendors from Huawei, Juniper and Cisco. It has been presented in Beijing Interim meeting, Taipei meeting, and Pairs, and demoed in IETF 81th. * The motivation/senario which lw 4over6 actually solves has been discussed several times, and it has been approved as an valueable requirement in the WG. It belongs to per-subscriber stateful and per-session stateless solution space. * Our lw4over6 group are doing the actual work all the time around. We have improved our draft serveral times according to the WG decision, implemented the running code (we have also published it recently for the sake of the community), taken the field trial in China. All these tests have been proved to be a success. * Our VP has announced publicly on 2012 world IPv6 launch day that China Telecom, which has more than 70 million broandband access customers, will use lw4over6 as a major transition solution. As the first few operators who are truely facing such a great pressure IPv4 address shortage problem in the world, we really find lw4over6 is a very efficient way to solve our problem. It is clean, easy to manage and efficient, and we are doing seriously for the sake of the whole community. * Lightweight 4over6 itself is simple, easy to understand and consistent. The flexible addressing feature has brought us a lot of benifits including network management, development and future usage. It can solve both the dynamic mode of IPv4/IPv6 address mapping on-demand, and explicit pre-determined mapping. And it has also improved the scalability problem of traditional CGN to a great extend. * For operators who only need stateful solutions do not need to deploy a huge "heavy" solution to include both stateful and stateless features. It is not only useless, but will also enlarge the possibility of troubleshooting. Best wishes Qiong On Mon, Jun 25, 2012 at 8:31 PM, Wojciech Dec wrote: > Some points for the record: > > * lightweight 4over6 is not a WG draft nor does it have a monopoly on the > shape of final solutions. > > * Discussion on what lw 4over6 actually solves is still expected. > > * Nothing in the stateless solution (eg MAP) says that they have to be > used with stateful elements, or at what scale they are to be deployed. Th= e > fact MAP devices can be used with stateful elements is a basic fact > deriving from the use of common IPv6 data-planes. > > * Lw 4over6 is co-authored by one of the current and also one of the past > WG chairs... > > -Woj. > > > On 24 June 2012 17:13, Qiong wrote: > >> Hi Satoru, >> >> Every solution has its solution space with respective application >> scenarios as well as pros and cons. >> The essence of stateless solution, which follows the stateless motivatio= n >> approved by the WG, is to achieve efficient address mapping by algorithm= ic >> embedding part of IPv4 address+port set into IPv6 address/prefix, while = the >> essence of stateful solution is to maintain the subscriber-based state >> on-demand. IPv4 address and IPv6 address is not coupled, and there is no >> requirement on IPv6 addressing format. It is twisty to mix them together= in >> one document as in the current draft-ietf-softwire-map. It is not clear = for >> vendors to implement and for operators to deploy, and will lose the >> features for both. >> >> I'm not saying I'm against the work of stateless solutions, but it is >> really not fair to just extend one solution arbitrarily to cover another >> one without the permission from the WG and the authors. In particular, >> lightweight 4over6 is a collaborative work of 15 co-authors for more tha= n >> one and a half years, including operators from China Telecom, Tsinghua, >> Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and a= lso >> the vendors from Huawei, Juniper and Cisco. >> >> Our WG or DT has never reached the consensus to have one unified documen= t >> for both stateful and stateless sotluion. And the motivation draft has >> never been extended to include the stateful features as well. So unless = we >> reach the consensus first in the WG, we can then move forward with this >> document. >> >> Best wishes >> >> >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima < >> satoru.matsushima@gmail.com> wrote: >> >>> Hi Qiong, >>> >>> I'm disagree with your opinion. >>> >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in >>> the DT. >>> 2. MAP just covers so called '1:1 mode' with most granular mapping rule >>> for CEs provisioning, which is as one of its characteristics. >>> 3. The motivation draft does not restrict that as you stated, just >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. >>> >>> Best regards, >>> --satoru >>> >>> >>> On 2012/06/24, at 14:35, Qiong wrote: >>> >>> > Hi all, >>> > >>> > As we all know, once an individual draft is adopted as a WG draft, it >>> is owned by the whole WG, rather than just the editors. Just as Remi sa= id, >>> the normal procedure to follow is to reach WG consensus _before_ postin= g a >>> newly edited version. >>> > >>> > From draft-mdt-softwire-mapping-address-and-port-03 to >>> draft-ietf-softwire-map-00, there are several changes between them. In >>> particular, the newly introduced "1:1 mode", which decouples IPv4 and I= Pv6 >>> addressing, has never been discussed openly in the WG mailing list, or = even >>> in the MAP design team either. >>> > >>> > Actually, this "1:1 mode" is against the stateless-4v6-motivation >>> draft. The motivation draft has clearly defines the "Stateless 4/6 >>> solution" as follows: >>> > >>> > Stateless 4/6 solution denotes a solution which does not require any >>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by any I= P >>> address sharing function in the Service Provider's network. This catego= ry >>> of solutions assumes a dependency between an IPv6 prefix and IPv4 addre= ss. >>> > >>> > AFAIK what the WG has adopted MAP related draft is >>> draft-mdt-softwire-mapping-address-and-port-03, NOT >>> draft-ietf-softwire-map-00. And the stateless solution should =E2=80=9C= response to >>> the solution motivation document=E2=80=9D according to the Softwire cha= rter. That >>> means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. >>> > >>> > We can all recall that our softwire WG has worked on stateless >>> solutions for more than one and a half years, and we have achieved a lo= t of >>> work which has been documented in charter, stateless motivation, >>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic >>> "stateless" principle and the MAP design team is also working on it >>> together to find a better algorithm, address format, etc. So it is real= ly >>> not appropriate to make such changes when MAP is adopted as a WG item i= n >>> such a short time. >>> > >>> > From this perspective, draft-ietf-softwire-map-00 can only be regarde= d >>> as draft-XX-softwire-mapping-address-and-port-04. It is not even the ou= tput >>> of MAP design team. >>> > >>> > Best wishes >>> > >>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >>> >>> >> >> >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > > --=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 --14dae93411578bc4f204c34c7c21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Woj,

I can not agree with your points. Here is my points:

= * Lightweight 4over6 is a collaborative work of 15 co-authors for more than= one and a half years, including=C2=A0 China Telecom, Tsinghua, Comcast,=20 France telecom, Deutsche Telekom, Bouygues Telecom, Freebits, etc., and=20 also the vendors from Huawei, Juniper and Cisco.=C2=A0 It has been presente= d in Beijing Interim meeting, Taipei meeting, and Pairs, and demoed in IETF= 81th.

* The motivation/senario which lw 4over6 actually solves has= been discussed several times, and it has been approved as an valueable req= uirement in the WG. It belongs to per-subscriber stateful and per-session s= tateless solution space.

* Our lw4over6 group are doing the actual work all the time around. We = have improved our draft serveral times according to the WG decision, implem= ented the running code (we have also published it recently for the sake of = the community), taken the field trial in China. All these tests have been p= roved to be a success.

* Our VP has announced publicly on 2012 world IPv6 launch day that Chin= a Telecom, which=20 has more than 70 million broandband access customers, will use lw4over6=20 as a major transition solution. As the first few operators who are truely f= acing such a great pressure IPv4 address shortage problem in the world, we = really find lw4over6 is a very efficient way to solve our problem. It is cl= ean, easy to manage and efficient, and we are doing seriously for the sake = of the whole community.

* Lightweight 4over6 itself is simple, easy to understand and consisten= t. The flexible addressing feature has brought us a lot of benifits includi= ng network management, development and future usage. It can solve both the = dynamic mode of IPv4/IPv6 address mapping on-demand, and explicit pre-deter= mined mapping. And it has also improved the scalability problem of traditio= nal CGN to a great extend.

* For operators who only need stateful solutions do not need to deploy = a huge "heavy" solution to include both stateful and stateless fe= atures. It is not only useless, but will also enlarge the possibility of tr= oubleshooting.

Best wishes
Qiong
=C2=A0

On Mo= n, Jun 25, 2012 at 8:31 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
Some points for the record:

* lightw= eight 4over6 is not a WG draft nor does it have a monopoly on the shape of = final solutions.

* Discussion on what lw 4over6 actually solves is still expected.
* Nothing in the stateless solution (eg MAP) says that they have to be us= ed with stateful elements, or at what scale they are to be deployed. The fa= ct MAP devices can be used with stateful elements is a basic fact deriving = from the use of common IPv6 data-planes.

* Lw 4over6 is co-authored by one of the current and also one of the pa= st WG chairs...

-Woj.

On 24 June 2012 17:13, Qiong = <bingxuere@gmai= l.com> wrote:
Hi Satoru,

Every solution has its sol= ution space with respective application scenarios as well as pros and cons.=
The essence of stateless solution, which follows the stateless motivation a= pproved by the WG, is to achieve efficient address mapping by algorithmic e= mbedding part of IPv4 address+port set into IPv6 address/prefix, while the = essence of stateful solution is to maintain the subscriber-based state on-d= emand. IPv4 address and IPv6 address is not coupled, and there is no requir= ement on IPv6 addressing format. It is twisty to mix them together in one d= ocument as in the current draft-ietf-softwire-map. It is not clear for vend= ors to implement and for operators to deploy, and will lose the features fo= r both.

I'm not saying I'm against the work of stateless solutions, but= it is really not fair to just extend one solution arbitrarily to cover ano= ther one without the permission from the WG and the authors. In particular,= =C2=A0 lightweight 4over6 is a collaborative work of 15 co-authors for mor= e than one and a half years, including operators from China Telecom, Tsingh= ua, Comcast,=20 France telecom, Deutsche Telekom, Bouygues Telecom, etc., and=20 also the vendors from Huawei, Juniper and Cisco.

Our WG or DT has ne= ver reached the consensus to have one unified document for both stateful an= d stateless sotluion. And the motivation draft has never been extended to i= nclude the stateful features as well. So unless we reach the consensus firs= t in the WG, we can then move forward with this document.

Best wishes


On Sun, Jun 24,= 2012 at 2:00 PM, Satoru Matsushima <satoru.matsushima@gmail.com= > wrote:
Hi Qiong,

I'm disagree with your opinion.

1. Recent changes in draft-ietf-softwire-map-00 has been discussed in the D= T.
2. MAP just covers so called '1:1 mode' with most granular mapping = rule for CEs provisioning, which is as one of its characteristics.
3. The motivation draft does not restrict that as you stated, just 'ass= umed', it's neither 'MUST' nor 'SHOULD'.

Best regards,
--satoru


On 2012/06/24, at 14:35, Qiong wrote:

> Hi all,
>
> As we all know, once an individual draft is adopted as a WG draft, it = is owned by the whole WG, rather than just the editors. Just as Remi said, = the normal procedure to follow is to reach WG consensus _before_ posting a = newly edited version.
>
> From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf-soft= wire-map-00, there are several changes between them. In particular, the new= ly introduced "1:1 mode", which decouples IPv4 and IPv6 addressin= g, has never been discussed openly in the WG mailing list, or even in the M= AP design team either.
>
> Actually, this "1:1 mode" is against the stateless-4v6-motiv= ation draft. The motivation draft has clearly defines the "Stateless 4= /6 solution" as follows:
>
> Stateless 4/6 solution denotes a solution which does not require any p= er-user state (see Section 2.3 of [RFC1958]) to be maintained by any IP add= ress sharing function in the Service Provider's network. This category = of solutions assumes a dependency between an IPv6 prefix and IPv4 address.<= br> >
> AFAIK what the WG has adopted MAP related draft is draft-mdt-softwire-= mapping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the statel= ess solution should =E2=80=9Cresponse to the solution motivation document= =E2=80=9D according to the Softwire charter. That means draft-ietf-softwire= -map-00 IS NOT QUALIFIED to be a WG draft.
>
> We can all recall that our softwire WG has worked on stateless solutio= ns for more than one and a half years, and we have achieved a lot of work w= hich has been documented in charter, stateless motivation, 4rd-varients, MA= P-03, etc. AFAIK all the authors have kept the basic "stateless" = principle and the MAP design team is also working on it together to find a = better algorithm, address format, etc. So it is really not appropriate to m= ake such changes when MAP is adopted as a WG item in such a short time.
>
> From this perspective, draft-ietf-softwire-map-00 can only be regarded= as draft-XX-softwire-mapping-address-and-port-04. It is not even the outpu= t of MAP design team.
>
> Best wishes
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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




--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Su= n
China Telecom Beijing Research Institude


Open source code:<= br> 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<= /a>
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

--14dae93411578bc4f204c34c7c21-- From wdec.ietf@gmail.com Mon Jun 25 07:24: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 19BB411E8072 for ; Mon, 25 Jun 2012 07:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruZFiOr5EUP5 for ; Mon, 25 Jun 2012 07:24:46 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBF2B11E8080 for ; Mon, 25 Jun 2012 07:24:45 -0700 (PDT) Received: by qadz3 with SMTP id z3so1399403qad.10 for ; Mon, 25 Jun 2012 07:24:45 -0700 (PDT) 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=nKPrbMqDsrLCKr37yk8SHhLN0IcInx0khbTRTn98dtA=; b=prpv2Pgy4UxhbGFEJcuC2yTamrJlKUd8zF4qNlD37XJ6j/GJTWimiQ/mLRMpiY1oo6 K6HN9UBMnvAtoxjpsbEsdmgtgpEBhGb31p0QaQ8ztavdi2ug9JFLvEuultU54zHAreIB rVP9E2fXCO6U5+fTZv4fx29LJejzvg5d57CLbSxxgZEFSFeb8py1Iu7e5qgbBTvh5QKJ 1A2ZZWW06zAiLwHCd5Fa8TBCPkYrXc4IhrvjkjkDyNnyuBIx2svwEVzOCjKjRATx38Bh CyW9rkPjJ+fC2VSyVjTZZSDv1WgORpqP8P4jQHRtWB0rzNWpb7yVj3X0CpqOdqxwwLKE 1vBg== MIME-Version: 1.0 Received: by 10.229.137.84 with SMTP id v20mr5511789qct.128.1340634285077; Mon, 25 Jun 2012 07:24:45 -0700 (PDT) Received: by 10.229.246.6 with HTTP; Mon, 25 Jun 2012 07:24:44 -0700 (PDT) In-Reply-To: <2012062514514640804415@gmail.com> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> Date: Mon, 25 Jun 2012 16:24:44 +0200 Message-ID: From: Wojciech Dec To: "sunqi.csnet.thu" , softwires WG Content-Type: multipart/alternative; boundary=00235452f5c855f65004c34cbe50 Cc: Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 14:24:51 -0000 --00235452f5c855f65004c34cbe50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, taking a step back to discuss some items in more detail, and hopefully move this discussion forward: 1. Domain size The MAP architecture does not prescribe the size of a domain, and neither does it prescribe the number of rules to be used. There is nothing in the technology, except vendor implementation limits or practical sense (or both), to prevent MAP domains from defining 1 domain =3D 1 CPE. This was a day 1 characteristic of MAP drafts. Choosing to deploy or implement MAP with a configuration supporting 1 rule, 100 rules or 100k rules or domains is a vendor's and/or operator's choice. Nobody is stating that deployment is to be limited to X rules, nor that a near infinite number of rules is reasonable. These are general points that apply to DS-lite state as well as the "Light Weight 4 over 6" or "stateless deterministic NAT", and pretty much any technology for that matter. 2. Stateless DOES NOT mean configuration-less There appears to be confusion between the concept of stateless and configuration-less. MAP domains are based on configured rules, that are provisioned/applied through means that are currently outside the scope of Softwire drafts - this is configuration state, and this was and continues to be a characteristic of MAP. Further more, unlike some of the other proposals, MAP allows to optimize the amount of configuration needed in cases where this is viable. In other words, MAP does NOT exclusively force 1:1 rule configuration, but also allows N:1. 3. Stateless has no data plane induced state A major difference between stateless (eg MAP) and stateful (eg Carrier Grade NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic core node forwarding state that is directly driven by user data-plane traffic (eg new IP flows). MAP does not rely on such dynamic state, never did. 4. No change of MAP spec The updated MAP draft does not change the MAP architecture nor its technical underpinnings. In fact there are no changes, bar editorial to the normative parts of MAP, something that is proven by existing implementations prior to this draft supporting the current draft. A few individuals appear to object to new descriptive text which highlights the usage of MAP, eg in 1:1. Removing that text will not change the matter that MAP allows such usage. Prohibiting such use by specification would actually require a spec change, besides being unreasonable. 5. What is the problem? We're pleased to see a growing understanding of MAP's applicability to solve problems, incl v4-v6 address independence, when needed. Given that the emails on this thread do not appear to bring forward any technical issues with the MAP solution, could we know WHY we need other solutions to the problem, or what is the problem that remains to be solved? Taking the liberty to speak on behalf of the other MAP authors, I would like to say that we all remain open for collaboration with all WG members in terms of arriving at a minimal set of reasonable solutions that solve problems that the community cares about. We also trust that our renewed WG leadership will finally help us all in getting there. Regards, Woj. On 25 June 2012 08:51, Qi Sun wrote: > ** > Hi Satoru, > > In MAP 1:1 mode, if there are 10000000 subscribers, there would be > 10000000 MAP domains which a BR has to manage. I think that will create a > huge mapping table on the BR, which is called 'state' that stateful > solutions deal with. > > Best Regards! > > ------------------------------ > Qi Sun > > *From:* Satoru Matsushima > *Date:* 2012-06-25 10:27 > *To:* Lee, Yiu > *CC:* softwires@ietf.org; Yong Cui > *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT > reflect the consensus from the WG > Hi Yiu, > > No, that's a misunderstanding. > > Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber = mapping' in stateless manner, not to introduce 'per-flow NAT binding' or 'p= er-subscriber state on demand'. > > cheers, > --satoru > > On 2012/06/25, at 2:32, Lee, Yiu wrote: > > > Dear Satoru and MAP-DT > > > > I echo what Peng and Qiong said. When the WG agreed working on the > > stateless solution, it was very clear stated that the solution would no= t > > maintain states in the network. If the 1:1 mode changed this, this no > > longer matched the requirements stated in the stateless motivation draf= t, > > thus, it would disqualify MAP as a solution for the motivation draft. > > > > AFAIK, the MAP Design Team could propose a change, but such a dramatic > > change by introducing states in the network would require WG approval. = I > > would like the chairs to clarify this. > > > > Thanks, > > Yiu > > > > > > On 6/24/12 12:21 PM, "Peng Wu" wrote: > > > >> Hi Qiong, Satoru and all, > >> > > >> I should thank Qiong for pointing this out. I gotta say I'm a bit shoc= ked. > >> If I understand the procedures of IETF correctly, a WG document should > >> reflect the consensus of the WG. MAP is approved by the WG as a > >> stateless solution. As a participator in Softwire, I didn't get the > >> information anywhere that the MAP WG document would cover the > >> so-called 1:1, in fact per-user stateful mode before it was released, > >> not to say discuss in the WG. Don't the WG need to approve such big > >> change anymore? > >> > >> Now let me provide my impression as an outsider of the MAP DT. You > >> guys make great effort to build the solution, The address composition, > >> the GMA algorithm, the different types of address mapping rules. > >> should be quite difficult to pull together such sophisticated ideas. I > >> guess that's what it takes to achieve the benifits of statelessness. > >> And I admire that, bravo. Then, all of a sudden, you guys are saying, > >> let's apply this sophisticated method to the different problem, by > >> dropping quite some comlexity and twistting the mechanism a bit, seems > >> it may work. Considering the problem are now solved in a more pure and > >> clear way, I'm sorry but I CANNOT follow the logic here. > >> > >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima > >> wrote: > >>> Hi Qiong, > >>> > >>> I'm disagree with your opinion. > >>> > >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in > >>> the DT. > >>> 2. MAP just covers so called '1:1 mode' with most granular mapping ru= le > >>> for CEs provisioning, which is as one of its characteristics. > >>> 3. The motivation draft does not restrict that as you stated, just > >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. > >>> > >>> Best regards, > >>> --satoru > >>> > >>> > >>> On 2012/06/24, at 14:35, Qiong wrote: > >>> > >>>> Hi all, > >>>> > >>>> As we all know, once an individual draft is adopted as a WG draft, i= t > >>>> is owned by the whole WG, rather than just the editors. Just as Remi > >>>> said, the normal procedure to follow is to reach WG consensus _befor= e_ > >>>> posting a newly edited version. > >>>> > >>>> From draft-mdt-softwire-mapping-address-and-port-03 to > >>>> draft-ietf-softwire-map-00, there are several changes between them. = In > >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 an= d > >>>> IPv6 addressing, has never been discussed openly in the WG mailing > >>>> list, or even in the MAP design team either. > >>>> > >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation > >>>> draft. The motivation draft has clearly defines the "Stateless 4/6 > >>>> solution" as follows: > >>>> > >>>> Stateless 4/6 solution denotes a solution which does not require any > >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by an= y > >>>> IP address sharing function in the Service Provider's network. This > >>>> category of solutions assumes a dependency between an IPv6 prefix an= d > >>>> IPv4 address. > >>>> > >>>> AFAIK what the WG has adopted MAP related draft is > >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT > > >>>> draft-ietf-softwire-map-00. And the stateless solution should =B3res= ponse > > >>>> to the solution motivation document=B2 according to the Softwire cha= rter. > > >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG dr= aft. > >>>> > >>>> We can all recall that our softwire WG has worked on stateless > >>>> solutions for more than one and a half years, and we have achieved a > > >>>> lot of work which has been documented in charter, stateless motivati= on, > >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic > >>>> "stateless" principle and the MAP design team is also working on it > >>>> together to find a better algorithm, address format, etc. So it is > > >>>> really not appropriate to make such changes when MAP is adopted as a= WG > >>>> item in such a short time. > >>>> > >>>> From this perspective, draft-ietf-softwire-map-00 can only be regard= ed > >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even the > >>>> output of MAP design team. > >>>> > >>>> Best wishes > >>>> > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 > >> _______________________________________________ > >> 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 > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --00235452f5c855f65004c34cbe50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

taking a step back to discuss some items in more detail, and hopefully = move this discussion forward:

1. Domain size
The MAP architecture does not prescribe the size of a domain,=20 and neither does it prescribe the number of rules to be used. There is noth= ing in the technology, except vendor implementation limits or practical sen= se (or both), to prevent MAP domains from defining 1 domain =3D 1 CPE. This= was a day 1 characteristic of MAP drafts.
Choosing to deploy or implement MAP with a configuration supporting 1 rule,= 100 rules or 100k rules or domains is a vendor's and/or operator's= choice. Nobody is stating that deployment is to be limited to X rules, nor= that a near infinite number of rules is reasonable. These are general poin= ts that apply to DS-lite state as well as the "Light Weight 4 over 6&q= uot; or "stateless deterministic NAT", and pretty much any techno= logy for that matter.

2. Stateless DOES NOT mean configuration-less
There appears to be co= nfusion between the concept of stateless and configuration-less. MAP domain= s are based on configured rules, that are provisioned/applied through means= that are currently outside the scope of Softwire drafts - this is configur= ation state, and this was and continues to be a characteristic of MAP.
Further more, unlike some of the other proposals, MAP allows to optimize th= e amount of configuration needed in cases where this is viable. In other wo= rds, MAP does NOT exclusively force 1:1 rule configuration, but also allows= N:1.

3. Stateless has no data plane induced state
A major difference betw= een stateless (eg MAP) and stateful (eg Carrier Grade NAT44/Ds-Lite) soluti= ons is that the latter are characterised by dynamic core node forwarding st= ate that is directly driven by user data-plane traffic (eg new IP flows). M= AP does not rely on such dynamic state, never did.

4. No change of MAP spec
The updated MAP draft does not change the M= AP architecture nor its technical underpinnings. In fact there are no chang= es, bar editorial to the normative parts of MAP, something that is proven b= y existing implementations prior to this draft supporting the current draft= . A few individuals appear to object to new descriptive text which highligh= ts the usage of MAP, eg in 1:1. Removing that text will not change the matt= er that MAP allows such usage. Prohibiting such use by specification would = actually require a spec change, besides being unreasonable.

5. What is the problem?
We're=A0 pleased to see a growing unders= tanding of MAP's applicability to solve problems, incl v4-v6 address in= dependence, when needed. Given that the emails on this thread do not appear= to bring forward any technical issues with the MAP solution, could we know= WHY we need other solutions to the problem, or what is the problem that re= mains to be solved?

Taking the liberty to speak on behalf of the other MAP authors, I would= like to say that we all remain open for collaboration with all WG members = in terms of arriving at a minimal set of reasonable solutions that solve pr= oblems that the community cares about. We also trust that our renewed WG le= adership will finally help us all in getting there.

Regards,
Woj.

On 25 June 2012 08:5= 1, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:
Hi Satoru,
=A0
In MAP 1:1 mode, if there are 10000000 subscribers, there would be 100= 00000=20 MAP domains which a BR has to manage. I think that will create a huge mappi= ng=20 table on the BR, which is called 'state' that stateful solutions de= al=20 with.
=A0
Best Regards!
=A0
Qi Sun
=A0
Date:=A02012-06-25=A010:27
Subject:=A0Re: [Softwires] [Softwire] draft-ietf-softwire-map-0= 0=20 does NOT reflect the consensus from the WG
Hi=A0Yiu,
=A0
No,=A0that's=A0a=A0misunderstanding.
Current=A0MAP=A0specify=A0the=A0case=A0for=A0ea-len=A0is=A0'zero&#= 39;.=A0It=A0is=A0'per-subscriber=A0mapping'=A0in=A0stateless=A0mann= er,=A0not=A0to=A0introduce=A0'per-flow=A0NAT=A0binding'=A0or=A0'= ;per-subscriber=A0state=A0on=A0demand'.
=A0
cheers,
--satoru
=A0
On=A02012/06/25,=A0at=A02:32,=A0Lee,=A0Yiu=A0wrote:
=A0
>=A0Dear=A0Satoru=A0and=A0MAP-DT
>=A0
>=A0I=A0echo=A0what=A0Peng=A0and=A0Qiong=A0said.=A0When=A0the=A0WG= =A0agreed=A0working=A0on=A0the
>=A0stateless=A0solution,=A0it=A0was=A0very=A0clear=A0stated=A0that= =A0the=A0solution=A0would=A0not
>=A0maintain=A0states=A0in=A0the=A0network.=A0If=A0the=A01:1=A0mode= =A0changed=A0this,=A0this=A0no
>=A0longer=A0matched=A0the=A0requirements=A0stated=A0in=A0the=A0sta= teless=A0motivation=A0draft,
>=A0thus,=A0it=A0would=A0disqualify=A0MAP=A0as=A0a=A0solution=A0for= =A0the=A0motivation=A0draft.
>=A0
>=A0AFAIK,=A0the=A0MAP=A0Design=A0Team=A0could=A0propose=A0a=A0chan= ge,=A0but=A0such=A0a=A0dramatic
>=A0change=A0by=A0introducing=A0states=A0in=A0the=A0network=A0would= =A0require=A0WG=A0approval.=A0I
>=A0would=A0like=A0the=A0chairs=A0to=A0clarify=A0this.
>=A0
>=A0Thanks,
>=A0Yiu
>=A0
>=A0
>=A0On=A06/24/12=A012:21=A0PM,=A0"Peng=A0Wu"=A0<pengwu.thu@gmail.com>=A0wrote:
>=A0
>>=A0Hi=A0Qiong,=A0Satoru=A0and=A0all,
>>=A0
>>=A0I=A0should=A0thank=A0Qiong=A0for=A0pointing=A0this=A0out.= =A0I=A0gotta=A0say=A0I'm=A0a=A0bit=A0shocked.
>>=A0If=A0I=A0understand=A0the=A0procedures=A0of=A0IETF=A0correc= tly,=A0a=A0WG=A0document=A0should
>>=A0reflect=A0the=A0consensus=A0of=A0the=A0WG.=A0MAP=A0is=A0app= roved=A0by=A0the=A0WG=A0as=A0a
>>=A0stateless=A0solution.=A0As=A0a=A0participator=A0in=A0Softwi= re,=A0I=A0didn't=A0get=A0the
>>=A0information=A0anywhere=A0that=A0the=A0MAP=A0WG=A0document= =A0would=A0cover=A0the
>>=A0so-called=A01:1,=A0in=A0fact=A0per-user=A0stateful=A0mode= =A0before=A0it=A0was=A0released,
>>=A0not=A0to=A0say=A0discuss=A0in=A0the=A0WG.=A0Don't=A0the= =A0WG=A0need=A0to=A0approve=A0such=A0big
>>=A0change=A0anymore?
>>=A0
>>=A0Now=A0let=A0me=A0provide=A0my=A0impression=A0as=A0an=A0outs= ider=A0of=A0the=A0MAP=A0DT.=A0You
>>=A0guys=A0make=A0great=A0effort=A0to=A0build=A0the=A0solution,= =A0The=A0address=A0composition,
>>=A0the=A0GMA=A0algorithm,=A0the=A0different=A0types=A0of=A0add= ress=A0mapping=A0rules.
>>=A0should=A0be=A0quite=A0difficult=A0to=A0pull=A0together=A0su= ch=A0sophisticated=A0ideas.=A0I
>>=A0guess=A0that's=A0what=A0it=A0takes=A0to=A0achieve=A0the= =A0benifits=A0of=A0statelessness.
>>=A0And=A0I=A0admire=A0that,=A0bravo.=A0Then,=A0all=A0of=A0a=A0= sudden,=A0you=A0guys=A0are=A0saying,
>>=A0let's=A0apply=A0this=A0sophisticated=A0method=A0to=A0th= e=A0different=A0problem,=A0by
>>=A0dropping=A0quite=A0some=A0comlexity=A0and=A0twistting=A0the= =A0mechanism=A0a=A0bit,=A0seems
>>=A0it=A0may=A0work.=A0Considering=A0the=A0problem=A0are=A0now= =A0solved=A0in=A0a=A0more=A0pure=A0and
>>=A0clear=A0way,=A0I'm=A0sorry=A0but=A0I=A0CANNOT=A0follow= =A0the=A0logic=A0here.
>>=A0
>>=A0On=A0Sun,=A0Jun=A024,=A02012=A0at=A02:00=A0PM,=A0Satoru=A0M= atsushima
>>>=A0Hi=A0Qiong,
>>>=A0
>>>=A0I'm=A0disagree=A0with=A0your=A0opinion.
>>>=A0
>>>=A01.=A0Recent=A0changes=A0in=A0draft-ietf-softwire-map-00= =A0has=A0been=A0discussed=A0in
>>>=A0the=A0DT.
>>>=A02.=A0MAP=A0just=A0covers=A0so=A0called=A0'1:1=A0mod= e'=A0with=A0most=A0granular=A0mapping=A0rule
>>>=A0for=A0CEs=A0provisioning,=A0which=A0is=A0as=A0one=A0of= =A0its=A0characteristics.
>>>=A03.=A0The=A0motivation=A0draft=A0does=A0not=A0restrict= =A0that=A0as=A0you=A0stated,=A0just
>>>=A0'assumed',=A0it's=A0neither=A0'MUST'= ;=A0nor=A0'SHOULD'.
>>>=A0
>>>=A0Best=A0regards,
>>>=A0--satoru
>>>=A0
>>>=A0
>>>=A0On=A02012/06/24,=A0at=A014:35,=A0Qiong=A0wrote:
>>>=A0
>>>>=A0Hi=A0all,
>>>>=A0
>>>>=A0As=A0we=A0all=A0know,=A0once=A0an=A0individual=A0dr= aft=A0is=A0adopted=A0as=A0a=A0WG=A0draft,=A0it
>>>>=A0is=A0owned=A0by=A0the=A0whole=A0WG,=A0rather=A0than= =A0just=A0the=A0editors.=A0Just=A0as=A0Remi
>>>>=A0said,=A0the=A0normal=A0procedure=A0to=A0follow=A0is= =A0to=A0reach=A0WG=A0consensus=A0_before_
>>>>=A0posting=A0a=A0newly=A0edited=A0version.
>>>>=A0
>>>>=A0From=A0draft-mdt-softwire-mapping-address-and-port-= 03=A0to
>>>>=A0draft-ietf-softwire-map-00,=A0there=A0are=A0several= =A0changes=A0between=A0them.=A0In
>>>>=A0particular,=A0the=A0newly=A0introduced=A0"1:1= =A0mode",=A0which=A0decouples=A0IPv4=A0and
>>>>=A0IPv6=A0addressing,=A0has=A0never=A0been=A0discussed= =A0openly=A0in=A0the=A0WG=A0mailing
>>>>=A0list,=A0or=A0even=A0in=A0the=A0MAP=A0design=A0team= =A0either.
>>>>=A0
>>>>=A0Actually,=A0this=A0"1:1=A0mode"=A0is=A0ag= ainst=A0the=A0stateless-4v6-motivation
>>>>=A0draft.=A0The=A0motivation=A0draft=A0has=A0clearly= =A0defines=A0the=A0"Stateless=A04/6
>>>>=A0solution"=A0as=A0follows:
>>>>=A0
>>>>=A0Stateless=A04/6=A0solution=A0denotes=A0a=A0solution= =A0which=A0does=A0not=A0require=A0any
>>>>=A0per-user=A0state=A0(see=A0Section=A02.3=A0of=A0[RFC= 1958])=A0to=A0be=A0maintained=A0by=A0any
>>>>=A0IP=A0address=A0sharing=A0function=A0in=A0the=A0Serv= ice=A0Provider's=A0network.=A0This
>>>>=A0category=A0of=A0solutions=A0assumes=A0a=A0dependenc= y=A0between=A0an=A0IPv6=A0prefix=A0and
>>>>=A0IPv4=A0address.
>>>>=A0
>>>>=A0AFAIK=A0what=A0the=A0WG=A0has=A0adopted=A0MAP=A0rel= ated=A0draft=A0is
>>>>=A0draft-mdt-softwire-mapping-address-and-port-03,=A0N= OT
>>>>=A0draft-ietf-softwire-map-00.=A0And=A0the=A0stateless= =A0solution=A0should=A0=B3response
>>>>=A0to=A0the=A0solution=A0motivation=A0document=B2=A0ac= cording=A0to=A0the=A0Softwire=A0charter.
>>>>=A0That=A0means=A0draft-ietf-softwire-map-00=A0IS=A0NO= T=A0QUALIFIED=A0to=A0be=A0a=A0WG=A0draft.
>>>>=A0
>>>>=A0We=A0can=A0all=A0recall=A0that=A0our=A0softwire=A0W= G=A0has=A0worked=A0on=A0stateless
>>>>=A0solutions=A0for=A0more=A0than=A0one=A0and=A0a=A0hal= f=A0years,=A0and=A0we=A0have=A0achieved=A0a
>>>>=A0lot=A0of=A0work=A0which=A0has=A0been=A0documented= =A0in=A0charter,=A0stateless=A0motivation,
>>>>=A04rd-varients,=A0MAP-03,=A0etc.=A0AFAIK=A0all=A0the= =A0authors=A0have=A0kept=A0the=A0basic
>>>>=A0"stateless"=A0principle=A0and=A0the=A0MAP= =A0design=A0team=A0is=A0also=A0working=A0on=A0it
>>>>=A0together=A0to=A0find=A0a=A0better=A0algorithm,=A0ad= dress=A0format,=A0etc.=A0So=A0it=A0is
>>>>=A0really=A0not=A0appropriate=A0to=A0make=A0such=A0cha= nges=A0when=A0MAP=A0is=A0adopted=A0as=A0a=A0WG
>>>>=A0item=A0in=A0such=A0a=A0short=A0time.
>>>>=A0
>>>>=A0From=A0this=A0perspective,=A0draft-ietf-softwire-ma= p-00=A0can=A0only=A0be=A0regarded
>>>>=A0as=A0draft-XX-softwire-mapping-address-and-port-04.= =A0It=A0is=A0not=A0even=A0the
>>>>=A0output=A0of=A0MAP=A0design=A0team.
>>>>=A0
>>>>=A0Best=A0wishes
>>>>=A0
>>>>=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>>>>=A0Qiong=A0Sun
>>>>=A0China=A0Telecom=A0Beijing=A0Research=A0Institude
>>>>=A0
>>>>=A0
>>>>=A0Open=A0source=A0code:
>>>>=A0lightweight=A04over6:=A0http://sourceforge.net/projects/l= aft6/
>>>>=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>>>>=A0
>>>>=A0
>>>>=A0_______________________________________________
>>>>=A0Softwires=A0mailing=A0list
>>>=A0
>>>=A0_______________________________________________
>>>=A0Softwires=A0mailing=A0list
>>>=A0https://www.ietf.org/mailman/listinfo/softwires<= /div>
>>=A0_______________________________________________
>>=A0Softwires=A0mailing=A0list
>>=A0https://www.ietf.org/mailman/listinfo/softwires
=A0
_______________________________________________
Softwires=A0mailing=A0list

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


--00235452f5c855f65004c34cbe50-- From satoru.matsushima@gmail.com Mon Jun 25 07:48: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 3096521F8627 for ; Mon, 25 Jun 2012 07:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FVw-RSrxB0c for ; Mon, 25 Jun 2012 07:48:39 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4420121F8623 for ; Mon, 25 Jun 2012 07:48:39 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6740016pbc.31 for ; Mon, 25 Jun 2012 07:48:39 -0700 (PDT) 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=CKK4n1/fRABogjMl4OQgcAQeUokgMblrUtivCd4aydo=; b=qP5xbzOFa3RVDz07OIWcu1WxJuqrwzXc2ZryA3OEY47urkmYf4hbKEDvC18A8JCrzT Sv27kfn+xBk534Ejuwbt7xQhMVSlvif0fEyhBhhWeNHo4NA/2vDwHjR3u2UUD+KX5oZz E5+Odm1aeDW586uCM8Ava0+ekWDG6TPLjuNF0qMr7G8yq5rzUrTMCWSvkk/pom6Afh9D MGKUd/E/dEJPELxg4j4izQK+Uv/WZ9kazfzfh21qa6sV9+6q5FJ4DbLtB7iJSY9jwohD tnJyZvG3NXOyHFkrY0/l6fp1l4T2mghG+UHyVyeC1Ce2rdat3C+eKDY/vb78EGNdrhRo sBCg== Received: by 10.68.222.40 with SMTP id qj8mr40618997pbc.139.1340635718557; Mon, 25 Jun 2012 07:48:38 -0700 (PDT) Received: from ?IPv6:2400:2411:8900::a843:af7c:92b6:144e? ([2400:2411:8900:0:a843:af7c:92b6:144e]) by mx.google.com with ESMTPS id u5sm8708572pbu.76.2012.06.25.07.48.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 07:48:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Mon, 25 Jun 2012 23:48:33 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <971226EB-E444-4A55-9A77-F9A6EE3081E0@gmail.com> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 14:48:40 -0000 +1. It all covers what I argued in the long thread just on today, thanks = Woj. cheers, --satoru On 2012/06/25, at 23:24, Wojciech Dec wrote: > Hi, >=20 > taking a step back to discuss some items in more detail, and hopefully = move this discussion forward: >=20 > 1. Domain size > The MAP architecture does not prescribe the size of a domain, and = neither does it prescribe the number of rules to be used. There is = nothing in the technology, except vendor implementation limits or = practical sense (or both), to prevent MAP domains from defining 1 domain = =3D 1 CPE. This was a day 1 characteristic of MAP drafts.=20 > Choosing to deploy or implement MAP with a configuration supporting 1 = rule, 100 rules or 100k rules or domains is a vendor's and/or operator's = choice. Nobody is stating that deployment is to be limited to X rules, = nor that a near infinite number of rules is reasonable. These are = general points that apply to DS-lite state as well as the "Light Weight = 4 over 6" or "stateless deterministic NAT", and pretty much any = technology for that matter. >=20 > 2. Stateless DOES NOT mean configuration-less > There appears to be confusion between the concept of stateless and = configuration-less. MAP domains are based on configured rules, that are = provisioned/applied through means that are currently outside the scope = of Softwire drafts - this is configuration state, and this was and = continues to be a characteristic of MAP. > Further more, unlike some of the other proposals, MAP allows to = optimize the amount of configuration needed in cases where this is = viable. In other words, MAP does NOT exclusively force 1:1 rule = configuration, but also allows N:1.=20 >=20 > 3. Stateless has no data plane induced state > A major difference between stateless (eg MAP) and stateful (eg Carrier = Grade NAT44/Ds-Lite) solutions is that the latter are characterised by = dynamic core node forwarding state that is directly driven by user = data-plane traffic (eg new IP flows). MAP does not rely on such dynamic = state, never did. >=20 > 4. No change of MAP spec > The updated MAP draft does not change the MAP architecture nor its = technical underpinnings. In fact there are no changes, bar editorial to = the normative parts of MAP, something that is proven by existing = implementations prior to this draft supporting the current draft. A few = individuals appear to object to new descriptive text which highlights = the usage of MAP, eg in 1:1. Removing that text will not change the = matter that MAP allows such usage. Prohibiting such use by specification = would actually require a spec change, besides being unreasonable. >=20 > 5. What is the problem? > We're pleased to see a growing understanding of MAP's applicability = to solve problems, incl v4-v6 address independence, when needed. Given = that the emails on this thread do not appear to bring forward any = technical issues with the MAP solution, could we know WHY we need other = solutions to the problem, or what is the problem that remains to be = solved?=20 >=20 > Taking the liberty to speak on behalf of the other MAP authors, I = would like to say that we all remain open for collaboration with all WG = members in terms of arriving at a minimal set of reasonable solutions = that solve problems that the community cares about. We also trust that = our renewed WG leadership will finally help us all in getting there. >=20 > Regards, > Woj. >=20 > On 25 June 2012 08:51, Qi Sun wrote: > Hi Satoru, > =20 > In MAP 1:1 mode, if there are 10000000 subscribers, there would be = 10000000 MAP domains which a BR has to manage. I think that will create = a huge mapping table on the BR, which is called 'state' that stateful = solutions deal with. > =20 > Best Regards! > =20 > Qi Sun > =20 > From: Satoru Matsushima > Date: 2012-06-25 10:27 > To: Lee, Yiu > CC: softwires@ietf.org; Yong Cui > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does = NOT reflect the consensus from the WG > Hi Yiu, > =20 > No, that's a misunderstanding. > Current MAP specify the case for ea-len is 'zero'. It is = 'per-subscriber mapping' in stateless manner, not to introduce 'per-flow = NAT binding' or 'per-subscriber state on demand'. > =20 > cheers, > --satoru > =20 > On 2012/06/25, at 2:32, Lee, Yiu wrote: > =20 > > Dear Satoru and MAP-DT > >=20 > > I echo what Peng and Qiong said. When the WG agreed working on the > > stateless solution, it was very clear stated that the solution would = not > > maintain states in the network. If the 1:1 mode changed this, this = no > > longer matched the requirements stated in the stateless motivation = draft, > > thus, it would disqualify MAP as a solution for the motivation = draft. > >=20 > > AFAIK, the MAP Design Team could propose a change, but such a = dramatic > > change by introducing states in the network would require WG = approval. I > > would like the chairs to clarify this. > >=20 > > Thanks, > > Yiu > >=20 > >=20 > > On 6/24/12 12:21 PM, "Peng Wu" wrote: > >=20 > >> Hi Qiong, Satoru and all, > >>=20 > >> I should thank Qiong for pointing this out. I gotta say I'm a bit = shocked. > >> If I understand the procedures of IETF correctly, a WG document = should > >> reflect the consensus of the WG. MAP is approved by the WG as a > >> stateless solution. As a participator in Softwire, I didn't get the > >> information anywhere that the MAP WG document would cover the > >> so-called 1:1, in fact per-user stateful mode before it was = released, > >> not to say discuss in the WG. Don't the WG need to approve such big > >> change anymore? > >>=20 > >> Now let me provide my impression as an outsider of the MAP DT. You > >> guys make great effort to build the solution, The address = composition, > >> the GMA algorithm, the different types of address mapping rules. > >> should be quite difficult to pull together such sophisticated = ideas. I > >> guess that's what it takes to achieve the benifits of = statelessness. > >> And I admire that, bravo. Then, all of a sudden, you guys are = saying, > >> let's apply this sophisticated method to the different problem, by > >> dropping quite some comlexity and twistting the mechanism a bit, = seems > >> it may work. Considering the problem are now solved in a more pure = and > >> clear way, I'm sorry but I CANNOT follow the logic here. > >>=20 > >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima > >> wrote: > >>> Hi Qiong, > >>>=20 > >>> I'm disagree with your opinion. > >>>=20 > >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed = in > >>> the DT. > >>> 2. MAP just covers so called '1:1 mode' with most granular mapping = rule > >>> for CEs provisioning, which is as one of its characteristics. > >>> 3. The motivation draft does not restrict that as you stated, just > >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. > >>>=20 > >>> Best regards, > >>> --satoru > >>>=20 > >>>=20 > >>> On 2012/06/24, at 14:35, Qiong wrote: > >>>=20 > >>>> Hi all, > >>>>=20 > >>>> As we all know, once an individual draft is adopted as a WG = draft, it > >>>> is owned by the whole WG, rather than just the editors. Just as = Remi > >>>> said, the normal procedure to follow is to reach WG consensus = _before_ > >>>> posting a newly edited version. > >>>>=20 > >>>> =46rom draft-mdt-softwire-mapping-address-and-port-03 to > >>>> draft-ietf-softwire-map-00, there are several changes between = them. In > >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 = and > >>>> IPv6 addressing, has never been discussed openly in the WG = mailing > >>>> list, or even in the MAP design team either. > >>>>=20 > >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation > >>>> draft. The motivation draft has clearly defines the "Stateless = 4/6 > >>>> solution" as follows: > >>>>=20 > >>>> Stateless 4/6 solution denotes a solution which does not require = any > >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by = any > >>>> IP address sharing function in the Service Provider's network. = This > >>>> category of solutions assumes a dependency between an IPv6 prefix = and > >>>> IPv4 address. > >>>>=20 > >>>> AFAIK what the WG has adopted MAP related draft is > >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT > >>>> draft-ietf-softwire-map-00. And the stateless solution should = =B3response > >>>> to the solution motivation document=B2 according to the Softwire = charter. > >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG = draft. > >>>>=20 > >>>> We can all recall that our softwire WG has worked on stateless > >>>> solutions for more than one and a half years, and we have = achieved a > >>>> lot of work which has been documented in charter, stateless = motivation, > >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the = basic > >>>> "stateless" principle and the MAP design team is also working on = it > >>>> together to find a better algorithm, address format, etc. So it = is > >>>> really not appropriate to make such changes when MAP is adopted = as a WG > >>>> item in such a short time. > >>>>=20 > >>>> =46rom this perspective, draft-ietf-softwire-map-00 can only be = regarded > >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even = the > >>>> output of MAP design team. > >>>>=20 > >>>> Best wishes > >>>>=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/ > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 > >>>=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 > =20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 From despres.remi@laposte.net Mon Jun 25 08:28: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 74DBB21F8593 for ; Mon, 25 Jun 2012 08:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYufFQvy4H+Q for ; Mon, 25 Jun 2012 08:28:45 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id E328B21F858A for ; Mon, 25 Jun 2012 08:28:44 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 2266D7000118; Mon, 25 Jun 2012 17:28:44 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 8D660700005B; Mon, 25 Jun 2012 17:28:43 +0200 (CEST) X-SFR-UUID: 20120625152843579.8D660700005B@msfrf2212.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 25 Jun 2012 17:28:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 15:28:45 -0000 2012-06-25 =E0 16:24, Wojciech Dec: ... > The updated MAP draft does not change the MAP architecture nor its = technical underpinnings. In fact there are no changes, bar editorial to = the normative parts of MAP, Having asked several times for a list of substantial evolutions from = previous MAP drafts, with their justifications, and having received no = answer, I see this statement as an indirect but first answer. But it doesn't seem acceptable (*): - AFAIK, the added 5th parameter of basic mapping rules is more than = editorial - I didn't find the equivalent of the following sentence in previous = drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by = other means, MUST disable its NAT44 functionality." =3D> A carefully studied list of substantial changes MAP supporters have = found appropriate after the Paris meeting remains to be due. > something that is proven by existing implementations prior to this = draft supporting the current draft. Please understand that your stating that some tests (for which we don't = have detailed reports) should be considered a proof that what you say is = true, is difficult to accept.=20 Especially if what you say seems contradicted by a verifiable fact (see = (*) above). RD From sarikaya2012@gmail.com Mon Jun 25 11:50: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 B8F8311E80A1 for ; Mon, 25 Jun 2012 11:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95dLzH7cKLoV for ; Mon, 25 Jun 2012 11:50:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCBDB11E8089 for ; Mon, 25 Jun 2012 11:50:33 -0700 (PDT) Received: by yenq13 with SMTP id q13so3470593yen.31 for ; Mon, 25 Jun 2012 11:50:33 -0700 (PDT) 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=5fH1qTIqdHAE8n5Km1v+Gn8NtJDlzMNfxIGABiCYlRU=; b=Kltz/OW+lErzTuZP1p5LVY16KzbMKmOSLUEAepFoFxvLzWDx4BxYtLaa+4LmdPmlwJ 3ppt28KiuPlyIKR5gc4AV6DL17A2ED19oG1nueFtsBL7dkeTgDqn1iYDESqsf6360xx/ DZJPN+JljbKdY80Jw0GPWbK1Vu413PMD2uKpgEyn4ZdLSqrEY3LN+/RjOzLGD4K1Yj9+ CLOmS+HWQlTFIRwrZhpID5mwEyjHBpfLrXCu3qarSnDk2yzNhe7cmahh6ordCxjb0NKd /4dj0GJ04rmKDzbyFg7Npv0WMF71Z949tXcXrdH8N6VmNjkNi/dzkWyPXEmusM/DGzmd TITg== MIME-Version: 1.0 Received: by 10.42.130.68 with SMTP id u4mr7192885ics.17.1340650233068; Mon, 25 Jun 2012 11:50:33 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Mon, 25 Jun 2012 11:50:32 -0700 (PDT) In-Reply-To: <4FE8007D.7000102@jacni.com> References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> Date: Mon, 25 Jun 2012 13:50:32 -0500 Message-ID: From: Behcet Sarikaya To: Jacni Qin Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires-wg Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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: Mon, 25 Jun 2012 18:50:37 -0000 On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin wrote: > Hi Behcet, all, > > > On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: >> >> Folks, >> >> We have published revised version of our draft on multicast extensions >> to DS-Lite at >> >> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt >> > > It's been discussed on the list and in the 81st meeting, and concluded quite > clearly by the WG why this is abandoned. > It tunnels the IGMP packets upwards, replicates the multicast traffic "per > tunnel", opposite to the property of multicast technology. And these are > problems we're trying to solve. > draft-ietf-softwire-dslite-multicast-02 has nothing to do with DS-Lite and therefore it is not a DS-Lite multicast extensions document as the charter requires. OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates multicast into DS-Lite tunnel. It is not against multicast technology. > There is no necessity to initiate that kind of discussion once again. > I did not start this discussion. Please check the list. Regards. Behcet > > Cheers, > Jacni > > >> We think that this draft should be part of >> draft-ietf-softwire-dslite-multicast. >> >> Regards, >> >> Behcet >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > From Tetsuya.Murakami@ipinfusion.com Mon Jun 25 15:51: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 4B66321F85C5 for ; Mon, 25 Jun 2012 15:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otNGDHmx8nOJ for ; Mon, 25 Jun 2012 15:51:06 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id F264221F85C4 for ; Mon, 25 Jun 2012 15:51:04 -0700 (PDT) Received: from mail83-am1-R.bigfish.com (10.3.201.225) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Jun 2012 22:49:25 +0000 Received: from mail83-am1 (localhost [127.0.0.1]) by mail83-am1-R.bigfish.com (Postfix) with ESMTP id E67FC140190; Mon, 25 Jun 2012 22:49:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I936eIc85dh1432I1418I4015I14ffIzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25he5bhf0ahbe3k) Received-SPF: pass (mail83-am1: domain of ipinfusion.com designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=BY2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail83-am1 (localhost.localdomain [127.0.0.1]) by mail83-am1 (MessageSwitch) id 1340664563270381_30887; Mon, 25 Jun 2012 22:49:23 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.250]) by mail83-am1.bigfish.com (Postfix) with ESMTP id 3F8D12A004C; Mon, 25 Jun 2012 22:49:23 +0000 (UTC) Received: from BY2PRD0510HT002.namprd05.prod.outlook.com (157.56.236.101) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 25 Jun 2012 22:49:21 +0000 Received: from BY2PRD0510MB388.namprd05.prod.outlook.com ([169.254.3.207]) by BY2PRD0510HT002.namprd05.prod.outlook.com ([10.255.84.37]) with mapi id 14.16.0164.004; Mon, 25 Jun 2012 22:50:57 +0000 From: Tetsuya Murakami To: Wojciech Dec Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNUyT7AbQW5on+8UW6VDx03Kn7ig== Date: Mon, 25 Jun 2012 22:50:56 +0000 Message-ID: <459A6E94-9534-4203-940A-B04891B49DAB@ipinfusion.com> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> 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: multipart/alternative; boundary="_000_459A6E9495344203940AB04891B49DABipinfusioncom_" MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 25 Jun 2012 22:51:09 -0000 --_000_459A6E9495344203940AB04891B49DABipinfusioncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1. In fact, we have already done the implementation prior to the current MAP d= raft. But there is no change in our implementation in order to support the = current draft. In addition, our implementation has no limitation for the nu= mber of mapping rules. It depends on the available memory size only. So, ou= r implementation can allow 1:1 as well as N:1. Thanks, Tetsuya Murakami On 2012/06/25, at 7:24, Wojciech Dec wrote: Hi, taking a step back to discuss some items in more detail, and hopefully move= this discussion forward: 1. Domain size The MAP architecture does not prescribe the size of a domain, and neither d= oes it prescribe the number of rules to be used. There is nothing in the te= chnology, except vendor implementation limits or practical sense (or both),= to prevent MAP domains from defining 1 domain =3D 1 CPE. This was a day 1 = characteristic of MAP drafts. Choosing to deploy or implement MAP with a configuration supporting 1 rule,= 100 rules or 100k rules or domains is a vendor's and/or operator's choice.= Nobody is stating that deployment is to be limited to X rules, nor that a = near infinite number of rules is reasonable. These are general points that = apply to DS-lite state as well as the "Light Weight 4 over 6" or "stateless= deterministic NAT", and pretty much any technology for that matter. 2. Stateless DOES NOT mean configuration-less There appears to be confusion between the concept of stateless and configur= ation-less. MAP domains are based on configured rules, that are provisioned= /applied through means that are currently outside the scope of Softwire dra= fts - this is configuration state, and this was and continues to be a chara= cteristic of MAP. Further more, unlike some of the other proposals, MAP allows to optimize th= e amount of configuration needed in cases where this is viable. In other wo= rds, MAP does NOT exclusively force 1:1 rule configuration, but also allows= N:1. 3. Stateless has no data plane induced state A major difference between stateless (eg MAP) and stateful (eg Carrier Grad= e NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic = core node forwarding state that is directly driven by user data-plane traff= ic (eg new IP flows). MAP does not rely on such dynamic state, never did. 4. No change of MAP spec The updated MAP draft does not change the MAP architecture nor its technica= l underpinnings. In fact there are no changes, bar editorial to the normati= ve parts of MAP, something that is proven by existing implementations prior= to this draft supporting the current draft. A few individuals appear to ob= ject to new descriptive text which highlights the usage of MAP, eg in 1:1. = Removing that text will not change the matter that MAP allows such usage. P= rohibiting such use by specification would actually require a spec change, = besides being unreasonable. 5. What is the problem? We're pleased to see a growing understanding of MAP's applicability to sol= ve problems, incl v4-v6 address independence, when needed. Given that the e= mails on this thread do not appear to bring forward any technical issues wi= th the MAP solution, could we know WHY we need other solutions to the probl= em, or what is the problem that remains to be solved? Taking the liberty to speak on behalf of the other MAP authors, I would lik= e to say that we all remain open for collaboration with all WG members in t= erms of arriving at a minimal set of reasonable solutions that solve proble= ms that the community cares about. We also trust that our renewed WG leader= ship will finally help us all in getting there. Regards, Woj. On 25 June 2012 08:51, Qi Sun > wrote: Hi Satoru, In MAP 1:1 mode, if there are 10000000 subscribers, there would be 10000000= MAP domains which a BR has to manage. I think that will create a huge mapp= ing table on the BR, which is called 'state' that stateful solutions deal w= ith. Best Regards! ________________________________ Qi Sun From: Satoru Matsushima Date: 2012-06-25 10:27 To: Lee, Yiu CC: softwires@ietf.org; Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT ref= lect the consensus from the WG Hi Yiu, No, that's a misunderstanding. Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber ma= pping' in stateless manner, not to introduce 'per-flow NAT binding' or 'per= -subscriber state on demand'. cheers, --satoru On 2012/06/25, at 2:32, Lee, Yiu wrote: > Dear Satoru and MAP-DT > > I echo what Peng and Qiong said. When the WG agreed working on the > stateless solution, it was very clear stated that the solution would not > maintain states in the network. If the 1:1 mode changed this, this no > longer matched the requirements stated in the stateless motivation draft, > thus, it would disqualify MAP as a solution for the motivation draft. > > AFAIK, the MAP Design Team could propose a change, but such a dramatic > change by introducing states in the network would require WG approval. I > would like the chairs to clarify this. > > Thanks, > Yiu > > > On 6/24/12 12:21 PM, "Peng Wu" > wrote: > >> Hi Qiong, Satoru and all, >> >> I should thank Qiong for pointing this out. I gotta say I'm a bit shocke= d. >> If I understand the procedures of IETF correctly, a WG document should >> reflect the consensus of the WG. MAP is approved by the WG as a >> stateless solution. As a participator in Softwire, I didn't get the >> information anywhere that the MAP WG document would cover the >> so-called 1:1, in fact per-user stateful mode before it was released, >> not to say discuss in the WG. Don't the WG need to approve such big >> change anymore? >> >> Now let me provide my impression as an outsider of the MAP DT. You >> guys make great effort to build the solution, The address composition, >> the GMA algorithm, the different types of address mapping rules. >> should be quite difficult to pull together such sophisticated ideas. I >> guess that's what it takes to achieve the benifits of statelessness. >> And I admire that, bravo. Then, all of a sudden, you guys are saying, >> let's apply this sophisticated method to the different problem, by >> dropping quite some comlexity and twistting the mechanism a bit, seems >> it may work. Considering the problem are now solved in a more pure and >> clear way, I'm sorry but I CANNOT follow the logic here. >> >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima >> > wrote: >>> Hi Qiong, >>> >>> I'm disagree with your opinion. >>> >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in >>> the DT. >>> 2. MAP just covers so called '1:1 mode' with most granular mapping rule >>> for CEs provisioning, which is as one of its characteristics. >>> 3. The motivation draft does not restrict that as you stated, just >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. >>> >>> Best regards, >>> --satoru >>> >>> >>> On 2012/06/24, at 14:35, Qiong wrote: >>> >>>> Hi all, >>>> >>>> As we all know, once an individual draft is adopted as a WG draft, it >>>> is owned by the whole WG, rather than just the editors. Just as Remi >>>> said, the normal procedure to follow is to reach WG consensus _before_ >>>> posting a newly edited version. >>>> >>>> From draft-mdt-softwire-mapping-address-and-port-03 to >>>> draft-ietf-softwire-map-00, there are several changes between them. In >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 and >>>> IPv6 addressing, has never been discussed openly in the WG mailing >>>> list, or even in the MAP design team either. >>>> >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation >>>> draft. The motivation draft has clearly defines the "Stateless 4/6 >>>> solution" as follows: >>>> >>>> Stateless 4/6 solution denotes a solution which does not require any >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by any >>>> IP address sharing function in the Service Provider's network. This >>>> category of solutions assumes a dependency between an IPv6 prefix and >>>> IPv4 address. >>>> >>>> AFAIK what the WG has adopted MAP related draft is >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT >>>> draft-ietf-softwire-map-00. And the stateless solution should =B3respo= nse >>>> to the solution motivation document=B2 according to the Softwire chart= er. >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draf= t. >>>> >>>> We can all recall that our softwire WG has worked on stateless >>>> solutions for more than one and a half years, and we have achieved a >>>> lot of work which has been documented in charter, stateless motivation= , >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic >>>> "stateless" principle and the MAP design team is also working on it >>>> together to find a better algorithm, address format, etc. So it is >>>> really not appropriate to make such changes when MAP is adopted as a W= G >>>> item in such a short time. >>>> >>>> From this perspective, draft-ietf-softwire-map-00 can only be regarded >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even the >>>> output of MAP design team. >>>> >>>> Best wishes >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >> _______________________________________________ >> 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 _______________________________________________ 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_459A6E9495344203940AB04891B49DABipinfusioncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable +1.

In fact, we have already done the implementation prior to the current = MAP draft. But there is no change in our implementation in order to support= the current draft. In addition, our implementation has no limitation for t= he number of mapping rules. It depends on the available memory size only. So, our implementation can allow 1:1 as= well as N:1.

Thanks,
Tetsuya Murakami

On 2012/06/25, at 7:24, Wojciech Dec wrote:

Hi,

taking a step back to discuss some items in more detail, and hopefully move= this discussion forward:

1. Domain size
The MAP architecture does not prescribe the size of a domain, and neither d= oes it prescribe the number of rules to be used. There is nothing in the te= chnology, except vendor implementation limits or practical sense (or both),= to prevent MAP domains from defining 1 domain =3D 1 CPE. This was a day 1 characteristic of MAP drafts.
Choosing to deploy or implement MAP with a configuration supporting 1 rule,= 100 rules or 100k rules or domains is a vendor's and/or operator's choice.= Nobody is stating that deployment is to be limited to X rules, nor that a = near infinite number of rules is reasonable. These are general points that apply to DS-lite state as well a= s the "Light Weight 4 over 6" or "stateless deterministic NA= T", and pretty much any technology for that matter.

2. Stateless DOES NOT mean configuration-less
There appears to be confusion between the concept of stateless and configur= ation-less. MAP domains are based on configured rules, that are provisioned= /applied through means that are currently outside the scope of Softwire dra= fts - this is configuration state, and this was and continues to be a characteristic of MAP.
Further more, unlike some of the other proposals, MAP allows to optimize th= e amount of configuration needed in cases where this is viable. In other wo= rds, MAP does NOT exclusively force 1:1 rule configuration, but also allows= N:1.

3. Stateless has no data plane induced state
A major difference between stateless (eg MAP) and stateful (eg Carrier Grad= e NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic = core node forwarding state that is directly driven by user data-plane traff= ic (eg new IP flows). MAP does not rely on such dynamic state, never did.

4. No change of MAP spec
The updated MAP draft does not change the MAP architecture nor its technica= l underpinnings. In fact there are no changes, bar editorial to the normati= ve parts of MAP, something that is proven by existing implementations prior= to this draft supporting the current draft. A few individuals appear to object to new descriptive text which hi= ghlights the usage of MAP, eg in 1:1. Removing that text will not change th= e matter that MAP allows such usage. Prohibiting such use by specification = would actually require a spec change, besides being unreasonable.

5. What is the problem?
We're  pleased to see a growing understanding of MAP's applicability t= o solve problems, incl v4-v6 address independence, when needed. Given that = the emails on this thread do not appear to bring forward any technical issu= es with the MAP solution, could we know WHY we need other solutions to the problem, or what is the problem that re= mains to be solved?

Taking the liberty to speak on behalf of the other MAP authors, I would lik= e to say that we all remain open for collaboration with all WG members in t= erms of arriving at a minimal set of reasonable solutions that solve proble= ms that the community cares about. We also trust that our renewed WG leadership will finally help us all in g= etting there.

Regards,
Woj.

On 25 June 2012 08:51, Qi Sun = <sunqi.cs= net.thu@gmail.com> wrote:
Hi Satoru,
 
In MAP 1:1 mode, if there are 10000000 subscribers, there would be 100= 00000 MAP domains which a BR has to manage. I think that will create a huge= mapping table on the BR, which is called 'state' that stateful solutions d= eal with.
 
Best Regards!
 
Qi Sun
 
Date: 2012-06-25 10:27
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-ma= p-00 does NOT reflect the consensus from the WG
Hi Yiu,
 
No, that's a misunderstanding.
Current MAP specify the case for ea-len&= nbsp;is 'zero'. It is 'per-subscriber mapping'&nbs= p;in stateless manner, not to introduce 'per-= flow NAT binding' or 'per-subscriber state on=  demand'.
 
cheers,
--satoru
 
On 2012/06/25, at 2:32, Lee, Yiu wrote:<= /div>
 
> Dear Satoru and MAP-DT
> 
> I echo what Peng and Qiong sai= d. When the WG agreed working on the
> stateless solution, it was very cle= ar stated that the solution would not
> maintain states in the network. If&= nbsp;the 1:1 mode changed this, this no
> longer matched the requirements stated&n= bsp;in the stateless motivation draft,
> thus, it would disqualify MAP as&nb= sp;a solution for the motivation draft.
> 
> AFAIK, the MAP Design Team could&nb= sp;propose a change, but such a dramatic
> change by introducing states in the=  network would require WG approval. I
> would like the chairs to clarify&nb= sp;this.
> 
> Thanks,
> Yiu
> 
> 
> On 6/24/12 12:21 PM, "Peng Wu&= quot; <pe= ngwu.thu@gmail.com> wrote:
> 
>> Hi Qiong, Satoru and all,
>> 
>> I should thank Qiong for pointi= ng this out. I gotta say I'm a bit&= nbsp;shocked.
>> If I understand the procedures = of IETF correctly, a WG document should
>> reflect the consensus of the WG= . MAP is approved by the WG as a
>> stateless solution. As a participato= r in Softwire, I didn't get the
>> information anywhere that the MAP&nb= sp;WG document would cover the
>> so-called 1:1, in fact per-user = ;stateful mode before it was released,
>> not to say discuss in the = WG. Don't the WG need to approve such&nb= sp;big
>> change anymore?
>> 
>> Now let me provide my impressio= n as an outsider of the MAP DT. You=
>> guys make great effort to build=  the solution, The address composition,
>> the GMA algorithm, the different&nbs= p;types of address mapping rules.
>> should be quite difficult to pu= ll together such sophisticated ideas. I
>> guess that's what it takes to&n= bsp;achieve the benifits of statelessness.
>> And I admire that, bravo. Then,=  all of a sudden, you guys are sayi= ng,
>> let's apply this sophisticated metho= d to the different problem, by
>> dropping quite some comlexity and&nb= sp;twistting the mechanism a bit, seems
>> it may work. Considering the pr= oblem are now solved in a more pure = ;and
>> clear way, I'm sorry but I = ;CANNOT follow the logic here.
>> 
>> On Sun, Jun 24, 2012 at 2:= 00 PM, Satoru Matsushima
>>> Hi Qiong,
>>> 
>>> I'm disagree with your opinion.<= /div>
>>> 
>>> 1. Recent changes in draft-ietf-= softwire-map-00 has been discussed in
>>> the DT.
>>> 2. MAP just covers so calle= d '1:1 mode' with most granular mapping = rule
>>> for CEs provisioning, which is&n= bsp;as one of its characteristics.
>>> 3. The motivation draft does&nbs= p;not restrict that as you stated, just
>>> 'assumed', it's neither 'MUST' n= or 'SHOULD'.
>>> 
>>> Best regards,
>>> --satoru
>>> 
>>> 
>>> On 2012/06/24, at 14:35, Qiong&n= bsp;wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> As we all know, once an=  individual draft is adopted as a WG&nbs= p;draft, it
>>>> is owned by the whole W= G, rather than just the editors. Just as=  Remi
>>>> said, the normal procedure t= o follow is to reach WG consensus _befor= e_
>>>> posting a newly edited versi= on.
>>>> 
>>>> From draft-mdt-softwire-mapping-address-and= -port-03 to
>>>> draft-ietf-softwire-map-00, there are&= nbsp;several changes between them. In
>>>> particular, the newly introduced&= nbsp;"1:1 mode", which decouples IPv4 an= d
>>>> IPv6 addressing, has never b= een discussed openly in the WG mailing
>>>> list, or even in the MA= P design team either.
>>>> 
>>>> Actually, this "1:1 mode&quo= t; is against the stateless-4v6-motivation
>>>> draft. The motivation draft = has clearly defines the "Stateless 4/6
>>>> solution" as follows:
>>>> 
>>>> Stateless 4/6 solution denotes&nb= sp;a solution which does not require any
>>>> per-user state (see Section = 2.3 of [RFC1958]) to be maintained by an= y
>>>> IP address sharing function = in the Service Provider's network. This
>>>> category of solutions assumes&nbs= p;a dependency between an IPv6 prefix and
>>>> IPv4 address.
>>>> 
>>>> AFAIK what the WG has a= dopted MAP related draft is
>>>> draft-mdt-softwire-mapping-address-and-port-03,&= nbsp;NOT
>>>> draft-ietf-softwire-map-00. And the&nb= sp;stateless solution should =B3response
>>>> to the solution motivation d= ocument=B2 according to the Softwire charter.
>>>> That means draft-ietf-softwire-map-00&= nbsp;IS NOT QUALIFIED to be a WG draft.<= /div>
>>>> 
>>>> We can all recall that = our softwire WG has worked on stateless
>>>> solutions for more than one&= nbsp;and a half years, and we have achie= ved a
>>>> lot of work which has b= een documented in charter, stateless motivation,
>>>> 4rd-varients, MAP-03, etc. AFAIK&= nbsp;all the authors have kept the basic
>>>> "stateless" principle and&nb= sp;the MAP design team is also working o= n it
>>>> together to find a better&nb= sp;algorithm, address format, etc. So it is
>>>> really not appropriate to ma= ke such changes when MAP is adopted as&n= bsp;a WG
>>>> item in such a short ti= me.
>>>> 
>>>> From this perspective, draft-ietf= -softwire-map-00 can only be regarded
>>>> as draft-XX-softwire-mapping-address-and-po= rt-04. It is not even the
>>>> output of MAP design team.
>>>> 
>>>> Best wishes
>>>> 
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=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&nb= sp;Institude
>>>> 
>>>> 
>>>> Open source code:
>>>> lightweight 4over6: http://sourceforge.net/p= rojects/laft6/
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>>>> 
>>>> 
>>>> _______________________________________________<= /div>
>>>> Softwires mailing list
>>> 

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


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

--_000_459A6E9495344203940AB04891B49DABipinfusioncom_-- From jacni@jacni.com Mon Jun 25 16:36:55 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 B963121F848F for ; Mon, 25 Jun 2012 16:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, SARE_RECV_IP_218078=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKiH5STmXtJt for ; Mon, 25 Jun 2012 16:36:54 -0700 (PDT) Received: from srv05.olivemail.cn (unknown [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id D948621F8478 for ; Mon, 25 Jun 2012 16:36:53 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 934713800A5 for ; Mon, 25 Jun 2012 19:36:52 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 3AB593400EC for ; Tue, 26 Jun 2012 07:36:51 +0800 (CST) Received: from [192.168.1.4] (unknown [218.82.182.206]) by app (Coremail) with SMTP id +AWowJDLYAIM9uhPut1vAQ--.51111S2; Tue, 26 Jun 2012 07:36:50 +0800 (CST) Message-ID: <4FE8F609.1040407@jacni.com> Date: Tue, 26 Jun 2012 07:36:41 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: +AWowJDLYAIM9uhPut1vAQ--.51111S2 X-Coremail-Antispam: 1UD129KBjvJXoW7WrW5tr4fJrW3CF4Utw13Arb_yoW8Cw18pa y0gF4jkrs8Jr18Cwn29w1v9ryvvFW5tFWvqa45Ga4UX34DGF1Utr1FkFW5ua4DJrZ8Cr4j vrWDCr17X3W3Zw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUU0bIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnK8YjsxI4VWxJwAYFVCjjxCrM7AEwI8IwI0E74AGY7Cv6cx26r4UM7CY 07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7V C0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41lc7I2 V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFw20E84ACjcxK64kEx2IqYxC7MI 8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43ZEXa7IUnHE EUUUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEQEko7lRcsyQABsV Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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, 25 Jun 2012 23:36:55 -0000 Re-, On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: > On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin wrote: >> Hi Behcet, all, >> >> >> On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: >>> Folks, >>> >>> We have published revised version of our draft on multicast extensions >>> to DS-Lite at >>> >>> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt >>> >> It's been discussed on the list and in the 81st meeting, and concluded quite >> clearly by the WG why this is abandoned. >> It tunnels the IGMP packets upwards, replicates the multicast traffic "per >> tunnel", opposite to the property of multicast technology. And these are >> problems we're trying to solve. >> > draft-ietf-softwire-dslite-multicast-02 has nothing to do with > DS-Lite and therefore it is not a DS-Lite multicast extensions > document as the charter requires. > OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates > multicast into DS-Lite tunnel. > > It is not against multicast technology. In this way, the efficiency is lost. If operators put the AFTR box deeply in the network, far from the end users, as you process the singling messages and replicate of traffic per tunnel, the network and the box will crash because of the huge burden. >> There is no necessity to initiate that kind of discussion once again. >> > I did not start this discussion. Please check the list. Again please see above, or check the archive and the offlist messages where we've explained it to you in detail. Cheers, Jacni > > Regards. > > Behcet > >> Cheers, >> Jacni >> >> >>> We think that this draft should be part of >>> draft-ietf-softwire-dslite-multicast. >>> >>> Regards, >>> >>> Behcet >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> From pengwu.thu@gmail.com Mon Jun 25 20:34: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 8EFCD21F8549 for ; Mon, 25 Jun 2012 20:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-KjRnlc8DvU for ; Mon, 25 Jun 2012 20:34:47 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E805321F8551 for ; Mon, 25 Jun 2012 20:34:46 -0700 (PDT) Received: by qadz3 with SMTP id z3so1703319qad.10 for ; Mon, 25 Jun 2012 20:34:46 -0700 (PDT) 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:content-transfer-encoding; bh=2KxsQm4gHXefn6q7cMiGM+6NQCYUmPlH/UNTRd2rSOw=; b=OoNv0HS3hxzIEsaHp76sAdeVVsNzrHwyPsg+G3ch3w4sXgxICNoZ3xEJYMDeHcPNBA EEggMvhZn3lFFpFPDUIyrCADYWL1ylEQoRNlv7dAeva8lomNZDG8ryfPrIvJJbAOQ28r pH2ORNtSvy+BH0vtN83CffEH0bHM6GFj4O27WGhyegPRqfdSC14v+uYK7MLbxSvJT2Ts KGklV/neUWI1nO62xuNxw2MJzsL9dCw9bvbIqAxPbleWl/SbscZXVqKWSYjmI7BjMUDT qaNWr5/EYQhR1HxLX3+an1FItAUuGxWg3tEXCxf3zO230fqp1+1dhI6K731PLpwsMQ7t 3jXw== MIME-Version: 1.0 Received: by 10.224.207.4 with SMTP id fw4mr23468757qab.82.1340681686323; Mon, 25 Jun 2012 20:34:46 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Mon, 25 Jun 2012 20:34:46 -0700 (PDT) In-Reply-To: <4FE86A26.2030000@joelhalpern.com> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <4FE86A26.2030000@joelhalpern.com> Date: Tue, 26 Jun 2012 11:34:46 +0800 Message-ID: From: Peng Wu To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 03:34:47 -0000 Hi Joel, Thanks for the clarification. Fully agree with the 4 types. Two additional comments: 1. From implementation view, the 2nd and the 3rd are more close to the 4th because there are binding table lookup procedure in data plane, while the 1st depends on algorithmic address calculation essentially. Some may argue that there are mutliple rules even in the 1st case, but that's a specific feature in IPv4-over-IPv6 scenario with address sharing demand, only because we want to include port set information into IPv6 address beside the IPv4 address and there may be not enough bits in IPv6 address. Generally this is not a necessary feature for pure stateless solution.(take 6RD and SIIT as example) 2. In this specific context, I quote what is the defined in the stateless motivation draft(http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-mot= ivation/): " Stateless 4/6 solution (or stateless solution in short): denotes a solution which does not require any PER-USER state (see Section 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a DEPENDENCY between an IPv6 prefix and IPv4 address." On Mon, Jun 25, 2012 at 9:39 PM, Joel M. Halpern wrot= e: > This appears to mix different kinds of state. > In particular, with regard to state in network resident boxes, there can = be: > General state covering all subscribers; > Per subscriber state provisioned state; > Per subscriber dynamic, but not flow specific state; > per flow state. > > All are state. > The first is clearly permitted. > The fourth is clearly not permitted in a "stateless" solution. > Some descriptions of "stateless" have allowed for the middle two, while > others have prohibited it. =A0I have no opinion on what the WG "agreement= " is > on the scoping. =A0But we need to be careful about what we mean about "st= ate". > > Yours, > Joel > > > On 6/25/2012 2:51 AM, Qi Sun wrote: >> >> Hi Satoru, >> In MAP 1:1 mode, if there are 10000000 subscribers, there would be >> 10000000 MAP domains which a BR has to manage. I think that will create >> a huge mapping table on the BR, which is called 'state' that stateful >> solutions deal with. >> Best Regards! >> Qi Sun > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From pengwu.thu@gmail.com Mon Jun 25 21:07: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 8567711E8079 for ; Mon, 25 Jun 2012 21:07:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQBOU2ZHycCL for ; Mon, 25 Jun 2012 21:07:36 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id A5A8621F8472 for ; Mon, 25 Jun 2012 21:07:36 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2634505qcm.15 for ; Mon, 25 Jun 2012 21:07:36 -0700 (PDT) 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:content-transfer-encoding; bh=HU/m9hJTHTShl8GD9nUVBs4MYxKj3ipunHQI3PMLcmk=; b=Sqn9fICEBpzq9tWCn4SaOAFqz3c3o6f1bsZsOAYUGOeAJ2wckO4155590vH+kcEFDD kwLD65h1ey1AvEu0oVoMx0OCuR9pL2ZgS1LRGukSSiPL/IGgZB2Ld7Y/KzwTU/rJTdki 6AoES95M0y6zKrUK24PGk7jNIHH2vi/Qb68SfFMn02Q+y7o8pQbWIN5SMHaTqFz041sL ko4Pt599JVAs2hmejBRrOmmIfEeotMtERd5QjnxldOieIcZjv+n1jcg1JehKmSyvXaA0 /5/CYVX5vLS9qNvWl7/wN7NENpqWShZejr1ohLNA4QL4cbvI/3eDGhHnHvUZqRSWUB00 dbVA== MIME-Version: 1.0 Received: by 10.229.136.145 with SMTP id r17mr85231qct.43.1340683656079; Mon, 25 Jun 2012 21:07:36 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Mon, 25 Jun 2012 21:07:35 -0700 (PDT) In-Reply-To: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> Date: Tue, 26 Jun 2012 12:07:35 +0800 Message-ID: From: Peng Wu To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 04:07:37 -0000 Woj, On Mon, Jun 25, 2012 at 10:24 PM, Wojciech Dec wrote: > Hi, > > taking a step back to discuss some items in more detail, and hopefully mo= ve > this discussion forward: > > 1. Domain size > The MAP architecture does not prescribe the size of a domain, and neither > does it prescribe the number of rules to be used. There is nothing in the > technology, except vendor implementation limits or practical sense (or > both), to prevent MAP domains from defining 1 domain =3D 1 CPE. This was = a day > 1 characteristic of MAP drafts. Yes from the theoretical view you could. But that's not the exact 1:1 mode the "ietf-map-00" described. You have to change the specification and twist the mechanism definiation to particularly support the 1:1 mode. > Choosing to deploy or implement MAP with a configuration supporting 1 rul= e, > 100 rules or 100k rules or domains is a vendor's and/or operator's choice= . > Nobody is stating that deployment is to be limited to X rules, nor that a > near infinite number of rules is reasonable. These are general points tha= t > apply to DS-lite state as well as the "Light Weight 4 over 6" or "statele= ss > deterministic NAT", and pretty much any technology for that matter. > > 2. Stateless DOES NOT mean configuration-less > There appears to be confusion between the concept of stateless and > configuration-less. MAP domains are based on configured rules, that are > provisioned/applied through means that are currently outside the scope of > Softwire drafts - this is configuration state, and this was and continues= to > be a characteristic of MAP. If you have per-user specific configuration, that definitely changes the operation model. > Further more, unlike some of the other proposals, MAP allows to optimize = the > amount of configuration needed in cases where this is viable. In other > words, MAP does NOT exclusively force 1:1 rule configuration, but also > allows N:1. That's not what is discussed in this thread at all... > > 3. Stateless has no data plane induced state > A major difference between stateless (eg MAP) and stateful (eg Carrier Gr= ade > NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic > core node forwarding state that is directly driven by user data-plane > traffic (eg new IP flows). MAP does not rely on such dynamic state, never > did. I think you only mean per-session stateful. For per-user stateful mechanisms, you run the provisioning process to avoid state creating from the data plane. That's one of the essential design goals and benifits of the per-user stateful mechanisms and reflected in lw4over6. > > 4. No change of MAP spec > The updated MAP draft does not change the MAP architecture nor its techni= cal > underpinnings. In fact there are no changes, bar editorial to the normati= ve > parts of MAP, something that is proven by existing implementations prior = to > this draft supporting the current draft. A few individuals appear to obje= ct > to new descriptive text which highlights the usage of MAP, eg in 1:1. > Removing that text will not change the matter that MAP allows such usage. > Prohibiting such use by specification would actually require a spec chang= e, > besides being unreasonable. Sorry, no. You need to change specifications, and you need to twist the definations of the terminology. For example, you need to explicitly provisio the port set information, which is not the usual case at all. > > 5. What is the problem? > We're=A0 pleased to see a growing understanding of MAP's applicability to > solve problems, incl v4-v6 address independence, when needed. Given that = the > emails on this thread do not appear to bring forward any technical issues > with the MAP solution, could we know WHY we need other solutions to the > problem, or what is the problem that remains to be solved? The problem is that there are apparently three types of solutions with perspective application scenarios, while the MAP solution, originally strongly customized for the pure stateless scenario, is now twisting itself in a somehow weired way, dropping the essential feature of statelessness, to include the per-user state/mapping scenario which can be solved by a more pure and clear solution. > Taking the liberty to speak on behalf of the other MAP authors, I would l= ike > to say that we all remain open for collaboration with all WG members in > terms of arriving at a minimal set of reasonable solutions that solve > problems that the community cares about. We also trust that our renewed W= G > leadership will finally help us all in getting there. No objection to MAP at all, AS LONG AS it follows the original, suitable problem space which it is expected to developed for. From wdec.ietf@gmail.com Mon Jun 25 23:04:07 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 BC2D221F8550 for ; Mon, 25 Jun 2012 23:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfZsoUKRSGOo for ; Mon, 25 Jun 2012 23:04:07 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id DA2EB21F8549 for ; Mon, 25 Jun 2012 23:04:06 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2666334qcm.15 for ; Mon, 25 Jun 2012 23:04:06 -0700 (PDT) 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=sjs8oMuQRt+QWALkaJVuOnTOv9lBg3FWJFDvdIWFhpA=; b=nw2JeipQM8rO5Jhw1LyK+Oc55LAzjVX1cn7tQHNTI/uRFWbyozHI3UfytTz97wT2oL pttWmd/NFxHn8QMgTYpehu8jo+ZlA5CdgRe3kLDyzPGmCDJfRt4KZkeWgfLgOshdBKoe uClHR+XS2N9Jlp3f8Bvi2Iuxdb5wiap0OVEz35eaGF8N6M66tQghgUiTqF1PwPtP+y3Y RuEVhj2wWoenZ2OCYrnFQ9F3hrA3ebVcZbluaJ4UUvDMEWsLtba38e+xx64eZ6ZO+MzO FUN2DaBWrtyH5Sbp5xX2LfxJYFezDByeCMoJX58E/bMxJ8EH+ZOCa61OhmNIZGPYt8pE m08A== MIME-Version: 1.0 Received: by 10.224.201.136 with SMTP id fa8mr23876872qab.20.1340690646100; Mon, 25 Jun 2012 23:04:06 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Mon, 25 Jun 2012 23:04:05 -0700 (PDT) In-Reply-To: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> Date: Tue, 26 Jun 2012 08:04:05 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300fafe5b6ead804c359dd6b Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 06:04:07 -0000 --20cf300fafe5b6ead804c359dd6b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 25 June 2012 17:28, R=E9mi Despr=E9s wrote: > > 2012-06-25 =E0 16:24, Wojciech Dec: > ... > > The updated MAP draft does not change the MAP architecture nor its > technical underpinnings. In fact there are no changes, bar editorial to t= he > normative parts of MAP, > > Having asked several times for a list of substantial evolutions from > previous MAP drafts, with their justifications, and having received no > answer, I see this statement as an indirect but first answer. > Woj> You were provided with an answer (pls see Ole's mail). > > But it doesn't seem acceptable (*): > - AFAIK, the added 5th parameter of basic mapping rules is more than > editorial > Woj> Please indicate what the new parameter in your opinion is. - I didn't find the equivalent of the following sentence in previous > drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in t= he > 1:1 case, and with no IPv4 address and port range configured by other > means, MUST disable its NAT44 functionality." > Woj> Well, perhaps you would like to suggest what the CPE should do in the case the CPE is issued with a default mapping rule, ie a default route in map terms, and the absence of an assigned IPv4 address or other parameters (BMR). The above appears to be reasonable behaviour. > > =3D> A carefully studied list of substantial changes MAP supporters have > found appropriate after the Paris meeting remains to be due. > Woj> Take it from the other people who have done implementations, technically there are no changes. -Woj. > > > something that is proven by existing implementations prior to this draf= t > supporting the current draft. > > Please understand that your stating that some tests (for which we don't > have detailed reports) should be considered a proof that what you say is > true, is difficult to accept. > Especially if what you say seems contradicted by a verifiable fact (see > (*) above). > > RD > > --20cf300fafe5b6ead804c359dd6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 25 June 2012 17:28, R=E9mi Despr=E9s = <despres.remi@laposte.net> wrote:

2012-06-25 =E0 16:24, Wojciech Dec:
...
> The updated MAP draft does not change the MAP archit= ecture nor its technical underpinnings. In fact there are no changes, bar e= ditorial to the normative parts of MAP,

Having asked several times for a list of substantial evolutions from = previous MAP drafts, with their justifications, and having received no answ= er, I see this statement as an indirect but first answer.

Woj> You were provided with an answer (pls see Ole's mail).=

But it doesn't seem acceptable (*):
- AFAIK, the added 5th parameter of basic mapping rules is more than editor= ial

Woj> Please indicate what the new parameter= in your opinion is.

- I didn't find the equivalent of the following sentence in previous dr= afts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by other = =A0means, MUST disable its NAT44 functionality."

Woj> Well, perhaps you would like to suggest what = the CPE should do in the case the CPE is issued with a default mapping rule= , ie a default route in map terms, and the absence of an assigned IPv4 addr= ess or other parameters (BMR). The above appears to be reasonable behaviour= .

=3D> A carefully studied list of substantial changes MAP supporters have= found appropriate after the Paris meeting remains to be due.

Woj> Take it from the other people who have done implementat= ions, technically there are no changes.

-Woj.



> something that is proven by existing implementations prior to this dra= ft supporting the current draft.

Please understand that your stating that some tests (for which we don= 't have detailed reports) should be considered a proof that what you sa= y is true, is difficult to accept.
Especially if what you say seems contradicted by a verifiable fact (see (*)= above).

RD


--20cf300fafe5b6ead804c359dd6b-- From fibrib@gmail.com Mon Jun 25 23:24: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 B506B21F855D for ; Mon, 25 Jun 2012 23:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6Zf4xeZKSHQ for ; Mon, 25 Jun 2012 23:24:10 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id A38A621F8557 for ; Mon, 25 Jun 2012 23:24:10 -0700 (PDT) Received: by qabj34 with SMTP id j34so1889817qab.4 for ; Mon, 25 Jun 2012 23:24:10 -0700 (PDT) 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 :content-type; bh=+RLD5TyGFu/LM5/4KkyEmf5F3PJLCWeRRggp4z8L0OA=; b=G1396/fY94VKS85glmZzrmoZXS93G2ZAgDL6AaFyO6NIJ3sMmNKfmYwVfBWRipq0wv cdBL+YyIGHTo4ogaP/yKJ2ml/ruklTNIzeTGuQD3l0d4HvmQfo+razdgCUeO04mtJO7w tw+qC25SPe/Xk6k4zVuX9SGFYq7fWKsh8nPefYOWg6TQMnnC+59W2H5CRWKxNkcS92ev Vi2QSgZfUekbgwJc0xteIK/7t24uwo/VwrTTPZXZBcnvOzrl+X2bP9Z/wsN29aZ64+wZ z6Sz24+d2lErbFX2t6f3xAwkku/YJiIl3V0AQh+rCeG0EYpUruFmXjxjnd4CwdnOPVJD 9QYQ== MIME-Version: 1.0 Received: by 10.229.105.100 with SMTP id s36mr6539046qco.88.1340691849967; Mon, 25 Jun 2012 23:24:09 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Mon, 25 Jun 2012 23:24:09 -0700 (PDT) In-Reply-To: <20120624054808.18705.88312.idtracker@ietfa.amsl.com> References: <20120624054808.18705.88312.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 06:24:09 +0000 Message-ID: From: Maoke To: Softwires-wg Content-Type: multipart/alternative; boundary=002354470d54787a4404c35a2544 Subject: [Softwires] Fwd: New Version Notification for draft-mdt-softwire-map-deployment-01.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, 26 Jun 2012 06:24:11 -0000 --002354470d54787a4404c35a2544 Content-Type: text/plain; charset=ISO-8859-1 hi all, we have submitted the updated version of the MAP deployment draft. As the new draft of MAP spec introduces technical uncertainties and hasn't reach the consensus. we noticed that the 1:1 mode involves different way of operation, needing to carefully investigate and to understand. Currently we exclude the 1:1 mode from the scope of MAP deployment. the major change of this version in comparison to the previous version includes: - adding of the new section 4.1: Network Models taking the example of home network, explain what is the typical use cases of MAP - editorial changes and correction of grammar/wording/spellings. we are aware that this MAP deployment draft has not reviewed by the working group, and therefore we update it still as individual draft for the time being. comments and recommendations are requested. regards, maoke ---------- Forwarded message ---------- From: Date: 2012/6/24 Subject: New Version Notification for draft-mdt-softwire-map-deployment-01.txt To: sunqiong@ctbri.com.cn Cc: simon.perreault@viagenie.ca, fibrib@gmail.com, tina.tsou.zouting@huawei.com, chengang@chinamobile.com, chunfa.sun@g.softbank.co.jp A new version of I-D, draft-mdt-softwire-map-deployment-01.txt has been successfully submitted by Qiong Sun and posted to the IETF repository. Filename: draft-mdt-softwire-map-deployment Revision: 01 Title: Mapping of Address and Port (MAP) - Deployment Considerations Creation date: 2012-06-24 WG ID: Individual Submission Number of pages: 32 URL: http://www.ietf.org/internet-drafts/draft-mdt-softwire-map-deployment-01.txt Status: http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment Htmlized: http://tools.ietf.org/html/draft-mdt-softwire-map-deployment-01 Diff: http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-map-deployment-01 Abstract: This document describes when and how an operator uses the technique of Mapping of Address and Port (MAP) for the IPv4 residual deployment in the IPv6-dominant domain. The IETF Secretariat --002354470d54787a4404c35a2544 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

hi all,=A0

we have submitt= ed the updated version of the MAP deployment draft. As the new draft of MAP= spec introduces technical uncertainties and hasn't reach the consensus= . we noticed that the 1:1 mode involves different way of operation, needing= to carefully investigate and to understand. Currently we exclude the 1:1 m= ode from the scope of MAP deployment.=A0

the major change of this version in comparison to the p= revious version includes:=A0
- adding of the new section 4.1: Net= work Models
=A0 taking the example of home network, explain what = is the typical use cases of MAP
- editorial changes and correction of grammar/wording/spellings.=A0

we are aware that this MAP deployment draft has not rev= iewed by the working group, and therefore we update it still as individual = draft for the time being. comments and recommendations are requested.=A0

regards,
maoke


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2012/6/24
Subject: New Version Notification for draft-mdt-softwire= -map-deployment-01.txt
To: sunqiong@ctbri.com.cn
Cc: simon.perreault@viagenie.ca, fibrib@gmail.com, tina.tsou.zou= ting@huawei.com, chengang@chinamobile.com, chunfa.sun@g.softbank.co.jp



A new version of I-D, draft-mdt-softwire-map-deployment-01.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mdt-softwire-map-deployment
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Mapping of Address and Port (MAP) - Deployment C= onsiderations
Creation date: =A0 2012-06-24
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 32
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.iet= f.org/internet-drafts/draft-mdt-softwire-map-deployment-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org= /doc/draft-mdt-softwire-map-deployment
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draf= t-mdt-softwire-map-deployment-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.iet= f.org/rfcdiff?url2=3Ddraft-mdt-softwire-map-deployment-01

Abstract:
=A0 This document describes when and how an operator uses the technique =A0 of Mapping of Address and Port (MAP) for the IPv4 residual deployment<= br> =A0 in the IPv6-dominant domain.




The IETF Secretariat

--002354470d54787a4404c35a2544-- From wdec.ietf@gmail.com Mon Jun 25 23:27:26 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 31BBB21F8557 for ; Mon, 25 Jun 2012 23:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE6TQivzYDSH for ; Mon, 25 Jun 2012 23:27:25 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 615D221F8539 for ; Mon, 25 Jun 2012 23:27:21 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2672921qcm.15 for ; Mon, 25 Jun 2012 23:27:20 -0700 (PDT) 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=TJzvX21xXP17CvvU6nTIaje5ZIRpE0BGI3L6AFAB6f4=; b=fLjNGhz07CV8tudkG5hEDUBIp3yE8PEtFqVSbgUw5LU3D42oDEcA3QrdnfpuViXs03 +kWApbft9+6dgh/3W8BnbrCEuGpoLfjnc+VAKpDxdW60j0NJzKBS+MXtMlXSR+sMxF1u fAMQxcyXr1GQpECmjYtWSBqNRBzmkimo+qrq06XvEDMLTKcQ4QFA0ZA1LkMWoyWeYIZp gED1xqabLm7Z266E3N0uANf0wwU01tGoulfgOOfXrqFoiTc+4O4KIRvM/uCovCAru6qI CZR5jlyMqpqPJrt4rniF6+6WjMGoBd4ZqScWectc4NIqO9ntyABi8DxPO5FQV+zlQOej WeCA== MIME-Version: 1.0 Received: by 10.224.200.6 with SMTP id eu6mr23938100qab.33.1340692040679; Mon, 25 Jun 2012 23:27:20 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Mon, 25 Jun 2012 23:27:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 08:27:20 +0200 Message-ID: From: Wojciech Dec To: Qiong Content-Type: multipart/alternative; boundary=20cf300fb0fdd67f2004c35a30d3 Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 06:27:26 -0000 --20cf300fb0fdd67f2004c35a30d3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, IMO The MAP solution fullfills most, if not all of the points in the stateless motivations draft. The fact that it can do more, or can be used differently doesn't alter the solution. Now, it would appear that you're arbitrarily trying to make sure that MAP does not solve a problem you care about. This would require a change to the MAP spec, and all it's predecessors, and also implementations which pre date this draft. It also raises the question of what should the solution to this problem, which you appear to exclusively intend to be "another draft" ( that likely happens to be your draft, but that is probably just a mere coincidence). If the WG wants multiple solutions to the same problem, that's for the WG to decide based on some rational argument. Breaking or changing a solution just so that another solution can be given "exclusivity" to some problem solution seems not rational. The argument below, and it's a repeat of what you've stated earlier, does not appear to be technically motivated. I would like to bring the discussion to a technical level, but with you continuing to voice rhetoric and not addressing the key question of what is the technical problem, it appears difficult to proceed. Regards, Woj. On 24 June 2012 07:35, Qiong wrote: > Hi all, > > > As we all know, once an individual draft is adopted as a WG draft, it is = owned by the whole WG, rather than just the editors. Just as Remi said, the= normal procedure to follow is to reach WG consensus _before_ posting a new= ly edited version. > > From draft-mdt-softwire-mapping-address-and-port-03 to draft-ietf-softwir= e-map-00, there are several changes between them. In particular, the newly = introduced "1:1 mode", which decouples IPv4 and IPv6 addressing, has > never been > discussed openly in the WG mailing list, or even in the MAP design team e= ither. > > > Actually, this "1:1 mode" is against the stateless-4v6-motivation draft. = The motivation draft has clearly defines the "Stateless 4/6 solution" as fo= llows: > > > Stateless 4/6 solution denotes a solution which does not require any per-= user state (see Section 2.3 of [RFC1958]) to be maintained by any IP addres= s sharing function in the Service Provider's network. This category of solu= tions assumes a dependency between an IPv6 prefix and IPv4 address. > > > AFAIK what the WG has adopted MAP related draft is draft-mdt-softwire-map= ping-address-and-port-03, NOT draft-ietf-softwire-map-00. And the stateless= solution should =93response to the solution motivation document=94 accordi= ng to the Softwire charter. That means draft-ietf-softwire-map-00 IS NOT QU= ALIFIED to be a WG draft. > > > We can all recall that our softwire WG has worked on stateless solutions = for more than one and a half years, and we have achieved a lot of work whic= h has been documented in charter, stateless motivation, 4rd-varients, MAP-0= 3, etc. AFAIK all the authors have kept the basic "stateless" principle and= the MAP design team is also working on it together to find a better algori= thm, address format, etc. So it is really not appropriate to make such chan= ges when MAP is adopted as a WG item in such a short time. > > From this perspective, draft-ietf-softwire-map-00 can only be regarded as= draft-XX-softwire-mapping-address-and-port-04. It is not even > the output of MAP design team. > > Best wishes > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > > --20cf300fb0fdd67f2004c35a30d3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

IMO The MAP solution fullfills most, if not all of the points in= the stateless motivations draft. The fact that it can do more, or can be u= sed differently doesn't alter the solution.
Now, it would appear th= at you're arbitrarily trying to make sure that MAP does not solve a pro= blem you care about. This would require a change to the MAP spec, and all i= t's predecessors, and also implementations which pre date this draft. <= br> It also raises the question of what should the solution to this problem, wh= ich you appear to exclusively intend to be "another draft" ( that= likely happens to be your draft, but that is probably just a mere coincide= nce).
If the WG wants multiple solutions to the same problem, that's for the = WG to decide based on some rational argument. Breaking or changing a soluti= on just so that another solution can be given "exclusivity" to so= me problem solution seems not rational.

The argument below, and it's a repeat of what you've stated ear= lier, does not appear to be technically motivated. I would like to bring th= e discussion to a=20 technical level, but with you continuing to voice rhetoric and not addressi= ng the key question of what is the technical problem, it appears difficult to proceed.

Regards,Woj.

On 24 June 2012 07:35, Qiong <bi= ngxuere@gmail.com> wrote:
Hi=A0all,
=A0
As=A0we=A0all=A0know,=A0once=A0an=A0individual=A0draft=A0is=A0adopted= =A0as=A0a=A0WG=A0draft,=A0it=A0is=A0owned=A0by=A0the=A0whole=A0WG,=A0rather= =A0than=A0just=A0the=A0editors.=A0Just=A0as=A0Remi=A0said,=A0the=A0normal= =A0procedure=A0to=A0follow=A0is=A0to=A0reach=A0WG=A0consensus=A0_before_=A0= posting=A0a=A0newly=A0edited=A0version.=A0
=A0
From=A0draft-mdt-softwire-mapping-address-and-port-03=A0to=A0draft-iet= f-softwire-map-00,=A0there=A0are=A0several=A0changes=A0between=A0them.=A0In= =A0particular,=A0the=A0newly=A0introduced=A0"1:1=A0mode",=A0which= =A0decouples=A0IPv4=A0and=A0IPv6=A0addressing,=A0has never been discussed= =A0openly=A0in=A0the=A0WG=A0mailing=A0list,=A0or=A0even=A0in=A0the=A0MAP=A0= design=A0team=A0either.
=A0
Actually,=A0this=A0"1:1=A0mode"=A0is=A0against=A0the=A0state= less-4v6-motivation=A0draft.=A0The=A0motivation=A0draft=A0has=A0clearly=A0d= efines=A0the=A0"Stateless=A04/6=A0solution"=A0as=A0follows:

Stateless=A04/6=A0solution=A0denotes=A0a=A0solution=A0which=A0does= =A0not=A0require=A0any=A0per-user=A0state=A0(see=A0Section=A02.3=A0of=A0[RF= C1958])=A0to=A0be=A0maintained=A0by=A0any=A0IP=A0address=A0sharing=A0functi= on=A0in=A0the=A0Service=A0Provider's=A0network.=A0This=A0category=A0of= =A0solutions=A0assumes=A0a=A0dependency=A0between=A0an=A0IPv6=A0prefix=A0an= d=A0IPv4=A0address.
=A0
AFAIK=A0what=A0the=A0WG=A0has=A0adopted=A0MAP=A0related=A0draft=A0is= =A0draft-mdt-softwire-mapping-address-and-port-03,=A0NOT=A0draft-ietf-softw= ire-map-00.=A0And=A0the=A0stateless=A0solution=A0should=A0=93response=A0to= =A0the=A0solution=A0motivation=A0document=94=A0according=A0to=A0the=A0Softw= ire=A0charter.=A0That=A0means=A0draft-ietf-softwire-map-00=A0IS=A0NOT=A0QUA= LIFIED=A0to=A0be=A0a=A0WG=A0draft.=A0
=A0
We=A0can=A0all=A0recall=A0that=A0our=A0softwire=A0WG=A0has=A0worked=A0= on=A0stateless=A0solutions=A0for=A0more=A0than=A0one=A0and=A0a=A0half=A0yea= rs,=A0and=A0we=A0have=A0achieved=A0a=A0lot=A0of=A0work=A0which=A0has=A0been= =A0documented=A0in=A0charter,=A0stateless=A0motivation,=A04rd-varients,=A0M= AP-03,=A0etc.=A0AFAIK=A0all=A0the=A0authors=A0have=A0kept=A0the=A0basic=A0&= quot;stateless"=A0principle=A0and=A0the=A0MAP=A0design=A0team=A0is=A0a= lso=A0working=A0on=A0it=A0together=A0to=A0find=A0a=A0better=A0algorithm,=A0= address=A0format,=A0etc.=A0So=A0it=A0is=A0really=A0not=A0appropriate=A0to= =A0make=A0such=A0changes=A0when=A0MAP=A0is=A0adopted=A0as=A0a=A0WG=A0item= =A0in=A0such=A0a=A0short=A0time.=A0
=A0
From=A0this=A0perspective,=A0draft-ietf-softwire-map-00=A0can=A0only= =A0be=A0regarded=A0as=A0draft-XX-softwire-mapping-address-and-port-04.=A0It= =A0is=A0not=A0even the output of=A0MAP=A0design=A0team.

Best= wishes

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=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 sourc= e code:
lightweight 4over6: http://sourceforge.net/projects/laft6/<= br> 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


--20cf300fb0fdd67f2004c35a30d3-- From sunqi.csnet.thu@gmail.com Mon Jun 25 23:37: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 63F7021F855E for ; Mon, 25 Jun 2012 23:37:48 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzRTZWzGFFn0 for ; Mon, 25 Jun 2012 23:37:47 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE6C21F855D for ; Mon, 25 Jun 2012 23:37:47 -0700 (PDT) Received: by dacx6 with SMTP id x6so6418648dac.31 for ; Mon, 25 Jun 2012 23:37:47 -0700 (PDT) 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=RESb+nUsi0oGbggRqfYpetqCRGlbUFh2KbbO3GKYEsU=; b=xt04QgtUvt20/l8VtdhrbQ75uClIH7LXQdGUZANUNfUbPZtZFqa1eeviLj8srtZs8m cNUeLPYphwCj6qP8vNWbj7YTnHmt28Yd++vDBF0755MmPUXf9tsnG65Pe/Gxhrt5YOus 09zaYxMw22T6KolJUH5NDZelpuD+oM8qJnHTznUYfU0bvmCv8K6b6NTYuMpEDtPpU8uo 89TXEf2z/IUmiifT+WjEoN1nRwad+82rxK5M26f7ALoDQX7lTR+OIh8Lts+77HViIRR0 RyydNkfZQeAisMfZjvJL9xpqD/MC50EsRLsIrosX7bp0UurtoW/rlcxA7JofqGoi4eIK 9TBQ== MIME-Version: 1.0 Received: by 10.68.233.201 with SMTP id ty9mr48795979pbc.34.1340692667121; Mon, 25 Jun 2012 23:37:47 -0700 (PDT) Received: by 10.143.7.3 with HTTP; Mon, 25 Jun 2012 23:37:46 -0700 (PDT) In-Reply-To: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> Date: Tue, 26 Jun 2012 14:37:46 +0800 Message-ID: From: Qi Sun To: Peng Wu Content-Type: multipart/alternative; boundary=047d7b33d5fc2d400704c35a5696 Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 06:37:48 -0000 --047d7b33d5fc2d400704c35a5696 Content-Type: text/plain; charset=ISO-8859-1 +1 support. I respect what the MAP authors have worked on. But besides what Peng has said, could you clarify where the so called "ietf"-map-00 achieves consensus? Qi Sun On Tue, Jun 26, 2012 at 12:07 PM, Peng Wu wrote: > Woj, > > On Mon, Jun 25, 2012 at 10:24 PM, Wojciech Dec > wrote: > > Hi, > > > > taking a step back to discuss some items in more detail, and hopefully > move > > this discussion forward: > > > > 1. Domain size > > The MAP architecture does not prescribe the size of a domain, and neither > > does it prescribe the number of rules to be used. There is nothing in the > > technology, except vendor implementation limits or practical sense (or > > both), to prevent MAP domains from defining 1 domain = 1 CPE. This was a > day > > 1 characteristic of MAP drafts. > Yes from the theoretical view you could. But that's not the exact 1:1 > mode the "ietf-map-00" described. You have to change the specification > and twist the mechanism definiation to particularly support the 1:1 > mode. > > > Choosing to deploy or implement MAP with a configuration supporting 1 > rule, > > 100 rules or 100k rules or domains is a vendor's and/or operator's > choice. > > Nobody is stating that deployment is to be limited to X rules, nor that a > > near infinite number of rules is reasonable. These are general points > that > > apply to DS-lite state as well as the "Light Weight 4 over 6" or > "stateless > > deterministic NAT", and pretty much any technology for that matter. > > > > 2. Stateless DOES NOT mean configuration-less > > There appears to be confusion between the concept of stateless and > > configuration-less. MAP domains are based on configured rules, that are > > provisioned/applied through means that are currently outside the scope of > > Softwire drafts - this is configuration state, and this was and > continues to > > be a characteristic of MAP. > If you have per-user specific configuration, that definitely changes > the operation model. > > > Further more, unlike some of the other proposals, MAP allows to optimize > the > > amount of configuration needed in cases where this is viable. In other > > words, MAP does NOT exclusively force 1:1 rule configuration, but also > > allows N:1. > That's not what is discussed in this thread at all... > > > > 3. Stateless has no data plane induced state > > A major difference between stateless (eg MAP) and stateful (eg Carrier > Grade > > NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic > > core node forwarding state that is directly driven by user data-plane > > traffic (eg new IP flows). MAP does not rely on such dynamic state, never > > did. > I think you only mean per-session stateful. For per-user stateful > mechanisms, you run the provisioning process to avoid state creating > from the data plane. That's one of the essential design goals and > benifits of the per-user stateful mechanisms and reflected in > lw4over6. > > > > > 4. No change of MAP spec > > The updated MAP draft does not change the MAP architecture nor its > technical > > underpinnings. In fact there are no changes, bar editorial to the > normative > > parts of MAP, something that is proven by existing implementations prior > to > > this draft supporting the current draft. A few individuals appear to > object > > to new descriptive text which highlights the usage of MAP, eg in 1:1. > > Removing that text will not change the matter that MAP allows such usage. > > Prohibiting such use by specification would actually require a spec > change, > > besides being unreasonable. > Sorry, no. You need to change specifications, and you need to twist > the definations of the terminology. > For example, you need to explicitly provisio the port set information, > which is not the usual case at all. > > > > > 5. What is the problem? > > We're pleased to see a growing understanding of MAP's applicability to > > solve problems, incl v4-v6 address independence, when needed. Given that > the > > emails on this thread do not appear to bring forward any technical issues > > with the MAP solution, could we know WHY we need other solutions to the > > problem, or what is the problem that remains to be solved? > The problem is that there are apparently three types of solutions with > perspective application scenarios, while the MAP solution, originally > strongly customized for the pure stateless scenario, is now twisting > itself in a somehow weired way, dropping the essential feature of > statelessness, to include the per-user state/mapping scenario which > can be solved by a more pure and clear solution. > > > Taking the liberty to speak on behalf of the other MAP authors, I would > like > > to say that we all remain open for collaboration with all WG members in > > terms of arriving at a minimal set of reasonable solutions that solve > > problems that the community cares about. We also trust that our renewed > WG > > leadership will finally help us all in getting there. > No objection to MAP at all, AS LONG AS it follows the original, > suitable problem space which it is expected to developed for. > --047d7b33d5fc2d400704c35a5696 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 support.=A0
I respect what the MAP authors have worked on. But besid= es what Peng has said, could you clarify where the so called "ietf&quo= t;-map-00 achieves consensus?

Qi Sun

On Tue, Jun 26, 2012 at 12:07 PM, Peng Wu <pengwu.thu@gmail.com>= wrote:
Woj,

On Mon, Jun 25, 2012 at 10:24 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Hi,
>
> taking a step back to discuss some items in more detail, and hopefully= move
> this discussion forward:
>
> 1. Domain size
> The MAP architecture does not prescribe the size of a domain, and neit= her
> does it prescribe the number of rules to be used. There is nothing in = the
> technology, except vendor implementation limits or practical sense (or=
> both), to prevent MAP domains from defining 1 domain =3D 1 CPE. This w= as a day
> 1 characteristic of MAP drafts.
Yes from the theoretical view you could. But that's not the exact= 1:1
mode the "ietf-map-00" described. You have to change the specific= ation
and twist the mechanism definiation to particularly support the 1:1
mode.

> Choosing to deploy or implement MAP with a configuration supporting 1 = rule,
> 100 rules or 100k rules or domains is a vendor's and/or operator&#= 39;s choice.
> Nobody is stating that deployment is to be limited to X rules, nor tha= t a
> near infinite number of rules is reasonable. These are general points = that
> apply to DS-lite state as well as the "Light Weight 4 over 6"= ; or "stateless
> deterministic NAT", and pretty much any technology for that matte= r.
>
> 2. Stateless DOES NOT mean configuration-less
> There appears to be confusion between the concept of stateless and
> configuration-less. MAP domains are based on configured rules, that ar= e
> provisioned/applied through means that are currently outside the scope= of
> Softwire drafts - this is configuration state, and this was and contin= ues to
> be a characteristic of MAP.
If you have =A0per-user specific configuration, that definitely chang= es
the operation model.

> Further more, unlike some of the other proposals, MAP allows to optimi= ze the
> amount of configuration needed in cases where this is viable. In other=
> words, MAP does NOT exclusively force 1:1 rule configuration, but also=
> allows N:1.
That's not what is discussed in this thread at all...
>
> 3. Stateless has no data plane induced state
> A major difference between stateless (eg MAP) and stateful (eg Carrier= Grade
> NAT44/Ds-Lite) solutions is that the latter are characterised by dynam= ic
> core node forwarding state that is directly driven by user data-plane<= br> > traffic (eg new IP flows). MAP does not rely on such dynamic state, ne= ver
> did.
I think you only mean per-session stateful. For per-user stateful
mechanisms, you run the provisioning process to avoid state creating
from the data plane. That's one of the essential design goals and
benifits of the per-user stateful mechanisms and reflected in
lw4over6.

>
> 4. No change of MAP spec
> The updated MAP draft does not change the MAP architecture nor its tec= hnical
> underpinnings. In fact there are no changes, bar editorial to the norm= ative
> parts of MAP, something that is proven by existing implementations pri= or to
> this draft supporting the current draft. A few individuals appear to o= bject
> to new descriptive text which highlights the usage of MAP, eg in 1:1.<= br> > Removing that text will not change the matter that MAP allows such usa= ge.
> Prohibiting such use by specification would actually require a spec ch= ange,
> besides being unreasonable.
Sorry, no. You need to change specifications, and you need to twist the definations of the terminology.
For example, you need to explicitly provisio the port set information,
which is not the usual case at all.

>
> 5. What is the problem?
> We're=A0 pleased to see a growing understanding of MAP's appli= cability to
> solve problems, incl v4-v6 address independence, when needed. Given th= at the
> emails on this thread do not appear to bring forward any technical iss= ues
> with the MAP solution, could we know WHY we need other solutions to th= e
> problem, or what is the problem that remains to be solved?
The problem is that there are apparently three types of solutions wit= h
perspective application scenarios, while the MAP solution, originally
strongly customized for the pure stateless scenario, is now twisting
itself in a somehow weired way, dropping the essential feature of
statelessness, to include the per-user state/mapping scenario which
can be solved by a more pure and clear solution.

> Taking the liberty to speak on behalf of the other MAP authors, I woul= d like
> to say that we all remain open for collaboration with all WG members i= n
> terms of arriving at a minimal set of reasonable solutions that solve<= br> > problems that the community cares about. We also trust that our renewe= d WG
> leadership will finally help us all in getting there.
No objection to MAP at all, AS LONG AS =A0it follows the original, suitable problem space which it is expected to developed for.

--047d7b33d5fc2d400704c35a5696-- From jiangdong345@gmail.com Mon Jun 25 23:49: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 26BF521F8550 for ; Mon, 25 Jun 2012 23:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rF0dY5hIHRxd for ; Mon, 25 Jun 2012 23:49:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1880621F8541 for ; Mon, 25 Jun 2012 23:49:04 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7713925pbc.31 for ; Mon, 25 Jun 2012 23:49:03 -0700 (PDT) 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=kQG75+SVL0v/3ZT+/9+AtTfyOPt38j9gKUOKD3MHr2k=; b=kfVPJ5ocsg2PYEJEA/UZfZ7nGFMc4WPKNSdN5TjFV/xM+na3tDrgSfpOpgUP3cJsgm ygiKWbKhmcuKjB4j/2uZ+hhQw7PkLxJJ7UpRcUtGtJvT/B+UhkhcUEZBvD3zCqG2L+gZ xOPYwUl/g0/pZbHzza5D5mFcNfFiZfC9GZzuPWNGtPXu69dHjA/q+WXlAXhAoibNEFZq F1ntYEUxMhI1jTxJaiqMxWCVpu4QIGNpz6bC2etOAhQQLZIgplfN+mnrg597dyyOs26p EJO/8G1IawXMsVNo25GMWrnC1QDbDOubItqPWNYoJyZY8UbiUZme/wsKA6LxBnXIhCAt yVkw== Received: by 10.68.190.102 with SMTP id gp6mr49097119pbc.5.1340693343739; Mon, 25 Jun 2012 23:49:03 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id rv9sm10949734pbc.43.2012.06.25.23.48.59 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 23:49:02 -0700 (PDT) Date: Tue, 26 Jun 2012 14:49:00 +0800 From: "Jiang Dong" To: "Peng Wu" , "Wojciech Dec" References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> , X-Priority: 3 X-GUID: 9AD01DC7-2977-4DC3-8506-C6E2D731E0E7 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012062614485617056252@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart824065370664_=----" Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 06:49:05 -0000 This is a multi-part message in MIME format. ------=_001_NextPart824065370664_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIFBlbmcsDQoNCkkgdG90YWxseSBhZ3JlZSB3aXRoIHlvdS4NCg0KQUZBSUssIHRoZSBvcmln aW5hbGx5IE1BUCBkcmFmdCBpcyBkZXNpZ25lZCB0byBzb2x2ZSB0aGUgc3RhdGVsZXNzIHNjZW5h cmlvcyBpbiBhIElQdjQgaW5mbyBlbWJlZGRlZCB3YXkuIE5vdyBvbmUgZGF5LCB0aGUgMToxIG1v ZGUgd2FzIHN1ZGRlbmx5IGFkZGVkIGJ5IHNldHRpbmcgdGhlIEVBIGJpdHMgdG8gemVybyB3aXRo b3V0IGFueSBjb25zZW50IGZyb20gdGhlIFdHLCB3aGljaCBhbHNvIGFiYW5kb25lZCB0aGUgZXNz ZW5jZSBvZiBvcmlnaW5hbCBNQVAuDQoNClNpbmNlIEkgY2Fubm90IGZpbmQgYW55IHdvcmRzIGlu IGVhcmxpZXIgTUFQIGRyYWZ0cyB0YWxraW5nIGFib3V0IDE6MSBtb2RlLCB3aGF0IEkgY2FuIGlt YWdpbmUgaXMgdGhhdCB0aGUgdHdvIHllYXJzIGhhcmQgd29ya3MgYnkgdGhlIHJlYWwgMToxIG1h cHBpbmcgZ3V5cyBhcmUgaWdub3JlZCAgaW4gdGhlIG5ldyBNQVAgZHJhZnQuDQoNCkJlc3QgUmVn YXJkcyENCkppYW5nIERvbmcNCg0KRnJvbTogUGVuZyBXdQ0KRGF0ZTogMjAxMi0wNi0yNiAxMjow Nw0KVG86IFdvamNpZWNoIERlYw0KQ0M6IHNvZnR3aXJlcyBXRzsgWW9uZyBDdWkNClN1YmplY3Q6 IFJlOiBbU29mdHdpcmVzXSBbU29mdHdpcmVdIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwIGRv ZXMgTk9UIHJlZmxlY3QgdGhlIGNvbnNlbnN1cyBmcm9tIHRoZSBXRw0KV29qLA0KDQpPbiBNb24s IEp1biAyNSwgMjAxMiBhdCAxMDoyNCBQTSwgV29qY2llY2ggRGVjIDx3ZGVjLmlldGZAZ21haWwu Y29tPiB3cm90ZToNCj4gSGksDQo+DQo+IHRha2luZyBhIHN0ZXAgYmFjayB0byBkaXNjdXNzIHNv bWUgaXRlbXMgaW4gbW9yZSBkZXRhaWwsIGFuZCBob3BlZnVsbHkgbW92ZQ0KPiB0aGlzIGRpc2N1 c3Npb24gZm9yd2FyZDoNCj4NCj4gMS4gRG9tYWluIHNpemUNCj4gVGhlIE1BUCBhcmNoaXRlY3R1 cmUgZG9lcyBub3QgcHJlc2NyaWJlIHRoZSBzaXplIG9mIGEgZG9tYWluLCBhbmQgbmVpdGhlcg0K PiBkb2VzIGl0IHByZXNjcmliZSB0aGUgbnVtYmVyIG9mIHJ1bGVzIHRvIGJlIHVzZWQuIFRoZXJl IGlzIG5vdGhpbmcgaW4gdGhlDQo+IHRlY2hub2xvZ3ksIGV4Y2VwdCB2ZW5kb3IgaW1wbGVtZW50 YXRpb24gbGltaXRzIG9yIHByYWN0aWNhbCBzZW5zZSAob3INCj4gYm90aCksIHRvIHByZXZlbnQg TUFQIGRvbWFpbnMgZnJvbSBkZWZpbmluZyAxIGRvbWFpbiA9IDEgQ1BFLiBUaGlzIHdhcyBhIGRh eQ0KPiAxIGNoYXJhY3RlcmlzdGljIG9mIE1BUCBkcmFmdHMuDQpZZXMgZnJvbSB0aGUgdGhlb3Jl dGljYWwgdmlldyB5b3UgY291bGQuIEJ1dCB0aGF0J3Mgbm90IHRoZSBleGFjdCAxOjENCm1vZGUg dGhlICJpZXRmLW1hcC0wMCIgZGVzY3JpYmVkLiBZb3UgaGF2ZSB0byBjaGFuZ2UgdGhlIHNwZWNp ZmljYXRpb24NCmFuZCB0d2lzdCB0aGUgbWVjaGFuaXNtIGRlZmluaWF0aW9uIHRvIHBhcnRpY3Vs YXJseSBzdXBwb3J0IHRoZSAxOjENCm1vZGUuDQoNCj4gQ2hvb3NpbmcgdG8gZGVwbG95IG9yIGlt cGxlbWVudCBNQVAgd2l0aCBhIGNvbmZpZ3VyYXRpb24gc3VwcG9ydGluZyAxIHJ1bGUsDQo+IDEw MCBydWxlcyBvciAxMDBrIHJ1bGVzIG9yIGRvbWFpbnMgaXMgYSB2ZW5kb3IncyBhbmQvb3Igb3Bl cmF0b3IncyBjaG9pY2UuDQo+IE5vYm9keSBpcyBzdGF0aW5nIHRoYXQgZGVwbG95bWVudCBpcyB0 byBiZSBsaW1pdGVkIHRvIFggcnVsZXMsIG5vciB0aGF0IGENCj4gbmVhciBpbmZpbml0ZSBudW1i ZXIgb2YgcnVsZXMgaXMgcmVhc29uYWJsZS4gVGhlc2UgYXJlIGdlbmVyYWwgcG9pbnRzIHRoYXQN Cj4gYXBwbHkgdG8gRFMtbGl0ZSBzdGF0ZSBhcyB3ZWxsIGFzIHRoZSAiTGlnaHQgV2VpZ2h0IDQg b3ZlciA2IiBvciAic3RhdGVsZXNzDQo+IGRldGVybWluaXN0aWMgTkFUIiwgYW5kIHByZXR0eSBt dWNoIGFueSB0ZWNobm9sb2d5IGZvciB0aGF0IG1hdHRlci4NCj4NCj4gMi4gU3RhdGVsZXNzIERP RVMgTk9UIG1lYW4gY29uZmlndXJhdGlvbi1sZXNzDQo+IFRoZXJlIGFwcGVhcnMgdG8gYmUgY29u ZnVzaW9uIGJldHdlZW4gdGhlIGNvbmNlcHQgb2Ygc3RhdGVsZXNzIGFuZA0KPiBjb25maWd1cmF0 aW9uLWxlc3MuIE1BUCBkb21haW5zIGFyZSBiYXNlZCBvbiBjb25maWd1cmVkIHJ1bGVzLCB0aGF0 IGFyZQ0KPiBwcm92aXNpb25lZC9hcHBsaWVkIHRocm91Z2ggbWVhbnMgdGhhdCBhcmUgY3VycmVu dGx5IG91dHNpZGUgdGhlIHNjb3BlIG9mDQo+IFNvZnR3aXJlIGRyYWZ0cyAtIHRoaXMgaXMgY29u ZmlndXJhdGlvbiBzdGF0ZSwgYW5kIHRoaXMgd2FzIGFuZCBjb250aW51ZXMgdG8NCj4gYmUgYSBj aGFyYWN0ZXJpc3RpYyBvZiBNQVAuDQpJZiB5b3UgaGF2ZSAgcGVyLXVzZXIgc3BlY2lmaWMgY29u ZmlndXJhdGlvbiwgdGhhdCBkZWZpbml0ZWx5IGNoYW5nZXMNCnRoZSBvcGVyYXRpb24gbW9kZWwu DQoNCj4gRnVydGhlciBtb3JlLCB1bmxpa2Ugc29tZSBvZiB0aGUgb3RoZXIgcHJvcG9zYWxzLCBN QVAgYWxsb3dzIHRvIG9wdGltaXplIHRoZQ0KPiBhbW91bnQgb2YgY29uZmlndXJhdGlvbiBuZWVk ZWQgaW4gY2FzZXMgd2hlcmUgdGhpcyBpcyB2aWFibGUuIEluIG90aGVyDQo+IHdvcmRzLCBNQVAg ZG9lcyBOT1QgZXhjbHVzaXZlbHkgZm9yY2UgMToxIHJ1bGUgY29uZmlndXJhdGlvbiwgYnV0IGFs c28NCj4gYWxsb3dzIE46MS4NClRoYXQncyBub3Qgd2hhdCBpcyBkaXNjdXNzZWQgaW4gdGhpcyB0 aHJlYWQgYXQgYWxsLi4uDQo+DQo+IDMuIFN0YXRlbGVzcyBoYXMgbm8gZGF0YSBwbGFuZSBpbmR1 Y2VkIHN0YXRlDQo+IEEgbWFqb3IgZGlmZmVyZW5jZSBiZXR3ZWVuIHN0YXRlbGVzcyAoZWcgTUFQ KSBhbmQgc3RhdGVmdWwgKGVnIENhcnJpZXIgR3JhZGUNCj4gTkFUNDQvRHMtTGl0ZSkgc29sdXRp b25zIGlzIHRoYXQgdGhlIGxhdHRlciBhcmUgY2hhcmFjdGVyaXNlZCBieSBkeW5hbWljDQo+IGNv cmUgbm9kZSBmb3J3YXJkaW5nIHN0YXRlIHRoYXQgaXMgZGlyZWN0bHkgZHJpdmVuIGJ5IHVzZXIg ZGF0YS1wbGFuZQ0KPiB0cmFmZmljIChlZyBuZXcgSVAgZmxvd3MpLiBNQVAgZG9lcyBub3QgcmVs eSBvbiBzdWNoIGR5bmFtaWMgc3RhdGUsIG5ldmVyDQo+IGRpZC4NCkkgdGhpbmsgeW91IG9ubHkg bWVhbiBwZXItc2Vzc2lvbiBzdGF0ZWZ1bC4gRm9yIHBlci11c2VyIHN0YXRlZnVsDQptZWNoYW5p c21zLCB5b3UgcnVuIHRoZSBwcm92aXNpb25pbmcgcHJvY2VzcyB0byBhdm9pZCBzdGF0ZSBjcmVh dGluZw0KZnJvbSB0aGUgZGF0YSBwbGFuZS4gVGhhdCdzIG9uZSBvZiB0aGUgZXNzZW50aWFsIGRl c2lnbiBnb2FscyBhbmQNCmJlbmlmaXRzIG9mIHRoZSBwZXItdXNlciBzdGF0ZWZ1bCBtZWNoYW5p c21zIGFuZCByZWZsZWN0ZWQgaW4NCmx3NG92ZXI2Lg0KDQo+DQo+IDQuIE5vIGNoYW5nZSBvZiBN QVAgc3BlYw0KPiBUaGUgdXBkYXRlZCBNQVAgZHJhZnQgZG9lcyBub3QgY2hhbmdlIHRoZSBNQVAg YXJjaGl0ZWN0dXJlIG5vciBpdHMgdGVjaG5pY2FsDQo+IHVuZGVycGlubmluZ3MuIEluIGZhY3Qg dGhlcmUgYXJlIG5vIGNoYW5nZXMsIGJhciBlZGl0b3JpYWwgdG8gdGhlIG5vcm1hdGl2ZQ0KPiBw YXJ0cyBvZiBNQVAsIHNvbWV0aGluZyB0aGF0IGlzIHByb3ZlbiBieSBleGlzdGluZyBpbXBsZW1l bnRhdGlvbnMgcHJpb3IgdG8NCj4gdGhpcyBkcmFmdCBzdXBwb3J0aW5nIHRoZSBjdXJyZW50IGRy YWZ0LiBBIGZldyBpbmRpdmlkdWFscyBhcHBlYXIgdG8gb2JqZWN0DQo+IHRvIG5ldyBkZXNjcmlw dGl2ZSB0ZXh0IHdoaWNoIGhpZ2hsaWdodHMgdGhlIHVzYWdlIG9mIE1BUCwgZWcgaW4gMToxLg0K PiBSZW1vdmluZyB0aGF0IHRleHQgd2lsbCBub3QgY2hhbmdlIHRoZSBtYXR0ZXIgdGhhdCBNQVAg YWxsb3dzIHN1Y2ggdXNhZ2UuDQo+IFByb2hpYml0aW5nIHN1Y2ggdXNlIGJ5IHNwZWNpZmljYXRp b24gd291bGQgYWN0dWFsbHkgcmVxdWlyZSBhIHNwZWMgY2hhbmdlLA0KPiBiZXNpZGVzIGJlaW5n IHVucmVhc29uYWJsZS4NClNvcnJ5LCBuby4gWW91IG5lZWQgdG8gY2hhbmdlIHNwZWNpZmljYXRp b25zLCBhbmQgeW91IG5lZWQgdG8gdHdpc3QNCnRoZSBkZWZpbmF0aW9ucyBvZiB0aGUgdGVybWlu b2xvZ3kuDQpGb3IgZXhhbXBsZSwgeW91IG5lZWQgdG8gZXhwbGljaXRseSBwcm92aXNpbyB0aGUg cG9ydCBzZXQgaW5mb3JtYXRpb24sDQp3aGljaCBpcyBub3QgdGhlIHVzdWFsIGNhc2UgYXQgYWxs Lg0KDQo+DQo+IDUuIFdoYXQgaXMgdGhlIHByb2JsZW0/DQo+IFdlJ3JlICBwbGVhc2VkIHRvIHNl ZSBhIGdyb3dpbmcgdW5kZXJzdGFuZGluZyBvZiBNQVAncyBhcHBsaWNhYmlsaXR5IHRvDQo+IHNv bHZlIHByb2JsZW1zLCBpbmNsIHY0LXY2IGFkZHJlc3MgaW5kZXBlbmRlbmNlLCB3aGVuIG5lZWRl ZC4gR2l2ZW4gdGhhdCB0aGUNCj4gZW1haWxzIG9uIHRoaXMgdGhyZWFkIGRvIG5vdCBhcHBlYXIg dG8gYnJpbmcgZm9yd2FyZCBhbnkgdGVjaG5pY2FsIGlzc3Vlcw0KPiB3aXRoIHRoZSBNQVAgc29s dXRpb24sIGNvdWxkIHdlIGtub3cgV0hZIHdlIG5lZWQgb3RoZXIgc29sdXRpb25zIHRvIHRoZQ0K PiBwcm9ibGVtLCBvciB3aGF0IGlzIHRoZSBwcm9ibGVtIHRoYXQgcmVtYWlucyB0byBiZSBzb2x2 ZWQ/DQpUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZXJlIGFyZSBhcHBhcmVudGx5IHRocmVlIHR5cGVz IG9mIHNvbHV0aW9ucyB3aXRoDQpwZXJzcGVjdGl2ZSBhcHBsaWNhdGlvbiBzY2VuYXJpb3MsIHdo aWxlIHRoZSBNQVAgc29sdXRpb24sIG9yaWdpbmFsbHkNCnN0cm9uZ2x5IGN1c3RvbWl6ZWQgZm9y IHRoZSBwdXJlIHN0YXRlbGVzcyBzY2VuYXJpbywgaXMgbm93IHR3aXN0aW5nDQppdHNlbGYgaW4g YSBzb21laG93IHdlaXJlZCB3YXksIGRyb3BwaW5nIHRoZSBlc3NlbnRpYWwgZmVhdHVyZSBvZg0K c3RhdGVsZXNzbmVzcywgdG8gaW5jbHVkZSB0aGUgcGVyLXVzZXIgc3RhdGUvbWFwcGluZyBzY2Vu YXJpbyB3aGljaA0KY2FuIGJlIHNvbHZlZCBieSBhIG1vcmUgcHVyZSBhbmQgY2xlYXIgc29sdXRp b24uDQoNCj4gVGFraW5nIHRoZSBsaWJlcnR5IHRvIHNwZWFrIG9uIGJlaGFsZiBvZiB0aGUgb3Ro ZXIgTUFQIGF1dGhvcnMsIEkgd291bGQgbGlrZQ0KPiB0byBzYXkgdGhhdCB3ZSBhbGwgcmVtYWlu IG9wZW4gZm9yIGNvbGxhYm9yYXRpb24gd2l0aCBhbGwgV0cgbWVtYmVycyBpbg0KPiB0ZXJtcyBv ZiBhcnJpdmluZyBhdCBhIG1pbmltYWwgc2V0IG9mIHJlYXNvbmFibGUgc29sdXRpb25zIHRoYXQg c29sdmUNCj4gcHJvYmxlbXMgdGhhdCB0aGUgY29tbXVuaXR5IGNhcmVzIGFib3V0LiBXZSBhbHNv IHRydXN0IHRoYXQgb3VyIHJlbmV3ZWQgV0cNCj4gbGVhZGVyc2hpcCB3aWxsIGZpbmFsbHkgaGVs cCB1cyBhbGwgaW4gZ2V0dGluZyB0aGVyZS4NCk5vIG9iamVjdGlvbiB0byBNQVAgYXQgYWxsLCBB UyBMT05HIEFTICBpdCBmb2xsb3dzIHRoZSBvcmlnaW5hbCwNCnN1aXRhYmxlIHByb2JsZW0gc3Bh Y2Ugd2hpY2ggaXQgaXMgZXhwZWN0ZWQgdG8gZGV2ZWxvcGVkIGZvci4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0 DQpTb2Z0d2lyZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc29mdHdpcmVz ------=_001_NextPart824065370664_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Peng,
 
I totally agree= with=20 you.
 
AFAIK, the originally MAP draft is designed to so= lve the=20 stateless scenarios in a IPv4 info embedded way. Now one day, the 1:1=20 mode was suddenly added by setting the EA bits to zero without any co= nsent=20 from the WG, which also abandoned the essence of original=20 MAP.
 
Since I= cannot find=20 any words in earlier MAP drafts talking about 1:1 mode, what I can imagine= is=20 that the two years hard works by the real 1:1 mapping guys are=20 ignored  in the new MAP draft.
 
Best Regards!
Jiang Dong
 
From: Peng Wu=
Date: 2012-06-26 12:07
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
Woj,
 
On Mon, Jun 25, 2012 at 10:24 PM,&= nbsp;Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Hi,
>
> taking a step back to discuss = ;some items in more detail, and hopefully&nb= sp;move
> this discussion forward:
>
> 1. Domain size
> The MAP architecture does not pres= cribe the size of a domain, and neither=
> does it prescribe the number of&nb= sp;rules to be used. There is nothing i= n the
> technology, except vendor implementation&nbs= p;limits or practical sense (or
> both), to prevent MAP domains from=  defining 1 domain =3D 1 CPE. This = ;was a day
> 1 characteristic of MAP drafts.
Yes from the theoretical view you could= . But that's not the exact 1:1
mode the "ietf-map-00" described. You have&n= bsp;to change the specification
and twist the mechanism definiation to = particularly support the 1:1
mode.
 
> Choosing to deploy or implement MA= P with a configuration supporting 1 rule,
> 100 rules or 100k rules or do= mains is a vendor's and/or operator's choice= .
> Nobody is stating that deployment = is to be limited to X rules, nor t= hat a
> near infinite number of rules is&n= bsp;reasonable. These are general points that
> apply to DS-lite state as well&nbs= p;as the "Light Weight 4 over 6" or&nbs= p;"stateless
> deterministic NAT", and pretty much&nbs= p;any technology for that matter.
>
> 2. Stateless DOES NOT mean configu= ration-less
> There appears to be confusion betw= een the concept of stateless and
> configuration-less. MAP domains are bas= ed on configured rules, that are
> provisioned/applied through means that = are currently outside the scope of
> Softwire drafts - this is configur= ation state, and this was and continues = ;to
> be a characteristic of MAP.
If you have  per-user specific configur= ation, that definitely changes
the operation model.
 
> Further more, unlike some of the&n= bsp;other proposals, MAP allows to optimize = the
> amount of configuration needed in = cases where this is viable. In other
> words, MAP does NOT exclusively fo= rce 1:1 rule configuration, but also
> allows N:1.
That's not what is discussed in this&nb= sp;thread at all...
>
> 3. Stateless has no data plane&nbs= p;induced state
> A major difference between stateless&nb= sp;(eg MAP) and stateful (eg Carrier Grade
> NAT44/Ds-Lite) solutions is that the&nb= sp;latter are characterised by dynamic
> core node forwarding state that is=  directly driven by user data-plane
> traffic (eg new IP flows). MAP&nbs= p;does not rely on such dynamic state, = never
> did.
I think you only mean per-session state= ful. For per-user stateful
mechanisms, you run the provisioning process=  to avoid state creating
from the data plane. That's one of = ;the essential design goals and
benifits of the per-user stateful mechanisms=  and reflected in
lw4over6.
 
>
> 4. No change of MAP spec
> The updated MAP draft does not&nbs= p;change the MAP architecture nor its techni= cal
> underpinnings. In fact there are n= o changes, bar editorial to the normative
> parts of MAP, something that is&nb= sp;proven by existing implementations prior to
> this draft supporting the current = draft. A few individuals appear to object
> to new descriptive text which high= lights the usage of MAP, eg in 1:1.
> Removing that text will not change=  the matter that MAP allows such usage.=
> Prohibiting such use by specification&n= bsp;would actually require a spec change,
> besides being unreasonable.
Sorry, no. You need to change specifica= tions, and you need to twist
the definations of the terminology.
For example, you need to explicitly pro= visio the port set information,
which is not the usual case at all= .
 
>
> 5. What is the problem?
> We're  pleased to see a growi= ng understanding of MAP's applicability to
> solve problems, incl v4-v6 address = ;independence, when needed. Given that the
> emails on this thread do not = appear to bring forward any technical issues=
> with the MAP solution, could we&nb= sp;know WHY we need other solutions to = the
> problem, or what is the problem&nb= sp;that remains to be solved?
The problem is that there are apparentl= y three types of solutions with
perspective application scenarios, while the = ;MAP solution, originally
strongly customized for the pure stateless&n= bsp;scenario, is now twisting
itself in a somehow weired way, droppin= g the essential feature of
statelessness, to include the per-user state= /mapping scenario which
can be solved by a more pure and&n= bsp;clear solution.
 
> Taking the liberty to speak on&nbs= p;behalf of the other MAP authors, I wo= uld like
> to say that we all remain ope= n for collaboration with all WG members = ;in
> terms of arriving at a minimal&nbs= p;set of reasonable solutions that solve
> problems that the community cares = about. We also trust that our renewed W= G
> leadership will finally help us al= l in getting there.
No objection to MAP at all, AS LON= G AS  it follows the original,
suitable problem space which it is expe= cted to developed for.
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart824065370664_=------ From ian.farrer@telekom.de Tue Jun 26 00:13: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 3CCF321F8582 for ; Tue, 26 Jun 2012 00:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScE-qbvNkLFo for ; Tue, 26 Jun 2012 00:13:04 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id EC97D21F84DD for ; Tue, 26 Jun 2012 00:13:03 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 26 Jun 2012 09:13:02 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 26 Jun 2012 09:13:01 +0200 From: To: Date: Tue, 26 Jun 2012 09:13:00 +0200 Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: Ac1Tax9W+sGyXKH3RNqiPvzqKsg38Q== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CC0F2D82285F4ianfarrertelekomde_" MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 07:13:05 -0000 --_000_CC0F2D82285F4ianfarrertelekomde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Satoru, Comment in line below. Best regards, Ian Date: Mon, 25 Jun 2012 18:46:18 +0900 From: Satoru Matsushima > To: Peng Wu > Cc: softwires@ietf.org, Yong Cui > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOTreflect the consensus from the WG Message-ID: <5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com> Content-Type: text/plain; charset=3Diso-8859-1 Hi Peng, On 2012/06/25, at 18:34, Peng Wu wrote: Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 = options. BMR: o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o Rule-ipv4-prefix : x.x.x.x/32 o EA-length : 0 o Port-param option : {PSID/length} This BMR could be a LW46 provisioning means. Again, all the information needed is the IPv4 address and port set. 1) The item like rule-ipv6-prefix is not needed at all. 2) Port set or PSID still needs extra provisioning (while in regular MAP it's embedded in IPv6 address) So why make it so difficult and obscure Not difficult, easy business for CE which implemented MAP. Other difficulty= in operator side in particular provisioning complex, that should be same w= ith LW46. It also makes to complete MAP spec in the ea-len zero case. [IF] Additional complexity in the operator side is where I see the problem = with MAP in our case. The strength that MAP offers is for the mesh model an= d the complexity that it brings is a neat way of achieving this. But if hub= -and-spoke is the only deployment scenario that you need, then the complexi= ty for mesh is an unnecessary addition that results in operational complexi= ty, which is something we're trying to engineer out wherever we can. E.g. In the case above, for a shared IP address, the source port range is e= ncoded in the port-param option. To troubleshoot user connectivity, ops nee= d to have a good understanding of how this is being calculated so that they= can trace the user. Not the end of the world, but with millions of custome= rs and a hundred support staff, it's just better avoided if possible. This = logic also then needs to be built into other business support systems that = rely on the customers IP/port range as an identifier. LW46 solves this with a simple (though long) lookup table. This does mean t= hat it's very easy to extract how a user is configured or identified with a= minimum of additional knowledge and calculating tools. cheers, --satoru ------------------------------ --_000_CC0F2D82285F4ianfarrertelekomde_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Satoru,

Comment in line below.

Best regards,
Ian

Date: Mon, 25 Jun 2012 18:46:18 +0900
From: Satoru Matsushima = <satoru.matsushima@gmail.= com>
= To: Peng Wu <pengwu.thu@gmail.co= m>
NOTreflect the consensus from the WG
Content-Type: text/plain; charset=3Diso-= 8859-1

<= /div>
Hi Peng,

On 2012/06/25, at 18:3= 4, Peng Wu wrote:

= Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 = options.
BMR:
  o Rule-ipv6-prefix=   : {exact matched with CE's delegated prefix}
 &n= bsp;o Rule-ipv4-prefix  : x.x.x.x/32
  o EA-l= ength         : 0
 &= nbsp;o Port-param option : {PSID/length}
This BMR coul= d be a LW46 provisioning means.
Again, al= l the information needed is the IPv4 address and port set.
=
1) The item like rule-ipv6-prefix is not needed at all.
2) P= ort set or PSID still needs extra provisioning (while in regular
= MAP it's embedded in IPv6 address)
So why make it so d= ifficult and obscure

Not difficult, easy business for CE which implemented MAP. O= ther difficulty in operator side in particular provisioning complex, that s= hould be same with LW46. It also makes to complete MAP spec in the ea-len zero case.

= [IF] Additional complexity in the operator side is where I see the problem = with MAP in our case. The strength that MAP offers is for the mesh model an= d the complexity that it brings is a neat way of achieving this. But if hub-and-spoke is the only deployment scenario that you need, = then the complexity for mesh is an unnecessary addition that results in ope= rational complexity, which is something we're trying to engineer out wherev= er we can.
E= .g. In the case above, for a shared IP address, the source port range is en= coded in the port-param option. To troubleshoot user connectivity, ops need= to have a good understanding of how this is being calculated so that they can trace the user. Not the end of the world, but = with millions of customers and a hundred support staff, it's just better av= oided if possible. This logic also then needs to be built into other busine= ss support systems that rely on the customers IP/port range as an identifier.
LW46 solves this with a simple (though l= ong) lookup table. This does mean that it's very easy to extract how a user= is configured or identified with a minimum of additional knowledge and cal= culating tools.

che= ers,
--sator= u

=
-----------------= -------------

<= /div>
--_000_CC0F2D82285F4ianfarrertelekomde_-- From despres.remi@laposte.net Tue Jun 26 00:13: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 1966A21F84DD for ; Tue, 26 Jun 2012 00:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxjNZnER2fSZ for ; Tue, 26 Jun 2012 00:13:05 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0886921F8567 for ; Tue, 26 Jun 2012 00:13:04 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2103.sfr.fr (SMTP Server) with ESMTP id 3B86670000AF; Tue, 26 Jun 2012 09:13:03 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2103.sfr.fr (SMTP Server) with ESMTP id 68E7F7000081; Tue, 26 Jun 2012 09:13:02 +0200 (CEST) X-SFR-UUID: 20120626071302429.68E7F7000081@msfrf2103.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--537154415 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 26 Jun 2012 09:13:01 +0200 Message-Id: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 07:13:06 -0000 --Apple-Mail-2--537154415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-06-26 =E0 08:04, Wojciech Dec a =E9crit : >=20 >=20 > On 25 June 2012 17:28, R=E9mi Despr=E9s = wrote: >=20 > 2012-06-25 =E0 16:24, Wojciech Dec: > ... > > The updated MAP draft does not change the MAP architecture nor its = technical underpinnings. In fact there are no changes, bar editorial to = the normative parts of MAP, >=20 > Having asked several times for a list of substantial evolutions from = previous MAP drafts, with their justifications, and having received no = answer, I see this statement as an indirect but first answer. >=20 > Woj> You were provided with an answer (pls see Ole's mail). Could you please indicate which one? >=20 >=20 > But it doesn't seem acceptable (*): > - AFAIK, the added 5th parameter of basic mapping rules is more than = editorial >=20 > Woj> Please indicate what the new parameter in your opinion is. In Section 5, "Forwarding mode" has become a BMR 5th parameter.=20 In Section 5 of the mdt draft of january 30, there were only 4 BMR = parameter. Anything missed? > - I didn't find the equivalent of the following sentence in previous = drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by = other means, MUST disable its NAT44 functionality." Is there such an equivalent? Please answer (not answering the question isn't a way to eliminate it). > Woj> Well, perhaps you would like to suggest what the CPE should do in = the case the CPE is issued with a default mapping rule, ie a default = route in map terms, and the absence of an assigned IPv4 address or other = parameters (BMR). The above appears to be reasonable behaviour. >=20 > =3D> A carefully studied list of substantial changes MAP supporters = have found appropriate after the Paris meeting remains to be due. >=20 > Woj> Take it from the other people who have done implementations, = technically there are no changes. In their implementation, maybe, but we talk about the specification. RD >=20 > -Woj. >=20 >=20 >=20 > > something that is proven by existing implementations prior to this = draft supporting the current draft. >=20 > Please understand that your stating that some tests (for which we = don't have detailed reports) should be considered a proof that what you = say is true, is difficult to accept. > Especially if what you say seems contradicted by a verifiable fact = (see (*) above). >=20 > RD >=20 >=20 --Apple-Mail-2--537154415 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On 25 June 2012 17:28, = R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:

2012-06-25 =E0 16:24, Wojciech Dec:
...
> The updated MAP draft does not change the MAP = architecture nor its technical underpinnings. In fact there are no = changes, bar editorial to the normative parts of MAP,

Having asked several times for a list of substantial evolutions = from previous MAP drafts, with their justifications, and having received = no answer, I see this statement as an indirect but first = answer.

Woj> You were provided with an answer (pls see Ole's = mail).

Could you please indicate = which one?



But it doesn't seem acceptable (*):
- AFAIK, the added 5th parameter of basic mapping rules is more than = editorial

Woj> Please indicate what the new = parameter in your opinion = is.

In Section 5, "Forwarding = mode" has become a BMR 5th parameter. 
In Section 5 of = the mdt draft of january 30, there were only 4 BMR = parameter.

Anything = missed?


- I didn't find the equivalent of the following sentence in previous = drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by = other  means, MUST disable its NAT44 = functionality."

Is = there such an equivalent?
Please answer (not answering = the question isn't a way to eliminate it).

Woj> Well, perhaps you would like to suggest what = the CPE should do in the case the CPE is issued with a default mapping = rule, ie a default route in map terms, and the absence of an assigned = IPv4 address or other parameters (BMR). The above appears to be = reasonable behaviour.

=3D> A carefully studied list of substantial changes MAP supporters = have found appropriate after the Paris meeting remains to be = due.

Woj> Take it from the other people who = have done implementations, technically there are no = changes.

In their = implementation, maybe, but we talk about the = specification.

RD



-Woj.



> something that is proven by existing implementations prior to this = draft supporting the current draft.

Please understand that your stating that some tests (for which we = don't have detailed reports) should be considered a proof that what you = say is true, is difficult to accept.
Especially if what you say seems contradicted by a verifiable fact (see = (*) above).

RD



= --Apple-Mail-2--537154415-- From wdec.ietf@gmail.com Tue Jun 26 00:37: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 E6D1721F857D for ; Tue, 26 Jun 2012 00:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoV5Xd98gEuK for ; Tue, 26 Jun 2012 00:37:13 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id B1A8621F8534 for ; Tue, 26 Jun 2012 00:37:13 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2694712qcm.15 for ; Tue, 26 Jun 2012 00:37:13 -0700 (PDT) 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=5XN1aKn23RyGTmWktKFxrQm+/vwIhDeTE77rKl9yUQk=; b=GT5gpj1zXBfxMsyXyGeJvUbNksCEefdgbK1vXUiWjYO3lJJ8JC8vBVe9PMsf94wm41 q4JKrxKOQDb1dEJhMtXyMlyBAUOw0vlWBc2tKnprt02dwS0P2e51SwrHmLc95Xa5J3CO cY4nJPD/dD8Ne8zQyhl5UwYZcE88vdegaxX2wIYFXPq0X9aHP/yBl31EpSGF8yNXAqlX 6MGpggaZ7A5gVxJUNRucr+OPNT2qLDmyrxkJMiOeQw8a6FQNIBFRASh4xtRydcLKRPsN A2047uNKbTK4x0kHyycs6VF4EyAiH1d6sVJBclTTo+0Jg8JLQPDWMRha8GYGlUxEPthf 39cA== MIME-Version: 1.0 Received: by 10.224.207.138 with SMTP id fy10mr24087907qab.85.1340696233099; Tue, 26 Jun 2012 00:37:13 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Tue, 26 Jun 2012 00:37:12 -0700 (PDT) In-Reply-To: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> Date: Tue, 26 Jun 2012 09:37:12 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300facd7b9c04504c35b2a63 Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 07:37:18 -0000 --20cf300facd7b9c04504c35b2a63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 26 June 2012 09:13, R=E9mi Despr=E9s wrote: > > Le 2012-06-26 =E0 08:04, Wojciech Dec a =E9crit : > > > > On 25 June 2012 17:28, R=E9mi Despr=E9s wrote: > >> >> 2012-06-25 =E0 16:24, Wojciech Dec: >> ... >> > The updated MAP draft does not change the MAP architecture nor its >> technical underpinnings. In fact there are no changes, bar editorial to = the >> normative parts of MAP, >> >> Having asked several times for a list of substantial evolutions from >> previous MAP drafts, with their justifications, and having received no >> answer, I see this statement as an indirect but first answer. >> > > Woj> You were provided with an answer (pls see Ole's mail). > > > Could you please indicate which one? > > > >> But it doesn't seem acceptable (*): >> - AFAIK, the added 5th parameter of basic mapping rules is more than >> editorial >> > > Woj> Please indicate what the new parameter in your opinion is. > > > In Section 5, "Forwarding mode" has become a BMR 5th parameter. > In Section 5 of the mdt draft of january 30, there were only 4 BMR > parameter. > > Anything missed? > Ok, so fair point. MAP-E and -T have been merged in the draft, based on previous feedback from the WG incl discussions at the last meeting. We thought having less drafts is more as was discussed at the last meeting. The updated draft also highlights how much commonality there is. We're welcome to suggestions on how to provide information on which transport mode to use, or if the merger is no desired. > > - I didn't find the equivalent of the following sentence in previous >> drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the >> 1:1 case, and with no IPv4 address and port range configured by other >> means, MUST disable its NAT44 functionality." >> > > Is there such an equivalent? > Please answer (not answering the question isn't a way to eliminate it). > Equivalent of what? Note: I asked you how you would propose dealing with the DMR but no BMR corner case, and await your proposal.. -Woj. > > Woj> Well, perhaps you would like to suggest what the CPE should do in th= e > case the CPE is issued with a default mapping rule, ie a default route in > map terms, and the absence of an assigned IPv4 address or other parameter= s > (BMR). The above appears to be reasonable behaviour. > >> >> =3D> A carefully studied list of substantial changes MAP supporters have >> found appropriate after the Paris meeting remains to be due. >> > > Woj> Take it from the other people who have done implementations, > technically there are no changes. > > > In their implementation, maybe, but we talk about the specification. > > RD > > > > -Woj. > > >> >> > something that is proven by existing implementations prior to this >> draft supporting the current draft. >> >> Please understand that your stating that some tests (for which we don't >> have detailed reports) should be considered a proof that what you say is >> true, is difficult to accept. >> Especially if what you say seems contradicted by a verifiable fact (see >> (*) above). >> >> RD >> >> > > --20cf300facd7b9c04504c35b2a63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 26 June 2012 09:13, R=E9mi Despr=E9s = <despres.remi@laposte.net> wrote:

Le 2012-06-26 =E0 08:04, = Wojciech Dec a =E9crit :



On 25 June 2012 17:28, R=E9mi Despr= =E9s <despres.remi@laposte.net> wrote:

2012-06-25 =E0 16:24, Wojciech Dec:
...
> The updated MAP draft does not change the MAP architecture nor it= s technical underpinnings. In fact there are no changes, bar editorial to t= he normative parts of MAP,

Having asked several times for a list of substantial evolutions from = previous MAP drafts, with their justifications, and having received no answ= er, I see this statement as an indirect but first answer.

Woj> You were provided with an answer (pls see Ole's mail).=

Could you please indicate whi= ch one?



But it doesn't seem acceptable (*):
- AFAIK, the added 5th parameter of basic mapping rules is more than editor= ial

Woj> Please indicate what the new parameter= in your opinion is.

In Section 5, "Forwarding mode" has become a BMR 5th parameter.= =A0
In Section 5 of the mdt draft of january 30, there were only = 4 BMR parameter.

Anything missed?

Ok, so fair point. MAP-E and -T have been merged in the draft, bas= ed on previous feedback from the WG incl discussions at the last meeting. W= e thought having less drafts is more as was discussed at the last meeting. = The updated draft also highlights how much commonality there is.
We're welcome to suggestions on how to provide information on which tra= nsport mode to use, or if the merger is no desired.


<= br>
- I didn't find the equivalent of the following sentence in previous dr= afts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by other = =A0means, MUST disable its NAT44 functionality."

Is there such an equiv= alent?
Please answer=A0(not answering the question isn't a wa= y to eliminate it).

Equivalent of what? Note: I asked you how you would propose dealing with the DMR but no BMR cor= ner case, and await your proposal..=A0

-Woj.

Woj> Well, perhaps you would like to suggest what the = CPE should do in the case the CPE is issued with a default mapping rule, ie= a default route in map terms, and the absence of an assigned IPv4 address = or other parameters (BMR). The above appears to be reasonable behaviour.

=3D> A carefully studied list of substantial changes MAP supporters have= found appropriate after the Paris meeting remains to be due.

Woj> Take it from the other people who have done implementat= ions, technically there are no changes.

In their implementation, mayb= e, but we talk about the specification.

RD



-Woj.



> something that is proven by existing implementations prior to this dra= ft supporting the current draft.

Please understand that your stating that some tests (for which we don= 't have detailed reports) should be considered a proof that what you sa= y is true, is difficult to accept.
Especially if what you say seems contradicted by a verifiable fact (see (*)= above).

RD




--20cf300facd7b9c04504c35b2a63-- From wdec.ietf@gmail.com Tue Jun 26 00:55: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 4DDD421F858A for ; Tue, 26 Jun 2012 00:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je6Dd3T4ee-L for ; Tue, 26 Jun 2012 00:55:20 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6721F8589 for ; Tue, 26 Jun 2012 00:55:20 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2700743qcm.15 for ; Tue, 26 Jun 2012 00:55:20 -0700 (PDT) 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=Ls1vsSKme0MrzZO2cy2bd0a4vUTxNcESh4axbfLjDxc=; b=C44D/bsYRfAb3GefqDpmSz/lZrS0N3NF7HJBkBpYlXJIHlExDv0uAE9WkjtkmtaDGE 96u7Dl5wAtwNJP3vrQ/3pdcMldt9vmGoMTBKYtL5ydZ69jfD3ChtTEpOCzXcaJCJYnQv udV2se8J62NyK6eMUcomBa7t4jrECJxWoCw+CUtY1fk907UkJah7v9GBODfdveOj2my9 6GF/ow+Zejt6eEmuF/R5dtul9Z2aOq7PTIFIc17gNLHEA6mefiD7U2WTT/thAlUBEpP/ EKN8P986bylKz7JXwRfIlGD2vcyefr0tZK2+1C/89XiAO0QCmxqlxsG3zIFu1lxSgZ3E PPsg== MIME-Version: 1.0 Received: by 10.224.182.72 with SMTP id cb8mr15758026qab.46.1340697319838; Tue, 26 Jun 2012 00:55:19 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Tue, 26 Jun 2012 00:55:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 09:55:19 +0200 Message-ID: From: Wojciech Dec To: ian.farrer@telekom.de Content-Type: multipart/alternative; boundary=20cf303b430b8013e804c35b6b5e Cc: softwires@ietf.org Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 07:55:21 -0000 --20cf303b430b8013e804c35b6b5e Content-Type: text/plain; charset=ISO-8859-1 On 26 June 2012 09:13, wrote: > Hi Satoru, > > Comment in line below. > > Best regards, > Ian > > Date: Mon, 25 Jun 2012 18:46:18 +0900 > From: Satoru Matsushima > To: Peng Wu > Cc: softwires@ietf.org, Yong Cui > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does > NOTreflect the consensus from the WG > Message-ID: <5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com> > Content-Type: text/plain; charset=iso-8859-1 > > Hi Peng, > > On 2012/06/25, at 18:34, Peng Wu wrote: > > Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 > options. > BMR: > o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} > o Rule-ipv4-prefix : x.x.x.x/32 > o EA-length : 0 > o Port-param option : {PSID/length} > This BMR could be a LW46 provisioning means. > > Again, all the information needed is the IPv4 address and port set. > 1) The item like rule-ipv6-prefix is not needed at all. > 2) Port set or PSID still needs extra provisioning (while in regular > MAP it's embedded in IPv6 address) > So why make it so difficult and obscure > > > Not difficult, easy business for CE which implemented MAP. Other > difficulty in operator side in particular provisioning complex, that should > be same with LW46. It also makes to complete MAP spec in the ea-len zero > case. > > [IF] Additional complexity in the operator side is where I see the problem > with MAP in our case. The strength that MAP offers is for the mesh model > and the complexity that it brings is a neat way of achieving this. But if > hub-and-spoke is the only deployment scenario that you need, then the > complexity for mesh is an unnecessary addition that results in operational > complexity, which is something we're trying to engineer out wherever we can. > E.g. In the case above, for a shared IP address, the source port range is > encoded in the port-param option. To troubleshoot user connectivity, ops > need to have a good understanding of how this is being calculated so that > they can trace the user. Not the end of the world, but with millions of > customers and a hundred support staff, it's just better avoided if > possible. This logic also then needs to be built into other business > support systems that rely on the customers IP/port range as an identifier. > LW46 solves this with a simple (though long) lookup table. This does mean > that it's very easy to extract how a user is configured or identified with > a minimum of additional knowledge and calculating tools. > Well, a couple of observations: A) MAP allows you to optimize complexity in not having to deal with per subscriber rules in cases where this is feasible. B) You're referring to data representation as an operational problem, which if so, actually applies to any solution incl LW46 that transmits port-range info to a client. I.e. "Whatever support staff" needs to be schooled to use some logic to glean useful port information from the data sent to a client C) It is very easy to represent MAP data as port range info on routers, tools, etc. -Woj. > > cheers, > --satoru > > ------------------------------ > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf303b430b8013e804c35b6b5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 26 June 2012 09:13, <ian.farrer= @telekom.de> wrote:
= Hi Satoru,

Comment in line below.=

Best regards,
Ian

Date: Mon, 25 Jun 2012 18= :46:18 +0900
From= : Satoru Matsushima <satoru.matsushima@gmail.com>
Subj= ect: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does
=
NOTreflec= t the consensus from the WG
Content-Type: text/plain; charset=3Diso-8859-1

Hi Peng,

On 2012/06/2= 5, at 18:34, Peng Wu wrote:

Let's think that a CE provisioned with following BMR comes from MA= P DHCPv6 options.
BMR:
=A0=A0o Rule-ipv6-pre= fix=A0=A0: {exact matched with CE's delegated prefix}
=A0=A0o= Rule-ipv4-prefix=A0=A0: x.x.x.x/32
=A0=A0o EA-length=A0=A0=A0=A0=A0=A0=A0=A0 : 0
=A0=A0o Port-p= aram option : {PSID/length}
This BMR could be a LW46 p= rovisioning means.
Again, all the i= nformation needed is the IPv4 address and port set.
1) The item like rule-ipv6-prefix is not = needed at all.
2) Port set or PSID still needs extra provisioning= (while in regular
MAP it's embedded in IPv6 address)
So why make it so difficult and obscure

Not difficu= lt, easy business for CE which implemented MAP. Other difficulty in operato= r side in particular provisioning complex, that should be same with LW46. I= t also makes to complete MAP spec in the ea-len zero case.

[IF]= Additional complexity in the operator side is where I see the problem with= MAP in our case. The strength that MAP offers is for the mesh model and th= e complexity that it brings is a neat way of achieving this. But if hub-and-spoke is the only deployment scenario that you need, = then the complexity for mesh is an unnecessary addition that results in ope= rational complexity, which is something we're trying to engineer out wh= erever we can.
E.g. In the case above= , for a shared IP address, the source port range is encoded in the port-par= am option. To troubleshoot user connectivity, ops need to have a good under= standing of how this is being calculated so that they can trace the user. Not the end of the world, but = with millions of customers and a hundred support staff, it's just bette= r avoided if possible. This logic also then needs to be built into other bu= siness support systems that rely on the customers IP/port range as an identifier.
LW46 solves this with a simple (though long) = lookup table. This does mean that it's very easy to extract how a user = is configured or identified with a minimum of additional knowledge and calc= ulating tools.

Well, a couple of observation= s:
A) MAP allows you to optimize complexity in not having to deal with p= er subscriber rules in cases where this is feasible.
B) You're refe= rring to data representation as an operational problem, which if so, actual= ly applies to any solution incl LW46 that transmits port-range info to a cl= ient. I.e. "Whatever support staff" needs to be schooled to use s= ome logic to glean useful port information from the data sent to a client C) It is very easy to represent MAP data as port range info on routers, too= ls, etc.

-Woj.
=A0
=
cheers,
--satoru

--------------------= ----------


=

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


--20cf303b430b8013e804c35b6b5e-- From despres.remi@laposte.net Tue Jun 26 01:37: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 104B721F8550 for ; Tue, 26 Jun 2012 01:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I200uYgAJ38X for ; Tue, 26 Jun 2012 01:37:18 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id E402521F84F0 for ; Tue, 26 Jun 2012 01:37:17 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2103.sfr.fr (SMTP Server) with ESMTP id C812070000AF; Tue, 26 Jun 2012 10:37:16 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2103.sfr.fr (SMTP Server) with ESMTP id 382117000081; Tue, 26 Jun 2012 10:37:16 +0200 (CEST) X-SFR-UUID: 20120626083716230.382117000081@msfrf2103.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--532099967 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 26 Jun 2012 10:37:16 +0200 Message-Id: <76F73D2D-B6FA-48A2-9748-073ABDB30641@laposte.net> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 08:37:19 -0000 --Apple-Mail-3--532099967 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-06-26 =E0 09:37, Wojciech Dec: > On 26 June 2012 09:13, R=E9mi Despr=E9s = wrote: >=20 > Le 2012-06-26 =E0 08:04, Wojciech Dec a =E9crit : >>=20 >> On 25 June 2012 17:28, R=E9mi Despr=E9s = wrote: ... >> Having asked several times for a list of substantial evolutions from = previous MAP drafts, with their justifications, and having received no = answer, I see this statement as an indirect but first answer. >>=20 >> Woj> You were provided with an answer (pls see Ole's mail). >=20 > Could you please indicate which one? Since you claim there has been an answer, and suggest I find it, I = suppose you can find it yourself. =3D> Please answer (or implicitly acknowledge that the list of MAP = substantial evolutions is still awaited). >> But it doesn't seem acceptable (*): >> - AFAIK, the added 5th parameter of basic mapping rules is more than = editorial >>=20 >> Woj> Please indicate what the new parameter in your opinion is. >=20 > In Section 5, "Forwarding mode" has become a BMR 5th parameter.=20 > In Section 5 of the mdt draft of january 30, there were only 4 BMR = parameter. >=20 > Anything missed? >=20 > Ok, so fair point. MAP-E and -T have been merged in the draft, based = on previous feedback from the WG incl discussions at the last meeting. = We thought having less drafts is more as was discussed at the last = meeting. The updated draft also highlights how much commonality there = is. - A parameter PER DOMAIN was an obvious result of a merger. - But a parameter PER RULE is a significant novelty. OK? > We're welcome to suggestions on how to provide information on which = transport mode to use, or if the merger is no desired.=20 >=20 >> - I didn't find the equivalent of the following sentence in previous = drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by = other means, MUST disable its NAT44 functionality." >=20 > Is there such an equivalent? > Please answer (not answering the question isn't a way to eliminate = it). >=20 > Equivalent of what? Is there in previous drafts the sentence above (or an equivalent) "A = MAP-E CE... MUST disable its NAT44 functionality."?=20 - If yes, please indicate where. - If not, IT IS an evolution, to be identified as such. > Note: I asked you how you would propose dealing with the DMR but no = BMR corner case, and await your proposal.. =20 - In the 4rd draft, appendix D, there is a deployment example with only = on mapping rule (the BR mapping rule, AKA the DMR in your MAP draft). - If this isn't sufficient to answer your concern, please point to the = mail in which you asked the unanswered question.=20 =20 Thanks, RD --Apple-Mail-3--532099967 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 26 June 2012 09:13, R=E9mi = Despr=E9s <despres.remi@laposte.net> = wrote:

Le 2012-06-26 =E0 = 08:04, Wojciech Dec a =E9crit :

On 25 June 2012 17:28, R=E9mi= Despr=E9s <despres.remi@laposte.net> = wrote:
...
Having asked several times for a list of = substantial evolutions from previous MAP drafts, with their = justifications, and having received no answer, I see this statement as = an indirect but first answer.

Woj> You were provided with an answer (pls see Ole's = mail).

Could you please = indicate which = one?

= Since you claim there has been an answer, and suggest I find it, I = suppose you can find it yourself.
=3D> Please answer (or = implicitly acknowledge that the list of MAP substantial evolutions is = still awaited).


But it doesn't seem acceptable (*):
- AFAIK, the added 5th parameter of basic mapping rules is more than = editorial

Woj> Please indicate what the new = parameter in your opinion = is.

In Section 5, "Forwarding mode" has become a BMR 5th = parameter. 
In Section 5 of the mdt draft of january 30, = there were only 4 BMR parameter.

Anything = missed?

Ok, so fair point. MAP-E and -T have been merged in the draft, = based on previous feedback from the WG incl discussions at the last = meeting. We thought having less drafts is more as was discussed at the = last meeting. The updated draft also highlights how much commonality = there is.

- A = parameter PER DOMAIN was an obvious result of a merger.
- But = a parameter PER RULE is a significant = novelty.
OK?


We're welcome to suggestions on how to provide information on which = transport mode to use, or if the merger is no = desired. 

- I didn't find the equivalent of the following sentence in previous = drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by = other  means, MUST disable its NAT44 functionality."

Is there such an = equivalent?
Please answer (not answering the question = isn't a way to eliminate = it).

Equivalent of = what?

Is there in previous = drafts the sentence above (or an equivalent) "A MAP-E CE... MUST disable = its NAT44 functionality."? 
- If yes, please indicate = where.
- If not, IT IS an evolution, to be identified as = such.


Note: I asked you how you would propose dealing with the DMR but no BMR = corner case, and await your proposal..  =

- In the 4rd = draft, appendix D, there is a deployment example with only on = mapping rule (the BR mapping rule, AKA the DMR in your MAP = draft).
- If this isn't sufficient to answer your concern, = please point to the mail in which you asked the unanswered = question. 
 
Thanks,
RD

= --Apple-Mail-3--532099967-- From wdec.ietf@gmail.com Tue Jun 26 01:50: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 1224E21F8598 for ; Tue, 26 Jun 2012 01:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.303 X-Spam-Level: X-Spam-Status: No, score=-3.303 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfdNBmLUVbmo for ; Tue, 26 Jun 2012 01:50:56 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id CCA7021F8593 for ; Tue, 26 Jun 2012 01:50:55 -0700 (PDT) Received: by qcmt36 with SMTP id t36so2720067qcm.15 for ; Tue, 26 Jun 2012 01:50:55 -0700 (PDT) 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=7vOKF9MFBMX/6UfrdWwfaTWLGvEyES6R+Ff/OTmf+iM=; b=pz3pteOmKR16kzgwUi8/3d9KRkskxLLk8I4FbiK6bEQxeYOkjtM+STCMdGHVSIM8Bv 1660vmfGuC52O2mh24qIBUE87AydWoWLh6Su2GlYPfbVyQ9h3sxDgyhOOVgWTypDVPQb XAcIcNu/PueIKv0sXB6MiD+LHPyK7MlD+JLxMoR2sAtS5maUUmNdqtznxkDAKNDjEWMo 5pSMaTfQrz6J3yNX3h3MA1XyGwpyZZce1Mynqh6u30ZbqxZerfPUvZIpTegvG68k7InW soopUg2jUVpDIXTFFdzMOoe08VcooTBdx0tTDdo7rhN6R0Fy4I5kgJhIVFnOZIWPj3z4 RpHA== MIME-Version: 1.0 Received: by 10.229.135.20 with SMTP id l20mr326198qct.83.1340700655309; Tue, 26 Jun 2012 01:50:55 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Tue, 26 Jun 2012 01:50:55 -0700 (PDT) In-Reply-To: <76F73D2D-B6FA-48A2-9748-073ABDB30641@laposte.net> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <76F73D2D-B6FA-48A2-9748-073ABDB30641@laposte.net> Date: Tue, 26 Jun 2012 10:50:55 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c6a5ade4f53af04c35c32d1 Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 08:50:57 -0000 --00248c6a5ade4f53af04c35c32d1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 26 June 2012 10:37, R=E9mi Despr=E9s wrote: > > 2012-06-26 =E0 09:37, Wojciech Dec: > > On 26 June 2012 09:13, R=E9mi Despr=E9s wrote: > >> >> Le 2012-06-26 =E0 08:04, Wojciech Dec a =E9crit : >> >> >> On 25 June 2012 17:28, R=E9mi Despr=E9s wrote= : >> >> ... > > Having asked several times for a list of substantial evolutions from >>> previous MAP drafts, with their justifications, and having received no >>> answer, I see this statement as an indirect but first answer. >>> >> >> Woj> You were provided with an answer (pls see Ole's mail). >> >> >> Could you please indicate which one? >> > > Since you claim there has been an answer, and suggest I find it, I suppos= e > you can find it yourself. > =3D> Please answer (or implicitly acknowledge that the list of MAP > substantial evolutions is still awaited). > http://www.ietf.org/mail-archive/web/softwires/current/msg04358.html It's a short list : - MAP-E and MAP-T drafts have been merged. - Handling of the corner cases regarding DMR but no BMR added - Non normative text regarding use (eg backwards compatibility) added. > > But it doesn't seem acceptable (*): >>> - AFAIK, the added 5th parameter of basic mapping rules is more than >>> editorial >>> >> >> Woj> Please indicate what the new parameter in your opinion is. >> >> >> In Section 5, "Forwarding mode" has become a BMR 5th parameter. >> In Section 5 of the mdt draft of january 30, there were only 4 BMR >> parameter. >> >> Anything missed? >> > > Ok, so fair point. MAP-E and -T have been merged in the draft, based on > previous feedback from the WG incl discussions at the last meeting. We > thought having less drafts is more as was discussed at the last meeting. > The updated draft also highlights how much commonality there is. > > > - A parameter PER DOMAIN was an obvious result of a merger. > - But a parameter PER RULE is a significant novelty. > OK? > > That was not intended, and appears to be a genuine mistake in draft-00. Thanks for spotting. It is a parameter per domain, as discussed on the design team alias. -Woj. > > We're welcome to suggestions on how to provide information on which > transport mode to use, or if the merger is no desired. > > >> - I didn't find the equivalent of the following sentence in previous >>> drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in= the >>> 1:1 case, and with no IPv4 address and port range configured by other >>> means, MUST disable its NAT44 functionality." >>> >> >> Is there such an equivalent? >> Please answer (not answering the question isn't a way to eliminate it). >> > > Equivalent of what? > > > Is there in previous drafts the sentence above (or an equivalent) "A MAP-= E > CE... MUST disable its NAT44 functionality."? > - If yes, please indicate where. > - If not, IT IS an evolution, to be identified as such. > > > Note: I asked you how you would propose dealing with the DMR but no BMR > corner case, and await your proposal.. > > > - In the 4rd draft, appendix D, there is a deployment example with only o= n > mapping rule (the BR mapping rule, AKA the DMR in your MAP draft). > - If this isn't sufficient to answer your concern, please point to the > mail in which you asked the unanswered question. > > Thanks, > RD > > --00248c6a5ade4f53af04c35c32d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 26 June 2012 10:37, R=E9mi Despr=E9s = <despres.remi@laposte.net> wrote:

2012-06-26 =E0 09:37, Woj= ciech Dec:

On 26 June 2012 09:13, R=E9mi Despr=E9s = <despres.r= emi@laposte.net> wrote:

Le 2012-06-26 =E0 08:04, = Wojciech Dec a =E9crit :

On 25 June 2012 17:28, R=E9mi Despr=E9s = <despres.r= emi@laposte.net> wrote:
...
Having asked several times for a list of substantial evolutions from previo= us MAP drafts, with their justifications, and having received no answer, I = see this statement as an indirect but first answer.

Woj> You were provided with an answer (pls see Ole's mail).=

Could you please indicate whi= ch one?

Since you claim there has been an answer, and suggest I find it,= I suppose you can find it yourself.
=3D> Please answer (or im= plicitly acknowledge that the list of MAP substantial evolutions is still a= waited).

http://www.ietf.org/mail-archive/web/soft= wires/current/msg04358.html
It's a short list :
- MAP-E and = MAP-T drafts have been merged.
- Handling of the corner cases regarding DMR but no BMR added
- Non norm= ative text regarding use (eg backwards compatibility) added.



<= br>
But it doesn't seem acceptable (*):
- AFAIK, the added 5th parameter of basic mapping rules is more than editor= ial

Woj> Please indicate what the new parameter= in your opinion is.

In Section 5, "Forwarding mode" has become a BMR 5th parameter.= =A0
In Section 5 of the mdt draft of january 30, there were only = 4 BMR parameter.

Anything missed?

Ok, so fair point. MAP-E and -T have been merged in the draft, bas= ed on previous feedback from the WG incl discussions at the last meeting. W= e thought having less drafts is more as was discussed at the last meeting. = The updated draft also highlights how much commonality there is.

- A parameter PER D= OMAIN was an obvious result of a merger.
- But a parameter PER RU= LE is a significant novelty.
OK?

That was not intended, and appears to be a genuine = mistake in draft-00. Thanks for spotting.
It is a parameter per domain, = as discussed on the design team alias.

-Woj.

We're welcome to suggestions on how to provide information on which tra= nsport mode to use, or if the merger is no desired.=A0

- I didn't find the equivalent of the following sentence in previous dr= afts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by other = =A0means, MUST disable its NAT44 functionality."

Is there such an equiv= alent?
Please answer=A0(not answering the question isn't a wa= y to eliminate it).

Equivalent of what?

Is there in previous drafts t= he sentence above (or an equivalent) "A MAP-E CE... MUST disable its N= AT44 functionality."?=A0
- If yes, please indicate where.
- If not, IT IS an evolution, to be identified as such.

=

Note: I asked you how you would propose dealing with the DMR but no BMR cor= ner case, and await your proposal..=A0
- In=A0the 4rd draft,=A0appendix D, there is a deploymen= t example with only on mapping rule (the BR mapping rule, AKA the DMR in yo= ur MAP draft).
- If this isn't sufficient to answer your concern, please point to= the mail in which you asked the unanswered question.=A0
=A0
Thanks,
RD


--00248c6a5ade4f53af04c35c32d1-- From wdec.ietf@gmail.com Tue Jun 26 02:05:14 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 C399221F85C4 for ; Tue, 26 Jun 2012 02:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.452 X-Spam-Level: X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoXhs4vCFsCz for ; Tue, 26 Jun 2012 02:05:13 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4953221F85CE for ; Tue, 26 Jun 2012 02:05:13 -0700 (PDT) Received: by qadz3 with SMTP id z3so1789099qad.10 for ; Tue, 26 Jun 2012 02:05:08 -0700 (PDT) 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=L3RL3t3EsFu4aEPNnBf8QlhiBYBmK+AhWf1oEPsQ3iY=; b=m9FftIix9bgv7G9WFKXuCFpZkNC61dnUUbdtlRE3x2odkzEaWoZAtkoNeZ1Q0N5Ddu f9ffcmp7+u5oeojitn6CAjaWp7he3tCDxSqu3yt2inUfaON9e/zZwejjU+RhvLXAkTVm 1lGg542DK6YK7dMzrjlaDRQtyASmyfSHuy7hoYCkYwO9ZvYF/0rlp2wwoV3Lj0J2Dxav JgzzK8jmnOCRMs5zQyj1l72O+AJatkSmPppOKkbpTR/5CjUZ9M4YA02WfJqrkOJ05Eg1 k0GHG1nGJbzq+KtOvWEfJ/SGmYKa5SNXWD5ufLZV/3Om8+icltL56yGNC4+ZjSbSsHH4 P1DQ== MIME-Version: 1.0 Received: by 10.224.201.136 with SMTP id fa8mr24405373qab.20.1340701508151; Tue, 26 Jun 2012 02:05:08 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Tue, 26 Jun 2012 02:05:08 -0700 (PDT) In-Reply-To: References: <20120624054808.18705.88312.idtracker@ietfa.amsl.com> Date: Tue, 26 Jun 2012 11:05:08 +0200 Message-ID: From: Wojciech Dec To: Maoke Content-Type: multipart/alternative; boundary=20cf300fafe524a87b04c35c65a2 Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-mdt-softwire-map-deployment-01.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, 26 Jun 2012 09:05:15 -0000 --20cf300fafe524a87b04c35c65a2 Content-Type: text/plain; charset=ISO-8859-1 Hi, comments: section 4.2 of the draft reads: " a MAP domain is a set of MAP CEs and BRs connected to the same virtual link. One MAP domain shares a common BR and has the same set of BMRs, FMRs and DMR, and it can be further divided into multiple sub-domains when multiple IPv4 subnets are deployed in one MAP domain. There might be multiple BMRs in one MAP domain, and CE would pick up its own BMR by longest prefix matching lookup. This effectively confirms that multiple MAP domains are an established characteristics, and logic dictates that if N CEs can be in a given domain, N can also equal 1. We look forward to updates to the draft, also in terms of referring to the specs. Regards, Woj. On 26 June 2012 08:24, Maoke wrote: > > hi all, > > we have submitted the updated version of the MAP deployment draft. As the > new draft of MAP spec introduces technical uncertainties and hasn't reach > the consensus. we noticed that the 1:1 mode involves different way of > operation, needing to carefully investigate and to understand. Currently we > exclude the 1:1 mode from the scope of MAP deployment. > > the major change of this version in comparison to the previous version > includes: > - adding of the new section 4.1: Network Models > taking the example of home network, explain what is the typical use > cases of MAP > - editorial changes and correction of grammar/wording/spellings. > > we are aware that this MAP deployment draft has not reviewed by the > working group, and therefore we update it still as individual draft for the > time being. comments and recommendations are requested. > > regards, > maoke > > > ---------- Forwarded message ---------- > From: > Date: 2012/6/24 > Subject: New Version Notification for > draft-mdt-softwire-map-deployment-01.txt > To: sunqiong@ctbri.com.cn > Cc: simon.perreault@viagenie.ca, fibrib@gmail.com, > tina.tsou.zouting@huawei.com, chengang@chinamobile.com, > chunfa.sun@g.softbank.co.jp > > > > A new version of I-D, draft-mdt-softwire-map-deployment-01.txt > has been successfully submitted by Qiong Sun and posted to the > IETF repository. > > Filename: draft-mdt-softwire-map-deployment > Revision: 01 > Title: Mapping of Address and Port (MAP) - Deployment > Considerations > Creation date: 2012-06-24 > WG ID: Individual Submission > Number of pages: 32 > URL: > http://www.ietf.org/internet-drafts/draft-mdt-softwire-map-deployment-01.txt > Status: > http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment > Htmlized: > http://tools.ietf.org/html/draft-mdt-softwire-map-deployment-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-map-deployment-01 > > Abstract: > This document describes when and how an operator uses the technique > of Mapping of Address and Port (MAP) for the IPv4 residual deployment > in the IPv6-dominant domain. > > > > > The IETF Secretariat > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf300fafe524a87b04c35c65a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

comments:

section 4.2 of the draft reads:
" a MAP= domain is a set of MAP CEs and BRs connected to the same virtual link. One MAP domain shares a common BR and has the same set of BMRs, FMRs and DMR, and it can be further divided into multiple sub-domains when multiple IPv4 subnets are deployed in one MAP domain.
There might be multiple BMR= s in one MAP domain, and CE would pick up its own BMR by longest prefix matching lookup.

This effectively confirms that multiple MAP do= mains are an established characteristics, and logic dictates that if N CEs = can be in a given domain, N can also equal 1.

We look forward to upd= ates to the draft, also in terms of referring to the specs.

Regards,
Woj.

On 26 June 2012 08:2= 4, Maoke <fibrib@gmail.com> wrote:

hi all,=A0

we have submitt= ed the updated version of the MAP deployment draft. As the new draft of MAP= spec introduces technical uncertainties and hasn't reach the consensus= . we noticed that the 1:1 mode involves different way of operation, needing= to carefully investigate and to understand. Currently we exclude the 1:1 m= ode from the scope of MAP deployment.=A0

the major change of this version in comparison to the p= revious version includes:=A0
- adding of the new section 4.1: Net= work Models
=A0 taking the example of home network, explain what = is the typical use cases of MAP
- editorial changes and correction of grammar/wording/spellings.=A0

we are aware that this MAP deployment draft has not rev= iewed by the working group, and therefore we update it still as individual = draft for the time being. comments and recommendations are requested.=A0

regards,
maoke


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2012/6/24
Subject: New Version Notification for draft-mdt-softwire= -map-deployment-01.txt
To: sunqiong@ctbri.com.cn
Cc: simon.perreault@viagenie.ca, fibrib@gmail.com, tina.tsou.zou= ting@huawei.com, chengang@chinamobile.com, chunfa.sun@g.softbank.co.jp



A new version of I-D, draft-mdt-softwire-map-deployment-01.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mdt-softwire-map-deployment
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Mapping of Address and Port (MAP) - Deployment C= onsiderations
Creation date: =A0 2012-06-24
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 32
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.iet= f.org/internet-drafts/draft-mdt-softwire-map-deployment-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org= /doc/draft-mdt-softwire-map-deployment
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draf= t-mdt-softwire-map-deployment-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.iet= f.org/rfcdiff?url2=3Ddraft-mdt-softwire-map-deployment-01

Abstract:
=A0 This document describes when and how an operator uses the technique =A0 of Mapping of Address and Port (MAP) for the IPv4 residual deployment<= br> =A0 in the IPv6-dominant domain.




The IETF Secretariat


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


--20cf300fafe524a87b04c35c65a2-- From despres.remi@laposte.net Tue Jun 26 02:54:01 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 5EDB721F85D9 for ; Tue, 26 Jun 2012 02:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ImubxZnI-ZA for ; Tue, 26 Jun 2012 02:54:00 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4421F85D5 for ; Tue, 26 Jun 2012 02:53:59 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id BEB277000048; Tue, 26 Jun 2012 11:53:58 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id ED50670000D1; Tue, 26 Jun 2012 11:53:57 +0200 (CEST) X-SFR-UUID: 20120626095357972.ED50670000D1@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--527498008 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 26 Jun 2012 11:53:58 +0200 Message-Id: <2EF2BB9F-5EC5-4B8D-96E4-81D9E532CEEC@laposte.net> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <76F73D2D-B6FA-48A2-9748-073ABDB30641@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 09:54:01 -0000 --Apple-Mail-4--527498008 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-06-26 =E0 10:50, Wojciech Dec: >=20 > On 26 June 2012 10:37, R=E9mi Despr=E9s = wrote: >=20 > 2012-06-26 =E0 09:37, Wojciech Dec: >=20 >> On 26 June 2012 09:13, R=E9mi Despr=E9s = wrote: >>=20 >> Le 2012-06-26 =E0 08:04, Wojciech Dec a =E9crit : >>>=20 >>> On 25 June 2012 17:28, R=E9mi Despr=E9s = wrote: > ... >=20 >>> Having asked several times for a list of substantial evolutions from = previous MAP drafts, with their justifications, and having received no = answer, I see this statement as an indirect but first answer. >>>=20 >>> Woj> You were provided with an answer (pls see Ole's mail). >>=20 >> Could you please indicate which one? >=20 > Since you claim there has been an answer, and suggest I find it, I = suppose you can find it yourself. > =3D> Please answer (or implicitly acknowledge that the list of MAP = substantial evolutions is still awaited). >=20 > http://www.ietf.org/mail-archive/web/softwires/current/msg04358.html Sorry, but I am lost! This reference is that of my query, not that of an answer by Ole. > It's a short list :=20 > - MAP-E and MAP-T drafts have been merged.=20 > - Handling of the corner cases regarding DMR but no BMR added An explanation on this point would be appreciated. Which sentences of the draft deal with this? > - Non normative text regarding use (eg backwards compatibility) added. A less "short" list has yet to be made. It should include AFAIK: - 5th DMR parameter addition (as long as the deletion you suggest below = hasn't been discussed an approved in the WG) - ability to disable NAT functionality (which has a normative MUST in = the draft) >>> But it doesn't seem acceptable (*): >>> - AFAIK, the added 5th parameter of basic mapping rules is more than = editorial >>>=20 >>> Woj> Please indicate what the new parameter in your opinion is. >>=20 >> In Section 5, "Forwarding mode" has become a BMR 5th parameter.=20 >> In Section 5 of the mdt draft of january 30, there were only 4 BMR = parameter. >>=20 >> Anything missed? >>=20 >> Ok, so fair point. MAP-E and -T have been merged in the draft, based = on previous feedback from the WG incl discussions at the last meeting. = We thought having less drafts is more as was discussed at the last = meeting. The updated draft also highlights how much commonality there = is. >=20 > - A parameter PER DOMAIN was an obvious result of a merger. > - But a parameter PER RULE is a significant novelty. > OK? >=20 > That was not intended, and appears to be a genuine mistake in = draft-00. Thanks for spotting. > It is a parameter per domain, as discussed on the design team alias. The specification is AFAIK viable with this 5th parameter, and some may = find it useful.=20 Since it is now a WG matter, individuals who would like to delete it = from the specification should propose it on the mailing list.=20 (FWIW, I have personally no objection to its deletion). RD >=20 > -Woj. >=20 >> We're welcome to suggestions on how to provide information on which = transport mode to use, or if the merger is no desired.=20 >>=20 >>> - I didn't find the equivalent of the following sentence in previous = drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by = other means, MUST disable its NAT44 functionality." >>=20 >> Is there such an equivalent? >> Please answer (not answering the question isn't a way to eliminate = it). >>=20 >> Equivalent of what? >=20 > Is there in previous drafts the sentence above (or an equivalent) "A = MAP-E CE... MUST disable its NAT44 functionality."?=20 > - If yes, please indicate where. > - If not, IT IS an evolution, to be identified as such. >=20 >=20 >> Note: I asked you how you would propose dealing with the DMR but no = BMR corner case, and await your proposal.. =20 >=20 > - In the 4rd draft, appendix D, there is a deployment example with = only on mapping rule (the BR mapping rule, AKA the DMR in your MAP = draft). > - If this isn't sufficient to answer your concern, please point to the = mail in which you asked the unanswered question.=20 Subject closed, I suppose. > =20 > Thanks, > RD >=20 >=20 --Apple-Mail-4--527498008 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On 26 June 2012 10:37, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:

2012-06-26 =E0 09:37, = Wojciech Dec:

On 26 June 2012 09:13, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:

Le 2012-06-26 =E0 = 08:04, Wojciech Dec a =E9crit :

On 25 June 2012 17:28, R=E9mi= Despr=E9s <despres.remi@laposte.net> wrote:
=
...
Having asked several times for a list of substantial evolutions from = previous MAP drafts, with their justifications, and having received no = answer, I see this statement as an indirect but first = answer.

Woj> You were provided with an answer (pls see Ole's = mail).

Could you please = indicate which = one?

Since you claim there has been an answer, and suggest I find = it, I suppose you can find it yourself.
=3D> Please answer = (or implicitly acknowledge that the list of MAP substantial evolutions = is still awaited).



It's a short list :
- MAP-E and MAP-T = drafts have been merged.

- Handling of the corner cases regarding DMR but no BMR = added

An explanation on this = point would be appreciated.
- = ability to disable NAT functionality (which has a normative MUST in the = draft)


But it doesn't seem acceptable (*):
- AFAIK, the added 5th parameter of basic mapping rules is more than = editorial

Woj> Please indicate what the new = parameter in your opinion = is.

In Section 5, "Forwarding mode" has become a BMR 5th = parameter. 
In Section 5 of the mdt draft of january 30, = there were only 4 BMR parameter.

Anything = missed?

Ok, so fair point. MAP-E and -T have been merged in the draft, = based on previous feedback from the WG incl discussions at the last = meeting. We thought having less drafts is more as was discussed at the = last meeting. The updated draft also highlights how much commonality = there is.

- A parameter = PER DOMAIN was an obvious result of a merger.
- But a = parameter PER RULE is a significant = novelty.
OK?

That was not intended, and appears to be a = genuine mistake in draft-00. Thanks for spotting.
It is a parameter = per domain, as discussed on the design team = alias.

The specification = is AFAIK viable with this 5th parameter, and some may find it = useful. 
Since it is now a WG matter, individuals who = would like to delete it from the specification should propose it on the = mailing list. 
(FWIW, I have personally no objection to = its = deletion).


RD

=



-Woj.

We're welcome to suggestions on how to provide information on which = transport mode to use, or if the merger is no = desired. 

- I didn't find the equivalent of the following sentence in previous = drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in = the 1:1 case, and with no IPv4 address and port range configured by = other  means, MUST disable its NAT44 functionality."

Is there such an = equivalent?
Please answer (not answering the question = isn't a way to eliminate = it).

Equivalent of what?

Is there in previous = drafts the sentence above (or an equivalent) "A MAP-E CE... MUST disable = its NAT44 functionality."? 
- If yes, please indicate = where.
- If not, IT IS an evolution, to be identified as = such.


Note: I asked you how you would propose dealing with the DMR but no BMR = corner case, and await your proposal..  =

- In the 4rd = draft, appendix D, there is a deployment example with only on = mapping rule (the BR mapping rule, AKA the DMR in your MAP draft).
- If this isn't sufficient to answer your concern, please point to = the mail in which you asked the unanswered = question. 

=
Subject closed, I = suppose.



= --Apple-Mail-4--527498008-- From leaf.y.yeh@huawei.com Tue Jun 26 04:08: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 E35CA21F8606 for ; Tue, 26 Jun 2012 04:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.149 X-Spam-Level: X-Spam-Status: No, score=-8.149 tagged_above=-999 required=5 tests=[AWL=-2.450, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sllyJdApOL4n for ; Tue, 26 Jun 2012 04:08:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1783221F8604 for ; Tue, 26 Jun 2012 04:08:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHF39933; Tue, 26 Jun 2012 07:08:44 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 04:07:34 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 04:07:36 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Tue, 26 Jun 2012 19:07:33 +0800 From: Leaf yeh To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Wojciech Dec Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNU4GlvXQkGZ+BzUaqpjWjqo0dYZcMbswQ Date: Tue, 26 Jun 2012 11:07:32 +0000 Message-ID: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <76F73D2D-B6FA-48A2-9748-073ABDB30641@laposte.net> <2EF2BB9F-5EC5-4B8D-96E4-81D9E532CEEC@laposte.net> In-Reply-To: <2EF2BB9F-5EC5-4B8D-96E4-81D9E532CEEC@laposte.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.160] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 11:08:46 -0000 RD - The specification is AFAIK viable with this 5th parameter, and some ma= y find it useful. Since it is now a WG matter, individuals who would like to delete it from t= he specification should propose it on the mailing list.=A0 (FWIW, I have personally no objection to its deletion). I suggested one code for the forwarding mode (mesh or H&S) in BMR on the MD= T ML before, because I supposed MAP-base intended to support the mode of Hu= b&Spoke. Best Regards, Leaf From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of R=E9mi Despr=E9s Sent: Tuesday, June 26, 2012 5:54 PM To: Wojciech Dec Cc: softwires WG; Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT ref= lect the consensus from the WG 2012-06-26 =E0 10:50, Wojciech Dec: On 26 June 2012 10:37, R=E9mi Despr=E9s wrote: 2012-06-26 =E0 09:37, Wojciech Dec: On 26 June 2012 09:13, R=E9mi Despr=E9s wrote: Le 2012-06-26 =E0 08:04, Wojciech Dec a =E9crit : On 25 June 2012 17:28, R=E9mi Despr=E9s wrote: ... Having asked several times for a list of substantial evolutions from previo= us MAP drafts, with their justifications, and having received no answer, I = see this statement as an indirect but first answer. Woj> You were provided with an answer (pls see Ole's mail). Could you please indicate which one? Since you claim there has been an answer, and suggest I find it, I suppose = you can find it yourself. =3D> Please answer (or implicitly acknowledge that the list of MAP substant= ial evolutions is still awaited). http://www.ietf.org/mail-archive/web/softwires/current/msg04358.html Sorry, but I am lost! This reference is that of my query, not that of an answer by Ole. It's a short list :=20 - MAP-E and MAP-T drafts have been merged.=20 - Handling of the corner cases regarding DMR but no BMR added An explanation on this point would be appreciated. Which sentences of the draft deal with this? - Non normative text regarding use (eg backwards compatibility) added. A less "short" list has yet to be made. It should include AFAIK: - 5th DMR parameter addition (as long as the deletion=A0you suggest below= =A0hasn't been discussed an approved in the WG) - ability to disable NAT functionality (which has a normative MUST in the d= raft) But it doesn't seem acceptable (*): - AFAIK, the added 5th parameter of basic mapping rules is more than editor= ial Woj> Please indicate what the new parameter in your opinion is. In Section 5, "Forwarding mode" has become a BMR 5th parameter.=A0 In Section 5 of the mdt draft of january 30, there were only 4 BMR paramete= r. Anything missed? Ok, so fair point. MAP-E and -T have been merged in the draft, based on pre= vious feedback from the WG incl discussions at the last meeting. We thought= having less drafts is more as was discussed at the last meeting. The updat= ed draft also highlights how much commonality there is. - A parameter PER DOMAIN was an obvious result of a merger. - But a parameter PER RULE is a significant novelty. OK? That was not intended, and appears to be a genuine mistake in draft-00. Tha= nks for spotting. It is a parameter per domain, as discussed on the design team alias. The specification is AFAIK viable with this 5th parameter, and some may fin= d it useful.=A0 Since it is now a WG matter, individuals who would like to delete it from t= he specification should propose it on the mailing list.=A0 (FWIW, I have personally no objection to its deletion). RD -Woj. We're welcome to suggestions on how to provide information on which transpo= rt mode to use, or if the merger is no desired.=A0 - I didn't find the equivalent of the following sentence in previous drafts= : "A MAP-E CE provisioned with only a Default Mapping Rule, as in the 1:1 c= ase, and with no IPv4 address and port range configured by other =A0means, = MUST disable its NAT44 functionality." Is there such an equivalent? Please answer=A0(not answering the question isn't a way to eliminate it). Equivalent of what? Is there in previous drafts the sentence above (or an equivalent) "A MAP-E = CE... MUST disable its NAT44 functionality."?=A0 - If yes, please indicate where. - If not, IT IS an evolution, to be identified as such. Note: I asked you how you would propose dealing with the DMR but no BMR cor= ner case, and await your proposal..=A0=20 - In=A0the 4rd draft,=A0appendix D, there is a deployment example with only= on mapping rule (the BR mapping rule, AKA the DMR in your MAP draft). - If this isn't sufficient to answer your concern, please point to the mail= in which you asked the unanswered question.=A0 Subject closed, I suppose. =A0 Thanks, RD From leaf.y.yeh@huawei.com Tue Jun 26 04:27: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 00BB321F861F for ; Tue, 26 Jun 2012 04:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.374 X-Spam-Level: X-Spam-Status: No, score=-7.374 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QmmZzF0cHTw for ; Tue, 26 Jun 2012 04:27:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBE521F8625 for ; Tue, 26 Jun 2012 04:27:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHM67095; Tue, 26 Jun 2012 07:27:35 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 04:27:23 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 04:27:25 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 26 Jun 2012 19:27:17 +0800 From: Leaf yeh To: Satoru Matsushima , Peng Wu Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNUrGklzGR1GV1KUqRtNoiHszFDJcMc02Q Date: Tue, 26 Jun 2012 11:27:16 +0000 Message-ID: References: <4F63FEA2-B20C-4772-A9D6-EF87DFAB7134@gmail.com> <2BB8471B-E912-49BF-BF77-6F7FE8A6D742@gmail.com> <97A4D74A-A531-4F83-B281-86973A3139A5@gmail.com> <570C97A3-D641-47EB-B0EB-B75ECD7E9EC4@gmail.com> In-Reply-To: <570C97A3-D641-47EB-B0EB-B75ECD7E9EC4@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.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 11:27:36 -0000 Satoru - Let's think that a CE provisioned with following BMR comes from MA= P DHCPv6 options. BMR: o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} =20 o Rule-ipv4-prefix : x.x.x.x/32 o EA-length : 0 o Port-param option : {PSID/length} This BMR could be a LW46 provisioning means. If the intention is only for the independence provision of IPv4 address ass= ignment and IPv6 prefix delegation, I guess we could also think the alterna= tive scenario that CE provisioned with following BMR comes from MAP DHCPv6 = options. BMR: o Rule-ipv6-prefix : the length of Rule-ipv6-prefix + PSID length =3D the= length of CE's IPv6 delegated prefix o Rule-ipv4-prefix : x.x.x.x/32 o EA-length : PSID length That means PSID still be embedded in the CE's IPv6 delegated prefix. Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Satoru Matsushima Sent: Monday, June 25, 2012 5:05 PM To: Peng Wu Cc: softwires@ietf.org; Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT ref= lect the consensus from the WG Hi Peng, On 2012/06/25, at 17:50, Peng Wu wrote: >> Hmm, I've read 'draft-cui-softwire-b4-translated-ds-lite' as you called = 'lightweight 4over6'. LW46 for short, it looks me that MAP just provides LW= 46 a provisioning means which would be described in the section 5, or appen= dix section because following text described in section 5: >>=20 >> "Other optional alternatives to retrieve the public address and port- >> set also exist. The specific protocol extensions are out of scope in >> this document, however some alternatives are mentioned in the Appendix >> section." > Let me take a step further following your direction: > You are saying MAP is a provisioning mean in lw4over6. Then, what exactly= ? > With IPv4-IPv6 addressing independency, you proivde an IPv4 address > and port set, within another DHCPv6 option? > No BMR, No FMR, No embedding address. Look at what's left. how is this > even similar to MAP? Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 = options. BMR: o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o Rule-ipv4-prefix : x.x.x.x/32 o EA-length : 0 o Port-param option : {PSID/length} This BMR could be a LW46 provisioning means. cheers, --satoru _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From sumanshailesh@gmail.com Tue Jun 26 05:07: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 8B8CF21F863E for ; Tue, 26 Jun 2012 05:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYdgO67fAuyu for ; Tue, 26 Jun 2012 05:07:18 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDF021F8627 for ; Tue, 26 Jun 2012 05:07:18 -0700 (PDT) Received: by bkty8 with SMTP id y8so4600690bkt.31 for ; Tue, 26 Jun 2012 05:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=U21uXOMEgekktNvNrwtV5IT42YGDykUYBLrwGMf/wYI=; b=sbxqqqNAnWyMIY77ZqBmpvTe1kvCZluNHqPGT1QGJ0z3UHGvPtA8BhFzFC0pLhWgfr qiL+NtaXnbzbGMaOiy/c+a8Q1NguKi/OUwaZMJ4+YdRp0+M6Zu2grKSUrz9rsxu/EJet CM8eIsMHsYea84RYk791798iCX6RQPOHt99apVHO1BDfKSSpecU7yl50KaR1zeoHhaxn w1GdBIlt0jYeDzv9iN2SFjsppoJNrVBxZaExz+SVHUpjAo3dM3if9FwIY4XEeffY8JBV BRtqvHM4J9m9Z2QCh1S0w4e5/jB1gLdElDnf+UqWCEwy4ToFJxpSf0mH8HVaXhNWJvLP E7jg== MIME-Version: 1.0 Received: by 10.152.148.199 with SMTP id tu7mr16019695lab.43.1340712437272; Tue, 26 Jun 2012 05:07:17 -0700 (PDT) Received: by 10.114.12.129 with HTTP; Tue, 26 Jun 2012 05:07:17 -0700 (PDT) Date: Tue, 26 Jun 2012 17:37:17 +0530 Message-ID: From: Shailesh Suman To: softwires@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 26 Jun 2012 12:07:19 -0000 Hi All, I see few points of this draft need to be addressed to address complete solution. 1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and uPrefix64) packets silently. There can be scenarios, where some of LAN Multicast receivers are supporting native IPv6. How will such packets reach the v6 Multicast Receivers, in case they get silently discarded by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast Receivers in LAN should also be looked into. 2). It is also possible for LAN to have Multicast Originators rather than only Multicast Receivers. This solution currently restricts the scope to downstream Multicast traffic only and there should be some exploration for Originators as well. 3). Fragmentation issues can surface for any transition techniques. However for DS-Lite (applicable to Unicast traffic only) Path-MTU can come for rescue. But for Multicast traffic Path-MTU can not be run. This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4 respectively. I think, addressing these points would be vital for this I.D. Regards -Shailesh > Message: 1 > Date: Tue, 26 Jun 2012 07:36:41 +0800 > From: Jacni Qin > To: sarikaya@ieee.org > Cc: Softwires-wg , Behcet Sarikaya > =A0 =A0 =A0 =A0 > Subject: Re: [Softwires] [SPAM] Re: WG last call on > =A0 =A0 =A0 =A0draft-ietf-softwire-dslite-multicast-02 > Message-ID: <4FE8F609.1040407@jacni.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Re-, > > On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: >> On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin =A0wrote: >>> Hi Behcet, all, >>> >>> >>> On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: >>>> Folks, >>>> >>>> We have published revised version of our draft on multicast extensions >>>> to DS-Lite at >>>> >>>> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt >>>> >>> It's been discussed on the list and in the 81st meeting, and concluded = quite >>> clearly by the WG why this is abandoned. >>> It tunnels the IGMP packets upwards, replicates the multicast traffic "= per >>> tunnel", opposite to the property of multicast technology. And these ar= e >>> problems we're trying to solve. >>> >> =A0 draft-ietf-softwire-dslite-multicast-02 has nothing to do with >> DS-Lite and therefore it is not a DS-Lite multicast extensions >> document as the charter requires. >> OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates >> multicast into DS-Lite tunnel. >> >> It is not against multicast technology. > In this way, the efficiency is lost. If operators put the AFTR box > deeply in the network, far from the end users, as you process the > singling messages and replicate of traffic per tunnel, the network and > the box will crash because of the huge burden. > >>> There is no necessity to initiate that kind of discussion once again. >>> >> I did not start this discussion. Please check the list. > > Again please see above, or check the archive and the offlist messages > where we've explained it to you in detail. > > > Cheers, > Jacni > >> >> Regards. >> >> Behcet >> >>> Cheers, >>> Jacni >>> >>> >>>> We think that this draft should be part of >>>> draft-ietf-softwire-dslite-multicast. >>>> >>>> Regards, >>>> >>>> Behcet >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> > > > From yiu_lee@cable.comcast.com Tue Jun 26 06:41: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 97CAF21F85F7 for ; Tue, 26 Jun 2012 06:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WnUf+rwXi4x for ; Tue, 26 Jun 2012 06:41:42 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 962A621F85F1 for ; Tue, 26 Jun 2012 06:41:41 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.17226898; Tue, 26 Jun 2012 09:31:49 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0283.003; Tue, 26 Jun 2012 09:41:35 -0400 From: "Lee, Yiu" To: Shailesh Suman , "softwires@ietf.org" Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Thread-Index: AQHNU6FnetqecmzkXkSeakpG/Let2A== Date: Tue, 26 Jun 2012 13:41:35 +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.2.120421 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3423548494_278504" MIME-Version: 1.0 Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 26 Jun 2012 13:41:42 -0000 --B_3423548494_278504 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Shailesh, Thanks very much of reviewing the draft. Please read comments inline: On 6/26/12 8:07 AM, "Shailesh Suman" wrote: >Hi All, > > I see few points of this draft need to be addressed to address >complete solution. > >1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and >uPrefix64) packets silently. There can be scenarios, where some of LAN >Multicast receivers are supporting native IPv6. How will such packets >reach the v6 Multicast Receivers, in case they get silently discarded >by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast >Receivers in LAN should also be looked into. [YL] mB4 is a logical function and should be implemented along side with normal MLD listener in the same CPE. If the multicast address header contains mPrefix64 and uPrefix64, it should pass to mB4. Otherwise, the normal MLD listener will handle it. That sentence tries to prevent normal multicast message from accidentally passing to mB4. > >2). It is also possible for LAN to have Multicast Originators rather >than only Multicast Receivers. This solution currently restricts the >scope to downstream Multicast traffic only and there should be some >exploration for Originators as well. [YL] Our main focus on this to support home user (i.e. IPTV service). You can find more discussion in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. This is why we limit the scope. We can add more words to expect our motives. > >3). Fragmentation issues can surface for any transition techniques. >However for DS-Lite (applicable to Unicast traffic only) Path-MTU can >come for rescue. But for Multicast traffic Path-MTU can not be run. >This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4 >respectively. > > I think, addressing these points would be vital for this I.D. [YL] I agree. We will propose some text in next revision. Thanks, Yiu > >Regards >-Shailesh > > >> Message: 1 >> Date: Tue, 26 Jun 2012 07:36:41 +0800 >> From: Jacni Qin >> To: sarikaya@ieee.org >> Cc: Softwires-wg , Behcet Sarikaya >> >> Subject: Re: [Softwires] [SPAM] Re: WG last call on >> draft-ietf-softwire-dslite-multicast-02 >> Message-ID: <4FE8F609.1040407@jacni.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Re-, >> >> On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: >>> On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin wrote: >>>> Hi Behcet, all, >>>> >>>> >>>> On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: >>>>> Folks, >>>>> >>>>> We have published revised version of our draft on multicast >>>>>extensions >>>>> to DS-Lite at >>>>> >>>>> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt >>>>> >>>> It's been discussed on the list and in the 81st meeting, and >>>>concluded quite >>>> clearly by the WG why this is abandoned. >>>> It tunnels the IGMP packets upwards, replicates the multicast traffic >>>>"per >>>> tunnel", opposite to the property of multicast technology. And these >>>>are >>>> problems we're trying to solve. >>>> >>> draft-ietf-softwire-dslite-multicast-02 has nothing to do with >>> DS-Lite and therefore it is not a DS-Lite multicast extensions >>> document as the charter requires. >>> OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates >>> multicast into DS-Lite tunnel. >>> >>> It is not against multicast technology. >> In this way, the efficiency is lost. If operators put the AFTR box >> deeply in the network, far from the end users, as you process the >> singling messages and replicate of traffic per tunnel, the network and >> the box will crash because of the huge burden. >> >>>> There is no necessity to initiate that kind of discussion once again. >>>> >>> I did not start this discussion. Please check the list. >> >> Again please see above, or check the archive and the offlist messages >> where we've explained it to you in detail. >> >> >> Cheers, >> Jacni >> >>> >>> Regards. >>> >>> Behcet >>> >>>> Cheers, >>>> Jacni >>>> >>>> >>>>> We think that this draft should be part of >>>>> draft-ietf-softwire-dslite-multicast. >>>>> >>>>> Regards, >>>>> >>>>> Behcet >>>>> _______________________________________________ >>>>> 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 --B_3423548494_278504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSWNmp+ TEm14u5asrGsALEaAv6PFTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MjYxMzQxMzNaMA0GCSqGSIb3DQEBAQUABIIBALu++nTrv34L1B79msZykdUy Pl//loAQ2i8OiW9YgwfOb2sGbrRrOCY5pvXuZ8J151aIQQovJnOxhNksbvCQ2aEOLB7TRL9y YOL9XVi2scSpythBPl4Bc4PbZs1f1NMRQ2sHOAR/TYNy/tEaZnIddZEr0sXL49APXqcZEk+t CYGX0CmQRzGi/CinuorDaVzB2V2aW6XpRkFTDFGFwacrHXUIV/2cJRVG6pcnS+/F/Xc7sqgZ YQso4eCOlNwykuES309zmDFi4bvgKcLhYOU06p8X2PULOtR5vXzN9tAN5/0suwJU4YcY11lx Dq8dZ7rOzedir5tH0d4qQ5ldPxXr0RE= --B_3423548494_278504-- From simon.perreault@viagenie.ca Tue Jun 26 06:58:04 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 A7CA121F8518 for ; Tue, 26 Jun 2012 06:58:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgIrcvUFFzuh for ; Tue, 26 Jun 2012 06:58:04 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 15BF721F84FE for ; Tue, 26 Jun 2012 06:58:04 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c064:b500:f896:300c:716f]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7E246400F0 for ; Tue, 26 Jun 2012 09:58:03 -0400 (EDT) Message-ID: <4FE9BFEB.7070701@viagenie.ca> Date: Tue, 26 Jun 2012 09:58:03 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <76F73D2D-B6FA-48A2-9748-073ABDB30641@laposte.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] MAP design team [Was: Re: [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG] 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, 26 Jun 2012 13:58:04 -0000 On 2012-06-26 04:50, Wojciech Dec wrote: > - A parameter PER DOMAIN was an obvious result of a merger. > - But a parameter PER RULE is a significant novelty. > OK? > > That was not intended, and appears to be a genuine mistake in draft-00. > Thanks for spotting. > It is a parameter per domain, as discussed on the design team alias. Now that MAP is a softwires WG item, wouldn't it be best for all to move MAP discussions to the softwires mailing list? 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 bingxuere@gmail.com Tue Jun 26 08:12: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 271C721F8559 for ; Tue, 26 Jun 2012 08:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgLKU9iDM7Br for ; Tue, 26 Jun 2012 08:12:27 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07821F84FC for ; Tue, 26 Jun 2012 08:12:27 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id g16so22421ghb.31 for ; Tue, 26 Jun 2012 08:12:27 -0700 (PDT) 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=YPu954r6DrklP+OmCO9L8NWT4+FEw6TDCvA97TFVwgU=; b=iuIVCG9AlL/dfLbCgF2UORCIykt+f5kB0asLBBeGr8afyeYXLMc0BONMhZg0G8ZeTR Otg4Pth6HHxzje2DvRDvtDLvT6znZTK6sAAwO+1H3EWbokNbuPYIJqce9BvKqncsqycr Bhysmob06DQ7gckMTL/gumhG4jS383kOl57QflwcL45UQZD3OENga5zKYbrzfGfx8lbD oP4SAgVwT9B7ztaC1V8dQKl2UtaHbl+CKmBZHyfNFEpxF4+nT0kFnYfdwHS3AJHJnpSu QP5vulTzVJki78pdiB2o4NLGClm5kTotENS0wP1E1Uuw579Fqc3Y+7tyiXTIRJiZiFHD TNpw== Received: by 10.50.181.225 with SMTP id dz1mr11358483igc.2.1340723546211; Tue, 26 Jun 2012 08:12:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Tue, 26 Jun 2012 08:11:45 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Tue, 26 Jun 2012 23:11:45 +0800 Message-ID: To: Wojciech Dec Content-Type: multipart/alternative; boundary=14dae9340981b6c5f504c3618652 Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 15:12:28 -0000 --14dae9340981b6c5f504c3618652 Content-Type: text/plain; charset=UTF-8 Agree with Ian. MAP is designed and optimized for algorithmatic address mapping, but not for per-subscriber rule mapping. Actually, the more you would like to solve, more complicated it will become. I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E, map-dhcp all becomes useless or not optimized. And I will not deploy per-subscriber stateful and stateless solutions at the same. So I encourage two seperated approaches optimized for different scenarios. It will be good for both. Do we really all forget about the "KISS" principle ? Best wishes Qiong On Tue, Jun 26, 2012 at 3:55 PM, Wojciech Dec wrote: > > Well, a couple of observations: > A) MAP allows you to optimize complexity in not having to deal with per > subscriber rules in cases where this is feasible. > B) You're referring to data representation as an operational problem, > which if so, actually applies to any solution incl LW46 that transmits > port-range info to a client. I.e. "Whatever support staff" needs to be > schooled to use some logic to glean useful port information from the data > sent to a client > C) It is very easy to represent MAP data as port range info on routers, > tools, etc. > > -Woj. > > >> >> cheers, >> --satoru >> >> ------------------------------ >> >> >> >> _______________________________________________ >> 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 > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae9340981b6c5f504c3618652 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree with Ian.

MAP is designed and optimized for algorithmatic addr= ess mapping, but not for per-subscriber rule mapping. Actually, the more yo= u would like to solve, more complicated it will become.

I will certa= inly not buy MAP for per-subscriber case when MAP-T, MAP-E, map-dhcp all be= comes useless or not optimized. And I will not deploy per-subscriber statef= ul and stateless solutions at the same.

So I encourage two seperated approaches optimized for different scenarios. It will be good for both.

Do we = really all forget about the "KISS" principle ?

Best wishes=
Qiong

On Tue, Jun 26, 2012 at 3:55 PM, Wo= jciech Dec <wdec.ietf@gmail.com> wrote:

Well, a couple of observations:
A) M= AP allows you to optimize complexity in not having to deal with per subscri= ber rules in cases where this is feasible.
B) You're referring to d= ata representation as an operational problem, which if so, actually applies= to any solution incl LW46 that transmits port-range info to a client. I.e.= "Whatever support staff" needs to be schooled to use some logic = to glean useful port information from the data sent to a client
C) It is very easy to represent MAP data as port range info on routers, too= ls, etc.

-Woj.
=C2=A0
=
cheers,
--satoru

--------------------= ----------


=

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
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

--14dae9340981b6c5f504c3618652-- From satoru.matsushima@gmail.com Tue Jun 26 08:54: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 1079C21F8597 for ; Tue, 26 Jun 2012 08:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI4nMxSz0qrg for ; Tue, 26 Jun 2012 08:54:10 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC6D21F8593 for ; Tue, 26 Jun 2012 08:54:10 -0700 (PDT) Received: by dacx6 with SMTP id x6so70438dac.31 for ; Tue, 26 Jun 2012 08:54:07 -0700 (PDT) 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=URays45zNHrPeRtK+6EGwQI09PBNQAu93VEzdRTqCKE=; b=UcDKX/L7z6kyBKU/KYzpD9xyXdarYH61xHxMTBpxNJgU5rWlT54JD12F15tEhQjUZm LbjLmOACRzgllnXXWZLbrCTm9zAZDrHpkjRoT2bwNoc0TJOz5UBx22z0+i4zOKPx0IIU 7WHDXHViEVefnT1aJG70ueYlcBAst2LJhE0cwC3mbyR58g8jExGYqQKLUL699j+smlso UbgFFHImaC2uEAtwaETvH1UBXzmcnG1HEcUewlK/HgXYE2yaELWtSZUrpN66of5tDfyq UgFehMDTW3RzLv7HD0dlhUthtfhIkp3b2+5NbiZOKd04DfZBjsA/FkUPo5MbxYvwyvWn viVA== Received: by 10.68.200.98 with SMTP id jr2mr53002460pbc.81.1340726044081; Tue, 26 Jun 2012 08:54:04 -0700 (PDT) Received: from ?IPv6:2400:2411:8900::c4d3:cb9d:88a0:274b? ([2400:2411:8900:0:c4d3:cb9d:88a0:274b]) by mx.google.com with ESMTPS id nv6sm12203546pbc.42.2012.06.26.08.54.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 08:54:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 00:54:00 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> References: To: Qiong X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 15:54:11 -0000 On 2012/06/27, at 0:11, Qiong wrote: > Agree with Ian. >=20 > MAP is designed and optimized for algorithmatic address mapping, but = not for per-subscriber rule mapping. Actually, the more you would like = to solve, more complicated it will become. >=20 > I will certainly not buy MAP for per-subscriber case when MAP-T, = MAP-E, map-dhcp all becomes useless or not optimized. And I will not = deploy per-subscriber stateful and stateless solutions at the same.=20 >=20 > So I encourage two seperated approaches optimized for different = scenarios. It will be good for both. >=20 > Do we really all forget about the "KISS" principle ? Not quite. I believe that the most motivate to start this work in the wg has = destined MAP to be 'multi-protocol socket v2.0' that's what the former = wg chair wished to. Do you remember that? cheers, --satoru From yiu_lee@cable.comcast.com Tue Jun 26 10:38:56 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 1510621F85A2 for ; Tue, 26 Jun 2012 10:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.031 X-Spam-Level: X-Spam-Status: No, score=-104.031 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol+VhWZKt3JD for ; Tue, 26 Jun 2012 10:38:55 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5B86121F85A1 for ; Tue, 26 Jun 2012 10:38:55 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.22745999; Tue, 26 Jun 2012 11:21:39 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.88]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Tue, 26 Jun 2012 13:38:50 -0400 From: "Lee, Yiu" To: Satoru Matsushima , Qiong Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNU8KLTPlGgvfoI0KmrAqx769azg== Date: Tue, 26 Jun 2012 17:38:49 +0000 Message-ID: In-Reply-To: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3423562729_1099208" MIME-Version: 1.0 Cc: "softwires@ietf.org" , "ian.farrer@telekom.de" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 26 Jun 2012 17:38:56 -0000 --B_3423562729_1099208 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Satoru, Did you propose the WG to revise the charter to add this work? I am sure the current charter does not reflect this. Regards, Yiu On 6/26/12 11:54 AM, "Satoru Matsushima" wrote: >'multi-protocol socket v2.0' --B_3423562729_1099208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSw01Rk w4NNJwLlez/BQuGf53PjlzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA2MjYxNzM4NDdaMA0GCSqGSIb3DQEBAQUABIIBACoLZVwDhKd1BSD+C4VFaDkf imcdkZ9leMK32NpRQ/N+POIiHMD5dcl/C4bSRdGDlLq+PSvta6+Qp6eFSNa5aK6Pr8cixJZ/ QFLniDa+Q794pmbwTEjTzZRZZgHKn1dn+Lyu4muGAATOj9WXk03lP45AHwx6rePM80sPCD0h ws6SruID+ibC2QT5nodSCbTu2+ykc/BynxQOBYwcrupNPIsg7g6fbwvh49GmaLjzt6W5/pW3 tPD2S8A/PJ8X5wxOcj2IY1KYrR0Mg1uvKaXzp6URhpof8vT+rk1a1PcfXZoNFCkf0u2ZXLL2 LZ4odKxFsOF/vK9GXYO5gahkaMIEUnE= --B_3423562729_1099208-- From fibrib@gmail.com Tue Jun 26 18:48: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 DDBDC11E80FD for ; Tue, 26 Jun 2012 18:48:45 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r62vhCvjrgRW for ; Tue, 26 Jun 2012 18:48:45 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2095B11E8085 for ; Tue, 26 Jun 2012 18:48:45 -0700 (PDT) Received: by qcmt36 with SMTP id t36so301243qcm.15 for ; Tue, 26 Jun 2012 18:48:44 -0700 (PDT) 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=XcWThC8Adx7JSImog+KNaRyrUGA5/Ncrsol5t1fdRgw=; b=lt3c5MgdqIqPDFnlMc2CxBneonuRDOfIsCkgwSduBamftJk3PzTxE7WugdnTy48Pgd nPdVsvKzEPT25MsbQFDGTdHyA4MKKPG4YWS/ZgEAeSz4cfzqzcXJ7tXcJDWCFRNbLLBv k0BUF8Q3sXTRnvG9SmTx/M8WklwXgmGaHrT2RtEMGQsOi/q6IauVdtMGsJ1/bsY6tjiM oqYMErwxRwUzuXlCsVWPxgqV+kvFsRliej7jxloOMO5TnScZQUM46sXF8C2kXBFinNS+ 6LrAviDHS9KZx6So6Sc9Wr80ivW65+MA439MR2vx6p4R9/wbkeZR1IMG4uaQovJFLQc5 ByJA== MIME-Version: 1.0 Received: by 10.224.217.201 with SMTP id hn9mr28528165qab.63.1340761724482; Tue, 26 Jun 2012 18:48:44 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Tue, 26 Jun 2012 18:48:44 -0700 (PDT) In-Reply-To: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> Date: Wed, 27 Jun 2012 01:48:44 +0000 Message-ID: From: Maoke To: Satoru Matsushima Content-Type: multipart/alternative; boundary=20cf306849ef50f2e504c36a6aa4 Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 01:48:46 -0000 --20cf306849ef50f2e504c36a6aa4 Content-Type: text/plain; charset=ISO-8859-1 dear Satoru, 2012/6/26 Satoru Matsushima > On 2012/06/27, at 0:11, Qiong wrote: > > > Agree with Ian. > > > > MAP is designed and optimized for algorithmatic address mapping, but not > for per-subscriber rule mapping. Actually, the more you would like to > solve, more complicated it will become. > > > > I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E, > map-dhcp all becomes useless or not optimized. And I will not deploy > per-subscriber stateful and stateless solutions at the same. > > > > So I encourage two seperated approaches optimized for different > scenarios. It will be good for both. > > > > Do we really all forget about the "KISS" principle ? > > Not quite. > I believe that the most motivate to start this work in the wg has destined > MAP to be 'multi-protocol socket v2.0' that's what the former wg chair > wished to. Do you remember that? > i like the philosophy of "multi-protocol socket". however, i moderately doubt the "multi-protocol socket v2.0" is a perfect plan for every cases. in a quite good hotel, we see typically one 'multi-protocol socket' while a lot of local-standard sockets. i never think it will make me happy if i see every socket in my room is *multi-protocol*, occupying much spaces and quite noticeable on the walls. we need one to deploy somewhere not the only one type to deploy anywhere. ;-) therefore i understand the motivation of the wg is making a unified solution covering both encapsulation and translation in the framework of stateless, WITHOUT the exclusiveness against other solutions, more specifically suitable for a certain use case. cheers, maoke > > cheers, > --satoru > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf306849ef50f2e504c36a6aa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Satoru,=A0

2012/6/26 Satoru Matsushi= ma <satoru.matsushima@gmail.com>
On 2012/06/27, at 0:11, Qiong wrote:

> Agree with Ian.
>
> MAP is designed and optimized for algorithmatic address mapping, but n= ot for per-subscriber rule mapping. Actually, the more you would like to so= lve, more complicated it will become.
>
> I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E= , map-dhcp all becomes useless or not optimized. And I will not deploy per-= subscriber stateful and stateless solutions at the same.
>
> So I encourage two seperated approaches optimized for different scenar= ios. It will be good for both.
>
> Do we really all forget about the "KISS" principle ?

Not quite.
I believe that the most motivate to start this work in the wg has destined = MAP to be 'multi-protocol socket v2.0' that's what the former w= g chair wished to. Do you remember that?

i like the philosophy of "multi-protocol socket". however, i= moderately doubt the "multi-protocol socket v2.0" is a perfect p= lan for every cases. in a quite good hotel, we see typically one 'multi= -protocol socket' while a lot of local-standard sockets. i never think = it will make me happy if i see every socket in my room is *multi-protocol*,= occupying much spaces and quite noticeable on the walls. we need one to de= ploy somewhere not the only one type to deploy anywhere. ;-)

therefore i understand the motivation of the wg is maki= ng a unified solution covering both encapsulation and translation in the fr= amework of stateless, WITHOUT the exclusiveness against other solutions, mo= re specifically suitable for a certain use case.=A0

cheers,
maoke
=A0

cheers,
--satoru

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

--20cf306849ef50f2e504c36a6aa4-- From leaf.y.yeh@huawei.com Tue Jun 26 18:58: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 CB35811E8101 for ; Tue, 26 Jun 2012 18:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-5uDqOWOjbJ for ; Tue, 26 Jun 2012 18:58:05 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EB1D511E8100 for ; Tue, 26 Jun 2012 18:58:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHN14445; Tue, 26 Jun 2012 21:58:04 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 18:57:02 -0700 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 18:56:59 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Wed, 27 Jun 2012 09:56:55 +0800 From: Leaf yeh To: Simon Perreault , "softwires@ietf.org" Thread-Topic: [Softwires] MAP design team [Was: Re: [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG] Thread-Index: AQHNU6O99DFH49z9gEa030cuUom5t5cNaEHw Date: Wed, 27 Jun 2012 01:56:54 +0000 Message-ID: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <76F73D2D-B6FA-48A2-9748-073ABDB30641@laposte.net> <4FE9BFEB.7070701@viagenie.ca> In-Reply-To: <4FE9BFEB.7070701@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] MAP design team [Was: Re: [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG] 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, 27 Jun 2012 01:58:05 -0000 +1 for draft-ietf-softwire-map-00 Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Simon Perreault Sent: Tuesday, June 26, 2012 9:58 PM To: softwires@ietf.org Subject: [Softwires] MAP design team [Was: Re: [Softwire] draft-ietf-softwi= re-map-00 does NOT reflect the consensus from the WG] On 2012-06-26 04:50, Wojciech Dec wrote: > - A parameter PER DOMAIN was an obvious result of a merger. > - But a parameter PER RULE is a significant novelty. > OK? > > That was not intended, and appears to be a genuine mistake in draft-00. > Thanks for spotting. > It is a parameter per domain, as discussed on the design team alias. Now that MAP is a softwires WG item, wouldn't it be best for all to move=20 MAP discussions to the softwires mailing list? Thanks, 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 satoru.matsushima@gmail.com Tue Jun 26 19:20: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 BFA3511E80FD for ; Tue, 26 Jun 2012 19:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2ZRE8I1xTXT for ; Tue, 26 Jun 2012 19:20:36 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0CFA11E80EF for ; Tue, 26 Jun 2012 19:20:35 -0700 (PDT) Received: by dacx6 with SMTP id x6so697993dac.31 for ; Tue, 26 Jun 2012 19:20:35 -0700 (PDT) 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=m2M3SXMghSvfUC4ZO/MgKFQi/Ns2fPDEwTV573WwXX4=; b=r5JvEKAzsBzykhUO1ScxQlzZqWeIKag8g5e9+vvInGwPMHia2mS7IvzbjjmnB91hmc R7IYW+e7F/cFhe3hYmRp9mAMxOAuqynvoFZPJ3O8908DwrFPdrRLjw0JqBQTMSdxLq5m UcPgYg7ann8Khcku34ulMYWGlAOgQ4e/CRfh1F2JgxdRPLtfmSs7z9/L2Fxa/iUksMAp RQMc33a3JhUYuL5BaAGOpnwSeRPqs8IzlpADCMDI20IUP7Mj5+4EkkWRSHTll/zL8+Wx 3Lf30XCVcfEqi8O2NZJ854Gj1Rcr9HT9j3zcgqKVThAFSshnvb5MTnNEWYCOdtuYBEh0 1pTg== Received: by 10.68.222.40 with SMTP id qj8mr57439173pbc.139.1340763635475; Tue, 26 Jun 2012 19:20:35 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id he9sm13590780pbc.68.2012.06.26.19.20.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 19:20:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 11:20:30 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> To: Maoke X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 02:20:36 -0000 Hi Maoke, On 2012/06/27, at 10:48, Maoke wrote: > dear Satoru,=20 >=20 > 2012/6/26 Satoru Matsushima > On 2012/06/27, at 0:11, Qiong wrote: >=20 > > Agree with Ian. > > > > MAP is designed and optimized for algorithmatic address mapping, but = not for per-subscriber rule mapping. Actually, the more you would like = to solve, more complicated it will become. > > > > I will certainly not buy MAP for per-subscriber case when MAP-T, = MAP-E, map-dhcp all becomes useless or not optimized. And I will not = deploy per-subscriber stateful and stateless solutions at the same. > > > > So I encourage two seperated approaches optimized for different = scenarios. It will be good for both. > > > > Do we really all forget about the "KISS" principle ? >=20 > Not quite. > I believe that the most motivate to start this work in the wg has = destined MAP to be 'multi-protocol socket v2.0' that's what the former = wg chair wished to. Do you remember that? >=20 > i like the philosophy of "multi-protocol socket". however, i = moderately doubt the "multi-protocol socket v2.0" is a perfect plan for = every cases. in a quite good hotel, we see typically one 'multi-protocol = socket' while a lot of local-standard sockets. i never think it will = make me happy if i see every socket in my room is *multi-protocol*, = occupying much spaces and quite noticeable on the walls. we need one to = deploy somewhere not the only one type to deploy anywhere. ;-) That point would be an operational matter for deploying any standardized = technology. For example, an operator adopt OSPF to use its rich routing = feature but the network is small, the operator does just area 0 routing, = even OSPF allow inter-area routing for scale. Is an another ospf = specification needed for 'OSPF Area 0 Only Routing'? >=20 > therefore i understand the motivation of the wg is making a unified = solution covering both encapsulation and translation in the framework of = stateless, WITHOUT the exclusiveness against other solutions, more = specifically suitable for a certain use case.=20 >=20 Studying each significant use case is quite important. I agree on that = point with no doubt. However, is it IETF business for each use case = specification? cheers, --satoru From fibrib@gmail.com Tue Jun 26 20:28: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 8F0B321F84C8 for ; Tue, 26 Jun 2012 20:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwskVasLi8ZD for ; Tue, 26 Jun 2012 20:28:53 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id D39C321F84A7 for ; Tue, 26 Jun 2012 20:28:52 -0700 (PDT) Received: by qcmt36 with SMTP id t36so331282qcm.15 for ; Tue, 26 Jun 2012 20:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IgG7VQ6Yrm2K2lormu79HFgooBACbO54z3YBXm/PTNw=; b=g3OkEMCQDr+L/FVbmnVRr+wrXvUNk7h6+TME5xzgUWLDarfEcFSWT4e2wkfawuiAL9 jOcFvRi1qbUvr1QGv1Zmkk8vUxFnFixhUDG7tvvD4BajCfEc2EaMtyStWbTNXckVwDee ZC1NXQKo+qqbZ5N43J2gW2hrKq0wgQ6wwVdHN6VZPZY+Eqi3UqdMeZvipnh+lM6jJE3c mRQkbq881JTc9rSdWvJI79c6R4FHNYJv47zD1D9yEAYhRW32ihWGY+u9AXSlNP0gBxaC 11OuexJ50nYkke0JdIaOFQZ+vUJ2mivZtnkMme9nUXMrNTlGQHIPr9OrwUswDRg/K9EW DOcg== MIME-Version: 1.0 Received: by 10.229.136.193 with SMTP id s1mr7960586qct.8.1340767732318; Tue, 26 Jun 2012 20:28:52 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Tue, 26 Jun 2012 20:28:52 -0700 (PDT) Date: Wed, 27 Jun 2012 03:28:52 +0000 Message-ID: From: Maoke To: Softwires-wg Content-Type: multipart/alternative; boundary=00235452e7b069430a04c36bd052 Subject: [Softwires] map-00: review on the mode 1:1 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, 27 Jun 2012 03:28:54 -0000 --00235452e7b069430a04c36bd052 Content-Type: text/plain; charset=ISO-8859-1 hi dear authors, as the map-00 draft contains the normative 1:1 mode statement that is new in comparison to the previous versions, i'd like to ask some technical questions in order to clarify the understanding. Section 4. page 9: MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a MAP domain per subscriber, and the CE is configured in hub and spoke mode, with only a DMR and no other mapping rules. This allows for a mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User IPv6 prefix. Question #1: who is a "subscriber"? the definition is missing. and relatedly, what is the protocol for the subscription? the specification on the protocol is missing too. Question #2: what is the relationship between 1:1 mode, encapsulation mode, translation mode, hub&spoke mode, mesh mode? are they independent to each other, exclusively or not, somehow orthogonal or not? the specification on the "mode" is missing. Question #3: what is the resource for deployment of a "MAP domain"? the MAP spec never define that. however, we kept understanding that the resource for a "MAP domain" includes: - an IPv4 prefix (with prefix length 32 or less) shared by CEs in this domain - an IPv6 prefix (with prefix length 64 or less) delegated to the CEs in this domain with a /64 (or shorter) per CE (as the basic model of prefix d the newly introduced "1:1 mode" obviously abandons this understanding, then an explicit definition on the resource of a "MAP domain" is requested. this is the origin and essential starting point of the MAP deployment. Section 5. page 10: * Forwarding mode Question #4: this appears twice at the definition of BMR and DMR, respectively. though Wojieich and Remi has discussed that in another thread, i would like to confirm: is this mode a domain configuration parameter or a rule parameter? Question #5: does this "forwarding mode" is a enumerate type of {MAP-T, MAP-E, 1:1, hub&spoke, mesh} or else, e.g., {MAP-T, MAP-E} x {1:1, N:1} x {hub&spoke, mesh}, where the "x" is the operator for de Cartesian product of sets? (related to #2) Section 7.1 page 19: In 1:1 mode, the MAP CE is provisioned with only a Default Mapping Rule, and the full IPv4 address/prefix and port range is provisioned using the DHCP option. Question #6: is the CE or the subscriber the receiver of the "full IPv4 address/prefix and port range" (correction: port set) to be provisioned? or does it mean a CE is a subscriber itself in the 1:1 mode? Section 7.3 page 19: A MAP-E CE provisioned with only a Default Mapping Rule, as in the 1:1 case, and with no IPv4 address and port range configured by other means, MUST disable its NAT44 functionality. Question #7: this text is contradictory with Section 7.1. is the DHCP option a sort of "other means" or not, or there's something out of scope of this draft? Question #8: what is the consequence of disabling the NAT44 functionality on CE when a subscriber having a PSID of a share IPv4 address is running behind that CE as a 1:1 mode domain? before all of the above questions and further questions possibly to be generated during the discussion are fully clarified, i cannot help but gently show my disagreement on putting the current draft as working group result. i also hope the MAP spec authors kindly understand with so many uncertainty modifying MAP deployment draft to fit the MAP spec is a mission-impossible for the time being. thanks and regards, maoke --00235452e7b069430a04c36bd052 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi dear authors,=A0

as the map-00 draft c= ontains the normative 1:1 mode statement that is new in comparison to the p= revious versions, i'd like to ask some technical questions in order to = clarify the understanding.=A0

Section 4. page 9:

MAP can als= o be provisioned in 1:1 mode. In 1:1 mode the BR has a
MAP domain pe= r subscriber, and the CE is configured in hub and spoke
mode, with on= ly a DMR and no other mapping rules. This allows for a
mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User
= IPv6 prefix.

Question #1: who is a "subscr= iber"? the definition is missing. and relatedly, what is the protocol = for the subscription? the specification on the protocol is missing too.

Question #2: what is the relationship between 1:1 mode,= encapsulation mode, translation mode, hub&spoke mode, mesh mode? are t= hey independent to each other, exclusively or not, somehow orthogonal or no= t? the specification on the "mode" is missing.=A0

Question #3: what is the resource for deployment of a &= quot;MAP domain"? the MAP spec never define that. however, we kept und= erstanding that the resource for a "MAP domain" includes:=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0- an IPv4 prefix (with prefix length 32 or = less) shared by CEs in this domain
=A0 =A0 =A0 =A0 =A0 =A0 =A0- a= n IPv6 prefix (with prefix length 64 or less) delegated to the CEs in this = domain with a /64 (or shorter) per CE (as the basic model of prefix d
=A0 =A0 =A0 =A0 =A0 =A0 =A0the newly introduced "1:1 mode" o= bviously abandons this understanding, then an explicit definition on the re= source of a "MAP domain" is requested. this is the origin and ess= ential starting point of the MAP deployment.=A0

Section 5. page 10:

=A0 * = Forwarding mode

Question #4: this appears twice a= t the definition of BMR and DMR, respectively. though Wojieich and Remi has= discussed that in another thread, i would like to confirm: is this mode a = domain configuration parameter or a rule parameter?

Question #5: does this "forwarding mode" is a= enumerate type of {MAP-T, MAP-E, 1:1, hub&spoke, mesh} or else, e.g., = {MAP-T, MAP-E} x {1:1, N:1} x {hub&spoke, mesh}, where the "x"= ; is the operator for de Cartesian product of sets? (related to #2)

Section 7.1 page 19:

In 1:= 1 mode, the MAP CE is provisioned with only a Default Mapping
Rule, a= nd the full IPv4 address/prefix and port range is provisioned
using t= he DHCP option.

Question #6: is the CE or the subscriber the rece= iver of the "full IPv4 address/prefix and port range" (correction= : port set) to be provisioned? or does it mean a CE is a subscriber itself = in the 1:1 mode?

Section 7.3 page 19:

A MAP-E C= E provisioned with only a Default Mapping Rule, as in the
1:1 case, a= nd with no IPv4 address and port range configured by other
means, MUS= T disable its NAT44 functionality.

Question #7: this text is contradictory with Section 7.= 1. is the DHCP option a sort of "other means" or not, or there= 9;s something out of scope of this draft?=A0

Quest= ion #8: what is the consequence of disabling the NAT44 functionality on CE = when a subscriber having a PSID of a share IPv4 address is running behind t= hat CE as a 1:1 mode domain?=A0

before all of the above questions and further questions= possibly to be generated during the discussion are fully clarified, i cann= ot help but gently show my disagreement on putting the current draft as wor= king group result. i also hope the MAP spec authors kindly understand with = so many uncertainty modifying MAP deployment draft to fit the MAP spec is a= mission-impossible for the time being.=A0

thanks and regards,
maoke
--00235452e7b069430a04c36bd052-- From pengwu.thu@gmail.com Tue Jun 26 20:36: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 AA16211E8104 for ; Tue, 26 Jun 2012 20:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0M9WZAfGpVwM for ; Tue, 26 Jun 2012 20:36:02 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id EAE2211E80A4 for ; Tue, 26 Jun 2012 20:36:01 -0700 (PDT) Received: by qabj34 with SMTP id j34so562829qab.4 for ; Tue, 26 Jun 2012 20:36:01 -0700 (PDT) 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:content-transfer-encoding; bh=mSS1HlTd8jGa662NOjzOpr3EQvcxyMbEJ+xbCjd02z8=; b=MbqDub9LB1F18vqnQ+dyzocD+hK/CDv6GsflOjdok/g6Kpm+GOFkbgoCo4KuI4lJg+ H1EMptqXQRiFNUvUgIMyUfyxOI4vx55noCV6CJAA3bmrbCzVD5TFzPF772dNiVUXj+2J IavSBP+fA1QSagng9cXu5LR2K+NJi9F6q6yXr+F/xNt2xbi3jVJPfgPMmj1erJThbZWb sbLR1COn1hYz0cymPZ3POZSP/Q/rz3hc4kryQ7vi8BMbXZ38yGd6i936KU0L8QKhcSGn gRz5lBVy446R7YDx4z03OpbYwCIkZOGm3fat5vWOoV9j7SKeor0DHiaxsIiF5G4UpB37 skjQ== MIME-Version: 1.0 Received: by 10.229.135.202 with SMTP id o10mr8053977qct.19.1340768161313; Tue, 26 Jun 2012 20:36:01 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Tue, 26 Jun 2012 20:36:01 -0700 (PDT) In-Reply-To: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> Date: Wed, 27 Jun 2012 11:36:01 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 03:36:02 -0000 On Wed, Jun 27, 2012 at 10:20 AM, Satoru Matsushima wrote: > Hi Maoke, > > On 2012/06/27, at 10:48, Maoke wrote: > >> dear Satoru, >> >> 2012/6/26 Satoru Matsushima >> On 2012/06/27, at 0:11, Qiong wrote: >> >> > Agree with Ian. >> > >> > MAP is designed and optimized for algorithmatic address mapping, but n= ot for per-subscriber rule mapping. Actually, the more you would like to so= lve, more complicated it will become. >> > >> > I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E= , map-dhcp all becomes useless or not optimized. And I will not deploy per-= subscriber stateful and stateless solutions at the same. >> > >> > So I encourage two seperated approaches optimized for different scenar= ios. It will be good for both. >> > >> > Do we really all forget about the "KISS" principle ? >> >> Not quite. >> I believe that the most motivate to start this work in the wg has destin= ed MAP to be 'multi-protocol socket v2.0' that's what the former wg chair w= ished to. Do you remember that? >> >> i like the philosophy of "multi-protocol socket". however, i moderately = doubt the "multi-protocol socket v2.0" is a perfect plan for every cases. i= n a quite good hotel, we see typically one 'multi-protocol socket' while a = lot of local-standard sockets. i never think it will make me happy if i see= every socket in my room is *multi-protocol*, occupying much spaces and qui= te noticeable on the walls. we need one to deploy somewhere not the only on= e type to deploy anywhere. ;-) > > That point would be an operational matter for deploying any standardized = technology. For example, an operator adopt OSPF to use its rich routing fea= ture but the network is small, the operator does just area 0 routing, even = OSPF allow inter-area routing for scale. Is an another ospf specification n= eeded for 'OSPF Area 0 Only Routing'? Well if I only have a simple network and I uses RIP, you don't make OSPF somehow compatible with RIP(or just include RIP with an OSPF terminology face? I don't know) and say "hey, just use this super suite, don't consider it overloaded, it's for unity!" > > >> >> therefore i understand the motivation of the wg is making a unified solu= tion covering both encapsulation and translation in the framework of statel= ess, WITHOUT the exclusiveness against other solutions, more specifically s= uitable for a certain use case. >> > > Studying each significant use case is quite important. I agree on that po= int with no doubt. However, is it IETF business for each use case specifica= tion? > > cheers, > --satoru > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From bingxuere@gmail.com Tue Jun 26 20:50: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 E1AF221F85F7 for ; Tue, 26 Jun 2012 20:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM+ERz-8wmYI for ; Tue, 26 Jun 2012 20:50:31 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04BBD21F85F3 for ; Tue, 26 Jun 2012 20:50:25 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so904541obb.31 for ; Tue, 26 Jun 2012 20:50:25 -0700 (PDT) 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=jaxBHrGUqSyWifF5qZur6mZcmm6GWA/ngqMDC2BFxq4=; b=ft+4ZVw6WcNNtApNou8F6R4nt8qmjHWj5tcGu+jwAXVWNL4N4EBFT6mKgxb30Pz3Tv f3joBOnM8F//H6SQQQ0IoxI6mBuE/9NGowgylAdE4BWA2mGdvrRdCJSWbvBwahpB6GIv ybBdGcxVZn3UZKbjSWSTeIInNgb0/CUJQBEH/y/HyISitnuWBDbT4R8YHqSWTc79CH5L OkbOiNFxysvN3ZMu+B3d2+booUhuHiV/+lYL8O8dy0zBq88JNan3/CUc2KDGJDyGlWg0 R0OwmKqCX+6mSCr+qZlypQeB/+RYQEB/wcy/IdaibcLlIEXeA/ASKykZ7bSVASeP/6XF l3SQ== Received: by 10.182.52.42 with SMTP id q10mr18862526obo.46.1340769025201; Tue, 26 Jun 2012 20:50:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.139.107 with HTTP; Tue, 26 Jun 2012 20:49:45 -0700 (PDT) In-Reply-To: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> From: Qiong Date: Wed, 27 Jun 2012 11:49:45 +0800 Message-ID: To: Peng Wu Content-Type: multipart/alternative; boundary=14dae939907179171b04c36c1dbd Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 03:50:33 -0000 --14dae939907179171b04c36c1dbd Content-Type: text/plain; charset=UTF-8 Exactly. We will always choose the technique for its appropriate scenario. On Wed, Jun 27, 2012 at 11:36 AM, Peng Wu wrote: > On Wed, Jun 27, 2012 at 10:20 AM, Satoru Matsushima > wrote: > > Hi Maoke, > > > > On 2012/06/27, at 10:48, Maoke wrote: > > > >> dear Satoru, > >> > >> 2012/6/26 Satoru Matsushima > >> On 2012/06/27, at 0:11, Qiong wrote: > >> > >> > Agree with Ian. > >> > > >> > MAP is designed and optimized for algorithmatic address mapping, but > not for per-subscriber rule mapping. Actually, the more you would like to > solve, more complicated it will become. > >> > > >> > I will certainly not buy MAP for per-subscriber case when MAP-T, > MAP-E, map-dhcp all becomes useless or not optimized. And I will not deploy > per-subscriber stateful and stateless solutions at the same. > >> > > >> > So I encourage two seperated approaches optimized for different > scenarios. It will be good for both. > >> > > >> > Do we really all forget about the "KISS" principle ? > >> > >> Not quite. > >> I believe that the most motivate to start this work in the wg has > destined MAP to be 'multi-protocol socket v2.0' that's what the former wg > chair wished to. Do you remember that? > >> > >> i like the philosophy of "multi-protocol socket". however, i moderately > doubt the "multi-protocol socket v2.0" is a perfect plan for every cases. > in a quite good hotel, we see typically one 'multi-protocol socket' while a > lot of local-standard sockets. i never think it will make me happy if i see > every socket in my room is *multi-protocol*, occupying much spaces and > quite noticeable on the walls. we need one to deploy somewhere not the only > one type to deploy anywhere. ;-) > > > > That point would be an operational matter for deploying any standardized > technology. For example, an operator adopt OSPF to use its rich routing > feature but the network is small, the operator does just area 0 routing, > even OSPF allow inter-area routing for scale. Is an another ospf > specification needed for 'OSPF Area 0 Only Routing'? > > Well if I only have a simple network and I uses RIP, you don't make > OSPF somehow compatible with RIP(or just include RIP with an OSPF > terminology face? I don't know) and say "hey, just use this super > suite, don't consider it overloaded, it's for unity!" > > > > > > >> > >> therefore i understand the motivation of the wg is making a unified > solution covering both encapsulation and translation in the framework of > stateless, WITHOUT the exclusiveness against other solutions, more > specifically suitable for a certain use case. > >> > > > > Studying each significant use case is quite important. I agree on that > point with no doubt. However, is it IETF business for each use case > specification? > > > > cheers, > > --satoru > > > > _______________________________________________ > > 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 > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae939907179171b04c36c1dbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Exactly. We will always choose the technique for its appropriate scenario.

On Wed, J= un 27, 2012 at 11:36 AM, Peng Wu <pengwu.thu@gmail.com> w= rote:
On Wed, Jun 27, 2012 at 10:20 AM, Sator= u Matsushima
<satoru= .matsushima@gmail.com> wrote:
> Hi Maoke,
>
> On 2012/06/27, at 10:48, Maoke wrote:
>
>> dear Satoru,
>>
>> 2012/6/26 Satoru Matsushima <satoru.matsushima@gmail.com>
>> On 2012/06/27, at 0:11, Qiong wrote:
>>
>> > Agree with Ian.
>> >
>> > MAP is designed and optimized for algorithmatic address mappi= ng, but not for per-subscriber rule mapping. Actually, the more you would l= ike to solve, more complicated it will become.
>> >
>> > I will certainly not buy MAP for per-subscriber case when MAP= -T, MAP-E, map-dhcp all becomes useless or not optimized. And I will not de= ploy per-subscriber stateful and stateless solutions at the same.
>> >
>> > So I encourage two seperated approaches optimized for differe= nt scenarios. It will be good for both.
>> >
>> > Do we really all forget about the "KISS" principle = ?
>>
>> Not quite.
>> I believe that the most motivate to start this work in the wg has = destined MAP to be 'multi-protocol socket v2.0' that's what the= former wg chair wished to. Do you remember that?
>>
>> i like the philosophy of "multi-protocol socket". howeve= r, i moderately doubt the "multi-protocol socket v2.0" is a perfe= ct plan for every cases. in a quite good hotel, we see typically one 'm= ulti-protocol socket' while a lot of local-standard sockets. i never th= ink it will make me happy if i see every socket in my room is *multi-protoc= ol*, occupying much spaces and quite noticeable on the walls. we need one t= o deploy somewhere not the only one type to deploy anywhere. ;-)
>
> That point would be an operational matter for deploying any standardiz= ed technology. For example, an operator adopt OSPF to use its rich routing = feature but the network is small, the operator does just area 0 routing, ev= en OSPF allow inter-area routing for scale. Is an another ospf specificatio= n needed for 'OSPF Area 0 Only Routing'?

Well if I only have a simple network and I uses RIP, you don't ma= ke
OSPF somehow compatible with RIP(or just include RIP with an OSPF
terminology face? I don't know) and say "hey, just use this super<= br> suite, don't consider it overloaded, it's for unity!"

>
>
>>
>> therefore i understand the motivation of the wg is making a unifie= d solution covering both encapsulation and translation in the framework of = stateless, WITHOUT the exclusiveness against other solutions, more specific= ally suitable for a certain use case.
>>
>
> Studying each significant use case is quite important. I agree on that= point with no doubt. However, is it IETF business for each use case specif= ication?
>
> cheers,
> --satoru
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
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

--14dae939907179171b04c36c1dbd-- From fibrib@gmail.com Tue Jun 26 21:00: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 7FD9311E80EF for ; Tue, 26 Jun 2012 21:00:42 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceSZ0ETVMQt0 for ; Tue, 26 Jun 2012 21:00:41 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3C68311E80A4 for ; Tue, 26 Jun 2012 21:00:41 -0700 (PDT) Received: by qcmt36 with SMTP id t36so339791qcm.15 for ; Tue, 26 Jun 2012 21:00:40 -0700 (PDT) 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=taHEnpyaIB94pioaAs5vWGiCdvd8ajAUOaR0wrXRTt8=; b=zdeQZTbXJgaY/zigzNmlPrrJ6C4ojgss5o79NYLiE6x9FyXlqpuvbS4nmvoia7kvxE 1DChfb9ubdI4nc93fBzvdBINhaOKzNftdtk1sg1DaseSRIyFfeGUHD7ejorBbBF8zNTk 9ONnLOsZJFyrQcvwjvKqVM4ULJIi86COZLIwsnaRkjUCcmYAw7n2GEsJxxeqOFXv9VQ5 a36EUOScK9Tn6HIprEMwC4K01+eAHUwDxsM8Swo9f68Sl7CZONpsA6ClozdzdSPiPj3A 0qkmLmayLfyq1peEZTnKdmfqES7tEJVLTG/PpVpdkCfP3CNJsO14lBmqVN0ykiPyYjsY OxHg== MIME-Version: 1.0 Received: by 10.224.116.143 with SMTP id m15mr28542046qaq.50.1340769640603; Tue, 26 Jun 2012 21:00:40 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Tue, 26 Jun 2012 21:00:40 -0700 (PDT) In-Reply-To: References: <20120624054808.18705.88312.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 13:00:40 +0900 Message-ID: From: Maoke To: Wojciech Dec Content-Type: multipart/alternative; boundary=20cf3074d3022761e304c36c429d Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-mdt-softwire-map-deployment-01.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: Wed, 27 Jun 2012 04:00:42 -0000 --20cf3074d3022761e304c36c429d Content-Type: text/plain; charset=ISO-8859-1 2012/6/26 Wojciech Dec > Hi, > > comments: > > section 4.2 of the draft reads: > " a MAP domain is a set of MAP CEs and BRs connected to the same virtual > link. One MAP domain shares a common BR and has the same set of BMRs, FMRs > and DMR, and it can be further divided into multiple sub-domains when > multiple IPv4 subnets are deployed in one MAP domain. > There might be multiple BMRs in one MAP domain, and CE would pick up its > own BMR by longest prefix matching lookup. > > This effectively confirms that multiple MAP domains are an established > characteristics, and logic dictates that if N CEs can be in a given domain, > N can also equal 1. > multiple domain is surely an established characteristics. however, the question is: can N be 1/K (K:int > 1)? ;-) > > We look forward to updates to the draft, also in terms of referring to the > specs. > thanks a lot for the comment. and updating the draft with referring to the specs is definitely the most important task but the first-priority task of us is clarifying the semantics and impacts of the specs itself. thanks and regards, maoke > > Regards, > Woj. > > On 26 June 2012 08:24, Maoke wrote: > >> >> hi all, >> >> we have submitted the updated version of the MAP deployment draft. As the >> new draft of MAP spec introduces technical uncertainties and hasn't reach >> the consensus. we noticed that the 1:1 mode involves different way of >> operation, needing to carefully investigate and to understand. Currently we >> exclude the 1:1 mode from the scope of MAP deployment. >> >> the major change of this version in comparison to the previous version >> includes: >> - adding of the new section 4.1: Network Models >> taking the example of home network, explain what is the typical use >> cases of MAP >> - editorial changes and correction of grammar/wording/spellings. >> >> we are aware that this MAP deployment draft has not reviewed by the >> working group, and therefore we update it still as individual draft for the >> time being. comments and recommendations are requested. >> >> regards, >> maoke >> >> >> ---------- Forwarded message ---------- >> From: >> Date: 2012/6/24 >> Subject: New Version Notification for >> draft-mdt-softwire-map-deployment-01.txt >> To: sunqiong@ctbri.com.cn >> Cc: simon.perreault@viagenie.ca, fibrib@gmail.com, >> tina.tsou.zouting@huawei.com, chengang@chinamobile.com, >> chunfa.sun@g.softbank.co.jp >> >> >> >> A new version of I-D, draft-mdt-softwire-map-deployment-01.txt >> has been successfully submitted by Qiong Sun and posted to the >> IETF repository. >> >> Filename: draft-mdt-softwire-map-deployment >> Revision: 01 >> Title: Mapping of Address and Port (MAP) - Deployment >> Considerations >> Creation date: 2012-06-24 >> WG ID: Individual Submission >> Number of pages: 32 >> URL: >> http://www.ietf.org/internet-drafts/draft-mdt-softwire-map-deployment-01.txt >> Status: >> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment >> Htmlized: >> http://tools.ietf.org/html/draft-mdt-softwire-map-deployment-01 >> Diff: >> http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-map-deployment-01 >> >> Abstract: >> This document describes when and how an operator uses the technique >> of Mapping of Address and Port (MAP) for the IPv4 residual deployment >> in the IPv6-dominant domain. >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --20cf3074d3022761e304c36c429d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/6/26 Wojciech Dec <wdec.ietf@gma= il.com>
Hi,

comments:

section 4.2 of the draft reads:
" a MAP= domain is a set of MAP CEs and BRs connected to the same virtual link. One MAP domain shares a common BR and has the same set of BMRs, FMRs and DMR, and it can be further divided into multiple sub-domains when multiple IPv4 subnets are deployed in one MAP domain.
There might be multiple BMR= s in one MAP domain, and CE would pick up its own BMR by longest prefix matching lookup.

This effectively confirms that multiple MAP do= mains are an established characteristics, and logic dictates that if N CEs = can be in a given domain, N can also equal 1.

multiple domain is surely an established characteristics. howeve= r, the question is: can N be 1/K (K:int > 1)? ;-)
=A0

We look forward to updates to the draft, also in terms of referring to = the specs.

thanks a lot for the comment= . and updating the draft with referring to the specs is definitely the most= important task but the first-priority task of us is clarifying the semanti= cs and impacts of the specs itself.=A0

thanks and regards,
maoke
=A0
=

Regards,
Woj.

On 26 June 2012 08:24, Maoke <fibrib@gmail.com> wrote:
=

hi all,=A0

we have submitt= ed the updated version of the MAP deployment draft. As the new draft of MAP= spec introduces technical uncertainties and hasn't reach the consensus= . we noticed that the 1:1 mode involves different way of operation, needing= to carefully investigate and to understand. Currently we exclude the 1:1 m= ode from the scope of MAP deployment.=A0

the major change of this version in comparison to the p= revious version includes:=A0
- adding of the new section 4.1: Net= work Models
=A0 taking the example of home network, explain what = is the typical use cases of MAP
- editorial changes and correction of grammar/wording/spellings.=A0

we are aware that this MAP deployment draft has not rev= iewed by the working group, and therefore we update it still as individual = draft for the time being. comments and recommendations are requested.=A0

regards,
maoke


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: 2012/6/24
Subject: New Version Notification for draft-mdt-softwire= -map-deployment-01.txt
To: sunqiong@ctbri.com.cn
Cc: simon.perreault@viagenie.ca, fibrib@gmail.com, tina.tsou.zou= ting@huawei.com, chengang@chinamobile.com, chunfa.sun@g.softbank.co.jp



A new version of I-D, draft-mdt-softwire-map-deployment-01.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mdt-softwire-map-deployment
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Mapping of Address and Port (MAP) - Deployment C= onsiderations
Creation date: =A0 2012-06-24
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 32
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.iet= f.org/internet-drafts/draft-mdt-softwire-map-deployment-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org= /doc/draft-mdt-softwire-map-deployment
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draf= t-mdt-softwire-map-deployment-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.iet= f.org/rfcdiff?url2=3Ddraft-mdt-softwire-map-deployment-01

Abstract:
=A0 This document describes when and how an operator uses the technique =A0 of Mapping of Address and Port (MAP) for the IPv4 residual deployment<= br> =A0 in the IPv6-dominant domain.




The IETF Secretariat


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



--20cf3074d3022761e304c36c429d-- From leaf.y.yeh@huawei.com Tue Jun 26 21:19:10 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 0216F11E80EB for ; Tue, 26 Jun 2012 21:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.986 X-Spam-Level: X-Spam-Status: No, score=-6.986 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1+WKNN231AZ for ; Tue, 26 Jun 2012 21:19:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id CF79D11E808F for ; Tue, 26 Jun 2012 21:19:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHF95554; Wed, 27 Jun 2012 00:19:08 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 21:19:08 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Jun 2012 21:19:05 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 27 Jun 2012 12:19:01 +0800 From: Leaf yeh To: Maoke , Wojciech Dec Thread-Topic: [Softwires] Fwd: New Version Notification for draft-mdt-softwire-map-deployment-01.txt Thread-Index: AQHNU2RWic60FzSB20ell9HgNlxKM5cLyKwAgAE9QwCAAIkFEA== Date: Wed, 27 Jun 2012 04:18:59 +0000 Message-ID: References: <20120624054808.18705.88312.idtracker@ietfa.amsl.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.160] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-mdt-softwire-map-deployment-01.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: Wed, 27 Jun 2012 04:19:10 -0000 I might have a naive question: why does the Softtwire-WG need a document fo= r deployment other than a document for motivation?=20 I guess the answer might be the motivation is for the requirements, and the= deployment is for the specified application cases, right? But to me the an= swer might be as simple as that motivation is the deployment. Could it possible to merge these 2 document? Best Regards, Leaf From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Maoke Sent: Wednesday, June 27, 2012 12:01 PM To: Wojciech Dec Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-mdt-softwi= re-map-deployment-01.txt 2012/6/26 Wojciech Dec Hi, comments: section 4.2 of the draft reads: " a MAP domain is a set of MAP CEs and BRs connected to the same virtual li= nk. One MAP domain shares a common BR and has the same set of BMRs, FMRs an= d DMR, and it can be further divided into multiple sub-domains when multipl= e IPv4 subnets are deployed in one MAP domain.=20 There might be multiple BMRs in one MAP domain, and CE would pick up its ow= n BMR by longest prefix matching lookup.=20 This effectively confirms that multiple MAP domains are an established char= acteristics, and logic dictates that if N CEs can be in a given domain, N c= an also equal 1. multiple domain is surely an established characteristics. however, the ques= tion is: can N be 1/K (K:int > 1)? ;-) =A0 We look forward to updates to the draft, also in terms of referring to the = specs. thanks a lot for the comment. and updating the draft with referring to the = specs is definitely the most important task but the first-priority task of = us is clarifying the semantics and impacts of the specs itself.=A0 thanks and regards, maoke =A0 Regards, Woj. On 26 June 2012 08:24, Maoke wrote: hi all,=A0 we have submitted the updated version of the MAP deployment draft. As the n= ew draft of MAP spec introduces technical uncertainties and hasn't reach th= e consensus. we noticed that the 1:1 mode involves different way of operati= on, needing to carefully investigate and to understand. Currently we exclud= e the 1:1 mode from the scope of MAP deployment.=A0 the major change of this version in comparison to the previous version incl= udes:=A0 - adding of the new section 4.1: Network Models =A0 taking the example of home network, explain what is the typical use cas= es of MAP - editorial changes and correction of grammar/wording/spellings.=A0 we are aware that this MAP deployment draft has not reviewed by the working= group, and therefore we update it still as individual draft for the time b= eing. comments and recommendations are requested.=A0 regards, maoke ---------- Forwarded message ---------- From: Date: 2012/6/24 Subject: New Version Notification for draft-mdt-softwire-map-deployment-01.= txt To: sunqiong@ctbri.com.cn Cc: simon.perreault@viagenie.ca, fibrib@gmail.com, tina.tsou.zouting@huawei= .com, chengang@chinamobile.com, chunfa.sun@g.softbank.co.jp A new version of I-D, draft-mdt-softwire-map-deployment-01.txt has been successfully submitted by Qiong Sun and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-mdt-softwire-map-deployment Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 Mapping of Address and Port (MAP) - Deployment C= onsiderations Creation date: =A0 2012-06-24 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 32 URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-mdt-= softwire-map-deployment-01.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-softwi= re-map-deployment Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-mdt-softwire-map-= deployment-01 Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt= -softwire-map-deployment-01 Abstract: =A0 This document describes when and how an operator uses the technique =A0 of Mapping of Address and Port (MAP) for the IPv4 residual deployment =A0 in the IPv6-dominant domain. The IETF Secretariat _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Tue Jun 26 21:37:55 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 DF26C11E8102 for ; Tue, 26 Jun 2012 21:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P2sGqmIwmNC for ; Tue, 26 Jun 2012 21:37:54 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21A9C11E80C5 for ; Tue, 26 Jun 2012 21:37:54 -0700 (PDT) Received: by dacx6 with SMTP id x6so825084dac.31 for ; Tue, 26 Jun 2012 21:37:54 -0700 (PDT) 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=SbddrouL6uWTkV98Z/9kgr3BSISctKKamPtckII8ThU=; b=W8GQPH6h5KGOaC//2J+77qQezXyrf26q6wT7IcPo/0sYbLmdnuVN9CXs5I7zFe0mil 8FCC+uYG8wjOI5/QTxIrN4gqIEVF1hScurB397eeWSrrII/6j1dN7VHyzVVDLrpg2jwA lDjSrsJcZJoBQRH6x2oToWvBcHSZR4v2kj2Hdrd83EkBSw9RynAhy+3gi0amfvwjcTvY GWniSz55CG/hiz+pr4dZiI+FbXcvr2uOZTDBhg51IFOpWmk7I4B7LMSj7/pV3w0BzuEN YMS9XqZgJ5bvPGwddkNCERAJpN1wiPrZkrvY7MtVbzyzYx2BZgczL+dVtp2Ye9WvQBJr 6SYQ== Received: by 10.68.222.38 with SMTP id qj6mr59672953pbc.6.1340771873969; Tue, 26 Jun 2012 21:37:53 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id pg3sm13944813pbc.2.2012.06.26.21.37.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 21:37:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 13:37:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 04:37:56 -0000 On 2012/06/27, at 12:36, Peng Wu wrote: >>> Not quite. >>> I believe that the most motivate to start this work in the wg has = destined MAP to be 'multi-protocol socket v2.0' that's what the former = wg chair wished to. Do you remember that? >>>=20 >>> i like the philosophy of "multi-protocol socket". however, i = moderately doubt the "multi-protocol socket v2.0" is a perfect plan for = every cases. in a quite good hotel, we see typically one 'multi-protocol = socket' while a lot of local-standard sockets. i never think it will = make me happy if i see every socket in my room is *multi-protocol*, = occupying much spaces and quite noticeable on the walls. we need one to = deploy somewhere not the only one type to deploy anywhere. ;-) >>=20 >> That point would be an operational matter for deploying any = standardized technology. For example, an operator adopt OSPF to use its = rich routing feature but the network is small, the operator does just = area 0 routing, even OSPF allow inter-area routing for scale. Is an = another ospf specification needed for 'OSPF Area 0 Only Routing'? >=20 > Well if I only have a simple network and I uses RIP, you don't make > OSPF somehow compatible with RIP(or just include RIP with an OSPF > terminology face? I don't know) and say "hey, just use this super > suite, don't consider it overloaded, it's for unity!" Oh, you don't argue that OSPF covers an use case which is also covered = by RIP. So then why are you arguing that an use case of MAP is = eventually same with the LW46 use case? cheers, --satoru= From bingxuere@gmail.com Tue Jun 26 21:56: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 74DE521F85BB for ; Tue, 26 Jun 2012 21:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2b5ZzND9nxmo for ; Tue, 26 Jun 2012 21:56:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3E8921F8494 for ; Tue, 26 Jun 2012 21:56:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so987324obb.31 for ; Tue, 26 Jun 2012 21:56:48 -0700 (PDT) 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=MsL3AAX+rdiNiA2rmfCZM4pTNbJCNGHeW4R4D91Y28A=; b=CJiFINthJDfiULjEt2qWHF2rQPTktXkcbptP1eFMwsuzOylRNcHOX6Zx+TwTUBgC1e OzU3/Jvd8sS08kqy9+Lpr8EMzsYny8bvrijD2nQE2qOLnWrraJrUPjTcGI/XpoFfhorc TveQqu/IqcFN50OxsQExP8tTSTN8nT4bG0kKmTU4ei7fC0qv5pCMEgnqcEfjzQG44JcY ymn36GvuTxbmCHSbnBZGTk5SgnFU3omWGC7NqNOayR3qg99/XXkr4GsDcYRp8J41YeAm a1XFrBxEFjSH8q6h4ntwiAWGSZBFaLUSEKVmkxSboBs0b8r+EH0FK7ugQ7dsRg2G+MkO g1UA== Received: by 10.60.18.114 with SMTP id v18mr18918424oed.34.1340773008297; Tue, 26 Jun 2012 21:56:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.139.107 with HTTP; Tue, 26 Jun 2012 21:56:08 -0700 (PDT) In-Reply-To: References: <20120624054808.18705.88312.idtracker@ietfa.amsl.com> From: Qiong Date: Wed, 27 Jun 2012 12:56:08 +0800 Message-ID: To: Leaf yeh Content-Type: multipart/alternative; boundary=f46d0444eba5e250c004c36d0a7b Cc: Softwires-wg Subject: Re: [Softwires] Fwd: New Version Notification for draft-mdt-softwire-map-deployment-01.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: Wed, 27 Jun 2012 04:56:51 -0000 --f46d0444eba5e250c004c36d0a7b Content-Type: text/plain; charset=UTF-8 Hi Leaf, On Wed, Jun 27, 2012 at 12:18 PM, Leaf yeh wrote: > I might have a naive question: why does the Softtwire-WG need a document > for deployment other than a document for motivation? > Qiong: We already have a motivation draft that clearly demenstrates the requirements. This is exactly what is documented in charter: "develop a protocol specification response to the solution motivation document" > > I guess the answer might be the motivation is for the requirements, and > the deployment is for the specified application cases, right? But to me the > answer might be as simple as that motivation is the deployment. > Qiong: Motivation is why we need it. Specification is what it is.Deployment is how we use it in operational network. These three are quite different essentially. > > Could it possible to merge these 2 document? > I don't think so. See above reasons. Best wishes Qiong > > > Best Regards, > Leaf > > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Maoke > Sent: Wednesday, June 27, 2012 12:01 PM > To: Wojciech Dec > Cc: Softwires-wg > Subject: Re: [Softwires] Fwd: New Version Notification for > draft-mdt-softwire-map-deployment-01.txt > > > 2012/6/26 Wojciech Dec > Hi, > > comments: > > section 4.2 of the draft reads: > " a MAP domain is a set of MAP CEs and BRs connected to the same virtual > link. One MAP domain shares a common BR and has the same set of BMRs, FMRs > and DMR, and it can be further divided into multiple sub-domains when > multiple IPv4 subnets are deployed in one MAP domain. > There might be multiple BMRs in one MAP domain, and CE would pick up its > own BMR by longest prefix matching lookup. > > This effectively confirms that multiple MAP domains are an established > characteristics, and logic dictates that if N CEs can be in a given domain, > N can also equal 1. > > multiple domain is surely an established characteristics. however, the > question is: can N be 1/K (K:int > 1)? ;-) > > > We look forward to updates to the draft, also in terms of referring to the > specs. > > thanks a lot for the comment. and updating the draft with referring to the > specs is definitely the most important task but the first-priority task of > us is clarifying the semantics and impacts of the specs itself. > > thanks and regards, > maoke > > > Regards, > Woj. > On 26 June 2012 08:24, Maoke wrote: > > hi all, > > we have submitted the updated version of the MAP deployment draft. As the > new draft of MAP spec introduces technical uncertainties and hasn't reach > the consensus. we noticed that the 1:1 mode involves different way of > operation, needing to carefully investigate and to understand. Currently we > exclude the 1:1 mode from the scope of MAP deployment. > > the major change of this version in comparison to the previous version > includes: > - adding of the new section 4.1: Network Models > taking the example of home network, explain what is the typical use > cases of MAP > - editorial changes and correction of grammar/wording/spellings. > > we are aware that this MAP deployment draft has not reviewed by the > working group, and therefore we update it still as individual draft for the > time being. comments and recommendations are requested. > > regards, > maoke > > > ---------- Forwarded message ---------- > From: > Date: 2012/6/24 > Subject: New Version Notification for > draft-mdt-softwire-map-deployment-01.txt > To: sunqiong@ctbri.com.cn > Cc: simon.perreault@viagenie.ca, fibrib@gmail.com, > tina.tsou.zouting@huawei.com, chengang@chinamobile.com, > chunfa.sun@g.softbank.co.jp > > > > A new version of I-D, draft-mdt-softwire-map-deployment-01.txt > has been successfully submitted by Qiong Sun and posted to the > IETF repository. > > Filename: draft-mdt-softwire-map-deployment > Revision: 01 > Title: Mapping of Address and Port (MAP) - Deployment > Considerations > Creation date: 2012-06-24 > WG ID: Individual Submission > Number of pages: 32 > URL: > http://www.ietf.org/internet-drafts/draft-mdt-softwire-map-deployment-01.txt > Status: > http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment > Htmlized: > http://tools.ietf.org/html/draft-mdt-softwire-map-deployment-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-map-deployment-01 > > Abstract: > This document describes when and how an operator uses the technique > of Mapping of Address and Port (MAP) for the IPv4 residual deployment > in the IPv6-dominant domain. > > > > > The IETF Secretariat > > _______________________________________________ > 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 > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --f46d0444eba5e250c004c36d0a7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Leaf,

On Wed, Jun 27, 2012 at 12:18 PM= , Leaf yeh <leaf.y.yeh@huawei.com> wrote:
I might have a naive question: why does the Softtwire-WG need a document fo= r deployment other than a document for motivation?
Qio= ng: We already have a motivation draft that clearly demenstrates the requir= ements. This is exactly what is documented in charter: "develop a prot= ocol specification response to the solution motivation document"=C2=A0 =C2=A0

I guess the answer might be the motivation is for the requirements, and the= deployment is for the specified application cases, right? But to me the an= swer might be as simple as that motivation is the deployment.
Qiong:=C2=A0 Motivation is why we need it. Specification is what it is= .Deployment is how we use it in operational network.
These three are qui= te different essentially.

Could it possible to merge these 2 document?

I don= 't think so.=C2=A0 See above reasons.

Best wishes
Qiong


Best Regards,
Leaf


From: softwires-bounces@ietf.= org [mailto:softwires-bou= nces@ietf.org] On Behalf Of Maoke
Sent: Wednesday, June 27, 2012 12:01 PM
To: Wojciech Dec
Cc: Softwires-wg
Subject: Re: [Softwires] Fwd: New Version Notification for draft-mdt-softwi= re-map-deployment-01.txt


2012/6/26 Wojciech Dec <wdec.ietf= @gmail.com>
Hi,

comments:

section 4.2 of the draft reads:
" a MAP domain is a set of MAP CEs and BRs connected to the same virtu= al link. One MAP domain shares a common BR and has the same set of BMRs, FM= Rs and DMR, and it can be further divided into multiple sub-domains when mu= ltiple IPv4 subnets are deployed in one MAP domain.
There might be multiple BMRs in one MAP domain, and CE would pick up its ow= n BMR by longest prefix matching lookup.

This effectively confirms that multiple MAP domains are an established char= acteristics, and logic dictates that if N CEs can be in a given domain, N c= an also equal 1.

multiple domain is surely an established characteristics. however, the ques= tion is: can N be 1/K (K:int > 1)? ;-)
=C2=A0

We look forward to updates to the draft, also in terms of referring to the = specs.

thanks a lot for the comment. and updating the draft with referring to the = specs is definitely the most important task but the first-priority task of = us is clarifying the semantics and impacts of the specs itself.=C2=A0

thanks and regards,
maoke
=C2=A0

Regards,
Woj.
On 26 June 2012 08:24, Maoke <fibrib= @gmail.com> wrote:

hi all,=C2=A0

we have submitted the updated version of the MAP deployment draft. As the n= ew draft of MAP spec introduces technical uncertainties and hasn't reac= h the consensus. we noticed that the 1:1 mode involves different way of ope= ration, needing to carefully investigate and to understand. Currently we ex= clude the 1:1 mode from the scope of MAP deployment.=C2=A0

the major change of this version in comparison to the previous version incl= udes:=C2=A0
- adding of the new section 4.1: Network Models
=C2=A0 taking the example of home network, explain what is the typical use = cases of MAP
- editorial changes and correction of grammar/wording/spellings.=C2=A0

we are aware that this MAP deployment draft has not reviewed by the working= group, and therefore we update it still as individual draft for the time b= eing. comments and recommendations are requested.=C2=A0

regards,
maoke


---------- Forwarded message ----------
From: <internet-drafts@ietf.= org>
Date: 2012/6/24
Subject: New Version Notification for draft-mdt-softwire-map-deployment-01.= txt
To: sunqiong@ctbri.com.cn
Cc: simon.perreault@viagenie= .ca, fibrib@gmail.com, tina.tsou.zouting@huawei.com, = chengang@chinamobile.com, <= a href=3D"mailto:chunfa.sun@g.softbank.co.jp">chunfa.sun@g.softbank.co.jp



A new version of I-D, draft-mdt-softwire-map-deployment-01.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mdt-softwire-map-deployment
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A001
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mapping of Address and Port (MAP)= - Deployment Considerations
Creation date: =C2=A0 2012-06-24
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 32
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-mdt-softwire-map-deployment-0= 1.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datat= racker.ietf.org/doc/draft-mdt-softwire-map-deployment
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.o= rg/html/draft-mdt-softwire-map-deployment-01
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt-softwire-map-deployment-01<= /a>

Abstract:
=C2=A0 This document describes when and how an operator uses the technique<= br> =C2=A0 of Mapping of Address and Port (MAP) for the IPv4 residual deploymen= t
=C2=A0 in the IPv6-dominant domain.




The IETF Secretariat

_______________________________________________
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
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

--f46d0444eba5e250c004c36d0a7b-- From jiangdong345@gmail.com Tue Jun 26 23:34: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 3B20111E8102 for ; Tue, 26 Jun 2012 23:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h0F876MCary for ; Tue, 26 Jun 2012 23:34:23 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92DA611E807F for ; Tue, 26 Jun 2012 23:34:23 -0700 (PDT) Received: by dacx6 with SMTP id x6so947814dac.31 for ; Tue, 26 Jun 2012 23:34:23 -0700 (PDT) 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=nsJmL3owoFO3bttAc7N5SN+BC7sm3oFenCgyNnBAu7U=; b=DpRgqAC/nAZ9omsMWgGD15eILYSeME1fTRZvppp9aelzyoxgxft1G+P1KNFTeWNvjo 1pvxtko/rf1e2QrFklvVmaQ/x4CAu3u5MhH+LwLGFPICh/FPK6kB7xEdMVZUiZWjfnPX /VN+ThJEw2EFcmA/B0NNvMBifrh8/CjzAxMH1XyXclvcPyayII6FYw/NMdM1S2KApdm5 MyWagFaefHEsPf0M6RCAu/us6yUWcQf1Hn6gVrbWGz8PphnYkd70geYveG0XVuwJlDOo nchx7LgNG94xWPPT9dqNDGNZNP4dVYQppmn4RUEn3XLhQAW3CovxBg/CUyTwPpTTQdKK 5Oyg== Received: by 10.68.226.226 with SMTP id rv2mr59981217pbc.101.1340778863002; Tue, 26 Jun 2012 23:34:23 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id tm2sm14213163pbc.69.2012.06.26.23.34.16 (version=SSLv3 cipher=OTHER); Tue, 26 Jun 2012 23:34:22 -0700 (PDT) Date: Wed, 27 Jun 2012 14:34:16 +0800 From: "Jiang Dong" To: "Satoru Matsushima" , "Peng Wu" References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> , X-Priority: 3 X-GUID: C9AFE509-10F7-4950-B943-E40C7662108C X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012062714341150257645@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart202718401548_=----" Cc: Softwires WG , "ian.farrer" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 06:34:24 -0000 This is a multi-part message in MIME format. ------=_001_NextPart202718401548_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIFNhdG9ydSwNCg0KSSBiZWxpZXZlIE9TUEYgbmV2ZXIgYWJhbmRvbiBpdHMgb3duIGVzc2Vu Y2UgaW4gb3JkZXIgdG8gYmUgYSBzdXBlciBzdWl0ZSBhbmQgZG8gc29tZXRoaW5nIHZlcnkgc3Ry YW5nZSB0byBjb3ZlciB0aGUgdXNlIGNhc2Ugd2hpY2ggY2FuIGJlIGVhc2lseSBhbmQgY2xlYXJs eSBkb25lIGJ5IFJJUC4gDQoNCldoYXQncyBtb3JlLCBNQVAgaXMgbm90IE9TUEYsIGFuZCBMVzRv dmVyNiBpcyBub3QgUklQLiBNQVAgYW5kIExXNG92ZXI2IGhhdmUgdGhlaXIgb3duIHVzZSBjYXNl IHdoZW4gdGhleSBhcmUgb3JpZ2luYWxseSBkZXNpZ25lZC4gTUFQIGlzIG5vdCBzdXBwb3NlZCB0 byBkbyB0aGUgMToxIG1vZGUgaW4gdGhlIGJlZ2lubmluZy4gDQoNClJlZ2FyZHMhDQpKaWFuZyBE b25nDQoNCkZyb206IFNhdG9ydSBNYXRzdXNoaW1hDQpEYXRlOiAyMDEyLTA2LTI3IDEyOjM3DQpU bzogUGVuZyBXdQ0KQ0M6IHNvZnR3aXJlczsgaWFuLmZhcnJlcg0KU3ViamVjdDogUmU6IFtTb2Z0 d2lyZXNdIFtTb2Z0d2lyZV0gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgZG9lcyBOT1QgcmVm bGVjdCB0aGUgY29uc2Vuc3VzIGZyb20gdGhlIFdHDQpPbiAyMDEyLzA2LzI3LCBhdCAxMjozNiwg UGVuZyBXdSB3cm90ZToNCg0KPj4+IE5vdCBxdWl0ZS4NCj4+PiBJIGJlbGlldmUgdGhhdCB0aGUg bW9zdCBtb3RpdmF0ZSB0byBzdGFydCB0aGlzIHdvcmsgaW4gdGhlIHdnIGhhcyBkZXN0aW5lZCBN QVAgdG8gYmUgJ211bHRpLXByb3RvY29sIHNvY2tldCB2Mi4wJyB0aGF0J3Mgd2hhdCB0aGUgZm9y bWVyIHdnIGNoYWlyIHdpc2hlZCB0by4gRG8geW91IHJlbWVtYmVyIHRoYXQ/DQo+Pj4gDQo+Pj4g aSBsaWtlIHRoZSBwaGlsb3NvcGh5IG9mICJtdWx0aS1wcm90b2NvbCBzb2NrZXQiLiBob3dldmVy LCBpIG1vZGVyYXRlbHkgZG91YnQgdGhlICJtdWx0aS1wcm90b2NvbCBzb2NrZXQgdjIuMCIgaXMg YSBwZXJmZWN0IHBsYW4gZm9yIGV2ZXJ5IGNhc2VzLiBpbiBhIHF1aXRlIGdvb2QgaG90ZWwsIHdl IHNlZSB0eXBpY2FsbHkgb25lICdtdWx0aS1wcm90b2NvbCBzb2NrZXQnIHdoaWxlIGEgbG90IG9m IGxvY2FsLXN0YW5kYXJkIHNvY2tldHMuIGkgbmV2ZXIgdGhpbmsgaXQgd2lsbCBtYWtlIG1lIGhh cHB5IGlmIGkgc2VlIGV2ZXJ5IHNvY2tldCBpbiBteSByb29tIGlzICptdWx0aS1wcm90b2NvbCos IG9jY3VweWluZyBtdWNoIHNwYWNlcyBhbmQgcXVpdGUgbm90aWNlYWJsZSBvbiB0aGUgd2FsbHMu IHdlIG5lZWQgb25lIHRvIGRlcGxveSBzb21ld2hlcmUgbm90IHRoZSBvbmx5IG9uZSB0eXBlIHRv IGRlcGxveSBhbnl3aGVyZS4gOy0pDQo+PiANCj4+IFRoYXQgcG9pbnQgd291bGQgYmUgYW4gb3Bl cmF0aW9uYWwgbWF0dGVyIGZvciBkZXBsb3lpbmcgYW55IHN0YW5kYXJkaXplZCB0ZWNobm9sb2d5 LiBGb3IgZXhhbXBsZSwgYW4gb3BlcmF0b3IgYWRvcHQgT1NQRiB0byB1c2UgaXRzIHJpY2ggcm91 dGluZyBmZWF0dXJlIGJ1dCB0aGUgbmV0d29yayBpcyBzbWFsbCwgdGhlIG9wZXJhdG9yIGRvZXMg anVzdCBhcmVhIDAgcm91dGluZywgZXZlbiBPU1BGIGFsbG93IGludGVyLWFyZWEgcm91dGluZyBm b3Igc2NhbGUuIElzIGFuIGFub3RoZXIgb3NwZiBzcGVjaWZpY2F0aW9uIG5lZWRlZCBmb3IgJ09T UEYgQXJlYSAwIE9ubHkgUm91dGluZyc/DQo+IA0KPiBXZWxsIGlmIEkgb25seSBoYXZlIGEgc2lt cGxlIG5ldHdvcmsgYW5kIEkgdXNlcyBSSVAsIHlvdSBkb24ndCBtYWtlDQo+IE9TUEYgc29tZWhv dyBjb21wYXRpYmxlIHdpdGggUklQKG9yIGp1c3QgaW5jbHVkZSBSSVAgd2l0aCBhbiBPU1BGDQo+ IHRlcm1pbm9sb2d5IGZhY2U/IEkgZG9uJ3Qga25vdykgYW5kIHNheSAiaGV5LCBqdXN0IHVzZSB0 aGlzIHN1cGVyDQo+IHN1aXRlLCBkb24ndCBjb25zaWRlciBpdCBvdmVybG9hZGVkLCBpdCdzIGZv ciB1bml0eSEiDQoNCk9oLCB5b3UgZG9uJ3QgYXJndWUgdGhhdCBPU1BGIGNvdmVycyBhbiB1c2Ug Y2FzZSB3aGljaCBpcyBhbHNvIGNvdmVyZWQgYnkgUklQLiBTbyB0aGVuIHdoeSBhcmUgeW91IGFy Z3VpbmcgdGhhdCBhbiB1c2UgY2FzZSBvZiBNQVAgaXMgZXZlbnR1YWxseSBzYW1lIHdpdGggdGhl IExXNDYgdXNlIGNhc2U/DQoNCmNoZWVycywNCi0tc2F0b3J1DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29m dHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nv ZnR3aXJlcw== ------=_001_NextPart202718401548_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,=20 Satoru,
 
I believe OSPF = never=20 abandon its own essence in order to be a super suite and do something= very=20 strange to cover the use case which can be easily and clearly done by= RIP.=20
 
What's more, MAP is not OSPF, and LW4ov= er6 is=20 not RIP. MAP and LW4over6 have their own use case when they are origi= nally=20 designed. MAP is not supposed to do the 1:1 mode in the beginning.=20
 
Regards!
Jiang Dong
 
Date: 2012-06-27 12:37
To: Peng Wu
CC: softwires; = ian.farrer
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
On 2012/06/27, at 12:36, Peng Wu wrote:=
 
>>> Not quite.
>>> I believe that the most mo= tivate to start this work in the wg&nbs= p;has destined MAP to be 'multi-protocol soc= ket v2.0' that's what the former wg cha= ir wished to. Do you remember that?
>>> 
>>> i like the philosophy of "= multi-protocol socket". however, i moderately dou= bt the "multi-protocol socket v2.0" is a&nbs= p;perfect plan for every cases. in a qu= ite good hotel, we see typically one 'm= ulti-protocol socket' while a lot of local-s= tandard sockets. i never think it will = make me happy if i see every socket&nbs= p;in my room is *multi-protocol*, occupying = much spaces and quite noticeable on the = ;walls. we need one to deploy somewhere = ;not the only one type to deploy anywhe= re. ;-)
>> 
>> That point would be an operati= onal matter for deploying any standardized t= echnology. For example, an operator adopt OS= PF to use its rich routing feature but&= nbsp;the network is small, the operator does=  just area 0 routing, even OSPF allow&n= bsp;inter-area routing for scale. Is an anot= her ospf specification needed for 'OSPF Area=  0 Only Routing'?
> 
> Well if I only have a simple&= nbsp;network and I uses RIP, you don't = make
> OSPF somehow compatible with RIP(or&nbs= p;just include RIP with an OSPF
> terminology face? I don't know) an= d say "hey, just use this super
> suite, don't consider it overloaded,&nb= sp;it's for unity!"
 
Oh, you don't argue that OSPF covers&nb= sp;an use case which is also covered by=  RIP. So then why are you arguing = that an use case of MAP is eventually&n= bsp;same with the LW46 use case?
 
cheers,
--satoru
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart202718401548_=------ From pengwu.thu@gmail.com Tue Jun 26 23:38:04 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 C602121F857F for ; Tue, 26 Jun 2012 23:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.243 X-Spam-Level: X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flQg22IHzTA0 for ; Tue, 26 Jun 2012 23:38:04 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C89E421F8579 for ; Tue, 26 Jun 2012 23:38:03 -0700 (PDT) Received: by qadz3 with SMTP id z3so2268888qad.10 for ; Tue, 26 Jun 2012 23:38:03 -0700 (PDT) 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:content-transfer-encoding; bh=MXpKCJT3Zu4xesbESccpBtouYx5uRUDTQOy98C3Iwrk=; b=jJQsa81caYp/f4mKukSnkwlcN5aCcIRAEyYIEeXUtt+W0icMnxL0AmsdzwQYZIk557 h9PufBgPQVmMVKqT+x/MHnDHHO/bVwNJ6k5CpJaTYRJDSC0yclItGG5xLqcvfXALeb6N FhsOBm1MRAbtmCvFjkfm4kGGksUJkoYCOzhwVpbIatDVuMx/5POA8hJpmnRzwLKfUOa/ X6Wt7E593ov8aZTIVdOl6wkreXDfSkCbHfMxAwdYDMNO4kO2YkxvXmFu328kZWbZSwfU VFqSyoKVynlUsPkYYdxrKP3oNuIdKStOHZgy8Y8IXIE44p7EV8poCPQwunMnBBjIzObD dPpw== MIME-Version: 1.0 Received: by 10.224.78.195 with SMTP id m3mr29663462qak.1.1340779083202; Tue, 26 Jun 2012 23:38:03 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Tue, 26 Jun 2012 23:38:03 -0700 (PDT) In-Reply-To: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> Date: Wed, 27 Jun 2012 14:38:03 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 06:38:04 -0000 >>>> i like the philosophy of "multi-protocol socket". however, i moderatel= y doubt the "multi-protocol socket v2.0" is a perfect plan for every cases.= in a quite good hotel, we see typically one 'multi-protocol socket' while = a lot of local-standard sockets. i never think it will make me happy if i s= ee every socket in my room is *multi-protocol*, occupying much spaces and q= uite noticeable on the walls. we need one to deploy somewhere not the only = one type to deploy anywhere. ;-) >>> >>> That point would be an operational matter for deploying any standardize= d technology. For example, an operator adopt OSPF to use its rich routing f= eature but the network is small, the operator does just area 0 routing, eve= n OSPF allow inter-area routing for scale. Is an another ospf specification= needed for 'OSPF Area 0 Only Routing'? >> >> Well if I only have a simple network and I uses RIP, you don't make >> OSPF somehow compatible with RIP(or just include RIP with an OSPF >> terminology face? I don't know) and say "hey, just use this super >> suite, don't consider it overloaded, it's for unity!" > > Oh, you don't argue that OSPF covers an use case which is also covered by= RIP. So then why are you arguing that an use case of MAP is eventually sam= e with the LW46 use case? I'm clearly saying they have different use cases, but that's not the point. Let me repeat. If I want RIP, you cannot just place RIP into OSPF, put an OSPF "face" on it, and force me to use the OSPF "suite" while the essence of the protocol I'm using is still RIP. From satoru.matsushima@gmail.com Tue Jun 26 23:57: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 2E35111E8096 for ; Tue, 26 Jun 2012 23:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.412 X-Spam-Level: X-Spam-Status: No, score=-3.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTYNDqVMOqnE for ; Tue, 26 Jun 2012 23:57:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A81BE11E807F for ; Tue, 26 Jun 2012 23:57:44 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1164678pbc.31 for ; Tue, 26 Jun 2012 23:57:44 -0700 (PDT) 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=MS0IvtDfPOwniBx/xH6AsvQCJwFVAzcuCly8YTz4kXM=; b=z3lWwaA1o45rVqpuQ41/PC5yM+vbjXlsWrHpe5VcW/lDrdKy39CjxIop88KnPUiBCX IdYlLelEpt/+FhkWH6BIUa+9JQNoZsZxqRYS54IqWHo2OpeX+n2VKe8lsjcn0qZLfwj5 4vTR+BIfTpwYTFEa68XJbuLxFBRyrP2nr0hRS/kvtaDXFLgphPoHFSVyV1tLXa+NQmf4 7RhAjIzEymtnCHrShyEhzGFLK6YyDrhn1Y5AofpCQXIiWphFQwfSORmLwUel5Dd7UIaw keUcWiY3b9PupWDAUFqjOOuj/lbC1x7xM0oX7xtyjgxNg/4KxeE4gK5uhMVBeowRDdwV N7Uw== Received: by 10.68.197.136 with SMTP id iu8mr59985272pbc.111.1340780264276; Tue, 26 Jun 2012 23:57:44 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id nh6sm14279705pbc.44.2012.06.26.23.57.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 23:57:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 15:57:40 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 06:57:45 -0000 On 2012/06/27, at 15:38, Peng Wu wrote: >> Oh, you don't argue that OSPF covers an use case which is also = covered by RIP. So then why are you arguing that an use case of MAP is = eventually same with the LW46 use case? > I'm clearly saying they have different use cases, but that's not the > point. Let me repeat. If I want RIP, you cannot just place RIP into > OSPF, Agree on that it's not what I'm intended to. MAP thus never put DHCPv4 = over IPv6, nor PCP into its specification. Please keep your mind in = peace.=20 > put an OSPF "face" on it, and force me to use the OSPF "suite" > while the essence of the protocol I'm using is still RIP. Not to force, MAP uses its MAP protocol to an use case which also could = be covered by LW46's DHCPv4 over IPv6, or PCP. Correct? cheers, --satoru= From pengwu.thu@gmail.com Wed Jun 27 00:43: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 01F8B21F85FB for ; Wed, 27 Jun 2012 00:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re-7z1hdr+5a for ; Wed, 27 Jun 2012 00:43:49 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFF921F85EA for ; Wed, 27 Jun 2012 00:43:49 -0700 (PDT) Received: by qabj34 with SMTP id j34so660025qab.4 for ; Wed, 27 Jun 2012 00:43:48 -0700 (PDT) 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=PAkgXAwMgcIM3uQF8Rk7vhJva3/vaLjnL6fC6vrJQUo=; b=E/HJn6iEQ8lShM8i6xQm8q7d9HbqbrdpdZANV1mbmTiIAxbAvaHNkFlVH9IpNkkqrS hAEnn8ALSksrbqQ9/gLh7gfEN5BuEd08YHdPt4q+6iCrRTzraVTHU/jaZ2jXzoXqRm0B 4Nhhp7T/ELOzdJmnWEu9JsuA8UnglxqeoDZB5NdmQ2wZL8GCcjLEke6OOOlGYW/tIJSc /79RvQhgF1jKJrIvqlSCtRSFV8Uq+y3ddrELXJWKTzy+cSSFBg+12FcY05BK5HnNlsv5 /5sY0vO2AyldtWmyuzK9++jaRrn3o5EJVsTp//fL1Uh32MBD0WK64RYMwJjut69MTb+5 bUNw== MIME-Version: 1.0 Received: by 10.224.207.4 with SMTP id fw4mr29250472qab.82.1340783028386; Wed, 27 Jun 2012 00:43:48 -0700 (PDT) Received: by 10.229.216.212 with HTTP; Wed, 27 Jun 2012 00:43:48 -0700 (PDT) In-Reply-To: <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> Date: Wed, 27 Jun 2012 15:43:48 +0800 Message-ID: From: Peng Wu To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 07:43:50 -0000 On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima wrote: > > On 2012/06/27, at 15:38, Peng Wu wrote: > >>> Oh, you don't argue that OSPF covers an use case which is also covered by RIP. So then why are you arguing that an use case of MAP is eventually same with the LW46 use case? >> I'm clearly saying they have different use cases, but that's not the >> point. Let me repeat. If I want RIP, you cannot just place RIP into >> OSPF, > > Agree on that it's not what I'm intended to. MAP thus never put DHCPv4 over IPv6, nor PCP into its specification. Please keep your mind in peace. > >> put an OSPF "face" on it, and force me to use the OSPF "suite" >> while the essence of the protocol I'm using is still RIP. > > Not to force, MAP uses its MAP protocol to an use case which also could be covered by LW46's DHCPv4 over IPv6, or PCP. Correct? > Yes, there are mutliple choices for the provisioning protocol. But the essence here is 1.no v4-v6 address coupling, and thereby 2.explicitly provisoin the v4 address and port set. I would say the ORIGINAL MAP fits with neither points here. BTW, if I may, my suggestion on MAP to deal with the situation of EA bit=0 is, just say in this case there is no algorithmic address mapping so it's not consistent with general case or the original motivation, and thereby not covered. I believe it is not the main scenario you want to cover and this way you keep MAP clean. From bingxuere@gmail.com Wed Jun 27 00:53: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 411B021F8648 for ; Wed, 27 Jun 2012 00:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQ8-DYCe3uOp for ; Wed, 27 Jun 2012 00:53:40 -0700 (PDT) Received: from mail-yw0-f53.google.com (mail-yw0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8EC21F8645 for ; Wed, 27 Jun 2012 00:53:34 -0700 (PDT) Received: by yhp26 with SMTP id 26so1053108yhp.26 for ; Wed, 27 Jun 2012 00:53:33 -0700 (PDT) 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=uM9WtlsvLnsB1UyneCtW6c8IG7zw3rSiOJN91p0gyB0=; b=nTt/zZn/VTjuT2MmShZID5+Jx/nt9idW2gP/e2i5vmkFUuAb/go77Gcs/kygQ5KacR 5RvR5cKv/DYPKsBeHWW8BsHZQBDR9EZ13HhsW940OGTqhjiYwG10IstoE4f9Ye3AssS+ 1s6YEtVkB5f50cgH1rC7Ri9pvJUGa6ULpddNFcWe7Vn/FUegDOjGcNCSGI1hY1xxPfH5 yrjOR2nzthdztYzHJ4LA1nI6Bi/yl8d5ZiFzDHMYZxP7dF7o7ocnTgnMgAD8YtY03lMZ 7e451QfghYcjh6lLTQHelQFrqOwPSpeWZQSPK+cP7yxl56W7CXCJQ6kXbi18GhapL3sU q0AQ== Received: by 10.50.188.131 with SMTP id ga3mr621011igc.54.1340783613435; Wed, 27 Jun 2012 00:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 27 Jun 2012 00:52:53 -0700 (PDT) In-Reply-To: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> From: Qiong Date: Wed, 27 Jun 2012 15:52:53 +0800 Message-ID: To: Peng Wu Content-Type: multipart/alternative; boundary=14dae9341157ffe0dc04c36f82b5 Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 07:53:43 -0000 --14dae9341157ffe0dc04c36f82b5 Content-Type: text/plain; charset=UTF-8 Yes. And in ietf-map section1, it declares: The residual IPv4 over IPv6 mechanisms must be capable of algorithmically map between an IPv4 prefix, IPv4 address or a shared IPv4 address and an IPv6 address It is not consistent with EA-bit=0 case. On Wed, Jun 27, 2012 at 3:43 PM, Peng Wu wrote: > On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima > wrote: > > > > On 2012/06/27, at 15:38, Peng Wu wrote: > > > >>> Oh, you don't argue that OSPF covers an use case which is also covered > by RIP. So then why are you arguing that an use case of MAP is eventually > same with the LW46 use case? > >> I'm clearly saying they have different use cases, but that's not the > >> point. Let me repeat. If I want RIP, you cannot just place RIP into > >> OSPF, > > > > Agree on that it's not what I'm intended to. MAP thus never put DHCPv4 > over IPv6, nor PCP into its specification. Please keep your mind in peace. > > > >> put an OSPF "face" on it, and force me to use the OSPF "suite" > >> while the essence of the protocol I'm using is still RIP. > > > > Not to force, MAP uses its MAP protocol to an use case which also could > be covered by LW46's DHCPv4 over IPv6, or PCP. Correct? > > > Yes, there are mutliple choices for the provisioning protocol. But the > essence here is 1.no v4-v6 address coupling, and thereby 2.explicitly > provisoin the v4 address and port set. I would say the ORIGINAL MAP > fits with neither points here. > > BTW, if I may, my suggestion on MAP to deal with the situation of EA > bit=0 is, just say in this case there is no algorithmic address > mapping so it's not consistent with general case or the original > motivation, and thereby not covered. I believe it is not the main > scenario you want to cover and this way you keep MAP clean. > _______________________________________________ > 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/ * =============================================== --14dae9341157ffe0dc04c36f82b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes. And in ietf-map section1, it declares:

The residual IPv4 over I= Pv6 mechanisms must be capable of algorithmically map between an IPv4 prefi= x, IPv4 address or a shared IPv4 address and an IPv6 address

It is n= ot consistent with EA-bit=3D0 case.

On Wed, Jun 27, 2012 at 3:43 PM, Peng Wu <pengwu.thu@gmail.com> wrote:
On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima
<satoru.matsushima@gmail.= com> wrote:
>
> On 2012/06/27, at 15:38, Peng Wu wrote:
>
>>> Oh, you don't argue that OSPF covers an use case which is = also covered by RIP. So then why are you arguing that an use case of MAP is= eventually same with the LW46 use case?
>> I'm clearly saying they have different use cases, but that'= ;s not the
>> point. Let me repeat. If I want RIP, you cannot just place RIP int= o
>> OSPF,
>
> Agree on that it's not what I'm intended to. MAP thus never pu= t DHCPv4 over IPv6, nor PCP into its specification. Please keep your mind i= n peace.
>
>> put an OSPF "face" on it, and force me to use the OSPF &= quot;suite"
>> while the essence of the protocol I'm using is still RIP.
>
> Not to force, MAP uses its MAP protocol to an use case which also coul= d be covered by LW46's DHCPv4 over IPv6, or PCP. Correct?
>
Yes, there are mutliple choices for the provisioning protocol. But th= e
essence here is 1.no v4-v6 ad= dress coupling, and thereby 2.explicitly
provisoin the v4 address and port set. I would say the ORIGINAL MAP
fits with neither points here.

BTW, =C2=A0if I may, my suggestion on MAP to deal with the situation of EA<= br> bit=3D0 is, just say in this case there is no algorithmic address
mapping so it's not consistent with general case or the original
motivation, and thereby not covered. I believe it is not the main
scenario you want to cover and this way you keep MAP clean.
___________________________________= ____________
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

--14dae9341157ffe0dc04c36f82b5-- From satoru.matsushima@gmail.com Wed Jun 27 01:12:41 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 9CCF121F8600 for ; Wed, 27 Jun 2012 01:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGsCSpEZtVRs for ; Wed, 27 Jun 2012 01:12:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5771421F85EA for ; Wed, 27 Jun 2012 01:12:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1255299pbc.31 for ; Wed, 27 Jun 2012 01:12:40 -0700 (PDT) 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=jw65TtP9bMLYEdABHnz3vTChLRrYtXNXr4mv16YUILQ=; b=E/b2EkK7UeUBRD/SPn+Xtgz3Vl5VoB7nJ5iAMr3gWLPn1G6QYsPfbiWtvWKliFXNTB tYRBMMLxMxowLjmx5lNLHoxea16JGgEH1N6Y7kXyzO+iWv0KXblCUyzdaKfrWLfMCwge cIuWYGPPkU7jokqLQxdLtLPZ+gJipCdusID8BXdNIFjsoShuhgRRRrb3j5iXacAfTgMM s0MXNI7t3j+XgnfXR4VgGoyoZtP7IDAFMIIn2/QPqDwYQNcm5dGQyPj4sTbVPayczd0w gM74qGNHifnyiPOOyafp1n138YHLLhtJjyfd6jKrAfgAVN9OGmsRVUsKvq3UI8djMkvr ILfA== Received: by 10.68.223.35 with SMTP id qr3mr62519625pbc.83.1340784760006; Wed, 27 Jun 2012 01:12:40 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id pi7sm9141256pbb.56.2012.06.27.01.12.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 01:12:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 17:12:34 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <00E36C66-430E-428F-9E0B-0C5929FD951A@gmail.com> References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> To: Qiong X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 08:12:41 -0000 Qiong, On 2012/06/27, at 16:52, Qiong wrote: > Yes. And in ietf-map section1, it declares: >=20 > The residual IPv4 over IPv6 mechanisms must be capable of = algorithmically map between an IPv4 prefix, IPv4 address or a shared = IPv4 address and an IPv6 address >=20 > It is not consistent with EA-bit=3D0 case. >=20 Not true. Whether ea-len is zero or not, when a rule-ipv6-prefix in a = BMR is exact matched with a CE's prefix, it must be legitimate that = provisioning the CE to have rule-ipv4-prefix and the PSID in the BMR. cheers, --satoru > On Wed, Jun 27, 2012 at 3:43 PM, Peng Wu wrote: > On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima > wrote: > > > > On 2012/06/27, at 15:38, Peng Wu wrote: > > > >>> Oh, you don't argue that OSPF covers an use case which is also = covered by RIP. So then why are you arguing that an use case of MAP is = eventually same with the LW46 use case? > >> I'm clearly saying they have different use cases, but that's not = the > >> point. Let me repeat. If I want RIP, you cannot just place RIP into > >> OSPF, > > > > Agree on that it's not what I'm intended to. MAP thus never put = DHCPv4 over IPv6, nor PCP into its specification. Please keep your mind = in peace. > > > >> put an OSPF "face" on it, and force me to use the OSPF "suite" > >> while the essence of the protocol I'm using is still RIP. > > > > Not to force, MAP uses its MAP protocol to an use case which also = could be covered by LW46's DHCPv4 over IPv6, or PCP. Correct? > > > Yes, there are mutliple choices for the provisioning protocol. But the > essence here is 1.no v4-v6 address coupling, and thereby 2.explicitly > provisoin the v4 address and port set. I would say the ORIGINAL MAP > fits with neither points here. >=20 > BTW, if I may, my suggestion on MAP to deal with the situation of EA > bit=3D0 is, just say in this case there is no algorithmic address > mapping so it's not consistent with general case or the original > motivation, and thereby not covered. I believe it is not the main > scenario you want to cover and this way you keep MAP clean. > _______________________________________________ > 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 From satoru.matsushima@gmail.com Wed Jun 27 01:25: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 A834521F86A7 for ; Wed, 27 Jun 2012 01:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id refIHWUo5V1p for ; Wed, 27 Jun 2012 01:25:19 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25AC821F86A2 for ; Wed, 27 Jun 2012 01:25:19 -0700 (PDT) Received: by dacx6 with SMTP id x6so1080793dac.31 for ; Wed, 27 Jun 2012 01:25:18 -0700 (PDT) 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=hw4IzA7aHKVPmmXscGsel0H0lDLrOUmAz5ee0ZJujAM=; b=sdt2FEgqMxllBDqzx09x/9Anl75h5kHj8uDG90rNWJUGZ3j5bUzBIkIHqs4ppvP9ic ElTPhaI3w63lfx2ENzN4UYRBFnk7duntgGjQkiHfBIDj/040ceK9kAmayGwKkvwkZxkj 90EP6DzJRyROn3s+K6QT8wak/h4eq3ey0Fxda/mK4s2RO/OnJpAHriR4Zln4vshk2rF/ SqXb3QZ6yOcEK2Gl1xuuC7EKI5/zE+ukUod1QKLw2GdX73AJNCiXmXXUgX+4cOZOIN8k 5Q3As4GngYVOrtDxFkSPYEncQN7YJXw89JFSkJ6cOKGemrdHNA0iejmFrCpBLPS2iSFq XMTw== Received: by 10.68.212.102 with SMTP id nj6mr62489329pbc.15.1340785518769; Wed, 27 Jun 2012 01:25:18 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id nv6sm14493303pbc.42.2012.06.27.01.25.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 01:25:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 17:25:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> To: Peng Wu X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org, ian.farrer@telekom.de Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 08:25:19 -0000 On 2012/06/27, at 16:43, Peng Wu wrote: > On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima > wrote: >>=20 >> On 2012/06/27, at 15:38, Peng Wu wrote: >>=20 >>>> Oh, you don't argue that OSPF covers an use case which is also = covered by RIP. So then why are you arguing that an use case of MAP is = eventually same with the LW46 use case? >>> I'm clearly saying they have different use cases, but that's not the >>> point. Let me repeat. If I want RIP, you cannot just place RIP into >>> OSPF, >>=20 >> Agree on that it's not what I'm intended to. MAP thus never put = DHCPv4 over IPv6, nor PCP into its specification. Please keep your mind = in peace. >>=20 >>> put an OSPF "face" on it, and force me to use the OSPF "suite" >>> while the essence of the protocol I'm using is still RIP. >>=20 >> Not to force, MAP uses its MAP protocol to an use case which also = could be covered by LW46's DHCPv4 over IPv6, or PCP. Correct? >>=20 > Yes, there are mutliple choices for the provisioning protocol. But the > essence here is 1.no v4-v6 address coupling, and thereby 2.explicitly > provisoin the v4 address and port set. I would say the ORIGINAL MAP > fits with neither points here. >=20 > BTW, if I may, my suggestion on MAP to deal with the situation of EA > bit=3D0 is, just say in this case there is no algorithmic address > mapping so it's not consistent with general case or the original > motivation, and thereby not covered. I believe it is not the main > scenario you want to cover and this way you keep MAP clean. Thank you for your technical suggestion.=20 But it couldn't be an option because MAP node finds its BMR in longest = match basis between end-user ipv6 prefix and the rule-ipv6-prefix = whether the ea-len is zero or not in the BMR. FWIW, my suggestion is that LW46 adopts MAP provisioned CE to be a kind = of TI which connected to a TC. cheers, --satoru From ian.farrer@telekom.de Wed Jun 27 01:39: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 8C31F21F85F2 for ; Wed, 27 Jun 2012 01:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hChOduS60sNp for ; Wed, 27 Jun 2012 01:39:53 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id AEFD721F85D7 for ; Wed, 27 Jun 2012 01:39:51 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 27 Jun 2012 10:39:49 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 27 Jun 2012 10:39:49 +0200 From: To: Date: Wed, 27 Jun 2012 10:39:41 +0200 Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: Ac1TcRGKcR+XdGg9RqKLQ25rF2xrdAAyKiew Message-ID: <8A1B81989BCFAE44A22B2B86BF2B76318918594767@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_8A1B81989BCFAE44A22B2B86BF2B76318918594767HE111643EMEA1_" MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 08:39:54 -0000 --_000_8A1B81989BCFAE44A22B2B86BF2B76318918594767HE111643EMEA1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Woj, Comments in line. Cheers, Ian ________________________________ From: Wojciech Dec [mailto:wdec.ietf@gmail.com] Sent: Dienstag, 26. Juni 2012 09:55 To: Farrer, Ian Cc: satoru.matsushima@gmail.com; softwires@ietf.org Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT ref= lect the consensus from the WG On 26 June 2012 09:13, = > wrote: Hi Satoru, Comment in line below. Best regards, Ian Date: Mon, 25 Jun 2012 18:46:18 +0900 From: Satoru Matsushima > To: Peng Wu > Cc: softwires@ietf.org, Yong Cui > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOTreflect the consensus from the WG Message-ID: <5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com> Content-Type: text/plain; charset=3Diso-8859-1 Hi Peng, On 2012/06/25, at 18:34, Peng Wu wrote: Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 = options. BMR: o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o Rule-ipv4-prefix : x.x.x.x/32 o EA-length : 0 o Port-param option : {PSID/length} This BMR could be a LW46 provisioning means. Again, all the information needed is the IPv4 address and port set. 1) The item like rule-ipv6-prefix is not needed at all. 2) Port set or PSID still needs extra provisioning (while in regular MAP it's embedded in IPv6 address) So why make it so difficult and obscure Not difficult, easy business for CE which implemented MAP. Other difficulty= in operator side in particular provisioning complex, that should be same w= ith LW46. It also makes to complete MAP spec in the ea-len zero case. [IF] Additional complexity in the operator side is where I see the problem = with MAP in our case. The strength that MAP offers is for the mesh model an= d the complexity that it brings is a neat way of achieving this. But if hub= -and-spoke is the only deployment scenario that you need, then the complexi= ty for mesh is an unnecessary addition that results in operational complexi= ty, which is something we're trying to engineer out wherever we can. E.g. In the case above, for a shared IP address, the source port range is e= ncoded in the port-param option. To troubleshoot user connectivity, ops nee= d to have a good understanding of how this is being calculated so that they= can trace the user. Not the end of the world, but with millions of custome= rs and a hundred support staff, it's just better avoided if possible. This = logic also then needs to be built into other business support systems that = rely on the customers IP/port range as an identifier. LW46 solves this with a simple (though long) lookup table. This does mean t= hat it's very easy to extract how a user is configured or identified with a= minimum of additional knowledge and calculating tools. Well, a couple of observations: A) MAP allows you to optimize complexity in not having to deal with per sub= scriber rules in cases where this is feasible. But this re-introduces v4 and v6 addressing dependency which we're trying t= o avoid. B) You're referring to data representation as an operational problem, which= if so, actually applies to any solution incl LW46 that transmits port-rang= e info to a client. I.e. "Whatever support staff" needs to be schooled to u= se some logic to glean useful port information from the data sent to a clie= nt "Don't worry about unnecessary complexity, we'll just do more training!" is= n't a very powerful argument in our business. C) It is very easy to represent MAP data as port range info on routers, too= ls, etc. On routers, I'm sure that it is. However, the fact that you need a tool to = work out the mapping again points to complexity. On internally developed an= d 3rd party BSS systems then it's more work that offers no benefit. -Woj. cheers, --satoru ------------------------------ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_8A1B81989BCFAE44A22B2B86BF2B76318918594767HE111643EMEA1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Woj,
 
Comments in line.
 
Cheers,
Ian

From: Wojciech Dec [mailto:wdec.ietf@gm= ail.com]=20
Sent: Dienstag, 26. Juni 2012 09:55
To: Farrer,=20 Ian
Cc: satoru.matsushima@gmail.com;=20 softwires@ietf.org
Subject: Re: [Softwires] [Softwire]=20 draft-ietf-softwire-map-00 does NOT reflect the consensus from the=20 WG



On 26 June 2012 09:13, <ian.farrer@telekom.de> wrote:
Hi Satoru,

Comment in line=20 below.

Best regards,
Ian

Date: Mon, 25 Jun= 2012=20 18:46:18 +0900
From: Satoru Mats= ushima=20 <satoru.matsushima@gmail.com>
To: Peng Wu <<= A=20 href=3D"mailto:pengwu.thu@gmail.com"=20 target=3D_blank>pengwu.thu@gmail.com>
Cc: softwires@ietf.org= , Yong=20 Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [Sof= twires]=20 [Softwire] draft-ietf-softwire-map-00 does
NOT= reflect=20 the consensus from the WG
Message-ID: <<= A=20 href=3D"mailto:5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com"=20 target=3D_blank>5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com>
Content-Type:=20 text/plain; charset=3Diso-8859-1

Hi Peng,

On 2012/06/25, at= 18:34,=20 Peng Wu wrote:

Let's think that a CE provisioned with following BMR comes from = MAP=20 DHCPv6 options.
BMR:
  o Rule-ipv6-prefix  : {exact matched with = CE's=20 delegated prefix}
  o Rule-ipv4-prefix  : x.x.x.x/32
  o=20 EA-length         : 0
  o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
Again, all the information needed is the IPv4 address and port=20 set.
1) The item like rule-ipv6-prefix is not needed at all.
2) Port set or PSID still needs extra provisioning (while in=20 regular
MAP it's embedded in IPv6 address)
So why make it so difficult and obscure

Not difficult, ea= sy=20 business for CE which implemented MAP. Other difficulty in operator side = in=20 particular provisioning complex, that should be same with LW46. It also m= akes=20 to complete MAP spec in the ea-len zero case.

[IF] Additional=20 complexity in the operator side is where I see the problem with MAP in ou= r=20 case. The strength that MAP offers is for the mesh model and the complexi= ty=20 that it brings is a neat way of achieving this. But if hub-and-spoke is t= he=20 only deployment scenario that you need, then the complexity for mesh is a= n=20 unnecessary addition that results in operational complexity, which is=20 something we're trying to engineer out wherever we can.
E.g. In the case = above,=20 for a shared IP address, the source port range is encoded in the port-par= am=20 option. To troubleshoot user connectivity, ops need to have a good=20 understanding of how this is being calculated so that they can trace the = user.=20 Not the end of the world, but with millions of customers and a hundred su= pport=20 staff, it's just better avoided if possible. This logic also then needs t= o be=20 built into other business support systems that rely on the customers IP/p= ort=20 range as an identifier.
LW46 solves this = with a=20 simple (though long) lookup table. This does mean that it's very easy to= =20 extract how a user is configured or identified with a minimum of addition= al=20 knowledge and calculating tools.

Well, a couple of observations:
A) MAP allows you to= =20 optimize complexity in not having to deal with per subscriber rules in case= s=20 where this is feasible.  
 
But=20 this re-introduces v4 and v6 addressing dependency which we're trying = to=20 avoid.
 
B) You're referring = to data=20 representation as an operational problem, which if so, actually applies to = any=20 solution incl LW46 that transmits port-range info to a client. I.e. "Whatev= er=20 support staff" needs to be schooled to use some logic to glean useful port= =20 information from the data sent to a client=  
 
"Don't=20 worry about unnecessary complexity, we'll just do more training!"=20 isn't a very powerful argument in our=20 business. 
 
C) It is very easy t= o=20 represent MAP data as port range info on routers, tools, etc.
 
On=20 routers, I'm sure that it is. However, the fact that you need a tool to wor= k out=20 the mapping again points to complexity. On internally developed and 3rd par= ty=20 BSS systems then it's more work that offers no benefit.
 
-Woj.
 

cheers,
--satoru

----------------------= --------


=

_______________________________________________
Softwire= s=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--_000_8A1B81989BCFAE44A22B2B86BF2B76318918594767HE111643EMEA1_-- From wdec.ietf@gmail.com Wed Jun 27 01:43: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 E962C21F85F2 for ; Wed, 27 Jun 2012 01:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDN-YfnI7mU8 for ; Wed, 27 Jun 2012 01:43:28 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD5521F857F for ; Wed, 27 Jun 2012 01:43:28 -0700 (PDT) Received: by qcmt36 with SMTP id t36so422199qcm.15 for ; Wed, 27 Jun 2012 01:43:28 -0700 (PDT) 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=Dp1FT2VCujbTeOvhU+gfIs84Da8L4dxCemqR6Y+xb+U=; b=K+MpLqqkoKaDBTYTB3x7D8pnGOHFvU95advfA4UcQrq4m3OPAoTQRhELtHzNnH8nCx FhoNl/zPzhATaVAnlywqeFnftoLYTMyWmSU3GgkdPhmFp/UoJ124q+W8JNgpKVi5/DxD uyewkFcw9Kx6xONTluAcEQqtfhKZtn4fTGyqiNfFuKRQg/ucgUWLmj0rbFFhsDG5Y/6a tAvAgPi2qYIEpOs+yuKR/Eqdmv506WERXzZSesHPP04w+6yLgXg3Sfj22BV0fUrfv3iX tyzslYeL4IdaoJlmRWGKENT67Wvt4Sd0sattAEivw8WW1phJsGSZYziSpOV6aciPPCH5 rWVw== MIME-Version: 1.0 Received: by 10.224.218.73 with SMTP id hp9mr14256550qab.67.1340786607877; Wed, 27 Jun 2012 01:43:27 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Wed, 27 Jun 2012 01:43:27 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jun 2012 10:43:27 +0200 Message-ID: From: Wojciech Dec To: Maoke Content-Type: multipart/alternative; boundary=20cf300fb3d77b6e4904c3703519 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 27 Jun 2012 08:43:30 -0000 --20cf300fb3d77b6e4904c3703519 Content-Type: text/plain; charset=ISO-8859-1 Hi Maoke, inline... On 27 June 2012 05:28, Maoke wrote: > hi dear authors, > > as the map-00 draft contains the normative 1:1 mode statement that is new > in comparison to the previous versions, i'd like to ask some technical > questions in order to clarify the understanding. > > Section 4. page 9: > > MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a > MAP domain per subscriber, and the CE is configured in hub and spoke > mode, with only a DMR and no other mapping rules. This allows for a > mode where the BR has one rule per subscriber and the provisioning of > IPv4 address or prefix and port sets is independent of the End-User > IPv6 prefix. > > Question #1: who is a "subscriber"? the definition is missing. and > relatedly, what is the protocol for the subscription? the specification on > the protocol is missing too. > Answer 1: Subscriber = MAP CE. We will clarify the term. > > Question #2: what is the relationship between 1:1 mode, encapsulation > mode, translation mode, hub&spoke mode, mesh mode? are they independent to > each other, exclusively or not, somehow orthogonal or not? the > specification on the "mode" is missing. > Answer 2: mode = forwarding mode, also known as transport mode. There are two of these, translation and encapsulation. No relation between the rest of the things you mention. > > Question #3: what is the resource for deployment of a "MAP domain"? the > MAP spec never define that. however, we kept understanding that the > resource for a "MAP domain" includes: > - an IPv4 prefix (with prefix length 32 or less) shared by > CEs in this domain > - an IPv6 prefix (with prefix length 64 or less) delegated to > the CEs in this domain with a /64 (or shorter) per CE (as the basic model > of prefix d > the newly introduced "1:1 mode" obviously abandons this > understanding, then an explicit definition on the resource of a "MAP > domain" is requested. this is the origin and essential starting point of > the MAP deployment. > Answer 3: What do you mean by resource for deployment?? It has, and always has been an IPv6 prefix and an IPv4 address. This is the same in *all* of this solution space. The split in terms of how one arrives at the IPv4 address and port-range has always been variable in MAP. Additional point: There is no newly introduced 1:1 mode, as the spec hasn't changed. Folks who implemented according to the previous spec, whihc you seem to indicate had no 1:1 mode see no difference. Disabling the 1:1 mode would actually require a spec change. > > Section 5. page 10: > > * Forwarding mode > > Question #4: this appears twice at the definition of BMR and DMR, > respectively. though Wojieich and Remi has discussed that in another > thread, i would like to confirm: is this mode a domain configuration > parameter or a rule parameter? > Answer 4: Confirmed, intent is for it to be per domain. > > Question #5: does this "forwarding mode" is a enumerate type of {MAP-T, > MAP-E, 1:1, hub&spoke, mesh} or else, e.g., {MAP-T, MAP-E} x {1:1, N:1} x > {hub&spoke, mesh}, where the "x" is the operator for de Cartesian product > of sets? (related to #2) > Answer 5: No need to enumerate, because there is no relation between these (answered above) > > Section 7.1 page 19: > > In 1:1 mode, the MAP CE is provisioned with only a Default Mapping > Rule, and the full IPv4 address/prefix and port range is provisioned > using the DHCP option. > > Question #6: is the CE or the subscriber the receiver of the "full IPv4 > address/prefix and port range" (correction: port set) to be provisioned? or > does it mean a CE is a subscriber itself in the 1:1 mode? > Woj> MAP CE. > > Section 7.3 page 19: > > A MAP-E CE provisioned with only a Default Mapping Rule, as in the > 1:1 case, and with no IPv4 address and port range configured by other > means, MUST disable its NAT44 functionality. > > Question #7: this text is contradictory with Section 7.1. is the DHCP > option a sort of "other means" or not, or there's something out of scope of > this draft? > Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing in the architecture prevents any other provisioning mechanisms to be used incl dhcpv4, snmp, etc. > > Question #8: what is the consequence of disabling the NAT44 functionality > on CE when a subscriber having a PSID of a share IPv4 address is running > behind that CE as a 1:1 mode domain? > Woj> That is not possible. We can be clearer in saying that if the CPE has no IPv4 address configured then NAT44 is to be disabled (kind of obvious) > > before all of the above questions and further questions possibly to be > generated during the discussion are fully clarified, i cannot help but > gently show my disagreement on putting the current draft as working group > result. i also hope the MAP spec authors kindly understand with so many > uncertainty modifying MAP deployment draft to fit the MAP spec is a > mission-impossible for the time being. > Woj> What is the basis of your gentle disagreement, and its timing now? The merged of the drafts was discussed previously, and circulated on the design team of which you are a apart of. It appears your comments relate to the supposed controversial 1:1 non-normative text. Regards, Woj. > > thanks and regards, > maoke > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --20cf300fb3d77b6e4904c3703519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Maoke,

inline...

On 27 June 201= 2 05:28, Maoke <fibrib@gmail.com> wrote:
hi dear authors,=A0

as the map-00 draft c= ontains the normative 1:1 mode statement that is new in comparison to the p= revious versions, i'd like to ask some technical questions in order to = clarify the understanding.=A0

Section 4. page 9:

MAP can als= o be provisioned in 1:1 mode. In 1:1 mode the BR has a
MAP domain pe= r subscriber, and the CE is configured in hub and spoke
mode, with on= ly a DMR and no other mapping rules. This allows for a
mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User
= IPv6 prefix.

Question #1: who is a "subscr= iber"? the definition is missing. and relatedly, what is the protocol = for the subscription? the specification on the protocol is missing too.

Answer 1: Subscriber =3D MAP CE. We will clarify the = term.

Question #2: what is the relationship between 1:1 mode,= encapsulation mode, translation mode, hub&spoke mode, mesh mode? are t= hey independent to each other, exclusively or not, somehow orthogonal or no= t? the specification on the "mode" is missing.=A0

Answer 2: mode =3D forwarding mode, also known as tra= nsport mode. There are two of these, translation and encapsulation. No rela= tion between the rest of the things you mention.

Question #3: what is the resource for deployment of a &= quot;MAP domain"? the MAP spec never define that. however, we kept und= erstanding that the resource for a "MAP domain" includes:=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0- an IPv4 prefix (with prefix length 32 or = less) shared by CEs in this domain
=A0 =A0 =A0 =A0 =A0 =A0 =A0- a= n IPv6 prefix (with prefix length 64 or less) delegated to the CEs in this = domain with a /64 (or shorter) per CE (as the basic model of prefix d
=A0 =A0 =A0 =A0 =A0 =A0 =A0the newly introduced "1:1 mode" o= bviously abandons this understanding, then an explicit definition on the re= source of a "MAP domain" is requested. this is the origin and ess= ential starting point of the MAP deployment.=A0

Answer 3: What do you mean by resource for deployment= ?? It has, and always has been an IPv6 prefix and an IPv4 address. This is = the same in *all* of this solution space. The split in terms of how one arr= ives at the IPv4 address and port-range has always been variable in MAP. Additional point: There is no newly introduced 1:1 mode, as the spec hasn&#= 39;t changed. Folks who implemented according to the previous spec, whihc y= ou seem to indicate had no 1:1 mode see no difference. Disabling the 1:1 mo= de would actually require a spec change.

Section 5. page 10:

=A0 * = Forwarding mode

Question #4: this appears twice a= t the definition of BMR and DMR, respectively. though Wojieich and Remi has= discussed that in another thread, i would like to confirm: is this mode a = domain configuration parameter or a rule parameter?

Answer 4: Confirmed, intent is for it to be per domai= n.

Question #5: does this "forwarding mode" is a= enumerate type of {MAP-T, MAP-E, 1:1, hub&spoke, mesh} or else, e.g., = {MAP-T, MAP-E} x {1:1, N:1} x {hub&spoke, mesh}, where the "x"= ; is the operator for de Cartesian product of sets? (related to #2)

Answer 5: No need to enumerate, because there is no r= elation between these (answered above)

Section 7.1 page 19:

In 1:= 1 mode, the MAP CE is provisioned with only a Default Mapping
Rule, a= nd the full IPv4 address/prefix and port range is provisioned
using t= he DHCP option.

Question #6: is the CE or the subscriber the rece= iver of the "full IPv4 address/prefix and port range" (correction= : port set) to be provisioned? or does it mean a CE is a subscriber itself = in the 1:1 mode?

Woj>=A0 MAP CE.

Section 7.3 page 19:

A MAP-E C= E provisioned with only a Default Mapping Rule, as in the
1:1 case, a= nd with no IPv4 address and port range configured by other
means, MUS= T disable its NAT44 functionality.

Question #7: this text is contradictory with Section 7.= 1. is the DHCP option a sort of "other means" or not, or there= 9;s something out of scope of this draft?=A0

Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing i= n the architecture prevents any other provisioning mechanisms to be used in= cl dhcpv4, snmp, etc.

Question #8: what is the consequence of disabling the N= AT44 functionality on CE when a subscriber having a PSID of a share IPv4 ad= dress is running behind that CE as a 1:1 mode domain?=A0

Woj>=A0 That is not possible.=A0 We can be clearer in saying th= at if the CPE has no IPv4 address configured then NAT44 is to be disabled (= kind of obvious)

before all of the above questions and further questions= possibly to be generated during the discussion are fully clarified, i cann= ot help but gently show my disagreement on putting the current draft as wor= king group result. i also hope the MAP spec authors kindly understand with = so many uncertainty modifying MAP deployment draft to fit the MAP spec is a= mission-impossible for the time being.=A0

Woj> What is the basis of your gentle disagreement= , and its timing now? The merged of the drafts was discussed previously, an= d circulated on the design team of which you are a apart of. It appears you= r comments relate to the supposed controversial 1:1 non-normative text.

Regards,
Woj.

thanks and regards,
maoke

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


--20cf300fb3d77b6e4904c3703519-- From wdec.ietf@gmail.com Wed Jun 27 01:53: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 DF37C21F8658 for ; Wed, 27 Jun 2012 01:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf1FrOThVrc5 for ; Wed, 27 Jun 2012 01:53:47 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 36A9621F865A for ; Wed, 27 Jun 2012 01:53:46 -0700 (PDT) Received: by qcmt36 with SMTP id t36so425621qcm.15 for ; Wed, 27 Jun 2012 01:53:45 -0700 (PDT) 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=2xrXJDH33P/abrwRZPw1c3aoJ4G2W8NbP7H8m3wRyzw=; b=cSN8DkYSAMJqkc7RIKXMnnI3eNCWDi/nRY80RFqOD5rfN8ijojtvwWsHbfuWfLIyau cxjZdoUadkgUwYUAjyzuLeTkDmMo+RBB9YE7QhKa+Vg9nK7NGftM8t64mf8v0T9GHMWx l5VjTVL/xwlPift4WNjiLsVC1oIWZh6XHKfN8LjMYIJSJCKwi4zoX28RfxJFkI8zDPEk dAjtY/xRKmW0+SlUf3eAvH6tZoc/48fW1GeDJ4wolEuGGDFKfvQlh5d1RKrR7lN9cn3K BNqBJm9MvBL3DA3rYJccxU6OkfSgDj0GJ3SXeQfgsV0h792otJMbHKnTNPti0TeN6udb /BPQ== MIME-Version: 1.0 Received: by 10.224.101.193 with SMTP id d1mr2522453qao.20.1340787225534; Wed, 27 Jun 2012 01:53:45 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Wed, 27 Jun 2012 01:53:45 -0700 (PDT) In-Reply-To: <8A1B81989BCFAE44A22B2B86BF2B76318918594767@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: <8A1B81989BCFAE44A22B2B86BF2B76318918594767@HE111643.EMEA1.CDS.T-INTERNAL.COM> Date: Wed, 27 Jun 2012 10:53:45 +0200 Message-ID: From: Wojciech Dec To: ian.farrer@telekom.de Content-Type: multipart/alternative; boundary=20cf306681574c215604c3705aeb Cc: softwires@ietf.org Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 08:53:48 -0000 --20cf306681574c215604c3705aeb Content-Type: text/plain; charset=ISO-8859-1 Ian, On 27 June 2012 10:39, wrote: > ** > Hi Woj, > > Comments in line. > > Cheers, > Ian > > ------------------------------ > *From:* Wojciech Dec [mailto:wdec.ietf@gmail.com] > *Sent:* Dienstag, 26. Juni 2012 09:55 > *To:* Farrer, Ian > *Cc:* satoru.matsushima@gmail.com; softwires@ietf.org > *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT > reflect the consensus from the WG > > > > On 26 June 2012 09:13, wrote: > >> Hi Satoru, >> >> Comment in line below. >> >> Best regards, >> Ian >> >> Date: Mon, 25 Jun 2012 18:46:18 +0900 >> From: Satoru Matsushima >> To: Peng Wu >> Cc: softwires@ietf.org, Yong Cui >> Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does >> NOTreflect the consensus from the WG >> Message-ID: <5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com> >> Content-Type: text/plain; charset=iso-8859-1 >> >> Hi Peng, >> >> On 2012/06/25, at 18:34, Peng Wu wrote: >> >> Let's think that a CE provisioned with following BMR comes from MAP >> DHCPv6 options. >> BMR: >> o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} >> o Rule-ipv4-prefix : x.x.x.x/32 >> o EA-length : 0 >> o Port-param option : {PSID/length} >> This BMR could be a LW46 provisioning means. >> >> Again, all the information needed is the IPv4 address and port set. >> 1) The item like rule-ipv6-prefix is not needed at all. >> 2) Port set or PSID still needs extra provisioning (while in regular >> MAP it's embedded in IPv6 address) >> So why make it so difficult and obscure >> >> >> Not difficult, easy business for CE which implemented MAP. Other >> difficulty in operator side in particular provisioning complex, that should >> be same with LW46. It also makes to complete MAP spec in the ea-len zero >> case. >> >> [IF] Additional complexity in the operator side is where I see the >> problem with MAP in our case. The strength that MAP offers is for the mesh >> model and the complexity that it brings is a neat way of achieving this. >> But if hub-and-spoke is the only deployment scenario that you need, then >> the complexity for mesh is an unnecessary addition that results in >> operational complexity, which is something we're trying to engineer out >> wherever we can. >> E.g. In the case above, for a shared IP address, the source port range is >> encoded in the port-param option. To troubleshoot user connectivity, ops >> need to have a good understanding of how this is being calculated so that >> they can trace the user. Not the end of the world, but with millions of >> customers and a hundred support staff, it's just better avoided if >> possible. This logic also then needs to be built into other business >> support systems that rely on the customers IP/port range as an identifier. >> LW46 solves this with a simple (though long) lookup table. This does mean >> that it's very easy to extract how a user is configured or identified with >> a minimum of additional knowledge and calculating tools. >> > > Well, a couple of observations: > A) MAP allows you to optimize complexity in not having to deal with per > subscriber rules in cases where this is feasible. > > But this re-introduces v4 and v6 addressing dependency which we're trying > to avoid. > > B) You're referring to data representation as an operational problem, > which if so, actually applies to any solution incl LW46 that transmits > port-range info to a client. I.e. "Whatever support staff" needs to be > schooled to use some logic to glean useful port information from the data > sent to a client > > "Don't worry about unnecessary complexity, we'll just do more training!" > isn't a very powerful argument in our business. > Woj> You appear to forget that your support staff using L46 needs to be trained. There is no difference in the amount of training > > C) It is very easy to represent MAP data as port range info on routers, > tools, etc. > > On routers, I'm sure that it is. However, the fact that you need a tool to > work out the mapping again points to complexity. On internally developed > and 3rd party BSS systems then it's more work that offers no benefit. > Woj> Tool = packet sniffer, whatever. I'll assert that you cannot decode L46 options without specialised tooling. Cheers, Woj. > > -Woj. > > >> >> cheers, >> --satoru >> >> ------------------------------ >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --20cf306681574c215604c3705aeb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ian,

On 27 June 2012 10:39, <ian.fa= rrer@telekom.de> wrote:
Hi Woj,
=A0
Comments=A0in line.
=A0
Cheers,
Ian



On 26 June 2012 09:13, <ian.farrer@telekom.de> wrote:
Hi Satoru,
Comment in line=20 below.
Best regards,
Ian
Date: Mon, 25 Jun 20= 12=20 18:46:18 +0900
From: Satoru Matsush= ima=20 <sato= ru.matsushima@gmail.com>
Subject: Re: [Softwi= res]=20 [Softwire] draft-ietf-softwire-map-00 does
NOTreflect=20 the consensus from the WG
Content-Type:=20 text/plain; charset=3Diso-8859-1
Hi Peng,
On 2012/06/25, at 18= :34,=20 Peng Wu wrote:
Let's think that a CE provisioned with following BMR comes f= rom MAP=20 DHCPv6 options.
BMR:
=A0=A0o Rule-ipv6-prefix=A0=A0: {exact matched with CE's=20 delegated prefix}
=A0=A0o Rule-ipv4-prefix=A0=A0: x.x.x.x/32
=A0=A0o=20 EA-length=A0=A0=A0=A0=A0=A0=A0=A0 : 0
=A0=A0o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
Again, all the information needed is the IPv4 address and port=20 set.
1) The item like rule-ipv6-prefix is not needed at all.
2) Port set or PSID still needs extra provisioning (while in=20 regular
MAP it's embedded in IPv6 address)
So why make it so difficult and obscure
Not difficult, easy= =20 business for CE which implemented MAP. Other difficulty in operator side = in=20 particular provisioning complex, that should be same with LW46. It also m= akes=20 to complete MAP spec in the ea-len zero case.
[IF] Additional=20 complexity in the operator side is where I see the problem with MAP in ou= r=20 case. The strength that MAP offers is for the mesh model and the complexi= ty=20 that it brings is a neat way of achieving this. But if hub-and-spoke is t= he=20 only deployment scenario that you need, then the complexity for mesh is a= n=20 unnecessary addition that results in operational complexity, which is=20 something we're trying to engineer out wherever we can.
E.g. In the case abo= ve,=20 for a shared IP address, the source port range is encoded in the port-par= am=20 option. To troubleshoot user connectivity, ops need to have a good=20 understanding of how this is being calculated so that they can trace the = user.=20 Not the end of the world, but with millions of customers and a hundred su= pport=20 staff, it's just better avoided if possible. This logic also then nee= ds to be=20 built into other business support systems that rely on the customers IP/p= ort=20 range as an identifier.
LW46 solves this wit= h a=20 simple (though long) lookup table. This does mean that it's very easy= to=20 extract how a user is configured or identified with a minimum of addition= al=20 knowledge and calculating tools.

Well, a couple of observations:
A) MAP allows = you to=20 optimize complexity in not having to deal with per subscriber rules in case= s=20 where this is feasible.=A0=A0<= /font>
=A0
But=20 this re-introduces v4=A0and v6 addressing dependency which we're trying= to=20 avoid.
=A0
B) You're referring to data=20 representation as an operational problem, which if so, actually applies to = any=20 solution incl LW46 that transmits port-range info to a client. I.e. "W= hatever=20 support staff" needs to be schooled to use some logic to glean useful = port=20 information from the data sent to a client=A0
=A0
"Don't=20 worry about unnecessary complexity, we'll just do more training!"= =20 isn't=A0a=A0very powerful argument in our=20 business.=A0

Woj> Y= ou appear to forget that your support staff using L46 needs to be trained. = There is no difference in the amount of training=A0
=A0
C) It is very easy to=20 represent MAP data as port range info on routers, tools, etc.
=A0
On=20 routers, I'm sure that it is. However, the fact that you need a tool to= work out=20 the mapping again points to complexity. On internally developed and 3rd par= ty=20 BSS systems then it's more work that offers no benefit.

Woj> Tool =3D packet sniffer, what= ever. I'll assert that you cannot decode L46 options without specialise= d tooling.

Cheers,
Woj.
=A0
-Woj.
=A0

cheers,
--satoru

--------------------= ----------



_______________________________________________
Softwi= res=20 mailing list
S= oftwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires=



--20cf306681574c215604c3705aeb-- From satoru.matsushima@gmail.com Wed Jun 27 01:57:25 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 CA5CE21F85CF for ; Wed, 27 Jun 2012 01:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNSlcgyU4y7J for ; Wed, 27 Jun 2012 01:57:25 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5F7821F855F for ; Wed, 27 Jun 2012 01:57:24 -0700 (PDT) Received: by dacx6 with SMTP id x6so1118299dac.31 for ; Wed, 27 Jun 2012 01:57:23 -0700 (PDT) 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=HqkG5X5Zc3kyRzISXcTp9qd8l6PeXiwRT/5RLcIrMmU=; b=F8Os8Lqn1/qyJdgNmdP6xOQ81Ge7qpPlsJZYK7Ny/iuLxTSRUn1K9ewB/XylUoh9rJ 0fATmWqKSCJg1nIPEn1xh1hDCDlShqX9jHbu7/CR3+prDWodEuWzOJEYMyHiabhIwB8p 8S5BpMT3bTgjcJrYoTBiM/Lqv0p+7pi45emD4chMN+ACtslHx+sFv0KHIFVyMGMgvUfy GADbd7qYvoOkCMueV011QN/oHJw9Qfo7dCZVXd4rzcH7jr1+m7nuAKo8Rq90rH4C4cQG 2F5YveOJ1d5RIw+wvVhg6Egd3wy4O08VwE21RJo664DAiK6oSFL09bePY4L5aPXwkKC5 E0LQ== Received: by 10.68.236.102 with SMTP id ut6mr60859468pbc.113.1340787440810; Wed, 27 Jun 2012 01:57:20 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id oo6sm14577449pbc.22.2012.06.27.01.57.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 01:57:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 17:57:15 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7683A644-D86E-4A33-9234-AF742F4CC5AE@gmail.com> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1278) Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 27 Jun 2012 08:57:26 -0000 Hi Maoke, Woj, Two points. On 2012/06/27, at 17:43, Wojciech Dec wrote: > Question #7: this text is contradictory with Section 7.1. is the DHCP = option a sort of "other means" or not, or there's something out of scope = of this draft?=20 >=20 > Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing = in the architecture prevents any other provisioning mechanisms to be = used incl dhcpv4, snmp, etc. In addition, any provisioning protocol could be used in MAP. But using = these protocol in LW46 basis, DHCPv4-over-IPv6 and PCP in particular, = absolutely out of scope for MAP. >=20 > Question #8: what is the consequence of disabling the NAT44 = functionality on CE when a subscriber having a PSID of a share IPv4 = address is running behind that CE as a 1:1 mode domain?=20 >=20 > Woj> That is not possible. We can be clearer in saying that if the = CPE has no IPv4 address configured then NAT44 is to be disabled (kind of = obvious) Described text for '1:1 mode' in current version would make some people = confused. We need to make clear for that. cheers, --satoru= From xiechf01@gmail.com Wed Jun 27 02:18: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 95B0121F865E for ; Wed, 27 Jun 2012 02:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[AWL=-4.592, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM75Grj6GgdB for ; Wed, 27 Jun 2012 02:18:11 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B38B21F85FB for ; Wed, 27 Jun 2012 02:18:11 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1334885pbc.31 for ; Wed, 27 Jun 2012 02:18:11 -0700 (PDT) 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-has-attach :x-mailer:mime-version:message-id:content-type; bh=MfKwf4KH89DLE5rfQt0/z6wPTc2e8hU/YxU1r0ruPPg=; b=J9P8VYm6Q4vCA68qufIOELbxReciMhW+fMxV/r5eN8z+Suc5xqQKXYTF13ewaPI3bH XgNtUL/J1Xsb7jQwUHg6QGfbcJbW/ScJNZmaS8Fh84AqEi/5AScSIDd/lPsSOBc2IC2z /tfE2Tjb5Mit/byynj+2FWPfO4oY3yaMLCGUtWLI1Cn9aGqvdtHPEHuT8+EfjQeQEXf1 4+l5LjUmq/uBhlJK9XSxvnslBHOV4SF1NVcZVp+QAYJ8GsKF2ypgs1TI8nzzvZy0l4oh QoGmmMkoVXlPCb3IhHIuxWLLrhZyUqnedRrqy2i4+zIy4KxEzu/T/SgXZUXMNE32wrUt Xx9A== Received: by 10.68.191.72 with SMTP id gw8mr61893006pbc.143.1340788690796; Wed, 27 Jun 2012 02:18:10 -0700 (PDT) Received: from xiechf-PC ([219.142.69.76]) by mx.google.com with ESMTPS id os1sm14615088pbb.49.2012.06.27.02.18.02 (version=SSLv3 cipher=OTHER); Wed, 27 Jun 2012 02:18:09 -0700 (PDT) Date: Wed, 27 Jun 2012 17:17:57 +0800 From: xiechf01 To: "ian.farrer@telekom.de" , "wdec.ietf@gmail.com" References: , <8A1B81989BCFAE44A22B2B86BF2B76318918594767@HE111643.EMEA1.CDS.T-INTERNAL.COM> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <2012062717174839466911@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart500160022201_=----" Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiechf01 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 09:18:12 -0000 This is a multi-part message in MIME format. ------=_001_NextPart500160022201_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCldlIGFkbWl0IHRoZSBhbGdvcml0aG1pYyBtYXBwaW5nIGlzIHRlY2huaWNhbGx5IGFuZCB0 aGVvcmV0aWNhbGx5ICJiZWF1dGlmdWwiLCBtdWx0aXBsZSBtYXBwaW5nIG1ldGhvZHMgYW5kIGZv cndhcmRpbmcgbW9kZXMgaGF2ZSBiZWVuIGRlc2lnbmVkLiANClRoZSBlc3NlbmNlIG9mIHRoaXMg bWFwcGluZyBpcyB0aGF0IHRoZSBmb3JtYXQgb2YgSVB2NiBwYWNrZXQgZGVwZW5kcyBvbiBJUHY0 IGFkZHJlc3MgYW5kIHBvcnQgaW5mb3JtYXRpb24sIHdpdGggYW4gYWxnb3JpdGhtaWMgcHJlLWRl dGVybWluZWQgIHJlbGF0aW9uc2hpcCBpbiBpdC4gSG93ZXZlciwgd2hlbiBkZWNpZGluZyB3aGV0 aGVyIHRvIGFkb3B0IGl0IGluIHRoZSBmdXR1cmUsdGhlIGZvbGxvd2luZyBhc3BlY3RzIHNob3Vs ZCBiZSBjb25zaWRlcmVkIGZpcnN0Lg0KDQoxKSBXaXRoIGFsZ29yaXRobWljIG1hcHBpbmcgbWV0 aG9kLCBzb21lIG9mIGJpdHMgaW4gSVB2NiBwcmVmaXggd2lsbCBiZSB1dGlsaXplZCBieSBJUHY0 IGFkZHJlc3Mob3IgcGFydCBvZiBJUHY0IGFkZHJlc3MpLCAgIHdoaWNoIG1lYW5zIHRoYXQgdGhl c2UgIGJpdHMgDQpjYW4gbm90IGJlIHVzZWQgZm9yIG90aGVyIHB1cnBvc2UuIFNpbmNlIHRoZSBu dW1iZXIgb2YgYml0cyBvZiBJUHY2IHByZWZpeCBhbGxvY2F0ZWQgdG8gYSBnaXZlbiBJU1AgaXMg bGltaXRlZCwgZXZlcnkgYml0IHNob3VsZCBiZSB0cmVhdGVkIGNhcmVmdWxseS4gDQpXaGVuIElT UCBkZXBsb3lzIElQdjYgaW4gcHJvZHVjdCBuZXR3b3JrLHNvbWUgb3RoZXIgZmVhdHVyZXMgaW5j bHVkaW5nIHNlcnZpY2UgdHlwZSwgUW9TLCBsb2NhdGlvbiwgZXRjLG1heSBhbHNvIGJlIHRha2Vu IGludG8gY29uc2lkZXJhdGlvbiBhbmQgZW1iZWRkZWQNCiBpbiBJUHY2IHByZWZpeCx3aGljaCBt aWdodCBjb25mbGljdCB3aXRoIEVBLWJpdHMuDQoNCjIpIEFsZ29yaXRobWljIG1hcHBpbmcgbmVl ZHMgdGhlIGVuZ2luZWVyaW5nIHN0YWZmIG9mIGxvY2FsIE5PQyB0byB1bmRlcnN0YW5kIGNvbXBs ZXggbWFwcGluZyBhbGdvcml0aG0sIGRpZmZlcmVudCBtYXBwaW5nIG1vZGVzLCBmb3J3YXJkaW5n IG1vZGVzLA0KIGV0Yywgd2hpY2ggbWVhbnMgdGhleSBtdXN0IGJlIHNtYXJ0IGVub3VnaC4gQWRk cmVzcyBwbGFubmluZyBhbmQgYWxsb2NhdGlvbiBpcyBhbiBpbXBvcnRhbnQgam9iIG9mIE5PQywg YW5kIGl0IHJlcXVpcmVzIE5PQyBndXlzIHRvIG1hc3RlciBhbGwgdGhlc2Ugc3R1ZmYgDQp0byBv cGVyYXRlIG5ldHdvcmsgY29ycmVjdGx5LiBCdXQgd2Ugd2lsbCBhc2sgaG9uZXN0bHksIGRvIG91 ciBlZmZvcnQgZGVzZXJ2ZSBzdWNoIGNvbXBsZXhpdHk/DQoNCkZyb20gb3BlcmF0b3JzJyBwZXJz cGVjdGl2ZSwgd2UgaG9wZSB0aGF0IHRoZSBhZGRyZXNzIGZvcm1hdCBzaG91bGQgaGF2ZSBsZXNz IGNvbnN0cmFpbnQgYW5kIG1vcmUgZmxleGliaWxpdHkuIElQdjYgaXMgYm9ybiBmb3IgSVB2Niwg bm90IGZvciBJUHY0LiBXZSBjYW4gaGF2ZSANCm1vcmUgZnJlZWRvbSB0aGUgdXRpbGl6ZSB0aGUg SVB2NiBhZGRyZXNzLCBtb3JlIGZsZXhpYmlsaXR5LCBlYXN5IHVuZGVyc3RhbmRpbmcgYW5kIG1h bmFnZW1lbnQgZmVhdHVyZS4NCg0KWWVzLCBNQVAgY2FuIHByb3ZpZGUgYSBwZXItc3Vic2NyaWJl ciBwZXItcnVsZSBtb2RlIHdoZW4gdGhlIGxlbmd0aCBvZiBFQS1iaXRzIGJlY29tZXMgemVybyBz b21laG93LiBCdXQgdGhpcyBtZWFucyB0aGUgbWFwcGluZyBmZWF0dXJlIGlzIHJlbW92ZWQgaW4g dGhpcyBjYXNlLiBCdXQgdGhlbiB3ZSB3aWxsIGFzaywgaWYgdGhlIG1hcHBpbmcgaXMgYWxyZWFk eSBnb25lLCB3aHkgc2hvdWxkIHdlIA0KYnV5IHNvIG1hbnkgdXNlbGVzcyBmZWF0dXJlcyB0byBk byB0aGlzPyAgIA0KDQqhsFRoZSBzaW1wbGVyLCB0aGUgYmV0dGVyobGjrHRoYXQncyB3aGF0IHdl IHdhbnQuDQoNCkNob25nZmVuZyBAQ2hpbmEgVGVsZWNvbQ0KDQoNCg0KDQoNCg0KRnJvbTogaWFu LmZhcnJlckB0ZWxla29tLmRlDQpEYXRlOiAyMDEyLTA2LTI3IDE2OjM5DQpUbzogd2RlYy5pZXRm QGdtYWlsLmNvbQ0KQ0M6IHNvZnR3aXJlcw0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIFtTb2Z0 d2lyZV0gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgZG9lcyBOT1QgcmVmbGVjdCB0aGUgY29u c2Vuc3VzIGZyb20gdGhlIFdHDQpIaSBXb2osDQoNCkNvbW1lbnRzIGluIGxpbmUuDQoNCkNoZWVy cywNCklhbg0KDQoNCg0KDQpGcm9tOiBXb2pjaWVjaCBEZWMgW21haWx0bzp3ZGVjLmlldGZAZ21h aWwuY29tXSANClNlbnQ6IERpZW5zdGFnLCAyNi4gSnVuaSAyMDEyIDA5OjU1DQpUbzogRmFycmVy LCBJYW4NCkNjOiBzYXRvcnUubWF0c3VzaGltYUBnbWFpbC5jb207IHNvZnR3aXJlc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIFtTb2Z0d2lyZV0gZHJhZnQtaWV0Zi1zb2Z0d2ly ZS1tYXAtMDAgZG9lcyBOT1QgcmVmbGVjdCB0aGUgY29uc2Vuc3VzIGZyb20gdGhlIFdHDQoNCg0K DQoNCg0KT24gMjYgSnVuZSAyMDEyIDA5OjEzLCA8aWFuLmZhcnJlckB0ZWxla29tLmRlPiB3cm90 ZToNCg0KSGkgU2F0b3J1LA0KDQoNCkNvbW1lbnQgaW4gbGluZSBiZWxvdy4NCg0KDQpCZXN0IHJl Z2FyZHMsDQpJYW4NCg0KDQpEYXRlOiBNb24sIDI1IEp1biAyMDEyIDE4OjQ2OjE4ICswOTAwDQpG cm9tOiBTYXRvcnUgTWF0c3VzaGltYSA8c2F0b3J1Lm1hdHN1c2hpbWFAZ21haWwuY29tPg0KVG86 IFBlbmcgV3UgPHBlbmd3dS50aHVAZ21haWwuY29tPg0KQ2M6IHNvZnR3aXJlc0BpZXRmLm9yZywg WW9uZyBDdWkgPGN1aXlvbmdAdHNpbmdodWEuZWR1LmNuPg0KU3ViamVjdDogUmU6IFtTb2Z0d2ly ZXNdIFtTb2Z0d2lyZV0gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtMDAgZG9lcw0KTk9UcmVmbGVj dCB0aGUgY29uc2Vuc3VzIGZyb20gdGhlIFdHDQpNZXNzYWdlLUlEOiA8NTg1MUIyOUItMENDRi00 QjA4LTg2RDUtOENCQkZDRUY1RkE0QGdtYWlsLmNvbT4NCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFp bjsgY2hhcnNldD1pc28tODg1OS0xDQoNCg0KSGkgUGVuZywNCg0KDQpPbiAyMDEyLzA2LzI1LCBh dCAxODozNCwgUGVuZyBXdSB3cm90ZToNCg0KDQpMZXQncyB0aGluayB0aGF0IGEgQ0UgcHJvdmlz aW9uZWQgd2l0aCBmb2xsb3dpbmcgQk1SIGNvbWVzIGZyb20gTUFQIERIQ1B2NiBvcHRpb25zLg0K Qk1SOg0KICBvIFJ1bGUtaXB2Ni1wcmVmaXggIDoge2V4YWN0IG1hdGNoZWQgd2l0aCBDRSdzIGRl bGVnYXRlZCBwcmVmaXh9DQogIG8gUnVsZS1pcHY0LXByZWZpeCAgOiB4LngueC54LzMyDQogIG8g RUEtbGVuZ3RoICAgICAgICAgOiAwDQogIG8gUG9ydC1wYXJhbSBvcHRpb24gOiB7UFNJRC9sZW5n dGh9DQpUaGlzIEJNUiBjb3VsZCBiZSBhIExXNDYgcHJvdmlzaW9uaW5nIG1lYW5zLg0KQWdhaW4s IGFsbCB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIGlzIHRoZSBJUHY0IGFkZHJlc3MgYW5kIHBvcnQg c2V0Lg0KMSkgVGhlIGl0ZW0gbGlrZSBydWxlLWlwdjYtcHJlZml4IGlzIG5vdCBuZWVkZWQgYXQg YWxsLg0KMikgUG9ydCBzZXQgb3IgUFNJRCBzdGlsbCBuZWVkcyBleHRyYSBwcm92aXNpb25pbmcg KHdoaWxlIGluIHJlZ3VsYXINCk1BUCBpdCdzIGVtYmVkZGVkIGluIElQdjYgYWRkcmVzcykNClNv IHdoeSBtYWtlIGl0IHNvIGRpZmZpY3VsdCBhbmQgb2JzY3VyZQ0KDQoNCk5vdCBkaWZmaWN1bHQs IGVhc3kgYnVzaW5lc3MgZm9yIENFIHdoaWNoIGltcGxlbWVudGVkIE1BUC4gT3RoZXIgZGlmZmlj dWx0eSBpbiBvcGVyYXRvciBzaWRlIGluIHBhcnRpY3VsYXIgcHJvdmlzaW9uaW5nIGNvbXBsZXgs IHRoYXQgc2hvdWxkIGJlIHNhbWUgd2l0aCBMVzQ2LiBJdCBhbHNvIG1ha2VzIHRvIGNvbXBsZXRl IE1BUCBzcGVjIGluIHRoZSBlYS1sZW4gemVybyBjYXNlLg0KDQoNCltJRl0gQWRkaXRpb25hbCBj b21wbGV4aXR5IGluIHRoZSBvcGVyYXRvciBzaWRlIGlzIHdoZXJlIEkgc2VlIHRoZSBwcm9ibGVt IHdpdGggTUFQIGluIG91ciBjYXNlLiBUaGUgc3RyZW5ndGggdGhhdCBNQVAgb2ZmZXJzIGlzIGZv ciB0aGUgbWVzaCBtb2RlbCBhbmQgdGhlIGNvbXBsZXhpdHkgdGhhdCBpdCBicmluZ3MgaXMgYSBu ZWF0IHdheSBvZiBhY2hpZXZpbmcgdGhpcy4gQnV0IGlmIGh1Yi1hbmQtc3Bva2UgaXMgdGhlIG9u bHkgZGVwbG95bWVudCBzY2VuYXJpbyB0aGF0IHlvdSBuZWVkLCB0aGVuIHRoZSBjb21wbGV4aXR5 IGZvciBtZXNoIGlzIGFuIHVubmVjZXNzYXJ5IGFkZGl0aW9uIHRoYXQgcmVzdWx0cyBpbiBvcGVy YXRpb25hbCBjb21wbGV4aXR5LCB3aGljaCBpcyBzb21ldGhpbmcgd2UncmUgdHJ5aW5nIHRvIGVu Z2luZWVyIG91dCB3aGVyZXZlciB3ZSBjYW4uDQpFLmcuIEluIHRoZSBjYXNlIGFib3ZlLCBmb3Ig YSBzaGFyZWQgSVAgYWRkcmVzcywgdGhlIHNvdXJjZSBwb3J0IHJhbmdlIGlzIGVuY29kZWQgaW4g dGhlIHBvcnQtcGFyYW0gb3B0aW9uLiBUbyB0cm91Ymxlc2hvb3QgdXNlciBjb25uZWN0aXZpdHks IG9wcyBuZWVkIHRvIGhhdmUgYSBnb29kIHVuZGVyc3RhbmRpbmcgb2YgaG93IHRoaXMgaXMgYmVp bmcgY2FsY3VsYXRlZCBzbyB0aGF0IHRoZXkgY2FuIHRyYWNlIHRoZSB1c2VyLiBOb3QgdGhlIGVu ZCBvZiB0aGUgd29ybGQsIGJ1dCB3aXRoIG1pbGxpb25zIG9mIGN1c3RvbWVycyBhbmQgYSBodW5k cmVkIHN1cHBvcnQgc3RhZmYsIGl0J3MganVzdCBiZXR0ZXIgYXZvaWRlZCBpZiBwb3NzaWJsZS4g VGhpcyBsb2dpYyBhbHNvIHRoZW4gbmVlZHMgdG8gYmUgYnVpbHQgaW50byBvdGhlciBidXNpbmVz cyBzdXBwb3J0IHN5c3RlbXMgdGhhdCByZWx5IG9uIHRoZSBjdXN0b21lcnMgSVAvcG9ydCByYW5n ZSBhcyBhbiBpZGVudGlmaWVyLg0KTFc0NiBzb2x2ZXMgdGhpcyB3aXRoIGEgc2ltcGxlICh0aG91 Z2ggbG9uZykgbG9va3VwIHRhYmxlLiBUaGlzIGRvZXMgbWVhbiB0aGF0IGl0J3MgdmVyeSBlYXN5 IHRvIGV4dHJhY3QgaG93IGEgdXNlciBpcyBjb25maWd1cmVkIG9yIGlkZW50aWZpZWQgd2l0aCBh IG1pbmltdW0gb2YgYWRkaXRpb25hbCBrbm93bGVkZ2UgYW5kIGNhbGN1bGF0aW5nIHRvb2xzLg0K DQpXZWxsLCBhIGNvdXBsZSBvZiBvYnNlcnZhdGlvbnM6DQpBKSBNQVAgYWxsb3dzIHlvdSB0byBv cHRpbWl6ZSBjb21wbGV4aXR5IGluIG5vdCBoYXZpbmcgdG8gZGVhbCB3aXRoIHBlciBzdWJzY3Jp YmVyIHJ1bGVzIGluIGNhc2VzIHdoZXJlIHRoaXMgaXMgZmVhc2libGUuICANCg0KQnV0IHRoaXMg cmUtaW50cm9kdWNlcyB2NCBhbmQgdjYgYWRkcmVzc2luZyBkZXBlbmRlbmN5IHdoaWNoIHdlJ3Jl IHRyeWluZyB0byBhdm9pZC4NCg0KQikgWW91J3JlIHJlZmVycmluZyB0byBkYXRhIHJlcHJlc2Vu dGF0aW9uIGFzIGFuIG9wZXJhdGlvbmFsIHByb2JsZW0sIHdoaWNoIGlmIHNvLCBhY3R1YWxseSBh cHBsaWVzIHRvIGFueSBzb2x1dGlvbiBpbmNsIExXNDYgdGhhdCB0cmFuc21pdHMgcG9ydC1yYW5n ZSBpbmZvIHRvIGEgY2xpZW50LiBJLmUuICJXaGF0ZXZlciBzdXBwb3J0IHN0YWZmIiBuZWVkcyB0 byBiZSBzY2hvb2xlZCB0byB1c2Ugc29tZSBsb2dpYyB0byBnbGVhbiB1c2VmdWwgcG9ydCBpbmZv cm1hdGlvbiBmcm9tIHRoZSBkYXRhIHNlbnQgdG8gYSBjbGllbnQgDQoNCiJEb24ndCB3b3JyeSBh Ym91dCB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5LCB3ZSdsbCBqdXN0IGRvIG1vcmUgdHJhaW5pbmch IiBpc24ndCBhIHZlcnkgcG93ZXJmdWwgYXJndW1lbnQgaW4gb3VyIGJ1c2luZXNzLiANCg0KQykg SXQgaXMgdmVyeSBlYXN5IHRvIHJlcHJlc2VudCBNQVAgZGF0YSBhcyBwb3J0IHJhbmdlIGluZm8g b24gcm91dGVycywgdG9vbHMsIGV0Yy4NCiANCk9uIHJvdXRlcnMsIEknbSBzdXJlIHRoYXQgaXQg aXMuIEhvd2V2ZXIsIHRoZSBmYWN0IHRoYXQgeW91IG5lZWQgYSB0b29sIHRvIHdvcmsgb3V0IHRo ZSBtYXBwaW5nIGFnYWluIHBvaW50cyB0byBjb21wbGV4aXR5LiBPbiBpbnRlcm5hbGx5IGRldmVs b3BlZCBhbmQgM3JkIHBhcnR5IEJTUyBzeXN0ZW1zIHRoZW4gaXQncyBtb3JlIHdvcmsgdGhhdCBv ZmZlcnMgbm8gYmVuZWZpdC4NCg0KLVdvai4NCiANCg0KDQpjaGVlcnMsDQotLXNhdG9ydQ0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0 DQpTb2Z0d2lyZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc29mdHdpcmVz ------=_001_NextPart500160022201_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
We admit the algorithmic mapping is tec= hnically and theoretically "beautiful", multiple = mapping methods and forwarding modes have be= en designed. 
The essence of this mapping is that&nbs= p;the format of IPv6 packet depends on = IPv4 address and port information, with an&n= bsp;algorithmic pre-determined =20 relationship in it. However, when deciding w= hether to adopt it in the future,the fo= llowing aspects should be considered first.
 
1) With algorithmic mapping method, some&nbs= p;of bits in IPv6 prefix will be utiliz= ed by IPv4 address(or part of IPv4 addr= ess),  =20 which means that these  bits 
can not be used for other purpose. = ;Since the number of bits of IPv6 prefi= x allocated to a given ISP is limited,&= nbsp;every bit should be treated carefully. =
When ISP deploys IPv6 in product networ= k,some other features including service type,=20 QoS,=20 location, etc,may also be taken into conside= ration and embedded
 in IPv6 prefix,which might conflict wi= th EA-bits.
 
2) Algorithmic mapping needs the engineering=  staff of local NOC to understand compl= ex mapping algorithm, different mapping modes,&nb= sp;forwarding modes,
 etc, which means they must be sma= rt enough. Address planning and allocation i= s an important job of NOC, and it = requires NOC guys to master all these s= tuff 
to operate network correctly. But we wi= ll ask honestly, do our effort deserve = such complexity?
 
From operators' perspective, we hope that&nb= sp;the address format should have less const= raint and more flexibility. IPv6 is born&nbs= p;for IPv6, not for IPv4. We can have&n= bsp;
more freedom the utilize the IPv6 addre= ss, more flexibility, easy understanding and = ;management feature.
 
Yes, MAP can provide a per-subscriber p= er-rule mode when the length of EA-bits = ;becomes zero somehow. But this means the&nb= sp;mapping feature is removed in this case.&= nbsp;But then we will ask, if the mappi= ng is already gone, why should we 
buy so many useless features to do = ;this?   
 
=A1=B0The simpler, the better=A1=B1=A3=ACthat's w= hat we want.
 
=
 
 
 
From: ian.farrer@telekom.de
Date: 2012-06-27 16:39
To: wdec.ietf@gmail.com
CC: softwires
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOT reflect the consensus from the WG
Hi Woj,
 
Comments in line.
 
Cheers,
Ian

From: Wojciech Dec [mailto:wdec.ietf@g= mail.com]=20
Sent: Dienstag, 26. Juni 2012 09:55
To: Farrer,=20 Ian
Cc: satoru.matsushima@gmail.com;=20 softwires@ietf.org
Subject: Re: [Softwires] [Softwire]=20 draft-ietf-softwire-map-00 does NOT reflect the consensus from the=20 WG



On 26 June 2012 09:13, <ian.farrer@telekom.de> wrote:
Hi Satoru,

Comment in line=20 below.

Best regards,
Ian

Date: Mon, 25 Ju= n 2012=20 18:46:18 +0900
From: Satoru Mat= sushima=20 <satoru.matsushima@gmail.com>
To: Peng Wu <= pengwu.thu@gmail.com>
Cc: softwires@ietf.org, Yong=20 Cui <cuiyong@tsinghua.edu.cn>
Subject: Re: [So= ftwires]=20 [Softwire] draft-ietf-softwire-map-00 does
NOTreflect=20 the consensus from the WG
Message-ID: <= 5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com>
Content-Type:=20 text/plain; charset=3Diso-8859-1

Hi Peng,

On 2012/06/25, a= t 18:34,=20 Peng Wu wrote:

Let's think that a CE provisioned with following BMR comes from= MAP=20 DHCPv6 options.
BMR:
  o Rule-ipv6-prefix  : {exact matched with= CE's=20 delegated prefix}
  o Rule-ipv4-prefix  : x.x.x.x/32
  o=20 EA-length         : 0
  o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
Again, all the information needed is the IPv4 address and port=20 set.
1) The item like rule-ipv6-prefix is not needed at all.
2) Port set or PSID still needs extra provisioning (while in=20 regular
MAP it's embedded in IPv6 address)
So why make it so difficult and obscure

Not difficult, e= asy=20 business for CE which implemented MAP. Other difficulty in operator side= in=20 particular provisioning complex, that should be same with LW46. It also = makes=20 to complete MAP spec in the ea-len zero case.

[IF] Additional=20 complexity in the operator side is where I see the problem with MAP in o= ur=20 case. The strength that MAP offers is for the mesh model and the complex= ity=20 that it brings is a neat way of achieving this. But if hub-and-spoke is = the=20 only deployment scenario that you need, then the complexity for mesh is = an=20 unnecessary addition that results in operational complexity, which is=20 something we're trying to engineer out wherever we can.
E.g. In the case= above,=20 for a shared IP address, the source port range is encoded in the port-pa= ram=20 option. To troubleshoot user connectivity, ops need to have a good=20 understanding of how this is being calculated so that they can trace the= user.=20 Not the end of the world, but with millions of customers and a hundred s= upport=20 staff, it's just better avoided if possible. This logic also then needs = to be=20 built into other business support systems that rely on the customers IP/= port=20 range as an identifier.
LW46 solves this= with a=20 simple (though long) lookup table. This does mean that it's very easy to= =20 extract how a user is configured or identified with a minimum of additio= nal=20 knowledge and calculating tools.

Well, a couple of observations:
A) MAP allows y= ou to=20 optimize complexity in not having to deal with per subscriber rules in cas= es=20 where this is feasible.  
 
But=20 this re-introduces v4 and v6 addressing dependency which we're trying= to=20 avoid.

B) You're referring to da= ta=20 representation as an operational problem, which if so, actually applies to= any=20 solution incl LW46 that transmits port-range info to a client. I.e. "Whate= ver=20 support staff" needs to be schooled to use some logic to glean useful port= =20 information from the data sent to a client 
 
"Don't=20 worry about unnecessary complexity, we'll just do more training!"=20 isn't a very powerful argument in our=20 business. 

C) It is very easy to rep= resent=20 MAP data as port range info on routers, tools, etc.
 
On=20 routers, I'm sure that it is. However, the fact that you need a tool to wo= rk out=20 the mapping again points to complexity. On internally developed and 3rd pa= rty=20 BSS systems then it's more work that offers no benefit.

-Woj.
 

cheers,
--satoru

---------------------= ---------



_______________________________________________
Softwi= res=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
<= BR>

------=_001_NextPart500160022201_=------ From sunqi.csnet.thu@gmail.com Wed Jun 27 02:20: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 8A40F21F8661 for ; Wed, 27 Jun 2012 02:20:27 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApFNIIeJH3vz for ; Wed, 27 Jun 2012 02:20:26 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A504B21F8663 for ; Wed, 27 Jun 2012 02:20:26 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1337561pbc.31 for ; Wed, 27 Jun 2012 02:20:26 -0700 (PDT) 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=C/E8BZkNbTfoq7X1l0YPEP8UMhGXjm/9lRj3eYg2oz0=; b=s1SfLIVFeciSGN3AmbadLiv8pIY55IsqUCVrZVEVludgmCyixDFVLzSdV2XsD17Bkq 2zY/SzqHsFSo5O5SjIHCJrmYQ0mFrZXyKoSQueVa4SST3J1gj7LIt+Wamj8hi41Bx8yS o/EHyz5WoTQaqGZRTd3+DoP+ngOMouUGBOUWPG/+C9xRjZcE2VvEkay4FSqC/mr1S5MD 2tmKYNlTV+IG3ut8s77qfnHGZ601mLXWhBlStvovCFQrpBfyNTgGlMtqw/CHAIfUKz54 LPr+baOwnHvmmGBfqFk7SiU3jUU9BynIsny5sz4P0UYhwmtPQualyNl4Bx/nrh1zzC3f /0mg== MIME-Version: 1.0 Received: by 10.68.225.201 with SMTP id rm9mr62027978pbc.71.1340788826370; Wed, 27 Jun 2012 02:20:26 -0700 (PDT) Received: by 10.143.7.3 with HTTP; Wed, 27 Jun 2012 02:20:26 -0700 (PDT) In-Reply-To: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> Date: Wed, 27 Jun 2012 17:20:26 +0800 Message-ID: From: Qi Sun To: Satoru Matsushima Content-Type: multipart/alternative; boundary=047d7b2ede33b6f09804c370b936 Cc: Softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 09:20:27 -0000 --047d7b2ede33b6f09804c370b936 Content-Type: text/plain; charset=ISO-8859-1 Hi Satoru, Please see inline. BTW, my name is Qi :) Qi Sun On Wed, Jun 27, 2012 at 4:37 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hi Qiong, > > On 2012/06/27, at 16:54, Qi Sun wrote: > > > Hi Satoru, > > > > Please see inline. > > > > Qi Sun > > > > On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima < > satoru.matsushima@gmail.com> wrote: > > > > On 2012/06/27, at 15:38, Peng Wu wrote: > > > > >> Oh, you don't argue that OSPF covers an use case which is also > covered by RIP. So then why are you arguing that an use case of MAP is > eventually same with the LW46 use case? > > > I'm clearly saying they have different use cases, but that's not the > > > point. Let me repeat. If I want RIP, you cannot just place RIP into > > > OSPF, > > > > Agree on that it's not what I'm intended to. MAP thus never put DHCPv4 > over IPv6, nor PCP into its specification. Please keep your mind in peace. > > > > [Qi] That's not what the thread is discussing. Please do not try to > change the topic. > > > > Not intended. > > > > put an OSPF "face" on it, and force me to use the OSPF "suite" > > > while the essence of the protocol I'm using is still RIP. > > > > Not to force, MAP uses its MAP protocol to an use case which also could > be covered by LW46's DHCPv4 over IPv6, or PCP. Correct? > > > > [Qi] Do you mean MAP can do all these things WITHOUT ANY help from other > documents, saying DHCPv6 options? > > Ah, ok. MAP define mapping rule as its protocol. DHCPv6 is a bearer of > mapping rules. > [Qi] What we are discussing is on the essence of MAP where 1:1 mode is intended to import binding table on BR , and on whether the ietf-map-00 is qualified as a WG draft without consensus of the softwire WG. Rather than the provisioning methods, saying DHCPv4 over IPv6 or DHCPv6 options. > > > All those mechanisms like DHCPv4 over IPv6 or PCP are not the essence > of the protocol but provisioning method for LW4over6. > > Actually, based on what you have said, I can get that the "new" MAP can > achieve its NEW added 1:1 mode with the help of DHCPv4 over IPv6 for IPv4 > address allocation. Why don't you use it, which has been a DHC WG draft? > > > > These are not possible because they require state in BR so that it's LW46 > use case, right? MAP define mapping rule in stateless manner. > [Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any state in TC/BR. Please check the draft. As a result, this is not about stateful or stateless. There is no conflict between the binding table on BR and the DHCPv4 over IPv6 process. > cheers, > --satoru --047d7b2ede33b6f09804c370b936 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Satoru,

Please see inline.

B= TW, my name is Qi :)

Qi Sun


On Wed, Jun 27, 2012 at 4:37 PM, Satoru Matsushima <= span dir=3D"ltr"><satoru.matsushima@gmail.com> wrote:
Hi Qiong,

On 2012/06/27, at 16:54, Qi Sun wrote:

> Hi Satoru,
>
> Please see inline.
>
> Qi Sun
>
> On Wed, Jun 27, 2012 at 2:57 PM, Satoru Matsushima <satoru.matsushima@gmail.com> wrote:<= br> >
> On 2012/06/27, at 15:38, Peng Wu wrote:
>
> >> Oh, you don't argue that OSPF covers an use case which is= also covered by RIP. So then why are you arguing that an use case of MAP i= s eventually same with the LW46 use case?
> > I'm clearly saying they have different use cases, but that= 9;s not the
> > point. Let me repeat. If I want RIP, you cannot just place RIP in= to
> > OSPF,
>
> Agree on that it's not what I'm intended to. MAP thus never pu= t DHCPv4 over IPv6, nor PCP into its specification. Please keep your mind i= n peace.
>
> [Qi] That's not what the thread is discussing. Please do not try t= o change the topic.
>

Not intended.

> > put an OSPF "face" on it, and force me to use the OSPF = "suite"
> > while the essence of the protocol I'm using is still RIP.
>
> Not to force, MAP uses its MAP protocol to an use case which also coul= d be covered by LW46's DHCPv4 over IPv6, or PCP. Correct?
>
> [Qi] Do you mean MAP can do all these things WITHOUT ANY help from oth= er documents, saying DHCPv6 options?

Ah, ok. MAP define mapping rule as its protocol. DHCPv6 is a bearer o= f mapping rules.

[Qi] =A0What we are di= scussing is on the essence of MAP where 1:1 mode is intended to import bind= ing table on BR , and on whether the ietf-map-00 is qualified as a WG draft= without consensus of the softwire WG. Rather than the provisioning methods= , saying DHCPv4 over IPv6 or DHCPv6 options.

> =A0All those mechanisms like DHCPv4 over IPv6 or PCP are not the essen= ce of the protocol but provisioning method for LW4over6.
> Actually, based on what you have said, I can get that the "new&qu= ot; MAP can achieve its NEW added 1:1 mode with the help of DHCPv4 over IPv= 6 for IPv4 address allocation. Why don't you use it, which has been a D= HC WG draft?
>

These are not possible because they require state in BR so that it= 9;s LW46 use case, right? MAP define mapping rule in stateless manner.
<= /blockquote>

[Qi] As a provisioning method, DHCPv4 over = IPv6 DOES NOT require any state in TC/BR. Please check the draft. As a resu= lt, this is not about stateful or stateless. There is no conflict between t= he binding table on BR and the DHCPv4 over IPv6 process.


cheers,
--satoru

--047d7b2ede33b6f09804c370b936-- From Tetsuya.Murakami@ipinfusion.com Wed Jun 27 02:31: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 079E721F85D6 for ; Wed, 27 Jun 2012 02:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWqce1wps-4y for ; Wed, 27 Jun 2012 02:31:16 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1AD21F8595 for ; Wed, 27 Jun 2012 02:31:16 -0700 (PDT) Received: from mail194-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 09:29:32 +0000 Received: from mail194-tx2 (localhost [127.0.0.1]) by mail194-tx2-R.bigfish.com (Postfix) with ESMTP id 73D033A00A5; Wed, 27 Jun 2012 09:29:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I1432I4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25he5bhf0ah) Received-SPF: pass (mail194-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=CH1PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail194-tx2 (localhost.localdomain [127.0.0.1]) by mail194-tx2 (MessageSwitch) id 134078937140681_6387; Wed, 27 Jun 2012 09:29:31 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.254]) by mail194-tx2.bigfish.com (Postfix) with ESMTP id 06682380042; Wed, 27 Jun 2012 09:29:31 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 09:29:30 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.7.238]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0164.004; Wed, 27 Jun 2012 09:31:12 +0000 From: Tetsuya Murakami To: Peng Wu Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNVEeWmsbkzo+12UO1r4MkwjoWYA== Date: Wed, 27 Jun 2012 09:31:12 +0000 Message-ID: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> 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: <76789D3666C9E34F96F39553C80283D0@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: "" , "" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 09:31:17 -0000 Hi Peng, I think it is just example.=20 In case of this example, I think the standard of OSPF can't allow to use it= for only inter-area routing. This standard can also allow to use it within= only area 0. I think sometimes multiple solutions could be applied to solv= e the same problem. In case of this example, either OSPF or RIP could be ap= plied. BTW, based on MAP draft, I think MAP can always keep the stateless mapping = between ipv4 prefix, ipv4 address or a shared ipv4 address and an ipv6 addr= ess. It does not depend on the length of ea-bit. Even though ea-bit length = is zero, rule ipv6 prefix is totally matched to the delegated prefix to CE = and also ipv4 address based on rule ipv4 prefix can be associated with the = ipv6 address based on the mapping rule. For this, I think MAP can keep the = mapping functionality between ipv4 and ipv6 even though ea-bit length is ze= ro. Thanks, Tetsuya On 2012/06/26, at 20:36, Peng Wu wrote: > On Wed, Jun 27, 2012 at 10:20 AM, Satoru Matsushima > wrote: >> Hi Maoke, >>=20 >> On 2012/06/27, at 10:48, Maoke wrote: >>=20 >>> dear Satoru, >>>=20 >>> 2012/6/26 Satoru Matsushima >>> On 2012/06/27, at 0:11, Qiong wrote: >>>=20 >>>> Agree with Ian. >>>>=20 >>>> MAP is designed and optimized for algorithmatic address mapping, but n= ot for per-subscriber rule mapping. Actually, the more you would like to so= lve, more complicated it will become. >>>>=20 >>>> I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E= , map-dhcp all becomes useless or not optimized. And I will not deploy per-= subscriber stateful and stateless solutions at the same. >>>>=20 >>>> So I encourage two seperated approaches optimized for different scenar= ios. It will be good for both. >>>>=20 >>>> Do we really all forget about the "KISS" principle ? >>>=20 >>> Not quite. >>> I believe that the most motivate to start this work in the wg has desti= ned MAP to be 'multi-protocol socket v2.0' that's what the former wg chair = wished to. Do you remember that? >>>=20 >>> i like the philosophy of "multi-protocol socket". however, i moderately= doubt the "multi-protocol socket v2.0" is a perfect plan for every cases. = in a quite good hotel, we see typically one 'multi-protocol socket' while a= lot of local-standard sockets. i never think it will make me happy if i se= e every socket in my room is *multi-protocol*, occupying much spaces and qu= ite noticeable on the walls. we need one to deploy somewhere not the only o= ne type to deploy anywhere. ;-) >>=20 >> That point would be an operational matter for deploying any standardized= technology. For example, an operator adopt OSPF to use its rich routing fe= ature but the network is small, the operator does just area 0 routing, even= OSPF allow inter-area routing for scale. Is an another ospf specification = needed for 'OSPF Area 0 Only Routing'? >=20 > Well if I only have a simple network and I uses RIP, you don't make > OSPF somehow compatible with RIP(or just include RIP with an OSPF > terminology face? I don't know) and say "hey, just use this super > suite, don't consider it overloaded, it's for unity!" >=20 >>=20 >>=20 >>>=20 >>> therefore i understand the motivation of the wg is making a unified sol= ution covering both encapsulation and translation in the framework of state= less, WITHOUT the exclusiveness against other solutions, more specifically = suitable for a certain use case. >>>=20 >>=20 >> Studying each significant use case is quite important. I agree on that p= oint with no doubt. However, is it IETF business for each use case specific= ation? >>=20 >> cheers, >> --satoru >>=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 >=20 From leaf.y.yeh@huawei.com Wed Jun 27 02:31: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 556BC21F8663 for ; Wed, 27 Jun 2012 02:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvLNdqVvbKhQ for ; Wed, 27 Jun 2012 02:31:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AF22521F8661 for ; Wed, 27 Jun 2012 02:31:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHN35801; Wed, 27 Jun 2012 05:31:53 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 02:31:17 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 02:31:20 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 27 Jun 2012 17:31:10 +0800 From: Leaf yeh To: Satoru Matsushima , Wojciech Dec Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNVBUBIzAEAIGKNkCWo9DZKkEJyJcNU5CAgAAD24CAAImf0A== Date: Wed, 27 Jun 2012 09:31:09 +0000 Message-ID: References: <7683A644-D86E-4A33-9234-AF742F4CC5AE@gmail.com> In-Reply-To: <7683A644-D86E-4A33-9234-AF742F4CC5AE@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.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 27 Jun 2012 09:31:54 -0000 Satoru - Described text for '1:1 mode' in current version would make some p= eople confused. We need to make clear for that. I am also not in favor of the concept of '1:1 mode'. A special mode is call= ed here. I guess it doesn't mean length (EA bits in End-User IPv6 prefix) =3D 0. 1:1 might just mean length (Rule IPv4 prefix of BMR) =3D 32,=20 that is a full public IPv4 address is associated with a Rule IPv6 prefix, b= ut this public IPv4 address is definitely for sharing with different PSID. = Right? Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Satoru Matsushima Sent: Wednesday, June 27, 2012 4:57 PM To: Wojciech Dec Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 Hi Maoke, Woj, Two points. On 2012/06/27, at 17:43, Wojciech Dec wrote: > Question #7: this text is contradictory with Section 7.1. is the DHCP opt= ion a sort of "other means" or not, or there's something out of scope of th= is draft?=20 >=20 > Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing in= the architecture prevents any other provisioning mechanisms to be used inc= l dhcpv4, snmp, etc. In addition, any provisioning protocol could be used in MAP. But using thes= e protocol in LW46 basis, DHCPv4-over-IPv6 and PCP in particular, absolutel= y out of scope for MAP. >=20 > Question #8: what is the consequence of disabling the NAT44 functionality= on CE when a subscriber having a PSID of a share IPv4 address is running b= ehind that CE as a 1:1 mode domain?=20 >=20 > Woj> That is not possible. We can be clearer in saying that if the CPE = has no IPv4 address configured then NAT44 is to be disabled (kind of obviou= s) Described text for '1:1 mode' in current version would make some people con= fused. We need to make clear for that. cheers, --satoru _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Wed Jun 27 02:32:26 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 8E63521F85F3 for ; Wed, 27 Jun 2012 02:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1zXpJy4TqHM for ; Wed, 27 Jun 2012 02:32:26 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40A21F85F1 for ; Wed, 27 Jun 2012 02:32:26 -0700 (PDT) Received: by dacx6 with SMTP id x6so1161470dac.31 for ; Wed, 27 Jun 2012 02:32:25 -0700 (PDT) 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=YEwL75tA8Cd8FvBetYQggAgEuz4WmdhcycYdF1xDKRM=; b=BbVyeIbPyEZUtJe08MwY34YwTRg36mF+cNtjcl9t9lwesuRFnOZsIPsCAteWGEway0 uWEB1UVVPizTCFfeFh4GBGOmW3U0tGibKG5xjlU3nz0YVjY6LBC0qIPookt4ANdF77qD FuGNNcbkMpEeN84JHSmbOSs4jNAoh6Gsl4zU2C2+t+/5T9mpx9zng+z3fWDbWL+ONSX4 AjRawiTVbrjp0Y6693dMTS2IxpSc0c04XWfO/fI7Vl1qJpl4VSUuJPn9Vf5BxC3pgUZo JlUdlsUtv/GpGP2b+1zuYVFx1sDVbpz4U7HW2cLD9ot6HO7WAiX679DYylLqhyolGIcD gB4Q== Received: by 10.68.238.68 with SMTP id vi4mr40638626pbc.123.1340789545890; Wed, 27 Jun 2012 02:32:25 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id nh8sm14645730pbc.60.2012.06.27.02.32.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 02:32:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 18:32:19 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1278) Cc: Softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 09:32:26 -0000 On 2012/06/27, at 18:20, Qi Sun wrote: > Hi Satoru, >=20 > Please see inline. >=20 > BTW, my name is Qi :) >=20 Agh! I'm so sorry! >=20 > [Qi] What we are discussing is on the essence of MAP where 1:1 mode = is intended to import binding table on BR , and on whether the = ietf-map-00 is qualified as a WG draft without consensus of the softwire = WG. Rather than the provisioning methods, saying DHCPv4 over IPv6 or = DHCPv6 options. >=20 Ah, ok. > > All those mechanisms like DHCPv4 over IPv6 or PCP are not the = essence of the protocol but provisioning method for LW4over6. > > Actually, based on what you have said, I can get that the "new" MAP = can achieve its NEW added 1:1 mode with the help of DHCPv4 over IPv6 for = IPv4 address allocation. Why don't you use it, which has been a DHC WG = draft? > > >=20 > These are not possible because they require state in BR so that it's = LW46 use case, right? MAP define mapping rule in stateless manner. >=20 > [Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any = state in TC/BR. Please check the draft. As a result, this is not about = stateful or stateless. There is no conflict between the binding table on = BR and the DHCPv4 over IPv6 process. If it is true, LW46 should be a stateless solution. cheers, --satoru= From sunqi.csnet.thu@gmail.com Wed Jun 27 03:02:00 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 066E721F85C7 for ; Wed, 27 Jun 2012 03:02:00 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqsE16Incl0D for ; Wed, 27 Jun 2012 03:01:59 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 640A421F8593 for ; Wed, 27 Jun 2012 03:01:59 -0700 (PDT) Received: by dacx6 with SMTP id x6so1197288dac.31 for ; Wed, 27 Jun 2012 03:01:59 -0700 (PDT) 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=bsSDvqiSlgIvP1wve+aALOwPLn0nuPjgyOCTdgbfuDs=; b=YNLseU4sbuZHFzwiRSecWt0tuDo0eN4YTcvzMMqC4APDwqVIFVIwS4PqKg1iOnRS/s XQr3+O5Kb3xe1tSWfcdAVNnH/TlEWTrkpEfwErJe7S2b4jwmUX3Zw0D00kQDsTVed6EV q9w2RU0reBIPVHGy0pz5PFw0+lWiSd/oUyxE2jDTxIQfie4ModI9UF0+xBTTRSV+OGct 3Evtr56vH6L49mCNwHQIiUn+heFWOFOPFDoTmLqo/6RWs2Asoc6jNWZtZN7CR32t5qlY lEd+SDeGk3PzPlcjzpz+USL8xvb8wzXf2J8TK6+TDx6W8O/DKCel5sl0dy4QBzZ4JF2X v5uA== MIME-Version: 1.0 Received: by 10.68.212.102 with SMTP id nj6mr63329509pbc.15.1340791319113; Wed, 27 Jun 2012 03:01:59 -0700 (PDT) Received: by 10.143.7.3 with HTTP; Wed, 27 Jun 2012 03:01:58 -0700 (PDT) In-Reply-To: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> Date: Wed, 27 Jun 2012 18:01:58 +0800 Message-ID: From: Qi Sun To: Satoru Matsushima Content-Type: multipart/alternative; boundary=e89a8fb2081c4b2f3c04c3714e68 Cc: Softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 10:02:00 -0000 --e89a8fb2081c4b2f3c04c3714e68 Content-Type: text/plain; charset=ISO-8859-1 Hi Satoru, Inline, please ;) Qi Sun On Wed, Jun 27, 2012 at 5:32 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > On 2012/06/27, at 18:20, Qi Sun wrote: > > > Hi Satoru, > > > > Please see inline. > > > > BTW, my name is Qi :) > > > > Agh! I'm so sorry! > > > > > [Qi] What we are discussing is on the essence of MAP where 1:1 mode is > intended to import binding table on BR , and on whether the ietf-map-00 is > qualified as a WG draft without consensus of the softwire WG. Rather than > the provisioning methods, saying DHCPv4 over IPv6 or DHCPv6 options. > > > > Ah, ok. > > > > All those mechanisms like DHCPv4 over IPv6 or PCP are not the essence > of the protocol but provisioning method for LW4over6. > > > Actually, based on what you have said, I can get that the "new" MAP > can achieve its NEW added 1:1 mode with the help of DHCPv4 over IPv6 for > IPv4 address allocation. Why don't you use it, which has been a DHC WG > draft? > > > > > > > These are not possible because they require state in BR so that it's > LW46 use case, right? MAP define mapping rule in stateless manner. > > > > [Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any > state in TC/BR. Please check the draft. As a result, this is not about > stateful or stateless. There is no conflict between the binding table on BR > and the DHCPv4 over IPv6 process. > > If it is true, LW46 should be a stateless solution. > > [Qi] DHCPv4 over IPv6 is a provisioning method. And it's about the public IPv4 address allocation, NOT about IPv4 address and IPv6 address mapping. So there is no state. Please read the draft of DHCPv4 over IPv6 for clarification. LW4over6 needs to maintain the binding table on TC. That's stateful. Actually in MAP 1:1 mode there will be a binding table right? Here comes the question: what will you do if there are new comers or some users leaving the network? > cheers, > --satoru --e89a8fb2081c4b2f3c04c3714e68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Satoru,

Inline, please ;)

Qi= Sun

On Wed, Jun 27, 2012 at 5:32 PM, Sat= oru Matsushima <satoru.matsushima@gmail.com> wrote= :
On 2012/06/27, at 18:20, Q= i Sun wrote:

> Hi Satoru,
>
> Please see inline.
>
> BTW, my name is Qi :)
>

Agh! I'm so sorry!

>
> [Qi] =A0What we are discussing is on the essence of MAP where 1:1 mode= is intended to import binding table on BR , and on whether the ietf-map-00= is qualified as a WG draft without consensus of the softwire WG. Rather th= an the provisioning methods, saying DHCPv4 over IPv6 or DHCPv6 options.
>

Ah, ok.

> > =A0All those mechanisms like DHCPv4 over IPv6 or PCP are not the = essence of the protocol but provisioning method for LW4over6.
> > Actually, based on what you have said, I can get that the "n= ew" MAP can achieve its NEW added 1:1 mode with the help of DHCPv4 ove= r IPv6 for IPv4 address allocation. Why don't you use it, which has bee= n a DHC WG draft?
> >
>
> These are not possible because they require state in BR so that it'= ;s LW46 use case, right? MAP define mapping rule in stateless manner.
>
> [Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any s= tate in TC/BR. Please check the draft. As a result, this is not about state= ful or stateless. There is no conflict between the binding table on BR and = the DHCPv4 over IPv6 process.

If it is true, LW46 should be a stateless solution.

[Qi] DHCPv4 over IPv6 is a provisioning method. And i= t's about the public IPv4 address allocation, NOT about IPv4 address an= d IPv6 address mapping. So there is no state. Please read the draft of DHCP= v4 over IPv6 for clarification.
LW4over6 needs to maintain the binding table on TC. That's statefu= l.
Actually in MAP 1:1 mode there will be a binding table right? = Here comes the question: what will you do if there are new comers or some u= sers leaving the network?


=A0
cheers,
--satoru

--e89a8fb2081c4b2f3c04c3714e68-- From satoru.matsushima@gmail.com Wed Jun 27 03:27:38 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 00FEB21F866B for ; Wed, 27 Jun 2012 03:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+yHYmsEb6rl for ; Wed, 27 Jun 2012 03:27:37 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEFB21F84EA for ; Wed, 27 Jun 2012 03:27:33 -0700 (PDT) Received: by dacx6 with SMTP id x6so1227390dac.31 for ; Wed, 27 Jun 2012 03:27:33 -0700 (PDT) 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=ATxueJQAW0BMdy3EzcwB7UPGI/6FAYKaKH8jUPEB9zs=; b=PIa6qrtQG/3XSe/g2INQCkkG+ZEsMfGwN4F2GsYTOAce93xCfdWNBHZp5wv6nNyo0+ MZt+5mv4qeshiCiFbt9/yaT5nX2FMnQL4IP2Xv24/VNJ95uwUCXloksPebfiw5LS5CTY qdPSwpYcHll0kCjgYiEKKGaz1wq6w4hCq05y1f7wx8yAs77NVO9T2rwvUW00LzGhC/yx 96EaYziI94epfTG4gKYJMmnzjkw42E75Bc6CTf7Ba+YJUnxeJMt59Q+Wle51qthCuVhM In/P3vg8rxlzxvuE20N4nqboVPKW0557RkdjdCWKY+d8f+Z2xcxbl5gRfufDc5+0VEVS EoTQ== Received: by 10.68.223.198 with SMTP id qw6mr42716925pbc.94.1340792853230; Wed, 27 Jun 2012 03:27:33 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id nv6sm14779336pbc.42.2012.06.27.03.27.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 03:27:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 19:27:28 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1278) Cc: Softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 10:27:38 -0000 Qi, On 2012/06/27, at 19:01, Qi Sun wrote: >=20 > [Qi] DHCPv4 over IPv6 is a provisioning method. And it's about the = public IPv4 address allocation, NOT about IPv4 address and IPv6 address = mapping. So there is no state. Please read the draft of DHCPv4 over IPv6 = for clarification. > LW4over6 needs to maintain the binding table on TC. That's stateful. That sense is 'stateless' in my mind if there's no DHCP state in the BR.=20= > Actually in MAP 1:1 mode there will be a binding table right? Here = comes the question: what will you do if there are new comers or some = users leaving the network? it is just an operation in provision. Now I find that LW46 could be = possible to merged with MAP, or vice versa. thanks. cheers, --satoru= From fibrib@gmail.com Wed Jun 27 03:55: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 EEF7A21F8685 for ; Wed, 27 Jun 2012 03:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+Paq3U4MaNq for ; Wed, 27 Jun 2012 03:55:35 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0B21F866B for ; Wed, 27 Jun 2012 03:55:34 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so4158133wib.13 for ; Wed, 27 Jun 2012 03:55:33 -0700 (PDT) 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=gY5vQNNnmWkyLTyjMHzuDXjPFrMPV5grHMBR2DgTIQA=; b=IS/sf0lNK3O5rza5d13USus7BRfXPVSZhOfacicC5sDZ3Cp8rukVjOc8FrJrNvKQhM qjJewUi5EjCUiXVTYlnU+5pu4UhP/omvB0wZHHpChCPuLeB0U5V8URIeGvAxeuU85trQ GRfLj4r2ZTtzVuZlCuk9TSn7sOKqHU3mETiyJLjPGoshX2mWuoaksFh1BmXAU+1c2gEI DeWVPkHLpLGf1LPpQ2VE4FMS38A2ootcsdbmiKYT3B/shz/0sUZSWrvxCdA1TlldAEr9 r906JQgzq/uBEBJKJ7R6uOIZvyFEPbQpH77zsugF/MvbwN7Xgn68XW9wxknNb/VrrmDF LEog== MIME-Version: 1.0 Received: by 10.180.82.42 with SMTP id f10mr3710713wiy.22.1340794533757; Wed, 27 Jun 2012 03:55:33 -0700 (PDT) Received: by 10.216.17.20 with HTTP; Wed, 27 Jun 2012 03:55:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jun 2012 10:55:33 +0000 Message-ID: From: Maoke To: Wojciech Dec Content-Type: multipart/alternative; boundary=f46d04430474e6c38904c3720d6f Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 27 Jun 2012 10:55:37 -0000 --f46d04430474e6c38904c3720d6f Content-Type: text/plain; charset=ISO-8859-1 hi Woj, thanks a lot for the clarification. 2012/6/27 Wojciech Dec > Hi Maoke, > > inline... > > On 27 June 2012 05:28, Maoke wrote: > >> hi dear authors, >> >> as the map-00 draft contains the normative 1:1 mode statement that is new >> in comparison to the previous versions, i'd like to ask some technical >> questions in order to clarify the understanding. >> >> Section 4. page 9: >> >> MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a >> MAP domain per subscriber, and the CE is configured in hub and spoke >> mode, with only a DMR and no other mapping rules. This allows for a >> mode where the BR has one rule per subscriber and the provisioning of >> IPv4 address or prefix and port sets is independent of the End-User >> IPv6 prefix. >> >> Question #1: who is a "subscriber"? the definition is missing. and >> relatedly, what is the protocol for the subscription? the specification on >> the protocol is missing too. >> > > Answer 1: Subscriber = MAP CE. We will clarify the term. > got it. > >> Question #2: what is the relationship between 1:1 mode, encapsulation >> mode, translation mode, hub&spoke mode, mesh mode? are they independent to >> each other, exclusively or not, somehow orthogonal or not? the >> specification on the "mode" is missing. >> > > Answer 2: mode = forwarding mode, also known as transport mode. There are > two of these, translation and encapsulation. No relation between the rest > of the things you mention > okay. then please clearly revise the wording to avoid confusing the readers. only after the terms/wordings are revised, the MAP deployment is able to follow these well-defined words and terms. > > >> Question #3: what is the resource for deployment of a "MAP domain"? the >> MAP spec never define that. however, we kept understanding that the >> resource for a "MAP domain" includes: >> - an IPv4 prefix (with prefix length 32 or less) shared by >> CEs in this domain >> - an IPv6 prefix (with prefix length 64 or less) delegated >> to the CEs in this domain with a /64 (or shorter) per CE (as the basic >> model of prefix d >> the newly introduced "1:1 mode" obviously abandons this >> understanding, then an explicit definition on the resource of a "MAP >> domain" is requested. this is the origin and essential starting point of >> the MAP deployment. >> > > Answer 3: What do you mean by resource for deployment?? It has, and always > has been an IPv6 prefix and an IPv4 address. This is the same in *all* of > this solution space. The split in terms of how one arrives at the IPv4 > address and port-range has always been variable in MAP. > Additional point: There is no newly introduced 1:1 mode, as the spec > hasn't changed. Folks who implemented according to the previous spec, whihc > you seem to indicate had no 1:1 mode see no difference. > as you clarified CE = subscriber, it is ok. but a new question: question #3.1: in the 1:1 mode, how long the PSID is? how long the EA-bits? i understand the bit relationship described in the Figure 7 is the native property of the MAP algorithm. but it looks to me that 1:1 mode has nothing related to this figure. it breaks the relation o = p + q. it is hard to accept that the 1:1 mode is not newly introduced alien. even an alien were welcome, i would like to suggest the authors prepare a text at Figure 7 stating "this is nosense to the 1:1 mode". question #3.2: then about the rule, for ONE rule, i see only, in Section 5: * Rule IPv6 prefix (including prefix length) * Rule IPv4 prefix (including prefix length) * Rule EA-bits length (in bits) * Rule Port Parameters (optional) (as the 5th "forwarding mode" has been confirmed as a domain configuration) i don't see there is a PSID value in this tuple, nor i see it in the example in Sec 5.2, 5.3 for the Given rules. if Section 5 is not applied to the 1:1 mode, an explicit text "This section is nonsense to the 1:1 mode" is required. if a PSID value is to be added into the rule, i understand it is hard to call "not newly introduced" stuff. > Disabling the 1:1 mode would actually require a spec change. > >> Section 5. page 10: >> >> * Forwarding mode >> >> Question #4: this appears twice at the definition of BMR and DMR, >> respectively. though Wojieich and Remi has discussed that in another >> thread, i would like to confirm: is this mode a domain configuration >> parameter or a rule parameter? >> > > Answer 4: Confirmed, intent is for it to be per domain. > >> >> Question #5: does this "forwarding mode" is a enumerate type of {MAP-T, >> MAP-E, 1:1, hub&spoke, mesh} or else, e.g., {MAP-T, MAP-E} x {1:1, N:1} x >> {hub&spoke, mesh}, where the "x" is the operator for de Cartesian product >> of sets? (related to #2) >> > > Answer 5: No need to enumerate, because there is no relation between these > (answered above) > question #5.1: do you mean, for example, when i decided the domain forward mode, e.g. MAP-T, it is fine that i deploy 1:1 for CE.A while N:1 for CE.B, right? please confirm this. > >> Section 7.1 page 19: >> >> In 1:1 mode, the MAP CE is provisioned with only a Default Mapping >> Rule, and the full IPv4 address/prefix and port range is provisioned >> using the DHCP option. >> >> Question #6: is the CE or the subscriber the receiver of the "full IPv4 >> address/prefix and port range" (correction: port set) to be provisioned? or >> does it mean a CE is a subscriber itself in the 1:1 mode? >> > > Woj> MAP CE. > >> >> Section 7.3 page 19: >> >> A MAP-E CE provisioned with only a Default Mapping Rule, as in the >> 1:1 case, and with no IPv4 address and port range configured by other >> means, MUST disable its NAT44 functionality. >> >> Question #7: this text is contradictory with Section 7.1. is the DHCP >> option a sort of "other means" or not, or there's something out of scope of >> this draft? >> > > Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing in > the architecture prevents any other provisioning mechanisms to be used incl > dhcpv4, snmp, etc. > still confusing. Question #7.1: is what the MAP *can* use a part of MAP spec suite, e.g., MAP-DHCP? please clarify explicitly: in the condition of Section 7.1, NAT44 must be disable or not? > >> Question #8: what is the consequence of disabling the NAT44 functionality >> on CE when a subscriber having a PSID of a share IPv4 address is running >> behind that CE as a 1:1 mode domain? >> > > Woj> That is not possible. We can be clearer in saying that if the CPE > has no IPv4 address configured then NAT44 is to be disabled (kind of > obvious) > much more confusing. Question #8.1: please clarify if this CPE has no IPv4 stack enabled or has only no IPv4 address configured (statically or dynamically). how it works? > >> before all of the above questions and further questions possibly to be >> generated during the discussion are fully clarified, i cannot help but >> gently show my disagreement on putting the current draft as working group >> result. i also hope the MAP spec authors kindly understand with so many >> uncertainty modifying MAP deployment draft to fit the MAP spec is a >> mission-impossible for the time being. >> > > Woj> What is the basis of your gentle disagreement, and its timing now? > The merged of the drafts was discussed previously, and circulated on the > design team of which you are a apart of. It appears your comments relate to > the supposed controversial 1:1 non-normative text. > i only talk about the aspect of technical maturity. it is not unreasonable that i disagree the status of being WG doc even if there might be only me who hasn't understood. however, as you raised this question on the procedural justice, i have to point out the following fact: the mdt-named MAP spec was circulated, according to my mailbox record (maybe i missed some), until March 30, with the last message sent out by Leaf. however, the 1:1 mode is added on May 31st 10:47:11 timezone +0200 according to the git log and git diff and the next day, June 1st, it becomes the published version, which appears to IETF draft repos on June 8th. after May 30th, nobody among the authors called for review. i may imagine that, maybe, the authors were not aware that the 1:1 mode text IS a sort of change that need to review. but what do you suggest the "right timing" if it is not NOW?! i hope i need to point out the above fact only once and never talk on it again. i also hope it were the case that the authors called for review but i missed. it is not my purpose to debate on such kind of trivials -- wasting life of you, of me and of all of ours, nor i care what is the normative text what is not. i only focus on the technical issue. whatever the timing is, i am against any confusion and misleading. - maoke --f46d04430474e6c38904c3720d6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Woj,=A0

thanks a lot for the clarifica= tion.=A0

2012/6/27 Wojciech Dec <wde= c.ietf@gmail.com>
Hi Maoke,

inline...

On 27 June 2012 05:28, Maoke <fibrib@gmail.com>= ; wrote:
hi dear authors,=A0

as the map-00 draft c= ontains the normative 1:1 mode statement that is new in comparison to the p= revious versions, i'd like to ask some technical questions in order to = clarify the understanding.=A0

Section 4. page 9:

MAP can als= o be provisioned in 1:1 mode. In 1:1 mode the BR has a
MAP domain pe= r subscriber, and the CE is configured in hub and spoke
mode, with on= ly a DMR and no other mapping rules. This allows for a
mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User
= IPv6 prefix.

Question #1: who is a "subscr= iber"? the definition is missing. and relatedly, what is the protocol = for the subscription? the specification on the protocol is missing too.

Answer 1: Subscriber =3D MAP CE. We will clarif= y the term.

got it.
<= div>=A0

Question #2: what is the relationship between 1:1 mode,= encapsulation mode, translation mode, hub&spoke mode, mesh mode? are t= hey independent to each other, exclusively or not, somehow orthogonal or no= t? the specification on the "mode" is missing.=A0

Answer 2: mode =3D forwarding mode, also known = as transport mode. There are two of these, translation and encapsulation. N= o relation between the rest of the things you mention

okay. then please clearly revise the wording to avoid c= onfusing the readers. only after the terms/wordings are revised, the MAP de= ployment is able to follow these well-defined words and terms.=A0
=A0

Question #3: what is the resource for deployment of a &= quot;MAP domain"? the MAP spec never define that. however, we kept und= erstanding that the resource for a "MAP domain" includes:=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0- an IPv4 prefix (with prefix length 32 or = less) shared by CEs in this domain
=A0 =A0 =A0 =A0 =A0 =A0 =A0- a= n IPv6 prefix (with prefix length 64 or less) delegated to the CEs in this = domain with a /64 (or shorter) per CE (as the basic model of prefix d
=A0 =A0 =A0 =A0 =A0 =A0 =A0the newly introduced "1:1 mode" o= bviously abandons this understanding, then an explicit definition on the re= source of a "MAP domain" is requested. this is the origin and ess= ential starting point of the MAP deployment.=A0

Answer 3: What do you mean by resource for depl= oyment?? It has, and always has been an IPv6 prefix and an IPv4 address. Th= is is the same in *all* of this solution space. The split in terms of how o= ne arrives at the IPv4 address and port-range has always been variable in M= AP.
Additional point: There is no newly introduced 1:1 mode, as the spec hasn&#= 39;t changed. Folks who implemented according to the previous spec, whihc y= ou seem to indicate had no 1:1 mode see no difference.

as you clarified CE =3D subscriber, it is ok. but a new= question:=A0

question #3.1: in the 1:1 mode, how = long the PSID is? how long the EA-bits? i understand the bit relationship d= escribed in the Figure 7 is the native property of the MAP algorithm. but i= t looks to me that 1:1 mode has nothing related to this figure. it breaks t= he relation o =3D p + q. it is hard to accept that the 1:1 mode is not newl= y introduced alien. even an alien were welcome, i would like to suggest the= authors prepare a text at Figure 7 stating "this is nosense to the 1:= 1 mode".=A0

question #3.2: then about the rule, for ONE rule, i see= only, in Section 5:=A0
* Rule IPv6 prefix (including pre= fix length)

* Rule IPv4 prefix (including prefix length)

* Rule EA-bits length (in bits)

* Rule Port Para= meters (optional)

(as the 5th "forwarding mod= e" has been confirmed as a domain configuration)

i don't see there is a PSID value in this tuple, nor i see it in t= he example in Sec 5.2, 5.3 for the Given rules.=A0

if Section 5 is not applied to the 1:1 mode, an explicit text "This s= ection is nonsense to the 1:1 mode" is required. if a PSID value is to= be added into the rule, i understand it is hard to call "not newly in= troduced" stuff. =A0
=A0
=A0Disabling the 1:1 mode would actually require a spec change.=A0
<= /div>

Section 5. page 10:

=A0 * = Forwarding mode

Question #4: this appears twice a= t the definition of BMR and DMR, respectively. though Wojieich and Remi has= discussed that in another thread, i would like to confirm: is this mode a = domain configuration parameter or a rule parameter?

Answer 4: Confirmed, intent is for it to be per= domain.

Question #5: does this "forwarding mode" is a= enumerate type of {MAP-T, MAP-E, 1:1, hub&spoke, mesh} or else, e.g., = {MAP-T, MAP-E} x {1:1, N:1} x {hub&spoke, mesh}, where the "x"= ; is the operator for de Cartesian product of sets? (related to #2)

Answer 5: No need to enumerate, because there i= s no relation between these (answered above)

question #5.1: do you mean, for example, when i decided t= he domain forward mode, e.g. MAP-T, it is fine that i deploy 1:1 for CE.A w= hile N:1 for CE.B, right? please confirm this.=A0
=A0

Section 7.1 page 19:

In 1:= 1 mode, the MAP CE is provisioned with only a Default Mapping
Rule, a= nd the full IPv4 address/prefix and port range is provisioned
using t= he DHCP option.

Question #6: is the CE or the subscriber the rece= iver of the "full IPv4 address/prefix and port range" (correction= : port set) to be provisioned? or does it mean a CE is a subscriber itself = in the 1:1 mode?

Woj>=A0 MAP CE.

Section 7.3 page 19:

A MAP-E C= E provisioned with only a Default Mapping Rule, as in the
1:1 case, a= nd with no IPv4 address and port range configured by other
means, MUS= T disable its NAT44 functionality.

Question #7: this text is contradictory with Section 7.= 1. is the DHCP option a sort of "other means" or not, or there= 9;s something out of scope of this draft?=A0

Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing i= n the architecture prevents any other provisioning mechanisms to be used in= cl dhcpv4, snmp, etc.

still confusing.=A0
Question #7.1: is what the MAP *can* use a pa= rt of MAP spec suite, e.g., MAP-DHCP? please clarify explicitly: in the con= dition of Section 7.1, NAT44 must be disable or not?=A0
=A0
=

Question #8: what is the consequence of disabling the N= AT44 functionality on CE when a subscriber having a PSID of a share IPv4 ad= dress is running behind that CE as a 1:1 mode domain?=A0

Woj>=A0 That is not possible.=A0 We can be clearer in say= ing that if the CPE has no IPv4 address configured then NAT44 is to be disa= bled (kind of obvious)

much= more confusing.=A0
Question #8.1: please clarify if this CPE has no IPv4 stack enabled or= has only no IPv4 address configured (statically or dynamically). how it wo= rks?=A0
=A0

before all of the above questions and further questions= possibly to be generated during the discussion are fully clarified, i cann= ot help but gently show my disagreement on putting the current draft as wor= king group result. i also hope the MAP spec authors kindly understand with = so many uncertainty modifying MAP deployment draft to fit the MAP spec is a= mission-impossible for the time being.=A0

Woj> What is the basis of your gentle disagr= eement, and its timing now? The merged of the drafts was discussed previous= ly, and circulated on the design team of which you are a apart of. It appea= rs your comments relate to the supposed controversial 1:1 non-normative tex= t.

i only talk about the aspect o= f technical maturity. it is not unreasonable that i disagree the status of = being WG doc even if there might be only me who hasn't understood.=A0

however, as you raised this question on the procedural = justice, i have to point out the following fact:=A0

=A0the mdt-named MAP spec was circulated, according to my mailbox record = (maybe i missed some), until March 30, with the last message sent out by Le= af. however, the 1:1 mode is added on May 31st 10:47:11 =A0timezone +0200 a= ccording to the git log and git diff and the next day, June 1st, it becomes= the published version, which appears to IETF draft repos on June 8th. afte= r May 30th, nobody among the authors called for review.=A0

i may imagine that, maybe, the authors were not aware t= hat the 1:1 mode text IS a sort of change that need to review. but what do = you suggest the "right timing" if it is not NOW?!=A0

i hope i need to point out the above fact only once and= never talk on it again. i also hope it were the case that the authors call= ed for review but i missed. it is not my purpose to debate on such kind of = trivials -- wasting life of you, of me and of all of ours, nor i care what = is the normative text what is not. i only focus on the technical issue. wha= tever the timing is, i am against any confusion and misleading.=A0

- maoke
--f46d04430474e6c38904c3720d6f-- From fibrib@gmail.com Wed Jun 27 04:12:23 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 B106921F85E3 for ; Wed, 27 Jun 2012 04:12:23 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdjnZMUXD81U for ; Wed, 27 Jun 2012 04:12:22 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 682AF21F85C5 for ; Wed, 27 Jun 2012 04:12:22 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so752679wib.13 for ; Wed, 27 Jun 2012 04:12:21 -0700 (PDT) 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=g5HmkKd9/CeoEqUs1yBUCjSiRScJ7LfkdlVpuEZSwhM=; b=uATrT+JVLLHtkwLz0rxsUm2HeBdra59PduXwhevdzdKnFDGe3hSwJASwxGgSInz/Yh Uoc4x1UWWBZWglxFWm/YqmVUlKVTSdbwhgKcdF1iiBlF5Y7x/EW7oWWLr/M8D+8GAYC6 c7OdU/H234wkjJB18ku7wiwOnJbTcW85m9dnuifMl9wwQ5RX3Hv0zbadn2c74/u0pY7n eHCiOSeDvzJX+16Laoon6AetkmX6q2BmZr360aUT4ZVtvFlEYxmUaP+Tkcd9JdVMh7na 0yA6xtWMBvTTlGzDGPAY5inuA0eZ4uSrIsu4DBV9JcYxSMIRZi1Fse7fV+KWXKNzZr2K 0I+Q== MIME-Version: 1.0 Received: by 10.180.93.99 with SMTP id ct3mr3873622wib.13.1340795541427; Wed, 27 Jun 2012 04:12:21 -0700 (PDT) Received: by 10.216.17.20 with HTTP; Wed, 27 Jun 2012 04:12:21 -0700 (PDT) In-Reply-To: <7683A644-D86E-4A33-9234-AF742F4CC5AE@gmail.com> References: <7683A644-D86E-4A33-9234-AF742F4CC5AE@gmail.com> Date: Wed, 27 Jun 2012 11:12:21 +0000 Message-ID: From: Maoke To: Satoru Matsushima Content-Type: multipart/alternative; boundary=f46d043c08e8f6979804c37249a5 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 27 Jun 2012 11:12:23 -0000 --f46d043c08e8f6979804c37249a5 Content-Type: text/plain; charset=ISO-8859-1 hi Satoru-san, 2012/6/27 Satoru Matsushima > Hi Maoke, Woj, > > Two points. > > On 2012/06/27, at 17:43, Wojciech Dec wrote: > > > Question #7: this text is contradictory with Section 7.1. is the DHCP > option a sort of "other means" or not, or there's something out of scope of > this draft? > > > > Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing > in the architecture prevents any other provisioning mechanisms to be used > incl dhcpv4, snmp, etc. > > In addition, any provisioning protocol could be used in MAP. But using > these protocol in LW46 basis, DHCPv4-over-IPv6 and PCP in particular, > absolutely out of scope for MAP. > > > > > > Question #8: what is the consequence of disabling the NAT44 > functionality on CE when a subscriber having a PSID of a share IPv4 address > is running behind that CE as a 1:1 mode domain? > > > > Woj> That is not possible. We can be clearer in saying that if the CPE > has no IPv4 address configured then NAT44 is to be disabled (kind of > obvious) > > Described text for '1:1 mode' in current version would make some people > confused. We need to make clear for that. > i fully agree with you as zero-lengthed EA-bits is a naturally possible case of MAP. however, to my understanding, even in this case the Figure 7 of MAP addressing architecture is still appliable and therefore it implies PSID length also equals to zero. this is the real meaning of 1:1 that is a natural case possibly occurs rather than a "mode" - mode is a sort of preset configuration. and further, it is not necessary to disable NAT44 in such EA-null/PSID-null cases at CE. this definitely makes the MAP spec clear. if necessary, including this special case in the MAP draft or in the MAP deployment draft, mentioning its usage, is what i support unless we discover any other flaws regarding this. cheers, maoke > > cheers, > --satoru --f46d043c08e8f6979804c37249a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Satoru-san,=A0

2= 012/6/27 Satoru Matsushima <satoru.matsushima@gmail.com><= /span>
Hi Maoke, Woj,

Two points.

On 2012/06/27, at 17:43, Wojciech Dec wrote:

> Question #7: this text is contradictory with Section 7.1. is the DHCP = option a sort of "other means" or not, or there's something o= ut of scope of this draft?
>
> Woj> DHCP is a provisioning mechanism which MAP *can* use, but noth= ing in the architecture prevents any other provisioning mechanisms to be us= ed incl dhcpv4, snmp, etc.

In addition, any provisioning protocol could be used in MAP. But usin= g these protocol in LW46 basis, DHCPv4-over-IPv6 and PCP in particular, abs= olutely out of scope for MAP.


>
> Question #8: what is the consequence of disabling the NAT44 functional= ity on CE when a subscriber having a PSID of a share IPv4 address is runnin= g behind that CE as a 1:1 mode domain?
>
> Woj> =A0That is not possible. =A0We can be clearer in saying that i= f the CPE has no IPv4 address configured then NAT44 is to be disabled (kind= of obvious)

Described text for '1:1 mode' in current version would make s= ome people confused. We need to make clear for that.
<= br>
i fully agree with you as zero-lengthed EA-bits is a nat= urally possible case of MAP. however, to my understanding, even in this cas= e the Figure 7 of MAP addressing architecture is still appliable and theref= ore it implies PSID length also equals to zero. this is the real meaning of= 1:1 that is a natural case possibly occurs rather than a "mode" = - mode is a sort of preset configuration. and further, it is not necessary = to disable NAT44 in such EA-null/PSID-null cases at CE.

this definitely makes the MAP spec clear. if necessary,= including this special case in the MAP draft or in the MAP deployment draf= t, mentioning its usage, is what i support unless we discover any other fla= ws regarding this.=A0

cheers,
maoke
=A0

cheers,
--satoru

--f46d043c08e8f6979804c37249a5-- From wdec.ietf@gmail.com Wed Jun 27 04:30: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 66AEE21F86DE for ; Wed, 27 Jun 2012 04:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.313 X-Spam-Level: X-Spam-Status: No, score=0.313 tagged_above=-999 required=5 tests=[AWL=-3.520, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_74=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8EKmWug4D9X for ; Wed, 27 Jun 2012 04:30:08 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 450D321F86DD for ; Wed, 27 Jun 2012 04:30:08 -0700 (PDT) Received: by qabj34 with SMTP id j34so772618qab.4 for ; Wed, 27 Jun 2012 04:30:07 -0700 (PDT) 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=TZlxANswKrlhUcnyhOTfdbIH5WOIGIXVORseqaYhrps=; b=Hp9+7uKjfpK/5SSRg3/sGm06LsbF1yFXweEy2PiajOeY02npQFsv/SAi6l9TETS+bu QQezOYuwRaQid2s7TSLYSEZCZWb1c+6pO5L5yAhRrne9gBajU7hpNPI7dzcPR9gZ+MHq N2UMbotpTv/0BBst9wmMvatt3zC+ZUfq/25LdEhP8Ls5SKa+VVA2FFZeVBSkUgRj/gcK nPM5dJWFFZE5VFpbFO/3WcwEiJyPUfINqXaqro7iSNVeJW7lR0ys5oly60NS9p5G1Znu YlhvuEN7fWU45m6rPVLDjrdPgEOZG+XsCXy3n99A+fBvg1SGZl7dmdHh2up1LRGc5xQp 77gA== MIME-Version: 1.0 Received: by 10.229.106.226 with SMTP id y34mr8439004qco.54.1340796607388; Wed, 27 Jun 2012 04:30:07 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Wed, 27 Jun 2012 04:30:06 -0700 (PDT) In-Reply-To: <2012062717174839466911@gmail.com> References: <8A1B81989BCFAE44A22B2B86BF2B76318918594767@HE111643.EMEA1.CDS.T-INTERNAL.COM> <2012062717174839466911@gmail.com> Date: Wed, 27 Jun 2012 13:30:06 +0200 Message-ID: From: Wojciech Dec To: xiechf01 Content-Type: multipart/alternative; boundary=002354471af47fdc3b04c3728930 Cc: "softwires@ietf.org WG" , "ian.farrer@telekom.de" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 11:30:12 -0000 --002354471af47fdc3b04c3728930 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hello Chongfeng, On 27 June 2012 11:17, xiechf01 wrote: > ** > > > > We admit the algorithmic mapping is technically and theoretically "beauti= ful", multiple mapping methods and forwarding modes have been designed. > The essence of this mapping is that the format of IPv6 packet depends on = IPv4 address and port information, with an algorithmic pre-determined > relationship in it. However, when deciding whether to adopt it in the fut= ure,the following aspects should be considered first. > > 1) With algorithmic mapping method, some of bits in IPv6 prefix will be u= tilized by IPv4 address(or part of IPv4 address), > which means that these bits > > can not be used for other purpose. Since the number of bits of IPv6 prefi= x allocated to a given ISP is limited, every bit should be treated carefull= y. > When ISP deploys IPv6 in product network,some other features including se= rvice type, > QoS, location, etc,may also be taken into consideration and embedded > in IPv6 prefix,which might conflict with EA-bits. > MAP uses EA-bits, but the source of those EA-bits can be almost any. In cases where the EA-bits derive from the v6 prefix, this leads to actually a significant reduction in the number of rules that need to be provisioned in a domain - this simplifies operations hugely. The location of the EA-bits in the prefix is also flexible. That said, the EA-bits can derive from any piece of configuration information, and this does NOT have to be the IPv6 prefix. This leads to per CE rules, and effectively more complex operations. It is thus a question of optimization and simplicity vs a lock-in to an "impossible" to optimize architecture. > > > 2) Algorithmic mapping needs the engineering staff of local NOC to unders= tand complex mapping algorithm, different mapping modes, forwarding modes, > > etc, which means they must be smart enough. Address planning and allocat= ion is an important job of NOC, and it requires NOC guys to master all thes= e stuff > > to operate network correctly. But we will ask honestly, do our effort des= erve such complexity? > Well, there is nothing difficult in the mapping algorithm; it maps port ranges to CEs. All solutions in this space do just that. I do not believe that complexity can be attributed to the use of a Port-Set-ID, vs the use of explicit port ranges in some dhcp option. Even "light" NOC staff would need to be schooled in interpreting such data. I'll levae aside the complex chain of events that is necessary to put into place to make the L46 solution in place > > > From operators' perspective, we hope that the address format should have = less constraint and more flexibility. IPv6 is born for IPv6, not for IPv4. = We can have > > more freedom the utilize the IPv6 address, more flexibility, easy underst= anding and management feature. > > > Yes, MAP can provide a per-subscriber per-rule mode when the length of EA= -bits becomes zero somehow. But this means the mapping feature is removed i= n this case. But then we will ask, if the mapping is already gone, why shou= ld we > buy so many useless features to do this? > > =A1=B0The simpler, the better=A1=B1=A3=ACthat's what we want. > Many years of network experience have shown that solutions which rely per-CPE/subscriber provisioning or state on network devices are ultimately anything but simple or robust - that does not stop people from re-inventing the BRAS, etc. That said, building such intricate stateful solutions, with no possibility for optimization is anything but simpler or better. Ironically a unified & comprehensive solution is possible here. Hopefully we'll converge on that soon, but that requires some more open discussion. Regards, Woj. > > Chongfeng @China Telecom > > > ------------------------------ > > *From:* ian.farrer@telekom.de > *Date:* 2012-06-27 16:39 > *To:* wdec.ietf@gmail.com > *CC:* softwires > *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT > reflect the consensus from the WG > Hi Woj, > > Comments in line. > > Cheers, > Ian > > ------------------------------ > *From:* Wojciech Dec [mailto:wdec.ietf@gmail.com] > *Sent:* Dienstag, 26. Juni 2012 09:55 > *To:* Farrer, Ian > *Cc:* satoru.matsushima@gmail.com; softwires@ietf.org > *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT > reflect the consensus from the WG > > > > On 26 June 2012 09:13, wrote: > >> Hi Satoru, >> >> Comment in line below. >> >> Best regards, >> Ian >> >> Date: Mon, 25 Jun 2012 18:46:18 +0900 >> From: Satoru Matsushima >> To: Peng Wu >> Cc: softwires@ietf.org, Yong Cui >> Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does >> NOTreflect the consensus from the WG >> Message-ID: <5851B29B-0CCF-4B08-86D5-8CBBFCEF5FA4@gmail.com> >> Content-Type: text/plain; charset=3Diso-8859-1 >> >> Hi Peng, >> >> On 2012/06/25, at 18:34, Peng Wu wrote: >> >> Let's think that a CE provisioned with following BMR comes from MAP >> DHCPv6 options. >> BMR: >> o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} >> o Rule-ipv4-prefix : x.x.x.x/32 >> o EA-length : 0 >> o Port-param option : {PSID/length} >> This BMR could be a LW46 provisioning means. >> >> Again, all the information needed is the IPv4 address and port set. >> 1) The item like rule-ipv6-prefix is not needed at all. >> 2) Port set or PSID still needs extra provisioning (while in regular >> MAP it's embedded in IPv6 address) >> So why make it so difficult and obscure >> >> >> Not difficult, easy business for CE which implemented MAP. Other >> difficulty in operator side in particular provisioning complex, that sho= uld >> be same with LW46. It also makes to complete MAP spec in the ea-len zero >> case. >> >> [IF] Additional complexity in the operator side is where I see the >> problem with MAP in our case. The strength that MAP offers is for the me= sh >> model and the complexity that it brings is a neat way of achieving this. >> But if hub-and-spoke is the only deployment scenario that you need, then >> the complexity for mesh is an unnecessary addition that results in >> operational complexity, which is something we're trying to engineer out >> wherever we can. >> E.g. In the case above, for a shared IP address, the source port range i= s >> encoded in the port-param option. To troubleshoot user connectivity, ops >> need to have a good understanding of how this is being calculated so tha= t >> they can trace the user. Not the end of the world, but with millions of >> customers and a hundred support staff, it's just better avoided if >> possible. This logic also then needs to be built into other business >> support systems that rely on the customers IP/port range as an identifie= r. >> LW46 solves this with a simple (though long) lookup table. This does mea= n >> that it's very easy to extract how a user is configured or identified wi= th >> a minimum of additional knowledge and calculating tools. >> > > Well, a couple of observations: > A) MAP allows you to optimize complexity in not having to deal with per > subscriber rules in cases where this is feasible. > > But this re-introduces v4 and v6 addressing dependency which we're trying > to avoid. > > B) You're referring to data representation as an operational problem, > which if so, actually applies to any solution incl LW46 that transmits > port-range info to a client. I.e. "Whatever support staff" needs to be > schooled to use some logic to glean useful port information from the data > sent to a client > > "Don't worry about unnecessary complexity, we'll just do more training!" > isn't a very powerful argument in our business. > > C) It is very easy to represent MAP data as port range info on routers, > tools, etc. > > On routers, I'm sure that it is. However, the fact that you need a tool t= o > work out the mapping again points to complexity. On internally developed > and 3rd party BSS systems then it's more work that offers no benefit. > > -Woj. > > >> >> cheers, >> --satoru >> >> ------------------------------ >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --002354471af47fdc3b04c3728930 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hello Chongfeng,

On 27 June 2012 11:17, x= iechf01 <xiechf01@gmail.com> wrote:
 
 
We admit the algorithmic mapping is tech= nically and theoretically "beautiful", multip= le mapping methods and forwarding modes have&= nbsp;been designed. 
The essence of this mapping is that = ;the format of IPv6 packet depends on IP= v4 address and port information, with an = ;algorithmic pre-determined =20 relationship in it. However, when deciding wh= ether to adopt it in the future,the foll= owing aspects should be considered first.
 
1) With algorithmic mapping method, some = ;of bits in IPv6 prefix will be utilized=  by IPv4 address(or part of IPv4 address= ),  =20 which means that these  bits 
can not be used for other purpose. = Since the number of bits of IPv6 prefix&= nbsp;allocated to a given ISP is limited,&nbs= p;every bit should be treated carefully. 
When ISP deploys IPv6 in product network= ,some other features including service type,=20 QoS,=20 location, etc,may also be taken into consider= ation and embedded
 in IPv6 prefix,which might conflict wit= h EA-bits.

MAP uses EA-bits, bu= t the source of those EA-bits can be almost any. In cases where the EA-bits= derive from the v6 prefix, this leads to actually a significant reduction = in the number of rules that need to be provisioned in a domain - this simpl= ifies operations hugely. The location of the EA-bits in the prefix is also = flexible.
That said, the EA-bits can derive from any piece of configuration informati= on, and this does NOT have to be the IPv6 prefix. This leads to per CE rule= s, and effectively more complex operations.
It is thus a question of opt= imization and simplicity vs a lock-in to an "impossible" to optim= ize architecture.
 
2) Algorithmic mapping needs the engineering&= nbsp;staff of local NOC to understand complex=  mapping algorithm, different mapping modes, = forwarding modes,
 etc, which means they must be smar= t enough. Address planning and allocation is&= nbsp;an important job of NOC, and it req= uires NOC guys to master all these stuff=  
to operate network correctly. But we wil= l ask honestly, do our effort deserve su= ch complexity?
Well, there is nothi= ng difficult in the mapping algorithm; it maps port ranges to CEs. All solu= tions in this space do just that.
I do not believe that complexity can be attributed to the use of a Port-Set= -ID, vs the use of explicit port ranges in some dhcp option. Even "lig= ht" NOC staff would need to be schooled in interpreting such data. I&#= 39;ll levae aside the complex chain of events that is necessary to put into= place to make the L46 solution in place
 
From operators' perspective, we hope that=  the address format should have less con= straint and more flexibility. IPv6 is born&nb= sp;for IPv6, not for IPv4. We can have&n= bsp;
more freedom the utilize the IPv6 addres= s, more flexibility, easy understanding and m= anagement feature.
 
Yes, MAP can provide a per-subscriber pe= r-rule mode when the length of EA-bits b= ecomes zero somehow. But this means the = mapping feature is removed in this case. = ;But then we will ask, if the mapping&nb= sp;is already gone, why should we 
buy so many useless features to do = this?   
 
“The simpler, the better”=A3=ACthat's&n= bsp;what we want.

Many yea= rs of network experience have shown that solutions which rely per-CPE/subsc= riber provisioning or state on network devices are ultimately anything but = simple or robust - that does not stop people from re-inventing the BRAS, et= c. That said, building such intricate stateful solutions, with no possibili= ty for optimization is anything but simpler or better.
Ironically a unified & comprehensive solution is possible here. Hopeful= ly we'll converge on that soon, but that requires some more open discus= sion.

Regards,
Woj.
 
 
 
Date: 2012-06-27 16:39
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-ma= p-00=20 does NOT reflect the consensus from the WG
Hi Woj,
 
Comments in line.
 
Cheers,
Ian



On 26 June 2012 09:13, <ian.farrer@telekom.= de> wrote:
Hi Satoru,
Comment in line=20 below.
Best regards,
Ian
Date: Mon, 25 Jun 20= 12=20 18:46:18 +0900
From: Satoru Matsush= ima=20 <sato= ru.matsushima@gmail.com>
Subject: Re: [Softwi= res]=20 [Softwire] draft-ietf-softwire-map-00 does
NOTreflect=20 the consensus from the WG
Content-Type:=20 text/plain; charset=3Diso-8859-1
Hi Peng,
On 2012/06/25, at 18= :34,=20 Peng Wu wrote:
Let's think that a CE provisioned with following BMR comes f= rom MAP=20 DHCPv6 options.
BMR:
  o Rule-ipv6-prefix  : {exact matched with = CE's=20 delegated prefix}
  o Rule-ipv4-prefix  : x.x.x.x/32
  o=20 EA-length         : 0
  o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
Again, all the information needed is the IPv4 address and port=20 set.
1) The item like rule-ipv6-prefix is not needed at all.
2) Port set or PSID still needs extra provisioning (while in=20 regular
MAP it's embedded in IPv6 address)
So why make it so difficult and obscure
Not difficult, easy= =20 business for CE which implemented MAP. Other difficulty in operator side = in=20 particular provisioning complex, that should be same with LW46. It also m= akes=20 to complete MAP spec in the ea-len zero case.
[IF] Additional=20 complexity in the operator side is where I see the problem with MAP in ou= r=20 case. The strength that MAP offers is for the mesh model and the complexi= ty=20 that it brings is a neat way of achieving this. But if hub-and-spoke is t= he=20 only deployment scenario that you need, then the complexity for mesh is a= n=20 unnecessary addition that results in operational complexity, which is=20 something we're trying to engineer out wherever we can.
E.g. In the case abo= ve,=20 for a shared IP address, the source port range is encoded in the port-par= am=20 option. To troubleshoot user connectivity, ops need to have a good=20 understanding of how this is being calculated so that they can trace the = user.=20 Not the end of the world, but with millions of customers and a hundred su= pport=20 staff, it's just better avoided if possible. This logic also then nee= ds to be=20 built into other business support systems that rely on the customers IP/p= ort=20 range as an identifier.
LW46 solves this wit= h a=20 simple (though long) lookup table. This does mean that it's very easy= to=20 extract how a user is configured or identified with a minimum of addition= al=20 knowledge and calculating tools.

Well, a couple of observations:
A) MAP allows = you to=20 optimize complexity in not having to deal with per subscriber rules in case= s=20 where this is feasible. &= nbsp;
 
But=20 this re-introduces v4 and v6 addressing dependency which we're try= ing to=20 avoid.

B) You're referring to data=20 representation as an operational problem, which if so, actually applies to = any=20 solution incl LW46 that transmits port-range info to a client. I.e. "W= hatever=20 support staff" needs to be schooled to use some logic to glean useful = port=20 information from the data sent to a client 
 
"Don't=20 worry about unnecessary complexity, we'll just do more training!"= =20 isn't a very powerful argument in our=20 business. 

C) It is very easy to represent=20 MAP data as port range info on routers, tools, etc.
 
On=20 routers, I'm sure that it is. However, the fact that you need a tool to= work out=20 the mapping again points to complexity. On internally developed and 3rd par= ty=20 BSS systems then it's more work that offers no benefit.

-Woj.
 

cheers,
--satoru

--------------------= ----------



_______________________________________________
Softwi= res=20 mailing list
S= oftwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires=



--002354471af47fdc3b04c3728930-- From sunqi.csnet.thu@gmail.com Wed Jun 27 04:42: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 6036121F85F0 for ; Wed, 27 Jun 2012 04:42:18 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m3avDnPNcgz for ; Wed, 27 Jun 2012 04:42:17 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B87B621F85A4 for ; Wed, 27 Jun 2012 04:42:17 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1503593pbc.31 for ; Wed, 27 Jun 2012 04:42:17 -0700 (PDT) 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=hEbN32nsi9ZAoDVuJ0U9PEFqe6mw71h69raO1W4PHbM=; b=DH+w1MdMSLCv6leC7IpdWxc9s7dHGj7H8+HoKV2vU/j2zpVsodfXqyAWj5jdwh+eO6 Yqc5WCiIa0c6wOMh0TVPBbtHE2u3yY7st1OgaX8hsuvtV0FQKM+4xF3Q5VT86eJvroat L3tUKkUDMtlN4j3MjmIzT0ZHr/sr5/7Z7nY45xQgb4uIRxAjdncxEJBpnxmR6N7DXthq XERdCDrEZAHUriwECwUb5lvRppdGqfSZ8Sxo4wp8Fv78WRhlBaNgRkLsjBUexqr011B7 IaM0qR1k3+7Fg1PESN+m4ni7DPCT7N3MMR2kPAVnFEFXC1u0jSap2uDhdn7EDvpAyqhi wUtQ== MIME-Version: 1.0 Received: by 10.68.225.201 with SMTP id rm9mr63290683pbc.71.1340797337349; Wed, 27 Jun 2012 04:42:17 -0700 (PDT) Received: by 10.143.7.3 with HTTP; Wed, 27 Jun 2012 04:42:16 -0700 (PDT) In-Reply-To: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> Date: Wed, 27 Jun 2012 19:42:16 +0800 Message-ID: From: Qi Sun To: Satoru Matsushima Content-Type: multipart/alternative; boundary=047d7b2ede33022c9604c372b524 Cc: Softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 11:42:18 -0000 --047d7b2ede33022c9604c372b524 Content-Type: text/plain; charset=ISO-8859-1 Hi Satoru, Please see inline :) Qi Sun On Wed, Jun 27, 2012 at 6:27 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Qi, > > On 2012/06/27, at 19:01, Qi Sun wrote: > > > > > [Qi] DHCPv4 over IPv6 is a provisioning method. And it's about the > public IPv4 address allocation, NOT about IPv4 address and IPv6 address > mapping. So there is no state. Please read the draft of DHCPv4 over IPv6 > for clarification. > > LW4over6 needs to maintain the binding table on TC. That's stateful. > > That sense is 'stateless' in my mind if there's no DHCP state in the BR. > > [Qi] What discussed here is about states on data plane, aka the v4-v6 addressing binding(please refer to joel's email). The binding table could be dynamic(on-demand) or static. > > Actually in MAP 1:1 mode there will be a binding table right? Here comes > the question: what will you do if there are new comers or some users > leaving the network? > > it is just an operation in provision. Now I find that LW46 could be > possible to merged with MAP, or vice versa. thanks. > [Qi] LW4over6 is a solution targeting at the per-user stateful/binding scenario, pure and clear. MAP is originally targeting at pure stateless/alogrithmic address mapping scenario, and then comes to this 1:1 mode due to the theoretical corner case of EA-bits=0, according to you guys. While I believe the main targets are differnt and paralled (actually two out of three in 4-over-6 case, with the 3rd one per-session stateful), I don't think merging is the proper way to proceed. Thanks, Qi > > cheers, > --satoru --047d7b2ede33022c9604c372b524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Satoru,

Please see inline :)

Qi Sun

On Wed, Jun 27, 2012 = at 6:27 PM, Satoru Matsushima <satoru.matsushima@gmail.com&g= t; wrote:
Qi,

On 2012/06/27, at 19:01, Qi Sun wrote:

>
> [Qi] DHCPv4 over IPv6 is a provisioning method= . And it's about the public IPv4 address allocation, NOT about IPv4 add= ress and IPv6 address mapping. So there is no state. Please read the draft = of DHCPv4 over IPv6 for clarification.
> LW4over6 needs to maintain the binding table on TC. That's statefu= l.

That sense is 'stateless' in my mind if there's no DHCP s= tate in the BR.

[Qi] What discussed here is a= bout states on data plane, aka the v4-v6 addressing binding(please refer to= joel's email). The binding table=A0could be dynamic(on-demand) or stat= ic.
=A0
> Actually in MAP 1:1 mode there will be a binding table right? Here com= es the question: what will you do if there are new comers or some users lea= ving the network?

it is just an operation in provision. Now I find that LW46 could be p= ossible to merged with MAP, or vice versa. thanks.
[Qi]=A0LW4over6=A0is=A0a=A0solution=A0targeting=A0at=A0the=A0pe= r-user=A0stateful/binding=A0scenario,=A0pure=A0and=A0clear.
MAP=A0is=A0originally=A0targeting=A0at=A0pure=A0stateless/alogrithmic= =A0address=A0mapping=A0scenario,=A0and=A0then=A0comes to=A0this=A01:1=A0mod= e=A0due=A0to=A0the=A0theoretical=A0corner=A0case=A0of=A0EA-bits=3D0,=A0acco= rding=A0to=A0you=A0guys.
While=A0I=A0believe=A0the=A0main=A0targets are= =A0differnt=A0and=A0paralled (actually=A0two=A0out=A0of=A0three=A0in=A04-ov= er-6=A0case, with=A0the=A03rd=A0one=A0per-session=A0stateful),=A0I=A0don= 9;t=A0think=A0merging=A0is=A0the=A0proper=A0way=A0to=A0proceed.

Thanks,
Qi
> >> Not quite. >> I believe that the most motivate to start this work in the wg has destined >> MAP to be 'multi-protocol socket v2.0' that's what the former wg chair >> wished to. Do you remember that? >> > > i like the philosophy of "multi-protocol socket". however, i moderately > doubt the "multi-protocol socket v2.0" is a perfect plan for every cases. > in a quite good hotel, we see typically one 'multi-protocol socket' while a > lot of local-standard sockets. i never think it will make me happy if i see > every socket in my room is *multi-protocol*, occupying much spaces and > quite noticeable on the walls. we need one to deploy somewhere not the only > one type to deploy anywhere. ;-) > > therefore i understand the motivation of the wg is making a unified > solution covering both encapsulation and translation in the framework of > stateless, WITHOUT the exclusiveness against other solutions, more > specifically suitable for a certain use case. > > cheers, > maoke > > >> >> cheers, >> --satoru >> >> _______________________________________________ >> 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 satoru.matsushima@gmail.com Wed Jun 27 06:32: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 961A721F86DC for ; Wed, 27 Jun 2012 06:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWSIEAoAoMYB for ; Wed, 27 Jun 2012 06:32:21 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18A5E21F868A for ; Wed, 27 Jun 2012 06:32:21 -0700 (PDT) Received: by dacx6 with SMTP id x6so1444673dac.31 for ; Wed, 27 Jun 2012 06:32:20 -0700 (PDT) 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=j+98HuNRclAzO1RJjAZVERXKAoR+Iye9UFqR6YPXIZw=; b=vBuPq9HkQBepkODVlfdr2pHOSOoX1E+JRMCILv1CkUS54ecE20n4eqsjUGHCUCNtlo qlrtBRIu03A7rWz1nupPmUw4L8uXJi+RJWtxuHMbZgOWQyUrrZEv5ngTeZBG+tMnAs4I IrJ1suCvw3iIkbELyPC7GfDoOvhS72B/i//En1IM1gOdpUnDXb0t4yueYbpWWU/lJDBq prGG2DZ607fRWH9KvyPq9qg/N2F0Wji9KQl1b7cxhkXAxW+TTPXyekFMt/zRPHK2xJHr eesFuikraRMv+5XDCCjWW586jtG/vktf9Ak87eZ9mjyyesY4ZfNFHQIkKzd5ON9TJ2xj ZQuA== Received: by 10.68.138.166 with SMTP id qr6mr64308859pbb.43.1340803940803; Wed, 27 Jun 2012 06:32:20 -0700 (PDT) Received: from ?IPv6:2400:2411:8900::5540:f20c:521:fc29? ([2400:2411:8900:0:5540:f20c:521:fc29]) by mx.google.com with ESMTPS id nv6sm15195282pbc.42.2012.06.27.06.32.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 06:32:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Wed, 27 Jun 2012 22:32:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1278) Cc: Softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 13:32:21 -0000 On 2012/06/27, at 19:01, Qi Sun wrote: > > These are not possible because they require state in BR so that it's = LW46 use case, right? MAP define mapping rule in stateless manner. > > > > [Qi] As a provisioning method, DHCPv4 over IPv6 DOES NOT require any = state in TC/BR. Please check the draft. As a result, this is not about = stateful or stateless. There is no conflict between the binding table on = BR and the DHCPv4 over IPv6 process. >=20 OK. But wait, if it's not about stateful or stateless, the DHCPv4 over IPv6 = could also be a means to provision MAP CEs in a domain which is not only = per-sub mapping rule case, but also in the case of all MAP CEs covered = by single mapping rule. Great. How we are in well collaboration! Thanks a lot. cheers, --satoru=20= From tomasz.mrugalski@gmail.com Wed Jun 27 07:36: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 6CFED21F86D5 for ; Wed, 27 Jun 2012 07:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKCwd0zl5XHp for ; Wed, 27 Jun 2012 07:36:40 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A60BB21F86A8 for ; Wed, 27 Jun 2012 07:36:39 -0700 (PDT) Received: by eaaq13 with SMTP id q13so460267eaa.31 for ; Wed, 27 Jun 2012 07:36:38 -0700 (PDT) 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:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=Rz5SBhExZunb/b2isq/rypKFsUebZWkbFpCuudzc5RM=; b=nVtAYXaA3dKLUMygu3teiwTYILamT1GvG94N2vnuFooODX9zAaeAqBznjEA1O4u0F4 7O8/8vLXc0xyKGc1Can5YCMrJ1xQDOEzKGx/pJeAEWVeFUVXG0ZEUtjpOfKooORWP42F S7vSNfuPdOAlaulmOzB/nFRPhjbyAPGMc4oBHURN6WQjV9ExzbIH9DOtCtnzVoELbypm s8tPPVu008TGdLOsW3sPPS7dOsbsw8ILUO/+8KH5abCNrJfPChMEFv2/y+caMh+b0pIb RI1wDBw2w5WVjm/eZEv4nS5jup13vQ810wXWuK2nASdGr2zmeUBSEdZ/ycXpYRPAV2uW 16EA== Received: by 10.14.94.142 with SMTP id n14mr4244261eef.211.1340807798645; Wed, 27 Jun 2012 07:36:38 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:5964:8fb1:754e:1bc? ([2001:470:6061:1:5964:8fb1:754e:1bc]) by mx.google.com with ESMTPS id t3sm159777113eeb.15.2012.06.27.07.36.36 (version=SSLv3 cipher=OTHER); Wed, 27 Jun 2012 07:36:37 -0700 (PDT) Message-ID: <4FEB1A73.2030906@gmail.com> Date: Wed, 27 Jun 2012 16:36:35 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <4FEAFAB3.5020200@gmail.com> In-Reply-To: <4FEAFAB3.5020200@gmail.com> X-TagToolbar-Keys: D20120627163635219 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 14:36:40 -0000 On 27.06.2012 14:21, Tom Taylor wrote: > An old cartoon I once saw, making fun of ISDN IIRC, showed a single > socket on the outside of the wall, connected to a rat's-nest of > connections on the inside. This seems apt for the present enterprise. Regarding cartoons, I believe this one is relevant as well: http://xkcd.com/927/ Cheers, Tomek From leaf.y.yeh@huawei.com Wed Jun 27 08:08:43 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 3DFCB21F8657 for ; Wed, 27 Jun 2012 08:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.857 X-Spam-Level: X-Spam-Status: No, score=-6.857 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFdK+q0HIRUq for ; Wed, 27 Jun 2012 08:08:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ADBB721F8622 for ; Wed, 27 Jun 2012 08:08:39 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHN53613; Wed, 27 Jun 2012 11:08:39 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 08:05:12 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 08:05:16 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 27 Jun 2012 23:05:09 +0800 From: Leaf yeh To: Tomek Mrugalski , "softwires@ietf.org" Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG Thread-Index: AQHNVAcD7+bD+aq95Ue2+IseQtZKRpcNkH2AgAAl2YCAAIz3c4AAASMn Date: Wed, 27 Jun 2012 15:05:07 +0000 Message-ID: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <4FEAFAB3.5020200@gmail.com>,<4FEB1A73.2030906@gmail.com> In-Reply-To: <4FEB1A73.2030906@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: multipart/alternative; boundary="_000_B8D698183DF7404AAB5A1C5D4260E528mimectl_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 27 Jun 2012 15:08:43 -0000 --_000_B8D698183DF7404AAB5A1C5D4260E528mimectl_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://xkcd.com/449/ - Just for a test ________________________________ From: softwires-bounces@ietf.org [softwires-bounces@ietf.org] on behalf of = Tomek Mrugalski [tomasz.mrugalski@gmail.com] Sent: Wednesday, June 27, 2012 22:36 To: softwires@ietf.org Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT ref= lect the consensus from the WG On 27.06.2012 14:21, Tom Taylor wrote: > An old cartoon I once saw, making fun of ISDN IIRC, showed a single > socket on the outside of the wall, connected to a rat's-nest of > connections on the inside. This seems apt for the present enterprise. Regarding cartoons, I believe this one is relevant as well: http://xkcd.com/927/ Cheers, Tomek _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_B8D698183DF7404AAB5A1C5D4260E528mimectl_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

http://xkcd.com/449/<= /a> - Just for a test

 

 

 

From: softwires-bounces@ietf.org [softwires-bounces@ietf.org] on= behalf of Tomek Mrugalski [tomasz.mrugalski@gmail.com]
Sent: Wednesday, June 27, 2012 22:36
To: softwires@ietf.org
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does = NOT reflect the consensus from the WG

On 27.06.2012 14:21, Tom Taylor wrote:
> An old cartoon I once saw, making fun of ISDN IIRC, showed a single > socket on the outside of the wall, connected to a rat's-nest of
> connections on the inside. This seems apt for the present enterprise.<= br> Regarding cartoons, I believe this one is relevant as well:

http://xkcd.com/927/=

Cheers,
Tomek
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
--_000_B8D698183DF7404AAB5A1C5D4260E528mimectl_-- From rajiva@cisco.com Wed Jun 27 08:23: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 25BEA21F8683 for ; Wed, 27 Jun 2012 08:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.239 X-Spam-Level: X-Spam-Status: No, score=-9.239 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXvuaa2YzE5H for ; Wed, 27 Jun 2012 08:23:20 -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 0CC9721F8799 for ; Wed, 27 Jun 2012 08:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3457; q=dns/txt; s=iport; t=1340810600; x=1342020200; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zCBef26E7VfAUyjADAKEKG3kvh0CwQRrPLoghXH6sZQ=; b=LKOnI5gA3IQyMCCR92czCCRnYEyJd1rXvPX3sehfjwL6CxwUQpUgb9vg GEpO4BAGqVYqSFdKzBrVQ7g5hzbqZLA2qMM1VSmJjVahsFqgt7DGPp9Aq aL+ZdKwpSWY8HVjklZ0gcYXtWtbGIBL6gzmQp431bkkFfGdYiJ7ASP92m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOck60+tJV2b/2dsb2JhbABFtieBB4IYAQEBBAEBAQ8BHQo0CwwEAgEIEQMBAQEBCgYXAQYBIAYfCQgBAQQBEggTB4dbAwsLmTGWYg2JSgSKVGOFKmADiEqXa4MagWaCfYFB X-IronPort-AV: E=Sophos;i="4.77,483,1336348800"; d="scan'208";a="96507699" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 27 Jun 2012 15:23:19 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5RFNJOO030643; Wed, 27 Jun 2012 15:23:19 GMT Received: from xmb-rcd-212.cisco.com ([72.163.62.219]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 10:23:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jun 2012 10:23:18 -0500 Message-ID: In-Reply-To: <2012062714341150257645@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOTreflect the consensus from the WG Thread-Index: Ac1ULuflqyFwWR5ISsmPBt69teuiagASVC9A References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com>, <2012062714341150257645@gmail.com> From: "Rajiv Asati (rajiva)" To: "jiangdong345" , "Satoru Matsushima" , "Peng Wu" X-OriginalArrivalTime: 27 Jun 2012 15:23:19.0610 (UTC) FILETIME=[C840A1A0:01CD5478] Cc: Softwires WG , "ian.farrer" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOTreflect the consensus from the WG 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, 27 Jun 2012 15:23:21 -0000 This is a moot argument, as we have seen many protocols (take MPLS for example) that were proposed to do just X, evolved to do X, Y, Z and more. Who would have thought that BGP would be advertising MAC addresses when BGP was first introduced? Let's focus on the operational problems solved (or not solved) by any of our solution sets. I appreciate Ian's email in that light. This will help us evolve our solution sets and have us spend our time in the right direction. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Jiang Dong > Sent: Wednesday, June 27, 2012 2:34 AM > To: Satoru Matsushima; Peng Wu > Cc: Softwires WG; ian.farrer > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does > NOTreflect the consensus from the WG >=20 > Hi, Satoru, >=20 > I believe OSPF never abandon its own essence in order to be a super suite > and do something very strange to cover the use case which can be easily and > clearly done by RIP. >=20 > What's more, MAP is not OSPF, and LW4over6 is not RIP. MAP and LW4over6 > have their own use case when they are originally designed. MAP is not > supposed to do the 1:1 mode in the beginning. >=20 > Regards! > Jiang Dong >=20 > From: Satoru Matsushima > Date: 2012-06-27 12:37 > To: Peng Wu > CC: softwires ; ian.farrer > > Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT > reflect the consensus from the WG On 2012/06/27, at 12:36, Peng Wu wrote: >=20 > >>> Not quite. > >>> I believe that the most motivate to start this work in the wg has > destined MAP to be 'multi-protocol socket v2.0' that's what the former wg > chair wished to. Do you remember that? > >>> > >>> i like the philosophy of "multi-protocol socket". however, i > >>> moderately doubt the "multi-protocol socket v2.0" is a perfect plan > >>> for every cases. in a quite good hotel, we see typically one > >>> 'multi-protocol socket' while a lot of local-standard sockets. i > >>> never think it will make me happy if i see every socket in my room > >>> is *multi-protocol*, occupying much spaces and quite noticeable on > >>> the walls. we need one to deploy somewhere not the only one type to > >>> deploy anywhere. ;-) > >> > >> That point would be an operational matter for deploying any > standardized technology. For example, an operator adopt OSPF to use its > rich routing feature but the network is small, the operator does just area 0 > routing, even OSPF allow inter-area routing for scale. Is an another ospf > specification needed for 'OSPF Area 0 Only Routing'? > > > > Well if I only have a simple network and I uses RIP, you don't make > > OSPF somehow compatible with RIP(or just include RIP with an OSPF > > terminology face? I don't know) and say "hey, just use this super > > suite, don't consider it overloaded, it's for unity!" >=20 > Oh, you don't argue that OSPF covers an use case which is also covered by > RIP. So then why are you arguing that an use case of MAP is eventually same > with the LW46 use case? >=20 > cheers, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sarikaya2012@gmail.com Wed Jun 27 08:31:01 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 44C8121F87C3 for ; Wed, 27 Jun 2012 08:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmOfCS1RinES for ; Wed, 27 Jun 2012 08:31:00 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8721F87C1 for ; Wed, 27 Jun 2012 08:31:00 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1145259ghb.31 for ; Wed, 27 Jun 2012 08:31:00 -0700 (PDT) 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:content-transfer-encoding; bh=ZknBWVYCDigXmptJ7179j2fPcTza5Z/S92sCPJEjHYw=; b=CbPvq1eqrxEIcOd9fZXCDh42Ahy46bkE2xXihmerTyAG9oSIIXV38hnfSyGTR+ZpmH LntHh+82d/IHu/ag8ZYivqE2d2ZqYgDp1Ah1yGUqt6OuD77wz1m8GjgaC67BPhv6DfdO wr1btbSff5Kr2KfVPhk+2NIMjaSleV51wXP+hSZU/Bo1vUYT4GQecIAPZEdzuOYoICO6 1m6lvA53w8AU8g/RUZ8VWehVXyHnKeLuoGLZt5lPVOgdFDMswHIyMH9SmESAfSraGepr Wsar6kPCY7wVZgSeO0C+1breZs1F9kMxqw8TUVXDuFNEpg8ga17Zod2pmuNj6Wrfx/Kh Lg3A== MIME-Version: 1.0 Received: by 10.50.17.230 with SMTP id r6mr2144048igd.63.1340811059796; Wed, 27 Jun 2012 08:30:59 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Wed, 27 Jun 2012 08:30:59 -0700 (PDT) In-Reply-To: <4FE8F609.1040407@jacni.com> References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> Date: Wed, 27 Jun 2012 10:30:59 -0500 Message-ID: From: Behcet Sarikaya To: Jacni Qin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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, 27 Jun 2012 15:31:01 -0000 On Mon, Jun 25, 2012 at 6:36 PM, Jacni Qin wrote: > Re-, > > > On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: >> >> On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin =A0wrote: >>> >>> Hi Behcet, all, >>> >>> >>> On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: >>>> >>>> Folks, >>>> >>>> We have published revised version of our draft on multicast extensions >>>> to DS-Lite at >>>> >>>> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt >>>> >>> It's been discussed on the list and in the 81st meeting, and concluded >>> quite >>> clearly by the WG why this is abandoned. >>> It tunnels the IGMP packets upwards, replicates the multicast traffic >>> "per >>> tunnel", opposite to the property of multicast technology. And these ar= e >>> problems we're trying to solve. >>> >> =A0draft-ietf-softwire-dslite-multicast-02 has nothing to do with >> DS-Lite and therefore it is not a DS-Lite multicast extensions >> document as the charter requires. >> OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates >> multicast into DS-Lite tunnel. >> >> It is not against multicast technology. > > In this way, the efficiency is lost. If operators put the AFTR box deeply= in > the network, far from the end users, as you process the singling messages > and replicate of traffic per tunnel, the network and the box will crash > because of the huge burden. > That's a big IF. Not everybody has to do it the same way. The solution in draft-ietf-softwire-dslite-multicast-02 builds itself something without considering what DS-Lite is doing. As I told you before, DS-Lite unicast is a tunneling technology. If you don't like it it is not DS-Lite multicast to fix this. How many times this should be reminded to you? > >>> There is no necessity to initiate that kind of discussion once again. >>> >> I did not start this discussion. Please check the list. > > > Again please see above, or check the archive and the offlist messages whe= re > we've explained it to you in detail. I also had explained to you that the chairs wanted the two drafts merged in detail. >>>> Regards, >>>> >>>> Behcet From sumanshailesh@gmail.com Wed Jun 27 09:42:55 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 A83AC21F8733 for ; Wed, 27 Jun 2012 09:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82GmmwdyFMjc for ; Wed, 27 Jun 2012 09:42:55 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9BF21F8732 for ; Wed, 27 Jun 2012 09:42:54 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1983629lbb.31 for ; Wed, 27 Jun 2012 09:42:53 -0700 (PDT) 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:content-transfer-encoding; bh=4IwnCxnvnIcQhwbDEbfPE3erii79XPlWBltbjPLwjkc=; b=mNlMkmHwUd8TJf55ccnaVz1Oize+7IzC/N0qCzxhC4mgn6SfMNhGiM1uSUREZavKok eaRtcwKWc5VCsZ6tSHllvF/1DVoz2yXKOv6owYTrakzWyTZv5YkKbo53jkuko9Qg+rQQ s3fxlK0U31c+2oSxbY6vl/suE0QDb8m9B9g2MC1TM7DIQwoWWAgCqrsRRjS3D4Vnw2Fi UPWJ/jSlqmm1VkxWBSIFqHM0F+YpP/Mh7cP+MBrIBoXcpTI6orpdnUO+WC2Bw2D7mxR+ QD0fmYl0t0yR6vDxjMPIY0pQgyLYIclDn+V2aoLSPXoShaNjBOxZSQU/bLIn6f/y3fRY TEIg== MIME-Version: 1.0 Received: by 10.112.104.100 with SMTP id gd4mr9874948lbb.24.1340815373286; Wed, 27 Jun 2012 09:42:53 -0700 (PDT) Received: by 10.114.12.129 with HTTP; Wed, 27 Jun 2012 09:42:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jun 2012 22:12:53 +0530 Message-ID: From: Shailesh Suman To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 27 Jun 2012 16:42:55 -0000 Hi Lee, Thanks for your reply. It clarifies some of my queries now. Hope to see the revison tries to address these points. Regards.. -Shailesh On Tue, Jun 26, 2012 at 7:11 PM, Lee, Yiu wrote= : > Hi Shailesh, > > Thanks very much of reviewing the draft. Please read comments inline: > > On 6/26/12 8:07 AM, "Shailesh Suman" wrote: > >>Hi All, >> >> =A0 =A0 =A0I see few points of this draft need to be addressed to addres= s >>complete solution. >> >>1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and >>uPrefix64) packets silently. There can be scenarios, where some of LAN >>Multicast receivers are supporting native IPv6. How will such packets >>reach the v6 Multicast Receivers, in case they get silently discarded >>by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast >>Receivers in LAN should also be looked into. > > [YL] mB4 is a logical function and should be implemented along side with > normal MLD listener in the same CPE. If the multicast address header > contains mPrefix64 and uPrefix64, it should pass to mB4. Otherwise, the > normal MLD listener will handle it. That sentence tries to prevent normal > multicast message from accidentally passing to mB4. > >> >>2). It is also possible for LAN to have Multicast Originators rather >>than only Multicast Receivers. This solution currently restricts the >>scope to downstream Multicast traffic only and there should be some >>exploration for Originators as well. > > [YL] Our main focus on this to support home user (i.e. IPTV service). You > can find more discussion in > http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. This is wh= y > we limit the scope. We can add more words to expect our motives. > >> >>3). Fragmentation issues can surface for any transition techniques. >>However for DS-Lite (applicable to Unicast traffic only) Path-MTU can >>come for rescue. But for Multicast traffic Path-MTU can not be run. >>This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4 >>respectively. >> >> =A0 =A0I think, addressing these points would be vital for this I.D. > > [YL] I agree. We will propose some text in next revision. > > Thanks, > Yiu > > >> >>Regards >>-Shailesh >> >> >>> Message: 1 >>> Date: Tue, 26 Jun 2012 07:36:41 +0800 >>> From: Jacni Qin >>> To: sarikaya@ieee.org >>> Cc: Softwires-wg , Behcet Sarikaya >>> =A0 =A0 =A0 =A0 >>> Subject: Re: [Softwires] [SPAM] Re: WG last call on >>> =A0 =A0 =A0 =A0draft-ietf-softwire-dslite-multicast-02 >>> Message-ID: <4FE8F609.1040407@jacni.com> >>> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >>> >>> Re-, >>> >>> On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: >>>> On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin =A0wrote: >>>>> Hi Behcet, all, >>>>> >>>>> >>>>> On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: >>>>>> Folks, >>>>>> >>>>>> We have published revised version of our draft on multicast >>>>>>extensions >>>>>> to DS-Lite at >>>>>> >>>>>> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.tx= t >>>>>> >>>>> It's been discussed on the list and in the 81st meeting, and >>>>>concluded quite >>>>> clearly by the WG why this is abandoned. >>>>> It tunnels the IGMP packets upwards, replicates the multicast traffic >>>>>"per >>>>> tunnel", opposite to the property of multicast technology. And these >>>>>are >>>>> problems we're trying to solve. >>>>> >>>> =A0 draft-ietf-softwire-dslite-multicast-02 has nothing to do with >>>> DS-Lite and therefore it is not a DS-Lite multicast extensions >>>> document as the charter requires. >>>> OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates >>>> multicast into DS-Lite tunnel. >>>> >>>> It is not against multicast technology. >>> In this way, the efficiency is lost. If operators put the AFTR box >>> deeply in the network, far from the end users, as you process the >>> singling messages and replicate of traffic per tunnel, the network and >>> the box will crash because of the huge burden. >>> >>>>> There is no necessity to initiate that kind of discussion once again. >>>>> >>>> I did not start this discussion. Please check the list. >>> >>> Again please see above, or check the archive and the offlist messages >>> where we've explained it to you in detail. >>> >>> >>> Cheers, >>> Jacni >>> >>>> >>>> Regards. >>>> >>>> Behcet >>>> >>>>> Cheers, >>>>> Jacni >>>>> >>>>> >>>>>> We think that this draft should be part of >>>>>> draft-ietf-softwire-dslite-multicast. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Behcet >>>>>> _______________________________________________ >>>>>> 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 wdec.ietf@gmail.com Wed Jun 27 10:37: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 D6B2D21F86C9 for ; Wed, 27 Jun 2012 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTwV2lrTkLWQ for ; Wed, 27 Jun 2012 10:37:02 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA97821F86A1 for ; Wed, 27 Jun 2012 10:37:01 -0700 (PDT) Received: by yenq13 with SMTP id q13so1266850yen.31 for ; Wed, 27 Jun 2012 10:37:01 -0700 (PDT) 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=Lypl6mJbWSufJu3DIdfAE6WnbQh2BhSYEYHk9n7pWkQ=; b=qVGNbghd8RdGWbZlAlZBgXxipSTxp4vpkMTTQMFld8yAJCjAIkjbwGbRt9Cc8a2gzG cGKBYL1AnJ+rXMFsjbPxS0EWOEAvYsrmfE/6bdfsuuhPyG36Pe9Zqqlo/mhBlK+ntWzG 4H8Pq5RMAMP2SjJY6LbomcxgsXHMlUCDNpYnnoA15QA7s4mPIHVJ7aXM0JhSuRsJYTLt UwCLUZO8EywrbFT2qEa+fbR58rUX5dN057RtvcuQBKf/WzN4xnrTcMtuJ7hv5kzeqK55 nYM2r3PZIJdMDaYeNcNYpVhw573IKXxoh7WPu7QiARHk8V4eihuhCpEvb8Nut6CVrcXY fprw== MIME-Version: 1.0 Received: by 10.236.46.74 with SMTP id q50mr24242782yhb.30.1340818621490; Wed, 27 Jun 2012 10:37:01 -0700 (PDT) Received: by 10.100.46.6 with HTTP; Wed, 27 Jun 2012 10:37:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jun 2012 19:37:01 +0200 Message-ID: From: Wojciech Dec To: Maoke Content-Type: multipart/alternative; boundary=20cf303b4425a4651304c377a907 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 27 Jun 2012 17:37:04 -0000 --20cf303b4425a4651304c377a907 Content-Type: text/plain; charset=ISO-8859-1 Hello Maoke, inline... On 27 June 2012 12:55, Maoke wrote: > hi Woj, > > thanks a lot for the clarification. > > 2012/6/27 Wojciech Dec > >> Hi Maoke, >> >> inline... >> >> On 27 June 2012 05:28, Maoke wrote: >> >>> hi dear authors, >>> >>> as the map-00 draft contains the normative 1:1 mode statement that is >>> new in comparison to the previous versions, i'd like to ask some technical >>> questions in order to clarify the understanding. >>> >>> Section 4. page 9: >>> >>> MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a >>> MAP domain per subscriber, and the CE is configured in hub and spoke >>> mode, with only a DMR and no other mapping rules. This allows for a >>> mode where the BR has one rule per subscriber and the provisioning of >>> IPv4 address or prefix and port sets is independent of the End-User >>> IPv6 prefix. >>> >>> Question #1: who is a "subscriber"? the definition is missing. and >>> relatedly, what is the protocol for the subscription? the specification on >>> the protocol is missing too. >>> >> >> Answer 1: Subscriber = MAP CE. We will clarify the term. >> > > got it. > > >> >>> Question #2: what is the relationship between 1:1 mode, encapsulation >>> mode, translation mode, hub&spoke mode, mesh mode? are they independent to >>> each other, exclusively or not, somehow orthogonal or not? the >>> specification on the "mode" is missing. >>> >> >> Answer 2: mode = forwarding mode, also known as transport mode. There are >> two of these, translation and encapsulation. No relation between the rest >> of the things you mention >> > > okay. then please clearly revise the wording to avoid confusing the > readers. only after the terms/wordings are revised, the MAP deployment is > able to follow these well-defined words and terms. > > >> >> >>> Question #3: what is the resource for deployment of a "MAP domain"? the >>> MAP spec never define that. however, we kept understanding that the >>> resource for a "MAP domain" includes: >>> - an IPv4 prefix (with prefix length 32 or less) shared by >>> CEs in this domain >>> - an IPv6 prefix (with prefix length 64 or less) delegated >>> to the CEs in this domain with a /64 (or shorter) per CE (as the basic >>> model of prefix d >>> the newly introduced "1:1 mode" obviously abandons this >>> understanding, then an explicit definition on the resource of a "MAP >>> domain" is requested. this is the origin and essential starting point of >>> the MAP deployment. >>> >> >> Answer 3: What do you mean by resource for deployment?? It has, and >> always has been an IPv6 prefix and an IPv4 address. This is the same in >> *all* of this solution space. The split in terms of how one arrives at the >> IPv4 address and port-range has always been variable in MAP. >> Additional point: There is no newly introduced 1:1 mode, as the spec >> hasn't changed. Folks who implemented according to the previous spec, whihc >> you seem to indicate had no 1:1 mode see no difference. >> > > as you clarified CE = subscriber, it is ok. but a new question: > > question #3.1: in the 1:1 mode, how long the PSID is? how long the > EA-bits? i understand the bit relationship described in the Figure 7 is the > native property of the MAP algorithm. but it looks to me that 1:1 mode has > nothing related to this figure. it breaks the relation o = p + q. it is > hard to accept that the 1:1 mode is not newly introduced alien. even an > alien were welcome, i would like to suggest the authors prepare a text at > Figure 7 stating "this is nosense to the 1:1 mode". > The relation of o = p + q holds, for all values of p and q giving 0 <= o <=48. Given that we have resticted MAP to positive values of p and q, although negative were suggested, that provides you the range of p and q. > > question #3.2: then about the rule, for ONE rule, i see only, in Section > 5: > * Rule IPv6 prefix (including prefix length) > > * Rule IPv4 prefix (including prefix length) > > * Rule EA-bits length (in bits) > > * Rule Port Parameters (optional) > > (as the 5th "forwarding mode" has been confirmed as a domain configuration) > > i don't see there is a PSID value in this tuple, nor i see it in the > example in Sec 5.2, 5.3 for the Given rules. > Well, if you look at the info list passed in an FMR you will see that everything is there allowing the derivation of a PSID for a given destination if/when needed and/or the port range from a given FMR. In the case of EA=0, the prefix is enough for forwarding. > > if Section 5 is not applied to the 1:1 mode, an explicit text "This > section is nonsense to the 1:1 mode" is required. if a PSID value is to be > added into the rule, i understand it is hard to call "not newly introduced" > stuff. > As explained, it is not :-) And again, I bring your attention to what several implementers said about this, all of whom used previous drafts as their spec. > >> Disabling the 1:1 mode would actually require a spec change. >> > >>> Section 5. page 10: >>> >>> * Forwarding mode >>> >>> Question #4: this appears twice at the definition of BMR and DMR, >>> respectively. though Wojieich and Remi has discussed that in another >>> thread, i would like to confirm: is this mode a domain configuration >>> parameter or a rule parameter? >>> >> >> Answer 4: Confirmed, intent is for it to be per domain. >> >>> >>> Question #5: does this "forwarding mode" is a enumerate type of {MAP-T, >>> MAP-E, 1:1, hub&spoke, mesh} or else, e.g., {MAP-T, MAP-E} x {1:1, N:1} x >>> {hub&spoke, mesh}, where the "x" is the operator for de Cartesian product >>> of sets? (related to #2) >>> >> >> Answer 5: No need to enumerate, because there is no relation between >> these (answered above) >> > > question #5.1: do you mean, for example, when i decided the domain forward > mode, e.g. MAP-T, it is fine that i deploy 1:1 for CE.A while N:1 for CE.B, > right? please confirm this. > Each CE is configured independently. In case you mean to ask about two CPEs in the same domain having different domain configurations (eg BMR), I would like to point out that this makes them be in separate domains... > > >> >>> Section 7.1 page 19: >>> >>> In 1:1 mode, the MAP CE is provisioned with only a Default Mapping >>> Rule, and the full IPv4 address/prefix and port range is provisioned >>> using the DHCP option. >>> >>> Question #6: is the CE or the subscriber the receiver of the "full IPv4 >>> address/prefix and port range" (correction: port set) to be provisioned? or >>> does it mean a CE is a subscriber itself in the 1:1 mode? >>> >> >> Woj> MAP CE. >> >>> >>> Section 7.3 page 19: >>> >>> A MAP-E CE provisioned with only a Default Mapping Rule, as in the >>> 1:1 case, and with no IPv4 address and port range configured by other >>> means, MUST disable its NAT44 functionality. >>> >>> Question #7: this text is contradictory with Section 7.1. is the DHCP >>> option a sort of "other means" or not, or there's something out of scope of >>> this draft? >>> >> >> Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing in >> the architecture prevents any other provisioning mechanisms to be used incl >> dhcpv4, snmp, etc. >> > > still confusing. > Question #7.1: is what the MAP *can* use a part of MAP spec suite, e.g., > MAP-DHCP? please clarify explicitly: in the condition of Section 7.1, NAT44 > must be disable or not? > MAP is not defined or restricted to use of dhcpv6. As I state above, if one wishes to use any other provisioning mechanism, then that is fine. > > >> >>> Question #8: what is the consequence of disabling the NAT44 >>> functionality on CE when a subscriber having a PSID of a share IPv4 address >>> is running behind that CE as a 1:1 mode domain? >>> >> >> Woj> That is not possible. We can be clearer in saying that if the CPE >> has no IPv4 address configured then NAT44 is to be disabled (kind of >> obvious) >> > > much more confusing. > Question #8.1: please clarify if this CPE has no IPv4 stack enabled or has > only no IPv4 address configured (statically or dynamically). how it works? > Sorry, but your question doesn't appear to be quite logical. You asked, "what is the consequence of disabling NAT44 functionality" in the context of draft text which effectively says (which could be clearer) "disable NAT44 if there is no IPv4 address". Perhaps you could clarify what you see as running NAT44 without an IPv4 address, and then we can talk about its consequences (it does not appear to be MAP issue however). Regards, Woj. > > >> >>> before all of the above questions and further questions possibly to be >>> generated during the discussion are fully clarified, i cannot help but >>> gently show my disagreement on putting the current draft as working group >>> result. i also hope the MAP spec authors kindly understand with so many >>> uncertainty modifying MAP deployment draft to fit the MAP spec is a >>> mission-impossible for the time being. >>> >> >> Woj> What is the basis of your gentle disagreement, and its timing now? >> The merged of the drafts was discussed previously, and circulated on the >> design team of which you are a apart of. It appears your comments relate to >> the supposed controversial 1:1 non-normative text. >> > > i only talk about the aspect of technical maturity. it is not unreasonable > that i disagree the status of being WG doc even if there might be only me > who hasn't understood. > > however, as you raised this question on the procedural justice, i have to > point out the following fact: > > the mdt-named MAP spec was circulated, according to my mailbox record > (maybe i missed some), until March 30, with the last message sent out by > Leaf. however, the 1:1 mode is added on May 31st 10:47:11 timezone +0200 > according to the git log and git diff and the next day, June 1st, it > becomes the published version, which appears to IETF draft repos on June > 8th. after May 30th, nobody among the authors called for review. > > i may imagine that, maybe, the authors were not aware that the 1:1 mode > text IS a sort of change that need to review. but what do you suggest the > "right timing" if it is not NOW?! > > i hope i need to point out the above fact only once and never talk on it > again. i also hope it were the case that the authors called for review but > i missed. it is not my purpose to debate on such kind of trivials -- > wasting life of you, of me and of all of ours, nor i care what is the > normative text what is not. i only focus on the technical issue. whatever > the timing is, i am against any confusion and misleading. > > - maoke > --20cf303b4425a4651304c377a907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Maoke,

inline...

On 27 June = 2012 12:55, Maoke <fibrib@gmail.com> wrote:
hi Woj,=A0

thanks a lot for the clarifica= tion.=A0

2012/6/27 Wo= jciech Dec <wdec.ietf@gmail.com>
Hi Maoke,

inline...

On 27 June 2012 05:28, Maoke <fibrib@gmail.com>= ; wrote:
hi dear authors,=A0

as the map-00 draft c= ontains the normative 1:1 mode statement that is new in comparison to the p= revious versions, i'd like to ask some technical questions in order to = clarify the understanding.=A0

Section 4. page 9:

MAP can als= o be provisioned in 1:1 mode. In 1:1 mode the BR has a
MAP domain pe= r subscriber, and the CE is configured in hub and spoke
mode, with on= ly a DMR and no other mapping rules. This allows for a
mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User
= IPv6 prefix.

Question #1: who is a "subscr= iber"? the definition is missing. and relatedly, what is the protocol = for the subscription? the specification on the protocol is missing too.

Answer 1: Subscriber =3D MAP CE. We will clarif= y the term.

got it. <= /div>
=A0

Question #2: what is the relationship between 1:1 mode,= encapsulation mode, translation mode, hub&spoke mode, mesh mode? are t= hey independent to each other, exclusively or not, somehow orthogonal or no= t? the specification on the "mode" is missing.=A0

Answer 2: mode =3D forwarding mode, also known = as transport mode. There are two of these, translation and encapsulation. N= o relation between the rest of the things you mention

okay. then please clearly revise the wording to a= void confusing the readers. only after the terms/wordings are revised, the = MAP deployment is able to follow these well-defined words and terms.=A0
=A0

Question #3: what is the resource for deployment of a &= quot;MAP domain"? the MAP spec never define that. however, we kept und= erstanding that the resource for a "MAP domain" includes:=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0- an IPv4 prefix (with prefix length 32 or = less) shared by CEs in this domain
=A0 =A0 =A0 =A0 =A0 =A0 =A0- a= n IPv6 prefix (with prefix length 64 or less) delegated to the CEs in this = domain with a /64 (or shorter) per CE (as the basic model of prefix d
=A0 =A0 =A0 =A0 =A0 =A0 =A0the newly introduced "1:1 mode" o= bviously abandons this understanding, then an explicit definition on the re= source of a "MAP domain" is requested. this is the origin and ess= ential starting point of the MAP deployment.=A0

Answer 3: What do you mean by resource for depl= oyment?? It has, and always has been an IPv6 prefix and an IPv4 address. Th= is is the same in *all* of this solution space. The split in terms of how o= ne arrives at the IPv4 address and port-range has always been variable in M= AP.
Additional point: There is no newly introduced 1:1 mode, as the spec hasn&#= 39;t changed. Folks who implemented according to the previous spec, whihc y= ou seem to indicate had no 1:1 mode see no difference.

as you clarified CE =3D subscriber, it is ok. but= a new question:=A0

question #3.1: in the 1:1 mode= , how long the PSID is? how long the EA-bits? i understand the bit relation= ship described in the Figure 7 is the native property of the MAP algorithm.= but it looks to me that 1:1 mode has nothing related to this figure. it br= eaks the relation o =3D p + q. it is hard to accept that the 1:1 mode is no= t newly introduced alien. even an alien were welcome, i would like to sugge= st the authors prepare a text at Figure 7 stating "this is nosense to = the 1:1 mode".=A0

The relation of o =3D p + q holds, for all valu= es of p and q giving 0 <=3D o <=3D48. Given that we have resticted MA= P to positive values of p and q, although negative were suggested, that pro= vides you the range of p and q.
=A0

question #3.2: then about the rule, for ONE rule, i see= only, in Section 5:=A0
* Rule IPv6 prefix (including pre= fix length)

* Rule IPv4 prefix (including prefix length)

* Rule EA-bits length (in bits)

* Rule Port Para= meters (optional)

(as the 5th "forwarding mod= e" has been confirmed as a domain configuration)

i don't see there is a PSID value in this tuple, nor i see it in t= he example in Sec 5.2, 5.3 for the Given rules.=A0
=

Well, if you look at the info list passed in an FMR you will see t= hat everything is there allowing the derivation of a PSID for a given desti= nation if/when needed and/or the port range from a given FMR. In the case o= f EA=3D0, the prefix is enough for forwarding.=A0

if Section 5 is not applied to the 1:1 mode, an= explicit text "This section is nonsense to the 1:1 mode" is requ= ired. if a PSID value is to be added into the rule, i understand it is hard= to call "not newly introduced" stuff. =A0

As explained, it is not :-) And again, I bring = your attention to what several implementers said about this, all of whom us= ed previous drafts as their spec.=A0

=A0
=A0Disabling the 1:1 mode would actually require a spec change.=A0
<= /div>

Section 5. page 10:

=A0 * = Forwarding mode

Question #4: this appears twice a= t the definition of BMR and DMR, respectively. though Wojieich and Remi has= discussed that in another thread, i would like to confirm: is this mode a = domain configuration parameter or a rule parameter?

Answer 4: Confirmed, intent is for it to be per= domain.

Question #5: does this "forwarding mode" is a= enumerate type of {MAP-T, MAP-E, 1:1, hub&spoke, mesh} or else, e.g., = {MAP-T, MAP-E} x {1:1, N:1} x {hub&spoke, mesh}, where the "x"= ; is the operator for de Cartesian product of sets? (related to #2)

Answer 5: No need to enumerate, because there i= s no relation between these (answered above)

question #5.1: do you mean, for example, when i dec= ided the domain forward mode, e.g. MAP-T, it is fine that i deploy 1:1 for = CE.A while N:1 for CE.B, right? please confirm this.=A0

Each CE is configured independently. In case yo= u mean to ask about two CPEs in the same domain having different domain con= figurations (eg BMR), I would like to point out that this makes them be in = separate domains...=A0
=A0

Section 7.1 page 19:

In 1:= 1 mode, the MAP CE is provisioned with only a Default Mapping
Rule, a= nd the full IPv4 address/prefix and port range is provisioned
using t= he DHCP option.

Question #6: is the CE or the subscriber the rece= iver of the "full IPv4 address/prefix and port range" (correction= : port set) to be provisioned? or does it mean a CE is a subscriber itself = in the 1:1 mode?

Woj>=A0 MAP CE.

Section 7.3 page 19:

A MAP-E C= E provisioned with only a Default Mapping Rule, as in the
1:1 case, a= nd with no IPv4 address and port range configured by other
means, MUS= T disable its NAT44 functionality.

Question #7: this text is contradictory with Section 7.= 1. is the DHCP option a sort of "other means" or not, or there= 9;s something out of scope of this draft?=A0

Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing i= n the architecture prevents any other provisioning mechanisms to be used in= cl dhcpv4, snmp, etc.

still confusing.=A0
Question #7.1: is what the MAP *can* use a pa= rt of MAP spec suite, e.g., MAP-DHCP? please clarify explicitly: in the con= dition of Section 7.1, NAT44 must be disable or not?=A0

MAP is not defined or restricted to use of dhcpv6. As I state abov= e, if one wishes to use any other provisioning mechanism, then that is fine= .
=A0

Question #8: what is the consequence of disabling the N= AT44 functionality on CE when a subscriber having a PSID of a share IPv4 ad= dress is running behind that CE as a 1:1 mode domain?=A0

Woj>=A0 That is not possible.=A0 We can be clearer in say= ing that if the CPE has no IPv4 address configured then NAT44 is to be disa= bled (kind of obvious)

much more confusing.=A0
Question #8.1: please clarify if this CPE has no IPv4 stack enabled or= has only no IPv4 address configured (statically or dynamically). how it wo= rks?=A0

Sorry, but your question doesn'= ;t appear to be quite logical. You asked, "what is the consequence of = disabling NAT44 functionality" in the context of draft text which effe= ctively says (which could be clearer) "disable NAT44 if there is no IP= v4 address". Perhaps you could clarify what you see as running NAT44 w= ithout an IPv4 address, and then we can talk about its consequences (it doe= s not appear to be MAP issue however).

Regards,
Woj.
=A0

before all of the above questions and further questions= possibly to be generated during the discussion are fully clarified, i cann= ot help but gently show my disagreement on putting the current draft as wor= king group result. i also hope the MAP spec authors kindly understand with = so many uncertainty modifying MAP deployment draft to fit the MAP spec is a= mission-impossible for the time being.=A0

Woj> What is the basis of your gentle disagr= eement, and its timing now? The merged of the drafts was discussed previous= ly, and circulated on the design team of which you are a apart of. It appea= rs your comments relate to the supposed controversial 1:1 non-normative tex= t.

i only talk about the as= pect of technical maturity. it is not unreasonable that i disagree the stat= us of being WG doc even if there might be only me who hasn't understood= .=A0

however, as you raised this question on the procedural = justice, i have to point out the following fact:=A0

=A0the mdt-named MAP spec was circulated, according to my mailbox record = (maybe i missed some), until March 30, with the last message sent out by Le= af. however, the 1:1 mode is added on May 31st 10:47:11 =A0timezone +0200 a= ccording to the git log and git diff and the next day, June 1st, it becomes= the published version, which appears to IETF draft repos on June 8th. afte= r May 30th, nobody among the authors called for review.=A0

i may imagine that, maybe, the authors were not aware t= hat the 1:1 mode text IS a sort of change that need to review. but what do = you suggest the "right timing" if it is not NOW?!=A0

i hope i need to point out the above fact only once and= never talk on it again. i also hope it were the case that the authors call= ed for review but i missed. it is not my purpose to debate on such kind of = trivials -- wasting life of you, of me and of all of ours, nor i care what = is the normative text what is not. i only focus on the technical issue. wha= tever the timing is, i am against any confusion and misleading.=A0

- maoke

--20cf303b4425a4651304c377a907-- From stig@venaas.com Wed Jun 27 13:08:23 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 5F60A21F861E for ; Wed, 27 Jun 2012 13:08:23 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ24ACXK2TPm for ; Wed, 27 Jun 2012 13:08:22 -0700 (PDT) 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 AC6DA21F861D for ; Wed, 27 Jun 2012 13:08:22 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 5D88C7FE2; Wed, 27 Jun 2012 22:08:20 +0200 (CEST) Message-ID: <4FEB6831.5060100@venaas.com> Date: Wed, 27 Jun 2012 13:08:17 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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, 27 Jun 2012 20:08:23 -0000 FWIW, here is my take on this. On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: [...] > That's a big IF. Not everybody has to do it the same way. > > The solution in draft-ietf-softwire-dslite-multicast-02 > builds itself something without considering what DS-Lite is doing. > As I told you before, DS-Lite unicast is a tunneling technology. If > you don't like it it is not DS-Lite multicast to fix this. > How many times this should be reminded to you? draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing specific to DS-Lite, and I've been saying that the draft should be updated to reflect that. However, even though it is generic, I think it is a good solution for use in DS-Lite deployments (in addition to many other deployments). Whether additional solutions are needed for DS-Lite is something the WG should consider. Maybe it already has, I haven't paid enough attention. Stig From wdec.ietf@gmail.com Wed Jun 27 13:18: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 9616721F8594 for ; Wed, 27 Jun 2012 13:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWfI7zdzDDIp for ; Wed, 27 Jun 2012 13:18:08 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 63DC521F854E for ; Wed, 27 Jun 2012 13:18:04 -0700 (PDT) Received: by qcmt36 with SMTP id t36so804992qcm.15 for ; Wed, 27 Jun 2012 13:18:03 -0700 (PDT) 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=NhlT2c1+N1ggrWPAGYrImbHPCQXtsc1MUCXhZYiEsKw=; b=pvQ2lu6aqnq0wguIicsfJYAaQVNIJ/o9abEHwApKgEHVF5NlDAraUbEmOfoNpGXrWw USFWBAjCCTg71DMzkermUgnpSYVaUTrgRhgEE38smCBB+SfIK1APylL/iuR2GRm+/iiG KwXizLm7ysLJYc8X4wIP/7eWdrqekyQ4XRIYC774CYxULnCxpPna0O2D9q1JHUpzv082 c0GO6tcnokvmx6W3sZp3hsKfdMhvedHlx7hlcAlpSL91MPtm5XuRBbjBtvutK2ZCZPF8 Ht3dht+4AwNenZDEuviqLCpTs9os8o/KJXYLAluqcGQPByjF/uWktE0LL/1GxQiCOicu IDPQ== MIME-Version: 1.0 Received: by 10.224.218.73 with SMTP id hp9mr17400752qab.67.1340828283749; Wed, 27 Jun 2012 13:18:03 -0700 (PDT) Received: by 10.229.127.231 with HTTP; Wed, 27 Jun 2012 13:18:03 -0700 (PDT) In-Reply-To: <4FEB6831.5060100@venaas.com> References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> Date: Wed, 27 Jun 2012 22:18:03 +0200 Message-ID: From: Wojciech Dec To: Softwires-wg Content-Type: multipart/alternative; boundary=20cf300fb3d78ec6cb04c379e98b Cc: Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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, 27 Jun 2012 20:18:08 -0000 --20cf300fb3d78ec6cb04c379e98b Content-Type: text/plain; charset=ISO-8859-1 +1 The name and references to ds-lite terminology in the draft are misleading and should be revised. On 27 June 2012 22:08, Stig Venaas wrote: > FWIW, here is my take on this. > > > On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: > [...] > > That's a big IF. Not everybody has to do it the same way. >> >> The solution in draft-ietf-softwire-dslite-**multicast-02 >> builds itself something without considering what DS-Lite is doing. >> As I told you before, DS-Lite unicast is a tunneling technology. If >> you don't like it it is not DS-Lite multicast to fix this. >> How many times this should be reminded to you? >> > > draft-ietf-softwire-dslite-**multicast-02 is a generic solution, nothing > specific to DS-Lite, and I've been saying that the draft should be > updated to reflect that. > > However, even though it is generic, I think it is a good solution for > use in DS-Lite deployments (in addition to many other deployments). > > Whether additional solutions are needed for DS-Lite is something the > WG should consider. Maybe it already has, I haven't paid enough > attention. > > Stig > > ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > --20cf300fb3d78ec6cb04c379e98b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

The name and references to ds-lite terminology in the draft are m= isleading and should be revised.

On 27 Ju= ne 2012 22:08, Stig Venaas <stig@venaas.com> wrote:
FWIW, here is my take on this.


On 6/27/2012 8:30 AM, Behcet Sarikaya wrote:
[...]

That's a big IF. Not everybody has to do it the same way.

The solution in draft-ietf-softwire-dslite-multicast-02
builds itself something without considering what DS-Lite is doing.
As I told you before, DS-Lite unicast is a tunneling technology. If
you don't like it it is not DS-Lite multicast to fix this.
How many times this should be reminded to you?

draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothi= ng
specific to DS-Lite, and I've been saying that the draft should be
updated to reflect that.

However, even though it is generic, I think it is a good solution for
use in DS-Lite deployments (in addition to many other deployments).

Whether additional solutions are needed for DS-Lite is something the
WG should consider. Maybe it already has, I haven't paid enough
attention.

Stig

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

--20cf300fb3d78ec6cb04c379e98b-- From Tina.Tsou.Zouting@huawei.com Wed Jun 27 14:08: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 CB8C521F862F for ; Wed, 27 Jun 2012 14:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.558 X-Spam-Level: X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW+AMM3Y3qCs for ; Wed, 27 Jun 2012 14:08:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9132621F85CD for ; Wed, 27 Jun 2012 14:08:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHN74484; Wed, 27 Jun 2012 17:08:02 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 14:06:42 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.109]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 27 Jun 2012 14:06:36 -0700 From: Tina TSOU To: "Softwires@Ietf. Org" Thread-Topic: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.txt Thread-Index: AQHNVKigWZyHHfMa2kWg8q0AVKjAQZcOqCim Date: Wed, 27 Jun 2012 21:06:35 +0000 Message-ID: <47B0CB3A-FA26-4CE8-9805-EEEFBC0683CF@huawei.com> References: <20120627210541.24061.61162.idtracker@ietfa.amsl.com> In-Reply-To: <20120627210541.24061.61162.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_47B0CB3AFA264CE89805EEEFBC0683CFhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.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: Wed, 27 Jun 2012 21:08:04 -0000 --_000_47B0CB3AFA264CE89805EEEFBC0683CFhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For your comments. Tina Begin forwarded message: From: > Date: June 27, 2012 2:05:41 PM PDT To: > Cc: >, >, > Subject: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.tx= t A new version of I-D, draft-tsou-softwire-bfd-ds-lite-03.txt has been successfully submitted by Tina Tsou and posted to the IETF repository. Filename: draft-tsou-softwire-bfd-ds-lite Revision: 03 Title: DS-Lite Failure Detection and Failover Creation date: 2012-06-27 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-tsou-softwire-bf= d-ds-lite-03.txt Status: http://datatracker.ietf.org/doc/draft-tsou-softwire-bfd-ds= -lite Htmlized: http://tools.ietf.org/html/draft-tsou-softwire-bfd-ds-lite= -03 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-b= fd-ds-lite-03 Abstract: In DS-Lite, the tunnel is stateless, not associated with any state information, and no failure detection and failover mechanism is available. This makes it difficult to manage and diagnose if there is a problem. This draft analyzes the applicability of some of the possible solutions. The IETF Secretariat --_000_47B0CB3AFA264CE89805EEEFBC0683CFhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
For your comments.

Tina

Begin forwarded message:

From: <internet-= drafts@ietf.org>
Date: June 27, 2012 2:05:41 PM PDT
To: <tina.tsou.zo= uting@huawei.com>
Cc: <brandon.lijian@= huawei.com>, <repenno@cisco.= com>, <j.= schoenwaelder@jacobs-university.de>
Subject: New Version Notification for draft-tsou-softwire-bfd-ds-= lite-03.txt


A new version of I-D, draft-tsou-softwire-bfd-ds-lite-03.txt has been successfully submitted by Tina Tsou and posted to the=
IETF repository.

Filename:     draft-tsou-softwire-bfd-ds-lite
Revision:     03
Title:         DS-Lite Failure Detection and Fail= over
Creation date:     2012-06-27
WG ID:         Individual Submission
Number of pages: 9
URL:           &nbs= p; http://www.ietf.org/internet-drafts/draft-tsou-softwire= -bfd-ds-lite-03.txt
Status:          http:/= /datatracker.ietf.org/doc/draft-tsou-softwire-bfd-ds-lite
Htmlized:        http://tools.ietf.= org/html/draft-tsou-softwire-bfd-ds-lite-03
Diff:           &nb= sp;http://tools.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-bfd-ds= -lite-03

Abstract:
  In DS-Lite, the tunnel is stateless, not associated with = any state
  information, and no failure detection and failover mechan= ism is
  available.  This makes it difficult to manage and di= agnose if there
  is a problem.  This draft analyzes the applicability= of some of the
  possible solutions.




The IETF Secretariat
--_000_47B0CB3AFA264CE89805EEEFBC0683CFhuaweicom_-- From bingxuere@gmail.com Wed Jun 27 18:02:32 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 4D38111E8132 for ; Wed, 27 Jun 2012 18:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+kF1wwgQIlN for ; Wed, 27 Jun 2012 18:02:30 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8FF11E811E for ; Wed, 27 Jun 2012 18:02:27 -0700 (PDT) Received: by yhfq11 with SMTP id q11so1832053yhf.15 for ; Wed, 27 Jun 2012 18:02:26 -0700 (PDT) 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=0Cu4vDEOXstoGEk/LN6jPd+FfB8E/wPmmoApkAhO6zQ=; b=ExSXqIgyzaF6t3mub9QnNaY3/ZIqWJfVw66vwdPaI2lOCFv0IYE3t81JefTqFyWXu8 PZenYC6wf8b+r3azeJ7K3e/HwuIh1x+U+4crPaTH0qyBwz5FLB/3/q1mw7GiFL/qRUHS lW4pB0WTzYXJPzbCU5SGXzYLierV2IAWkIU/huuzxaoRYdCDBxmq+Z4VBmz21dujG9kQ x2Bv7wI/KixvsYxqrherbupO4PH2VQV7TFUBysCyqOd4yVSzuwCAM9QsglnsOPOiBSiO Ok6WAC8Rv0u36oG5FkOzKuQwUqboOxyznvL7UzTp2AXHJ0zZFU7p0WjK1fv5YeS3p+/5 qtgQ== Received: by 10.50.10.226 with SMTP id l2mr2536392igb.54.1340845346129; Wed, 27 Jun 2012 18:02:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 27 Jun 2012 18:01:41 -0700 (PDT) In-Reply-To: <459A6E94-9534-4203-940A-B04891B49DAB@ipinfusion.com> References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <459A6E94-9534-4203-940A-B04891B49DAB@ipinfusion.com> From: Qiong Date: Thu, 28 Jun 2012 09:01:41 +0800 Message-ID: To: Tetsuya Murakami Content-Type: multipart/alternative; boundary=14dae93404098e081d04c37de2ee Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 28 Jun 2012 01:02:32 -0000 --14dae93404098e081d04c37de2ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tetsuya, With regard to implementaion, what did you configure in BR ? In the specification, it says the BR and CE MUST be configured with the following MAP elements. o The End-User IPv6 prefix (Part of the normal IPv6 provisioning). o The Basic Mapping Rule and optionally the Forwarding Mapping Rules o The Default Mapping Rule with the BR IPv6 prefix or address o Hub and spoke mode or Mesh mode. Did you configure PSID explicitly ? If yes, the implementation does not consistent with the specification. If not, it can not been applied to the so-called 1:1 mode. Best wishes Qiong On Tue, Jun 26, 2012 at 6:50 AM, Tetsuya Murakami < Tetsuya.Murakami@ipinfusion.com> wrote: > +1. > > In fact, we have already done the implementation prior to the current > MAP draft. But there is no change in our implementation in order to suppo= rt > the current draft. In addition, our implementation has no limitation for > the number of mapping rules. It depends on the available memory size only= . > So, our implementation can allow 1:1 as well as N:1. > > Thanks, > Tetsuya Murakami > > On 2012/06/25, at 7:24, Wojciech Dec wrote: > > Hi, > > taking a step back to discuss some items in more detail, and hopefully > move this discussion forward: > > 1. Domain size > The MAP architecture does not prescribe the size of a domain, and neither > does it prescribe the number of rules to be used. There is nothing in the > technology, except vendor implementation limits or practical sense (or > both), to prevent MAP domains from defining 1 domain =3D 1 CPE. This was = a > day 1 characteristic of MAP drafts. > Choosing to deploy or implement MAP with a configuration supporting 1 > rule, 100 rules or 100k rules or domains is a vendor's and/or operator's > choice. Nobody is stating that deployment is to be limited to X rules, no= r > that a near infinite number of rules is reasonable. These are general > points that apply to DS-lite state as well as the "Light Weight 4 over 6" > or "stateless deterministic NAT", and pretty much any technology for that > matter. > > 2. Stateless DOES NOT mean configuration-less > There appears to be confusion between the concept of stateless and > configuration-less. MAP domains are based on configured rules, that are > provisioned/applied through means that are currently outside the scope of > Softwire drafts - this is configuration state, and this was and continues > to be a characteristic of MAP. > Further more, unlike some of the other proposals, MAP allows to optimize > the amount of configuration needed in cases where this is viable. In othe= r > words, MAP does NOT exclusively force 1:1 rule configuration, but also > allows N:1. > > 3. Stateless has no data plane induced state > A major difference between stateless (eg MAP) and stateful (eg Carrier > Grade NAT44/Ds-Lite) solutions is that the latter are characterised by > dynamic core node forwarding state that is directly driven by user > data-plane traffic (eg new IP flows). MAP does not rely on such dynamic > state, never did. > > 4. No change of MAP spec > The updated MAP draft does not change the MAP architecture nor its > technical underpinnings. In fact there are no changes, bar editorial to t= he > normative parts of MAP, something that is proven by existing > implementations prior to this draft supporting the current draft. A few > individuals appear to object to new descriptive text which highlights the > usage of MAP, eg in 1:1. Removing that text will not change the matter th= at > MAP allows such usage. Prohibiting such use by specification would actual= ly > require a spec change, besides being unreasonable. > > 5. What is the problem? > We're pleased to see a growing understanding of MAP's applicability to > solve problems, incl v4-v6 address independence, when needed. Given that > the emails on this thread do not appear to bring forward any technical > issues with the MAP solution, could we know WHY we need other solutions t= o > the problem, or what is the problem that remains to be solved? > > Taking the liberty to speak on behalf of the other MAP authors, I would > like to say that we all remain open for collaboration with all WG members > in terms of arriving at a minimal set of reasonable solutions that solve > problems that the community cares about. We also trust that our renewed W= G > leadership will finally help us all in getting there. > > Regards, > Woj. > > On 25 June 2012 08:51, Qi Sun wrote: > >> ** >> Hi Satoru, >> >> In MAP 1:1 mode, if there are 10000000 subscribers, there would be >> 10000000 MAP domains which a BR has to manage. I think that will create = a >> huge mapping table on the BR, which is called 'state' that stateful >> solutions deal with. >> >> Best Regards! >> >> ------------------------------ >> Qi Sun >> >> *From:* Satoru Matsushima >> *Date:* 2012-06-25 10:27 >> *To:* Lee, Yiu >> *CC:* softwires@ietf.org; Yong Cui >> *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does >> NOT reflect the consensus from the WG >> Hi Yiu, >> >> No, that's a misunderstanding. >> >> Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber= mapping' in stateless manner, not to introduce 'per-flow NAT binding' or '= per-subscriber state on demand'. >> >> cheers, >> --satoru >> >> On 2012/06/25, at 2:32, Lee, Yiu wrote: >> >> > Dear Satoru and MAP-DT >> > >> > I echo what Peng and Qiong said. When the WG agreed working on the >> > stateless solution, it was very clear stated that the solution would n= ot >> > maintain states in the network. If the 1:1 mode changed this, this no >> >> > longer matched the requirements stated in the stateless motivation dra= ft, >> > thus, it would disqualify MAP as a solution for the motivation draft. >> > >> > AFAIK, the MAP Design Team could propose a change, but such a dramatic >> > change by introducing states in the network would require WG approval.= I >> > would like the chairs to clarify this. >> > >> > Thanks, >> > Yiu >> > >> > >> > On 6/24/12 12:21 PM, "Peng Wu" wrote: >> > >> >> Hi Qiong, Satoru and all, >> >> >> >> >> I should thank Qiong for pointing this out. I gotta say I'm a bit sho= cked. >> >> If I understand the procedures of IETF correctly, a WG document shoul= d >> >> reflect the consensus of the WG. MAP is approved by the WG as a >> >> stateless solution. As a participator in Softwire, I didn't get the >> >> information anywhere that the MAP WG document would cover the >> >> so-called 1:1, in fact per-user stateful mode before it was released, >> >> not to say discuss in the WG. Don't the WG need to approve such big >> >> change anymore? >> >> >> >> Now let me provide my impression as an outsider of the MAP DT. You >> >> guys make great effort to build the solution, The address composition= , >> >> the GMA algorithm, the different types of address mapping rules. >> >> should be quite difficult to pull together such sophisticated ideas. = I >> >> guess that's what it takes to achieve the benifits of statelessness. >> >> And I admire that, bravo. Then, all of a sudden, you guys are saying, >> >> let's apply this sophisticated method to the different problem, by >> >> dropping quite some comlexity and twistting the mechanism a bit, seem= s >> >> it may work. Considering the problem are now solved in a more pure an= d >> >> clear way, I'm sorry but I CANNOT follow the logic here. >> >> >> >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima >> >> wrote: >> >>> Hi Qiong, >> >>> >> >>> I'm disagree with your opinion. >> >>> >> >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed i= n >> >>> the DT. >> >> >>> 2. MAP just covers so called '1:1 mode' with most granular mapping r= ule >> >>> for CEs provisioning, which is as one of its characteristics. >> >>> 3. The motivation draft does not restrict that as you stated, just >> >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. >> >>> >> >>> Best regards, >> >>> --satoru >> >>> >> >>> >> >>> On 2012/06/24, at 14:35, Qiong wrote: >> >>> >> >>>> Hi all, >> >>>> >> >>>> As we all know, once an individual draft is adopted as a WG draft, = it >> >>>> is owned by the whole WG, rather than just the editors. Just as Rem= i >> >> >>>> said, the normal procedure to follow is to reach WG consensus _befo= re_ >> >>>> posting a newly edited version. >> >>>> >> >>>> From draft-mdt-softwire-mapping-address-and-port-03 to >> >> >>>> draft-ietf-softwire-map-00, there are several changes between them.= In >> >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 a= nd >> >>>> IPv6 addressing, has never been discussed openly in the WG mailing >> >>>> list, or even in the MAP design team either. >> >>>> >> >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation >> >>>> draft. The motivation draft has clearly defines the "Stateless 4/6 >> >>>> solution" as follows: >> >>>> >> >>>> Stateless 4/6 solution denotes a solution which does not require an= y >> >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by a= ny >> >>>> IP address sharing function in the Service Provider's network. This >> >>>> category of solutions assumes a dependency between an IPv6 prefix a= nd >> >>>> IPv4 address. >> >>>> >> >>>> AFAIK what the WG has adopted MAP related draft is >> >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT >> >> >>>> draft-ietf-softwire-map-00. And the stateless solution should =C2= =B3response >> >> >>>> to the solution motivation document=C2=B2 according to the Softwire= charter. >> >> >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG d= raft. >> >>>> >> >>>> We can all recall that our softwire WG has worked on stateless >> >>>> solutions for more than one and a half years, and we have achieved = a >> >> >>>> lot of work which has been documented in charter, stateless motivat= ion, >> >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basi= c >> >>>> "stateless" principle and the MAP design team is also working on it >> >>>> together to find a better algorithm, address format, etc. So it is >> >> >>>> really not appropriate to make such changes when MAP is adopted as = a WG >> >>>> item in such a short time. >> >>>> >> >> >>>> From this perspective, draft-ietf-softwire-map-00 can only be regar= ded >> >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even th= e >> >>>> output of MAP design team. >> >>>> >> >>>> Best wishes >> >>>> >> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 >> >> _______________________________________________ >> >> 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 >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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 --14dae93404098e081d04c37de2ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tetsuya,

With regard to implementaion, what did you configure in = BR ?

In the specification, it says the BR and CE MUST be configured = with the following MAP elements.
o=C2=A0 The End-User IPv6 prefix (Part = of the normal IPv6 provisioning).
o=C2=A0 The Basic Mapping Rule and optionally the Forwarding Mapping Rules<= br>o=C2=A0 The Default Mapping Rule with the BR IPv6 prefix or address
o= =C2=A0 Hub and spoke mode or Mesh mode.

Did you configure PSID expli= citly ?

If yes, the implementation does not consistent with the specification. = If not, it can not been applied to the so-called 1:1 mode.

Best wish= es
Qiong

On Tue, Jun 26, 2012 at 6:50 = AM, Tetsuya Murakami <Tetsuya.Murakami@ipinfusion.com>= ; wrote:
+1.

In fact, we have already done the implementation prior to the current = MAP draft. But there is no change in our implementation in order to support= the current draft. In addition, our implementation has no limitation for t= he number of mapping rules. It depends on the available memory size only. So, our implementation can allow 1:1 as= well as N:1.

Thanks,
Tetsuya Murakami

On 2012/06/25, at 7:24, Wojciech Dec wrote:

Hi,

taking a step back to discuss some items in more detail, and hopefully move= this discussion forward:

1. Domain size
The MAP architecture does not prescribe the size of a domain, and neither d= oes it prescribe the number of rules to be used. There is nothing in the te= chnology, except vendor implementation limits or practical sense (or both),= to prevent MAP domains from defining 1 domain =3D 1 CPE. This was a day 1 characteristic of MAP drafts.
Choosing to deploy or implement MAP with a configuration supporting 1 rule,= 100 rules or 100k rules or domains is a vendor's and/or operator's= choice. Nobody is stating that deployment is to be limited to X rules, nor= that a near infinite number of rules is reasonable. These are general points that apply to DS-lite state as well a= s the "Light Weight 4 over 6" or "stateless deterministic NA= T", and pretty much any technology for that matter.

2. Stateless DOES NOT mean configuration-less
There appears to be confusion between the concept of stateless and configur= ation-less. MAP domains are based on configured rules, that are provisioned= /applied through means that are currently outside the scope of Softwire dra= fts - this is configuration state, and this was and continues to be a characteristic of MAP.
Further more, unlike some of the other proposals, MAP allows to optimize th= e amount of configuration needed in cases where this is viable. In other wo= rds, MAP does NOT exclusively force 1:1 rule configuration, but also allows= N:1.

3. Stateless has no data plane induced state
A major difference between stateless (eg MAP) and stateful (eg Carrier Grad= e NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic = core node forwarding state that is directly driven by user data-plane traff= ic (eg new IP flows). MAP does not rely on such dynamic state, never did.

4. No change of MAP spec
The updated MAP draft does not change the MAP architecture nor its technica= l underpinnings. In fact there are no changes, bar editorial to the normati= ve parts of MAP, something that is proven by existing implementations prior= to this draft supporting the current draft. A few individuals appear to object to new descriptive text which hi= ghlights the usage of MAP, eg in 1:1. Removing that text will not change th= e matter that MAP allows such usage. Prohibiting such use by specification = would actually require a spec change, besides being unreasonable.

5. What is the problem?
We're=C2=A0 pleased to see a growing understanding of MAP's applica= bility to solve problems, incl v4-v6 address independence, when needed. Giv= en that the emails on this thread do not appear to bring forward any techni= cal issues with the MAP solution, could we know WHY we need other solutions to the problem, or what is the problem that re= mains to be solved?

Taking the liberty to speak on behalf of the other MAP authors, I would lik= e to say that we all remain open for collaboration with all WG members in t= erms of arriving at a minimal set of reasonable solutions that solve proble= ms that the community cares about. We also trust that our renewed WG leadership will finally help us all in g= etting there.

Regards,
Woj.

On 25 June 2012 08:51, Qi Sun = <sunqi.cs= net.thu@gmail.com> wrote:
Hi Satoru,
=C2=A0
In MAP 1:1 mode, if there are 10000000 subscribers, there would be 100= 00000 MAP domains which a BR has to manage. I think that will create a huge= mapping table on the BR, which is called 'state' that stateful sol= utions deal with.
=C2=A0
Best Regards!
=C2=A0
Qi Sun
=C2=A0
Date:=C2=A02012-06-25=C2=A010:27
To:=C2=A0Lee, Yiu
Subject:=C2=A0Re: [Softwires] [Softwire] draft-ietf-softwire-ma= p-00 does NOT reflect the consensus from the WG
Hi=C2=A0Yiu,
=C2=A0
No,=C2=A0that's=C2=A0a=C2=A0misunderstanding.
Current=C2=A0MAP=C2=A0specify=C2=A0the=C2=A0case=C2=A0for=C2=A0ea-len= =C2=A0is=C2=A0'zero'.=C2=A0It=C2=A0is=C2=A0'per-subscriber=C2= =A0mapping'=C2=A0in=C2=A0stateless=C2=A0manner,=C2=A0not=C2=A0to=C2=A0i= ntroduce=C2=A0'per-flow=C2=A0NAT=C2=A0binding'=C2=A0or=C2=A0'pe= r-subscriber=C2=A0state=C2=A0on=C2=A0demand'.
=C2=A0
cheers,
--satoru
=C2=A0
On=C2=A02012/06/25,=C2=A0at=C2=A02:32,=C2=A0Lee,=C2=A0Yiu=C2=A0wrote:<= /div>
=C2=A0
>=C2=A0Dear=C2=A0Satoru=C2=A0and=C2=A0MAP-DT
>=C2=A0
>=C2=A0I=C2=A0echo=C2=A0what=C2=A0Peng=C2=A0and=C2=A0Qiong=C2=A0sai= d.=C2=A0When=C2=A0the=C2=A0WG=C2=A0agreed=C2=A0working=C2=A0on=C2=A0the
>=C2=A0stateless=C2=A0solution,=C2=A0it=C2=A0was=C2=A0very=C2=A0cle= ar=C2=A0stated=C2=A0that=C2=A0the=C2=A0solution=C2=A0would=C2=A0not
>=C2=A0maintain=C2=A0states=C2=A0in=C2=A0the=C2=A0network.=C2=A0If= =C2=A0the=C2=A01:1=C2=A0mode=C2=A0changed=C2=A0this,=C2=A0this=C2=A0no
>=C2=A0longer=C2=A0matched=C2=A0the=C2=A0requirements=C2=A0stated= =C2=A0in=C2=A0the=C2=A0stateless=C2=A0motivation=C2=A0draft,
>=C2=A0thus,=C2=A0it=C2=A0would=C2=A0disqualify=C2=A0MAP=C2=A0as=C2= =A0a=C2=A0solution=C2=A0for=C2=A0the=C2=A0motivation=C2=A0draft.
>=C2=A0
>=C2=A0AFAIK,=C2=A0the=C2=A0MAP=C2=A0Design=C2=A0Team=C2=A0could=C2= =A0propose=C2=A0a=C2=A0change,=C2=A0but=C2=A0such=C2=A0a=C2=A0dramatic
>=C2=A0change=C2=A0by=C2=A0introducing=C2=A0states=C2=A0in=C2=A0the= =C2=A0network=C2=A0would=C2=A0require=C2=A0WG=C2=A0approval.=C2=A0I
>=C2=A0would=C2=A0like=C2=A0the=C2=A0chairs=C2=A0to=C2=A0clarify=C2= =A0this.
>=C2=A0
>=C2=A0Thanks,
>=C2=A0Yiu
>=C2=A0
>=C2=A0
>=C2=A0On=C2=A06/24/12=C2=A012:21=C2=A0PM,=C2=A0"Peng=C2=A0Wu&= quot;=C2=A0<pe= ngwu.thu@gmail.com>=C2=A0wrote:
>=C2=A0
>>=C2=A0Hi=C2=A0Qiong,=C2=A0Satoru=C2=A0and=C2=A0all,
>>=C2=A0
>>=C2=A0I=C2=A0should=C2=A0thank=C2=A0Qiong=C2=A0for=C2=A0pointi= ng=C2=A0this=C2=A0out.=C2=A0I=C2=A0gotta=C2=A0say=C2=A0I'm=C2=A0a=C2=A0= bit=C2=A0shocked.
>>=C2=A0If=C2=A0I=C2=A0understand=C2=A0the=C2=A0procedures=C2=A0= of=C2=A0IETF=C2=A0correctly,=C2=A0a=C2=A0WG=C2=A0document=C2=A0should
>>=C2=A0reflect=C2=A0the=C2=A0consensus=C2=A0of=C2=A0the=C2=A0WG= .=C2=A0MAP=C2=A0is=C2=A0approved=C2=A0by=C2=A0the=C2=A0WG=C2=A0as=C2=A0a
>>=C2=A0stateless=C2=A0solution.=C2=A0As=C2=A0a=C2=A0participato= r=C2=A0in=C2=A0Softwire,=C2=A0I=C2=A0didn't=C2=A0get=C2=A0the
>>=C2=A0information=C2=A0anywhere=C2=A0that=C2=A0the=C2=A0MAP=C2= =A0WG=C2=A0document=C2=A0would=C2=A0cover=C2=A0the
>>=C2=A0so-called=C2=A01:1,=C2=A0in=C2=A0fact=C2=A0per-user=C2= =A0stateful=C2=A0mode=C2=A0before=C2=A0it=C2=A0was=C2=A0released,
>>=C2=A0not=C2=A0to=C2=A0say=C2=A0discuss=C2=A0in=C2=A0the=C2=A0= WG.=C2=A0Don't=C2=A0the=C2=A0WG=C2=A0need=C2=A0to=C2=A0approve=C2=A0suc= h=C2=A0big
>>=C2=A0change=C2=A0anymore?
>>=C2=A0
>>=C2=A0Now=C2=A0let=C2=A0me=C2=A0provide=C2=A0my=C2=A0impressio= n=C2=A0as=C2=A0an=C2=A0outsider=C2=A0of=C2=A0the=C2=A0MAP=C2=A0DT.=C2=A0You=
>>=C2=A0guys=C2=A0make=C2=A0great=C2=A0effort=C2=A0to=C2=A0build= =C2=A0the=C2=A0solution,=C2=A0The=C2=A0address=C2=A0composition,
>>=C2=A0the=C2=A0GMA=C2=A0algorithm,=C2=A0the=C2=A0different=C2= =A0types=C2=A0of=C2=A0address=C2=A0mapping=C2=A0rules.
>>=C2=A0should=C2=A0be=C2=A0quite=C2=A0difficult=C2=A0to=C2=A0pu= ll=C2=A0together=C2=A0such=C2=A0sophisticated=C2=A0ideas.=C2=A0I
>>=C2=A0guess=C2=A0that's=C2=A0what=C2=A0it=C2=A0takes=C2=A0= to=C2=A0achieve=C2=A0the=C2=A0benifits=C2=A0of=C2=A0statelessness.
>>=C2=A0And=C2=A0I=C2=A0admire=C2=A0that,=C2=A0bravo.=C2=A0Then,= =C2=A0all=C2=A0of=C2=A0a=C2=A0sudden,=C2=A0you=C2=A0guys=C2=A0are=C2=A0sayi= ng,
>>=C2=A0let's=C2=A0apply=C2=A0this=C2=A0sophisticated=C2=A0m= ethod=C2=A0to=C2=A0the=C2=A0different=C2=A0problem,=C2=A0by
>>=C2=A0dropping=C2=A0quite=C2=A0some=C2=A0comlexity=C2=A0and=C2= =A0twistting=C2=A0the=C2=A0mechanism=C2=A0a=C2=A0bit,=C2=A0seems
>>=C2=A0it=C2=A0may=C2=A0work.=C2=A0Considering=C2=A0the=C2=A0pr= oblem=C2=A0are=C2=A0now=C2=A0solved=C2=A0in=C2=A0a=C2=A0more=C2=A0pure=C2= =A0and
>>=C2=A0clear=C2=A0way,=C2=A0I'm=C2=A0sorry=C2=A0but=C2=A0I= =C2=A0CANNOT=C2=A0follow=C2=A0the=C2=A0logic=C2=A0here.
>>=C2=A0
>>=C2=A0On=C2=A0Sun,=C2=A0Jun=C2=A024,=C2=A02012=C2=A0at=C2=A02:= 00=C2=A0PM,=C2=A0Satoru=C2=A0Matsushima
>>=C2=A0<satoru.matsushima@gmail.com>=C2=A0wrote:
>>>=C2=A0Hi=C2=A0Qiong,
>>>=C2=A0
>>>=C2=A0I'm=C2=A0disagree=C2=A0with=C2=A0your=C2=A0opini= on.
>>>=C2=A0
>>>=C2=A01.=C2=A0Recent=C2=A0changes=C2=A0in=C2=A0draft-ietf-= softwire-map-00=C2=A0has=C2=A0been=C2=A0discussed=C2=A0in
>>>=C2=A0the=C2=A0DT.
>>>=C2=A02.=C2=A0MAP=C2=A0just=C2=A0covers=C2=A0so=C2=A0calle= d=C2=A0'1:1=C2=A0mode'=C2=A0with=C2=A0most=C2=A0granular=C2=A0mappi= ng=C2=A0rule
>>>=C2=A0for=C2=A0CEs=C2=A0provisioning,=C2=A0which=C2=A0is= =C2=A0as=C2=A0one=C2=A0of=C2=A0its=C2=A0characteristics.
>>>=C2=A03.=C2=A0The=C2=A0motivation=C2=A0draft=C2=A0does=C2= =A0not=C2=A0restrict=C2=A0that=C2=A0as=C2=A0you=C2=A0stated,=C2=A0just
>>>=C2=A0'assumed',=C2=A0it's=C2=A0neither=C2=A0&= #39;MUST'=C2=A0nor=C2=A0'SHOULD'.
>>>=C2=A0
>>>=C2=A0Best=C2=A0regards,
>>>=C2=A0--satoru
>>>=C2=A0
>>>=C2=A0
>>>=C2=A0On=C2=A02012/06/24,=C2=A0at=C2=A014:35,=C2=A0Qiong= =C2=A0wrote:
>>>=C2=A0
>>>>=C2=A0Hi=C2=A0all,
>>>>=C2=A0
>>>>=C2=A0As=C2=A0we=C2=A0all=C2=A0know,=C2=A0once=C2=A0an= =C2=A0individual=C2=A0draft=C2=A0is=C2=A0adopted=C2=A0as=C2=A0a=C2=A0WG=C2= =A0draft,=C2=A0it
>>>>=C2=A0is=C2=A0owned=C2=A0by=C2=A0the=C2=A0whole=C2=A0W= G,=C2=A0rather=C2=A0than=C2=A0just=C2=A0the=C2=A0editors.=C2=A0Just=C2=A0as= =C2=A0Remi
>>>>=C2=A0said,=C2=A0the=C2=A0normal=C2=A0procedure=C2=A0t= o=C2=A0follow=C2=A0is=C2=A0to=C2=A0reach=C2=A0WG=C2=A0consensus=C2=A0_befor= e_
>>>>=C2=A0posting=C2=A0a=C2=A0newly=C2=A0edited=C2=A0versi= on.
>>>>=C2=A0
>>>>=C2=A0From=C2=A0draft-mdt-softwire-mapping-address-and= -port-03=C2=A0to
>>>>=C2=A0draft-ietf-softwire-map-00,=C2=A0there=C2=A0are= =C2=A0several=C2=A0changes=C2=A0between=C2=A0them.=C2=A0In
>>>>=C2=A0particular,=C2=A0the=C2=A0newly=C2=A0introduced= =C2=A0"1:1=C2=A0mode",=C2=A0which=C2=A0decouples=C2=A0IPv4=C2=A0a= nd
>>>>=C2=A0IPv6=C2=A0addressing,=C2=A0has=C2=A0never=C2=A0b= een=C2=A0discussed=C2=A0openly=C2=A0in=C2=A0the=C2=A0WG=C2=A0mailing
>>>>=C2=A0list,=C2=A0or=C2=A0even=C2=A0in=C2=A0the=C2=A0MA= P=C2=A0design=C2=A0team=C2=A0either.
>>>>=C2=A0
>>>>=C2=A0Actually,=C2=A0this=C2=A0"1:1=C2=A0mode&quo= t;=C2=A0is=C2=A0against=C2=A0the=C2=A0stateless-4v6-motivation
>>>>=C2=A0draft.=C2=A0The=C2=A0motivation=C2=A0draft=C2=A0= has=C2=A0clearly=C2=A0defines=C2=A0the=C2=A0"Stateless=C2=A04/6
>>>>=C2=A0solution"=C2=A0as=C2=A0follows:
>>>>=C2=A0
>>>>=C2=A0Stateless=C2=A04/6=C2=A0solution=C2=A0denotes=C2= =A0a=C2=A0solution=C2=A0which=C2=A0does=C2=A0not=C2=A0require=C2=A0any
>>>>=C2=A0per-user=C2=A0state=C2=A0(see=C2=A0Section=C2=A0= 2.3=C2=A0of=C2=A0[RFC1958])=C2=A0to=C2=A0be=C2=A0maintained=C2=A0by=C2=A0an= y
>>>>=C2=A0IP=C2=A0address=C2=A0sharing=C2=A0function=C2=A0= in=C2=A0the=C2=A0Service=C2=A0Provider's=C2=A0network.=C2=A0This
>>>>=C2=A0category=C2=A0of=C2=A0solutions=C2=A0assumes=C2= =A0a=C2=A0dependency=C2=A0between=C2=A0an=C2=A0IPv6=C2=A0prefix=C2=A0and
>>>>=C2=A0IPv4=C2=A0address.
>>>>=C2=A0
>>>>=C2=A0AFAIK=C2=A0what=C2=A0the=C2=A0WG=C2=A0has=C2=A0a= dopted=C2=A0MAP=C2=A0related=C2=A0draft=C2=A0is
>>>>=C2=A0draft-mdt-softwire-mapping-address-and-port-03,= =C2=A0NOT
>>>>=C2=A0draft-ietf-softwire-map-00.=C2=A0And=C2=A0the=C2= =A0stateless=C2=A0solution=C2=A0should=C2=A0=C2=B3response
>>>>=C2=A0to=C2=A0the=C2=A0solution=C2=A0motivation=C2=A0d= ocument=C2=B2=C2=A0according=C2=A0to=C2=A0the=C2=A0Softwire=C2=A0charter.
>>>>=C2=A0That=C2=A0means=C2=A0draft-ietf-softwire-map-00= =C2=A0IS=C2=A0NOT=C2=A0QUALIFIED=C2=A0to=C2=A0be=C2=A0a=C2=A0WG=C2=A0draft.=
>>>>=C2=A0
>>>>=C2=A0We=C2=A0can=C2=A0all=C2=A0recall=C2=A0that=C2=A0= our=C2=A0softwire=C2=A0WG=C2=A0has=C2=A0worked=C2=A0on=C2=A0stateless
>>>>=C2=A0solutions=C2=A0for=C2=A0more=C2=A0than=C2=A0one= =C2=A0and=C2=A0a=C2=A0half=C2=A0years,=C2=A0and=C2=A0we=C2=A0have=C2=A0achi= eved=C2=A0a
>>>>=C2=A0lot=C2=A0of=C2=A0work=C2=A0which=C2=A0has=C2=A0b= een=C2=A0documented=C2=A0in=C2=A0charter,=C2=A0stateless=C2=A0motivation,
>>>>=C2=A04rd-varients,=C2=A0MAP-03,=C2=A0etc.=C2=A0AFAIK= =C2=A0all=C2=A0the=C2=A0authors=C2=A0have=C2=A0kept=C2=A0the=C2=A0basic
>>>>=C2=A0"stateless"=C2=A0principle=C2=A0and=C2= =A0the=C2=A0MAP=C2=A0design=C2=A0team=C2=A0is=C2=A0also=C2=A0working=C2=A0o= n=C2=A0it
>>>>=C2=A0together=C2=A0to=C2=A0find=C2=A0a=C2=A0better=C2= =A0algorithm,=C2=A0address=C2=A0format,=C2=A0etc.=C2=A0So=C2=A0it=C2=A0is
>>>>=C2=A0really=C2=A0not=C2=A0appropriate=C2=A0to=C2=A0ma= ke=C2=A0such=C2=A0changes=C2=A0when=C2=A0MAP=C2=A0is=C2=A0adopted=C2=A0as= =C2=A0a=C2=A0WG
>>>>=C2=A0item=C2=A0in=C2=A0such=C2=A0a=C2=A0short=C2=A0ti= me.
>>>>=C2=A0
>>>>=C2=A0From=C2=A0this=C2=A0perspective,=C2=A0draft-ietf= -softwire-map-00=C2=A0can=C2=A0only=C2=A0be=C2=A0regarded
>>>>=C2=A0as=C2=A0draft-XX-softwire-mapping-address-and-po= rt-04.=C2=A0It=C2=A0is=C2=A0not=C2=A0even=C2=A0the
>>>>=C2=A0output=C2=A0of=C2=A0MAP=C2=A0design=C2=A0team.
>>>>=C2=A0
>>>>=C2=A0Best=C2=A0wishes
>>>>=C2=A0
>>>>=C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>>>>=C2=A0Qiong=C2=A0Sun
>>>>=C2=A0China=C2=A0Telecom=C2=A0Beijing=C2=A0Research=C2= =A0Institude
>>>>=C2=A0
>>>>=C2=A0
>>>>=C2=A0Open=C2=A0source=C2=A0code:
>>>>=C2=A0lightweight=C2=A04over6:=C2=A0http://sourceforge.net/p= rojects/laft6/
>>>>=C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>>>>=C2=A0
>>>>=C2=A0
>>>>=C2=A0_______________________________________________<= /div>
>>>>=C2=A0Softwires=C2=A0mailing=C2=A0list
>>>=C2=A0
>>>=C2=A0_______________________________________________
>>>=C2=A0Softwires=C2=A0mailing=C2=A0list
>>=C2=A0_______________________________________________
>>=C2=A0Softwires=C2=A0mailing=C2=A0list
>>=C2=A0https://www.ietf.org/mailman/listinfo/softwires
=C2=A0
_______________________________________________
Softwires=C2=A0mailing=C2=A0list

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


_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
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

--14dae93404098e081d04c37de2ee-- From fibrib@gmail.com Wed Jun 27 18:53:38 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 C409711E8178 for ; Wed, 27 Jun 2012 18:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.169 X-Spam-Level: X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWNqm2GmRz-I for ; Wed, 27 Jun 2012 18:53:36 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83311E8177 for ; Wed, 27 Jun 2012 18:53:36 -0700 (PDT) Received: by qabj34 with SMTP id j34so1346756qab.4 for ; Wed, 27 Jun 2012 18:53:35 -0700 (PDT) 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=vQsrqVhcHYJG817kgkzLASoMsHxx2PCf6fUmQB+sxoE=; b=HejqByGJHtfr3So1wj1caeA5m9b5kFhrGl7jarcLCmU/JptWH7yqWWM1UpN7Rh48Yx XMy+fpamKsHXZh4/k8vD7arypbSTuendSfE5kdpWZWp+ZPCCvXNGZVoV4RMEccFUXLt0 KirRKbGSfeJNWyq9SWAGsu6j8+fyIbSAnTTniQnYCzk7j11Ww6o+4/pmKHD60kTu1aKK hrpxCBMt7IHgdROzD7t1EZHNOjZCkkHf9OJMCBSjhujDWc7vo/P4uefTpdUbiUf89nai IPh0pi+KkySDpuY2fO7UJ6Rx1z2BQDCT0tJfTwCcRBL2i3Xdpq4T0sGussoJNqCnm/9T jmGw== MIME-Version: 1.0 Received: by 10.224.86.206 with SMTP id t14mr694451qal.11.1340848415681; Wed, 27 Jun 2012 18:53:35 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Wed, 27 Jun 2012 18:53:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jun 2012 01:53:35 +0000 Message-ID: From: Maoke To: Wojciech Dec Content-Type: multipart/alternative; boundary=20cf3074d2e883ace404c37e995d Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 28 Jun 2012 01:53:38 -0000 --20cf3074d2e883ace404c37e995d Content-Type: text/plain; charset=ISO-8859-1 hi Woj, thanks but it looks you didn't answer my questions somewhere maybe because my questions were not clearly expressed. ;-) inline.. 2012/6/27 Wojciech Dec > Hello Maoke, > > inline... > > On 27 June 2012 12:55, Maoke wrote: > >> hi Woj, >> >> thanks a lot for the clarification. >> >> 2012/6/27 Wojciech Dec >> >>> Hi Maoke, >>> >>> inline... >>> >>> On 27 June 2012 05:28, Maoke wrote: >>> >>>> hi dear authors, >>>> >>>> as the map-00 draft contains the normative 1:1 mode statement that is >>>> new in comparison to the previous versions, i'd like to ask some technical >>>> questions in order to clarify the understanding. >>>> >>>> Section 4. page 9: >>>> >>>> MAP can also be provisioned in 1:1 mode. In 1:1 mode the BR has a >>>> MAP domain per subscriber, and the CE is configured in hub and spoke >>>> mode, with only a DMR and no other mapping rules. This allows for a >>>> mode where the BR has one rule per subscriber and the provisioning of >>>> IPv4 address or prefix and port sets is independent of the End-User >>>> IPv6 prefix. >>>> >>>> Question #1: who is a "subscriber"? the definition is missing. and >>>> relatedly, what is the protocol for the subscription? the specification on >>>> the protocol is missing too. >>>> >>> >>> Answer 1: Subscriber = MAP CE. We will clarify the term. >>> >> >> got it. >> >> >>> >>>> Question #2: what is the relationship between 1:1 mode, encapsulation >>>> mode, translation mode, hub&spoke mode, mesh mode? are they independent to >>>> each other, exclusively or not, somehow orthogonal or not? the >>>> specification on the "mode" is missing. >>>> >>> >>> Answer 2: mode = forwarding mode, also known as transport mode. There >>> are two of these, translation and encapsulation. No relation between the >>> rest of the things you mention >>> >> >> okay. then please clearly revise the wording to avoid confusing the >> readers. only after the terms/wordings are revised, the MAP deployment is >> able to follow these well-defined words and terms. >> >> >>> >>> >>>> Question #3: what is the resource for deployment of a "MAP domain"? the >>>> MAP spec never define that. however, we kept understanding that the >>>> resource for a "MAP domain" includes: >>>> - an IPv4 prefix (with prefix length 32 or less) shared by >>>> CEs in this domain >>>> - an IPv6 prefix (with prefix length 64 or less) delegated >>>> to the CEs in this domain with a /64 (or shorter) per CE (as the basic >>>> model of prefix d >>>> the newly introduced "1:1 mode" obviously abandons this >>>> understanding, then an explicit definition on the resource of a "MAP >>>> domain" is requested. this is the origin and essential starting point of >>>> the MAP deployment. >>>> >>> >>> Answer 3: What do you mean by resource for deployment?? It has, and >>> always has been an IPv6 prefix and an IPv4 address. This is the same in >>> *all* of this solution space. The split in terms of how one arrives at the >>> IPv4 address and port-range has always been variable in MAP. >>> Additional point: There is no newly introduced 1:1 mode, as the spec >>> hasn't changed. Folks who implemented according to the previous spec, whihc >>> you seem to indicate had no 1:1 mode see no difference. >>> >> >> as you clarified CE = subscriber, it is ok. but a new question: >> >> question #3.1: in the 1:1 mode, how long the PSID is? how long the >> EA-bits? i understand the bit relationship described in the Figure 7 is the >> native property of the MAP algorithm. but it looks to me that 1:1 mode has >> nothing related to this figure. it breaks the relation o = p + q. it is >> hard to accept that the 1:1 mode is not newly introduced alien. even an >> alien were welcome, i would like to suggest the authors prepare a text at >> Figure 7 stating "this is nosense to the 1:1 mode". >> > > The relation of o = p + q holds, for all values of p and q giving 0 <= o > <=48. Given that we have resticted MAP to positive values of p and q, > although negative were suggested, that provides you the range of p and q. > then there are two possible understanding to the "1:1" case: A. EA-bit becomes zero (it is surely not excluded by the MAP architecture), o = 0 => p = q = 0. p = 0 means the whole IPv4 address (/32) is applied in the mapping algorithm, with no any bits remained in the generated IPv6 address. q = 0 means the PSID length is zero, and therefore the CE working with such an mapping rule has a (full) IPv4 address without sharing to any others. B. CE works with a shared or not shared IPv4 address while it is considered that the CE is set to work in 1:1 mode. if shared, there IS a PSID assigned to the CE but (artificially) not inserted into the MAP IPv6 address for the CE. if your "1:1 mode" means A, it is fine and i totally agree that it is a naturally established case of the MAP; if your "1:1 mode" means B, i must say the MAP addressing algorithm is abandoned for this special mode de facto. i understand current MAP is talking B. please confirm! up to now, my understanding is: containing the explanation on A and clarifying its use case would make MAP spec comprehensive, while containing the text meaning B makes MAP spec a low-quality and confusing doc. > > >> >> question #3.2: then about the rule, for ONE rule, i see only, in Section >> 5: >> * Rule IPv6 prefix (including prefix length) >> >> * Rule IPv4 prefix (including prefix length) >> >> * Rule EA-bits length (in bits) >> >> * Rule Port Parameters (optional) >> >> (as the 5th "forwarding mode" has been confirmed as a domain >> configuration) >> >> i don't see there is a PSID value in this tuple, nor i see it in the >> example in Sec 5.2, 5.3 for the Given rules. >> > > Well, if you look at the info list passed in an FMR you will see that > everything is there allowing the derivation of a PSID for a given > destination if/when needed and/or the port range from a given FMR. > let's make an example similar to Section 5.2 page 16, but in the EA-length = 0: CE X: Forwarding Mapping Rule: { 2001:db8:0:2:3:4:5:6/128 (Rule IPv6 prefix, call it /64 is no problem), 192.0.2.18/32 (Rule IPv4 prefix), 0 (Rule EA-bits length) } PSID offset: 4 (default value as per section 5.1.3) this FMR stored in BR, to my understanding, is a valid and native MAP rule. it corresponds to the above 1:1 case A. when a packet (**) IPv4 destination address: 192.0.2.18 IPv4 destination port: 9030 comes, it is no doubt that the packet can be correctly forwarded to the above CE X. however, if there is a PSID for CE X and CE Y, sharing the same IPv4 address, but the PSID is not appear in the Rule IPv6 Prefix (as EA bits are null): CE X: same as (*) CE Y: Forwarding Mapping Rule: { 2001:db8:1:2:4:5:6:7/128 (Rule IPv6 prefix), 192.0.2.18/32 (Rule IPv4 prefix), 0 (Rule EA-bits length) } PSID offset: 4 (default value as per section 5.1.3) when the packet (**) arrives at the BR, please tell me: which CE's IPv6 address will be selected for the MAP-E or MAP-T? > In the case of EA=0, the prefix is enough for forwarding. > >> >> if Section 5 is not applied to the 1:1 mode, an explicit text "This >> section is nonsense to the 1:1 mode" is required. if a PSID value is to be >> added into the rule, i understand it is hard to call "not newly introduced" >> stuff. >> > > As explained, it is not :-) And again, I bring your attention to what > several implementers said about this, all of whom used previous drafts as > their spec. > NOTE: if you try to add a explicit PSID into the FMR, i don't think "what several implementers said about this, all of whom used previous drafts as their spec" can prove anything. if you don't mean to add anything new in the FMR, admitting that the 1:1 case is actually the case A that i mentioned above, we can finish this thread soon with a consensus to modify the text on 1:1 clarifying this understanding. > > > >> >>> Disabling the 1:1 mode would actually require a spec change. >>> >> >>>> Section 5. page 10: >>>> >>>> * Forwarding mode >>>> >>>> Question #4: this appears twice at the definition of BMR and DMR, >>>> respectively. though Wojieich and Remi has discussed that in another >>>> thread, i would like to confirm: is this mode a domain configuration >>>> parameter or a rule parameter? >>>> >>> >>> Answer 4: Confirmed, intent is for it to be per domain. >>> >>>> >>>> Question #5: does this "forwarding mode" is a enumerate type of {MAP-T, >>>> MAP-E, 1:1, hub&spoke, mesh} or else, e.g., {MAP-T, MAP-E} x {1:1, N:1} x >>>> {hub&spoke, mesh}, where the "x" is the operator for de Cartesian product >>>> of sets? (related to #2) >>>> >>> >>> Answer 5: No need to enumerate, because there is no relation between >>> these (answered above) >>> >> >> question #5.1: do you mean, for example, when i decided the domain >> forward mode, e.g. MAP-T, it is fine that i deploy 1:1 for CE.A while N:1 >> for CE.B, right? please confirm this. >> > > Each CE is configured independently. In case you mean to ask about two > CPEs in the same domain having different domain configurations (eg BMR), I > would like to point out that this makes them be in separate domains... > >> >> >>> >>>> Section 7.1 page 19: >>>> >>>> In 1:1 mode, the MAP CE is provisioned with only a Default Mapping >>>> Rule, and the full IPv4 address/prefix and port range is provisioned >>>> using the DHCP option. >>>> >>>> Question #6: is the CE or the subscriber the receiver of the "full IPv4 >>>> address/prefix and port range" (correction: port set) to be provisioned? or >>>> does it mean a CE is a subscriber itself in the 1:1 mode? >>>> >>> >>> Woj> MAP CE. >>> >>>> >>>> Section 7.3 page 19: >>>> >>>> A MAP-E CE provisioned with only a Default Mapping Rule, as in the >>>> 1:1 case, and with no IPv4 address and port range configured by other >>>> means, MUST disable its NAT44 functionality. >>>> >>>> Question #7: this text is contradictory with Section 7.1. is the DHCP >>>> option a sort of "other means" or not, or there's something out of scope of >>>> this draft? >>>> >>> >>> Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing >>> in the architecture prevents any other provisioning mechanisms to be used >>> incl dhcpv4, snmp, etc. >>> >> >> still confusing. >> Question #7.1: is what the MAP *can* use a part of MAP spec suite, e.g., >> MAP-DHCP? please clarify explicitly: in the condition of Section 7.1, NAT44 >> must be disable or not? >> > > MAP is not defined or restricted to use of dhcpv6. As I state above, if > one wishes to use any other provisioning mechanism, then that is fine. > please answer my question straightforwardly. Question #7.2: is MAP-DHCP a native MAP component? Yes or No. Question #7.3: when MAP-DHCP is used, NAT44 for a 1:1 mode CE MUST be disabled or not? Yes or No. > > >> >>> >>>> Question #8: what is the consequence of disabling the NAT44 >>>> functionality on CE when a subscriber having a PSID of a share IPv4 address >>>> is running behind that CE as a 1:1 mode domain? >>>> >>> >>> Woj> That is not possible. We can be clearer in saying that if the CPE >>> has no IPv4 address configured then NAT44 is to be disabled (kind of >>> obvious) >>> >> >> much more confusing. >> Question #8.1: please clarify if this CPE has no IPv4 stack enabled or >> has only no IPv4 address configured (statically or dynamically). how it >> works? >> > > Sorry, but your question doesn't appear to be quite logical. You asked, > "what is the consequence of disabling NAT44 functionality" in the context > of draft text which effectively says (which could be clearer) "disable > NAT44 if there is no IPv4 address". Perhaps you could clarify what you see > as running NAT44 without an IPv4 address, and then we can talk about its > consequences (it does not appear to be MAP issue however). > here my question is trying to understand what do you mean with the term "the CPE has no IPv4 address configured". let me change a way of asking: Question #8.2: does "the CPE has no IPv4 address configured" work in IPv4/IPv6 dual-stack or IPv6 only? Question #8.3: if "the CPE has no IPv4 address configured" works in IPv4/IPv6 dual-stack, why it "has no IPv4 address configured"? how its IPv4 stack works? if it works with IPv6 only, it sounds a case of single translation, out of the scope of MAP, right? Question #8.4: if there is no IPv4 address nor IPv4 stack, where do we need to *disable* the NAT44? i agree with you that "NAT44 is disabled" here is obvious but i see it is too obvious to cost a "MUST" in the specification. "MUST disable" means WE, the HUMAN, MUST make an action according to the specification. question clarified? please confirm that the editor/author of this text refers the same thing as you interpreted. thanks and regards, maoke > > Regards, > Woj. > >> >> >>> >>>> before all of the above questions and further questions possibly to be >>>> generated during the discussion are fully clarified, i cannot help but >>>> gently show my disagreement on putting the current draft as working group >>>> result. i also hope the MAP spec authors kindly understand with so many >>>> uncertainty modifying MAP deployment draft to fit the MAP spec is a >>>> mission-impossible for the time being. >>>> >>> >>> Woj> What is the basis of your gentle disagreement, and its timing now? >>> The merged of the drafts was discussed previously, and circulated on the >>> design team of which you are a apart of. It appears your comments relate to >>> the supposed controversial 1:1 non-normative text. >>> >> >> i only talk about the aspect of technical maturity. it is not >> unreasonable that i disagree the status of being WG doc even if there might >> be only me who hasn't understood. >> >> however, as you raised this question on the procedural justice, i have to >> point out the following fact: >> >> the mdt-named MAP spec was circulated, according to my mailbox record >> (maybe i missed some), until March 30, with the last message sent out by >> Leaf. however, the 1:1 mode is added on May 31st 10:47:11 timezone +0200 >> according to the git log and git diff and the next day, June 1st, it >> becomes the published version, which appears to IETF draft repos on June >> 8th. after May 30th, nobody among the authors called for review. >> >> i may imagine that, maybe, the authors were not aware that the 1:1 mode >> text IS a sort of change that need to review. but what do you suggest the >> "right timing" if it is not NOW?! >> >> i hope i need to point out the above fact only once and never talk on it >> again. i also hope it were the case that the authors called for review but >> i missed. it is not my purpose to debate on such kind of trivials -- >> wasting life of you, of me and of all of ours, nor i care what is the >> normative text what is not. i only focus on the technical issue. whatever >> the timing is, i am against any confusion and misleading. >> >> - maoke >> > > --20cf3074d2e883ace404c37e995d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Woj,=A0

thanks but it looks you didn&#= 39;t answer my questions somewhere maybe because my questions were not clea= rly expressed. ;-) inline..

2012/6/27 W= ojciech Dec <wdec.ietf@gmail.com>
Hello Maoke,

inline...

On 27 June 2012 12:55, Maoke <fi= brib@gmail.com> wrote:
hi Woj,=A0

thanks a lot for the clarifica= tion.=A0

2012/6/27 Wojciech Dec <wdec.ietf@gmail.com>
Hi Maoke,

inline...

On 27 June 2012 05:28, Maoke <fibrib@gmail.com>= ; wrote:
hi dear authors,=A0

as the map-00 draft c= ontains the normative 1:1 mode statement that is new in comparison to the p= revious versions, i'd like to ask some technical questions in order to = clarify the understanding.=A0

Section 4. page 9:

MAP can als= o be provisioned in 1:1 mode. In 1:1 mode the BR has a
MAP domain pe= r subscriber, and the CE is configured in hub and spoke
mode, with on= ly a DMR and no other mapping rules. This allows for a
mode where the BR has one rule per subscriber and the provisioning of IPv4 address or prefix and port sets is independent of the End-User
= IPv6 prefix.

Question #1: who is a "subscr= iber"? the definition is missing. and relatedly, what is the protocol = for the subscription? the specification on the protocol is missing too.

Answer 1: Subscriber =3D MAP CE. We will clarif= y the term.

got it. <= /div>
=A0

Question #2: what is the relationship between 1:1 mode,= encapsulation mode, translation mode, hub&spoke mode, mesh mode? are t= hey independent to each other, exclusively or not, somehow orthogonal or no= t? the specification on the "mode" is missing.=A0

Answer 2: mode =3D forwarding mode, also known = as transport mode. There are two of these, translation and encapsulation. N= o relation between the rest of the things you mention

okay. then please clearly revise the wording to a= void confusing the readers. only after the terms/wordings are revised, the = MAP deployment is able to follow these well-defined words and terms.=A0
=A0

Question #3: what is the resource for deployment of a &= quot;MAP domain"? the MAP spec never define that. however, we kept und= erstanding that the resource for a "MAP domain" includes:=A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0- an IPv4 prefix (with prefix length 32 or = less) shared by CEs in this domain
=A0 =A0 =A0 =A0 =A0 =A0 =A0- a= n IPv6 prefix (with prefix length 64 or less) delegated to the CEs in this = domain with a /64 (or shorter) per CE (as the basic model of prefix d
=A0 =A0 =A0 =A0 =A0 =A0 =A0the newly introduced "1:1 mode" o= bviously abandons this understanding, then an explicit definition on the re= source of a "MAP domain" is requested. this is the origin and ess= ential starting point of the MAP deployment.=A0

Answer 3: What do you mean by resource for depl= oyment?? It has, and always has been an IPv6 prefix and an IPv4 address. Th= is is the same in *all* of this solution space. The split in terms of how o= ne arrives at the IPv4 address and port-range has always been variable in M= AP.
Additional point: There is no newly introduced 1:1 mode, as the spec hasn&#= 39;t changed. Folks who implemented according to the previous spec, whihc y= ou seem to indicate had no 1:1 mode see no difference.

as you clarified CE =3D subscriber, it is ok. but= a new question:=A0

question #3.1: in the 1:1 mode= , how long the PSID is? how long the EA-bits? i understand the bit relation= ship described in the Figure 7 is the native property of the MAP algorithm.= but it looks to me that 1:1 mode has nothing related to this figure. it br= eaks the relation o =3D p + q. it is hard to accept that the 1:1 mode is no= t newly introduced alien. even an alien were welcome, i would like to sugge= st the authors prepare a text at Figure 7 stating "this is nosense to = the 1:1 mode".=A0

The relation of o =3D p + q holds, = for all values of p and q giving 0 <=3D o <=3D48. Given that we have = resticted MAP to positive values of p and q, although negative were suggest= ed, that provides you the range of p and q.

then there are two possible un= derstanding to the "1:1" case:

A. EA-bit= becomes zero (it is surely not excluded by the MAP architecture), o =3D 0 = =3D> p =3D q =3D 0.=A0
=A0 =A0p =3D 0 means the whole IPv4 address (/32) is applied in the ma= pping algorithm, with no any bits remained in the generated IPv6 address.= =A0
=A0 =A0q =3D 0 means the PSID length is zero, and therefore t= he CE working with such an mapping rule has a (full) IPv4 address without s= haring to any others.=A0

B. CE works with a shared or not shared IPv4 address wh= ile it is considered that the CE is set to work in 1:1 mode.=A0
= =A0 =A0if shared, there IS a PSID assigned to the CE but (artificially) not= inserted into the MAP IPv6 address for the CE.=A0

if your "1:1 mode" means A, it is fine and i = totally agree that it is a naturally established case of the MAP;=A0
<= div>if your "1:1 mode" means B, i must say the MAP addressing alg= orithm is abandoned for this special mode de facto.=A0

i understand current MAP is talking B. please confirm!<= /div>

up to now, my understanding is: containing the exp= lanation on A and clarifying its use case would make MAP spec comprehensive= , while containing the text meaning B makes MAP spec a low-quality and conf= using doc.=A0
=A0
=A0

question #3.2: then about the rule, for ONE rule, i see= only, in Section 5:=A0
* Rule IPv6 prefix (including pre= fix length)

* Rule IPv4 prefix (including prefix length)

* Rule EA-bits length (in bits)

* Rule Port Para= meters (optional)

(as the 5th "forwarding mod= e" has been confirmed as a domain configuration)

i don't see there is a PSID value in this tuple, nor i see it in t= he example in Sec 5.2, 5.3 for the Given rules.=A0
=

Well, if you look at the info list passed in an FMR you will= see that everything is there allowing the derivation of a PSID for a given= destination if/when needed and/or the port range from a given FMR.

let's make an example similar to= Section 5.2 page 16, but in the EA-length =3D 0:=A0

CE X:=A0
Forwarding Mapping Rule: {
=A0 =A0 2001:db= 8:0:2:3:4:5:6/128 (Rule IPv6 prefix, call it /64 is no problem),
=A0 =A0 192= .0.2.18/32 (Rule IPv4 prefix),
=A0 = =A0 0 (Rule EA-bits length)
=A0 }
PSID offset: = 4 (default value as per section 5.1.3)

this FMR stored in BR, to my understanding, is a valid = and native MAP rule. it corresponds to the above 1:1 case A. when a packet= =A0
(**)
=A0 =A0IPv4 destination address: 192.0.2.= 18
=A0 =A0IPv4 destination port: 9030

come= s, it is no doubt that the packet can be correctly forwarded to the above C= E X.=A0

however, if there is a PSID for CE X and C= E Y, sharing the same IPv4 address, but the PSID is not appear in the Rule = IPv6 Prefix (as EA bits are null):=A0

CE X: same as (*)

CE Y:
<= div>
Forwarding Mapping Rule: {
=A0 =A0 2001:db8:1:2:4:5:6:7= /128 (Rule IPv6 prefix),
=A0 =A0 192.0.2.18/32 (Rule IPv4 prefix),
=A0 =A0 0 (Rule EA-bits length)
= =A0 }
PSID offset: 4 (default value as per section 5.= 1.3)

when the packet (**) arrives at the BR,= please tell me: which CE's IPv6 address will be selected for the MAP-E= or MAP-T?=A0
=A0
In the case of EA=3D0, the prefix is enough for forwarding.= =A0
<= div class=3D"gmail_quote">

if Section 5 is not applied t= o the 1:1 mode, an explicit text "This section is nonsense to the 1:1 = mode" is required. if a PSID value is to be added into the rule, i und= erstand it is hard to call "not newly introduced" stuff. =A0

As explained, it is not :-) And again, I = bring your attention to what several implementers said about this, all of w= hom used previous drafts as their spec.=A0

NOTE: if you try to add a explicit PSID into the FMR, i don&= #39;t think "what several implementers said about this, all of whom us= ed previous drafts as their spec" can prove anything.

if you don't mean to add anything new in the FMR, admitting = that the 1:1 case is actually the case A that i mentioned above, we can fin= ish this thread soon with a consensus to modify the text on 1:1 clarifying = this understanding.=A0
=A0


=A0
=A0Disabling the 1:1 mode would actually require a spec change.=A0
<= /div>

Section 5. page 10:

=A0 * = Forwarding mode

Question #4: this appears twice a= t the definition of BMR and DMR, respectively. though Wojieich and Remi has= discussed that in another thread, i would like to confirm: is this mode a = domain configuration parameter or a rule parameter?

Answer 4: Confirmed, intent is for it to be per= domain.

Question #5: does this "forwarding mode" is a= enumerate type of {MAP-T, MAP-E, 1:1, hub&spoke, mesh} or else, e.g., = {MAP-T, MAP-E} x {1:1, N:1} x {hub&spoke, mesh}, where the "x"= ; is the operator for de Cartesian product of sets? (related to #2)

Answer 5: No need to enumerate, because there i= s no relation between these (answered above)

question #5.1: do you mean, for example, when i dec= ided the domain forward mode, e.g. MAP-T, it is fine that i deploy 1:1 for = CE.A while N:1 for CE.B, right? please confirm this.=A0

Each CE is configured independently. In c= ase you mean to ask about two CPEs in the same domain having different doma= in configurations (eg BMR), I would like to point out that this makes them = be in separate domains...=A0
<= div class=3D"gmail_quote">
=A0

Section 7.1 page 19:

In 1:= 1 mode, the MAP CE is provisioned with only a Default Mapping
Rule, a= nd the full IPv4 address/prefix and port range is provisioned
using t= he DHCP option.

Question #6: is the CE or the subscriber the rece= iver of the "full IPv4 address/prefix and port range" (correction= : port set) to be provisioned? or does it mean a CE is a subscriber itself = in the 1:1 mode?

Woj>=A0 MAP CE.

Section 7.3 page 19:

A MAP-E C= E provisioned with only a Default Mapping Rule, as in the
1:1 case, a= nd with no IPv4 address and port range configured by other
means, MUS= T disable its NAT44 functionality.

Question #7: this text is contradictory with Section 7.= 1. is the DHCP option a sort of "other means" or not, or there= 9;s something out of scope of this draft?=A0

Woj> DHCP is a provisioning mechanism which MAP *can* use, but nothing i= n the architecture prevents any other provisioning mechanisms to be used in= cl dhcpv4, snmp, etc.

still confusing.=A0
Question #7.1: is what the MAP *can* use a pa= rt of MAP spec suite, e.g., MAP-DHCP? please clarify explicitly: in the con= dition of Section 7.1, NAT44 must be disable or not?=A0

MAP is not defined or restricted to use of dhcpv6. As I stat= e above, if one wishes to use any other provisioning mechanism, then that i= s fine.

please answer my questi= on straightforwardly.=A0
Question #7.2: is MAP-DHCP a native MAP component? Yes or No.=A0
=
Question #7.3: when MAP-DHCP is used, NAT44 for a 1:1 mode CE MUST be = disabled or not? Yes or No.=A0
=A0

=A0

Question #8: what is the consequence of disabling the N= AT44 functionality on CE when a subscriber having a PSID of a share IPv4 ad= dress is running behind that CE as a 1:1 mode domain?=A0

Woj>=A0 That is not possible.=A0 We can be clearer in say= ing that if the CPE has no IPv4 address configured then NAT44 is to be disa= bled (kind of obvious)

much more confusing.=A0
Question #8.1: please clarify if this CPE has no IPv4 stack enabled or= has only no IPv4 address configured (statically or dynamically). how it wo= rks?=A0

Sorry, but your question doe= sn't appear to be quite logical. You asked, "what is the consequen= ce of disabling NAT44 functionality" in the context of draft text whic= h effectively says (which could be clearer) "disable NAT44 if there is= no IPv4 address". Perhaps you could clarify what you see as running N= AT44 without an IPv4 address, and then we can talk about its consequences (= it does not appear to be MAP issue however).

here my question is trying to = understand what do you mean with the term "the CPE has no IPv4 address= configured". let me change a way of asking:
Question #8.2: = does "the CPE has no IPv4 address configured" work in IPv4/IPv6 d= ual-stack or IPv6 only?=A0

Question #8.3: if "the CPE has no IPv4 addres= s configured" works in IPv4/IPv6 dual-stack, why it "has no IPv4 = address configured"? how its IPv4 stack works? if it works with IPv6 o= nly, it sounds a case of single translation, out of the scope of MAP, right= ?=A0

Question #8.4: if there is no IPv4 address nor IPv4 sta= ck, where do we need to *disable* the NAT44? i agree with you that "NA= T44 is disabled" here is obvious but i see it is too obvious to cost a= "MUST" in the specification. "MUST disable" means WE, = the HUMAN, MUST make an action according to the specification. question cla= rified? please confirm that the editor/author of this text refers the same = thing as you interpreted.=A0

thanks and regards,
maoke
=A0=

Regards,
Woj.
=A0

before all of the above questions and further questions= possibly to be generated during the discussion are fully clarified, i cann= ot help but gently show my disagreement on putting the current draft as wor= king group result. i also hope the MAP spec authors kindly understand with = so many uncertainty modifying MAP deployment draft to fit the MAP spec is a= mission-impossible for the time being.=A0

Woj> What is the basis of your gentle disagr= eement, and its timing now? The merged of the drafts was discussed previous= ly, and circulated on the design team of which you are a apart of. It appea= rs your comments relate to the supposed controversial 1:1 non-normative tex= t.

i only talk about the as= pect of technical maturity. it is not unreasonable that i disagree the stat= us of being WG doc even if there might be only me who hasn't understood= .=A0

however, as you raised this question on the procedural = justice, i have to point out the following fact:=A0

=A0the mdt-named MAP spec was circulated, according to my mailbox record = (maybe i missed some), until March 30, with the last message sent out by Le= af. however, the 1:1 mode is added on May 31st 10:47:11 =A0timezone +0200 a= ccording to the git log and git diff and the next day, June 1st, it becomes= the published version, which appears to IETF draft repos on June 8th. afte= r May 30th, nobody among the authors called for review.=A0

i may imagine that, maybe, the authors were not aware t= hat the 1:1 mode text IS a sort of change that need to review. but what do = you suggest the "right timing" if it is not NOW?!=A0

i hope i need to point out the above fact only once and= never talk on it again. i also hope it were the case that the authors call= ed for review but i missed. it is not my purpose to debate on such kind of = trivials -- wasting life of you, of me and of all of ours, nor i care what = is the normative text what is not. i only focus on the technical issue. wha= tever the timing is, i am against any confusion and misleading.=A0

- maoke


--20cf3074d2e883ace404c37e995d-- From jiangdong345@gmail.com Wed Jun 27 21:34: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 3C55F21F84B2 for ; Wed, 27 Jun 2012 21:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-s5DnVZYIfF for ; Wed, 27 Jun 2012 21:34:16 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 048A311E80C0 for ; Wed, 27 Jun 2012 18:57:34 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2402267pbc.31 for ; Wed, 27 Jun 2012 18:57:34 -0700 (PDT) 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=8fFMQbwwac3Z91O+M3Z/6DKFZG5tCwR5CXngJKKcGVQ=; b=ktJ1BlKVReBy9hVZxy4nnHloVwD+j/m71B8tp1jks9GDkB7ZmTyRTvoYPN0ohEnxT3 NawRJ1vIEfic40FhrVxadZytyAdLZS77G0NPQI4RRsfAtMtZbB9viRHZ7P1rGxLY+358 DJ6dTMHFpBTYM3/VO2mAfqLWr9ykoKQql/CcXma8z3baY3K7ubJUvaElGbu4hMAS4TA3 x/KxG0YcZdo20TELfwALxaNZb/k7YIdGLr+uU2wtBE3NcXnfFy0SHBn7AfvdvAQDOIg8 UBNb9MRAFK3IT6LsChNScN/aFS7M0n/pFzuM6OmHRSE94HKuWFFu9Y1UFBgTe8epXhBj i7Sw== Received: by 10.68.233.132 with SMTP id tw4mr1619272pbc.61.1340848654580; Wed, 27 Jun 2012 18:57:34 -0700 (PDT) Received: from John-PC ([166.111.68.231]) by mx.google.com with ESMTPS id nh6sm476221pbc.44.2012.06.27.18.57.31 (version=SSLv3 cipher=OTHER); Wed, 27 Jun 2012 18:57:33 -0700 (PDT) Date: Thu, 28 Jun 2012 09:57:32 +0800 From: "Jiang Dong" To: "Rajiv Asati (rajiva)" , "Satoru Matsushima" , "Peng Wu" References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com>, <2012062714341150257645@gmail.com>, X-Priority: 3 X-GUID: 24FCAC5B-31C4-4054-AD1D-03C91CBE07C7 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.86[cn] Mime-Version: 1.0 Message-ID: <2012062809572833691129@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart143646225383_=----" Cc: Softwires WG , "ian.farrer" Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOTreflect the consensus from the WG X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jiangdong345 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 04:34:17 -0000 This is a multi-part message in MIME format. ------=_001_NextPart143646225383_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNClRoZW4gSSB3aWxsIGFzazogSGF2ZSB0aGUgWSwgWiBhbHJlYWR5IGJlZW4gaGFyZCB3 b3JrZWQgYnkgc29tZSBvdGhlciBndXlzIGZvciBhIGxvbmcgdGltZT8NCg0KSSBkb24ndCB0aGlu ayB3aGF0IHlvdSBzYWlkIGlzIHRoZSByaWdodCBkaXJlY3Rpb24uIFdoYXQgSSBjYW4gc2VlIGZy b20gdGhlIG1haWxpbmcgbGlzdCBpcyB0aGF0IHRoZSBNQVAtMDAgYXV0aG9ycyB3ZXJlIHRyeWlu ZyB0byBhdm9pZCBzb21lIGNyaXRpY2FsIHF1ZXN0aW9ucy4NCg0KWWVzIHRoZSB0ZWNobmljYWwg ZGV0YWlscyBjYW4gYmUgZGlzY3Vzc2VkLCBidXQgdGhpcyBpcyBub3QgdGhlIHJpZ2h0IHRpbWUg dG8gZG8gdGhpcyBiZWZvcmUgYSBjbGVhciBjbGFyaWZpY2F0aW9uIGlzIG1hZGUuIA0KDQpSZWdh cmRzIQ0KSmlhbmcgRG9uZw0KDQpGcm9tOiBSYWppdiBBc2F0aSAocmFqaXZhKQ0KRGF0ZTogMjAx Mi0wNi0yNyAyMzoyMw0KVG86IGppYW5nZG9uZzM0NTsgU2F0b3J1IE1hdHN1c2hpbWE7IFBlbmcg V3UNCkNDOiBTb2Z0d2lyZXMgV0c7IGlhbi5mYXJyZXINClN1YmplY3Q6IFJFOiBbU29mdHdpcmVz XSBbU29mdHdpcmVdIGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLTAwIGRvZXMgTk9UcmVmbGVjdCB0 aGUgY29uc2Vuc3VzIGZyb20gdGhlIFdHDQpUaGlzIGlzIGEgbW9vdCBhcmd1bWVudCwgYXMgd2Ug aGF2ZSBzZWVuIG1hbnkgcHJvdG9jb2xzICh0YWtlIE1QTFMgZm9yDQpleGFtcGxlKSB0aGF0IHdl cmUgcHJvcG9zZWQgdG8gZG8ganVzdCBYLCBldm9sdmVkIHRvIGRvIFgsIFksIFogYW5kDQptb3Jl Lg0KDQpXaG8gd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgQkdQIHdvdWxkIGJlIGFkdmVydGlzaW5n IE1BQyBhZGRyZXNzZXMgd2hlbg0KQkdQIHdhcyBmaXJzdCBpbnRyb2R1Y2VkPw0KDQpMZXQncyBm b2N1cyBvbiB0aGUgb3BlcmF0aW9uYWwgcHJvYmxlbXMgc29sdmVkIChvciBub3Qgc29sdmVkKSBi eSBhbnkgb2YNCm91ciBzb2x1dGlvbiBzZXRzLiBJIGFwcHJlY2lhdGUgSWFuJ3MgZW1haWwgaW4g dGhhdCBsaWdodC4gVGhpcyB3aWxsDQpoZWxwIHVzIGV2b2x2ZSBvdXIgc29sdXRpb24gc2V0cyBh bmQgaGF2ZSB1cyBzcGVuZCBvdXIgdGltZSBpbiB0aGUgcmlnaHQNCmRpcmVjdGlvbi4NCg0KQ2hl ZXJzLA0KUmFqaXYNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNv ZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5v cmddDQpPbg0KPiBCZWhhbGYgT2YgSmlhbmcgRG9uZw0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUg MjcsIDIwMTIgMjozNCBBTQ0KPiBUbzogU2F0b3J1IE1hdHN1c2hpbWE7IFBlbmcgV3UNCj4gQ2M6 IFNvZnR3aXJlcyBXRzsgaWFuLmZhcnJlcg0KPiBTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gW1Nv ZnR3aXJlXSBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC0wMCBkb2VzDQo+IE5PVHJlZmxlY3QgdGhl IGNvbnNlbnN1cyBmcm9tIHRoZSBXRw0KPiANCj4gSGksIFNhdG9ydSwNCj4gDQo+IEkgYmVsaWV2 ZSBPU1BGIG5ldmVyIGFiYW5kb24gaXRzIG93biBlc3NlbmNlIGluIG9yZGVyIHRvIGJlIGEgc3Vw ZXINCnN1aXRlDQo+IGFuZCBkbyBzb21ldGhpbmcgdmVyeSBzdHJhbmdlIHRvIGNvdmVyIHRoZSB1 c2UgY2FzZSB3aGljaCBjYW4gYmUNCmVhc2lseSBhbmQNCj4gY2xlYXJseSBkb25lIGJ5IFJJUC4N Cj4gDQo+IFdoYXQncyBtb3JlLCBNQVAgaXMgbm90IE9TUEYsIGFuZCBMVzRvdmVyNiBpcyBub3Qg UklQLiBNQVAgYW5kDQpMVzRvdmVyNg0KPiBoYXZlIHRoZWlyIG93biB1c2UgY2FzZSB3aGVuIHRo ZXkgYXJlIG9yaWdpbmFsbHkgZGVzaWduZWQuIE1BUCBpcyBub3QNCj4gc3VwcG9zZWQgdG8gZG8g dGhlIDE6MSBtb2RlIGluIHRoZSBiZWdpbm5pbmcuDQo+IA0KPiBSZWdhcmRzIQ0KPiBKaWFuZyBE b25nDQo+IA0KPiBGcm9tOiBTYXRvcnUgTWF0c3VzaGltYSA8bWFpbHRvOnNhdG9ydS5tYXRzdXNo aW1hQGdtYWlsLmNvbT4NCj4gRGF0ZTogMjAxMi0wNi0yNyAxMjozNw0KPiBUbzogUGVuZyBXdSA8 bWFpbHRvOnBlbmd3dS50aHVAZ21haWwuY29tPg0KPiBDQzogc29mdHdpcmVzIDxtYWlsdG86c29m dHdpcmVzQGlldGYub3JnPiA7IGlhbi5mYXJyZXINCj4gPG1haWx0bzppYW4uZmFycmVyQHRlbGVr b20uZGU+DQo+IFN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBbU29mdHdpcmVdIGRyYWZ0LWlldGYt c29mdHdpcmUtbWFwLTAwIGRvZXMNCk5PVA0KPiByZWZsZWN0IHRoZSBjb25zZW5zdXMgZnJvbSB0 aGUgV0cgT24gMjAxMi8wNi8yNywgYXQgMTI6MzYsIFBlbmcgV3UNCndyb3RlOg0KPiANCj4gPj4+ IE5vdCBxdWl0ZS4NCj4gPj4+IEkgYmVsaWV2ZSB0aGF0IHRoZSBtb3N0IG1vdGl2YXRlIHRvIHN0 YXJ0IHRoaXMgd29yayBpbiB0aGUgd2cgaGFzDQo+IGRlc3RpbmVkIE1BUCB0byBiZSAnbXVsdGkt cHJvdG9jb2wgc29ja2V0IHYyLjAnIHRoYXQncyB3aGF0IHRoZSBmb3JtZXINCndnDQo+IGNoYWly IHdpc2hlZCB0by4gRG8geW91IHJlbWVtYmVyIHRoYXQ/DQo+ID4+Pg0KPiA+Pj4gaSBsaWtlIHRo ZSBwaGlsb3NvcGh5IG9mICJtdWx0aS1wcm90b2NvbCBzb2NrZXQiLiBob3dldmVyLCBpDQo+ID4+ PiBtb2RlcmF0ZWx5IGRvdWJ0IHRoZSAibXVsdGktcHJvdG9jb2wgc29ja2V0IHYyLjAiIGlzIGEg cGVyZmVjdA0KcGxhbg0KPiA+Pj4gZm9yIGV2ZXJ5IGNhc2VzLiBpbiBhIHF1aXRlIGdvb2QgaG90 ZWwsIHdlIHNlZSB0eXBpY2FsbHkgb25lDQo+ID4+PiAnbXVsdGktcHJvdG9jb2wgc29ja2V0JyB3 aGlsZSBhIGxvdCBvZiBsb2NhbC1zdGFuZGFyZCBzb2NrZXRzLiBpDQo+ID4+PiBuZXZlciB0aGlu ayBpdCB3aWxsIG1ha2UgbWUgaGFwcHkgaWYgaSBzZWUgZXZlcnkgc29ja2V0IGluIG15IHJvb20N Cj4gPj4+IGlzICptdWx0aS1wcm90b2NvbCosIG9jY3VweWluZyBtdWNoIHNwYWNlcyBhbmQgcXVp dGUgbm90aWNlYWJsZSBvbg0KPiA+Pj4gdGhlIHdhbGxzLiB3ZSBuZWVkIG9uZSB0byBkZXBsb3kg c29tZXdoZXJlIG5vdCB0aGUgb25seSBvbmUgdHlwZQ0KdG8NCj4gPj4+IGRlcGxveSBhbnl3aGVy ZS4gOy0pDQo+ID4+DQo+ID4+IFRoYXQgcG9pbnQgd291bGQgYmUgYW4gb3BlcmF0aW9uYWwgbWF0 dGVyIGZvciBkZXBsb3lpbmcgYW55DQo+IHN0YW5kYXJkaXplZCB0ZWNobm9sb2d5LiBGb3IgZXhh bXBsZSwgYW4gb3BlcmF0b3IgYWRvcHQgT1NQRiB0byB1c2UNCml0cw0KPiByaWNoIHJvdXRpbmcg ZmVhdHVyZSBidXQgdGhlIG5ldHdvcmsgaXMgc21hbGwsIHRoZSBvcGVyYXRvciBkb2VzIGp1c3QN CmFyZWEgMA0KPiByb3V0aW5nLCBldmVuIE9TUEYgYWxsb3cgaW50ZXItYXJlYSByb3V0aW5nIGZv ciBzY2FsZS4gSXMgYW4gYW5vdGhlcg0Kb3NwZg0KPiBzcGVjaWZpY2F0aW9uIG5lZWRlZCBmb3Ig J09TUEYgQXJlYSAwIE9ubHkgUm91dGluZyc/DQo+ID4NCj4gPiBXZWxsIGlmIEkgb25seSBoYXZl IGEgc2ltcGxlIG5ldHdvcmsgYW5kIEkgdXNlcyBSSVAsIHlvdSBkb24ndCBtYWtlDQo+ID4gT1NQ RiBzb21laG93IGNvbXBhdGlibGUgd2l0aCBSSVAob3IganVzdCBpbmNsdWRlIFJJUCB3aXRoIGFu IE9TUEYNCj4gPiB0ZXJtaW5vbG9neSBmYWNlPyBJIGRvbid0IGtub3cpIGFuZCBzYXkgImhleSwg anVzdCB1c2UgdGhpcyBzdXBlcg0KPiA+IHN1aXRlLCBkb24ndCBjb25zaWRlciBpdCBvdmVybG9h ZGVkLCBpdCdzIGZvciB1bml0eSEiDQo+IA0KPiBPaCwgeW91IGRvbid0IGFyZ3VlIHRoYXQgT1NQ RiBjb3ZlcnMgYW4gdXNlIGNhc2Ugd2hpY2ggaXMgYWxzbyBjb3ZlcmVkDQpieQ0KPiBSSVAuIFNv IHRoZW4gd2h5IGFyZSB5b3UgYXJndWluZyB0aGF0IGFuIHVzZSBjYXNlIG9mIE1BUCBpcyBldmVu dHVhbGx5DQpzYW1lDQo+IHdpdGggdGhlIExXNDYgdXNlIGNhc2U/DQo+IA0KPiBjaGVlcnMsDQo+ IC0tc2F0b3J1DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4gU29mdHdpcmVzQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVz ------=_001_NextPart143646225383_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 =
Then I wi= ll ask:=20 Have the Y, Z already been hard worked by some other guys for a long=20 time?
 =
I don't t= hink=20 what you said is the right direction. What I can see from the mailing list= is=20 that the MAP-00 authors were trying to avoid some critical=20 questions.
 =
Yes the t= echnical=20 details can be discussed, but this is not the right time to = ;do=20 this before a clear clarification is made.
 
Regards!
Jiang Dong
 
Date: 2012-06-27 23:23
Subject: RE: [Softwires] [Softwire] draft-ietf-softwire-m= ap-00=20 does NOTreflect the consensus from the WG
This is a moot argument, as we hav= e seen many protocols (take MPLS for
example) that were proposed to do just&= nbsp;X, evolved to do X, Y, Z and
more.
 
Who would have thought that BGP would&n= bsp;be advertising MAC addresses when
BGP was first introduced?
 
Let's focus on the operational problems = ;solved (or not solved) by any of
our solution sets. I appreciate Ian's e= mail in that light. This will
help us evolve our solution sets and&nb= sp;have us spend our time in the right<= /DIV>
direction.
 
Cheers,
Rajiv
 
 
> -----Original Message-----
> From: softwires-bounces@ietf.org [mailto:softwire= s-bounces@ietf.org]
On
> Behalf Of Jiang Dong
> Sent: Wednesday, June 27, 2012 2:3= 4 AM
> To: Satoru Matsushima; Peng Wu
> Cc: Softwires WG; ian.farrer
> Subject: Re: [Softwires] [Softwire] dra= ft-ietf-softwire-map-00 does
> NOTreflect the consensus from the = WG
> 
> Hi, Satoru,
> 
> I believe OSPF never abandon its&n= bsp;own essence in order to be a super<= /DIV>
suite
> and do something very strange to&n= bsp;cover the use case which can be
easily and
> clearly done by RIP.
> 
> What's more, MAP is not OSPF, = ;and LW4over6 is not RIP. MAP and
LW4over6
> have their own use case when = they are originally designed. MAP is not
> supposed to do the 1:1 mode i= n the beginning.
> 
> Regards!
> Jiang Dong
> 
> From: Satoru Matsushima <mailto:satoru.ma= tsushima@gmail.com>
> Date: 2012-06-27 12:37
> To: Peng Wu <mailto:pengwu.thu@gmail.com&= gt;
> CC: softwires <mailto:softwires@ietf.org>&n= bsp;; ian.farrer
> <mailto:ian.farrer@telekom.de>
> Subject: Re: [Softwires] [Softwire] dra= ft-ietf-softwire-map-00 does
NOT
> reflect the consensus from the WG&= nbsp;On 2012/06/27, at 12:36, Peng Wu
wrote:
> 
> >>> Not quite.
> >>> I believe that the mo= st motivate to start this work in the&n= bsp;wg has
> destined MAP to be 'multi-protocol = ;socket v2.0' that's what the former
wg
> chair wished to. Do you remember&n= bsp;that?
> >>>
> >>> i like the philosophy = ;of "multi-protocol socket". however, i
> >>> moderately doubt the "mult= i-protocol socket v2.0" is a perfect
plan
> >>> for every cases. in a=  quite good hotel, we see typically one=
> >>> 'multi-protocol socket' while&n= bsp;a lot of local-standard sockets. i
> >>> never think it will m= ake me happy if i see every socket = ;in my room
> >>> is *multi-protocol*, occupying&= nbsp;much spaces and quite noticeable on
> >>> the walls. we need on= e to deploy somewhere not the only one&= nbsp;type
to
> >>> deploy anywhere. ;-)
> >>
> >> That point would be an&nb= sp;operational matter for deploying any
> standardized technology. For example, a= n operator adopt OSPF to use
its
> rich routing feature but the netwo= rk is small, the operator does just
area 0
> routing, even OSPF allow inter-area&nbs= p;routing for scale. Is an another
ospf
> specification needed for 'OSPF Area&nbs= p;0 Only Routing'?
> >
> > Well if I only have a&nb= sp;simple network and I uses RIP, you d= on't make
> > OSPF somehow compatible with = RIP(or just include RIP with an OSPF
> > terminology face? I don't kno= w) and say "hey, just use this super
> > suite, don't consider it over= loaded, it's for unity!"
> 
> Oh, you don't argue that OSPF = ;covers an use case which is also cover= ed
by
> RIP. So then why are you argu= ing that an use case of MAP is eve= ntually
same
> with the LW46 use case?
> 
> cheers,
> --satoru
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
= ------=_001_NextPart143646225383_=------ From jacni@jacni.com Wed Jun 27 21:35:32 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 E214B11E80D6 for ; Wed, 27 Jun 2012 21:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOqSo7WGjHJr for ; Wed, 27 Jun 2012 21:35:32 -0700 (PDT) Received: from srv05.olivemail.cn (unknown [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 00CA721F85F1 for ; Wed, 27 Jun 2012 21:35:31 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id BA3233801F9 for ; Thu, 28 Jun 2012 00:35:30 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 3C99595000E for ; Thu, 28 Jun 2012 12:35:29 +0800 (CST) Received: from [10.79.98.39] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJDbaQQP3+tPtzZ4AQ--.4494S2; Thu, 28 Jun 2012 12:35:28 +0800 (CST) Message-ID: <4FEBDF0A.50800@jacni.com> Date: Thu, 28 Jun 2012 12:35:22 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: +AWowJDbaQQP3+tPtzZ4AQ--.4494S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGw1fCr4UWF4fAFWUuryxGrg_yoW5CFW8p3 W8Wa1Yyr4kJry8Crn29w1v9FyvvrWftay0gryUK34UX3s0g3W7Kr1SkrW5uF9rWrZ5Cr4j vrWDZry7XF15Zw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUU0bIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnA8YjsxI4VWDJwAYFVCjjxCrM7AEwI8IwI0E74AGY7Cv6cx26r4UM7CY 07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7V C0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41lc7I2 V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MI IYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jQeOXUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEQEko7lRcsyQBRsF Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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, 28 Jun 2012 04:35:33 -0000 On 6/27/2012 Wednesday 11:30 PM, Behcet Sarikaya wrote: > On Mon, Jun 25, 2012 at 6:36 PM, Jacni Qin wrote: >> Re-, >> >> >> On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: >>> On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin wrote: >>>> Hi Behcet, all, >>>> >>>> >>>> On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: >>>>> Folks, >>>>> >>>>> We have published revised version of our draft on multicast extensions >>>>> to DS-Lite at >>>>> >>>>> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt >>>>> >>>> It's been discussed on the list and in the 81st meeting, and concluded >>>> quite >>>> clearly by the WG why this is abandoned. >>>> It tunnels the IGMP packets upwards, replicates the multicast traffic >>>> "per >>>> tunnel", opposite to the property of multicast technology. And these are >>>> problems we're trying to solve. >>>> >>> draft-ietf-softwire-dslite-multicast-02 has nothing to do with >>> DS-Lite and therefore it is not a DS-Lite multicast extensions >>> document as the charter requires. >>> OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates >>> multicast into DS-Lite tunnel. >>> >>> It is not against multicast technology. >> In this way, the efficiency is lost. If operators put the AFTR box deeply in >> the network, far from the end users, as you process the singling messages >> and replicate of traffic per tunnel, the network and the box will crash >> because of the huge burden. >> > That's a big IF. Not everybody has to do it the same way. No, even you distribute AFTRs in the networks, e.g., co-locate the boxes beside BRAS/BNGs, the problems are still there. > The solution in draft-ietf-softwire-dslite-multicast-02 > builds itself something without considering what DS-Lite is doing. Not true, please see below. > As I told you before, DS-Lite unicast is a tunneling technology. If > you don't like it it is not DS-Lite multicast to fix this. > How many times this should be reminded to you? Let's remind you again, What you described in your approach ("Simply enabling multicast based on RFC6333") is the problem that needs to be solved. You're running multicast inside the UNICAST tunnels between B4s and AFTR. By contrast, we considered it. If following your approach to run multicast in the DS-Lite deployment (as stated earlier, we just consider this scenario), there will be problems (e.g., lost of efficiency of multicast, burden of network and devices, ... please see above). That is what we're trying to solve in draft-ietf-softwire-dslite-mulitcast. > >>>> There is no necessity to initiate that kind of discussion once again. >>>> >>> I did not start this discussion. Please check the list. >> >> Again please see above, or check the archive and the offlist messages where >> we've explained it to you in detail. > I also had explained to you that the chairs wanted the two drafts > merged in detail. No, it's been clarified during the meeting and previous discussions, that your approach is the problem that needs to be solved. Cheers, Jacni From sunqi.csnet.thu@gmail.com Wed Jun 27 22:01: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 C567211E810F for ; Wed, 27 Jun 2012 22:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjViriK7sfVc for ; Wed, 27 Jun 2012 22:01:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3A111E8106 for ; Wed, 27 Jun 2012 22:01:44 -0700 (PDT) Received: by dacx6 with SMTP id x6so2398709dac.31 for ; Wed, 27 Jun 2012 22:01:43 -0700 (PDT) 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=qOeY56ZAHib17LDRpHM98tf+mXYR0irYcqaq0efYVco=; b=pF4VRiYd65Fq7dOWBBw7LT6fqr3IqAIK7FB1Qpih2Q+5aXQRcosZKdxsUq2SzYfnld hTd4mP5N2F3TOg6AzABF81SVmEPEo96uw8x4PQPwxU0MV/9Hlej7HILNdra5GysITvAo v+WVysIxpxJW+BKvl+1Z11L39raVtnkEcmEYtC7MO27mIJe5juEsUOSHLRSe9WM2OGqT 5G4jCJ1b6VxcXoatR3brKzSwYb1VIOK4JdJUrHEDYyPjVpuzCbqPOYZWJFR3Clp4OxfB PguqQsNRhlFI9WdLuVJKN3Q1QfIx8cfpgHEjhxiMYJ+a3LPtgmltZyxGwGN2B5hntYLI ljJw== MIME-Version: 1.0 Received: by 10.68.233.132 with SMTP id tw4mr3182526pbc.61.1340859703684; Wed, 27 Jun 2012 22:01:43 -0700 (PDT) Received: by 10.143.7.3 with HTTP; Wed, 27 Jun 2012 22:01:43 -0700 (PDT) In-Reply-To: References: <04DCBF0D-2B31-42E8-A363-22656FBAF447@gmail.com> <1E6988FF-BFE6-4DA4-A7F6-B8BC4205967F@gmail.com> Date: Thu, 28 Jun 2012 13:01:43 +0800 Message-ID: From: Qi Sun To: Satoru Matsushima Content-Type: multipart/alternative; boundary=047d7b33cac654eff104c3813ab5 Cc: Softwires WG Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 28 Jun 2012 05:01:46 -0000 --047d7b33cac654eff104c3813ab5 Content-Type: text/plain; charset=ISO-8859-1 Hi Satoru, In addition to my previous email (not the one you last replyed): DHCPv4 over IPv6 will create/refresh the per-subscriber state. And LW4over6 features to keep it dynamic(on demand). Thanks, Qi On Wed, Jun 27, 2012 at 7:42 PM, Qi Sun wrote: > Hi Satoru, > > Please see inline :) > > Qi Sun > > On Wed, Jun 27, 2012 at 6:27 PM, Satoru Matsushima < > satoru.matsushima@gmail.com> wrote: > >> Qi, >> >> On 2012/06/27, at 19:01, Qi Sun wrote: >> >> > >> > [Qi] DHCPv4 over IPv6 is a provisioning method. And it's about the >> public IPv4 address allocation, NOT about IPv4 address and IPv6 address >> mapping. So there is no state. Please read the draft of DHCPv4 over IPv6 >> for clarification. >> > LW4over6 needs to maintain the binding table on TC. That's stateful. >> >> That sense is 'stateless' in my mind if there's no DHCP state in the BR. >> >> [Qi] What discussed here is about states on data plane, aka the v4-v6 > addressing binding(please refer to joel's email). The binding table could > be dynamic(on-demand) or static. > > >> > Actually in MAP 1:1 mode there will be a binding table right? Here >> comes the question: what will you do if there are new comers or some users >> leaving the network? >> >> it is just an operation in provision. Now I find that LW46 could be >> possible to merged with MAP, or vice versa. thanks. >> > > > [Qi] LW4over6 is a solution targeting at the per-user stateful/binding scenario, pure and clear. > MAP is originally targeting at pure stateless/alogrithmic address mapping scenario, and then comes > to this 1:1 mode due to the theoretical corner case of EA-bits=0, according to you guys. > While I believe the main targets are differnt and paralled > (actually two out of three in 4-over-6 case, > with the 3rd one per-session stateful), I don't think merging is the proper way to proceed. > > Thanks, > Qi > >> >> cheers, >> --satoru > > > --047d7b33cac654eff104c3813ab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Satoru,

In addition to my previous email (not th= e one you last replyed): DHCPv4 over IPv6 will create/refresh the per-subsc= riber state. And LW4over6 features to keep it dynamic(on demand).

Thanks,
Qi

On = Wed, Jun 27, 2012 at 7:42 PM, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:
Hi Satoru,

Please see inl= ine :)

Qi Sun

On Wed, Jun 27, 2012 at 6:27 PM, Satoru Matsushima &= lt;satoru.= matsushima@gmail.com> wrote:
Qi,

On 2012/06/27, at 19:01, Qi Sun wrote:

>
> [Qi] DHCPv4 over IPv6 is a provisioning method. And it'= s about the public IPv4 address allocation, NOT about IPv4 address and IPv6= address mapping. So there is no state. Please read the draft of DHCPv4 ove= r IPv6 for clarification.
> LW4over6 needs to maintain the binding table on TC. That's statefu= l.

That sense is 'stateless' in my mind if there's no DHCP s= tate in the BR.

[Qi] What discussed here is about st= ates on data plane, aka the v4-v6 addressing binding(please refer to joel&#= 39;s email). The binding table=A0could be dynamic(on-demand) or static.
=A0
> Actually in MAP 1:1 mode there will be a binding table right? Here com= es the question: what will you do if there are new comers or some users lea= ving the network?

it is just an operation in provision. Now I find that LW46 could be p= ossible to merged with MAP, or vice versa. thanks.
[Qi]=A0LW4over6=A0is=A0a=A0solution=A0targeting=A0at=A0th= e=A0per-user=A0stateful/binding=A0scenario,=A0pure=A0and=A0clear.
MAP=A0is=A0originally=A0targeting=A0at=A0pure=A0stateless/alogrithmic= =A0address=A0mapping=A0scenario,=A0and=A0then=A0comes to=A0this=A01:1=A0mod= e=A0due=A0to=A0the=A0theoretical=A0corner=A0case=A0of=A0EA-bits=3D0,=A0acco= rding=A0to=A0you=A0guys.
While=A0I=A0believe=A0the=A0main=A0targets are= =A0differnt=A0and=A0paralled (actually=A0two=A0out=A0of=A0three=A0in=A04-ov= er-6=A0case, with=A0the=A03rd=A0one=A0per-session=A0stateful),=A0I=A0don= 9;t=A0think=A0merging=A0is=A0the=A0proper=A0way=A0to=A0proceed.

Thanks,
Qi
=20 Right, it isn't a 'mode' which changes any MAP nature. > this definitely makes the MAP spec clear. if necessary, including this = special case in the MAP draft or in the MAP deployment draft, mentioning = its usage, is what i support unless we discover any other flaws = regarding this.=20 Thanks for clarification. cheers, --satoru= From jacni@jacni.com Wed Jun 27 22:25: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 062E111E80F0 for ; Wed, 27 Jun 2012 22:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBNRZ-D-En8e for ; Wed, 27 Jun 2012 22:25:02 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3A05211E8087 for ; Wed, 27 Jun 2012 22:25:01 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id D81BA3800CA for ; Thu, 28 Jun 2012 01:24:57 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 50E873400D9 for ; Thu, 28 Jun 2012 13:24:56 +0800 (CST) Received: from [10.79.98.39] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJALoQKK6utPUWl4AQ--.8257S2; Thu, 28 Jun 2012 13:24:50 +0800 (CST) Message-ID: <4FEBEA85.6010201@jacni.com> Date: Thu, 28 Jun 2012 13:24:21 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stig Venaas References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> In-Reply-To: <4FEB6831.5060100@venaas.com> Content-Type: multipart/alternative; boundary="------------070904010001080608030001" X-CM-TRANSID: +AWowJALoQKK6utPUWl4AQ--.8257S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Cw1DZr47XF4rAFyxKryUJrb_yoW8WF1fpa 18Gw4Ygr4kAr97Aw1kZws5Za4Ykrsa9FWUAas8K343Zas8G3ZrtrySkw4YkF9rWws8Cr4a vFsIyr98A3Z8A3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUU0bIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnWxYjsxI4VWkCwAYFVCjjxCrM7AEwI8IwI0E74AGY7Cv6cx26r4UM7CY 07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I 8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY 0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwC2zVAF1VAY17CE14v26r126r1DMIIYrx kI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jwPEfUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEQEko7lRcsyQBUsA Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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, 28 Jun 2012 05:25:03 -0000 This is a multi-part message in MIME format. --------------070904010001080608030001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stig, Thanks for you comments and support, please see below inline. On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote: > FWIW, here is my take on this. > > > On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: > [...] >> That's a big IF. Not everybody has to do it the same way. >> >> The solution in draft-ietf-softwire-dslite-multicast-02 >> builds itself something without considering what DS-Lite is doing. >> As I told you before, DS-Lite unicast is a tunneling technology. If >> you don't like it it is not DS-Lite multicast to fix this. >> How many times this should be reminded to you? > > draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing > specific to DS-Lite, and I've been saying that the draft should be > updated to reflect that. > > However, even though it is generic, I think it is a good solution for > use in DS-Lite deployments (in addition to many other deployments). As discussed in the previous messages of the thread, our motive is solve the problems for those who want multicast in their DS-Lite deployment. So we limited the scope. Where the DS-Lite is not deployed, it doesn't apply. If some pieces of the approach can be reused in the future, to solve the multicast issues in other deployments, that'd be good. While personally, I'd prefer we stay focus on the currently scenario. Extensions if needed, may be raised respectively for other deployments. More are detailed in, http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. Cheers, Jacni > > Whether additional solutions are needed for DS-Lite is something the > WG should consider. Maybe it already has, I haven't paid enough > attention. > > Stig > --------------070904010001080608030001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stig,

Thanks for you comments and support, please see below inline.
On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote:
FWIW, here is my take on this.


On 6/27/2012 8:30 AM, Behcet Sarikaya wrote:
[...]
That's a big IF. Not everybody has to do it the same way.

The solution in draft-ietf-softwire-dslite-multicast-02
builds itself something without considering what DS-Lite is doing.
As I told you before, DS-Lite unicast is a tunneling technology. If
you don't like it it is not DS-Lite multicast to fix this.
How many times this should be reminded to you?

draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing
specific to DS-Lite, and I've been saying that the draft should be
updated to reflect that.

However, even though it is generic, I think it is a good solution for
use in DS-Lite deployments (in addition to many other deployments).
As discussed in the previous messages of the thread, our motive is solve the problems
for those who want multicast in their DS-Lite deployment.
So we limited the scope. Where the DS-Lite is not deployed, it doesn't apply.

If some pieces of the approach can be reused in the future, to solve the multicast issues in
other deployments, that'd be good.
While personally, I'd prefer we stay focus on the currently scenario.
Extensions if needed, may be raised respectively for other deployments.
More are detailed in, http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00.


Cheers,
Jacni

Whether additional solutions are needed for DS-Lite is something the
WG should consider. Maybe it already has, I haven't paid enough
attention.

Stig



--------------070904010001080608030001-- From bingxuere@gmail.com Wed Jun 27 23:09: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 0CF1821F861C for ; Wed, 27 Jun 2012 23:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkDVMsY-UwYH for ; Wed, 27 Jun 2012 23:09:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92BC411E8180 for ; Wed, 27 Jun 2012 19:09:22 -0700 (PDT) Received: by yenq13 with SMTP id q13so1626178yen.31 for ; Wed, 27 Jun 2012 19:09:22 -0700 (PDT) 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=bQZa2rr6BxSzyvBXaNHo7a1xE7nwSKQHgoDSTlYgJTI=; b=LxDg1GqW6HM8xvTqY+AnNV/HJpGGXm822WJwReSyexM7aaOisqNUY+fmdOxz7B6NIt 395ff6fknrIaegaQwpjPeXPAual5vtfreMbB7Exp4LybAuRETk/L0a8VSbrRZIVd75k+ uz4tGWzWh7jD3qt/+czlfkp29iVjO+tO9hExamIcBL4xLeO610t35nFR3nn6jOmzsKK9 dRQeWsVjIJxUyMgqOneqntovkImAcKK62hi8sxZcOqma4hyChS6QxzGg9fj6/G84x9iV 76J+I7iQAnfaMrGJz7QFghnP4TSu6UkLDCC5koWqJ1QM0LdCuIlrxh+ba7IJIbLf6ziM OY2Q== Received: by 10.42.146.6 with SMTP id h6mr4335icv.53.1340849361527; Wed, 27 Jun 2012 19:09:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 27 Jun 2012 19:08:40 -0700 (PDT) In-Reply-To: References: <10CE32B3-7DFB-47F4-85F1-F591C613689A@gmail.com> <2012062514514640804415@gmail.com> <459A6E94-9534-4203-940A-B04891B49DAB@ipinfusion.com> From: Qiong Date: Thu, 28 Jun 2012 10:08:40 +0800 Message-ID: To: Tetsuya Murakami Content-Type: multipart/alternative; boundary=90e6ba6e8716e4219804c37ed1a2 Cc: softwires WG , Yong Cui Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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, 28 Jun 2012 06:09:16 -0000 --90e6ba6e8716e4219804c37ed1a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tetsuya, Well, then you mean this implementation is mode 1:1 A (raised by Maoke in review on the mode 1:1 thread). Sorry I misunderstand your meaning about this 1:1 mode. It clarifies a lot! Thanks! Best wishes Qiong On Thu, Jun 28, 2012 at 9:58 AM, Tetsuya Murakami < Tetsuya.Murakami@ipinfusion.com> wrote: > Hi Qiong, > > According to our current implementation, BR requires the following > configuration. > > - Rule IPv6 prefix > - Rule IPv4 prefix > - EA-bit length > - PSID offset length (optional. default value is 4) > - subnet id (optional) > > BR can maintain multiple set of the information described above as > BMR/FMR. > > CE can also have multiple set of informations as BMR/FMR. In addition, > CE can have a DMR including BR prefix/address. > > In terms of the forwarding mode, this can be configured per the map > tunnel instance which is associated with BMR. Right now, we don't allow t= o > configure PSID itself explicitly. This can be gotten from a delegated IPv= 6 > prefix with the above mapping rule. > > If the ea-bit length is set to 0, then our implementation does not > retrieve any value from a delegated IPv6 prefix which is matched to Rule > IPv6 prefix. > > Thanks, > Tetsuya Murakami > > On 2012/06/27, at 18:01, Qiong wrote: > > Hi Tetsuya, > > With regard to implementaion, what did you configure in BR ? > > In the specification, it says the BR and CE MUST be configured with the > following MAP elements. > o The End-User IPv6 prefix (Part of the normal IPv6 provisioning). > o The Basic Mapping Rule and optionally the Forwarding Mapping Rules > o The Default Mapping Rule with the BR IPv6 prefix or address > o Hub and spoke mode or Mesh mode. > > Did you configure PSID explicitly ? > > If yes, the implementation does not consistent with the specification. If > not, it can not been applied to the so-called 1:1 mode. > > Best wishes > Qiong > > On Tue, Jun 26, 2012 at 6:50 AM, Tetsuya Murakami < > Tetsuya.Murakami@ipinfusion.com> wrote: > >> +1. >> >> In fact, we have already done the implementation prior to the current >> MAP draft. But there is no change in our implementation in order to supp= ort >> the current draft. In addition, our implementation has no limitation for >> the number of mapping rules. It depends on the available memory size onl= y. >> So, our implementation can allow 1:1 as well as N:1. >> >> Thanks, >> Tetsuya Murakami >> >> On 2012/06/25, at 7:24, Wojciech Dec wrote: >> >> Hi, >> >> taking a step back to discuss some items in more detail, and hopefully >> move this discussion forward: >> >> 1. Domain size >> The MAP architecture does not prescribe the size of a domain, and neithe= r >> does it prescribe the number of rules to be used. There is nothing in th= e >> technology, except vendor implementation limits or practical sense (or >> both), to prevent MAP domains from defining 1 domain =3D 1 CPE. This was= a >> day 1 characteristic of MAP drafts. >> Choosing to deploy or implement MAP with a configuration supporting 1 >> rule, 100 rules or 100k rules or domains is a vendor's and/or operator's >> choice. Nobody is stating that deployment is to be limited to X rules, n= or >> that a near infinite number of rules is reasonable. These are general >> points that apply to DS-lite state as well as the "Light Weight 4 over 6= " >> or "stateless deterministic NAT", and pretty much any technology for tha= t >> matter. >> >> 2. Stateless DOES NOT mean configuration-less >> There appears to be confusion between the concept of stateless and >> configuration-less. MAP domains are based on configured rules, that are >> provisioned/applied through means that are currently outside the scope o= f >> Softwire drafts - this is configuration state, and this was and continue= s >> to be a characteristic of MAP. >> Further more, unlike some of the other proposals, MAP allows to optimize >> the amount of configuration needed in cases where this is viable. In oth= er >> words, MAP does NOT exclusively force 1:1 rule configuration, but also >> allows N:1. >> >> 3. Stateless has no data plane induced state >> A major difference between stateless (eg MAP) and stateful (eg Carrier >> Grade NAT44/Ds-Lite) solutions is that the latter are characterised by >> dynamic core node forwarding state that is directly driven by user >> data-plane traffic (eg new IP flows). MAP does not rely on such dynamic >> state, never did. >> >> 4. No change of MAP spec >> The updated MAP draft does not change the MAP architecture nor its >> technical underpinnings. In fact there are no changes, bar editorial to = the >> normative parts of MAP, something that is proven by existing >> implementations prior to this draft supporting the current draft. A few >> individuals appear to object to new descriptive text which highlights th= e >> usage of MAP, eg in 1:1. Removing that text will not change the matter t= hat >> MAP allows such usage. Prohibiting such use by specification would actua= lly >> require a spec change, besides being unreasonable. >> >> 5. What is the problem? >> We're pleased to see a growing understanding of MAP's applicability to >> solve problems, incl v4-v6 address independence, when needed. Given that >> the emails on this thread do not appear to bring forward any technical >> issues with the MAP solution, could we know WHY we need other solutions = to >> the problem, or what is the problem that remains to be solved? >> >> Taking the liberty to speak on behalf of the other MAP authors, I would >> like to say that we all remain open for collaboration with all WG member= s >> in terms of arriving at a minimal set of reasonable solutions that solve >> problems that the community cares about. We also trust that our renewed = WG >> leadership will finally help us all in getting there. >> >> Regards, >> Woj. >> >> On 25 June 2012 08:51, Qi Sun wrote: >> >>> ** >>> Hi Satoru, >>> >>> In MAP 1:1 mode, if there are 10000000 subscribers, there would be >>> 10000000 MAP domains which a BR has to manage. I think that will create= a >>> huge mapping table on the BR, which is called 'state' that stateful >>> solutions deal with. >>> >>> Best Regards! >>> >>> ------------------------------ >>> Qi Sun >>> >>> *From:* Satoru Matsushima >>> *Date:* 2012-06-25 10:27 >>> *To:* Lee, Yiu >>> *CC:* softwires@ietf.org; Yong Cui >>> *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does >>> NOT reflect the consensus from the WG >>> Hi Yiu, >>> >>> No, that's a misunderstanding. >>> >>> Current MAP specify the case for ea-len is 'zero'. It is 'per-subscribe= r mapping' in stateless manner, not to introduce 'per-flow NAT binding' or = 'per-subscriber state on demand'. >>> >>> cheers, >>> --satoru >>> >>> On 2012/06/25, at 2:32, Lee, Yiu wrote: >>> >>> > Dear Satoru and MAP-DT >>> > >>> > I echo what Peng and Qiong said. When the WG agreed working on the >>> >>> > stateless solution, it was very clear stated that the solution would = not >>> > maintain states in the network. If the 1:1 mode changed this, this no >>> >>> > longer matched the requirements stated in the stateless motivation dr= aft, >>> > thus, it would disqualify MAP as a solution for the motivation draft. >>> > >>> > AFAIK, the MAP Design Team could propose a change, but such a dramati= c >>> >>> > change by introducing states in the network would require WG approval= . I >>> > would like the chairs to clarify this. >>> > >>> > Thanks, >>> > Yiu >>> > >>> > >>> > On 6/24/12 12:21 PM, "Peng Wu" wrote: >>> > >>> >> Hi Qiong, Satoru and all, >>> >> >>> >>> >> I should thank Qiong for pointing this out. I gotta say I'm a bit sh= ocked. >>> >> If I understand the procedures of IETF correctly, a WG document shou= ld >>> >> reflect the consensus of the WG. MAP is approved by the WG as a >>> >> stateless solution. As a participator in Softwire, I didn't get the >>> >> information anywhere that the MAP WG document would cover the >>> >> so-called 1:1, in fact per-user stateful mode before it was released= , >>> >> not to say discuss in the WG. Don't the WG need to approve such big >>> >> change anymore? >>> >> >>> >> Now let me provide my impression as an outsider of the MAP DT. You >>> >> guys make great effort to build the solution, The address compositio= n, >>> >> the GMA algorithm, the different types of address mapping rules. >>> >> should be quite difficult to pull together such sophisticated ideas.= I >>> >> guess that's what it takes to achieve the benifits of statelessness. >>> >> And I admire that, bravo. Then, all of a sudden, you guys are saying= , >>> >> let's apply this sophisticated method to the different problem, by >>> >> dropping quite some comlexity and twistting the mechanism a bit, see= ms >>> >> it may work. Considering the problem are now solved in a more pure a= nd >>> >> clear way, I'm sorry but I CANNOT follow the logic here. >>> >> >>> >> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima >>> >> wrote: >>> >>> Hi Qiong, >>> >>> >>> >>> I'm disagree with your opinion. >>> >>> >>> >>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed = in >>> >>> the DT. >>> >>> >>> 2. MAP just covers so called '1:1 mode' with most granular mapping = rule >>> >>> for CEs provisioning, which is as one of its characteristics. >>> >>> 3. The motivation draft does not restrict that as you stated, just >>> >>> 'assumed', it's neither 'MUST' nor 'SHOULD'. >>> >>> >>> >>> Best regards, >>> >>> --satoru >>> >>> >>> >>> >>> >>> On 2012/06/24, at 14:35, Qiong wrote: >>> >>> >>> >>>> Hi all, >>> >>>> >>> >>> >>>> As we all know, once an individual draft is adopted as a WG draft,= it >>> >>>> is owned by the whole WG, rather than just the editors. Just as Re= mi >>> >>> >>>> said, the normal procedure to follow is to reach WG consensus _bef= ore_ >>> >>>> posting a newly edited version. >>> >>>> >>> >>>> From draft-mdt-softwire-mapping-address-and-port-03 to >>> >>> >>>> draft-ietf-softwire-map-00, there are several changes between them= . In >>> >>> >>>> particular, the newly introduced "1:1 mode", which decouples IPv4 = and >>> >>>> IPv6 addressing, has never been discussed openly in the WG mailing >>> >>>> list, or even in the MAP design team either. >>> >>>> >>> >>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation >>> >>>> draft. The motivation draft has clearly defines the "Stateless 4/6 >>> >>>> solution" as follows: >>> >>>> >>> >>>> Stateless 4/6 solution denotes a solution which does not require a= ny >>> >>> >>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by = any >>> >>>> IP address sharing function in the Service Provider's network. Thi= s >>> >>> >>>> category of solutions assumes a dependency between an IPv6 prefix = and >>> >>>> IPv4 address. >>> >>>> >>> >>>> AFAIK what the WG has adopted MAP related draft is >>> >>>> draft-mdt-softwire-mapping-address-and-port-03, NOT >>> >>> >>>> draft-ietf-softwire-map-00. And the stateless solution should =C2= =B3response >>> >>> >>>> to the solution motivation document=C2=B2 according to the Softwir= e charter. >>> >>> >>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG = draft. >>> >>>> >>> >>>> We can all recall that our softwire WG has worked on stateless >>> >>>> solutions for more than one and a half years, and we have achieved= a >>> >>> >>>> lot of work which has been documented in charter, stateless motiva= tion, >>> >>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the bas= ic >>> >>>> "stateless" principle and the MAP design team is also working on i= t >>> >>>> together to find a better algorithm, address format, etc. So it is >>> >>> >>>> really not appropriate to make such changes when MAP is adopted as= a WG >>> >>>> item in such a short time. >>> >>>> >>> >>> >>>> From this perspective, draft-ietf-softwire-map-00 can only be rega= rded >>> >>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even t= he >>> >>>> output of MAP design team. >>> >>>> >>> >>>> Best wishes >>> >>>> >>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =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 >>> >> _______________________________________________ >>> >> 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 >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 --90e6ba6e8716e4219804c37ed1a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tetsuya,

Well, then you mean this implementation is mode 1:1 A (r= aised by Maoke in review on the mode 1:1 thread).

Sorry I misunderst= and your meaning about this 1:1 mode. It clarifies a lot!

Thanks!
Best wishes
Qiong

On Thu, Jun 28, = 2012 at 9:58 AM, Tetsuya Murakami <Tetsuya.Murakami@ipinfusi= on.com> wrote:
Hi Qiong,

According to our current implementation, BR requires the following con= figuration.

- Rule IPv6 prefix
- Rule IPv4 prefix
- EA-bit length
- PSID offset length (optional. default value is 4)
- subnet id (optional)

BR can maintain multiple set of the information described above as BMR= /FMR.

CE can also have multiple set of informations as BMR/FMR. In addition,= CE can have a DMR including BR prefix/address.

In terms of the forwarding mode, this can be configured per the map tu= nnel instance which is associated with BMR. Right now, we don't allow t= o configure PSID itself explicitly. This can be gotten from a delegated IPv= 6 prefix with the above mapping rule.

If the ea-bit length is set to 0, then our implementation does not ret= rieve any value from a delegated IPv6 prefix which is matched to Rule IPv6 = prefix.

Thanks,
Tetsuya Murakami

On 2012/06/27, at 18:01, Qiong wrote:

Hi Tetsuya,

With regard to implementaion, what did you configure in BR ?

In the specification, it says the BR and CE MUST be configured with the fol= lowing MAP elements.
o=C2=A0 The End-User IPv6 prefix (Part of the normal IPv6 provisioning). o=C2=A0 The Basic Mapping Rule and optionally the Forwarding Mapping Rules<= br> o=C2=A0 The Default Mapping Rule with the BR IPv6 prefix or address
o=C2=A0 Hub and spoke mode or Mesh mode.

Did you configure PSID explicitly ?

If yes, the implementation does not consistent with the specification. If n= ot, it can not been applied to the so-called 1:1 mode.

Best wishes
Qiong

On Tue, Jun 26, 2012 at 6:50 AM, Tetsuya Murakam= i <Te= tsuya.Murakami@ipinfusion.com> wrote:
+1.

In fact, we have already done the implementation prior to the current = MAP draft. But there is no change in our implementation in order to support= the current draft. In addition, our implementation has no limitation for t= he number of mapping rules. It depends on the available memory size only. So, our implementation can allow 1:1 as= well as N:1.

Thanks,
Tetsuya Murakami

On 2012/06/25, at 7:24, Wojciech Dec wrote:

Hi,

taking a step back to discuss some items in more detail, and hopefully move= this discussion forward:

1. Domain size
The MAP architecture does not prescribe the size of a domain, and neither d= oes it prescribe the number of rules to be used. There is nothing in the te= chnology, except vendor implementation limits or practical sense (or both),= to prevent MAP domains from defining 1 domain =3D 1 CPE. This was a day 1 characteristic of MAP drafts.
Choosing to deploy or implement MAP with a configuration supporting 1 rule,= 100 rules or 100k rules or domains is a vendor's and/or operator's= choice. Nobody is stating that deployment is to be limited to X rules, nor= that a near infinite number of rules is reasonable. These are general points that apply to DS-lite state as well a= s the "Light Weight 4 over 6" or "stateless deterministic NA= T", and pretty much any technology for that matter.

2. Stateless DOES NOT mean configuration-less
There appears to be confusion between the concept of stateless and configur= ation-less. MAP domains are based on configured rules, that are provisioned= /applied through means that are currently outside the scope of Softwire dra= fts - this is configuration state, and this was and continues to be a characteristic of MAP.
Further more, unlike some of the other proposals, MAP allows to optimize th= e amount of configuration needed in cases where this is viable. In other wo= rds, MAP does NOT exclusively force 1:1 rule configuration, but also allows= N:1.

3. Stateless has no data plane induced state
A major difference between stateless (eg MAP) and stateful (eg Carrier Grad= e NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic = core node forwarding state that is directly driven by user data-plane traff= ic (eg new IP flows). MAP does not rely on such dynamic state, never did.

4. No change of MAP spec
The updated MAP draft does not change the MAP architecture nor its technica= l underpinnings. In fact there are no changes, bar editorial to the normati= ve parts of MAP, something that is proven by existing implementations prior= to this draft supporting the current draft. A few individuals appear to object to new descriptive text which hi= ghlights the usage of MAP, eg in 1:1. Removing that text will not change th= e matter that MAP allows such usage. Prohibiting such use by specification = would actually require a spec change, besides being unreasonable.

5. What is the problem?
We're=C2=A0 pleased to see a growing understanding of MAP's applica= bility to solve problems, incl v4-v6 address independence, when needed. Giv= en that the emails on this thread do not appear to bring forward any techni= cal issues with the MAP solution, could we know WHY we need other solutions to the problem, or what is the problem that re= mains to be solved?

Taking the liberty to speak on behalf of the other MAP authors, I would lik= e to say that we all remain open for collaboration with all WG members in t= erms of arriving at a minimal set of reasonable solutions that solve proble= ms that the community cares about. We also trust that our renewed WG leadership will finally help us all in g= etting there.

Regards,
Woj.

On 25 June 2012 08:51, Qi Sun = <sunqi.cs= net.thu@gmail.com> wrote:
Hi Satoru,
=C2=A0
In MAP 1:1 mode, if there are 10000000 subscribers, there would be 100= 00000 MAP domains which a BR has to manage. I think that will create a huge= mapping table on the BR, which is called 'state' that stateful sol= utions deal with.
=C2=A0
Best Regards!
=C2=A0
Qi Sun
=C2=A0
Date:=C2=A02012-06-25=C2=A010:27
To:=C2=A0Lee, Yiu
Subject:=C2=A0Re: [Softwires] [Softwire] draft-ietf-softwire-ma= p-00 does NOT reflect the consensus from the WG
Hi=C2=A0Yiu,
=C2=A0
No,=C2=A0that's=C2=A0a=C2=A0misunderstanding.
Current=C2=A0MAP=C2=A0specify=C2=A0the=C2=A0case=C2=A0for=C2=A0ea-len= =C2=A0is=C2=A0'zero'.=C2=A0It=C2=A0is=C2=A0'per-subscriber=C2= =A0mapping'=C2=A0in=C2=A0stateless=C2=A0manner,=C2=A0not=C2=A0to=C2=A0i= ntroduce=C2=A0'per-flow=C2=A0NAT=C2=A0binding'=C2=A0or=C2=A0'pe= r-subscriber=C2=A0state=C2=A0on=C2=A0demand'.
=C2=A0
cheers,
--satoru
=C2=A0
On=C2=A02012/06/25,=C2=A0at=C2=A02:32,=C2=A0Lee,=C2=A0Yiu=C2=A0wrote:<= /div>
=C2=A0
>=C2=A0Dear=C2=A0Satoru=C2=A0and=C2=A0MAP-DT
>=C2=A0
>=C2=A0I=C2=A0echo=C2=A0what=C2=A0Peng=C2=A0and=C2=A0Qiong=C2=A0sai= d.=C2=A0When=C2=A0the=C2=A0WG=C2=A0agreed=C2=A0working=C2=A0on=C2=A0the
>=C2=A0stateless=C2=A0solution,=C2=A0it=C2=A0was=C2=A0very=C2=A0cle= ar=C2=A0stated=C2=A0that=C2=A0the=C2=A0solution=C2=A0would=C2=A0not
>=C2=A0maintain=C2=A0states=C2=A0in=C2=A0the=C2=A0network.=C2=A0If= =C2=A0the=C2=A01:1=C2=A0mode=C2=A0changed=C2=A0this,=C2=A0this=C2=A0no
>=C2=A0longer=C2=A0matched=C2=A0the=C2=A0requirements=C2=A0stated= =C2=A0in=C2=A0the=C2=A0stateless=C2=A0motivation=C2=A0draft,
>=C2=A0thus,=C2=A0it=C2=A0would=C2=A0disqualify=C2=A0MAP=C2=A0as=C2= =A0a=C2=A0solution=C2=A0for=C2=A0the=C2=A0motivation=C2=A0draft.
>=C2=A0
>=C2=A0AFAIK,=C2=A0the=C2=A0MAP=C2=A0Design=C2=A0Team=C2=A0could=C2= =A0propose=C2=A0a=C2=A0change,=C2=A0but=C2=A0such=C2=A0a=C2=A0dramatic
>=C2=A0change=C2=A0by=C2=A0introducing=C2=A0states=C2=A0in=C2=A0the= =C2=A0network=C2=A0would=C2=A0require=C2=A0WG=C2=A0approval.=C2=A0I
>=C2=A0would=C2=A0like=C2=A0the=C2=A0chairs=C2=A0to=C2=A0clarify=C2= =A0this.
>=C2=A0
>=C2=A0Thanks,
>=C2=A0Yiu
>=C2=A0
>=C2=A0
>=C2=A0On=C2=A06/24/12=C2=A012:21=C2=A0PM,=C2=A0"Peng=C2=A0Wu&= quot;=C2=A0<pe= ngwu.thu@gmail.com>=C2=A0wrote:
>=C2=A0
>>=C2=A0Hi=C2=A0Qiong,=C2=A0Satoru=C2=A0and=C2=A0all,
>>=C2=A0
>>=C2=A0I=C2=A0should=C2=A0thank=C2=A0Qiong=C2=A0for=C2=A0pointi= ng=C2=A0this=C2=A0out.=C2=A0I=C2=A0gotta=C2=A0say=C2=A0I'm=C2=A0a=C2=A0= bit=C2=A0shocked.
>>=C2=A0If=C2=A0I=C2=A0understand=C2=A0the=C2=A0procedures=C2=A0= of=C2=A0IETF=C2=A0correctly,=C2=A0a=C2=A0WG=C2=A0document=C2=A0should
>>=C2=A0reflect=C2=A0the=C2=A0consensus=C2=A0of=C2=A0the=C2=A0WG= .=C2=A0MAP=C2=A0is=C2=A0approved=C2=A0by=C2=A0the=C2=A0WG=C2=A0as=C2=A0a
>>=C2=A0stateless=C2=A0solution.=C2=A0As=C2=A0a=C2=A0participato= r=C2=A0in=C2=A0Softwire,=C2=A0I=C2=A0didn't=C2=A0get=C2=A0the
>>=C2=A0information=C2=A0anywhere=C2=A0that=C2=A0the=C2=A0MAP=C2= =A0WG=C2=A0document=C2=A0would=C2=A0cover=C2=A0the
>>=C2=A0so-called=C2=A01:1,=C2=A0in=C2=A0fact=C2=A0per-user=C2= =A0stateful=C2=A0mode=C2=A0before=C2=A0it=C2=A0was=C2=A0released,
>>=C2=A0not=C2=A0to=C2=A0say=C2=A0discuss=C2=A0in=C2=A0the=C2=A0= WG.=C2=A0Don't=C2=A0the=C2=A0WG=C2=A0need=C2=A0to=C2=A0approve=C2=A0suc= h=C2=A0big
>>=C2=A0change=C2=A0anymore?
>>=C2=A0
>>=C2=A0Now=C2=A0let=C2=A0me=C2=A0provide=C2=A0my=C2=A0impressio= n=C2=A0as=C2=A0an=C2=A0outsider=C2=A0of=C2=A0the=C2=A0MAP=C2=A0DT.=C2=A0You=
>>=C2=A0guys=C2=A0make=C2=A0great=C2=A0effort=C2=A0to=C2=A0build= =C2=A0the=C2=A0solution,=C2=A0The=C2=A0address=C2=A0composition,
>>=C2=A0the=C2=A0GMA=C2=A0algorithm,=C2=A0the=C2=A0different=C2= =A0types=C2=A0of=C2=A0address=C2=A0mapping=C2=A0rules.
>>=C2=A0should=C2=A0be=C2=A0quite=C2=A0difficult=C2=A0to=C2=A0pu= ll=C2=A0together=C2=A0such=C2=A0sophisticated=C2=A0ideas.=C2=A0I
>>=C2=A0guess=C2=A0that's=C2=A0what=C2=A0it=C2=A0takes=C2=A0= to=C2=A0achieve=C2=A0the=C2=A0benifits=C2=A0of=C2=A0statelessness.
>>=C2=A0And=C2=A0I=C2=A0admire=C2=A0that,=C2=A0bravo.=C2=A0Then,= =C2=A0all=C2=A0of=C2=A0a=C2=A0sudden,=C2=A0you=C2=A0guys=C2=A0are=C2=A0sayi= ng,
>>=C2=A0let's=C2=A0apply=C2=A0this=C2=A0sophisticated=C2=A0m= ethod=C2=A0to=C2=A0the=C2=A0different=C2=A0problem,=C2=A0by
>>=C2=A0dropping=C2=A0quite=C2=A0some=C2=A0comlexity=C2=A0and=C2= =A0twistting=C2=A0the=C2=A0mechanism=C2=A0a=C2=A0bit,=C2=A0seems
>>=C2=A0it=C2=A0may=C2=A0work.=C2=A0Considering=C2=A0the=C2=A0pr= oblem=C2=A0are=C2=A0now=C2=A0solved=C2=A0in=C2=A0a=C2=A0more=C2=A0pure=C2= =A0and
>>=C2=A0clear=C2=A0way,=C2=A0I'm=C2=A0sorry=C2=A0but=C2=A0I= =C2=A0CANNOT=C2=A0follow=C2=A0the=C2=A0logic=C2=A0here.
>>=C2=A0
>>=C2=A0On=C2=A0Sun,=C2=A0Jun=C2=A024,=C2=A02012=C2=A0at=C2=A02:= 00=C2=A0PM,=C2=A0Satoru=C2=A0Matsushima
>>=C2=A0<satoru.matsushima@gmail.com>=C2=A0wrote:
>>>=C2=A0Hi=C2=A0Qiong,
>>>=C2=A0
>>>=C2=A0I'm=C2=A0disagree=C2=A0with=C2=A0your=C2=A0opini= on.
>>>=C2=A0
>>>=C2=A01.=C2=A0Recent=C2=A0changes=C2=A0in=C2=A0draft-ietf-= softwire-map-00=C2=A0has=C2=A0been=C2=A0discussed=C2=A0in
>>>=C2=A0the=C2=A0DT.
>>>=C2=A02.=C2=A0MAP=C2=A0just=C2=A0covers=C2=A0so=C2=A0calle= d=C2=A0'1:1=C2=A0mode'=C2=A0with=C2=A0most=C2=A0granular=C2=A0mappi= ng=C2=A0rule
>>>=C2=A0for=C2=A0CEs=C2=A0provisioning,=C2=A0which=C2=A0is= =C2=A0as=C2=A0one=C2=A0of=C2=A0its=C2=A0characteristics.
>>>=C2=A03.=C2=A0The=C2=A0motivation=C2=A0draft=C2=A0does=C2= =A0not=C2=A0restrict=C2=A0that=C2=A0as=C2=A0you=C2=A0stated,=C2=A0just
>>>=C2=A0'assumed',=C2=A0it's=C2=A0neither=C2=A0&= #39;MUST'=C2=A0nor=C2=A0'SHOULD'.
>>>=C2=A0
>>>=C2=A0Best=C2=A0regards,
>>>=C2=A0--satoru
>>>=C2=A0
>>>=C2=A0
>>>=C2=A0On=C2=A02012/06/24,=C2=A0at=C2=A014:35,=C2=A0Qiong= =C2=A0wrote:
>>>=C2=A0
>>>>=C2=A0Hi=C2=A0all,
>>>>=C2=A0
>>>>=C2=A0As=C2=A0we=C2=A0all=C2=A0know,=C2=A0once=C2=A0an= =C2=A0individual=C2=A0draft=C2=A0is=C2=A0adopted=C2=A0as=C2=A0a=C2=A0WG=C2= =A0draft,=C2=A0it
>>>>=C2=A0is=C2=A0owned=C2=A0by=C2=A0the=C2=A0whole=C2=A0W= G,=C2=A0rather=C2=A0than=C2=A0just=C2=A0the=C2=A0editors.=C2=A0Just=C2=A0as= =C2=A0Remi
>>>>=C2=A0said,=C2=A0the=C2=A0normal=C2=A0procedure=C2=A0t= o=C2=A0follow=C2=A0is=C2=A0to=C2=A0reach=C2=A0WG=C2=A0consensus=C2=A0_befor= e_
>>>>=C2=A0posting=C2=A0a=C2=A0newly=C2=A0edited=C2=A0versi= on.
>>>>=C2=A0
>>>>=C2=A0From=C2=A0draft-mdt-softwire-mapping-address-and= -port-03=C2=A0to
>>>>=C2=A0draft-ietf-softwire-map-00,=C2=A0there=C2=A0are= =C2=A0several=C2=A0changes=C2=A0between=C2=A0them.=C2=A0In
>>>>=C2=A0particular,=C2=A0the=C2=A0newly=C2=A0introduced= =C2=A0"1:1=C2=A0mode",=C2=A0which=C2=A0decouples=C2=A0IPv4=C2=A0a= nd
>>>>=C2=A0IPv6=C2=A0addressing,=C2=A0has=C2=A0never=C2=A0b= een=C2=A0discussed=C2=A0openly=C2=A0in=C2=A0the=C2=A0WG=C2=A0mailing
>>>>=C2=A0list,=C2=A0or=C2=A0even=C2=A0in=C2=A0the=C2=A0MA= P=C2=A0design=C2=A0team=C2=A0either.
>>>>=C2=A0
>>>>=C2=A0Actually,=C2=A0this=C2=A0"1:1=C2=A0mode&quo= t;=C2=A0is=C2=A0against=C2=A0the=C2=A0stateless-4v6-motivation
>>>>=C2=A0draft.=C2=A0The=C2=A0motivation=C2=A0draft=C2=A0= has=C2=A0clearly=C2=A0defines=C2=A0the=C2=A0"Stateless=C2=A04/6
>>>>=C2=A0solution"=C2=A0as=C2=A0follows:
>>>>=C2=A0
>>>>=C2=A0Stateless=C2=A04/6=C2=A0solution=C2=A0denotes=C2= =A0a=C2=A0solution=C2=A0which=C2=A0does=C2=A0not=C2=A0require=C2=A0any
>>>>=C2=A0per-user=C2=A0state=C2=A0(see=C2=A0Section=C2=A0= 2.3=C2=A0of=C2=A0[RFC1958])=C2=A0to=C2=A0be=C2=A0maintained=C2=A0by=C2=A0an= y
>>>>=C2=A0IP=C2=A0address=C2=A0sharing=C2=A0function=C2=A0= in=C2=A0the=C2=A0Service=C2=A0Provider's=C2=A0network.=C2=A0This
>>>>=C2=A0category=C2=A0of=C2=A0solutions=C2=A0assumes=C2= =A0a=C2=A0dependency=C2=A0between=C2=A0an=C2=A0IPv6=C2=A0prefix=C2=A0and
>>>>=C2=A0IPv4=C2=A0address.
>>>>=C2=A0
>>>>=C2=A0AFAIK=C2=A0what=C2=A0the=C2=A0WG=C2=A0has=C2=A0a= dopted=C2=A0MAP=C2=A0related=C2=A0draft=C2=A0is
>>>>=C2=A0draft-mdt-softwire-mapping-address-and-port-03,= =C2=A0NOT
>>>>=C2=A0draft-ietf-softwire-map-00.=C2=A0And=C2=A0the=C2= =A0stateless=C2=A0solution=C2=A0should=C2=A0=C2=B3response
>>>>=C2=A0to=C2=A0the=C2=A0solution=C2=A0motivation=C2=A0d= ocument=C2=B2=C2=A0according=C2=A0to=C2=A0the=C2=A0Softwire=C2=A0charter.
>>>>=C2=A0That=C2=A0means=C2=A0draft-ietf-softwire-map-00= =C2=A0IS=C2=A0NOT=C2=A0QUALIFIED=C2=A0to=C2=A0be=C2=A0a=C2=A0WG=C2=A0draft.=
>>>>=C2=A0
>>>>=C2=A0We=C2=A0can=C2=A0all=C2=A0recall=C2=A0that=C2=A0= our=C2=A0softwire=C2=A0WG=C2=A0has=C2=A0worked=C2=A0on=C2=A0stateless
>>>>=C2=A0solutions=C2=A0for=C2=A0more=C2=A0than=C2=A0one= =C2=A0and=C2=A0a=C2=A0half=C2=A0years,=C2=A0and=C2=A0we=C2=A0have=C2=A0achi= eved=C2=A0a
>>>>=C2=A0lot=C2=A0of=C2=A0work=C2=A0which=C2=A0has=C2=A0b= een=C2=A0documented=C2=A0in=C2=A0charter,=C2=A0stateless=C2=A0motivation,
>>>>=C2=A04rd-varients,=C2=A0MAP-03,=C2=A0etc.=C2=A0AFAIK= =C2=A0all=C2=A0the=C2=A0authors=C2=A0have=C2=A0kept=C2=A0the=C2=A0basic
>>>>=C2=A0"stateless"=C2=A0principle=C2=A0and=C2= =A0the=C2=A0MAP=C2=A0design=C2=A0team=C2=A0is=C2=A0also=C2=A0working=C2=A0o= n=C2=A0it
>>>>=C2=A0together=C2=A0to=C2=A0find=C2=A0a=C2=A0better=C2= =A0algorithm,=C2=A0address=C2=A0format,=C2=A0etc.=C2=A0So=C2=A0it=C2=A0is
>>>>=C2=A0really=C2=A0not=C2=A0appropriate=C2=A0to=C2=A0ma= ke=C2=A0such=C2=A0changes=C2=A0when=C2=A0MAP=C2=A0is=C2=A0adopted=C2=A0as= =C2=A0a=C2=A0WG
>>>>=C2=A0item=C2=A0in=C2=A0such=C2=A0a=C2=A0short=C2=A0ti= me.
>>>>=C2=A0
>>>>=C2=A0From=C2=A0this=C2=A0perspective,=C2=A0draft-ietf= -softwire-map-00=C2=A0can=C2=A0only=C2=A0be=C2=A0regarded
>>>>=C2=A0as=C2=A0draft-XX-softwire-mapping-address-and-po= rt-04.=C2=A0It=C2=A0is=C2=A0not=C2=A0even=C2=A0the
>>>>=C2=A0output=C2=A0of=C2=A0MAP=C2=A0design=C2=A0team.
>>>>=C2=A0
>>>>=C2=A0Best=C2=A0wishes
>>>>=C2=A0
>>>>=C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>>>>=C2=A0Qiong=C2=A0Sun
>>>>=C2=A0China=C2=A0Telecom=C2=A0Beijing=C2=A0Research=C2= =A0Institude
>>>>=C2=A0
>>>>=C2=A0
>>>>=C2=A0Open=C2=A0source=C2=A0code:
>>>>=C2=A0lightweight=C2=A04over6:=C2=A0http://sourceforge.net/p= rojects/laft6/
>>>>=C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>>>>=C2=A0
>>>>=C2=A0
>>>>=C2=A0_______________________________________________<= /div>
>>>>=C2=A0Softwires=C2=A0mailing=C2=A0list
>>>=C2=A0
>>>=C2=A0_______________________________________________
>>>=C2=A0Softwires=C2=A0mailing=C2=A0list
>>=C2=A0_______________________________________________
>>=C2=A0Softwires=C2=A0mailing=C2=A0list
>>=C2=A0https://www.ietf.org/mailman/listinfo/softwires
=C2=A0
_______________________________________________
Softwires=C2=A0mailing=C2=A0list

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


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


_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
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






--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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

--90e6ba6e8716e4219804c37ed1a2-- From satoru.matsushima@gmail.com Wed Jun 27 23:32: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 4C5C411E8177 for ; Wed, 27 Jun 2012 23:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-dqR+f5fZTf for ; Wed, 27 Jun 2012 23:32:20 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA6E011E8176 for ; Wed, 27 Jun 2012 23:32:20 -0700 (PDT) Received: by dacx6 with SMTP id x6so2486695dac.31 for ; Wed, 27 Jun 2012 23:32:20 -0700 (PDT) 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=N7mADpactjbvZR2RGn/OW/JxsLvthJKgQcwmBF7+wpc=; b=Nc24TMstT8MbSkEhm2LZnL9bZLjFR06fgCJHM3Yj1ptcrynOpCVzF5ge1mtHlisSqN eHiDFMLnfGZlh29rRIcglzT9A55lH2v02r0zc/Z7SKyM6NsTmNbNVYoujNqBssffM08l 6RX3RM/R3afxa1dYugYrmt3SYYWn0ExVTnqwW8Jx1NNSVzvz3wqDqjMdPjoyp2xtTz/3 7QV5gxKEI4htIkhR22cWUvSE4JgbTrHl6pm35/+FP73F/cCk1LymX4jyMTs0/2MKCjxC YGRzz3oKBfogFyvoIGu5lJQcDOIuktAbbDQR8cfHReCVVyb2EhQuz6fGfXMVukFqd5eH VyjQ== Received: by 10.68.202.99 with SMTP id kh3mr3292884pbc.157.1340865140690; Wed, 27 Jun 2012 23:32:20 -0700 (PDT) Received: from [10.201.81.61] ([202.45.12.141]) by mx.google.com with ESMTPS id pq5sm1160625pbb.30.2012.06.27.23.32.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 23:32:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Thu, 28 Jun 2012 15:32:14 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1278) Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 28 Jun 2012 06:32:21 -0000 Remark, Confusion of current 'draft-ietf-softwire-map-00' version of MAP about = 1:1 is that independence between the ipv6 and ipv4 addressing could be = represented as bellow: 1). ea-len equal to zero within a BMR/FMR for MAP-CE provisioning 2). only DMR provisioning for MAP-CE So in the 1), it doesn't mean NAT44 disabled on MAP CE.=20 In the 2), it does require MAP CE to disable NAT44 for compatibility of = MAP-CE(-E) be as DS-Lite B4, and MAP-CE(-T) to be compatible with = stateless NAT64. cheers, --satoru On 2012/06/28, at 10:53, Maoke wrote: > Question #8.4: if there is no IPv4 address nor IPv4 stack, where do we = need to *disable* the NAT44? i agree with you that "NAT44 is disabled" = here is obvious but i see it is too obvious to cost a "MUST" in the = specification. "MUST disable" means WE, the HUMAN, MUST make an action = according to the specification. question clarified? please confirm that = the editor/author of this text refers the same thing as you interpreted.=20= >=20 From leaf.y.yeh@huawei.com Wed Jun 27 23:37:46 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 053C011E811D for ; Wed, 27 Jun 2012 23:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.82 X-Spam-Level: X-Spam-Status: No, score=-6.82 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-l408dkKBhP for ; Wed, 27 Jun 2012 23:37:45 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF811E8192 for ; Wed, 27 Jun 2012 23:37:45 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHG76665; Thu, 28 Jun 2012 02:37:44 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 23:37:09 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 23:37:14 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Thu, 28 Jun 2012 14:37:11 +0800 From: Leaf yeh To: Satoru Matsushima , Maoke Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNVBUBIzAEAIGKNkCWo9DZKkEJyJcNU5CAgAAD24CAACW/gIABKvqAgACataA= Date: Thu, 28 Jun 2012 06:37:11 +0000 Message-ID: References: <7683A644-D86E-4A33-9234-AF742F4CC5AE@gmail.com> <1D160D2B-4415-4CC8-BC61-1775E55F5ED6@gmail.com> In-Reply-To: <1D160D2B-4415-4CC8-BC61-1775E55F5ED6@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.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 28 Jun 2012 06:37:46 -0000 Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally poss= ible case of MAP. however, to my understanding, even in this case the Figur= e 7 of MAP addressing architecture is still appliable and therefore it impl= ies PSID length also equals to zero. this is the real meaning of 1:1... Satoru - Let's think that a CE provisioned with following BMR comes from MA= P DHCPv6 options. BMR: o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o Rule-i= pv4-prefix : x.x.x.x/32 o EA-length : 0 o Port-param option : {PSID/length} This BMR could be a LW46 provisioning means. (http://www.ietf.org/mail-archive/web/softwires/current/msg04466.html ) I don't think 'it implies PSID length also equals to zero' can be derived f= rom 'zero-lengthed EA-bits' as per the example from Satoru. On the other hand, when the text of '1:1 mode' and '1:1 case' is mentioned = in the draft, I'd like to know what the 1st '1' & the 2nd '1' stand for res= pectively. Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Satoru Matsushima Sent: Thursday, June 28, 2012 1:02 PM To: Maoke Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 Hi Maoke-san, On 2012/06/27, at 20:12, Maoke wrote: >=20 > Described text for '1:1 mode' in current version would make some people c= onfused. We need to make clear for that. >=20 > i fully agree with you as zero-lengthed EA-bits is a naturally possible c= ase of MAP. however, to my understanding, even in this case the Figure 7 of= MAP addressing architecture is still appliable and therefore it implies PS= ID length also equals to zero. this is the real meaning of 1:1 that is a na= tural case possibly occurs rather than a "mode" - mode is a sort of preset = configuration. and further, it is not necessary to disable NAT44 in such EA= -null/PSID-null cases at CE. >=20 Right, it isn't a 'mode' which changes any MAP nature. > this definitely makes the MAP spec clear. if necessary, including this sp= ecial case in the MAP draft or in the MAP deployment draft, mentioning its = usage, is what i support unless we discover any other flaws regarding this.= =20 Thanks for clarification. cheers, --satoru _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Thu Jun 28 00:31: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 CC72021F8755 for ; Thu, 28 Jun 2012 00:31:09 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj2vh1DECWJ1 for ; Thu, 28 Jun 2012 00:31:08 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5085921F8759 for ; Thu, 28 Jun 2012 00:31:08 -0700 (PDT) Received: by qcsq13 with SMTP id q13so994964qcs.31 for ; Thu, 28 Jun 2012 00:31:07 -0700 (PDT) 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=tHT7mEGefOHSzk+lUoO51Usd8lUI7CGDpwZ9yelrmpA=; b=ogyot2xkxOpqEc4BIfj+XDvBGj/ti/Hl6/X90APfjRmjjgDaazMMVbyB1P4KCp+WeV k28SasT+oEz1/23LZqsx7nujg5JtpgYCGuBhV6wfku0I+UZVuF6/EeNKHnFQvKOJBQWo 2cdsZ1hm3LnljhxwTRfT5ypkhz7EyjxbRZlQj5PAKvWJlvz24+obKSroJtwZt5mpzksc rSsoAp3UCbNf2kMePMVaQNXWFj8s4is0U1SK/jq2Fbey/dylk3jLZ8knUnTJW9twWbTn FVhU8urpmRyYRyATtJxENHebmEeCreKlGHt4xIUC9pEGhYT+oHyJeVkVZUurt2r9NhjO JSVg== MIME-Version: 1.0 Received: by 10.224.176.70 with SMTP id bd6mr1762441qab.27.1340868667732; Thu, 28 Jun 2012 00:31:07 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Thu, 28 Jun 2012 00:31:07 -0700 (PDT) In-Reply-To: References: <7683A644-D86E-4A33-9234-AF742F4CC5AE@gmail.com> <1D160D2B-4415-4CC8-BC61-1775E55F5ED6@gmail.com> Date: Thu, 28 Jun 2012 07:31:07 +0000 Message-ID: From: Maoke To: Leaf yeh Content-Type: multipart/alternative; boundary=20cf302ef790a1750404c383501b Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 28 Jun 2012 07:31:09 -0000 --20cf302ef790a1750404c383501b Content-Type: text/plain; charset=ISO-8859-1 2012/6/28 Leaf yeh > Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally > possible case of MAP. however, to my understanding, even in this case the > Figure 7 of MAP addressing architecture is still appliable and therefore it > implies PSID length also equals to zero. this is the real meaning of 1:1... > > Satoru - Let's think that a CE provisioned with following BMR comes from > MAP DHCPv6 options. > BMR: > o Rule-ipv6-prefix : {exact matched with CE's delegated prefix} o > Rule-ipv4-prefix : x.x.x.x/32 > o EA-length : 0 > o Port-param option : {PSID/length} > This BMR could be a LW46 provisioning means. > (http://www.ietf.org/mail-archive/web/softwires/current/msg04466.html ) > > I don't think 'it implies PSID length also equals to zero' can be derived > from 'zero-lengthed EA-bits' as per the example from Satoru. > according to MAP architecture of addressing, EA-length MUST not less than the length of PSID, no matter it is in DHCP configuration or in FMR installed in BR. see my analysis in the discussion thread with Dec. having a PSID for CE but no the PSID embedded in the address makes ambiguity when mapping entry is selected for a specific IPv4 flow. > > On the other hand, when the text of '1:1 mode' and '1:1 case' is mentioned > in the draft, I'd like to know what the 1st '1' & the 2nd '1' stand for > respectively. > fully agree with you that any "1:1" is confusing. my understanding is 1-IPv6 address : 1-IPv4 address. but the term "1:1" is not necessary to appear in specification. - maoke > > > Best Regards, > Leaf > > > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Satoru Matsushima > Sent: Thursday, June 28, 2012 1:02 PM > To: Maoke > Cc: Softwires-wg > Subject: Re: [Softwires] map-00: review on the mode 1:1 > > Hi Maoke-san, > > On 2012/06/27, at 20:12, Maoke wrote: > > > > > Described text for '1:1 mode' in current version would make some people > confused. We need to make clear for that. > > > > i fully agree with you as zero-lengthed EA-bits is a naturally possible > case of MAP. however, to my understanding, even in this case the Figure 7 > of MAP addressing architecture is still appliable and therefore it implies > PSID length also equals to zero. this is the real meaning of 1:1 that is a > natural case possibly occurs rather than a "mode" - mode is a sort of > preset configuration. and further, it is not necessary to disable NAT44 in > such EA-null/PSID-null cases at CE. > > > > Right, it isn't a 'mode' which changes any MAP nature. > > > this definitely makes the MAP spec clear. if necessary, including this > special case in the MAP draft or in the MAP deployment draft, mentioning > its usage, is what i support unless we discover any other flaws regarding > this. > > Thanks for clarification. > > cheers, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf302ef790a1750404c383501b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/6/28 Leaf yeh <= ;leaf.y.yeh@huaw= ei.com>
Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally poss= ible case of MAP. however, to my understanding, even in this case the Figur= e 7 of MAP addressing architecture is still appliable and therefore it impl= ies PSID length also equals to zero. this is the real meaning of 1:1...

Satoru - Let's think that a CE provisioned with following BMR comes fro= m MAP DHCPv6 options.
BMR:
=A0o Rule-ipv6-prefix =A0: {exact matched with CE's delegated prefix} = =A0o Rule-ipv4-prefix =A0: x.x.x.x/32
=A0o EA-length =A0 =A0 =A0 =A0 : 0
=A0o Port-param option : {PSID/length}
This BMR could be a LW46 provisioning means.
(http://www.ietf.org/mail-archive/web/softwires/cur= rent/msg04466.html )

I don't think 'it implies PSID length also equals to zero' can = be derived from 'zero-lengthed EA-bits' as per the example from Sat= oru.

according to MAP architecture of a= ddressing, EA-length MUST not less than the length of PSID, no matter it is= in DHCP configuration or in FMR installed in BR. see my analysis in the di= scussion thread with Dec. having a PSID for CE but no the PSID embedded in = the address makes ambiguity when mapping entry is selected for a specific I= Pv4 flow.=A0
=A0

On the other hand, when the text of '1:1 mode' and '1:1 case= 9; is mentioned in the draft, I'd like to know what the 1st '1'= & the 2nd '1' stand for respectively.

fully agree with you that any "1:1" is confusing. = my understanding is 1-IPv6 address : 1-IPv4 address. but the term "1:1= " is not necessary to appear in specification.=A0

- maoke
=A0


Best Regards,
Leaf


-----Original Message-----
From: softwires-bounces@ietf.= org [mailto:softwires-bou= nces@ietf.org] On Behalf Of Satoru Matsushima
Sent: Thursday, June 28, 2012 1:02 PM
To: Maoke
Cc: Softwires-wg
Subject: Re: [Softwires] map-00: review on the mode 1:1

Hi Maoke-san,

On 2012/06/27, at 20:12, Maoke wrote:

>
> Described text for '1:1 mode' in current version would make so= me people confused. We need to make clear for that.
>
> i fully agree with you as zero-lengthed EA-bits is a naturally possibl= e case of MAP. however, to my understanding, even in this case the Figure 7= of MAP addressing architecture is still appliable and therefore it implies= PSID length also equals to zero. this is the real meaning of 1:1 that is a= natural case possibly occurs rather than a "mode" - mode is a so= rt of preset configuration. and further, it is not necessary to disable NAT= 44 in such EA-null/PSID-null cases at CE.
>

Right, it isn't a 'mode' which changes any MAP nature.

> this definitely makes the MAP spec clear. if necessary, including this= special case in the MAP draft or in the MAP deployment draft, mentioning i= ts usage, is what i support unless we discover any other flaws regarding th= is.

Thanks for clarification.

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

--20cf302ef790a1750404c383501b-- From tom.taylor.stds@gmail.com Thu Jun 28 00:53: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 820C121F888F for ; Thu, 28 Jun 2012 00:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URe0eHNvxiTu for ; Thu, 28 Jun 2012 00:53:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6B1621F888E for ; Thu, 28 Jun 2012 00:53:28 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2927674lbb.31 for ; Thu, 28 Jun 2012 00:53:27 -0700 (PDT) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=Q639GazgVAeb4n4cTnR+CEQtoJxRy/oXgoVxZbZ5LNM=; b=XTFRWB0ZkjwaMPkyjPBPPWi5wdzi6eaPh6LC4Oz5DLay0U7elevunwP/cZuWeoMhCR URvCB79vEwhnYGYvhjR2DUwP2mMKd74Uaqwo1RKXweygRFsQpEpdgZwk8EIDGwnwIVwB 8HVQiOEEbBq4B6HLOUXJpUcoe2l1HmEBe6Sy+PVE5iNEWlRo/I3OHgesuQacWbo9IcJn qgodISQsjAwWMJnEmZIp0aNuN6kOwpgpyV9MRTV9s5BmvlOZcyWfOnVXwn24edgyEnST y9L1INdy0/CNwvHxb+gqHAdp8Bf0mtxmmJPg7EkT+gnMFoUGeqMsm7xr4gLHpfgT258A H43w== Received: by 10.152.144.138 with SMTP id sm10mr970336lab.22.1340870007348; Thu, 28 Jun 2012 00:53:27 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-19-146.tor.primus.ca. [173.206.19.146]) by mx.google.com with ESMTPS id hg4sm88441944lab.11.2012.06.28.00.53.23 (version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 00:53:25 -0700 (PDT) Message-ID: <4FEC0D73.9010902@gmail.com> Date: Thu, 28 Jun 2012 03:53:23 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stig Venaas References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> In-Reply-To: <4FEB6831.5060100@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120627-1, 27/06/2012), Outbound message X-Antivirus-Status: Clean Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 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, 28 Jun 2012 07:53:29 -0000 My view has been similar to yours, with a twist: that the generic document could be followed up by documents that describe how the generic architecture relates to specific transition architectures like that of DS-Lite. Tom Taylor On 27/06/2012 4:08 PM, Stig Venaas wrote: > FWIW, here is my take on this. > > > On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: > [...] >> That's a big IF. Not everybody has to do it the same way. >> >> The solution in draft-ietf-softwire-dslite-multicast-02 >> builds itself something without considering what DS-Lite is doing. >> As I told you before, DS-Lite unicast is a tunneling technology. If >> you don't like it it is not DS-Lite multicast to fix this. >> How many times this should be reminded to you? > > draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing > specific to DS-Lite, and I've been saying that the draft should be > updated to reflect that. > > However, even though it is generic, I think it is a good solution for > use in DS-Lite deployments (in addition to many other deployments). > > Whether additional solutions are needed for DS-Lite is something the > WG should consider. Maybe it already has, I haven't paid enough > attention. > > Stig > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From leaf.y.yeh@huawei.com Thu Jun 28 00:59: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 4A8AE21F8570 for ; Thu, 28 Jun 2012 00:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUYUY9nLRtU2 for ; Thu, 28 Jun 2012 00:59:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6997E21F86FF for ; Thu, 28 Jun 2012 00:00:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHG77974; Thu, 28 Jun 2012 03:00:48 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 23:58:27 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 27 Jun 2012 23:58:23 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 28 Jun 2012 14:58:15 +0800 From: Leaf yeh To: Satoru Matsushima , Maoke Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNVBUBIzAEAIGKNkCWo9DZKkEJyJcNU5CAgAAk6YCAAHArgIAAir2AgABN2wCAAIg58A== Date: Thu, 28 Jun 2012 06:58:14 +0000 Message-ID: References: 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.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 28 Jun 2012 07:59:15 -0000 Maoke - Section 7.3 page 19: A MAP-E CE provisioned with only a Default Mapping Rule, as in the 1:1 case, and with no IPv4 address and port range configured by other means, MUST disable its NAT44 functionality.=20 Question #8: what is the consequence of disabling the NAT44 functionality o= n CE when a subscriber having a PSID of a share IPv4 address is running beh= ind that CE as a 1:1 mode domain? Supposed the draft is talking about the backward compatibility with DS-lite= . When CE provisioned with only a Default Mapping Rule and the CE disable i= ts NAT44 functionality, the CE turns to be B4 of DS-lite, the BR will turns= to be stateful AFTR of DS-lite. But the question on the text of "as in the 1:1 case" seems still be there, = because '1:1' continuous to puzzles us before it is defined.=20 I don't think the "as in the 1:1 case" is necessary here in the context of = this paragraph. Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Satoru Matsushima Sent: Thursday, June 28, 2012 2:32 PM To: Maoke Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 Remark, Confusion of current 'draft-ietf-softwire-map-00' version of MAP about 1:1 = is that independence between the ipv6 and ipv4 addressing could be represen= ted as bellow: 1). ea-len equal to zero within a BMR/FMR for MAP-CE provisioning 2). only DMR provisioning for MAP-CE So in the 1), it doesn't mean NAT44 disabled on MAP CE.=20 In the 2), it does require MAP CE to disable NAT44 for compatibility of MAP= -CE(-E) be as DS-Lite B4, and MAP-CE(-T) to be compatible with stateless NA= T64. cheers, --satoru On 2012/06/28, at 10:53, Maoke wrote: > Question #8.4: if there is no IPv4 address nor IPv4 stack, where do we ne= ed to *disable* the NAT44? i agree with you that "NAT44 is disabled" here i= s obvious but i see it is too obvious to cost a "MUST" in the specification= . "MUST disable" means WE, the HUMAN, MUST make an action according to the = specification. question clarified? please confirm that the editor/author of= this text refers the same thing as you interpreted.=20 >=20 _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From leaf.y.yeh@huawei.com Thu Jun 28 01:37:56 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 4654121F8921 for ; Thu, 28 Jun 2012 01:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.992 X-Spam-Level: X-Spam-Status: No, score=-4.992 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, FRT_BELOW2=2.154, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHLoAJNITmUx for ; Thu, 28 Jun 2012 01:37:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD9121F8920 for ; Thu, 28 Jun 2012 01:37:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHG83108; Thu, 28 Jun 2012 04:37:55 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 01:37:03 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 01:37:08 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.110]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Thu, 28 Jun 2012 16:37:01 +0800 From: Leaf yeh To: Maoke Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNVBUBIzAEAIGKNkCWo9DZKkEJyJcNU5CAgAAD24CAACW/gIABKvqAgACataD//47WgIAAhp5Q Date: Thu, 28 Jun 2012 08:37:00 +0000 Message-ID: References: <7683A644-D86E-4A33-9234-AF742F4CC5AE@gmail.com> <1D160D2B-4415-4CC8-BC61-1775E55F5ED6@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.160] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 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, 28 Jun 2012 08:37:56 -0000 maoke - see my analysis in the discussion thread with Dec. That sound the homework of Woj. :-) maoke - having a PSID for CE but no the PSID embedded in the address makes = ambiguity when mapping entry is selected for a specific IPv4 flow.=A0 Satoru - Confusion of current 'draft-ietf-softwire-map-00' version of MAP a= bout 1:1 is that independence between the ipv6 and ipv4 addressing could be= represented as bellow: 1). ea-len equal to zero within a BMR/FMR for MAP-C= E provisioning 2). only DMR provisioning for MAP-CE 1) Length (EA bits) =3D 0 sounds no mapping at CE, the provision of IPv4 a= ddress and PSID are independent. The mapping (Fig.7) is expected to be inva= lid. 2) Only DMR of MRs is provisioned to CE, sounds that no BMR/FMR defined in= the draft-spec is really provisioned to CE. maoke - my understanding is 1-IPv6 address : 1-IPv4 address. The alternative of 1:1 might be 1x IPv6 prefix of CE <-> 1x {IPv4 address= + PSID} of CE, which sound the same as before as the design target, but th= e MAP domain is expected only for one CE if length(EA bits) =3D 0. I suppos= ed there might be some reason that PSID is not embedded, I guess the expect= ation might be that PSID could be totally independent from the mapping. Best Regards, Leaf From: Maoke [mailto:fibrib@gmail.com]=20 Sent: Thursday, June 28, 2012 3:31 PM To: Leaf yeh Cc: Satoru Matsushima; Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 2012/6/28 Leaf yeh Maoke - i fully agree with you as zero-lengthed EA-bits is a naturally poss= ible case of MAP. however, to my understanding, even in this case the Figur= e 7 of MAP addressing architecture is still appliable and therefore it impl= ies PSID length also equals to zero. this is the real meaning of 1:1... Satoru - Let's think that a CE provisioned with following BMR comes from MA= P DHCPv6 options. BMR: =A0o Rule-ipv6-prefix =A0: {exact matched with CE's delegated prefix} =A0o = Rule-ipv4-prefix =A0: x.x.x.x/32 =A0o EA-length =A0 =A0 =A0 =A0 : 0 =A0o Port-param option : {PSID/length} This BMR could be a LW46 provisioning means. (http://www.ietf.org/mail-archive/web/softwires/current/msg04466.html ) I don't think 'it implies PSID length also equals to zero' can be derived f= rom 'zero-lengthed EA-bits' as per the example from Satoru. according to MAP architecture of addressing, EA-length MUST not less than t= he length of PSID, no matter it is in DHCP configuration or in FMR installe= d in BR. see my analysis in the discussion thread with Dec. having a PSID f= or CE but no the PSID embedded in the address makes ambiguity when mapping = entry is selected for a specific IPv4 flow.=A0 =A0 On the other hand, when the text of '1:1 mode' and '1:1 case' is mentioned = in the draft, I'd like to know what the 1st '1' & the 2nd '1' stand for res= pectively. fully agree with you that any "1:1" is confusing. my understanding is 1-IPv= 6 address : 1-IPv4 address. but the term "1:1" is not necessary to appear i= n specification.=A0 - maoke =A0 Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Satoru Matsushima Sent: Thursday, June 28, 2012 1:02 PM To: Maoke Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 Hi Maoke-san, On 2012/06/27, at 20:12, Maoke wrote: > > Described text for '1:1 mode' in current version would make some people c= onfused. We need to make clear for that. > > i fully agree with you as zero-lengthed EA-bits is a naturally possible c= ase of MAP. however, to my understanding, even in this case the Figure 7 of= MAP addressing architecture is still appliable and therefore it implies PS= ID length also equals to zero. this is the real meaning of 1:1 that is a na= tural case possibly occurs rather than a "mode" - mode is a sort of preset = configuration. and further, it is not necessary to disable NAT44 in such EA= -null/PSID-null cases at CE. > Right, it isn't a 'mode' which changes any MAP nature. > this definitely makes the MAP spec clear. if necessary, including this sp= ecial case in the MAP draft or in the MAP deployment draft, mentioning its = usage, is what i support unless we discover any other flaws regarding this. Thanks for clarification. cheers, --satoru _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From jacni@jacni.com Thu Jun 28 03:10: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 93F3B21F8810 for ; Thu, 28 Jun 2012 03:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.163 X-Spam-Level: X-Spam-Status: No, score=-1.163 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wK+Ajdb9qi56 for ; Thu, 28 Jun 2012 03:10:20 -0700 (PDT) Received: from srv05.olivemail.cn (unknown [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 3431911E80EB for ; Wed, 27 Jun 2012 21:56:15 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 5FE93380075 for ; Thu, 28 Jun 2012 00:56:14 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 066A43400DB for ; Thu, 28 Jun 2012 12:56:13 +0800 (CST) Received: from [10.79.98.39] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJALL4fr4+tP12J4AQ--.9381S2; Thu, 28 Jun 2012 12:56:11 +0800 (CST) Message-ID: <4FEBE3E6.9080605@jacni.com> Date: Thu, 28 Jun 2012 12:56:06 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Shailesh Suman References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000804040904000308000905" X-CM-TRANSID: +AWowJALL4fr4+tP12J4AQ--.9381S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWr1Duw4DXFWxWFWxWw4Uurg_yoWrKw4fpa y8Kr4DKw1kJr1rAw1kuw1jvwnYvFWrtFW8JF98Ga4UZ345GF47KrnYkay5CayDJrs8Cr4Y qF4UCrWUX3Z8Z3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07j6wZcUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQEQEko7lRcsyQBSsG Cc: "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 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, 28 Jun 2012 10:10:22 -0000 This is a multi-part message in MIME format. --------------000804040904000308000905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Re-, Thanks a lot for your review and comments, we'll update it accordingly. Cheers, Jacni On 6/28/2012 Thursday 12:42 AM, Shailesh Suman wrote: > Hi Lee, > > Thanks for your reply. It clarifies some of my queries now. Hope > to see the revison tries to address these points. > > Regards.. > -Shailesh > > On Tue, Jun 26, 2012 at 7:11 PM, Lee, Yiu wrote: >> Hi Shailesh, >> >> Thanks very much of reviewing the draft. Please read comments inline: >> >> On 6/26/12 8:07 AM, "Shailesh Suman" wrote: >> >>> Hi All, >>> >>> I see few points of this draft need to be addressed to address >>> complete solution. >>> >>> 1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and >>> uPrefix64) packets silently. There can be scenarios, where some of LAN >>> Multicast receivers are supporting native IPv6. How will such packets >>> reach the v6 Multicast Receivers, in case they get silently discarded >>> by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast >>> Receivers in LAN should also be looked into. >> [YL] mB4 is a logical function and should be implemented along side with >> normal MLD listener in the same CPE. If the multicast address header >> contains mPrefix64 and uPrefix64, it should pass to mB4. Otherwise, the >> normal MLD listener will handle it. That sentence tries to prevent normal >> multicast message from accidentally passing to mB4. >> >>> 2). It is also possible for LAN to have Multicast Originators rather >>> than only Multicast Receivers. This solution currently restricts the >>> scope to downstream Multicast traffic only and there should be some >>> exploration for Originators as well. >> [YL] Our main focus on this to support home user (i.e. IPTV service). You >> can find more discussion in >> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. This is why >> we limit the scope. We can add more words to expect our motives. >> >>> 3). Fragmentation issues can surface for any transition techniques. >>> However for DS-Lite (applicable to Unicast traffic only) Path-MTU can >>> come for rescue. But for Multicast traffic Path-MTU can not be run. >>> This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4 >>> respectively. >>> >>> I think, addressing these points would be vital for this I.D. >> [YL] I agree. We will propose some text in next revision. >> Thanks, >> Yiu >> >> >>> Regards >>> -Shailesh >>> >>> >>>> Message: 1 >>>> Date: Tue, 26 Jun 2012 07:36:41 +0800 >>>> From: Jacni Qin >>>> To: sarikaya@ieee.org >>>> Cc: Softwires-wg , Behcet Sarikaya >>>> >>>> Subject: Re: [Softwires] [SPAM] Re: WG last call on >>>> draft-ietf-softwire-dslite-multicast-02 >>>> Message-ID: <4FE8F609.1040407@jacni.com> >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>> >>>> Re-, >>>> >>>> On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote: >>>>> On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin wrote: >>>>>> Hi Behcet, all, >>>>>> >>>>>> >>>>>> On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote: >>>>>>> Folks, >>>>>>> >>>>>>> We have published revised version of our draft on multicast >>>>>>> extensions >>>>>>> to DS-Lite at >>>>>>> >>>>>>> http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt >>>>>>> >>>>>> It's been discussed on the list and in the 81st meeting, and >>>>>> concluded quite >>>>>> clearly by the WG why this is abandoned. >>>>>> It tunnels the IGMP packets upwards, replicates the multicast traffic >>>>>> "per >>>>>> tunnel", opposite to the property of multicast technology. And these >>>>>> are >>>>>> problems we're trying to solve. >>>>>> >>>>> draft-ietf-softwire-dslite-multicast-02 has nothing to do with >>>>> DS-Lite and therefore it is not a DS-Lite multicast extensions >>>>> document as the charter requires. >>>>> OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates >>>>> multicast into DS-Lite tunnel. >>>>> >>>>> It is not against multicast technology. >>>> In this way, the efficiency is lost. If operators put the AFTR box >>>> deeply in the network, far from the end users, as you process the >>>> singling messages and replicate of traffic per tunnel, the network and >>>> the box will crash because of the huge burden. >>>> >>>>>> There is no necessity to initiate that kind of discussion once again. >>>>>> >>>>> I did not start this discussion. Please check the list. >>>> Again please see above, or check the archive and the offlist messages >>>> where we've explained it to you in detail. >>>> >>>> >>>> Cheers, >>>> Jacni >>>> >>>>> Regards. >>>>> >>>>> Behcet >>>>> >>>>>> Cheers, >>>>>> Jacni >>>>>> >>>>>> >>>>>>> We think that this draft should be part of >>>>>>> draft-ietf-softwire-dslite-multicast. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Behcet >>>>>>> _______________________________________________ >>>>>>> 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 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --------------000804040904000308000905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-,

Thanks a lot for your review and comments, we'll update it accordingly.


Cheers,
Jacni
On 6/28/2012 Thursday 12:42 AM, Shailesh Suman wrote:
Hi Lee,

    Thanks for your reply. It clarifies some of my queries now. Hope
to see the revison tries to address these points.

Regards..
-Shailesh

On Tue, Jun 26, 2012 at 7:11 PM, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:

Hi Shailesh,

Thanks very much of reviewing the draft. Please read comments inline:

On 6/26/12 8:07 AM, "Shailesh Suman" <sumanshailesh@gmail.com> wrote:


Hi All,

     I see few points of this draft need to be addressed to address
complete solution.

1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and
uPrefix64) packets silently. There can be scenarios, where some of LAN
Multicast receivers are supporting native IPv6. How will such packets
reach the v6 Multicast Receivers, in case they get silently discarded
by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast
Receivers in LAN should also be looked into.

[YL] mB4 is a logical function and should be implemented along side with
normal MLD listener in the same CPE. If the multicast address header
contains mPrefix64 and uPrefix64, it should pass to mB4. Otherwise, the
normal MLD listener will handle it. That sentence tries to prevent normal
multicast message from accidentally passing to mB4.


2). It is also possible for LAN to have Multicast Originators rather
than only Multicast Receivers. This solution currently restricts the
scope to downstream Multicast traffic only and there should be some
exploration for Originators as well.

[YL] Our main focus on this to support home user (i.e. IPTV service). You
can find more discussion in
http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. This is why
we limit the scope. We can add more words to expect our motives.


3). Fragmentation issues can surface for any transition techniques.
However for DS-Lite (applicable to Unicast traffic only) Path-MTU can
come for rescue. But for Multicast traffic Path-MTU can not be run.
This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4
respectively.

   I think, addressing these points would be vital for this I.D.

[YL] I agree. We will propose some text in next revision.


      

        
Thanks,
Yiu




        

          
Regards
-Shailesh




          

            
Message: 1
Date: Tue, 26 Jun 2012 07:36:41 +0800
From: Jacni Qin <jacni@jacni.com>
To: sarikaya@ieee.org
Cc: Softwires-wg <softwires@ietf.org>, Behcet Sarikaya
       <sarikaya2012@gmail.com>
Subject: Re: [Softwires] [SPAM] Re: WG last call on
       draft-ietf-softwire-dslite-multicast-02
Message-ID: <4FE8F609.1040407@jacni.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Re-,

On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote:


            

              
On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin<jacni@jacni.com>  wrote:


              

                
Hi Behcet, all,


On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote:


                

                  
Folks,

We have published revised version of our draft on multicast
extensions
to DS-Lite at

http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt



                

                
It's been discussed on the list and in the 81st meeting, and
concluded quite
clearly by the WG why this is abandoned.
It tunnels the IGMP packets upwards, replicates the multicast traffic
"per
tunnel", opposite to the property of multicast technology. And these
are
problems we're trying to solve.



              

              
  draft-ietf-softwire-dslite-multicast-02 has nothing to do with
DS-Lite and therefore it is not a DS-Lite multicast extensions
document as the charter requires.
OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates
multicast into DS-Lite tunnel.

It is not against multicast technology.


            

            
In this way, the efficiency is lost. If operators put the AFTR box
deeply in the network, far from the end users, as you process the
singling messages and replicate of traffic per tunnel, the network and
the box will crash because of the huge burden.



            

              

                
There is no necessity to initiate that kind of discussion once again.



              

              
I did not start this discussion. Please check the list.


            

            
Again please see above, or check the archive and the offlist messages
where we've explained it to you in detail.


Cheers,
Jacni



            

              
Regards.

Behcet



              

                
Cheers,
Jacni




                

                  
We think that this draft should be part of
draft-ietf-softwire-dslite-multicast.

Regards,

Behcet
_______________________________________________
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


        

      

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




    

    

    

  


--------------000804040904000308000905--


From internet-drafts@ietf.org  Thu Jun 28 03:14: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 9F50621F844E; Thu, 28 Jun 2012 03:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZXEQsorveda; Thu, 28 Jun 2012 03:14:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFF921F842F; Thu, 28 Jun 2012 03:14:08 -0700 (PDT)
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.21p1
Message-ID: <20120628101408.21739.10988.idtracker@ietfa.amsl.com>
Date: Thu, 28 Jun 2012 03:14:08 -0700
Cc: softwires@ietf.org
Subject: [Softwires] I-D Action: draft-ietf-softwire-map-01.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, 28 Jun 2012 10:14:29 -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           : Mapping of Address and Port (MAP)
	Author(s)       : Ole Troan
                          Wojciech Dec
                          Xing Li
                          Congxiao Bao
                          Yu Zhai
                          Satoru Matsushima
                          Tetsuya Murakami
	Filename        : draft-ietf-softwire-map-01.txt
	Pages           : 33
	Date            : 2012-06-28

Abstract:
   This document describes a mechanism for transporting IPv4 packets
   across an IPv6 network, and a generic mechanism for mapping between
   IPv6 addresses and IPv4 addresses and transport layer ports.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-map

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-map-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-01


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


From yiu_lee@cable.comcast.com  Thu Jun 28 05:17: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 8F85721F84FE for ; Thu, 28 Jun 2012 05:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.15
X-Spam-Level: 
X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=0.684, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98ns-d9mWysC for ; Thu, 28 Jun 2012 05:17:10 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 88FE521F84DE for ; Thu, 28 Jun 2012 05:17:10 -0700 (PDT)
Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.23010513; Thu, 28 Jun 2012 05:59:50 -0600
Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0309.002; Thu, 28 Jun 2012 08:17:07 -0400
From: "Lee, Yiu" 
To: Softwires-wg 
Thread-Topic: [Softwires] map-00: review on the mode 1:1
Thread-Index: AQHNVSfv6n2dyQaV40yf5w1zmZJVfQ==
Date: Thu, 28 Jun 2012 12:17:07 +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.2.120421
x-originating-ip: [24.40.55.73]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3423716226_3264094"
MIME-Version: 1.0
Subject: Re: [Softwires] map-00: review on the mode 1:1
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, 28 Jun 2012 12:17:11 -0000

--B_3423716226_3264094
Content-type: multipart/alternative;
	boundary="B_3423716224_3248448"


--B_3423716224_3248448
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Woj and Satoru,

Thanks for spending time to explain MAP to the ML. It really helps to
understand it better. Thanks

I concur with Maoke's analysis. If the 1:1 mode means giving the CE a
complete IPv4 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e.
EA-bit=0 and r <= 32) , this is what MAP allows. If 1:1 means explicitly
provisioning PSID in the BR for shared an IPv4 address and PSID isn't
contained in the CE MAP address, AFAIK this is not MAP originally designed
for. 

In the current version of the draft, I found two references:

   MAP can also be provisioned in 1:1 mode.  In 1:1 mode the BR has a
   MAP domain per subscriber, and the CE is configured in hub and spoke
   mode, with only a DMR and no other mapping rules.  This allows for a
   mode where the BR has one rule per subscriber and the provisioning of
   IPv4 address or prefix and port sets is independent of the End-User
   IPv6 prefix.
   In 1:1 mode, the MAP CE is provisioned with only a Default Mapping
   Rule, and the full IPv4 address/prefix and port range is provisioned
   using the DHCP option.
When I read them, my interpretation is when EA-bit=0, port-set could be
provisioned to CE. BR will also install the BMR+Port-set per CE. It seems to
me the 1:1 is the second case rather than first case. Am I reading the draft
wrong?

I also have a question about routing the packet to CE. If EA-bit=0, does
this require each CE will have a different Rule IPv6 prefix (i.e. Each sub
is in its domain)? If not, how does routing work in BR?

Thanks,
Yiu




--B_3423716224_3248448
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable


Hi Woj and Satoru,

Thanks for spending time to explain MAP to the ML. It r=
eally helps to understand it better. Thanks

I concu=
r with Maoke's analysis. If the 1:1 mode means giving the CE a complete IPv4=
 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e. EA-bit=3D0 and r &l=
t;=3D 32) , this is what MAP allows. If 1:1 means explicitly provisioning PSID=
 in the BR for shared an IPv4 address and PSID isn't contained in the CE MAP=
 address, AFAIK this is not MAP originally designed for. 
In the current version of the draft, I found two references:

   MAP can also be provisioned in 1:1 mode.  In =
1:1 mode the BR has a
   MAP domain per subscriber, a=
nd the CE is configured in hub and spoke
   mode, wit=
h only a DMR and no other mapping rules.  This allows for a
   mode where the BR has one rule per subscriber and the provisioning=
 of
   IPv4 address or prefix and port sets is indepe=
ndent of the End-User
   IPv6 prefix.
   In 1:1 mode, the MAP CE is provisioned with only a=
 Default Mapping
   Rule, and the full IPv4 address/prefix and port range is provisioned
   using the DHCP option.

When I read them, my interpretation is when EA-bit=3D0, port=
-set could be provisioned to CE. BR will also install the BMR+Port-set per C=
E. It seems to me the 1:1 is the second case rather than first case. Am I re=
ading the draft wrong?

I also have a question about=
 routing the packet to CE. If EA-bit=3D0, does this require each CE will have =
a different Rule IPv6 prefix (i.e. Each sub is in its domain)? If not, how d=
oes routing work in BR? 

Thanks,
Yiu=




--B_3423716224_3248448--

--B_3423716226_3264094
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX
DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa
djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA
Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8
dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf
WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn
c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0
W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED
BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI
KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u
YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0
cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1
cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG
A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB
AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq
ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV
/F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss
oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7
mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC
AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS
VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE
AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx
MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD
QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY
1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp
ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU
gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/
FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ
Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME
GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5
xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV
HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF
UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw
ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp
ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq
hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5
yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z
X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG
1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u
5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl
cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe
Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt
VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq
mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM
yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN
oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR
Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/
MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa
MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T
AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov
L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF
BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW
uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR
zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd
lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg
7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC
BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT
C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi
MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y
MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0
IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz
5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6
2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO
rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B
X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq
WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O
BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/
MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT
RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU
UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG
SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD
UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69
FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh
jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE
MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw
NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT7uAO2
SjCMWlpZuYkvBqotE7zSHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMjA2MjgxMjE3MDRaMA0GCSqGSIb3DQEBAQUABIIBAMaahSudshyofB1QfZ6FzOsb
hryAt38GZ47NVCcrim1q2T7vYVsAVHiFevpvejHIqHe1s7fQE1c1ha80Vnj+NMWXFuz4wpKn
Y7VVOfDfOCjinY/jSwi+NrF/7bgcw8LP0sDdWL8mmE1mdQ8p5WFHjjRpsMEbAGqqSDhldWjL
ZzCU+UsiIDMFGy0rmGOiv+1/6FovVe8LvC3cNY23kCUw5IxsgycKtBtsQm10Bkd/DV65lLhH
iYgRDx3YFYxf+XPvxd1WsxHdnUAhBFWpkkI1z06d+DCaL8Gz+ujj7K0ubDYbKkyTdpKVeWmw
OnH4nr0Q21DhV5huglC85tsnEQ10kuI=

--B_3423716226_3264094--

From tomasz.mrugalski@gmail.com  Thu Jun 28 06:28: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 D652A21F8547 for ; Thu, 28 Jun 2012 06:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFvuM-4lcfPA for ; Thu, 28 Jun 2012 06:28:36 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26A4221F8540 for ; Thu, 28 Jun 2012 06:28:35 -0700 (PDT)
Received: by eekd4 with SMTP id d4so856293eek.31 for ; Thu, 28 Jun 2012 06:28:35 -0700 (PDT)
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:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=9ewfrYFpQsQnq9lwh9PZhBOVQ4k7gyjK8FA9/4vB+mE=; b=rxvh1CNz1Ig1LoiViPJX7OISbddrGFpLVyCqCQYtIMR52YTsUIENvNeMiy65rYkeXb qMXQ8hH+zwBqtAprYgLKeRZ5qfJrqmdE6QIZ3AjuBZCBeNs+mWNvmv2B4ENqIwrU/Gig nHbbMWRBXBBjaiBbBy5Jf7w+EI7chRlmVCIiTktfzCD3oPYg2BL2qAdepFd18LlyYhIG vI+eEfc7C3Ah43Nx+1nCbj6pgrp4ErXv2q+KL8sTwnE9AoIhxklMtxRF/ogYANwwMlJa lgi6G85ZfbBIzcto2D0YHES9KJoeztqba/Oa4L2t2VxHTzvH629ZeALxQxgvTgsZQHy2 Fn1Q==
Received: by 10.14.99.200 with SMTP id x48mr459841eef.77.1340890115235; Thu, 28 Jun 2012 06:28:35 -0700 (PDT)
Received: from ?IPv6:2001:470:6061:1:610f:4eb0:625:e349? ([2001:470:6061:1:610f:4eb0:625:e349]) by mx.google.com with ESMTPS id q53sm169297661eef.8.2012.06.28.06.28.34 (version=SSLv3 cipher=OTHER); Thu, 28 Jun 2012 06:28:34 -0700 (PDT)
Message-ID: <4FEC5BFF.4050905@gmail.com>
Date: Thu, 28 Jun 2012 15:28:31 +0200
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: softwires@ietf.org
References: 
In-Reply-To: 
X-TagToolbar-Keys: D20120628152831535
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Softwires] map-00: review on the mode 1:1
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, 28 Jun 2012 13:28:36 -0000

On 28.06.2012 14:17, Lee, Yiu wrote:
> Hi Woj and Satoru,
> 
> Thanks for spending time to explain MAP to the ML. It really helps to
> understand it better. Thanks
> 
> I concur with Maoke's analysis. If the 1:1 mode means giving the CE a
> complete IPv4 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e.
> EA-bit=0 and r <= 32) , this is what MAP allows. If 1:1 means explicitly
> provisioning PSID in the BR for shared an IPv4 address and PSID isn't
> contained in the CE MAP address, AFAIK this is not MAP originally
> designed for. 
> 
> In the current version of the draft, I found two references:
Sorry for interrupting, but which current version do you referring to?
There is softwire-map-01 published earlier today with the 1:1 mode removed.

Cheers,
Tomek

From yiu_lee@cable.comcast.com  Thu Jun 28 06:30: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 EF35521F8547 for ; Thu, 28 Jun 2012 06:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.892
X-Spam-Level: 
X-Spam-Status: No, score=-103.892 tagged_above=-999 required=5 tests=[AWL=1.339, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4VzZvQxJb7X for ; Thu, 28 Jun 2012 06:30:20 -0700 (PDT)
Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 53A1C21F8540 for ; Thu, 28 Jun 2012 06:30:20 -0700 (PDT)
Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.23022481; Thu, 28 Jun 2012 07:12:51 -0600
Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0309.002; Thu, 28 Jun 2012 09:30:12 -0400
From: "Lee, Yiu" 
To: Tomek Mrugalski , "softwires@ietf.org" 
Thread-Topic: [Softwires] map-00: review on the mode 1:1
Thread-Index: AQHNVTIk+boU10J5UESUTguhWJTu1g==
Date: Thu, 28 Jun 2012 13:30:11 +0000
Message-ID: 
In-Reply-To: <4FEC5BFF.4050905@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.2.120421
x-originating-ip: [24.40.55.71]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3423720611_47636"
MIME-Version: 1.0
Subject: Re: [Softwires] map-00: review on the mode 1:1
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, 28 Jun 2012 13:30:21 -0000

--B_3423720611_47636
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

I didn't check there was a newer version. My bad.

On 6/28/12 9:28 AM, "Tomek Mrugalski"  wrote:

>On 28.06.2012 14:17, Lee, Yiu wrote:
>> Hi Woj and Satoru,
>> 
>> Thanks for spending time to explain MAP to the ML. It really helps to
>> understand it better. Thanks
>> 
>> I concur with Maoke's analysis. If the 1:1 mode means giving the CE a
>> complete IPv4 address (or an IPv4 prefix) in the Rule IPv4 prefix (i.e.
>> EA-bit=0 and r <= 32) , this is what MAP allows. If 1:1 means explicitly
>> provisioning PSID in the BR for shared an IPv4 address and PSID isn't
>> contained in the CE MAP address, AFAIK this is not MAP originally
>> designed for. 
>> 
>> In the current version of the draft, I found two references:
>Sorry for interrupting, but which current version do you referring to?
>There is softwire-map-01 published earlier today with the 1:1 mode
>removed.
>
>Cheers,
>Tomek
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires

--B_3423720611_47636
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX
DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0
LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa
djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA
Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8
dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf
WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn
c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0
W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B
Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED
BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI
KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK
oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u
YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0
cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1
cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG
A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB
AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq
ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV
/F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss
oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7
mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC
AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG
A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS
VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE
AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx
MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH
cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD
QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT
ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY
1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp
ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU
gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/
FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ
Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME
GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5
xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV
HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF
UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw
ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp
ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq
hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu
PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5
yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z
X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG
1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u
5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl
cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe
Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU
IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt
VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq
mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM
yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN
oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR
Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/
MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa
MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T
AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov
L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF
BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG
9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW
uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR
zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd
lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg
7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC
BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT
C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi
MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y
MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0
IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz
5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6
2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO
rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B
X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq
WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O
BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/
MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT
RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU
UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG
SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD
UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69
FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A
q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh
jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE
MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw
NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg
Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSDRzB/
TdA7BcyUc33M2xmkJBO/ojAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xMjA2MjgxMzMwMDlaMA0GCSqGSIb3DQEBAQUABIIBAJ1Ekay5LIvduJWkgwv90L4u
tJy4LwB+tKDejlfAo0phk/JR3FX6essQr3yOYYNVPoSda9537BMbuv5RpiJ6PUDTqr/inFwi
E6X8xpIB1nyln3gWGkaWJbi/RyGgXHKjYMbva3O9hi+Aw70zOAzGz7YDQsj6V2PTUjhDIB4c
WaQIlpRN0MC3TM4Kx2Niqt8Z0H8ZTGN8nhMGStiEyCaeVdChrJgxvqdZq6UVmtNlX0zJhVm7
i7+YjPk9r7C0D0vrXdXZFmahPbcQPgpIKxM/FfDLFvXj+iF6UZJm8ezG9Cn1+0kuWpuaQ+SS
7hsLyP/gweQAKBSwtCb0Vu8U1xPzh80=

--B_3423720611_47636--

From suresh.krishnan@ericsson.com  Thu Jun 28 08:16:38 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 7FB8221F85DF for ; Thu, 28 Jun 2012 08:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.566
X-Spam-Level: 
X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XTXdVv6OCGK for ; Thu, 28 Jun 2012 08:16:38 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E414A21F85DB for ; Thu, 28 Jun 2012 08:16:37 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5SFGGcB013643 for ; Thu, 28 Jun 2012 10:16:37 -0500
Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 28 Jun 2012 11:16:14 -0400
Message-ID: <4FEC753D.5090806@ericsson.com>
Date: Thu, 28 Jun 2012 11:16:13 -0400
From: Suresh Krishnan 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Softwires WG 
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [Softwires] Document actions on MAP and 4rd
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, 28 Jun 2012 15:16:38 -0000

Hi all,
  There has been quite a bit of traffic on the mailing list as to
whether the current map and 4rd drafts actually represent wg consensus.
In order to clear the air around this, we have asked the map and the 4rd
editors to revert to the revisions of the drafts that represent
consensus. Specifically

* map-01 will remove any descriptive text concerning the 1:1 mapping
rules from the -00 draft
* 4rd-02 will be identical to 4rd-u-06

The map-01 draft has been submitted and the 4rd-02 draft should be
submitted soon.

Thanks
Suresh

From despres.remi@laposte.net  Thu Jun 28 09:25: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 58E8021F85E5 for ; Thu, 28 Jun 2012 09:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.816
X-Spam-Level: 
X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3Pqikb7KW+6 for ; Thu, 28 Jun 2012 09:25:46 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBCB21F8559 for ; Thu, 28 Jun 2012 09:25:46 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id B56847000045; Thu, 28 Jun 2012 18:25:44 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id 564707000092; Thu, 28 Jun 2012 18:25:44 +0200 (CEST)
X-SFR-UUID: 20120628162544353.564707000092@msfrf2308.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4FEC753D.5090806@ericsson.com>
Date: Thu, 28 Jun 2012 18:25:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <310169D7-DC2C-4D77-A008-86A02972EEA9@laposte.net>
References: <4FEC753D.5090806@ericsson.com>
To: Suresh Krishnan 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG 
Subject: Re: [Softwires] Document actions on MAP and 4rd
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, 28 Jun 2012 16:25:47 -0000

Le 2012-06-28 =E0 17:16, Suresh Krishnan a =E9crit :

> Hi all,
>  There has been quite a bit of traffic on the mailing list as to
> whether the current map and 4rd drafts actually represent wg =
consensus.
> In order to clear the air around this, we have asked the map and the =
4rd
> editors to revert to the revisions of the drafts that represent
> consensus. Specifically
>=20
> * map-01 will remove any descriptive text concerning the 1:1 mapping
> rules from the -00 draft
> * 4rd-02 will be identical to 4rd-u-06

Sorry, I couldn't see earlier the previous mail you sent me today. I was =
preparing my answer to it when I saw this mail on the list. (Sorry also =
if I misunderstood your intention when we talked, since I would have =
made then the comments below.)
=20
1.
Replacing 4rd-01 by 4rd-u-06 (the pre-Paris document on 4rd) would have =
been be fair *ONLY IF* map-00 would have been replaced by pre-Paris =
documents on map (i.e. mdt-softwire-mapping-address-and-port-01, =
possibly accompanied by some or all of its companion drafts).

2.
Actually, neither map-00 nor 4rd-00 have been just renamed pre-Paris =
drafts:=20
- map-00 is a completely restructured specification of map, also =
including some technical novelties. This raised AFAIK *no objection* =
from anyone (if on excludes the 1:1 issue, which was contentious WITHIN =
the map team.  =20
- 4rd-00 also differs from 4rd-u-06 (editorial improvements and one =
technical novelty, clearly announced to the WG in =
www.ietf.org/mail-archive/web/softwires/current/msg04256.html). This =
also raised AFAIK *no objection" from anyone.
- Then, after discussions of 4rd-00 on the WG mailing list, it appeared =
that the specification could be further improved regarding a security =
issue (maybe minor, but real). At this point I made the mistake to issue =
4rd-01, with this improvement, BEFORE asking for WG approval. Joel =
Halpern kindly warned me about the procedure infringement, which I =
acknowledged on the list.=20

=3D> fairness can then be restored if I post a 4rd-02 identical to =
4rd-00, thus relegating 4rd-01 to what it should have been, a proposal =
only submitted by its authors.

Hoping this is acceptable, I wait for your answer before doing anything.

Thank you,
RD


>=20
> The map-01 draft has been submitted and the 4rd-02 draft should be
> submitted soon.
>=20
> Thanks
> Suresh
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

From despres.remi@laposte.net  Thu Jun 28 10:05: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 B192421F85D8 for ; Thu, 28 Jun 2012 10:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.813
X-Spam-Level: 
X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ0YX8Ll-Dm1 for ; Thu, 28 Jun 2012 10:05:53 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id DF88621F85D6 for ; Thu, 28 Jun 2012 10:05:52 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id B990C700009F; Thu, 28 Jun 2012 19:05:51 +0200 (CEST)
Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id C411E700008B; Thu, 28 Jun 2012 19:05:50 +0200 (CEST)
X-SFR-UUID: 20120628170550803.C411E700008B@msfrf2308.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 28 Jun 2012 19:05:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <64292A6D-8247-42A5-BB8F-DBD54FBD5B30@laposte.net>
References:  
To: Satoru Matsushima 
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG , Ole Troan , Yong Cui , Ralph Droms 
Subject: Re: [Softwires] A new consensus opportunity with a MAP-bis
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, 28 Jun 2012 17:05:53 -0000

2012-06-23 =E0 10:52, Satoru Matsushima:

> Dear Remi,
>=20
> Thank you for a kind offer. It would be a very positive compromise for =
us.

I think we are making progress. Thanks.

> However, in the context of making another new stream document, which =
MAP-bis as you said, I decline it. Nevertheless, if you abandon 4rd =
work, I'm very welcome you as an author of MAP.

Well, the idea is only to introduce one more possibility for the choice =
the WG will have to m=F9ake. The three alternatives become:
a. T+E (the current map proposal)
b. H alone (the current 4rd proposal)
c. T+E+H (whatever its name...  MAP-T+E+H, 4rd-T+E+H, anything)

With the third combination:
- T is still included, thus satisfying some firm requests that justified =
MAP-T+E
- E is still included, thus satisfying some firm requests that justified =
MAP-T+E
- H is available, thus satisfying some firm requests that justified 4rd =
(ability to combine complete IPv4 transparency with IPv6-ACL =
compatibility) =20

How to introduce this 3rd choice in WG documents is AFAIK in chairs' =
hands.

Regards,
RD



>=20
> Best regards,
> --satoru
>=20
> On 2012/06/23, at 1:52, R=E9mi Despr=E9s wrote:
>=20
>> Yong, Suresh, Ralph,
>>=20
>> For mesh stateless v4/v6, we have so far a choice between only two =
solutions, MAP as is and 4rd.
>> On can hope that the consensus that couldn't be reached in Paris will =
be achievable in Vancouver, but this isn't sure, each "camp" keeping its =
own expectation.
>>=20
>> Looking at recent history, we can remember that, not long ago, the =
chair's approach was to have 3 specifications completed (MAP-T, MAP-E, =
and MAP-H, as Alain called it with H for Hybrid), and then to choose =
only one for standardization.
>>=20
>> After that, promoters of either -T and -E decided to merge -T and -E =
in a non-separable specification, as reflected in =
draft-ietf-softwire-map-00.=20
>> Thus, the choice has become between a "two-variants" specification =
(MAP) and a "single-variant" specification (4rd).
>>=20
>> In this context, a larger choice might well be the best chance for a =
WG consensus. It would include a MAP specification in which the =
forwarding mode of 4rd would be added as 3rd, say a "MAP-bis" .=20
>> With this MAP-bis:
>> - vendors have to support 3 forwarding modes, which isn't ideal, but =
most of the design, in particular in what concerns mapping rules, =
remains common (Alain once said, possibly with optimism, the three were =
99% identical!)=20
>> - operators have a free choice between T, E, or H, based on their =
operational preferences.
>> - we have (at last) a stabilized design with no one badly frustrated.
>>=20
>> If this approach makes sense for the WG, I can do the work of editing =
a MAP-bis proposal (taking the current MAP specification, adding a =
section that describes the hybrid forwarding mode, and adding a third =
variant in the address-format section).=20
>>=20
>> My personal preference remains for 4rd as single standard, but a =
choice between MAP-as-is, MAP-bis, and 4rd, is IMHO a sounder choice for =
the WG than just between MAP-as-is and 4rd.
>>=20
>> Hoping that this will be found constructive,
>> Best regards,
>> RD
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>=20

From stig@venaas.com  Thu Jun 28 10:20: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 7697F21F85D2 for ; Thu, 28 Jun 2012 10:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATS7LJ-qhVc7 for ; Thu, 28 Jun 2012 10:20:53 -0700 (PDT)
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 2293C21F8516 for ; Thu, 28 Jun 2012 10:20:52 -0700 (PDT)
Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id BCB607FE9; Thu, 28 Jun 2012 19:20:50 +0200 (CEST)
Message-ID: <4FEC9270.1050500@venaas.com>
Date: Thu, 28 Jun 2012 10:20:48 -0700
From: Stig Venaas 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Jacni Qin 
References:    <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr>   <4FE8007D.7000102@jacni.com>  <4FE8F609.1040407@jacni.com>  <4FEB6831.5060100@venaas.com> <4FEBEA85.6010201@jacni.com>
In-Reply-To: <4FEBEA85.6010201@jacni.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Softwires-wg , Behcet Sarikaya 
Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02
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, 28 Jun 2012 17:20:54 -0000

On 6/27/2012 10:24 PM, Jacni Qin wrote:
> Hi Stig,
>
> Thanks for you comments and support, please see below inline.
>
> On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote:
>> FWIW, here is my take on this.
>>
>>
>> On 6/27/2012 8:30 AM, Behcet Sarikaya wrote:
>> [...]
>>> That's a big IF. Not everybody has to do it the same way.
>>>
>>> The solution in draft-ietf-softwire-dslite-multicast-02
>>> builds itself something without considering what DS-Lite is doing.
>>> As I told you before, DS-Lite unicast is a tunneling technology. If
>>> you don't like it it is not DS-Lite multicast to fix this.
>>> How many times this should be reminded to you?
>>
>> draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing
>> specific to DS-Lite, and I've been saying that the draft should be
>> updated to reflect that.
>>
>> However, even though it is generic, I think it is a good solution for
>> use in DS-Lite deployments (in addition to many other deployments).
> As discussed in the previous messages of the thread, our motive is solve
> the problems
> for those who want multicast in their DS-Lite deployment.
> So we limited the scope. Where the DS-Lite is not deployed, it doesn't
> apply.

I understand that the motive is to have a solution for DS-Lite, but IMO
the key part is the solution itself. I think you should focus on the
solution and then discuss how it can be used in several scenarios, where
DS-Lite is one of them.

Wouldn't it be a shame if people have a need for your solution, but are
not aware of it, or doesn't consider it because they think it only
applies to DS-Lite?

Don't you agree that we should generally find good generic solutions and
describe them as such? We don't want to write basically identical docs
for each scenario. And in the worst case instead of having a single good
solution, having solutions that are only almost identical, maybe
requiring multiple slightly different implementations to solve each of
the problems, where a single solution and a single implementation would
be sufficient?

As a general principle when you come up with a solution to a problem,
don't you try to see what else it can solve, and try to present it as
a solution to all the problems? At least that is always my thinking.

It looks like we may disagree on this. I'm hoping I can make people see
the merits of making general solutions and presenting them as such. At
least for me, that seems like a good thing to strive for.

I know I've been repeating myself several times in emails to the list.
I feel strongly about this as a general principle. I don't know what
more I can say to stress my point though.

Stig

>
> If some pieces of the approach can be reused in the future, to solve the
> multicast issues in
> other deployments, that'd be good.
> While personally, I'd prefer we stay focus on the currently scenario.
> Extensions if needed, may be raised respectively for other deployments.
> More are detailed in,
> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00.
>
>
> Cheers,
> Jacni
>>
>> Whether additional solutions are needed for DS-Lite is something the
>> WG should consider. Maybe it already has, I haven't paid enough
>> attention.
>>
>> Stig
>>
>
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>



From stig@venaas.com  Thu Jun 28 10:27:31 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 A5D1221F8512 for ; Thu, 28 Jun 2012 10:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiyZHakPS+3y for ; Thu, 28 Jun 2012 10:27:31 -0700 (PDT)
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 EC8E721F84F7 for ; Thu, 28 Jun 2012 10:27:30 -0700 (PDT)
Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 745357FEC; Thu, 28 Jun 2012 19:27:29 +0200 (CEST)
Message-ID: <4FEC93FF.7@venaas.com>
Date: Thu, 28 Jun 2012 10:27:27 -0700
From: Stig Venaas 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Tom Taylor 
References:    <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr>   <4FE8007D.7000102@jacni.com>  <4FE8F609.1040407@jacni.com>  <4FEB6831.5060100@venaas.com> <4FEC0D73.9010902@gmail.com>
In-Reply-To: <4FEC0D73.9010902@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Softwires-wg , Behcet Sarikaya 
Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02
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, 28 Jun 2012 17:27:31 -0000

On 6/28/2012 12:53 AM, Tom Taylor wrote:
> My view has been similar to yours, with a twist: that the generic
> document could be followed up by documents that describe how the generic
> architecture relates to specific transition architectures like that of
> DS-Lite.

That sounds reasonable. But unless there are additional technical
considerations for how it applies to DS-Lite that need to be considered,
then I think it can be sufficient in the doc for the generic solution,
to state that it can be used in scenarios such as DS-Lite.

All I'm asking for is changing the title, and a bit of the abstract and
introduction to make it generic. As long as it doesn't look like just a
DS-Lite solution, I don't mind if there is some discussion of how it
applies to DS-Lite in the same doc. It could even say that the work
started out as a way of solving multicast for DS-Lite, but that this
generic solution was seen as the best approach.

Stig

>
> Tom Taylor
>
> On 27/06/2012 4:08 PM, Stig Venaas wrote:
>> FWIW, here is my take on this.
>>
>>
>> On 6/27/2012 8:30 AM, Behcet Sarikaya wrote:
>> [...]
>>> That's a big IF. Not everybody has to do it the same way.
>>>
>>> The solution in draft-ietf-softwire-dslite-multicast-02
>>> builds itself something without considering what DS-Lite is doing.
>>> As I told you before, DS-Lite unicast is a tunneling technology. If
>>> you don't like it it is not DS-Lite multicast to fix this.
>>> How many times this should be reminded to you?
>>
>> draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing
>> specific to DS-Lite, and I've been saying that the draft should be
>> updated to reflect that.
>>
>> However, even though it is generic, I think it is a good solution for
>> use in DS-Lite deployments (in addition to many other deployments).
>>
>> Whether additional solutions are needed for DS-Lite is something the
>> WG should consider. Maybe it already has, I haven't paid enough
>> attention.
>>
>> Stig
>> _______________________________________________
>> 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 suresh.krishnan@ericsson.com  Thu Jun 28 13:44: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 0D9A911E80BF for ; Thu, 28 Jun 2012 13:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.569
X-Spam-Level: 
X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Sh3cXe9vLI for ; Thu, 28 Jun 2012 13:44:26 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id B0DB011E80BB for ; Thu, 28 Jun 2012 13:44:26 -0700 (PDT)
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 q5SKiO2X027293 for ; Thu, 28 Jun 2012 15:44:25 -0500
Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 28 Jun 2012 16:44:18 -0400
Message-ID: <4FECC221.5080206@ericsson.com>
Date: Thu, 28 Jun 2012 16:44:17 -0400
From: Suresh Krishnan 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Softwires WG 
X-Enigmail-Version: 1.4.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [Softwires] Issue tracker for wg
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, 28 Jun 2012 20:44:28 -0000

Hi all,
  In order to handle document issues in an orderly manner, we have setup
an issue tracker for the softwire working group. Each of the wg drafts
has been setup as an available component to file issues on. At this
point, we have setup the tracker so that creation of issues is open to
everyone (and not just chairs and document editors), but we may revisit
this decision in the future based on the usage of the tracker.

The list of all open tickets (none at this moment) can be found at

http://trac.tools.ietf.org/wg/softwire/trac/report/1

To create a new ticket use (requires a tools login)

http://trac.tools.ietf.org/wg/softwire/trac/newticket

Further documentation and guides can be found at

http://trac.tools.ietf.org/wg/softwire/trac/wiki

Thanks
Suresh & Yong

From leo.liubing@huawei.com  Thu Jun 28 20:41: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 C9C9521F8642 for ; Thu, 28 Jun 2012 20:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.373
X-Spam-Level: 
X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.227,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ba1ABD-oJI3K for ; Thu, 28 Jun 2012 20:41:17 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58121F863C for ; Thu, 28 Jun 2012 20:41:17 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHH41557; Thu, 28 Jun 2012 23:41:16 -0400 (EDT)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 20:40:43 -0700
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 28 Jun 2012 20:40:39 -0700
Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Fri, 29 Jun 2012 11:40:34 +0800
From: "Liubing (Leo)" 
To: Suresh Krishnan , Softwires WG 
Thread-Topic: [Softwires] Document actions on MAP and 4rd
Thread-Index: AQHNVUEL4EC0fgIlaUCdB78kySPSjZcQonfw
Date: Fri, 29 Jun 2012 03:40:33 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292FC644@szxeml509-mbs>
References: <4FEC753D.5090806@ericsson.com>
In-Reply-To: <4FEC753D.5090806@ericsson.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.99.42]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [Softwires] Document actions on MAP and 4rd
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, 29 Jun 2012 03:41:17 -0000

Hi, Dear chairman

About this item:
> * map-01 will remove any descriptive text concerning the 1:1 mapping
> rules from the -00 draft

In MAP-00, the editors combined MAP-T and MAP-E together (which is only com=
bined by words, they are still two solutions that carriers have to choose o=
ne).=20
In my memory, this has not been discussed openly, neither reach WG consensu=
s.=20
So, may I venture to suggest this issue also backwarded to the original for=
 discussion?


B.R.
Bing

-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh=
alf Of Suresh Krishnan
Sent: Thursday, June 28, 2012 11:16 PM
To: Softwires WG
Subject: [Softwires] Document actions on MAP and 4rd

Hi all,
  There has been quite a bit of traffic on the mailing list as to
whether the current map and 4rd drafts actually represent wg consensus.
In order to clear the air around this, we have asked the map and the 4rd
editors to revert to the revisions of the drafts that represent
consensus. Specifically

* map-01 will remove any descriptive text concerning the 1:1 mapping
rules from the -00 draft
* 4rd-02 will be identical to 4rd-u-06

The map-01 draft has been submitted and the 4rd-02 draft should be
submitted soon.

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

From fibrib@gmail.com  Fri Jun 29 00:52: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 EFF7121F86D8 for ; Fri, 29 Jun 2012 00:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.465
X-Spam-Level: 
X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSbGIv8MJaV8 for ; Fri, 29 Jun 2012 00:52:38 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA5CD21F86D9 for ; Fri, 29 Jun 2012 00:52:37 -0700 (PDT)
Received: by qcac10 with SMTP id c10so615819qca.31 for ; Fri, 29 Jun 2012 00:52:37 -0700 (PDT)
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 :content-type; bh=Gsyp3/t03UJ5mJsmJZvMs/wphkMtUTy43D0uQeaXvps=; b=CY3GyivNWMcWKcs7ghbo3oirl7+PlpK0osgU/zUbPI6C8318Db78wHyKbEgmtkmZOR siT/oXab06S4WBYSxXmfjYQ/NxIlOzeo3dfe2J9VXnzTqV2ly8MPBH9GY9cY+IBVpl3W 8PWldLzcOQyuYwGCDfXS5yMzytaOa1UQuXk+6fnc+35rzxVDr9FLm8aBmKDUTVK8lTNj jF0SyqFpIE2LSlGtuFJaZSgwBshzJdJf+P0HUXvI7QS29Lt4E5yDvmrvL4y5ISzQL9uA Vcoqmv/u/lu1tT6KtisJJMZuIXxahJ9ZcNczCXMuXymENGCUcGB9iT483L41wDqvMqHZ e/LQ==
MIME-Version: 1.0
Received: by 10.224.174.205 with SMTP id u13mr1859237qaz.57.1340956357058; Fri, 29 Jun 2012 00:52:37 -0700 (PDT)
Received: by 10.229.26.66 with HTTP; Fri, 29 Jun 2012 00:52:37 -0700 (PDT)
In-Reply-To: <20120629072702.15177.32058.idtracker@ietfa.amsl.com>
References: <20120629072702.15177.32058.idtracker@ietfa.amsl.com>
Date: Fri, 29 Jun 2012 07:52:37 +0000
Message-ID: 
From: Maoke 
To: Softwires-wg 
Content-Type: multipart/alternative; boundary=485b397dd7bf525f5f04c397bb8d
Subject: [Softwires] Fwd: New Version Notification for draft-mdt-softwire-map-deployment-02.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, 29 Jun 2012 07:52:39 -0000

--485b397dd7bf525f5f04c397bb8d
Content-Type: text/plain; charset=ISO-8859-1

hi all,

according to the discussion on the previous submission we update the MAP
deployment draft as this -02 version, and call for your review before we
re-submit it as the WG doc for the chair review.

the changes in comparison to the -01 versions are:

1. draft-ietf-softwire-map-01, replacing the
draft-mdt-ietf-softwire-mapping-address-and-port is cited;
2. Section 5 is devided into sub-sections 5.1 and 5.2 where 5.1 is the
major part of original Section 5 while 5.2 is a revised version of the
"Remarks" of the original Section 5, including the extreme cases and
recommendations/non-recommendations regarding the MAP deployment;
3. editorial updates: merging Normative and Informational References into a
simple Reference section.

your comments and recommendations are welcome. considering the -01 version
didn't receive any obvious objection but some suggestions that we have
considered in this version, if we don't receive objections on the above
changes, we plan to re-submit this -02 version as the WG draft,
draft-ietf-softwire-map-deployment-00, by July 1st.

thanks and regards,
maoke

---------- Forwarded message ----------
From: 
Date: 2012/6/29
Subject: New Version Notification for
draft-mdt-softwire-map-deployment-02.txt
To: sunqiong@ctbri.com.cn
Cc: simon.perreault@viagenie.ca, fibrib@gmail.com,
tina.tsou.zouting@huawei.com, chengang@chinamobile.com,
chunfa.sun@g.softbank.co.jp



A new version of I-D, draft-mdt-softwire-map-deployment-02.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Filename:        draft-mdt-softwire-map-deployment
Revision:        02
Title:           Mapping of Address and Port (MAP) - Deployment
Considerations
Creation date:   2012-06-29
WG ID:           Individual Submission
Number of pages: 33
URL:
http://www.ietf.org/internet-drafts/draft-mdt-softwire-map-deployment-02.txt
Status:
http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment
Htmlized:
http://tools.ietf.org/html/draft-mdt-softwire-map-deployment-02
Diff:
http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-map-deployment-02

Abstract:
  This document describes when and how an operator uses the technique
  of Mapping of Address and Port (MAP) for the IPv4 residual deployment
  in the IPv6-dominant domain.




The IETF Secretariat

--485b397dd7bf525f5f04c397bb8d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


hi all,=A0

according to the discussion on=
 the previous submission we update the MAP deployment draft as this -02 ver=
sion, and call for your review before we re-submit it as the WG doc for the=
 chair review.=A0



the changes in comparison to the -01 versions are:=A0

1. draft-ietf-softwire-map-01, replacing the draft-=
mdt-ietf-softwire-mapping-address-and-port is cited;
2. Section 5=
 is devided into sub-sections 5.1 and 5.2 where 5.1 is the major part of or=
iginal Section 5 while 5.2 is a revised version of the "Remarks" =
of the original Section 5, including the extreme cases and recommendations/=
non-recommendations regarding the MAP deployment;=A0


3. editorial updates: merging Normative and Informational References i=
nto a simple Reference section.=A0

your comments a=
nd recommendations are welcome. considering the -01 version didn't rece=
ive any obvious objection but some suggestions that we have considered in t=
his version, if we don't receive objections on the above changes, we pl=
an to re-submit this -02 version as the WG draft, draft-ietf-softwire-map-d=
eployment-00, by July 1st. 



thanks and regards,
maoke

---------- Forwarded mess=
age ----------
From:  <internet-drafts@ietf.org>

Date: 2012/6/29
Subject: New Version Notification for draft-mdt-softwire=
-map-deployment-02.txt
To: sunq=
iong@ctbri.com.cn
Cc: simon.perreault@viagenie.ca, fibri=
b@gmail.com, tina.tsou.=
zouting@huawei.com, chengan=
g@chinamobile.com, chunf=
a.sun@g.softbank.co.jp





A new version of I-D, draft-mdt-softwire-map-deployment-02.txt

has been successfully submitted by Qiong Sun and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-mdt-softwire-map-deployment

Revision: =A0 =A0 =A0 =A002

Title: =A0 =A0 =A0 =A0 =A0 Mapping of Address and Port (MAP) - Deployment C=
onsiderations

Creation date: =A0 2012-06-29

WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 33

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.iet=
f.org/internet-drafts/draft-mdt-softwire-map-deployment-02.txt

Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org=
/doc/draft-mdt-softwire-map-deployment

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draf=
t-mdt-softwire-map-deployment-02

Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.iet=
f.org/rfcdiff?url2=3Ddraft-mdt-softwire-map-deployment-02



Abstract:

 =A0 This document describes when and how an operator uses the technique
 =A0 of Mapping of Address and Port (MAP) for the IPv4 residual deployment<=
br>
 =A0 in the IPv6-dominant domain.









The IETF Secretariat





--485b397dd7bf525f5f04c397bb8d--

From james.huang@huawei.com  Fri Jun 29 02:07: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 5551521F86A6 for ; Fri, 29 Jun 2012 02:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YetQvXf2tp0S for ; Fri, 29 Jun 2012 02:07:49 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C83FA21F869A for ; Fri, 29 Jun 2012 02:07:48 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHH56785; Fri, 29 Jun 2012 05:07:48 -0400 (EDT)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 29 Jun 2012 02:06:04 -0700
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 29 Jun 2012 02:06:00 -0700
Received: from SZXEML522-MBS.china.huawei.com ([fe80::d63:ad74:b260:1928]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Fri, 29 Jun 2012 17:05:50 +0800
From: Huangjing 
To: Tina TSOU 
Thread-Topic: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.txt
Thread-Index: Ac1V1l+eyTiyVPo4TseieLEYdMWopA==
Date: Fri, 29 Jun 2012 09:05:50 +0000
Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC2A8AC756@szxeml522-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.115.72]
Content-Type: multipart/alternative; boundary="_000_774B240D54DAB844B37EE80C2DD8E8BC2A8AC756szxeml522mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "softwires@ietf.org" 
Subject: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.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, 29 Jun 2012 09:07:50 -0000

--_000_774B240D54DAB844B37EE80C2DD8E8BC2A8AC756szxeml522mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, Tina,

Regarding anycast, I think if only one of the routers with a same anycast a=
ddress is working at any moment, and other(s) standby, then there is no ICM=
P error message problem.
What do you think?

Regards
James

For your comments.

Tina

Begin forwarded message:
From: >
Date: June 27, 2012 2:05:41 PM PDT
To: >
Cc: >=
, >, >
Subject: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.tx=
t

A new version of I-D, draft-tsou-softwire-bfd-ds-lite-03.txt
has been successfully submitted by Tina Tsou and posted to the
IETF repository.

Filename:     draft-tsou-softwire-bfd-ds-lite
Revision:     03
Title:         DS-Lite Failure Detection and Failover
Creation date:     2012-06-27
WG ID:         Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-tsou-softwire-bf=
d-ds-lite-03.txt
Status:          http://datatracker.ietf.org/doc/draft-tsou-softwire-bfd-ds=
-lite
Htmlized:        http://tools.ietf.org/html/draft-tsou-softwire-bfd-ds-lite=
-03
Diff:            http://tools.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-b=
fd-ds-lite-03

Abstract:
  In DS-Lite, the tunnel is stateless, not associated with any state
  information, and no failure detection and failover mechanism is
  available.  This makes it difficult to manage and diagnose if there
  is a problem.  This draft analyzes the applicability of some of the
  possible solutions.




The IETF Secretariat

________________________________

  *   Prev by Date: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-s=
oftwire-dslite-multicast-02
  *   Next by Date: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 d=
oes NOT reflect the consensus from the WG
  *   Previous by thread: [Softwires] map-00: review on the mode 1:1
  *   Next by thread: [Softwires] I-D Action: draft-ietf-softwire-map-01.tx=
t
  *   Index(es):
     *   Date
     *   Thread
Note: Messages sent to this list are the opinions of the senders and do not=
 imply endorsement by the IETF.



--_000_774B240D54DAB844B37EE80C2DD8E8BC2A8AC756szxeml522mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi, Tina,


 


Regarding anycast, I think if o=
nly one of the routers with a same anycast address is working at any moment=
, and other(s) standby, then there is no ICMP error message problem.



What do you think?


 


Regards


James


 








For your comments.



Tina





Begin forwarded message:



From: <internet-drafts at ietf.or=
g>

Date: June 27, 2012 2:05:41 PM PDT

To: <=
tina.tsou.zouting at huawei.com>

Cc: <bra=
ndon.lijian at huawei.com>, <repenno at cisco.com>, <j.schoenwaelder at jacobs-university.de&g=
t;

Subject: New Version Notification for draft-tsou-softwire-bf=
d-ds-lite-03.txt




A new version of I-D, draft-tsou-softwire-bfd-ds-lite-03.txt

has been successfully submitted by Tina Tsou and posted to the

IETF repository.



Filename:     draft-tsou-softwire-bfd-ds-lite

Revision:     03

Title:         DS-Lite Failure Detection and Failover
Creation date:     2012-06-27

WG ID:         Individual Submission

Number of pages: 9

URL:            &nbs=
p;http://www.ietf.org/internet-drafts/draft-tsou-softwire-bfd-d=
s-lite-03.txt

Status:          http://datat=
racker.ietf.org/doc/draft-tsou-softwire-bfd-ds-lite

Htmlized:        http://tools.ietf.org/ht=
ml/draft-tsou-softwire-bfd-ds-lite-03

Diff:            http://tools.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-bfd-ds-lite-=
03



Abstract:

  In DS-Lite, the tunnel is stateless, not associated with any st=
ate

  information, and no failure detection and failover mechanism is=


  available.  This makes it difficult to manage and diagnose=
 if there

  is a problem.  This draft analyzes the applicability of so=
me of the

  possible solutions.









The IETF Secretariat



















--_000_774B240D54DAB844B37EE80C2DD8E8BC2A8AC756szxeml522mbschi_--

From suresh.krishnan@ericsson.com  Fri Jun 29 05:29: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 681C321F8665 for ; Fri, 29 Jun 2012 05:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.422
X-Spam-Level: 
X-Spam-Status: No, score=-106.422 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXzuI5dr43ny for ; Fri, 29 Jun 2012 05:29:44 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C6CEE21F8620 for ; Fri, 29 Jun 2012 05:29:44 -0700 (PDT)
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 q5TCTgMP018531; Fri, 29 Jun 2012 07:29:44 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.184]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 29 Jun 2012 08:29:38 -0400
From: Suresh Krishnan 
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
Date: Fri, 29 Jun 2012 08:24:46 -0400
Thread-Topic: [Softwires] Document actions on MAP and 4rd
Thread-Index: Ac1VSrFTTBdGkRM3QIyL0k66sZRaZgAp3nuw
Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC15522170B9C@EUSAACMS0703.eamcs.ericsson.se>
References: <4FEC753D.5090806@ericsson.com>, <310169D7-DC2C-4D77-A008-86A02972EEA9@laposte.net>
In-Reply-To: <310169D7-DC2C-4D77-A008-86A02972EEA9@laposte.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Softwires WG 
Subject: Re: [Softwires] Document actions on MAP and 4rd
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, 29 Jun 2012 12:29:45 -0000

Hi Remi,
 =20
>- 4rd-00 also differs from 4rd-u-06 (editorial improvements and one techni=
cal novelty, clearly announced to the WG in www.ietf.org/mail-archive/web/s=
oftwires/current/msg04256.html). This also raised AFAIK *no objection" from=
 anyone.
> - Then, after discussions of 4rd-00 on the WG mailing list, it appeared t=
hat the specification could be further improved regarding a security issue =
(maybe minor, but real). At this point I made the mistake to issue 4rd-01, =
with this improvement, BEFORE asking for WG approval. Joel Halpern kindly w=
arned me about the procedure infringement, which I acknowledged on the list=
.

> =3D> fairness can then be restored if I post a 4rd-02 identical to 4rd-00=
, thus relegating 4rd-01 to what it should have been, a proposal only submi=
tted by its authors.

> Hoping this is acceptable, I wait for your answer before doing anything.

No problems. Go ahead and submit the -02 identical to -00. We can handle an=
y further issues using the issue tracker.=20

Thanks
Suresh

From suresh.krishnan@ericsson.com  Fri Jun 29 05:38: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 0D78921F85D0 for ; Fri, 29 Jun 2012 05:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.562
X-Spam-Level: 
X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWxGkbuvCrnU for ; Fri, 29 Jun 2012 05:38:01 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0629E21F85C6 for ; Fri, 29 Jun 2012 05:38:00 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q5TCbtXb019590; Fri, 29 Jun 2012 07:37:57 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.184]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 29 Jun 2012 08:37:55 -0400
From: Suresh Krishnan 
To: "Liubing (Leo)" , Softwires WG 
Date: Fri, 29 Jun 2012 08:34:51 -0400
Thread-Topic: [Softwires] Document actions on MAP and 4rd
Thread-Index: AQHNVUEL4EC0fgIlaUCdB78kySPSjZcQonfwgACaL5A=
Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC15522170B9F@EUSAACMS0703.eamcs.ericsson.se>
References: <4FEC753D.5090806@ericsson.com>, <8AE0F17B87264D4CAC7DE0AA6C406F45292FC644@szxeml509-mbs>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45292FC644@szxeml509-mbs>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Softwires] Document actions on MAP and 4rd
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, 29 Jun 2012 12:38:02 -0000

Hi Bing,
  For the sake of progress, we cannot keep revisiting our decisions forever=
. The map-01 document is now under working group change control. I think th=
e best way forward is to file this as an issue in the issue tracker and see=
 what the wg thinks about this.=20

Thanks
Suresh

________________________________________
From: Liubing (Leo) [leo.liubing@huawei.com]
Sent: Thursday, June 28, 2012 11:40 PM
To: Suresh Krishnan; Softwires WG
Subject: RE: [Softwires] Document actions on MAP and 4rd

Hi, Dear chairman

About this item:
> * map-01 will remove any descriptive text concerning the 1:1 mapping
> rules from the -00 draft

In MAP-00, the editors combined MAP-T and MAP-E together (which is only com=
bined by words, they are still two solutions that carriers have to choose o=
ne).
In my memory, this has not been discussed openly, neither reach WG consensu=
s.
So, may I venture to suggest this issue also backwarded to the original for=
 discussion?


B.R.
Bing

-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh=
alf Of Suresh Krishnan
Sent: Thursday, June 28, 2012 11:16 PM
To: Softwires WG
Subject: [Softwires] Document actions on MAP and 4rd

Hi all,
  There has been quite a bit of traffic on the mailing list as to
whether the current map and 4rd drafts actually represent wg consensus.
In order to clear the air around this, we have asked the map and the 4rd
editors to revert to the revisions of the drafts that represent
consensus. Specifically

* map-01 will remove any descriptive text concerning the 1:1 mapping
rules from the -00 draft
* 4rd-02 will be identical to 4rd-u-06

The map-01 draft has been submitted and the 4rd-02 draft should be
submitted soon.

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

From Tina.Tsou.Zouting@huawei.com  Fri Jun 29 09:29: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 E9ABB21F87AF for ; Fri, 29 Jun 2012 09:29:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.618
X-Spam-Level: 
X-Spam-Status: No, score=-5.618 tagged_above=-999 required=5 tests=[AWL=0.980,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiY4HEYSB249 for ; Fri, 29 Jun 2012 09:29:21 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7122521F87A9 for ; Fri, 29 Jun 2012 09:29:21 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHH79264; Fri, 29 Jun 2012 12:29:20 -0400 (EDT)
Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 29 Jun 2012 09:27:37 -0700
Received: from dfweml513-mbx.china.huawei.com ([169.254.3.109]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 29 Jun 2012 09:27:38 -0700
From: Tina TSOU 
To: Huangjing 
Thread-Topic: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.txt
Thread-Index: Ac1V1l+eyTiyVPo4TseieLEYdMWopAAPbkGM
Date: Fri, 29 Jun 2012 16:27:38 +0000
Message-ID: <488502F3-CBD3-4C40-AE10-2C137A47427C@huawei.com>
References: <774B240D54DAB844B37EE80C2DD8E8BC2A8AC756@szxeml522-mbs.china.huawei.com>
In-Reply-To: <774B240D54DAB844B37EE80C2DD8E8BC2A8AC756@szxeml522-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_488502F3CBD34C40AE102C137A47427Chuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "softwires@ietf.org" 
Subject: Re: [Softwires] Fwd: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.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, 29 Jun 2012 16:29:23 -0000

--_000_488502F3CBD34C40AE102C137A47427Chuaweicom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi James,
Thank u for u comments.
In some scenarios Anycast will be used for load balancing, not just one rou=
ter is working.
Hope it clarifies.

Tina

On Jun 29, 2012, at 2:05 AM, "Huangjing" > wrote:

Hi, Tina,

Regarding anycast, I think if only one of the routers with a same anycast a=
ddress is working at any moment, and other(s) standby, then there is no ICM=
P error message problem.
What do you think?

Regards
James

For your comments.

Tina

Begin forwarded message:
From: >
Date: June 27, 2012 2:05:41 PM PDT
To: >
Cc: >=
, >, >
Subject: New Version Notification for draft-tsou-softwire-bfd-ds-lite-03.tx=
t

A new version of I-D, draft-tsou-softwire-bfd-ds-lite-03.txt
has been successfully submitted by Tina Tsou and posted to the
IETF repository.

Filename:     draft-tsou-softwire-bfd-ds-lite
Revision:     03
Title:         DS-Lite Failure Detection and Failover
Creation date:     2012-06-27
WG ID:         Individual Submission
Number of pages: 9
URL:             http://www.ietf.org/internet-drafts/draft-tsou-softwire-bf=
d-ds-lite-03.txt
Status:          http://datatracker.ietf.org/doc/draft-tsou-softwire-bfd-ds=
-lite
Htmlized:        http://tools.ietf.org/html/draft-tsou-softwire-bfd-ds-lite=
-03
Diff:            http://tools.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-b=
fd-ds-lite-03

Abstract:
  In DS-Lite, the tunnel is stateless, not associated with any state
  information, and no failure detection and failover mechanism is
  available.  This makes it difficult to manage and diagnose if there
  is a problem.  This draft analyzes the applicability of some of the
  possible solutions.




The IETF Secretariat

________________________________

  *   Prev by Date: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-s=
oftwire-dslite-multicast-02
  *   Next by Date: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 d=
oes NOT reflect the consensus from the WG
  *   Previous by thread: [Softwires] map-00: review on the mode 1:1
  *   Next by thread: [Softwires] I-D Action: draft-ietf-softwire-map-01.tx=
t
  *   Index(es):
     *   Date
     *   Thread
Note: Messages sent to this list are the opinions of the senders and do not=
 imply endorsement by the IETF.



--_000_488502F3CBD34C40AE102C137A47427Chuaweicom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Hi James,


Thank u for u comments.


In some scenarios Anycast will be used for load balancing, not just on=
e router is working.


Hope it clarifies.



Tina




On Jun 29, 2012, at 2:05 AM, "Huangjing" <james.huang@huawei.com> wrote:
















Hi, Tina,


 


Regarding anycast, I think if o=
nly one of the routers with a same anycast address is working at any moment=
, and other(s) standby, then there is no ICMP error message problem.



What do you think?


 


Regards


James


 








For your comments.



Tina





Begin forwarded message:



From: <internet-drafts at ietf.or=
g>

Date: June 27, 2012 2:05:41 PM PDT

To: <=
tina.tsou.zouting at huawei.com>

Cc: <bra=
ndon.lijian at huawei.com>, <repenno at cisco.com>, <j.schoenwaelder at jacobs-university.de&g=
t;

Subject: New Version Notification for draft-tsou-softwire-bf=
d-ds-lite-03.txt




A new version of I-D, draft-tsou-softwire-bfd-ds-lite-03.txt

has been successfully submitted by Tina Tsou and posted to the

IETF repository.



Filename:     draft-tsou-softwire-bfd-ds-lite

Revision:     03

Title:         DS-Lite Failure Detection and Failover
Creation date:     2012-06-27

WG ID:         Individual Submission

Number of pages: 9

URL:            &nbs=
p;http://www.ietf.org/internet-drafts/draft-tsou-softwire-bfd-d=
s-lite-03.txt

Status:          http://datat=
racker.ietf.org/doc/draft-tsou-softwire-bfd-ds-lite

Htmlized:        http://tools.ietf.org/ht=
ml/draft-tsou-softwire-bfd-ds-lite-03

Diff:            http://tools.ietf.org/rfcdiff?url2=3Ddraft-tsou-softwire-bfd-ds-lite-=
03



Abstract:

  In DS-Lite, the tunnel is stateless, not associated with any st=
ate

  information, and no failure detection and failover mechanism is=


  available.  This makes it difficult to manage and diagnose=
 if there

  is a problem.  This draft analyzes the applicability of so=
me of the

  possible solutions.









The IETF Secretariat























--_000_488502F3CBD34C40AE102C137A47427Chuaweicom_--

From internet-drafts@ietf.org  Sat Jun 30 00:42: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 77CF921F86A5; Sat, 30 Jun 2012 00:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.512
X-Spam-Level: 
X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDpHDQy1ndRx; Sat, 30 Jun 2012 00:42:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72E521F8681; Sat, 30 Jun 2012 00:42:29 -0700 (PDT)
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.21p1
Message-ID: <20120630074229.6393.71868.idtracker@ietfa.amsl.com>
Date: Sat, 30 Jun 2012 00:42:29 -0700
Cc: softwires@ietf.org
Subject: [Softwires] I-D Action: draft-ietf-softwire-4rd-02.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: Sat, 30 Jun 2012 07:42:30 -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           : IPv4 Residual Deployment via IPv6 - a unified Stateless =
Solution (4rd)
	Author(s)       : Remi Despres
                          Reinaldo Penno
                          Yiu Lee
                          Gang Chen
                          Sheng Jiang
	Filename        : draft-ietf-softwire-4rd-02.txt
	Pages           : 40
	Date            : 2012-06-30

Abstract:
   The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment
   possible via IPv6 networks without maintaining for this per-customer
   states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of
   6rd).  To cope with the IPv4 address shortage, customers can be
   assigned IPv4 addresses with restricted port sets.  In some
   scenarios, 4rd-capable customer nodes can exchange packets of their
   IPv4-only applications via stateful NAT64s that are upgraded to
   support 4rd tunnels (in addition to their IP/ICMP translation of
   [RFC6145]).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-4rd-02

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-4rd-02


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


From despres.remi@laposte.net  Sat Jun 30 01:35: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 14FE421F8607 for ; Sat, 30 Jun 2012 01:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0f8mIJuORds for ; Sat, 30 Jun 2012 01:35:21 -0700 (PDT)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 34C2321F861E for ; Sat, 30 Jun 2012 01:35:18 -0700 (PDT)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 15D8E940072; Sat, 30 Jun 2012 10:35:11 +0200 (CEST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1084)
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC15522170B9C@EUSAACMS0703.eamcs.ericsson.se>
Date: Sat, 30 Jun 2012 10:35:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <777B1B97-D294-4D6B-A759-E7A6C40B8F93@laposte.net>
References: <4FEC753D.5090806@ericsson.com>, <310169D7-DC2C-4D77-A008-86A02972EEA9@laposte.net> <4FD1E7CD248BF84F86BD4814EDDDBCC15522170B9C@EUSAACMS0703.eamcs.ericsson.se>
To: Softwires WG , Suresh Krishnan 
X-Mailer: Apple Mail (2.1084)
Subject: [Softwires] 4rd update
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, 30 Jun 2012 08:35:22 -0000

Dear all,

1.
2012-06-29 =E0 14:24, Suresh Krishnan:
...
> submit the -02 identical to -00.

Done with tools.ietf.org/html/draft-ietf-softwire-4rd-02=20

> We can handle any further issues using the issue tracker.=20

Will learn how to do it.


2.
Please take the copied email below and =
tools.ietf.org/html/draft-ietf-softwire-4rd-01 as:
- identification of a possible security improvement of 4rd from 4rd-02
- description of the solution, presented as an update of the draft =
combined with some editorial improvements.)

Authors propose to the WG to update -02 by a re-issue of -01 as -03.
Any objection?

Regards,
RD


> De : R=E9mi Despr=E9s 
> Date : 2012-06-19 15:28
> =C0 : Softwires WG 
> Objet : Novelty in draft-ietf-softwire-4rd-01
>=20
> Dear all,
>=20
> The main difference between -00 and -O1 concerns protection against =
address or protocol corruption during 4rd-domain traversal:
> Problem: the CNP only protected IPv4 addresses of =
full-or-shared-address CEs? In particular, they didn't protect IPv4 =
addresses embedded in BR-destined IPv6 addresses (an overlook)=20
> Solution: include a checksum of IPv4 addresses and protocol in the =
flow label field=20
>  . It provides the desirable protection in a simple and intuitive way
>  . It remains compatible with the flow-label specification (see below)
>=20
>=20
> Relationship with FLs of RFC6437 is analyzed as follows:
>=20
> a) RFC6437 says "A node that forwards a flow whose flow label value in =
arriving packets is zero MAY change the flow label value.  In that case, =
it is RECOMMENDED that the forwarding node sets the flow label field for =
a flow to a uniformly distributed value as just described for source =
nodes. ... In such cases, a flow can be defined by fewer IPv6 header =
fields, typically using only the 2-tuple {dest addr, source addr}."
>=20
> b) In CEs and BRs, arriving packets are IPv4, i.e. equivalent to =
packets without FLs.=20
>=20
> c) In RFC2119, "RECOMMENDED" means that "there may exist valid reasons =
in particular circumstances to ignore a particular item, but the full =
implications must be understood and carefully weighed before choosing a =
different course".
>=20
> d) Implications, which have been well understood, have also been well =
weighted:
> - With this, FLs of 5-tuple flows aren't evenly distributed FLs, =
contrary to what is recommended
> - BUT this maintains IPv4 addresses-and-port protection without =
needing any extra header between the IPv6 header and the unchanged IP =
payload, a desirable feature of 4rd.=20
>=20
> Comments on all aspects of the proposal are welcome.
>=20
> Regards,
> RD