From iesg-secretary@ietf.org Fri Jul 1 08:18:22 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016C19E8060; Fri, 1 Jul 2011 08:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1epc1++i3UPz; Fri, 1 Jul 2011 08:18:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE209E8043; Fri, 1 Jul 2011 08:16:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110701151636.28793.25157.idtracker@ietfa.amsl.com> Date: Fri, 01 Jul 2011 08:16:36 -0700 Cc: softwires@ietf.org Subject: [Softwires] Last Call: (RADIUS Extensions for Dual-Stack Lite) to Proposed Standard X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:18:22 -0000 The IESG has received a request from the Softwires WG (softwire) to consider the following document: - 'RADIUS Extensions for Dual-Stack Lite' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers which are addressed only with an IPv6 prefix. DS-Lite requires to pre-configure the AFTR tunnel information on the B4 element. In many networks, the customer profile information may be stored in AAA servers while client configurations are mainly provided through DHC protocol. This document specifies one new RADIUS attribute to carry Dual-Stack Lite Address Family Transition Router (AFTR) name; the RADIUS attribute is defined based on the equivalent DHCPv6 option already specified in draft-ietf-softwire-ds-lite-tunnel-option. This RADIUS attribute is meant to be used between the RADIUS Server and the NAS, it is not intended to be used directly between the B4 element and the RADIUS Server. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-radius-ext/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-radius-ext/ No IPR declarations have been submitted directly on this I-D. From lizhenqiang@chinamobile.com Sat Jul 2 11:12:09 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677871F0C3E for ; Sat, 2 Jul 2011 11:12:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7tdw3WJXLk6 for ; Sat, 2 Jul 2011 11:12:08 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFB81F0C39 for ; Sat, 2 Jul 2011 11:12:07 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A9D8DA7A7; Sun, 3 Jul 2011 02:12:06 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id A163DA7A3; Sun, 3 Jul 2011 02:12:06 +0800 (CST) To: softwires@ietf.org MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Sun, 3 Jul 2011 02:12:04 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-03 02:12:06 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18236.001 X-TM-AS-Result: No--17.650-7.0-31-10 X-imss-scan-details: No--17.650-7.0-31-10;No--17.650-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 02 Jul 2011 18:12:09 -0000 Thanks, Washam, I got the intense debate. But for 6rd, the IPv4 address of the BR is recommended to use in the DHCP o= ption. Thus, different options are recommended for different technologies. = I want to know the reason. Using the similar method to do the similar thing= is better, isn't it? So, shall we modify the specification of 6rd to use a= FQDN for the BR configuration on CEs? Best Regards, Zhenqiang Li 2011-07-03=20 ----- Original Message -----=20 From: Washam Fan=20 Sent: 2011-07-01 13:04:46=20 To: lizhenqiang@chinamobile.com=20 CC: softwires@ietf.org=20 Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 o= ption?=20 =20 Hi, There was a debate between ip literal v.s. fqdn for this issue. Please search the old mail archive to check it out. If I recall correctly, a major argument would be, many ISPs prefer dns server to do load balancing over dhcp server. Thanks, washam 2011/6/30 : > Hi All, > > One question about the new DHCPv6 option for AFTR discovery. Maybe I miss= ed the previous discussion. Sorry for that. > According to draft-ietf-softwire-ds-lite-tunnel-option, a FQDN is suggest= ed to be deliveried in the new DHCPv6 option to the B4. When receiving the = FQDN, B4 has to do the DNS resolution to get the AFTR IPv6 address. The FQD= N of the AFTR has to be configured in the DNS server. So, I think deliverin= g the IPv6 address of the AFTR directly to the B4 is better. We can use DHC= Pv6 option to do this. The address of the AFTR only needs to be configured = in the DHCPv6 server. > > Best Regards, > Zhenqiang Li > 2011-06-30 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >= From washam.fan@gmail.com Sat Jul 2 21:02:06 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2721F86A1 for ; Sat, 2 Jul 2011 21:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSgpzI4uDPTm for ; Sat, 2 Jul 2011 21:02:05 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3F21F86A2 for ; Sat, 2 Jul 2011 21:02:05 -0700 (PDT) Received: by wwg11 with SMTP id 11so782022wwg.1 for ; Sat, 02 Jul 2011 21:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0jbbgox98XqqkBz02mbnptAF7BHBe4uZdN7C+Eymdgo=; b=fa5zTaK/jA2c3fBqkTffuuNnbV0Z1UudJCTA4JfugDldcu+KC0yGzzZbvjCzsxPnHl lJ2Y/XrstbQiGEPSudRU4PU40rQpiYSG4vUb1YXRjbso0fClLhgyH2a61nsFKb35YzHy 5aYIM0WIKXTrHnyVFvAwk1g+gpc63q+IF8tkQ= MIME-Version: 1.0 Received: by 10.216.50.2 with SMTP id y2mr3971187web.77.1309665721109; Sat, 02 Jul 2011 21:02:01 -0700 (PDT) Received: by 10.216.27.147 with HTTP; Sat, 2 Jul 2011 21:02:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Jul 2011 12:02:01 +0800 Message-ID: From: Washam Fan To: lizhenqiang@chinamobile.com Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 03 Jul 2011 04:02:06 -0000 Hi Zhenqiang, 6rd is stateless, so anycast address might be used for BR loadbalancing. I guess, that might be the reason why IP literal is prefered over fqdn for 6rd case. THanks, washam =D4=DA 2011=C4=EA7=D4=C23=C8=D5 =C9=CF=CE=E72:12=A3=AC =D0=B4=B5=C0=A3=BA > Thanks, Washam, I got the intense debate. > > But for 6rd, the IPv4 address of the BR is recommended to use in the DHCP= option. Thus, different options are recommended for different technologies= . I want to know the reason. Using the similar method to do the similar thi= ng is better, isn't it? So, shall we modify the specification of 6rd to use= a FQDN for the BR configuration on CEs? > > Best Regards, > Zhenqiang Li > 2011-07-03 > > > ----- Original Message ----- > From: Washam Fan > Sent: 2011-07-01 13:04:46 > To: lizhenqiang@chinamobile.com > CC: softwires@ietf.org > Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6= option? > > Hi, > > There was a debate between ip literal v.s. fqdn for this issue. Please > search the old mail archive to check it out. If I recall correctly, a > major argument would be, many ISPs prefer dns server to do load > balancing over dhcp server. > > Thanks, > washam > > 2011/6/30 : >> Hi All, >> >> One question about the new DHCPv6 option for AFTR discovery. Maybe I mis= sed the previous discussion. Sorry for that. >> According to draft-ietf-softwire-ds-lite-tunnel-option, a FQDN is sugges= ted to be deliveried in the new DHCPv6 option to the B4. When receiving the= FQDN, B4 has to do the DNS resolution to get the AFTR IPv6 address. The FQ= DN of the AFTR has to be configured in the DNS server. So, I think deliveri= ng the IPv6 address of the AFTR directly to the B4 is better. We can use DH= CPv6 option to do this. The address of the AFTR only needs to be configured= in the DHCPv6 server. >> >> Best Regards, >> Zhenqiang Li >> 2011-06-30 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> From yiu_lee@cable.comcast.com Sun Jul 3 17:00:35 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC2A21F85D5 for ; Sun, 3 Jul 2011 17:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=3.364, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0b+PgBiZrjR for ; Sun, 3 Jul 2011 17:00:34 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06121F85B1 for ; Sun, 3 Jul 2011 17:00:34 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.133058128; Sun, 03 Jul 2011 20:00:32 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Sun, 3 Jul 2011 20:00:32 -0400 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? Thread-Index: AQHMOd1e/y3YWrNBfkeusYIR9lVTHA== Date: Mon, 4 Jul 2011 00:00:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.253.6.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D30AFD8D978E840AEDA753C2D2A1E58@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 00:00:35 -0000 Few operators like to use fqdn for dslite for redundancy (multiple a-records). 6rd is stateless and can use anycast address for redundancy. This is why they are different. On 7/2/11 2:12 PM, "lizhenqiang@chinamobile.com" wrote: >ut for 6rd, the IPv4 address of the BR is recommended to use in the DHCP >option.=20 From lizhenqiang@chinamobile.com Sun Jul 3 18:53:45 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA3721F855A for ; Sun, 3 Jul 2011 18:53:45 -0700 (PDT) X-Quarantine-ID: <0uCyGemuUqj6> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uCyGemuUqj6 for ; Sun, 3 Jul 2011 18:53:45 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6110321F8557 for ; Sun, 3 Jul 2011 18:53:45 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A7140A485; Mon, 4 Jul 2011 09:53:43 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 9D587A471; Mon, 4 Jul 2011 09:53:43 +0800 (CST) To: Washam Fan, Lee@chinamobile.com, Yiu, zhangdacheng MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Mon, 4 Jul 2011 09:53:41 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-04 09:53:43 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18238.003 X-TM-AS-Result: No--11.691-7.0-31-10 X-imss-scan-details: No--11.691-7.0-31-10;No--11.691-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: softwires@ietf.org Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 01:53:46 -0000 Yes. 6rd is stateless, anycast address can be used for BR loadbalancing. Bu= t as stated in draft-zhang-behave-nat64-load-balancing, using anycast to do= the loadbalancing for the stateless transition technology has the followin= g drawbacks. Anyway, anycast address of BR can still be used by using a FQD= N of the B4 in the DHCPv4 option. The same address(i.e. the anycast address= ) is returned when the DNS server receives the DNS resolution requests from= CEs. FQDN solotion is more flexible. The efficiency of this mode largely depends on the underlying topology (e.g., location of NAT64 devices) and routing engineering policies. Moreover, a stateless device may be overloaded if the routing is not appropriately tuned and/or if the stateless devices are not appropriately dimensioned. Best Regards, Zhenqiang Li 2011-07-04=20 ----- Original Message ----- From: Washam Fan=20 Sent: 2011-07-03 12:02:07=20 To: lizhenqiang@chinamobile.com=20 CC: softwires@ietf.org=20 Subject: Re: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCP= v6 option?=20 =20 Hi Zhenqiang, 6rd is stateless, so anycast address might be used for BR loadbalancing. I guess, that might be the reason why IP literal is prefered over fqdn for 6rd case. THanks, washam From yiu_lee@cable.comcast.com Sun Jul 3 19:07:42 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410AE21F8507 for ; Sun, 3 Jul 2011 19:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-1.682, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3NpYNDbOQcP for ; Sun, 3 Jul 2011 19:07:41 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2779D21F8534 for ; Sun, 3 Jul 2011 19:07:41 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.43236682; Sun, 03 Jul 2011 20:11:41 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Sun, 3 Jul 2011 22:07:38 -0400 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? Thread-Index: AQHMOe8gvJY2OLAw6EijV0uPVEMWkw== Date: Mon, 4 Jul 2011 02:07:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.253.6.2] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 02:07:42 -0000 No disagreement here. However, we can't argue that using anycast for stateless 6rd BR does provide redundancy if an ISP designs the network properly. On the other hand, stateful dslite can't use anycast. =20 On 7/3/11 9:53 PM, "lizhenqiang@chinamobile.com" wrote: >Yes. 6rd is stateless, anycast address can be used for BR loadbalancing. >But as stated in draft-zhang-behave-nat64-load-balancing, using anycast >to do the loadbalancing for the stateless transition technology has the >following drawbacks. Anyway, anycast address of BR can still be used by >using a FQDN of the B4 in the DHCPv4 option. The same address(i.e. the >anycast address) is returned when the DNS server receives the DNS >resolution requests from CEs. FQDN solotion is more flexible. > >The efficiency of this mode largely depends on the underlying >topology (e.g., location of NAT64 devices) and routing engineering >policies. Moreover, a stateless device may be overloaded if >the routing is not appropriately tuned and/or if the stateless devices >are not appropriately dimensioned. > >Best Regards, >Zhenqiang Li >2011-07-04=20 > >----- Original Message ----- > >From: Washam Fan=20 >Sent: 2011-07-03 12:02:07 >To: lizhenqiang@chinamobile.com >CC: softwires@ietf.org >Subject: Re: Re: [Softwires] Why not use AFTR IPv6 address for the new >DHCPv6 option?=20 >=20 >Hi Zhenqiang, > >6rd is stateless, so anycast address might be used for BR >loadbalancing. I guess, that might be the reason why IP literal is >prefered over fqdn for 6rd case. > >THanks, >washam From lizhenqiang@chinamobile.com Mon Jul 4 23:44:46 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F2D21F86E4 for ; Mon, 4 Jul 2011 23:44:46 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: 0.173 X-Spam-Level: X-Spam-Status: No, score=0.173 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB9HGH4xKBPA for ; Mon, 4 Jul 2011 23:44:46 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0288621F86EC for ; Mon, 4 Jul 2011 23:44:45 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 0ECE9A52D; Tue, 5 Jul 2011 14:44:43 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 06515A4BE; Tue, 5 Jul 2011 14:44:43 +0800 (CST) To: Lee@chinamobile.com, Yiu, softwires@ietf.org MIME-Version: 1.0 From: lizhenqiang@chinamobile.com Date: Tue, 5 Jul 2011 14:44:40 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-07-05 14:44:42 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18240.004 X-TM-AS-Result: No--11.073-7.0-31-10 X-imss-scan-details: No--11.073-7.0-31-10;No--11.073-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 06:44:46 -0000 Two Points here. 1, For stateless 6rd, using anycast does provide BR redundancy, but not loa= dbalancing. Generally loadbalancing can not be achieved by anycast, see RFC= 4786 Operation of Anycast Services for more information.=20 2, Using AFTR IPv6 address in the new DHCPv6 option does dot mean to use an= ycast for the stateful dslite loadbalancing. DHCPv6 server sends different = IPv6 addresses of AFTRs to different B4s by some critera. Then, user traffi= c can be balanced among these AFTRs throngh these B4s. I do not think stateless or stateful is the key point. Both FQDN and IP add= ress can be used in the DHCP option to complete the gateway discovery. If t= he operators want, both FQDN and IP address can also be used to do the load= balancing. However, according to the respective RFC, 6rd selects IP addres= s, dslite selects FQDN. I am wondering why not use the same method? Best Regards, Zhenqiang Li ----- Original Message ----- Date: Mon, 4 Jul 2011 02:07:37 +0000 From: "Lee, Yiu" To: "softwires@ietf.org" Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? Message-ID: Content-Type: text/plain; charset=3D"us-ascii" No disagreement here. However, we can't argue that using anycast for stateless 6rd BR does provide redundancy if an ISP designs the network properly. On the other hand, stateful dslite can't use anycast. From yiu_lee@cable.comcast.com Tue Jul 5 07:04:38 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0439C11E80CF for ; Tue, 5 Jul 2011 07:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=2.243, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h65oHT8OqZKw for ; Tue, 5 Jul 2011 07:04:37 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5D29311E80B8 for ; Tue, 5 Jul 2011 07:04:37 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.133123835; Tue, 05 Jul 2011 10:04:33 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Tue, 5 Jul 2011 10:04:21 -0400 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: Why not use AFTR IPv6 address for the new DHCPv6 option? Thread-Index: AQHMOxxoBlN3BKgrbE+91RTjMsIEww== Date: Tue, 5 Jul 2011 14:04:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <250BD069743F9747A41AB63E3C293B79@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:04:38 -0000 Hi Zhenqiang, If you go back to the ML, it was the main concern of using ip address for ds-lite. Yes, you can use FQDN for anycast address, but nobody asked for it when 6rd was being standardized. Cheers, Yiu On 7/5/11 2:44 AM, "lizhenqiang@chinamobile.com" wrote: >I do not think stateless or stateful is the key point. From xiaohong.deng@orange-ftgroup.com Wed Jul 6 02:53:39 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD0F21F860A; Wed, 6 Jul 2011 02:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djlJ4zN0Dw3Q; Wed, 6 Jul 2011 02:53:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 697EF21F86BE; Wed, 6 Jul 2011 02:53:38 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9F80EFC4003; Wed, 6 Jul 2011 11:53:32 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8FFB0FC4001; Wed, 6 Jul 2011 11:53:32 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 11:53:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3BC2.8E7C6ECA" Date: Wed, 6 Jul 2011 17:53:28 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC018698AC@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft: draft-zheng-mif-apps-test-00 Thread-Index: Acw7wo5Sa/zBx7J6SFmBxSnO2ikCAQ== From: To: X-OriginalArrivalTime: 06 Jul 2011 09:53:31.0999 (UTC) FILETIME=[90720EF0:01CC3BC2] Cc: softwires@ietf.org, int-area@ietf.org, v6ops@ietf.org, behave@ietf.org Subject: [Softwires] New draft: draft-zheng-mif-apps-test-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:53:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3BC2.8E7C6ECA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, =20 A new draft describing applications behaviors dealing with multiple interface issues in the IPv6 transition context has been submitted. In this draft, DS-Lite, AplusP, NAT64 and their combinations with IPv6 provisioning have been tested and suggestions are therefore stated according to the test results. http://tools.ietf.org/id/draft-zheng-mif-apps-test-00.txt =20 =20 The Abstract of this I-D: =20 With the development of IPv6 and deployment of transition solutions, more and more hosts can access Internet with dual stack by multi-interface and applications behaviors are worth to be concerned under this environment. This memo describes the test results of some well-known applications in different scenarios under MIF environment and provides an analysis and suggestions to develop and deploy under MIF environment. =20 Comments are very much appreciated if it's something of your interest. =20 Cheers, Xiaohong =20 open source PCP Client, open source A+P http://opensourcev6transtechnologies.weebly.com/ =20 =20 ------_=_NextPart_001_01CC3BC2.8E7C6ECA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello=20 all,

 

A new draft describing applications = behaviors=20 dealing with multiple interface issues in the IPv6 transition context = has been=20 submitted. In this draft, DS-Lite, AplusP, NAT64 and their combinations = with=20 IPv6 provisioning have been tested and suggestions are therefore stated=20 according to the test results.

http://tools.ietf.org/id/draft-zheng-mif-apps-test-00.txt=

 

The Abstract of this = I-D:

 

With the development of IPv6 and = deployment of=20 transition solutions, more and more hosts can access Internet with dual = stack by=20 multi-interface and applications behaviors are worth to be concerned = under   this environment. This = memo=20 describes the test results of some well-known applications in different=20 scenarios under MIF environment and provides an analysis and suggestions = to=20 develop and deploy under MIF environment.

 

Comments are very much appreciated if = it's=20 something of your interest.

 

Cheers,

Xiaohong

 
open source PCP = Client,
open source = A+P
http://opensour= cev6transtechnologies.weebly.com/
 
 
------_=_NextPart_001_01CC3BC2.8E7C6ECA-- From mark@townsley.net Wed Jul 6 04:51:08 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4421F8506 for ; Wed, 6 Jul 2011 04:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfntRxkYvgYe for ; Wed, 6 Jul 2011 04:51:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6EC21F8680 for ; Wed, 6 Jul 2011 04:51:06 -0700 (PDT) Received: by wwe5 with SMTP id 5so4606762wwe.13 for ; Wed, 06 Jul 2011 04:51:06 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr1732896wby.18.1309953065954; Wed, 06 Jul 2011 04:51:05 -0700 (PDT) Received: from [64.103.29.88] ([64.103.29.88]) by mx.google.com with ESMTPS id c17sm6020967wbh.29.2011.07.06.04.51.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 04:51:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Wed, 6 Jul 2011 13:50:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F33E50162622@PUEXCB1B.nanterre.francetelecom.fr> To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg list , Isabel Borges , ChenGang , Softwire Chairs Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 11:51:08 -0000 I also support draft-operators-softwire-stateless-4v6-motivation-02 = becoming a WG document, and would like to see a last call on or before = the Quebec meeting.=20 Could one of the chairs please respond? - Mark On Jun 17, 2011, at 8:32 AM, Satoru Matsushima wrote: > Dear Softwires Working Group chairs, >=20 > I support that an request from Mohamed to make WG adoption as = appropriate charter item. > I'm looking forward you to take your kind adoption procedure for the = request. >=20 > Sincerely yours, >=20 > -- > Satoru Matsushima >=20 >=20 > On 2011/06/10, at 20:31, = wrote: >=20 >> Dear all, >>=20 >> An updated version of the "Motivations for Stateless IPv4 over IPv6 = Migration Solutions" I-D has been submitted. The document is available = at: >> = http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivati= on-02 >>=20 >> This document has been largely reviewed and inputs from other = contributors has been taken into account. >>=20 >> Together with my co-authors, we ask the working group to consider the = adoption of this document as a WG I-D. >>=20 >> Comments and suggestions are more than welcome. >>=20 >> Cheers, >> Med >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From mark@townsley.net Wed Jul 6 06:13:32 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF05D21F8676 for ; Wed, 6 Jul 2011 06:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj1B7kAC2NLV for ; Wed, 6 Jul 2011 06:13:31 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C120521F866A for ; Wed, 6 Jul 2011 06:13:30 -0700 (PDT) Received: by wwe5 with SMTP id 5so4657240wwe.13 for ; Wed, 06 Jul 2011 06:13:29 -0700 (PDT) Received: by 10.217.5.130 with SMTP id w2mr5522831wes.61.1309958009497; Wed, 06 Jul 2011 06:13:29 -0700 (PDT) Received: from [64.103.29.88] ([64.103.29.88]) by mx.google.com with ESMTPS id k84sm4203397weq.46.2011.07.06.06.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 06:13:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-938311871 From: Mark Townsley In-Reply-To: Date: Wed, 6 Jul 2011 15:13:13 +0200 Message-Id: <4284211D-2F71-4894-AF68-45DC4942DA3D@townsley.net> References: To: lizhenqiang@chinamobile.com X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org, Lee@chinamobile.com Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new DHCPv6 option? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:13:32 -0000 --Apple-Mail-7-938311871 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 5, 2011, at 8:44 AM, lizhenqiang@chinamobile.com wrote: > Two Points here. > 1, For stateless 6rd, using anycast does provide BR redundancy, but = not loadbalancing. Generally loadbalancing can not be achieved by = anycast, see RFC4786 Operation of Anycast Services for more information.=20= Many of the issues in RFC 4786 do not apply to 6rd. For example, RFC = 4786 says: "Load-balancing between Anycast Nodes is typically difficult to achieve (load distribution between nodes is generally unbalanced in terms of request and traffic load)." With 6rd, since the main purpose is forwarding traffic and not = processing requests, the load distribution is actually quite balanced in = terms of request and traffic load.=20 > 2, Using AFTR IPv6 address in the new DHCPv6 option does dot mean to = use anycast for the stateful dslite loadbalancing. DHCPv6 server sends = different IPv6 addresses of AFTRs to different B4s by some critera. = Then, user traffic can be balanced among these AFTRs throngh these B4s. One of the main operational advantages of a stateless solution is that = you do not have to manage which CE (B4) gets what set of configuration = data.=20 >=20 > I do not think stateless or stateful is the key point. This is a key point considering whether the system is deployable with a = single BR address or not.=20 > Both FQDN and IP address can be used in the DHCP option to complete = the gateway discovery. If the operators want, both FQDN and IP address = can also be used to do the load balancing. However, according to the = respective RFC, 6rd selects IP address, dslite selects FQDN. I am = wondering why not use the same method? As there is no requirement that an operator which deploys 6rd to deploy = ds-lite at some point or vice versa, I don't really see the operational = benefit of using the same configuration. Further, any code-savings = benefit is quite low as well since all we are talking about here is a = DHCP option. - Mark >=20 > Best Regards, > Zhenqiang Li >=20 > ----- Original Message ----- >=20 > Date: Mon, 4 Jul 2011 02:07:37 +0000 > From: "Lee, Yiu" > To: "softwires@ietf.org" > Subject: Re: [Softwires] Why not use AFTR IPv6 address for the new > DHCPv6 option? > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > No disagreement here. However, we can't argue that using anycast for > stateless 6rd BR does provide redundancy if an ISP designs the network > properly. On the other hand, stateful dslite can't use anycast. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-7-938311871 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii lizhenqiang@chinamobile.com wrote:
Two Points here.
1, For stateless 6rd, using = anycast does provide BR redundancy, but not loadbalancing. Generally = loadbalancing can not be achieved by anycast, see RFC4786 Operation of = Anycast Services for more information. =

Many of the issues in RFC = 4786 do not apply to 6rd. For example, RFC 4786 = says:

= "Load-balancing between Anycast Nodes is typically difficult to achieve (load distribution between nodes is generally unbalanced in terms of request and traffic load)."

With 6rd, since the main purpose is forwarding traffic and not =
processing requests, the load distribution is actually quite balanced in =
terms of request and traffic load. 

2, Using AFTR IPv6 address in the new DHCPv6 option = does dot mean to use anycast for the stateful dslite loadbalancing. = DHCPv6 server sends different IPv6 addresses of AFTRs to different B4s = by some critera. Then, user traffic can be balanced among these AFTRs = throngh these B4s.

One of the = main operational advantages of a stateless solution is that you do not = have to manage which CE (B4) gets what set of configuration = data. 


I do not think = stateless or stateful is the key point. =

This is a key point considering = whether the system is deployable with a single BR address or = not. 

Both FQDN and IP = address can be used in the DHCP option to complete the gateway = discovery. If the operators want, both FQDN and IP address can also be = used to do the load balancing. However, according to the respective RFC, = 6rd selects IP address, dslite selects FQDN. I am wondering why not use = the same method?

As there is = no requirement that an operator which deploys 6rd to deploy ds-lite at = some point or vice versa, I don't really see the operational benefit of = using the same configuration. Further, any code-savings benefit is quite = low as well since all we are talking about here is a DHCP = option.

- Mark


Best Regards,
Zhenqiang Li

----- = Original Message -----

Date: Mon, 4 Jul 2011 02:07:37 = +0000
From: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>= ;
To: "softwires@ietf.org" = <softwires@ietf.org>
Subject: = Re: [Softwires] Why not use AFTR IPv6 address for the new
DHCPv6 = option?
Message-ID: = <CA369744.115AC%yiu_lee@cable.comcast.com>
Content-Type: = text/plain; charset=3D"us-ascii"

No disagreement here. However, = we can't argue that using anycast for
stateless 6rd BR does provide = redundancy if an ISP designs the network
properly. On the other hand, = stateful dslite can't use = anycast.

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

= = --Apple-Mail-7-938311871-- From jguichard@juniper.net Wed Jul 6 06:23:56 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4B21F871A for ; Wed, 6 Jul 2011 06:23:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOoGn7lZG6kl for ; Wed, 6 Jul 2011 06:23:56 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD4021F8713 for ; Wed, 6 Jul 2011 06:23:55 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKThRh6up5aeXrzQ0REzWIwOldjGSIjj0N@postini.com; Wed, 06 Jul 2011 06:23:55 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 6 Jul 2011 06:23:51 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 6 Jul 2011 09:23:50 -0400 From: Jim Guichard To: Jim Guichard , "Frank Brockners (fbrockne)" Date: Wed, 6 Jul 2011 09:23:48 -0400 Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: Acw73/FSWvXLQP3ERpK+lExH3/5xKw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 13:23:56 -0000 Hi Frank, Reviewing version 04 of the draft I still do not see "vanilla" MPLS encapsulation given as an option. I would like to suggest adding something like the following to section 6: o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context within SWID may be indicated by the next MPLS label in the stack. On 3/28/11 1:17 PM, "Jim Guichard" wrote: >Hi Frank, > >What I would like to see is the ability to use TE without VPN's. I do not >want to be forced to deploy VPN infrastructure in this case. RSVP-TE is an >important piece of the puzzle as it provides the ability to steer traffic >based upon policy that I may wish to enforce. I would be happy to supply >text for the draft but would like to agree on this alias before doing so >.. > >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >wrote: > >> >>Jim, >> >>why is VPN "overkill" (kind of delicate wording these days...)? TE could >>also be combined with MPLS VPNs. >> >>Would also be interested in other folks' thoughts on the need for >>"plain" IP-over-MPLS tunnels. >> >>Thanks, Frank >> >>> -----Original Message----- >>> From: Jim Guichard [mailto:jguichard@juniper.net] >>> Sent: Friday, March 25, 2011 8:03 PM >>> To: Frank Brockners (fbrockne) >>> Cc: softwires@ietf.org >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>> >>> VPN is overkill imho plus i want the ability to engineer traffic paths >>> and for this i need TE >>> >>> Jim Guichard >>> >>> Principal Networking Architect >>> IPG CTO Office >>> Juniper Networks >>> >>> CCIE #2069 >>> >>> Sent from my iphone >>> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >>> wrote: >>> >>> > Hi Jim, >>> > >>> > fully agreed that MPLS should not be absent from the draft, and it >>is >>> > not. The current draft-ietf-softwire-gateway-init-ds-list-03 doesn't >>> > restrict things to IP tunneling. The draft already allows for MPLS >>> > transport between Gateway and AFTR using MPLS VPNs. >>> > >>> > Hence the question: For the use cases you have in mind, couldn't we >>> just >>> > use MPLS VPNs (possibly even point-to-point with just two PEs in a >>> VPN - >>> > Gateway and the AFTR)? Personally I've nothing against additional >>> > encapsulations, though so far there's always been a push in the WG >>> (and >>> > also in 3GPP SA2) to keep the number of encapsulations to a minimum >>> > (e.g. L2TPv3 was dropped from the list of encaps, because we could >>do >>> > the very same thing with GRE). >>> > >>> > On multicast: Don't fully follow your thought below. Do you consider >>> > running multicast over the softwire between AFTR and Gateway? The >>> > multicast considerations for GI-DS-lite (see >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that >>this >>> > would not be the case. >>> > >>> > Thanks, Frank >>> > >>> >> -----Original Message----- >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] >>> >> Sent: Thursday, March 24, 2011 9:43 PM >>> >> >>> >> Hi Frank, >>> >> >>> >> bi-directional tunnels are necessary if you wish for traffic flows >>> to >>> >> take >>> >> the same path in both directions across the network. It is possible >>> to >>> >> use >>> >> point-to-point but this is cumbersome to deploy. >>Point-to-multipoint >>> >> may >>> >> be necessary for multicast. >>> >> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement that >>> should >>> >> not >>> >> be absent from the draft. If an operator has MPLS why restrict them >>> to >>> >> IP >>> >> tunneling? >>> >> >>> >> >>> >>> >>> >>> to kick-start the discussion, could you outline the usage >>scenarios >>> >> that >>> >>> would drive the requirements you mention below? >>> >>> >>> > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Wed Jul 6 07:34:01 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242A21F85DA for ; Wed, 6 Jul 2011 07:34:01 -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=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK1pswCA8Txg for ; Wed, 6 Jul 2011 07:34:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 95A6821F85B1 for ; Wed, 6 Jul 2011 07:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1421; q=dns/txt; s=iport; t=1309962840; x=1311172440; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=p2zuFsbaMVCXyQSy6KQ9BCnUf+3U9nUYHYR7ieSR94E=; b=fKFYYUHCw0lMob7bzXC8hWtziTMhz8noDdLUDrKeVjSiEnhkhi47e/Ho 4ibvFkmuSHYXCfcjo7HBs1TF9annuOQCQ46Z/oXGUb8twZS4ozXRdj31P nDAnNK71V5mZJ95a6AgUyzdcAZKYEvlO5J0d/XdPiuDcpv7aNxOmm/Qo4 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAPhxFE6tJV2Z/2dsb2JhbABTmFaPLneuB54tgzSDAwSHRo9+hEqHDg X-IronPort-AV: E=Sophos;i="4.65,487,1304294400"; d="scan'208";a="405842" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 06 Jul 2011 14:34:00 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p66EXxRM022893; Wed, 6 Jul 2011 14:33:59 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 09:33:55 -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, 6 Jul 2011 09:33:54 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next step for Stateless Motivations I-D Thread-Index: Acw76btJToNzMD/3S1KZwPbKiEh6oQ== References: <94C682931C08B048B7A8645303FDC9F33E50162622@PUEXCB1B.nanterre.francetelecom.fr> From: "Rajiv Asati (rajiva)" To: "Satoru Matsushima" , X-OriginalArrivalTime: 06 Jul 2011 14:33:55.0537 (UTC) FILETIME=[BC0E3C10:01CC3BE9] Cc: chengang@chinamobile.com, Softwire Chairs , Softwires-wg , Isabel@ptinovacao.pt Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:34:01 -0000 Support. Cheers, Rajiv > -----Original Message----- > From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] > Sent: Friday, June 17, 2011 2:32 AM > To: > Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu; > Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; chengang@chinamobile.com > Subject: Re: Next step for Stateless Motivations I-D >=20 > Dear Softwires Working Group chairs, >=20 > I support that an request from Mohamed to make WG adoption as appropriate > charter item. > I'm looking forward you to take your kind adoption procedure for the request. >=20 > Sincerely yours, >=20 > -- > Satoru Matsushima >=20 >=20 > On 2011/06/10, at 20:31, > wrote: >=20 > > Dear all, > > > > An updated version of the "Motivations for Stateless IPv4 over IPv6 > Migration Solutions" I-D has been submitted. The document is available at: > > http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6- > motivation-02 > > > > This document has been largely reviewed and inputs from other contributors > has been taken into account. > > > > Together with my co-authors, we ask the working group to consider the > adoption of this document as a WG I-D. > > > > Comments and suggestions are more than welcome. > > > > Cheers, > > Med From christian.jacquenet@orange-ftgroup.com Wed Jul 6 07:35:21 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577C321F85F6 for ; Wed, 6 Jul 2011 07:35: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=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA0wrKZS2weu for ; Wed, 6 Jul 2011 07:35:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 80C0921F85DA for ; Wed, 6 Jul 2011 07:35:20 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id E84F72AC8FD; Wed, 6 Jul 2011 16:35:18 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id CAC69C805D; Wed, 6 Jul 2011 16:35:18 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 6 Jul 2011 16:35:18 +0200 From: To: Softwires-wg Date: Wed, 6 Jul 2011 16:35:18 +0200 Thread-Topic: Next step for Stateless Motivations I-D Thread-Index: Acw76btJToNzMD/3S1KZwPbKiEh6oQAAB/iA Message-ID: <23597_1309962918_4E1472A6_23597_113896_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF1F0A927@PUEXCB1C.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F33E50162622@PUEXCB1B.nanterre.francetelecom.fr> <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.6.135415 Cc: "Isabel@ptinovacao.pt" , "chengang@chinamobile.com" , Softwire Chairs , "Rajiv Asati \(rajiva\)" Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:35:21 -0000 +1 Cheers, Christian.=20 -----Message d'origine----- De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p= art de Rajiv Asati (rajiva) Envoy=E9 : mercredi 6 juillet 2011 16:34 =C0 : Satoru Matsushima; BOUCADAIR Mohamed OLNC/NAD/TIP Cc : chengang@chinamobile.com; Softwire Chairs; Softwires-wg; Isabel@ptinov= acao.pt Objet : Re: [Softwires] Next step for Stateless Motivations I-D Support. Cheers, Rajiv > -----Original Message----- > From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] > Sent: Friday, June 17, 2011 2:32 AM > To: > Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu;=20 > Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; chengang@chinamobile.com > Subject: Re: Next step for Stateless Motivations I-D >=20 > Dear Softwires Working Group chairs, >=20 > I support that an request from Mohamed to make WG adoption as appropriate > charter item. > I'm looking forward you to take your kind adoption procedure for the request. >=20 > Sincerely yours, >=20 > -- > Satoru Matsushima >=20 >=20 > On 2011/06/10, at 20:31, > wrote: >=20 > > Dear all, > > > > An updated version of the "Motivations for Stateless IPv4 over IPv6 > Migration Solutions" I-D has been submitted. The document is available at: > > http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6- > motivation-02 > > > > This document has been largely reviewed and inputs from other contributors > has been taken into account. > > > > Together with my co-authors, we ask the working group to consider the > adoption of this document as a WG I-D. > > > > Comments and suggestions are more than welcome. > > > > Cheers, > > Med _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** From fbrockne@cisco.com Wed Jul 6 07:59:41 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915A021F872A for ; Wed, 6 Jul 2011 07:59:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+YPR5qkZIaW for ; Wed, 6 Jul 2011 07:59:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1874D21F871A for ; Wed, 6 Jul 2011 07:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=5041; q=dns/txt; s=iport; t=1309964380; x=1311173980; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=gIEADa8Lt6WtqfSbhhpAtG0Slqto+v0uUZxiCxmz6aw=; b=mLnARfI56fwQ3tGS/W//2YR4D8QAB6NPhb6uViJHJymLoCfco8TGA0Gi CsIqUIZ46cIhywOq2oBaM/ZFWyFtAUUrzlHDfWBgQ33DzBuTJGrdcipoN D7VUHHVnXbfP6kdrAvb4tKHL4Oz8CyShT2BD0QHRTaN4ZnQjQMxCtArvx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAAF93FE6Q/khN/2dsb2JhbABTmFaPLnetdp4qhjcEl0SLPA X-IronPort-AV: E=Sophos;i="4.65,487,1304294400"; d="scan'208";a="40872837" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 06 Jul 2011 14:59:33 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p66ExXJW031017; Wed, 6 Jul 2011 14:59:33 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 16:59:33 +0200 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, 6 Jul 2011 16:59:30 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC06274EA9@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: Acw73/FSWvXLQP3ERpK+lExH3/5xKwADIZeg References: From: "Frank Brockners (fbrockne)" To: "Jim Guichard" X-OriginalArrivalTime: 06 Jul 2011 14:59:33.0817 (UTC) FILETIME=[50F12290:01CC3BED] Cc: softwires@ietf.org Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 14:59:41 -0000 Hi Jim, ... works for me (any additional opinions from others?). In order to get a -05 version out quickly, could you detail the change - i.e. possibly expand the bullet you propose below with some additional explanation, like e.g. what would be used as CID for "vanilla MPLS"; propose another row for the table in section 6; etc. Once we have this, we could quickly compile a -05. Thanks, Frank > -----Original Message----- > From: Jim Guichard [mailto:jguichard@juniper.net] > Sent: Wednesday, July 06, 2011 6:24 AM > To: Jim Guichard; Frank Brockners (fbrockne) > Cc: softwires@ietf.org > Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >=20 > Hi Frank, >=20 > Reviewing version 04 of the draft I still do not see "vanilla" MPLS > encapsulation given as an option. I would like to suggest adding > something > like the following to section 6: >=20 > o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context within > SWID > may be indicated by the next MPLS label in the stack. >=20 >=20 > On 3/28/11 1:17 PM, "Jim Guichard" wrote: >=20 > >Hi Frank, > > > >What I would like to see is the ability to use TE without VPN's. I do > not > >want to be forced to deploy VPN infrastructure in this case. RSVP-TE > is an > >important piece of the puzzle as it provides the ability to steer > traffic > >based upon policy that I may wish to enforce. I would be happy to > supply > >text for the draft but would like to agree on this alias before doing > so > >.. > > > >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" > >wrote: > > > >> > >>Jim, > >> > >>why is VPN "overkill" (kind of delicate wording these days...)? TE > could > >>also be combined with MPLS VPNs. > >> > >>Would also be interested in other folks' thoughts on the need for > >>"plain" IP-over-MPLS tunnels. > >> > >>Thanks, Frank > >> > >>> -----Original Message----- > >>> From: Jim Guichard [mailto:jguichard@juniper.net] > >>> Sent: Friday, March 25, 2011 8:03 PM > >>> To: Frank Brockners (fbrockne) > >>> Cc: softwires@ietf.org > >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list- > 02 > >>> > >>> VPN is overkill imho plus i want the ability to engineer traffic > paths > >>> and for this i need TE > >>> > >>> Jim Guichard > >>> > >>> Principal Networking Architect > >>> IPG CTO Office > >>> Juniper Networks > >>> > >>> CCIE #2069 > >>> > >>> Sent from my iphone > >>> > >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" > >>> wrote: > >>> > >>> > Hi Jim, > >>> > > >>> > fully agreed that MPLS should not be absent from the draft, and > it > >>is > >>> > not. The current draft-ietf-softwire-gateway-init-ds-list-03 > doesn't > >>> > restrict things to IP tunneling. The draft already allows for > MPLS > >>> > transport between Gateway and AFTR using MPLS VPNs. > >>> > > >>> > Hence the question: For the use cases you have in mind, couldn't > we > >>> just > >>> > use MPLS VPNs (possibly even point-to-point with just two PEs in > a > >>> VPN - > >>> > Gateway and the AFTR)? Personally I've nothing against additional > >>> > encapsulations, though so far there's always been a push in the > WG > >>> (and > >>> > also in 3GPP SA2) to keep the number of encapsulations to a > minimum > >>> > (e.g. L2TPv3 was dropped from the list of encaps, because we > could > >>do > >>> > the very same thing with GRE). > >>> > > >>> > On multicast: Don't fully follow your thought below. Do you > consider > >>> > running multicast over the softwire between AFTR and Gateway? The > >>> > multicast considerations for GI-DS-lite (see > >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that > >>this > >>> > would not be the case. > >>> > > >>> > Thanks, Frank > >>> > > >>> >> -----Original Message----- > >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] > >>> >> Sent: Thursday, March 24, 2011 9:43 PM > >>> >> > >>> >> Hi Frank, > >>> >> > >>> >> bi-directional tunnels are necessary if you wish for traffic > flows > >>> to > >>> >> take > >>> >> the same path in both directions across the network. It is > possible > >>> to > >>> >> use > >>> >> point-to-point but this is cumbersome to deploy. > >>Point-to-multipoint > >>> >> may > >>> >> be necessary for multicast. > >>> >> > >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement that > >>> should > >>> >> not > >>> >> be absent from the draft. If an operator has MPLS why restrict > them > >>> to > >>> >> IP > >>> >> tunneling? > >>> >> > >>> >> > >>> >>> > >>> >>> to kick-start the discussion, could you outline the usage > >>scenarios > >>> >> that > >>> >>> would drive the requirements you mention below? > >>> >>> > >>> > > > > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Wed Jul 6 08:00:45 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08E821F8749 for ; Wed, 6 Jul 2011 08:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-1.682, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4DmnspN6jnE for ; Wed, 6 Jul 2011 08:00:45 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0048021F873D for ; Wed, 6 Jul 2011 08:00:44 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.43492770; Wed, 06 Jul 2011 09:04:43 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Wed, 6 Jul 2011 11:00:36 -0400 From: "Lee, Yiu" To: "Rajiv Asati (rajiva)" , Satoru Matsushima , "mohamed.boucadair@orange-ftgroup.com" Thread-Topic: Next step for Stateless Motivations I-D Thread-Index: AQHMO+1skDLfj6K37UqO4grWST7ZWw== Date: Wed, 6 Jul 2011 15:00:35 +0000 Message-ID: In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg , "Isabel@ptinovacao.pt" , Softwire Chairs , "chengang@chinamobile.com" Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:00:45 -0000 +1 On 7/6/11 10:33 AM, "Rajiv Asati (rajiva)" wrote: >Support. > >Cheers, >Rajiv > > >> -----Original Message----- >> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] >> Sent: Friday, June 17, 2011 2:32 AM >> To: >> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu; >> Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; >chengang@chinamobile.com >> Subject: Re: Next step for Stateless Motivations I-D >>=20 >> Dear Softwires Working Group chairs, >>=20 >> I support that an request from Mohamed to make WG adoption as >appropriate >> charter item. >> I'm looking forward you to take your kind adoption procedure for the >request. >>=20 >> Sincerely yours, >>=20 >> -- >> Satoru Matsushima >>=20 >>=20 >> On 2011/06/10, at 20:31, >> wrote: >>=20 >> > Dear all, >> > >> > An updated version of the "Motivations for Stateless IPv4 over IPv6 >> Migration Solutions" I-D has been submitted. The document is available >at: >> > http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6- >> motivation-02 >> > >> > This document has been largely reviewed and inputs from other >contributors >> has been taken into account. >> > >> > Together with my co-authors, we ask the working group to consider >the >> adoption of this document as a WG I-D. >> > >> > Comments and suggestions are more than welcome. >> > >> > Cheers, >> > Med > From phdgang@gmail.com Wed Jul 6 08:23:23 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436B721F86AE for ; Wed, 6 Jul 2011 08:23:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF9d84KiVnSs for ; Wed, 6 Jul 2011 08:23:22 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7F0021F8762 for ; Wed, 6 Jul 2011 08:23:16 -0700 (PDT) Received: by vws12 with SMTP id 12so31015vws.31 for ; Wed, 06 Jul 2011 08:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g1O62dO2yyiCOspWWuo6TivlpCgHPn1NwjcGFYhTYBw=; b=VcOcJorrK5lG3DuIVGoNoZfm55pHH01iD16qbWQFQaXvKu3mLaT3ekCTo9u/oro2it vWRF9S8H3124HyY40J3ZzIY+48UAWz71MyQJK3envhxtwc/TrEPOWW35c7IlEINyI4Rl NIp393BEzco/XvHBy69PJLOzHDhxKYQEBRu2g= MIME-Version: 1.0 Received: by 10.52.72.51 with SMTP id a19mr8094669vdv.12.1309965796112; Wed, 06 Jul 2011 08:23:16 -0700 (PDT) Received: by 10.52.166.130 with HTTP; Wed, 6 Jul 2011 08:23:16 -0700 (PDT) In-Reply-To: References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com> Date: Wed, 6 Jul 2011 23:23:16 +0800 Message-ID: From: GangChen To: softwires@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "chengang@chinamobile.com" , Softwire Chairs , "Isabel@ptinovacao.pt" , "Rajiv Asati \(rajiva\)" Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:23:23 -0000 +1 2011/7/6, Lee, Yiu : > +1 > > On 7/6/11 10:33 AM, "Rajiv Asati (rajiva)" wrote: > >>Support. >> >>Cheers, >>Rajiv >> >> >>> -----Original Message----- >>> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] >>> Sent: Friday, June 17, 2011 2:32 AM >>> To: >>> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu; >>> Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; >>chengang@chinamobile.com >>> Subject: Re: Next step for Stateless Motivations I-D >>> >>> Dear Softwires Working Group chairs, >>> >>> I support that an request from Mohamed to make WG adoption as >>appropriate >>> charter item. >>> I'm looking forward you to take your kind adoption procedure for the >>request. >>> >>> Sincerely yours, >>> >>> -- >>> Satoru Matsushima >>> >>> >>> On 2011/06/10, at 20:31, >>> wrote: >>> >>> > Dear all, >>> > >>> > An updated version of the "Motivations for Stateless IPv4 over IPv6 >>> Migration Solutions" I-D has been submitted. The document is available >>at: >>> > http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6- >>> motivation-02 >>> > >>> > This document has been largely reviewed and inputs from other >>contributors >>> has been taken into account. >>> > >>> > Together with my co-authors, we ask the working group to consider >>the >>> adoption of this document as a WG I-D. >>> > >>> > Comments and suggestions are more than welcome. >>> > >>> > Cheers, >>> > Med >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From tetsuya@ipinfusion.com Wed Jul 6 08:49:51 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D21A21F880D for ; Wed, 6 Jul 2011 08:49:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOH99ZXuAQRo for ; Wed, 6 Jul 2011 08:49:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2A221F87D6 for ; Wed, 6 Jul 2011 08:49:49 -0700 (PDT) Received: by gyd5 with SMTP id 5so31486gyd.31 for ; Wed, 06 Jul 2011 08:49:49 -0700 (PDT) Received: by 10.236.173.33 with SMTP id u21mr10128189yhl.426.1309967389012; Wed, 06 Jul 2011 08:49:49 -0700 (PDT) Received: from [192.168.0.6] (c-76-102-170-116.hsd1.ca.comcast.net [76.102.170.116]) by mx.google.com with ESMTPS id w70sm5691593yhl.73.2011.07.06.08.49.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Jul 2011 08:49:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tetsuya Murakami In-Reply-To: Date: Wed, 6 Jul 2011 08:49:45 -0700 Content-Transfer-Encoding: 7bit Message-Id: <27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: "chengang@chinamobile.com" , Softwire Chairs , softwires@ietf.org, "Isabel@ptinovacao.pt" , "Rajiv Asati \(rajiva\)" Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:49:51 -0000 +1 On 2011/07/06, at 8:23, GangChen wrote: > +1 > > > 2011/7/6, Lee, Yiu : >> +1 >> >> On 7/6/11 10:33 AM, "Rajiv Asati (rajiva)" wrote: >> >>> Support. >>> >>> Cheers, >>> Rajiv >>> >>> >>>> -----Original Message----- >>>> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] >>>> Sent: Friday, June 17, 2011 2:32 AM >>>> To: >>>> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu; >>>> Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; >>> chengang@chinamobile.com >>>> Subject: Re: Next step for Stateless Motivations I-D >>>> >>>> Dear Softwires Working Group chairs, >>>> >>>> I support that an request from Mohamed to make WG adoption as >>> appropriate >>>> charter item. >>>> I'm looking forward you to take your kind adoption procedure for the >>> request. >>>> >>>> Sincerely yours, >>>> >>>> -- >>>> Satoru Matsushima >>>> >>>> >>>> On 2011/06/10, at 20:31, >>>> wrote: >>>> >>>>> Dear all, >>>>> >>>>> An updated version of the "Motivations for Stateless IPv4 over IPv6 >>>> Migration Solutions" I-D has been submitted. The document is available >>> at: >>>>> http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6- >>>> motivation-02 >>>>> >>>>> This document has been largely reviewed and inputs from other >>> contributors >>>> has been taken into account. >>>>> >>>>> Together with my co-authors, we ask the working group to consider >>> the >>>> adoption of this document as a WG I-D. >>>>> >>>>> Comments and suggestions are more than welcome. >>>>> >>>>> Cheers, >>>>> Med >>> >> >> _______________________________________________ >> 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 xing@cernet.edu.cn Wed Jul 6 16:17:00 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E986C21F8A54 for ; Wed, 6 Jul 2011 16:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHs2-NBUzVFw for ; Wed, 6 Jul 2011 16:17:00 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id D7F1521F8A53 for ; Wed, 6 Jul 2011 16:16:59 -0700 (PDT) Received: from [127.0.0.1]([125.34.48.245]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm164e156420; Thu, 07 Jul 2011 07:16:34 +0800 Message-ID: <4E14ECCA.2020507@cernet.edu.cn> Date: Thu, 07 Jul 2011 07:16:26 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Mark Townsley References: <94C682931C08B048B7A8645303FDC9F33E50162622@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cNcUbe0B Cc: Softwires-wg list , Isabel Borges , ChenGang , Softwire Chairs Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 23:17:01 -0000 Support. xing 于 2011/7/6 19:50, Mark Townsley 写é“: > I also support draft-operators-softwire-stateless-4v6-motivation-02 becoming a WG document, and would like to see a last call on or before the Quebec meeting. > > Could one of the chairs please respond? > > - Mark > > On Jun 17, 2011, at 8:32 AM, Satoru Matsushima wrote: > >> Dear Softwires Working Group chairs, >> >> I support that an request from Mohamed to make WG adoption as appropriate charter item. >> I'm looking forward you to take your kind adoption procedure for the request. >> Sincerely yours, >> >> -- >> Satoru Matsushima >> >> >> On 2011/06/10, at 20:31, wrote: >> >>> Dear all, >>> >>> An updated version of the "Motivations for Stateless IPv4 over IPv6 Migration Solutions" I-D has been submitted. The document is available at: >>> http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02 >>> >>> This document has been largely reviewed and inputs from other contributors has been taken into account. >>> >>> Together with my co-authors, we ask the working group to consider the adoption of this document as a WG I-D. >>> >>> Comments and suggestions are more than welcome. >>> >>> Cheers, >>> Med >> _______________________________________________ >> 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 cuiyong@tsinghua.edu.cn Wed Jul 6 18:37:26 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1A421F87AF for ; Wed, 6 Jul 2011 18:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzFasXm7lnxY for ; Wed, 6 Jul 2011 18:37:26 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 40C7921F8780 for ; Wed, 6 Jul 2011 18:37:26 -0700 (PDT) Received: from th024242.ip.tsinghua.edu.cn ([59.66.24.242]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1QedWs-0002zR-Bz; Thu, 07 Jul 2011 09:37:22 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 07 Jul 2011 09:37:19 +0800 From: Yong Cui To: Softwires-wg list Message-ID: Thread-Topic: Call for Agenda @ IETF 81 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 01:37:27 -0000 Hi guys, If you are planing to present something in the Softwire WG in Quebec City, please send your agenda item requests to Alain and me by 7/12 in the following format: (presenter's name, draft name, ietf link) We also need your slides by Saturday 7/23 (before the meeting starts). Thanks. - Alain & Yong. From cuiyong@tsinghua.edu.cn Wed Jul 6 18:46:27 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5C321F88A1 for ; Wed, 6 Jul 2011 18:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXP2zqZtm+H5 for ; Wed, 6 Jul 2011 18:46:26 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2953321F889E for ; Wed, 6 Jul 2011 18:46:26 -0700 (PDT) Received: from th024242.ip.tsinghua.edu.cn ([59.66.24.242]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Qedfd-0003E0-5t; Thu, 07 Jul 2011 09:46:25 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 07 Jul 2011 09:46:16 +0800 From: Yong Cui To: Softwires-wg list Message-ID: Thread-Topic: Call for contribution & draft Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] Call for contribution & draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 01:46:27 -0000 According to our softwire WG milestones, some work items have not been addressed, e.g. 6rd operational document. Some other drafts including our MIBs also need further reviews. So you are welcome to contribute to the WG. Thanks for your effort, - Alain & Yong From shtsuchi@cisco.com Wed Jul 6 20:36:42 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A286621F89D2 for ; Wed, 6 Jul 2011 20:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45QeQvOK3uML for ; Wed, 6 Jul 2011 20:36:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9821F89B0 for ; Wed, 6 Jul 2011 20:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2335; q=dns/txt; s=iport; t=1310009801; x=1311219401; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Zu71w2qGspNQRW6kwu8GV2e+rR1chfViEjYdUJcCAV0=; b=BSopRFmcMkqbFZY6m/1afpqbOPzTJ/t5ix0cLSyqPId5hqKfOaKiK/+2 NsK2y/Em6U4uC+Rzmwe8Z3tsZmr9xjZRctmfKzbci+zf27ZoA0oVh9PpP i3vtbTmcsdLV9+8hk0CQz4wUIcYR6aP1PaIbPIiPMKTM9bnRRqwcQppnB 0=; X-IronPort-AV: E=Sophos;i="4.65,491,1304294400"; d="scan'208";a="40941419" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 07 Jul 2011 03:36:39 +0000 Received: from [64.104.52.132] (dhcp-tmt-wirelessdata-64-104-52-132.cisco.com [64.104.52.132]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p673aank018355; Thu, 7 Jul 2011 03:36:37 GMT Message-ID: <4E1529C4.4000800@cisco.com> Date: Thu, 07 Jul 2011 12:36:36 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tetsuya@ipinfusion.com References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com> <27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> In-Reply-To: <27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: chengang@chinamobile.com, softwire-chairs@tools.ietf.org, softwires@ietf.org, Isabel@ptinovacao.pt, rajiva@cisco.com Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 03:36:42 -0000 +1 Tetsuya Murakami wrote: > +1 > > On 2011/07/06, at 8:23, GangChen wrote: > >> +1 >> >> >> 2011/7/6, Lee, Yiu: >>> +1 >>> >>> On 7/6/11 10:33 AM, "Rajiv Asati (rajiva)" wrote: >>> >>>> Support. >>>> >>>> Cheers, >>>> Rajiv >>>> >>>> >>>>> -----Original Message----- >>>>> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] >>>>> Sent: Friday, June 17, 2011 2:32 AM >>>>> To: >>>>> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; Lee, Yiu; >>>>> Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; >>>> chengang@chinamobile.com >>>>> Subject: Re: Next step for Stateless Motivations I-D >>>>> >>>>> Dear Softwires Working Group chairs, >>>>> >>>>> I support that an request from Mohamed to make WG adoption as >>>> appropriate >>>>> charter item. >>>>> I'm looking forward you to take your kind adoption procedure for the >>>> request. >>>>> >>>>> Sincerely yours, >>>>> >>>>> -- >>>>> Satoru Matsushima >>>>> >>>>> >>>>> On 2011/06/10, at 20:31, >>>>> wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> An updated version of the "Motivations for Stateless IPv4 over IPv6 >>>>> Migration Solutions" I-D has been submitted. The document is available >>>> at: >>>>>> http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6- >>>>> motivation-02 >>>>>> >>>>>> This document has been largely reviewed and inputs from other >>>> contributors >>>>> has been taken into account. >>>>>> >>>>>> Together with my co-authors, we ask the working group to consider >>>> the >>>>> adoption of this document as a WG I-D. >>>>>> >>>>>> Comments and suggestions are more than welcome. >>>>>> >>>>>> Cheers, >>>>>> Med >>>> >>> >>> _______________________________________________ >>> 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 xuxiaohu@huawei.com Wed Jul 6 20:44:57 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5064121F8A3A for ; Wed, 6 Jul 2011 20:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nksIIxTxk-Vx for ; Wed, 6 Jul 2011 20:44:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BD4A921F8A36 for ; Wed, 6 Jul 2011 20:44:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY00M102E1RC@szxga04-in.huawei.com> for softwires@ietf.org; Thu, 07 Jul 2011 11:44:25 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY00CHL2DLSR@szxga04-in.huawei.com> for softwires@ietf.org; Thu, 07 Jul 2011 11:44:25 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACI01695; Thu, 07 Jul 2011 11:44:20 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Jul 2011 11:44:16 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.136]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Thu, 07 Jul 2011 11:44:20 +0800 Date: Thu, 07 Jul 2011 03:44:28 +0000 From: Xuxiaohu In-reply-to: X-Originating-IP: [10.110.98.57] To: Mark Townsley , Satoru Matsushima Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE6F7C94@szxeml525-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [Softwires] Next step for Stateless Motivations I-D Thread-index: AQHMO9MiMueB10YI+0u199S3PxUo65TgO4Og X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <94C682931C08B048B7A8645303FDC9F33E50162622@PUEXCB1B.nanterre.francetelecom.fr> Cc: Softwires-wg list , Isabel Borges , ChenGang , Softwire Chairs Subject: [Softwires] =?gb2312?b?tPC4tDogIE5leHQgc3RlcCBmb3IgU3RhdGVsZXNz?= =?gb2312?b?IE1vdGl2YXRpb25zIEktRA==?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 03:48:30 -0000 KzENCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBzb2Z0d2lyZXMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnXSC0+g0KPiCx7SBNYXJr IFRvd25zbGV5DQo+ILeiy83KsbzkOiAyMDExxOo31MI2yNUgMTk6NTENCj4gytW8/sjLOiBTYXRv cnUgTWF0c3VzaGltYQ0KPiCzrcvNOiBTb2Z0d2lyZXMtd2cgbGlzdDsgSXNhYmVsIEJvcmdlczsg Q2hlbkdhbmc7IFNvZnR3aXJlIENoYWlycw0KPiDW98ziOiBSZTogW1NvZnR3aXJlc10gTmV4dCBz dGVwIGZvciBTdGF0ZWxlc3MgTW90aXZhdGlvbnMgSS1EDQo+IA0KPiANCj4gSSBhbHNvIHN1cHBv cnQgZHJhZnQtb3BlcmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlvbi0wMiBi ZWNvbWluZw0KPiBhIFdHIGRvY3VtZW50LCBhbmQgd291bGQgbGlrZSB0byBzZWUgYSBsYXN0IGNh bGwgb24gb3IgYmVmb3JlIHRoZSBRdWViZWMNCj4gbWVldGluZy4NCj4gDQo+IENvdWxkIG9uZSBv ZiB0aGUgY2hhaXJzIHBsZWFzZSByZXNwb25kPw0KPiANCj4gLSBNYXJrDQo+IA0KPiBPbiBKdW4g MTcsIDIwMTEsIGF0IDg6MzIgQU0sIFNhdG9ydSBNYXRzdXNoaW1hIHdyb3RlOg0KPiANCj4gPiBE ZWFyIFNvZnR3aXJlcyBXb3JraW5nIEdyb3VwIGNoYWlycywNCj4gPg0KPiA+IEkgc3VwcG9ydCB0 aGF0IGFuIHJlcXVlc3QgZnJvbSBNb2hhbWVkIHRvIG1ha2UgV0cgYWRvcHRpb24gYXMNCj4gYXBw cm9wcmlhdGUgY2hhcnRlciBpdGVtLg0KPiA+IEknbSBsb29raW5nIGZvcndhcmQgeW91IHRvIHRh a2UgeW91ciBraW5kIGFkb3B0aW9uIHByb2NlZHVyZSBmb3IgdGhlIHJlcXVlc3QuDQo+IA0KPiA+ DQo+ID4gU2luY2VyZWx5IHlvdXJzLA0KPiA+DQo+ID4gLS0NCj4gPiBTYXRvcnUgTWF0c3VzaGlt YQ0KPiA+DQo+ID4NCj4gPiBPbiAyMDExLzA2LzEwLCBhdCAyMDozMSwgPG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS1mdGdyb3VwLmNvbT4NCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS1mdGdy b3VwLmNvbT4gd3JvdGU6DQo+ID4NCj4gPj4gRGVhciBhbGwsDQo+ID4+DQo+ID4+IEFuIHVwZGF0 ZWQgdmVyc2lvbiBvZiB0aGUgIk1vdGl2YXRpb25zIGZvciBTdGF0ZWxlc3MgSVB2NCBvdmVyIElQ djYNCj4gTWlncmF0aW9uIFNvbHV0aW9ucyIgSS1EIGhhcyBiZWVuIHN1Ym1pdHRlZC4gVGhlIGRv Y3VtZW50IGlzIGF2YWlsYWJsZSBhdDoNCj4gPj4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtb3BlcmF0b3JzLXNvZnR3aXJlLXN0YXRlbGVzcy00djYtbW90aXZhdGlvbi0wMg0K PiA+Pg0KPiA+PiBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIGxhcmdlbHkgcmV2aWV3ZWQgYW5kIGlu cHV0cyBmcm9tIG90aGVyIGNvbnRyaWJ1dG9ycw0KPiBoYXMgYmVlbiB0YWtlbiBpbnRvIGFjY291 bnQuDQo+ID4+DQo+ID4+IFRvZ2V0aGVyIHdpdGggbXkgY28tYXV0aG9ycywgd2UgYXNrIHRoZSB3 b3JraW5nIGdyb3VwIHRvIGNvbnNpZGVyIHRoZQ0KPiBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50 IGFzIGEgV0cgSS1ELg0KPiA+Pg0KPiA+PiBDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIG1v cmUgdGhhbiB3ZWxjb21lLg0KPiA+Pg0KPiA+PiBDaGVlcnMsDQo+ID4+IE1lZA0KPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBTb2Z0 d2lyZXMgbWFpbGluZyBsaXN0DQo+ID4gU29mdHdpcmVzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNvZnR3aXJlcyBtYWlsaW5n IGxpc3QNCj4gU29mdHdpcmVzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc29mdHdpcmVzDQo= From phdgang@gmail.com Thu Jul 7 00:46:42 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD28A21F8802; Thu, 7 Jul 2011 00:46:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2-6TDSdTa1X; Thu, 7 Jul 2011 00:46:42 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF59F21F88B1; Thu, 7 Jul 2011 00:46:40 -0700 (PDT) Received: by vws12 with SMTP id 12so642735vws.31 for ; Thu, 07 Jul 2011 00:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=j7aknFtwZbN+hhvjNF+V5Hc78GSxeMQk5FJEC3LkJ4E=; b=QC4B25zP33J63yPbS8IlNAL7LE1EJxAFG46D4e+JypY5W7wxg+I523GrUkXBrB/Zz+ 703l/sPSYWE3ekhtZ7eQZg0+F1B0JQhP4AgLR5vipo9RVu8EkH622nkJ2tUwNCoJnA0L 9qtTWHn/eK7En9IMaxsJWPl9rGf9aaLxMAzeU= MIME-Version: 1.0 Received: by 10.52.72.51 with SMTP id a19mr690915vdv.12.1310024800364; Thu, 07 Jul 2011 00:46:40 -0700 (PDT) Received: by 10.52.166.130 with HTTP; Thu, 7 Jul 2011 00:46:40 -0700 (PDT) Date: Thu, 7 Jul 2011 15:46:40 +0800 Message-ID: From: GangChen To: softwires , Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] [Softwire] New Version Notification for draft-murakami-softwire-4v6-translation-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: Thu, 07 Jul 2011 07:46:42 -0000 Dear all, We have submitted a draft regarding 4via6 stateless translation. http://tools.ietf.org/id/draft-murakami-softwire-4v6-translation-00.txt comments are welcome. A new version of I-D, draft-murakami-softwire-4v6-translation-00.txt has been successfully submitted by Tetsuya Murakami and posted to the IETF repository. Filename: draft-murakami-softwire-4v6-translation Revision: 00 Title: 4via6 Stateless Translation Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 10 Abstract: This document specify 4via6, a solution for IPv4 connectivity across IPv6 network utilizes 4rd algorithmic address mapping rule as a series of stateless IPv4 over IPv6 migration solutions. 4via6 employ stateless address translation techniques. It is useful for operators who want to provide IPv4 connectivity across restricted bandwidth IPv6 network with stateless operation. Many thanks Gang From eleven.fuyu@huawei.com Thu Jul 7 00:54:28 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FADD21F88EA for ; Thu, 7 Jul 2011 00:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[AWL=1.348, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q0=0.303] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk95I1fnIDtz for ; Thu, 7 Jul 2011 00:54:27 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3508021F88D5 for ; Thu, 7 Jul 2011 00:54:27 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY00JQ7DYASI@szxga04-in.huawei.com> for softwires@ietfa.amsl.com; Thu, 07 Jul 2011 15:54:10 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY006GUDY95A@szxga04-in.huawei.com> for softwires@ietfa.amsl.com; Thu, 07 Jul 2011 15:54:10 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACI16876; Thu, 07 Jul 2011 15:54:09 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Jul 2011 15:54:02 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.8.3]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Thu, 07 Jul 2011 15:54:07 +0800 Date: Thu, 07 Jul 2011 07:53:22 +0000 From: "Eleven Fu(Yu)" X-Originating-IP: [10.110.98.70] To: "softwires@ietfa.amsl.com" Message-id: MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_1wCTOnGA2BSlrvok4e4mxQ)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Confirmation of list posting -- confirmation ID: VY6Xy2ThVRwQ Thread-index: Acw8ewvCSV1fBf7XS4uFo4HGV/bfow== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [Softwires] Confirmation of list posting -- confirmation ID: VY6Xy2ThVRwQ X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:54:28 -0000 --Boundary_(ID_1wCTOnGA2BSlrvok4e4mxQ) Content-type: multipart/alternative; boundary="Boundary_(ID_YNHGsxbyWYzly4mjMhEeHw)" --Boundary_(ID_YNHGsxbyWYzly4mjMhEeHw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT reply ________________________________ [Company_logo]Yu Fu Phone: 010-82882578 Email: eleven.fuyu@huawei.com Huawei Technologies Co., Ltd. Shangdi Xinxi Road 3#, Haidian District, Beijing 100085, P.R.China --Boundary_(ID_YNHGsxbyWYzly4mjMhEeHw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

reply

 

3D"Company_logo"Yu Fu
Phone: 010-82882578
Email: eleven.fuyu@huawei.com
Huawei Technologies Co., Ltd.
Shangdi Xinxi Road 3#, Haidian District, Beijing 100085, P.R.China

 

 

--Boundary_(ID_YNHGsxbyWYzly4mjMhEeHw)-- --Boundary_(ID_1wCTOnGA2BSlrvok4e4mxQ) Content-id: Content-type: image/jpeg; name=image001.jpg Content-transfer-encoding: base64 Content-disposition: inline; filename=image001.jpg; size=6737; creation-date="Thu, 07 Jul 2011 07:53:22 GMT"; modification-date="Thu, 07 Jul 2011 07:53:22 GMT" Content-description: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_1wCTOnGA2BSlrvok4e4mxQ)-- From eleven.fuyu@huawei.com Wed Jul 6 23:27:13 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755A421F88D5 for ; Wed, 6 Jul 2011 23:27:13 -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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwth4GT9zrj3 for ; Wed, 6 Jul 2011 23:27:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D27E621F88CA for ; Wed, 6 Jul 2011 23:27:12 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY002K69S15F@szxga05-in.huawei.com> for softwires@ietf.org; Thu, 07 Jul 2011 14:24:01 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY002J99QJLW@szxga05-in.huawei.com> for softwires@ietf.org; Thu, 07 Jul 2011 14:24:01 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACI09907; Thu, 07 Jul 2011 14:24:00 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Jul 2011 14:23:54 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.8.3]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Thu, 07 Jul 2011 14:23:59 +0800 Date: Thu, 07 Jul 2011 06:23:14 +0000 From: "Eleven Fu(Yu)" In-reply-to: <5D36713D8A4E7348A7E10DF7437A4B9286BE98@SZXEML504-MBX.china.huawei.com> X-Originating-IP: [10.110.98.70] To: Yong Cui , "adurand@juniper.net" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Call for Agenda @ IETF 81 Thread-index: AQHMPEZ0AVefakzds06LE2THqZFnI5TgOhfwgAAAUVA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B9286BE98@SZXEML504-MBX.china.huawei.com> Cc: "softwires@ietf.org" Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:54:37 -0000 Hi Alain & Yong: For the upcoming 81th IETF meeting, I am planning to present DS-Lite MIB in softwire WG in Quebec city. presenter's name: Yu Fu draft name: DS-Lite Management Information Base (MIB) ietf link: http://tools.ietf.org/html/draft-fu-softwire-dslite-mib-00 Please arrange time. Thank you very much. Best Regards, ------------------------------------------------ Yu Fu Phone: 010-82882578 Email: eleven.fuyu@huawei.com Huawei Technologies Co., Ltd. Shangdi Xinxi Road 3#, Haidian District, Beijing 100085, P.R.China > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Yong Cui > Sent: Thursday, July 07, 2011 9:37 AM > To: Softwires-wg list > Cc: Yong Cui > Subject: [Softwires] Call for Agenda @ IETF 81 > > Hi guys, > > If you are planing to present something in the Softwire WG in Quebec > City, > please send your agenda item requests to Alain and me by 7/12 in the > following format: > (presenter's name, draft name, ietf link) > > We also need your slides by Saturday 7/23 (before the meeting starts). > > Thanks. > > - Alain & Yong. > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From xiaohong.deng@orange-ftgroup.com Thu Jul 7 01:03:34 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A680E21F8872 for ; Thu, 7 Jul 2011 01:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9fiPsuFUIsK for ; Thu, 7 Jul 2011 01:03:34 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id AF4BF21F87BA for ; Thu, 7 Jul 2011 01:03:33 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F0C2FC4010; Thu, 7 Jul 2011 10:03:32 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 00617FC400F; Thu, 7 Jul 2011 10:03:31 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 10:03:31 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 16:03:28 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <4E1529C4.4000800@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[Softwires] Next step for Stateless Motivations I-D Thread-Index: Acw8fFqyuGn6ZgsKS8ObsTSm+skKNw== References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com><27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> <4E1529C4.4000800@cisco.com> From: To: , X-OriginalArrivalTime: 07 Jul 2011 08:03:31.0921 (UTC) FILETIME=[5CE7D410:01CC3C7C] Cc: softwires@ietf.org, Isabel@ptinovacao.pt, chengang@chinamobile.com, softwire-chairs@tools.ietf.org, rajiva@cisco.com Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:03:34 -0000 +1 Cheers, Xiaohong. open source PCP Client, open source A+P http://opensourcev6transtechnologies.weebly.com/ | |+1 | |Tetsuya Murakami wrote: |> +1 |>=20 |> On 2011/07/06, at 8:23, GangChen wrote: |>=20 |>> +1 |>> |>> |>> 2011/7/6, Lee, Yiu: |>>> +1 |>>> |>>> On 7/6/11 10:33 AM, "Rajiv Asati=20 |(rajiva)" wrote: |>>> |>>>> Support. |>>>> |>>>> Cheers, |>>>> Rajiv |>>>> |>>>> |>>>>> -----Original Message----- |>>>>> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] |>>>>> Sent: Friday, June 17, 2011 2:32 AM=20 |>>>>> To: |>>>>> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs';=20 |Lee, Yiu;=20 |>>>>> Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; |>>>> chengang@chinamobile.com |>>>>> Subject: Re: Next step for Stateless Motivations I-D |>>>>> |>>>>> Dear Softwires Working Group chairs, |>>>>> |>>>>> I support that an request from Mohamed to make WG adoption as |>>>> appropriate |>>>>> charter item. |>>>>> I'm looking forward you to take your kind adoption procedure for=20 |>>>>> the |>>>> request. |>>>>> |>>>>> Sincerely yours, |>>>>> |>>>>> -- |>>>>> Satoru Matsushima |>>>>> |>>>>> |>>>>> On 2011/06/10, at 20:31, |>>>>> wrote: |>>>>> |>>>>>> Dear all, |>>>>>> |>>>>>> An updated version of the "Motivations for Stateless IPv4 over=20 |>>>>>> IPv6 |>>>>> Migration Solutions" I-D has been submitted. The document is=20 |>>>>> available |>>>> at: |>>>>>>=20 |http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6 |>>>>>> - |>>>>> motivation-02 |>>>>>> |>>>>>> This document has been largely reviewed and inputs from other |>>>> contributors |>>>>> has been taken into account. |>>>>>> |>>>>>> Together with my co-authors, we ask the working group=20 |to consider |>>>> the |>>>>> adoption of this document as a WG I-D. |>>>>>> |>>>>>> Comments and suggestions are more than welcome. |>>>>>> |>>>>>> Cheers, |>>>>>> Med |>>>> |>>> |>>> _______________________________________________ |>>> 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 | | | | From cuiyong@tsinghua.edu.cn Thu Jul 7 01:38:02 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C365921F8782 for ; Thu, 7 Jul 2011 01:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeJxLxBdMM+e for ; Thu, 7 Jul 2011 01:38:02 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1102521F8696 for ; Thu, 7 Jul 2011 01:38:02 -0700 (PDT) Received: from th024242.ip.tsinghua.edu.cn ([59.66.24.242]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Qek5v-00027t-Be; Thu, 07 Jul 2011 16:37:59 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 07 Jul 2011 16:37:54 +0800 From: Yong Cui To: Softwires-wg list Message-ID: Thread-Topic: WG last call on RADIUS Attribute for 6rd Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Yong Cui Subject: [Softwires] WG last call on RADIUS Attribute for 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:38:02 -0000 The chairs of the Softwire WG would like to start a 2-week working group last call on =B3RADIUS Attribute for 6rd=B2. http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/ Please send substantive comments to the list and editorial comments to the authors. The wg last call ends on July 21 at 9am EST. - Alain & Yong From jguichard@juniper.net Thu Jul 7 05:18:55 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DDE21F85B0 for ; Thu, 7 Jul 2011 05:18:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIs7HPUH9-kJ for ; Thu, 7 Jul 2011 05:18:54 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 639FB21F8793 for ; Thu, 7 Jul 2011 05:18:53 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKThWkLEyi1oxk63miZbOtxNBtOCK3LG6a@postini.com; Thu, 07 Jul 2011 05:18:54 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Jul 2011 05:14:09 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 7 Jul 2011 08:14:08 -0400 From: Jim Guichard To: Paco Cortes Date: Thu, 7 Jul 2011 08:14:05 -0400 Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: Acw8n177/wvNfMIjTnm5sLx5HXYI+A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 12:18:55 -0000 Hi Paco, Comments inline .. On 7/7/11 3:39 AM, "Paco Cortes" wrote: >Hi Jim, > >can you clarify with the upper case part of your proposal? > > o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT WITHIN swid >MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK. > >You are speaking about a fully different case than the "MPLS VPN" case >currently in the draft, where the VPN label (i.e. the inner MPLS >label) is the SWID. >To me it sounds like a very significant change to gi-ds-lite, as you >seem to be proposing that traffic inside a softwire can be further >"split" into contexts with some meaning (differentiated handling?) by >the AFTR. Jim> yes, exactly this. In this case the SWID is the top label and the next label in the stack is the CID. > >Regarding the overall discussion in this thread (sorry I didn't answer >earlier), I disagree on the MPLS VPN case to be an overkill. In many >cases, the one-label overhead in part of the path is fully justified >by the gained operational simplicity (given by relaying on MP-BGP and >possibly CE-PE protocol for "softwire" setup and control signalling). >Also, as already mentioned by Yiu, it enables a very simple >implementation of overlapping IP addresses. Although this could also >be possible with your "vanilla MPLS" proposal, it would require some >kind of additional (proprietary?) implementation both in Gateway and >AFTR. Jim> let me clarify .. I completely agree that VPN should be included. My overkill comment was more to do with the fact that in some situations it is not necessary to deploy the full MPLS VPN machinery. > >This said, I do see the point on adding "vanilla MPLS" as possible >embodiment to the draft. There may be simple scenarios where it is >fully sufficient. >Maybe adding a bullet to section 6 like: > > o IPv4/IPv6-in-MPLS: SWID is the MPLS label. > >Would this be ok for you? Jim> I would like to see SWID =3D top label, CID =3D next label in stack noting that the SWID label is not PHP. > >br, > Paco > > >2011/7/6 Frank Brockners (fbrockne) : >> Hi Jim, >> >> ... works for me (any additional opinions from others?). >> >> In order to get a -05 version out quickly, could you detail the change - >> i.e. possibly expand the bullet you propose below with some additional >> explanation, like e.g. what would be used as CID for "vanilla MPLS"; >> propose another row for the table in section 6; etc. >> >> Once we have this, we could quickly compile a -05. >> >> Thanks, Frank >> >>> -----Original Message----- >>> From: Jim Guichard [mailto:jguichard@juniper.net] >>> Sent: Wednesday, July 06, 2011 6:24 AM >>> To: Jim Guichard; Frank Brockners (fbrockne) >>> Cc: softwires@ietf.org >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>> >>> Hi Frank, >>> >>> Reviewing version 04 of the draft I still do not see "vanilla" MPLS >>> encapsulation given as an option. I would like to suggest adding >>> something >>> like the following to section 6: >>> >>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context within >>> SWID >>> may be indicated by the next MPLS label in the stack. >>> >>> >>> On 3/28/11 1:17 PM, "Jim Guichard" wrote: >>> >>> >Hi Frank, >>> > >>> >What I would like to see is the ability to use TE without VPN's. I do >>> not >>> >want to be forced to deploy VPN infrastructure in this case. RSVP-TE >>> is an >>> >important piece of the puzzle as it provides the ability to steer >>> traffic >>> >based upon policy that I may wish to enforce. I would be happy to >>> supply >>> >text for the draft but would like to agree on this alias before doing >>> so >>> >.. >>> > >>> >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >>> >wrote: >>> > >>> >> >>> >>Jim, >>> >> >>> >>why is VPN "overkill" (kind of delicate wording these days...)? TE >>> could >>> >>also be combined with MPLS VPNs. >>> >> >>> >>Would also be interested in other folks' thoughts on the need for >>> >>"plain" IP-over-MPLS tunnels. >>> >> >>> >>Thanks, Frank >>> >> >>> >>> -----Original Message----- >>> >>> From: Jim Guichard [mailto:jguichard@juniper.net] >>> >>> Sent: Friday, March 25, 2011 8:03 PM >>> >>> To: Frank Brockners (fbrockne) >>> >>> Cc: softwires@ietf.org >>> >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list- >>> 02 >>> >>> >>> >>> VPN is overkill imho plus i want the ability to engineer traffic >>> paths >>> >>> and for this i need TE >>> >>> >>> >>> Jim Guichard >>> >>> >>> >>> Principal Networking Architect >>> >>> IPG CTO Office >>> >>> Juniper Networks >>> >>> >>> >>> CCIE #2069 >>> >>> >>> >>> Sent from my iphone >>> >>> >>> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >>> >>> wrote: >>> >>> >>> >>> > Hi Jim, >>> >>> > >>> >>> > fully agreed that MPLS should not be absent from the draft, and >>> it >>> >>is >>> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list-03 >>> doesn't >>> >>> > restrict things to IP tunneling. The draft already allows for >>> MPLS >>> >>> > transport between Gateway and AFTR using MPLS VPNs. >>> >>> > >>> >>> > Hence the question: For the use cases you have in mind, couldn't >>> we >>> >>> just >>> >>> > use MPLS VPNs (possibly even point-to-point with just two PEs in >>> a >>> >>> VPN - >>> >>> > Gateway and the AFTR)? Personally I've nothing against >> additional >>> >>> > encapsulations, though so far there's always been a push in the >>> WG >>> >>> (and >>> >>> > also in 3GPP SA2) to keep the number of encapsulations to a >>> minimum >>> >>> > (e.g. L2TPv3 was dropped from the list of encaps, because we >>> could >>> >>do >>> >>> > the very same thing with GRE). >>> >>> > >>> >>> > On multicast: Don't fully follow your thought below. Do you >>> consider >>> >>> > running multicast over the softwire between AFTR and Gateway? >> The >>> >>> > multicast considerations for GI-DS-lite (see >>> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that >>> >>this >>> >>> > would not be the case. >>> >>> > >>> >>> > Thanks, Frank >>> >>> > >>> >>> >> -----Original Message----- >>> >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] >>> >>> >> Sent: Thursday, March 24, 2011 9:43 PM >>> >>> >> >>> >>> >> Hi Frank, >>> >>> >> >>> >>> >> bi-directional tunnels are necessary if you wish for traffic >>> flows >>> >>> to >>> >>> >> take >>> >>> >> the same path in both directions across the network. It is >>> possible >>> >>> to >>> >>> >> use >>> >>> >> point-to-point but this is cumbersome to deploy. >>> >>Point-to-multipoint >>> >>> >> may >>> >>> >> be necessary for multicast. >>> >>> >> >>> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement that >>> >>> should >>> >>> >> not >>> >>> >> be absent from the draft. If an operator has MPLS why restrict >>> them >>> >>> to >>> >>> >> IP >>> >>> >> tunneling? >>> >>> >> >>> >>> >> >>> >>> >>> >>> >>> >>> to kick-start the discussion, could you outline the usage >>> >>scenarios >>> >>> >> that >>> >>> >>> would drive the requirements you mention below? >>> >>> >>> >>> >>> > >>> > >>> >_______________________________________________ >>> >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 jguichard@juniper.net Thu Jul 7 05:28:57 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5419A21F86FE for ; Thu, 7 Jul 2011 05:28:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAYUQf9sOAMP for ; Thu, 7 Jul 2011 05:28:56 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1123421F8530 for ; Thu, 7 Jul 2011 05:28:56 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKThWmhzVBwOX665UHHtLL+l95YTBwBZYr@postini.com; Thu, 07 Jul 2011 05:28:56 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Jul 2011 05:24:26 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 7 Jul 2011 08:24:22 -0400 From: Jim Guichard To: "Frank Brockners (fbrockne)" Date: Thu, 7 Jul 2011 08:24:19 -0400 Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: Acw8oMz2vsNYJ9JKT+e4YcYHq2uBoA== Message-ID: In-Reply-To: <0D212BD466921646B58854FB79092CEC06274EA9@XMB-AMS-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 12:28:57 -0000 Hi Frank, Suggested changes as follows: Section 5: - first bullet currently states "The softwire between the Gateway and the AFTR is created at system startup time and stays up active all time". I would like to allow flexibility to initiate a SW at any point in time. Given this could this bullet be changed to the following: "The softwire between the Gateway and the AFTR MAY be created at system startup time OR dynamically established on-demand" Section 6: - add the following bullet: o IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID is the next MPLS label in the stack. The AFTR may use the CID locally to identify context within a given inbound softwire. =20 On 7/6/11 10:59 AM, "Frank Brockners (fbrockne)" wrote: >Hi Jim, > >... works for me (any additional opinions from others?). > >In order to get a -05 version out quickly, could you detail the change - >i.e. possibly expand the bullet you propose below with some additional >explanation, like e.g. what would be used as CID for "vanilla MPLS"; >propose another row for the table in section 6; etc. > >Once we have this, we could quickly compile a -05. > >Thanks, Frank > >> -----Original Message----- >> From: Jim Guichard [mailto:jguichard@juniper.net] >> Sent: Wednesday, July 06, 2011 6:24 AM >> To: Jim Guichard; Frank Brockners (fbrockne) >> Cc: softwires@ietf.org >> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>=20 >> Hi Frank, >>=20 >> Reviewing version 04 of the draft I still do not see "vanilla" MPLS >> encapsulation given as an option. I would like to suggest adding >> something >> like the following to section 6: >>=20 >> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context within >> SWID >> may be indicated by the next MPLS label in the stack. >>=20 >>=20 >> On 3/28/11 1:17 PM, "Jim Guichard" wrote: >>=20 >> >Hi Frank, >> > >> >What I would like to see is the ability to use TE without VPN's. I do >> not >> >want to be forced to deploy VPN infrastructure in this case. RSVP-TE >> is an >> >important piece of the puzzle as it provides the ability to steer >> traffic >> >based upon policy that I may wish to enforce. I would be happy to >> supply >> >text for the draft but would like to agree on this alias before doing >> so >> >.. >> > >> >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >> >wrote: >> > >> >> >> >>Jim, >> >> >> >>why is VPN "overkill" (kind of delicate wording these days...)? TE >> could >> >>also be combined with MPLS VPNs. >> >> >> >>Would also be interested in other folks' thoughts on the need for >> >>"plain" IP-over-MPLS tunnels. >> >> >> >>Thanks, Frank >> >> >> >>> -----Original Message----- >> >>> From: Jim Guichard [mailto:jguichard@juniper.net] >> >>> Sent: Friday, March 25, 2011 8:03 PM >> >>> To: Frank Brockners (fbrockne) >> >>> Cc: softwires@ietf.org >> >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list- >> 02 >> >>> >> >>> VPN is overkill imho plus i want the ability to engineer traffic >> paths >> >>> and for this i need TE >> >>> >> >>> Jim Guichard >> >>> >> >>> Principal Networking Architect >> >>> IPG CTO Office >> >>> Juniper Networks >> >>> >> >>> CCIE #2069 >> >>> >> >>> Sent from my iphone >> >>> >> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >> >>> wrote: >> >>> >> >>> > Hi Jim, >> >>> > >> >>> > fully agreed that MPLS should not be absent from the draft, and >> it >> >>is >> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list-03 >> doesn't >> >>> > restrict things to IP tunneling. The draft already allows for >> MPLS >> >>> > transport between Gateway and AFTR using MPLS VPNs. >> >>> > >> >>> > Hence the question: For the use cases you have in mind, couldn't >> we >> >>> just >> >>> > use MPLS VPNs (possibly even point-to-point with just two PEs in >> a >> >>> VPN - >> >>> > Gateway and the AFTR)? Personally I've nothing against >additional >> >>> > encapsulations, though so far there's always been a push in the >> WG >> >>> (and >> >>> > also in 3GPP SA2) to keep the number of encapsulations to a >> minimum >> >>> > (e.g. L2TPv3 was dropped from the list of encaps, because we >> could >> >>do >> >>> > the very same thing with GRE). >> >>> > >> >>> > On multicast: Don't fully follow your thought below. Do you >> consider >> >>> > running multicast over the softwire between AFTR and Gateway? >The >> >>> > multicast considerations for GI-DS-lite (see >> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that >> >>this >> >>> > would not be the case. >> >>> > >> >>> > Thanks, Frank >> >>> > >> >>> >> -----Original Message----- >> >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] >> >>> >> Sent: Thursday, March 24, 2011 9:43 PM >> >>> >> >> >>> >> Hi Frank, >> >>> >> >> >>> >> bi-directional tunnels are necessary if you wish for traffic >> flows >> >>> to >> >>> >> take >> >>> >> the same path in both directions across the network. It is >> possible >> >>> to >> >>> >> use >> >>> >> point-to-point but this is cumbersome to deploy. >> >>Point-to-multipoint >> >>> >> may >> >>> >> be necessary for multicast. >> >>> >> >> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement that >> >>> should >> >>> >> not >> >>> >> be absent from the draft. If an operator has MPLS why restrict >> them >> >>> to >> >>> >> IP >> >>> >> tunneling? >> >>> >> >> >>> >> >> >>> >>> >> >>> >>> to kick-start the discussion, could you outline the usage >> >>scenarios >> >>> >> that >> >>> >>> would drive the requirements you mention below? >> >>> >>> >> >>> > >> > >> >_______________________________________________ >> >Softwires mailing list >> >Softwires@ietf.org >> >https://www.ietf.org/mailman/listinfo/softwires > From adurand@juniper.net Thu Jul 7 06:40:59 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D7521F8642 for ; Thu, 7 Jul 2011 06:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro7NrdJKnBRR for ; Thu, 7 Jul 2011 06:40:57 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0209D21F863B for ; Thu, 7 Jul 2011 06:40:56 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKThW3Y0npueKKHfjaVikg+ICJVGnDlUgW@postini.com; Thu, 07 Jul 2011 06:40:57 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 7 Jul 2011 06:38:55 -0700 From: Alain Durand To: "softwires@ietf.org list" Date: Thu, 7 Jul 2011 06:38:53 -0700 Thread-Topic: Preparation for a discussion on 'stateless motivations' at the Quebec meeting Thread-Index: Acw8qzc21mcz60O/Sqa5bom+B/1l5w== Message-ID: <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com><27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> <4E1529C4.4000800@cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Softwires] Preparation for a discussion on 'stateless motivations' at the Quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:40:59 -0000 Following up on the 'stateless' thread from a wg chair perspective. Yong and I are preparing a discussion FOR the Quebec meeting on the so-call= ed stateless solution. There are a number of points in the current draft that need discussion. For example, no logging has been presented as a strong reason to do sateles= s. However, no logging can be achieved with static port allocation on a centralized NAT. On this particular loggin= g point, there are no obvious differences between the 'distributed on CPE' NAT solution and the centralized NAT solution. More generally, it seems that what is described as a 'stateless' solution s= hould be characterized as a 'distributed state' solution. As such, the tradeoff of maintaining the stat= e centrally vs globally needs to be analyzed. =20 Also, it is not clear from this document which set of issues listed in RFC6= 269 are mitigated and which ones are not. In particular, I'd hold that a so-called 'stateless' solution does not chan= ge anything about the recommendations in RFC6302/BCP162 that are derived from RFC6269... We, chairs, would like to prepare a 'organized' discussion around these poi= nts (and others). We need a small number of volunteers to help frame this discussion. Please contact me and Yong direct= ly if you want to help. This is an important topic, and we intend to make sure there is ample time = for discussion in Quebec. - Alain. From jguichard@juniper.net Thu Jul 7 06:56:28 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD821F8676 for ; Thu, 7 Jul 2011 06:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpAFQIPAMhtU for ; Thu, 7 Jul 2011 06:56:27 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id A6E9C21F8617 for ; Thu, 7 Jul 2011 06:56:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKThW7CTjH4pqQNVuMbQooOSaGjp6PCERG@postini.com; Thu, 07 Jul 2011 06:56:27 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 7 Jul 2011 06:54:28 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 7 Jul 2011 09:54:27 -0400 From: Jim Guichard To: Paco Cortes Date: Thu, 7 Jul 2011 09:54:25 -0400 Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: Acw8rWKLfxh+k1BMS3OGw6tu/8Mr+A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 13:56:28 -0000 Yes, I agree that this change makes sense and provides more flexibility .. thanks On 7/7/11 9:48 AM, "Paco Cortes" wrote: >Thanks Jim, now I get it. >You were aiming at (outer label=3D SWID; inner label =3D CID), and I >misunderstood it as (outer label =3D SWID, inner label =3D something_new; >IP @ =3D CID). >Speaking about "vanilla MPLS" I was actually expecting (only label =3D >SWID; IP @ =3D CID) > >It sounds sensible to me. >But do you really want to restrict the vanilla MPLS case to (outer >label =3D SWID, inner label =3D CID)? In such case, the user IP@ is pure >overhead. > >Wouldn't it be better to cover both cases in one go? This could be >done with a change like: > >- SWID is the top MPLS label. CID might be the next MPLS >label in the stack, if present, or the AD's IP address. > >But don't take this email as an opposition to your last proposal to >Frank. If nobody is interested on (single label=3DSWID, IP@=3DCID), then I >will not be the one pushing for it. > >br, > Paco > > > > > >2011/7/7 Jim Guichard : >> Hi Paco, >> >> Comments inline .. >> >> On 7/7/11 3:39 AM, "Paco Cortes" wrote: >> >>>Hi Jim, >>> >>>can you clarify with the upper case part of your proposal? >>> >>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT WITHIN >>>swid >>>MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK. >>> >>>You are speaking about a fully different case than the "MPLS VPN" case >>>currently in the draft, where the VPN label (i.e. the inner MPLS >>>label) is the SWID. >>>To me it sounds like a very significant change to gi-ds-lite, as you >>>seem to be proposing that traffic inside a softwire can be further >>>"split" into contexts with some meaning (differentiated handling?) by >>>the AFTR. >> >> Jim> yes, exactly this. In this case the SWID is the top label and the >> next label in the stack is the CID. >> >>> >>>Regarding the overall discussion in this thread (sorry I didn't answer >>>earlier), I disagree on the MPLS VPN case to be an overkill. In many >>>cases, the one-label overhead in part of the path is fully justified >>>by the gained operational simplicity (given by relaying on MP-BGP and >>>possibly CE-PE protocol for "softwire" setup and control signalling). >>>Also, as already mentioned by Yiu, it enables a very simple >>>implementation of overlapping IP addresses. Although this could also >>>be possible with your "vanilla MPLS" proposal, it would require some >>>kind of additional (proprietary?) implementation both in Gateway and >>>AFTR. >> >> Jim> let me clarify .. I completely agree that VPN should be included. >>My >> overkill comment was more to do with the fact that in some situations it >> is not necessary to deploy the full MPLS VPN machinery. >>> >>>This said, I do see the point on adding "vanilla MPLS" as possible >>>embodiment to the draft. There may be simple scenarios where it is >>>fully sufficient. >>>Maybe adding a bullet to section 6 like: >>> >>> o IPv4/IPv6-in-MPLS: SWID is the MPLS label. >>> >>>Would this be ok for you? >> >> Jim> I would like to see SWID =3D top label, CID =3D next label in stack >> noting that the SWID label is not PHP. >>> >>>br, >>> Paco >>> >>> >>>2011/7/6 Frank Brockners (fbrockne) : >>>> Hi Jim, >>>> >>>> ... works for me (any additional opinions from others?). >>>> >>>> In order to get a -05 version out quickly, could you detail the >>>>change - >>>> i.e. possibly expand the bullet you propose below with some additional >>>> explanation, like e.g. what would be used as CID for "vanilla MPLS"; >>>> propose another row for the table in section 6; etc. >>>> >>>> Once we have this, we could quickly compile a -05. >>>> >>>> Thanks, Frank >>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard [mailto:jguichard@juniper.net] >>>>> Sent: Wednesday, July 06, 2011 6:24 AM >>>>> To: Jim Guichard; Frank Brockners (fbrockne) >>>>> Cc: softwires@ietf.org >>>>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>>>> >>>>> Hi Frank, >>>>> >>>>> Reviewing version 04 of the draft I still do not see "vanilla" MPLS >>>>> encapsulation given as an option. I would like to suggest adding >>>>> something >>>>> like the following to section 6: >>>>> >>>>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context within >>>>> SWID >>>>> may be indicated by the next MPLS label in the stack. >>>>> >>>>> >>>>> On 3/28/11 1:17 PM, "Jim Guichard" wrote: >>>>> >>>>> >Hi Frank, >>>>> > >>>>> >What I would like to see is the ability to use TE without VPN's. I >>>>>do >>>>> not >>>>> >want to be forced to deploy VPN infrastructure in this case. RSVP-TE >>>>> is an >>>>> >important piece of the puzzle as it provides the ability to steer >>>>> traffic >>>>> >based upon policy that I may wish to enforce. I would be happy to >>>>> supply >>>>> >text for the draft but would like to agree on this alias before >>>>>doing >>>>> so >>>>> >.. >>>>> > >>>>> >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >>>>> >>>>> >wrote: >>>>> > >>>>> >> >>>>> >>Jim, >>>>> >> >>>>> >>why is VPN "overkill" (kind of delicate wording these days...)? TE >>>>> could >>>>> >>also be combined with MPLS VPNs. >>>>> >> >>>>> >>Would also be interested in other folks' thoughts on the need for >>>>> >>"plain" IP-over-MPLS tunnels. >>>>> >> >>>>> >>Thanks, Frank >>>>> >> >>>>> >>> -----Original Message----- >>>>> >>> From: Jim Guichard [mailto:jguichard@juniper.net] >>>>> >>> Sent: Friday, March 25, 2011 8:03 PM >>>>> >>> To: Frank Brockners (fbrockne) >>>>> >>> Cc: softwires@ietf.org >>>>> >>> Subject: Re: [Softwires] >>>>>draft-ietf-softwire-gateway-init-ds-list- >>>>> 02 >>>>> >>> >>>>> >>> VPN is overkill imho plus i want the ability to engineer traffic >>>>> paths >>>>> >>> and for this i need TE >>>>> >>> >>>>> >>> Jim Guichard >>>>> >>> >>>>> >>> Principal Networking Architect >>>>> >>> IPG CTO Office >>>>> >>> Juniper Networks >>>>> >>> >>>>> >>> CCIE #2069 >>>>> >>> >>>>> >>> Sent from my iphone >>>>> >>> >>>>> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >>>>> >>> wrote: >>>>> >>> >>>>> >>> > Hi Jim, >>>>> >>> > >>>>> >>> > fully agreed that MPLS should not be absent from the draft, and >>>>> it >>>>> >>is >>>>> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list-03 >>>>> doesn't >>>>> >>> > restrict things to IP tunneling. The draft already allows for >>>>> MPLS >>>>> >>> > transport between Gateway and AFTR using MPLS VPNs. >>>>> >>> > >>>>> >>> > Hence the question: For the use cases you have in mind, >>>>>couldn't >>>>> we >>>>> >>> just >>>>> >>> > use MPLS VPNs (possibly even point-to-point with just two PEs >>>>>in >>>>> a >>>>> >>> VPN - >>>>> >>> > Gateway and the AFTR)? Personally I've nothing against >>>> additional >>>>> >>> > encapsulations, though so far there's always been a push in the >>>>> WG >>>>> >>> (and >>>>> >>> > also in 3GPP SA2) to keep the number of encapsulations to a >>>>> minimum >>>>> >>> > (e.g. L2TPv3 was dropped from the list of encaps, because we >>>>> could >>>>> >>do >>>>> >>> > the very same thing with GRE). >>>>> >>> > >>>>> >>> > On multicast: Don't fully follow your thought below. Do you >>>>> consider >>>>> >>> > running multicast over the softwire between AFTR and Gateway? >>>> The >>>>> >>> > multicast considerations for GI-DS-lite (see >>>>> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume >>>>>that >>>>> >>this >>>>> >>> > would not be the case. >>>>> >>> > >>>>> >>> > Thanks, Frank >>>>> >>> > >>>>> >>> >> -----Original Message----- >>>>> >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] >>>>> >>> >> Sent: Thursday, March 24, 2011 9:43 PM >>>>> >>> >> >>>>> >>> >> Hi Frank, >>>>> >>> >> >>>>> >>> >> bi-directional tunnels are necessary if you wish for traffic >>>>> flows >>>>> >>> to >>>>> >>> >> take >>>>> >>> >> the same path in both directions across the network. It is >>>>> possible >>>>> >>> to >>>>> >>> >> use >>>>> >>> >> point-to-point but this is cumbersome to deploy. >>>>> >>Point-to-multipoint >>>>> >>> >> may >>>>> >>> >> be necessary for multicast. >>>>> >>> >> >>>>> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement that >>>>> >>> should >>>>> >>> >> not >>>>> >>> >> be absent from the draft. If an operator has MPLS why restrict >>>>> them >>>>> >>> to >>>>> >>> >> IP >>>>> >>> >> tunneling? >>>>> >>> >> >>>>> >>> >> >>>>> >>> >>> >>>>> >>> >>> to kick-start the discussion, could you outline the usage >>>>> >>scenarios >>>>> >>> >> that >>>>> >>> >>> would drive the requirements you mention below? >>>>> >>> >>> >>>>> >>> > >>>>> > >>>>> >_______________________________________________ >>>>> >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 pacosaddress@googlemail.com Thu Jul 7 00:39:58 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0120C21F8867 for ; Thu, 7 Jul 2011 00:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF0sDKVtPiRS for ; Thu, 7 Jul 2011 00:39:57 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0462321F8763 for ; Thu, 7 Jul 2011 00:39:56 -0700 (PDT) Received: by iye7 with SMTP id 7so756098iye.31 for ; Thu, 07 Jul 2011 00:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hdYV21zO04gKTH+mGgLgrhpivmg44zibQWD5keKWIkE=; b=IenGId1Q1MI/DsC0jpoKy4SHya0H9eSbcrCoW2cXhV7yMOyGL4+0faHiPEGmEgSXnZ 01dZDj8TvKy8txhJNKTeyb/RJ4H+oQeQh+6o3q3/1QhUZHp9baWqUEZOQiW/FmA3bUM0 U5JHZQDvaIMTPU1C8IITdbbQgWTTwBJbDhPTM= MIME-Version: 1.0 Received: by 10.231.39.74 with SMTP id f10mr451852ibe.199.1310024396127; Thu, 07 Jul 2011 00:39:56 -0700 (PDT) Received: by 10.231.43.72 with HTTP; Thu, 7 Jul 2011 00:39:55 -0700 (PDT) In-Reply-To: <0D212BD466921646B58854FB79092CEC06274EA9@XMB-AMS-106.cisco.com> References: <0D212BD466921646B58854FB79092CEC06274EA9@XMB-AMS-106.cisco.com> Date: Thu, 7 Jul 2011 09:39:55 +0200 Message-ID: From: Paco Cortes To: Jim Guichard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Jul 2011 07:04:06 -0700 Cc: softwires@ietf.org Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 07:39:58 -0000 Hi Jim, can you clarify with the upper case part of your proposal? o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT WITHIN swid MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK. You are speaking about a fully different case than the "MPLS VPN" case currently in the draft, where the VPN label (i.e. the inner MPLS label) is the SWID. To me it sounds like a very significant change to gi-ds-lite, as you seem to be proposing that traffic inside a softwire can be further "split" into contexts with some meaning (differentiated handling?) by the AFTR. Regarding the overall discussion in this thread (sorry I didn't answer earlier), I disagree on the MPLS VPN case to be an overkill. In many cases, the one-label overhead in part of the path is fully justified by the gained operational simplicity (given by relaying on MP-BGP and possibly CE-PE protocol for "softwire" setup and control signalling). Also, as already mentioned by Yiu, it enables a very simple implementation of overlapping IP addresses. Although this could also be possible with your "vanilla MPLS" proposal, it would require some kind of additional (proprietary?) implementation both in Gateway and AFTR. This said, I do see the point on adding "vanilla MPLS" as possible embodiment to the draft. There may be simple scenarios where it is fully sufficient. Maybe adding a bullet to section 6 like: o IPv4/IPv6-in-MPLS: SWID is the MPLS label. Would this be ok for you? br, Paco 2011/7/6 Frank Brockners (fbrockne) : > Hi Jim, > > ... works for me (any additional opinions from others?). > > In order to get a -05 version out quickly, could you detail the change - > i.e. possibly expand the bullet you propose below with some additional > explanation, like e.g. what would be used as CID for "vanilla MPLS"; > propose another row for the table in section 6; etc. > > Once we have this, we could quickly compile a -05. > > Thanks, Frank > >> -----Original Message----- >> From: Jim Guichard [mailto:jguichard@juniper.net] >> Sent: Wednesday, July 06, 2011 6:24 AM >> To: Jim Guichard; Frank Brockners (fbrockne) >> Cc: softwires@ietf.org >> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >> >> Hi Frank, >> >> Reviewing version 04 of the draft I still do not see "vanilla" MPLS >> encapsulation given as an option. I would like to suggest adding >> something >> like the following to section 6: >> >> =A0 =A0o =A0IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context wit= hin >> SWID >> may be indicated by the next MPLS label in the stack. >> >> >> On 3/28/11 1:17 PM, "Jim Guichard" wrote: >> >> >Hi Frank, >> > >> >What I would like to see is the ability to use TE without VPN's. I do >> not >> >want to be forced to deploy VPN infrastructure in this case. RSVP-TE >> is an >> >important piece of the puzzle as it provides the ability to steer >> traffic >> >based upon policy that I may wish to enforce. I would be happy to >> supply >> >text for the draft but would like to agree on this alias before doing >> so >> >.. >> > >> >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >> >wrote: >> > >> >> >> >>Jim, >> >> >> >>why is VPN "overkill" (kind of delicate wording these days...)? TE >> could >> >>also be combined with MPLS VPNs. >> >> >> >>Would also be interested in other folks' thoughts on the need for >> >>"plain" IP-over-MPLS tunnels. >> >> >> >>Thanks, Frank >> >> >> >>> -----Original Message----- >> >>> From: Jim Guichard [mailto:jguichard@juniper.net] >> >>> Sent: Friday, March 25, 2011 8:03 PM >> >>> To: Frank Brockners (fbrockne) >> >>> Cc: softwires@ietf.org >> >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list- >> 02 >> >>> >> >>> VPN is overkill imho plus i want the ability to engineer traffic >> paths >> >>> and for this i need TE >> >>> >> >>> Jim Guichard >> >>> >> >>> Principal Networking Architect >> >>> IPG CTO Office >> >>> Juniper Networks >> >>> >> >>> CCIE #2069 >> >>> >> >>> Sent from my iphone >> >>> >> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >> >>> wrote: >> >>> >> >>> > Hi Jim, >> >>> > >> >>> > fully agreed that MPLS should not be absent from the draft, and >> it >> >>is >> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list-03 >> doesn't >> >>> > restrict things to IP tunneling. The draft already allows for >> MPLS >> >>> > transport between Gateway and AFTR using MPLS VPNs. >> >>> > >> >>> > Hence the question: For the use cases you have in mind, couldn't >> we >> >>> just >> >>> > use MPLS VPNs (possibly even point-to-point with just two PEs in >> a >> >>> VPN - >> >>> > Gateway and the AFTR)? Personally I've nothing against > additional >> >>> > encapsulations, though so far there's always been a push in the >> WG >> >>> (and >> >>> > also in 3GPP SA2) to keep the number of encapsulations to a >> minimum >> >>> > (e.g. L2TPv3 was dropped from the list of encaps, because we >> could >> >>do >> >>> > the very same thing with GRE). >> >>> > >> >>> > On multicast: Don't fully follow your thought below. Do you >> consider >> >>> > running multicast over the softwire between AFTR and Gateway? > The >> >>> > multicast considerations for GI-DS-lite (see >> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that >> >>this >> >>> > would not be the case. >> >>> > >> >>> > Thanks, Frank >> >>> > >> >>> >> -----Original Message----- >> >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] >> >>> >> Sent: Thursday, March 24, 2011 9:43 PM >> >>> >> >> >>> >> Hi Frank, >> >>> >> >> >>> >> bi-directional tunnels are necessary if you wish for traffic >> flows >> >>> to >> >>> >> take >> >>> >> the same path in both directions across the network. It is >> possible >> >>> to >> >>> >> use >> >>> >> point-to-point but this is cumbersome to deploy. >> >>Point-to-multipoint >> >>> >> may >> >>> >> be necessary for multicast. >> >>> >> >> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement that >> >>> should >> >>> >> not >> >>> >> be absent from the draft. If an operator has MPLS why restrict >> them >> >>> to >> >>> >> IP >> >>> >> tunneling? >> >>> >> >> >>> >> >> >>> >>> >> >>> >>> to kick-start the discussion, could you outline the usage >> >>scenarios >> >>> >> that >> >>> >>> would drive the requirements you mention below? >> >>> >>> >> >>> > >> > >> >_______________________________________________ >> >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 pacosaddress@googlemail.com Thu Jul 7 06:48:45 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E3521F85F5 for ; Thu, 7 Jul 2011 06:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXxSIxpFZ8oN for ; Thu, 7 Jul 2011 06:48:44 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFBA821F85E5 for ; Thu, 7 Jul 2011 06:48:44 -0700 (PDT) Received: by iye7 with SMTP id 7so1075895iye.31 for ; Thu, 07 Jul 2011 06:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yr0l/Oe1EmmGBkMdMwI8p0a7jJDjdhZsjy1Zo/qK4iM=; b=WaIYb4/sjQZlyGsga2dvhdKdO6O2qialk0d4FeTCqRXWG0B/hEod251cnqs0KDziMp vbLaGeC8Y9QfHinq1110QOd4MUUVkNyw1bxagccZI14FBJcdYibwgjItU77jX5/Ba48g s+HxdHlHr0s1bwQdPyf8gDMMniSd/oTmnKa4M= MIME-Version: 1.0 Received: by 10.231.28.72 with SMTP id l8mr708814ibc.194.1310046524216; Thu, 07 Jul 2011 06:48:44 -0700 (PDT) Received: by 10.231.180.79 with HTTP; Thu, 7 Jul 2011 06:48:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Jul 2011 15:48:44 +0200 Message-ID: From: Paco Cortes To: Jim Guichard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Jul 2011 07:04:06 -0700 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 13:48:45 -0000 Thanks Jim, now I get it. You were aiming at (outer label=3D SWID; inner label =3D CID), and I misunderstood it as (outer label =3D SWID, inner label =3D something_new; IP @ =3D CID). Speaking about "vanilla MPLS" I was actually expecting (only label =3D SWID; IP @ =3D CID) It sounds sensible to me. But do you really want to restrict the vanilla MPLS case to (outer label =3D SWID, inner label =3D CID)? In such case, the user IP@ is pure overhead. Wouldn't it be better to cover both cases in one go? This could be done with a change like: - SWID is the top MPLS label. CID might be the next MPLS label in the stack, if present, or the AD's IP address. But don't take this email as an opposition to your last proposal to Frank. If nobody is interested on (single label=3DSWID, IP@=3DCID), then I will not be the one pushing for it. br, Paco 2011/7/7 Jim Guichard : > Hi Paco, > > Comments inline .. > > On 7/7/11 3:39 AM, "Paco Cortes" wrote: > >>Hi Jim, >> >>can you clarify with the upper case part of your proposal? >> >> =A0o =A0IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT WITHIN = swid >>MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK. >> >>You are speaking about a fully different case than the "MPLS VPN" case >>currently in the draft, where the VPN label (i.e. the inner MPLS >>label) is the SWID. >>To me it sounds like a very significant change to gi-ds-lite, as you >>seem to be proposing that traffic inside a softwire can be further >>"split" into contexts with some meaning (differentiated handling?) by >>the AFTR. > > Jim> yes, exactly this. In this case the SWID is the top label and the > next label in the stack is the CID. > >> >>Regarding the overall discussion in this thread (sorry I didn't answer >>earlier), I disagree on the MPLS VPN case to be an overkill. In many >>cases, the one-label overhead in part of the path is fully justified >>by the gained operational simplicity (given by relaying on MP-BGP and >>possibly CE-PE protocol for "softwire" setup and control signalling). >>Also, as already mentioned by Yiu, it enables a very simple >>implementation of overlapping IP addresses. Although this could also >>be possible with your "vanilla MPLS" proposal, it would require some >>kind of additional (proprietary?) implementation both in Gateway and >>AFTR. > > Jim> let me clarify .. I completely agree that VPN should be included. My > overkill comment was more to do with the fact that in some situations it > is not necessary to deploy the full MPLS VPN machinery. >> >>This said, I do see the point on adding "vanilla MPLS" as possible >>embodiment to the draft. There may be simple scenarios where it is >>fully sufficient. >>Maybe adding a bullet to section 6 like: >> >> =A0o =A0IPv4/IPv6-in-MPLS: SWID is the MPLS label. >> >>Would this be ok for you? > > Jim> I would like to see SWID =3D top label, CID =3D next label in stack > noting that the SWID label is not PHP. >> >>br, >> =A0Paco >> >> >>2011/7/6 Frank Brockners (fbrockne) : >>> Hi Jim, >>> >>> ... works for me (any additional opinions from others?). >>> >>> In order to get a -05 version out quickly, could you detail the change = - >>> i.e. possibly expand the bullet you propose below with some additional >>> explanation, like e.g. what would be used as CID for "vanilla MPLS"; >>> propose another row for the table in section 6; etc. >>> >>> Once we have this, we could quickly compile a -05. >>> >>> Thanks, Frank >>> >>>> -----Original Message----- >>>> From: Jim Guichard [mailto:jguichard@juniper.net] >>>> Sent: Wednesday, July 06, 2011 6:24 AM >>>> To: Jim Guichard; Frank Brockners (fbrockne) >>>> Cc: softwires@ietf.org >>>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>>> >>>> Hi Frank, >>>> >>>> Reviewing version 04 of the draft I still do not see "vanilla" MPLS >>>> encapsulation given as an option. I would like to suggest adding >>>> something >>>> like the following to section 6: >>>> >>>> =A0 =A0o =A0IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context w= ithin >>>> SWID >>>> may be indicated by the next MPLS label in the stack. >>>> >>>> >>>> On 3/28/11 1:17 PM, "Jim Guichard" wrote: >>>> >>>> >Hi Frank, >>>> > >>>> >What I would like to see is the ability to use TE without VPN's. I do >>>> not >>>> >want to be forced to deploy VPN infrastructure in this case. RSVP-TE >>>> is an >>>> >important piece of the puzzle as it provides the ability to steer >>>> traffic >>>> >based upon policy that I may wish to enforce. I would be happy to >>>> supply >>>> >text for the draft but would like to agree on this alias before doing >>>> so >>>> >.. >>>> > >>>> >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >>>> >wrote: >>>> > >>>> >> >>>> >>Jim, >>>> >> >>>> >>why is VPN "overkill" (kind of delicate wording these days...)? TE >>>> could >>>> >>also be combined with MPLS VPNs. >>>> >> >>>> >>Would also be interested in other folks' thoughts on the need for >>>> >>"plain" IP-over-MPLS tunnels. >>>> >> >>>> >>Thanks, Frank >>>> >> >>>> >>> -----Original Message----- >>>> >>> From: Jim Guichard [mailto:jguichard@juniper.net] >>>> >>> Sent: Friday, March 25, 2011 8:03 PM >>>> >>> To: Frank Brockners (fbrockne) >>>> >>> Cc: softwires@ietf.org >>>> >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list- >>>> 02 >>>> >>> >>>> >>> VPN is overkill imho plus i want the ability to engineer traffic >>>> paths >>>> >>> and for this i need TE >>>> >>> >>>> >>> Jim Guichard >>>> >>> >>>> >>> Principal Networking Architect >>>> >>> IPG CTO Office >>>> >>> Juniper Networks >>>> >>> >>>> >>> CCIE #2069 >>>> >>> >>>> >>> Sent from my iphone >>>> >>> >>>> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >>>> >>> wrote: >>>> >>> >>>> >>> > Hi Jim, >>>> >>> > >>>> >>> > fully agreed that MPLS should not be absent from the draft, and >>>> it >>>> >>is >>>> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list-03 >>>> doesn't >>>> >>> > restrict things to IP tunneling. The draft already allows for >>>> MPLS >>>> >>> > transport between Gateway and AFTR using MPLS VPNs. >>>> >>> > >>>> >>> > Hence the question: For the use cases you have in mind, couldn't >>>> we >>>> >>> just >>>> >>> > use MPLS VPNs (possibly even point-to-point with just two PEs in >>>> a >>>> >>> VPN - >>>> >>> > Gateway and the AFTR)? Personally I've nothing against >>> additional >>>> >>> > encapsulations, though so far there's always been a push in the >>>> WG >>>> >>> (and >>>> >>> > also in 3GPP SA2) to keep the number of encapsulations to a >>>> minimum >>>> >>> > (e.g. L2TPv3 was dropped from the list of encaps, because we >>>> could >>>> >>do >>>> >>> > the very same thing with GRE). >>>> >>> > >>>> >>> > On multicast: Don't fully follow your thought below. Do you >>>> consider >>>> >>> > running multicast over the softwire between AFTR and Gateway? >>> The >>>> >>> > multicast considerations for GI-DS-lite (see >>>> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume that >>>> >>this >>>> >>> > would not be the case. >>>> >>> > >>>> >>> > Thanks, Frank >>>> >>> > >>>> >>> >> -----Original Message----- >>>> >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] >>>> >>> >> Sent: Thursday, March 24, 2011 9:43 PM >>>> >>> >> >>>> >>> >> Hi Frank, >>>> >>> >> >>>> >>> >> bi-directional tunnels are necessary if you wish for traffic >>>> flows >>>> >>> to >>>> >>> >> take >>>> >>> >> the same path in both directions across the network. It is >>>> possible >>>> >>> to >>>> >>> >> use >>>> >>> >> point-to-point but this is cumbersome to deploy. >>>> >>Point-to-multipoint >>>> >>> >> may >>>> >>> >> be necessary for multicast. >>>> >>> >> >>>> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement that >>>> >>> should >>>> >>> >> not >>>> >>> >> be absent from the draft. If an operator has MPLS why restrict >>>> them >>>> >>> to >>>> >>> >> IP >>>> >>> >> tunneling? >>>> >>> >> >>>> >>> >> >>>> >>> >>> >>>> >>> >>> to kick-start the discussion, could you outline the usage >>>> >>scenarios >>>> >>> >> that >>>> >>> >>> would drive the requirements you mention below? >>>> >>> >>> >>>> >>> > >>>> > >>>> >_______________________________________________ >>>> >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 mark@townsley.net Thu Jul 7 10:17:02 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0716E11E8081 for ; Thu, 7 Jul 2011 10:17:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Lqp6yw8pD72 for ; Thu, 7 Jul 2011 10:17:00 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7873C11E8080 for ; Thu, 7 Jul 2011 10:17:00 -0700 (PDT) Received: by wwe5 with SMTP id 5so797151wwe.13 for ; Thu, 07 Jul 2011 10:16:59 -0700 (PDT) Received: by 10.216.63.68 with SMTP id z46mr6658202wec.82.1310059019436; Thu, 07 Jul 2011 10:16:59 -0700 (PDT) Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id g48sm2150636wee.37.2011.07.07.10.16.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jul 2011 10:16:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5-1039322903 From: Mark Townsley In-Reply-To: <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> Date: Thu, 7 Jul 2011 19:16:44 +0200 Message-Id: <70C5EDAE-4297-47AB-B749-1B749450975E@townsley.net> References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com><27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> <4E1529C4.4000800@cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Preparation for a discussion on 'stateless motivations' at the Quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 17:17:02 -0000 --Apple-Mail-5-1039322903 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Let's have discussion on the list instead, k? On Jul 7, 2011, at 3:38 PM, Alain Durand wrote: > Following up on the 'stateless' thread from a wg chair perspective. The thread was nothing but an announcement that the draft was present, = and a bunch of people saying that they support it. >=20 > Yong and I are preparing a discussion FOR the Quebec meeting on the = so-called stateless solution. >=20 > There are a number of points in the current draft that need = discussion. Sure, based on your review of the document that's fine. But, not "the = thread from a WG chair perspective" as stated above. That's ridiculous. > For example, no logging has been presented as a strong reason to do = sateless. However, no logging can be achieved > with static port allocation on a centralized NAT. On this particular = logging point, there are no obvious differences between the > 'distributed on CPE' NAT solution and the centralized NAT solution. As you point out, the "no logging" part is really a function of the use = of a static mapping to a range of ports. Any centralized NAPT function = can use static mapping. When you use static mapping, then you get all = the pros and cons that go along with it. > More generally, it seems that what is described as a 'stateless' = solution should be characterized as a > 'distributed state' solution. As such, the tradeoff of maintaining the = state centrally vs globally > needs to be analyzed. "stateless operation" if you prefer. The point is that within the ISP = network, there is no per-flow state that resides on any single endpoint = running the protocol in question. So, config can be static, and BRs can = be reached via anycast. That's the heart of a stateless solution. Just = like 6rd, if you will.=20 > Also, it is not clear from this document which set of issues listed in = RFC6269 are mitigated and which ones are not. > In particular, I'd hold that a so-called 'stateless' solution does not = change anything about the recommendations in RFC6302/BCP162 > that are derived from RFC6269... RFC6302/BCP162 is a Standards track document that makes an informational = reference to an Informational RFC 6269, so I would hardly call that = "derived from," else we would likely have a downref issue that would = have needed to be called out during IETF Last call for RFC 6302.=20 In any case, RFC 6269 has some very good information. In fact, it very = correctly states: Whether we're talking about DS-Lite, A+P, NAT64, or CGN isn't especially important -- it's the view from the outside that matters, and given that, most of the issues identified below apply regardless of the specific address sharing scenario in question. So, since most of the issues don't matter between stateful vs. stateless = (A+P), we can dismiss most of this document pretty quickly for this = comparison. Here are a couple of issues that do seem to matter though: Section 13.4 Port Randomization - here the culprit is use of a static = mapping again, and essentially the other side of the coin for "no = logging". Put simply, if you want to reduce your logging with a = predictable port, you also make your port more guessable by an attacker. = .=20 Section 18: Single Points of Failure - here, stateless wins pretty much = hands down as it is not introducing any new single points of failure. Perhaps there are a few more, but "most" should be insignificant by the = own document's admission. > We, chairs, would like to prepare a 'organized' discussion around = these points (and others). We need a small number of > volunteers to help frame this discussion. Please contact me and Yong = directly if you want to help. > This is an important topic, and we intend to make sure there is ample = time for discussion in Quebec. Why don't we just discuss it on the list and have a consensus call = instead? If we had a thread of 200 messages as we did for moving 6to4 to = historic, OK maybe we need to have a big coordinated discussion. But, = I'm not seeing anything on the thread here that would suggest that we = need to spend a lot of time preparing some big discussion among a group = of people you and Yong select.=20 - Mark >=20 > - Alain. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-5-1039322903 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Following up on the 'stateless' thread from a wg = chair perspective.

The thread was = nothing but an announcement that the draft was present, and a bunch of = people saying that they support it.


Yong and I are preparing a discussion FOR the = Quebec meeting on the so-called stateless solution.

There are a = number of points in the current draft that need = discussion.

Sure, based on your review = of the document that's fine. But, not "the thread from a WG chair = perspective" as stated above. That's = ridiculous.

For example, no = logging has been presented as a strong reason to do sateless. However, = no logging can be achieved
with static port allocation on a = centralized NAT. On this particular logging point, there are no obvious = differences between the
'distributed on CPE' NAT solution and the = centralized NAT solution.

As = you point out, the "no logging" part is really a function of the use of = a static mapping to a range of ports. Any centralized NAPT function = can use static mapping. When you use static mapping, then you get all = the pros and cons that go along with it.

More generally, it seems that what is described as a = 'stateless' solution should be characterized as a
'distributed state' = solution. As such, the tradeoff of maintaining the state centrally vs = globally
needs to be = analyzed.

"stateless = operation" if you prefer. The point is that within the ISP network, = there is no per-flow state that resides on any single endpoint running = the protocol in question.  So, config can be static, and BRs can be = reached via anycast. That's the heart of a stateless solution. Just = like 6rd, if you will. 

Also,= it is not clear from this document which set of issues listed in = RFC6269 are mitigated and which ones are not.
In particular, I'd hold = that a so-called 'stateless' solution does not change anything about the = recommendations in RFC6302/BCP162
that are derived from = RFC6269...

RFC6302/BCP162 is a = Standards track document that makes an informational reference to an = Informational RFC 6269, so I would hardly call that "derived from," else = we would likely have a downref issue that would have needed to be called = out during IETF Last call for RFC = 6302. 

In any case, RFC 6269 has some very = good information. In fact, it very correctly = states:

Whether we're talking about DS-Lite, A+P, NAT64, or CGN isn't especially important -- it's the view from the outside that matters, and given that, most of the issues identified below apply regardless of the specific address sharing scenario in = question.

So, since = most of the issues don't matter between stateful vs. stateless (A+P), we = can dismiss most of this document pretty quickly for this comparison. = Here are a couple of issues that do seem to matter = though:

Section 13.4 Port Randomization - here = the culprit is use of a static mapping again, and essentially the other = side of the coin for "no logging". Put simply, if you want to reduce = your logging with a predictable port, you also make your port more = guessable by an attacker. . 

Section 18: = Single Points of Failure - here, stateless wins pretty much hands down = as it is not introducing any new single points of = failure.

Perhaps there are a few more, but = "most" should be insignificant by the own document's = admission.

We, = chairs, would like to prepare a 'organized' discussion around these = points (and others). We need a small number of
volunteers to help = frame this discussion. Please contact me and Yong directly if you want = to help.
This is an important topic, and we intend to make sure there = is ample time for discussion in = Quebec.

Why don't we just = discuss it on the list and have a consensus call = instead?

If we had a thread of 200 messages as = we did for moving 6to4 to historic, OK maybe we need to have a big = coordinated discussion. But, I'm not seeing anything on the thread here = that would suggest that we need to spend a lot of time preparing some = big discussion among a group of people you and Yong = select. 

- Mark


  - = Alain.

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

= = --Apple-Mail-5-1039322903-- From behcetsarikaya@yahoo.com Thu Jul 7 10:57:15 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676431F0C72 for ; Thu, 7 Jul 2011 10:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzZFBPAhhjFx for ; Thu, 7 Jul 2011 10:57:14 -0700 (PDT) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id B0FB21F0C6F for ; Thu, 7 Jul 2011 10:57:14 -0700 (PDT) Received: from [98.139.91.61] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jul 2011 17:57:12 -0000 Received: from [98.139.91.4] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jul 2011 17:57:11 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 07 Jul 2011 17:57:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 980876.2193.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 64227 invoked by uid 60001); 7 Jul 2011 17:57:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1310061431; bh=kEJS2YFqI294al3Bxh/l2FNpG9dBE2QDoogRQ4r7xRs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=z54mszik8omMa+ozZdAaJtBATfDWEWEYafdp9SO/pdd5Fq0R1oKD73KfE+9qo7spYEgxTOgSSM5rx6Qk/gHgppFWZQEKrY3ZN+o8GXkletPOBgSiDb9ovsQ8QfclzmpNASZKJC4J8wYvHfjmB9iWbPJeKyfJwaRuLFItmWJyYu4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=5rytbo2Orwoly3hI+Rx4pqZQXx5Zk8Q6RrhXQNlaVCylAy3HsL0lmPE5JCZuT+8n+SD/JJpNIMC7jNW8uyLX4rEp0VYNw7zja4Lrl7p/+vr3arhkb7epkvB3gi8NRqboGUoyedGQmTVsIFGcIzHfBgLUgLOpO0nH93gpnB+wyvo=; X-YMail-OSG: 1_ghBF0VM1kLoVSF1jN_Ti8aFJ1DMeP6q0GtdNvQ6mMypyp W_HnUupmKCO1s6_Nu_E_0BN72zhDKsesZHbrBnuWHxjbqPWk3bIYfRqTh7m4 LQ79HBaXWzxnVj_K.y5eZjxrWoqjfM4r.K28NxZYSQQv7c4Bpa3gojq9pysq 98i2Oz8K8OcLB711yWJd8tnJ0HBvg58.Nt6.EmWFLQUwHPVYZRATpiBm2p7e b8P8XMA_mxBlmA7aXkfKW38Z7XUqPrFm4wTU4dNJ_fLkVH_loHtUAiLMOtTU UALipBXUrGdGRe9GaQeruX1xWy_9F8LV0K8WtZjeR7qrgyvjNcStrlRuLSji XS08p3JG_jGe47exJdvSwLX165OfIFT9vOOdNvEu2GQ11ZA7RLiLiyMBeUDT hAXgpYhtFErfggw-- Received: from [50.58.7.243] by web111409.mail.gq1.yahoo.com via HTTP; Thu, 07 Jul 2011 10:57:11 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com><27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> <4E1529C4.4000800@cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> <70C5EDAE-4297-47AB-B749-1B749450975E@townsley.net> Message-ID: <1310061431.61433.YahooMailRC@web111409.mail.gq1.yahoo.com> Date: Thu, 7 Jul 2011 10:57:11 -0700 (PDT) From: Behcet Sarikaya To: Mark Townsley , Alain Durand In-Reply-To: <70C5EDAE-4297-47AB-B749-1B749450975E@townsley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "softwires@ietf.orglist" Subject: Re: [Softwires] Preparation for a discussion on 'stateless motivations' at the Quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:57:15 -0000 Hi Mark, It seems that the chairs have some concerns on the a+p transition technology which I understand. However here in so-called stateless solution, a+p is used in a very specific context, removing most of the concerns, at least to me. Regards, Behcet > > > >Let's have discussion on the list instead, k? > > >On Jul 7, 2011, at 3:38 PM, Alain Durand wrote: > >Following up on the 'stateless' thread from a wg chair perspective. The thread was nothing but an announcement that the draft was present, and a bunch of people saying that they support it. >Yong and I are preparing a discussion FOR the Quebec meeting on the so-called >stateless solution. > >There are a number of points in the current draft that need discussion. >Sure, based on your review of the document that's fine. But, not "the thread >from a WG chair perspective" as stated above. That's ridiculous. > > >For example, no logging has been presented as a strong reason to do sateless. >However, no logging can be achieved >>with static port allocation on a centralized NAT. On this particular logging >>point, there are no obvious differences between the >>'distributed on CPE' NAT solution and the centralized NAT solution. >> As you point out, the "no logging" part is really a function of the use of a static mapping to a range of ports. Any centralized NAPT function can use static mapping. When you use static mapping, then you get all the pros and cons that go along with it. More generally, it seems that what is described as a 'stateless' solution should be characterized as a >'distributed state' solution. As such, the tradeoff of maintaining the state >centrally vs globally >needs to be analyzed. > "stateless operation" if you prefer. The point is that within the ISP network, there is no per-flow state that resides on any single endpoint running the protocol in question. So, config can be static, and BRs can be reached via anycast. That's the heart of a stateless solution. Just like 6rd, if you will. Also, it is not clear from this document which set of issues listed in RFC6269 are mitigated and which ones are not. >In particular, I'd hold that a so-called 'stateless' solution does not change >anything about the recommendations in RFC6302/BCP162 >that are derived from RFC6269... > RFC6302/BCP162 is a Standards track document that makes an informational reference to an Informational RFC 6269, so I would hardly call that "derived from," else we would likely have a downref issue that would have needed to be called out during IETF Last call for RFC 6302. In any case, RFC 6269 has some very good information. In fact, it very correctly states: Whether we're talking about DS-Lite, A+P, NAT64, or CGN isn't especially important -- it's the view from the outside that matters, and given that, most of the issues identified below apply regardless of the specific address sharing scenario in question. So, since most of the issues don't matter between stateful vs. stateless (A+P), we can dismiss most of this document pretty quickly for this comparison. Here are a couple of issues that do seem to matter though: Section 13.4 Port Randomization - here the culprit is use of a static mapping again, and essentially the other side of the coin for "no logging". Put simply, if you want to reduce your logging with a predictable port, you also make your port more guessable by an attacker. . Section 18: Single Points of Failure - here, stateless wins pretty much hands down as it is not introducing any new single points of failure. Perhaps there are a few more, but "most" should be insignificant by the own document's admission. We, chairs, would like to prepare a 'organized' discussion around these points (and others). We need a small number of >volunteers to help frame this discussion. Please contact me and Yong directly if > >you want to help. >This is an important topic, and we intend to make sure there is ample time for >discussion in Quebec. > Why don't we just discuss it on the list and have a consensus call instead? If we had a thread of 200 messages as we did for moving 6to4 to historic, OK maybe we need to have a big coordinated discussion. But, I'm not seeing anything on the thread here that would suggest that we need to spend a lot of time preparing some big discussion among a group of people you and Yong select. - Mark > - Alain. > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > > From fbrockne@cisco.com Thu Jul 7 14:52:48 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C14C9E8037 for ; Thu, 7 Jul 2011 14:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbyMa4jc86r3 for ; Thu, 7 Jul 2011 14:52:47 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 84D149E8038 for ; Thu, 7 Jul 2011 14:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=10484; q=dns/txt; s=iport; t=1310075566; x=1311285166; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+ERZibPKTn+IMNeIbNydqHQqh2L0r9i3GNmNRH9Q+t8=; b=RWXHrdx83PYFn6tAvrq7zsM+QfaIKiFH5pJ+Pr11Ubg4ytWVc+oOVe2V ZdlRnDS1GmC7+GlPCPlLgKpFHAx1grOhoFh7kv6vfcIj7op0rkTPcPdHC QpLQqcmnkY1usA92hX8L+Zzktrhm07Y7S+r3YD0+sRgHCU4AUWTZRV+5A E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkBACcqFk6Q/khN/2dsb2JhbABTmAqPNHetQJ1zhjgEl0qLPA X-IronPort-AV: E=Sophos;i="4.65,495,1304294400"; d="scan'208";a="41116052" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Jul 2011 21:52:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p67LqgaE008209; Thu, 7 Jul 2011 21:52:42 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 23:52:42 +0200 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: Thu, 7 Jul 2011 23:52:40 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC062753AF@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: Acw8rWKLfxh+k1BMS3OGw6tu/8Mr+AAQqbFA References: From: "Frank Brockners (fbrockne)" To: "Jim Guichard" , "Paco Cortes" X-OriginalArrivalTime: 07 Jul 2011 21:52:42.0836 (UTC) FILETIME=[32C30140:01CC3CF0] Cc: softwires@ietf.org Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 21:52:48 -0000 Works for me (and thanks for the suggested text). If I don't hear otherwise, I'll post an -05 version by tomorrow including Jim's suggestions. Thanks, Frank > -----Original Message----- > From: Jim Guichard [mailto:jguichard@juniper.net] > Sent: Thursday, July 07, 2011 6:54 AM > To: Paco Cortes > Cc: softwires@ietf.org; Frank Brockners (fbrockne) > Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >=20 > Yes, I agree that this change makes sense and provides more flexibility > .. > thanks >=20 > On 7/7/11 9:48 AM, "Paco Cortes" wrote: >=20 > >Thanks Jim, now I get it. > >You were aiming at (outer label=3D SWID; inner label =3D CID), and I > >misunderstood it as (outer label =3D SWID, inner label =3D = something_new; > >IP @ =3D CID). > >Speaking about "vanilla MPLS" I was actually expecting (only label = =3D > >SWID; IP @ =3D CID) > > > >It sounds sensible to me. > >But do you really want to restrict the vanilla MPLS case to (outer > >label =3D SWID, inner label =3D CID)? In such case, the user IP@ is = pure > >overhead. > > > >Wouldn't it be better to cover both cases in one go? This could be > >done with a change like: > > > >- SWID is the top MPLS label. CID might be the next MPLS > >label in the stack, if present, or the AD's IP address. > > > >But don't take this email as an opposition to your last proposal to > >Frank. If nobody is interested on (single label=3DSWID, IP@=3DCID), = then I > >will not be the one pushing for it. > > > >br, > > Paco > > > > > > > > > > > >2011/7/7 Jim Guichard : > >> Hi Paco, > >> > >> Comments inline .. > >> > >> On 7/7/11 3:39 AM, "Paco Cortes" > wrote: > >> > >>>Hi Jim, > >>> > >>>can you clarify with the upper case part of your proposal? > >>> > >>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT WITHIN > >>>swid > >>>MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK. > >>> > >>>You are speaking about a fully different case than the "MPLS VPN" > case > >>>currently in the draft, where the VPN label (i.e. the inner MPLS > >>>label) is the SWID. > >>>To me it sounds like a very significant change to gi-ds-lite, as you > >>>seem to be proposing that traffic inside a softwire can be further > >>>"split" into contexts with some meaning (differentiated handling?) > by > >>>the AFTR. > >> > >> Jim> yes, exactly this. In this case the SWID is the top label and > the > >> next label in the stack is the CID. > >> > >>> > >>>Regarding the overall discussion in this thread (sorry I didn't > answer > >>>earlier), I disagree on the MPLS VPN case to be an overkill. In many > >>>cases, the one-label overhead in part of the path is fully justified > >>>by the gained operational simplicity (given by relaying on MP-BGP > and > >>>possibly CE-PE protocol for "softwire" setup and control > signalling). > >>>Also, as already mentioned by Yiu, it enables a very simple > >>>implementation of overlapping IP addresses. Although this could also > >>>be possible with your "vanilla MPLS" proposal, it would require some > >>>kind of additional (proprietary?) implementation both in Gateway and > >>>AFTR. > >> > >> Jim> let me clarify .. I completely agree that VPN should be > included. > >>My > >> overkill comment was more to do with the fact that in some > situations it > >> is not necessary to deploy the full MPLS VPN machinery. > >>> > >>>This said, I do see the point on adding "vanilla MPLS" as possible > >>>embodiment to the draft. There may be simple scenarios where it is > >>>fully sufficient. > >>>Maybe adding a bullet to section 6 like: > >>> > >>> o IPv4/IPv6-in-MPLS: SWID is the MPLS label. > >>> > >>>Would this be ok for you? > >> > >> Jim> I would like to see SWID =3D top label, CID =3D next label in stack > >> noting that the SWID label is not PHP. > >>> > >>>br, > >>> Paco > >>> > >>> > >>>2011/7/6 Frank Brockners (fbrockne) : > >>>> Hi Jim, > >>>> > >>>> ... works for me (any additional opinions from others?). > >>>> > >>>> In order to get a -05 version out quickly, could you detail the > >>>>change - > >>>> i.e. possibly expand the bullet you propose below with some > additional > >>>> explanation, like e.g. what would be used as CID for "vanilla > MPLS"; > >>>> propose another row for the table in section 6; etc. > >>>> > >>>> Once we have this, we could quickly compile a -05. > >>>> > >>>> Thanks, Frank > >>>> > >>>>> -----Original Message----- > >>>>> From: Jim Guichard [mailto:jguichard@juniper.net] > >>>>> Sent: Wednesday, July 06, 2011 6:24 AM > >>>>> To: Jim Guichard; Frank Brockners (fbrockne) > >>>>> Cc: softwires@ietf.org > >>>>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds- > list-02 > >>>>> > >>>>> Hi Frank, > >>>>> > >>>>> Reviewing version 04 of the draft I still do not see "vanilla" > MPLS > >>>>> encapsulation given as an option. I would like to suggest adding > >>>>> something > >>>>> like the following to section 6: > >>>>> > >>>>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context > within > >>>>> SWID > >>>>> may be indicated by the next MPLS label in the stack. > >>>>> > >>>>> > >>>>> On 3/28/11 1:17 PM, "Jim Guichard" wrote: > >>>>> > >>>>> >Hi Frank, > >>>>> > > >>>>> >What I would like to see is the ability to use TE without VPN's. > I > >>>>>do > >>>>> not > >>>>> >want to be forced to deploy VPN infrastructure in this case. > RSVP-TE > >>>>> is an > >>>>> >important piece of the puzzle as it provides the ability to > steer > >>>>> traffic > >>>>> >based upon policy that I may wish to enforce. I would be happy > to > >>>>> supply > >>>>> >text for the draft but would like to agree on this alias before > >>>>>doing > >>>>> so > >>>>> >.. > >>>>> > > >>>>> >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" > >>>>> > >>>>> >wrote: > >>>>> > > >>>>> >> > >>>>> >>Jim, > >>>>> >> > >>>>> >>why is VPN "overkill" (kind of delicate wording these days...)? > TE > >>>>> could > >>>>> >>also be combined with MPLS VPNs. > >>>>> >> > >>>>> >>Would also be interested in other folks' thoughts on the need > for > >>>>> >>"plain" IP-over-MPLS tunnels. > >>>>> >> > >>>>> >>Thanks, Frank > >>>>> >> > >>>>> >>> -----Original Message----- > >>>>> >>> From: Jim Guichard [mailto:jguichard@juniper.net] > >>>>> >>> Sent: Friday, March 25, 2011 8:03 PM > >>>>> >>> To: Frank Brockners (fbrockne) > >>>>> >>> Cc: softwires@ietf.org > >>>>> >>> Subject: Re: [Softwires] > >>>>>draft-ietf-softwire-gateway-init-ds-list- > >>>>> 02 > >>>>> >>> > >>>>> >>> VPN is overkill imho plus i want the ability to engineer > traffic > >>>>> paths > >>>>> >>> and for this i need TE > >>>>> >>> > >>>>> >>> Jim Guichard > >>>>> >>> > >>>>> >>> Principal Networking Architect > >>>>> >>> IPG CTO Office > >>>>> >>> Juniper Networks > >>>>> >>> > >>>>> >>> CCIE #2069 > >>>>> >>> > >>>>> >>> Sent from my iphone > >>>>> >>> > >>>>> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" > >>>>> >>> wrote: > >>>>> >>> > >>>>> >>> > Hi Jim, > >>>>> >>> > > >>>>> >>> > fully agreed that MPLS should not be absent from the draft, > and > >>>>> it > >>>>> >>is > >>>>> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list- > 03 > >>>>> doesn't > >>>>> >>> > restrict things to IP tunneling. The draft already allows > for > >>>>> MPLS > >>>>> >>> > transport between Gateway and AFTR using MPLS VPNs. > >>>>> >>> > > >>>>> >>> > Hence the question: For the use cases you have in mind, > >>>>>couldn't > >>>>> we > >>>>> >>> just > >>>>> >>> > use MPLS VPNs (possibly even point-to-point with just two > PEs > >>>>>in > >>>>> a > >>>>> >>> VPN - > >>>>> >>> > Gateway and the AFTR)? Personally I've nothing against > >>>> additional > >>>>> >>> > encapsulations, though so far there's always been a push in > the > >>>>> WG > >>>>> >>> (and > >>>>> >>> > also in 3GPP SA2) to keep the number of encapsulations to a > >>>>> minimum > >>>>> >>> > (e.g. L2TPv3 was dropped from the list of encaps, because > we > >>>>> could > >>>>> >>do > >>>>> >>> > the very same thing with GRE). > >>>>> >>> > > >>>>> >>> > On multicast: Don't fully follow your thought below. Do you > >>>>> consider > >>>>> >>> > running multicast over the softwire between AFTR and > Gateway? > >>>> The > >>>>> >>> > multicast considerations for GI-DS-lite (see > >>>>> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far assume > >>>>>that > >>>>> >>this > >>>>> >>> > would not be the case. > >>>>> >>> > > >>>>> >>> > Thanks, Frank > >>>>> >>> > > >>>>> >>> >> -----Original Message----- > >>>>> >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] > >>>>> >>> >> Sent: Thursday, March 24, 2011 9:43 PM > >>>>> >>> >> > >>>>> >>> >> Hi Frank, > >>>>> >>> >> > >>>>> >>> >> bi-directional tunnels are necessary if you wish for > traffic > >>>>> flows > >>>>> >>> to > >>>>> >>> >> take > >>>>> >>> >> the same path in both directions across the network. It is > >>>>> possible > >>>>> >>> to > >>>>> >>> >> use > >>>>> >>> >> point-to-point but this is cumbersome to deploy. > >>>>> >>Point-to-multipoint > >>>>> >>> >> may > >>>>> >>> >> be necessary for multicast. > >>>>> >>> >> > >>>>> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement > that > >>>>> >>> should > >>>>> >>> >> not > >>>>> >>> >> be absent from the draft. If an operator has MPLS why > restrict > >>>>> them > >>>>> >>> to > >>>>> >>> >> IP > >>>>> >>> >> tunneling? > >>>>> >>> >> > >>>>> >>> >> > >>>>> >>> >>> > >>>>> >>> >>> to kick-start the discussion, could you outline the usage > >>>>> >>scenarios > >>>>> >>> >> that > >>>>> >>> >>> would drive the requirements you mention below? > >>>>> >>> >>> > >>>>> >>> > > >>>>> > > >>>>> >_______________________________________________ > >>>>> >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 Thu Jul 7 14:59:17 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99E91F0C3F for ; Thu, 7 Jul 2011 14:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.145 X-Spam-Level: X-Spam-Status: No, score=-106.145 tagged_above=-999 required=5 tests=[AWL=1.718, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO9C4fuq4l6Z for ; Thu, 7 Jul 2011 14:59:16 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 48B441F0C3A for ; Thu, 7 Jul 2011 14:59:10 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.133439832; Thu, 07 Jul 2011 17:59:06 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Thu, 7 Jul 2011 17:59:06 -0400 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: AQHMPPEMLTglG2WLRkyzvj9YDDkeaw== Date: Thu, 7 Jul 2011 21:59:05 +0000 Message-ID: In-Reply-To: <0D212BD466921646B58854FB79092CEC062753AF@XMB-AMS-106.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 21:59:17 -0000 Hi Frank, Did Jim and Paco metnion to also allow IP for the CID? So, I suggest to modify Section 6: Section 6: - add the following bullet: o IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID is the next MPLS label in the stack or IPv4 address if the AFTR is the last hop of the LSP. The AFTR may use the CID locally to identify context within a given inbound softwire. On 7/7/11 5:52 PM, "Frank Brockners (fbrockne)" wrote: > >Works for me (and thanks for the suggested text). If I don't hear >otherwise, I'll post an -05 version by tomorrow including Jim's >suggestions. > >Thanks, Frank > >> -----Original Message----- >> From: Jim Guichard [mailto:jguichard@juniper.net] >> Sent: Thursday, July 07, 2011 6:54 AM >> To: Paco Cortes >> Cc: softwires@ietf.org; Frank Brockners (fbrockne) >> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>=20 >> Yes, I agree that this change makes sense and provides more >flexibility >> .. >> thanks >>=20 >> On 7/7/11 9:48 AM, "Paco Cortes" wrote: >>=20 >> >Thanks Jim, now I get it. >> >You were aiming at (outer label=3D SWID; inner label =3D CID), and I >> >misunderstood it as (outer label =3D SWID, inner label =3D something_ne= w; >> >IP @ =3D CID). >> >Speaking about "vanilla MPLS" I was actually expecting (only label =3D >> >SWID; IP @ =3D CID) >> > >> >It sounds sensible to me. >> >But do you really want to restrict the vanilla MPLS case to (outer >> >label =3D SWID, inner label =3D CID)? In such case, the user IP@ is pur= e >> >overhead. >> > >> >Wouldn't it be better to cover both cases in one go? This could be >> >done with a change like: >> > >> >- SWID is the top MPLS label. CID might be the next MPLS >> >label in the stack, if present, or the AD's IP address. >> > >> >But don't take this email as an opposition to your last proposal to >> >Frank. If nobody is interested on (single label=3DSWID, IP@=3DCID), the= n >I >> >will not be the one pushing for it. >> > >> >br, >> > Paco >> > >> > >> > >> > >> > >> >2011/7/7 Jim Guichard : >> >> Hi Paco, >> >> >> >> Comments inline .. >> >> >> >> On 7/7/11 3:39 AM, "Paco Cortes" >> wrote: >> >> >> >>>Hi Jim, >> >>> >> >>>can you clarify with the upper case part of your proposal? >> >>> >> >>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT >WITHIN >> >>>swid >> >>>MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK. >> >>> >> >>>You are speaking about a fully different case than the "MPLS VPN" >> case >> >>>currently in the draft, where the VPN label (i.e. the inner MPLS >> >>>label) is the SWID. >> >>>To me it sounds like a very significant change to gi-ds-lite, as >you >> >>>seem to be proposing that traffic inside a softwire can be further >> >>>"split" into contexts with some meaning (differentiated handling?) >> by >> >>>the AFTR. >> >> >> >> Jim> yes, exactly this. In this case the SWID is the top label and >> the >> >> next label in the stack is the CID. >> >> >> >>> >> >>>Regarding the overall discussion in this thread (sorry I didn't >> answer >> >>>earlier), I disagree on the MPLS VPN case to be an overkill. In >many >> >>>cases, the one-label overhead in part of the path is fully >justified >> >>>by the gained operational simplicity (given by relaying on MP-BGP >> and >> >>>possibly CE-PE protocol for "softwire" setup and control >> signalling). >> >>>Also, as already mentioned by Yiu, it enables a very simple >> >>>implementation of overlapping IP addresses. Although this could >also >> >>>be possible with your "vanilla MPLS" proposal, it would require >some >> >>>kind of additional (proprietary?) implementation both in Gateway >and >> >>>AFTR. >> >> >> >> Jim> let me clarify .. I completely agree that VPN should be >> included. >> >>My >> >> overkill comment was more to do with the fact that in some >> situations it >> >> is not necessary to deploy the full MPLS VPN machinery. >> >>> >> >>>This said, I do see the point on adding "vanilla MPLS" as possible >> >>>embodiment to the draft. There may be simple scenarios where it is >> >>>fully sufficient. >> >>>Maybe adding a bullet to section 6 like: >> >>> >> >>> o IPv4/IPv6-in-MPLS: SWID is the MPLS label. >> >>> >> >>>Would this be ok for you? >> >> >> >> Jim> I would like to see SWID =3D top label, CID =3D next label in >stack >> >> noting that the SWID label is not PHP. >> >>> >> >>>br, >> >>> Paco >> >>> >> >>> >> >>>2011/7/6 Frank Brockners (fbrockne) : >> >>>> Hi Jim, >> >>>> >> >>>> ... works for me (any additional opinions from others?). >> >>>> >> >>>> In order to get a -05 version out quickly, could you detail the >> >>>>change - >> >>>> i.e. possibly expand the bullet you propose below with some >> additional >> >>>> explanation, like e.g. what would be used as CID for "vanilla >> MPLS"; >> >>>> propose another row for the table in section 6; etc. >> >>>> >> >>>> Once we have this, we could quickly compile a -05. >> >>>> >> >>>> Thanks, Frank >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Jim Guichard [mailto:jguichard@juniper.net] >> >>>>> Sent: Wednesday, July 06, 2011 6:24 AM >> >>>>> To: Jim Guichard; Frank Brockners (fbrockne) >> >>>>> Cc: softwires@ietf.org >> >>>>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds- >> list-02 >> >>>>> >> >>>>> Hi Frank, >> >>>>> >> >>>>> Reviewing version 04 of the draft I still do not see "vanilla" >> MPLS >> >>>>> encapsulation given as an option. I would like to suggest adding >> >>>>> something >> >>>>> like the following to section 6: >> >>>>> >> >>>>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context >> within >> >>>>> SWID >> >>>>> may be indicated by the next MPLS label in the stack. >> >>>>> >> >>>>> >> >>>>> On 3/28/11 1:17 PM, "Jim Guichard" >wrote: >> >>>>> >> >>>>> >Hi Frank, >> >>>>> > >> >>>>> >What I would like to see is the ability to use TE without >VPN's. >> I >> >>>>>do >> >>>>> not >> >>>>> >want to be forced to deploy VPN infrastructure in this case. >> RSVP-TE >> >>>>> is an >> >>>>> >important piece of the puzzle as it provides the ability to >> steer >> >>>>> traffic >> >>>>> >based upon policy that I may wish to enforce. I would be happy >> to >> >>>>> supply >> >>>>> >text for the draft but would like to agree on this alias before >> >>>>>doing >> >>>>> so >> >>>>> >.. >> >>>>> > >> >>>>> >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >> >>>>> >> >>>>> >wrote: >> >>>>> > >> >>>>> >> >> >>>>> >>Jim, >> >>>>> >> >> >>>>> >>why is VPN "overkill" (kind of delicate wording these >days...)? >> TE >> >>>>> could >> >>>>> >>also be combined with MPLS VPNs. >> >>>>> >> >> >>>>> >>Would also be interested in other folks' thoughts on the need >> for >> >>>>> >>"plain" IP-over-MPLS tunnels. >> >>>>> >> >> >>>>> >>Thanks, Frank >> >>>>> >> >> >>>>> >>> -----Original Message----- >> >>>>> >>> From: Jim Guichard [mailto:jguichard@juniper.net] >> >>>>> >>> Sent: Friday, March 25, 2011 8:03 PM >> >>>>> >>> To: Frank Brockners (fbrockne) >> >>>>> >>> Cc: softwires@ietf.org >> >>>>> >>> Subject: Re: [Softwires] >> >>>>>draft-ietf-softwire-gateway-init-ds-list- >> >>>>> 02 >> >>>>> >>> >> >>>>> >>> VPN is overkill imho plus i want the ability to engineer >> traffic >> >>>>> paths >> >>>>> >>> and for this i need TE >> >>>>> >>> >> >>>>> >>> Jim Guichard >> >>>>> >>> >> >>>>> >>> Principal Networking Architect >> >>>>> >>> IPG CTO Office >> >>>>> >>> Juniper Networks >> >>>>> >>> >> >>>>> >>> CCIE #2069 >> >>>>> >>> >> >>>>> >>> Sent from my iphone >> >>>>> >>> >> >>>>> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >> >>>>> >>> wrote: >> >>>>> >>> >> >>>>> >>> > Hi Jim, >> >>>>> >>> > >> >>>>> >>> > fully agreed that MPLS should not be absent from the >draft, >> and >> >>>>> it >> >>>>> >>is >> >>>>> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list- >> 03 >> >>>>> doesn't >> >>>>> >>> > restrict things to IP tunneling. The draft already allows >> for >> >>>>> MPLS >> >>>>> >>> > transport between Gateway and AFTR using MPLS VPNs. >> >>>>> >>> > >> >>>>> >>> > Hence the question: For the use cases you have in mind, >> >>>>>couldn't >> >>>>> we >> >>>>> >>> just >> >>>>> >>> > use MPLS VPNs (possibly even point-to-point with just two >> PEs >> >>>>>in >> >>>>> a >> >>>>> >>> VPN - >> >>>>> >>> > Gateway and the AFTR)? Personally I've nothing against >> >>>> additional >> >>>>> >>> > encapsulations, though so far there's always been a push >in >> the >> >>>>> WG >> >>>>> >>> (and >> >>>>> >>> > also in 3GPP SA2) to keep the number of encapsulations to >a >> >>>>> minimum >> >>>>> >>> > (e.g. L2TPv3 was dropped from the list of encaps, because >> we >> >>>>> could >> >>>>> >>do >> >>>>> >>> > the very same thing with GRE). >> >>>>> >>> > >> >>>>> >>> > On multicast: Don't fully follow your thought below. Do >you >> >>>>> consider >> >>>>> >>> > running multicast over the softwire between AFTR and >> Gateway? >> >>>> The >> >>>>> >>> > multicast considerations for GI-DS-lite (see >> >>>>> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far >assume >> >>>>>that >> >>>>> >>this >> >>>>> >>> > would not be the case. >> >>>>> >>> > >> >>>>> >>> > Thanks, Frank >> >>>>> >>> > >> >>>>> >>> >> -----Original Message----- >> >>>>> >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] >> >>>>> >>> >> Sent: Thursday, March 24, 2011 9:43 PM >> >>>>> >>> >> >> >>>>> >>> >> Hi Frank, >> >>>>> >>> >> >> >>>>> >>> >> bi-directional tunnels are necessary if you wish for >> traffic >> >>>>> flows >> >>>>> >>> to >> >>>>> >>> >> take >> >>>>> >>> >> the same path in both directions across the network. It >is >> >>>>> possible >> >>>>> >>> to >> >>>>> >>> >> use >> >>>>> >>> >> point-to-point but this is cumbersome to deploy. >> >>>>> >>Point-to-multipoint >> >>>>> >>> >> may >> >>>>> >>> >> be necessary for multicast. >> >>>>> >>> >> >> >>>>> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement >> that >> >>>>> >>> should >> >>>>> >>> >> not >> >>>>> >>> >> be absent from the draft. If an operator has MPLS why >> restrict >> >>>>> them >> >>>>> >>> to >> >>>>> >>> >> IP >> >>>>> >>> >> tunneling? >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >>> >>> >> >>>>> >>> >>> to kick-start the discussion, could you outline the >usage >> >>>>> >>scenarios >> >>>>> >>> >> that >> >>>>> >>> >>> would drive the requirements you mention below? >> >>>>> >>> >>> >> >>>>> >>> > >> >>>>> > >> >>>>> >_______________________________________________ >> >>>>> >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 tsahara@iij.ad.jp Thu Jul 7 22:37:21 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6659D21F8902 for ; Thu, 7 Jul 2011 22:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y780h7qGmBV for ; Thu, 7 Jul 2011 22:37:20 -0700 (PDT) Received: from omgo.iij.ad.jp (mo00.iij.ad.jp [202.232.30.145]) by ietfa.amsl.com (Postfix) with ESMTP id D544F21F87CF for ; Thu, 7 Jul 2011 22:37:15 -0700 (PDT) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Cc:Subject:From:In-Reply-To:References:Mime-Version: Content-Type:Content-Transfer-Encoding;i=tsahara@iij.ad.jp;s=omgo1;t= 1310103429; x=1311313029; bh=jX3WFEgbOgqlMTBAf6hZ50at51OokWcLFoIk8l4+aYI=; b=Fdf fUhhmEpikuf+D6Ph587bNdUhCH7DanzE24E2cOl29CYmaP4xnA59tJ1D2iM16F74CspfEkybVoH3C QJN9QM9xuBKMH+H5Kuu145JvV2D9lFbsD+KHfTZKqrJmhVv+WgY+9cWFejVQ7ByXh+5WxeCqSYTqj F5tnQytwNOyoMU=; Received: by omgo.iij.ad.jp (mo00) id p685b8LH009421; Fri, 8 Jul 2011 14:37:08 +0900 Date: Fri, 08 Jul 2011 14:37:00 +0900 (JST) Message-Id: <20110708.143700.407454645627535350.tsahara@iij.ad.jp> To: softwires@ietf.org, softwire-chairs@tools.ietf.org From: Tomoyuki Sahara In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com> <27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> <4E1529C4.4000800@cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> X-PGP-Fingerprint: 7DBC BE8A 4965 ED2B EE79 DE9F 8150 67F8 4A25 6385 X-Mailer: Mew version 5.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Isabel@ptinovacao.pt, chengang@chinamobile.com, rajiva@cisco.com Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 05:37:21 -0000 +1 Stateless protocols are easy to implement. Thanks, Tomoyuki >From: >Date: Thu, Jul 7, 2011 at 5:03 PM >Subject: Re: [Softwires] Next step for Stateless Motivations I-D > > >+1 > >Cheers, >Xiaohong. > >open source PCP Client, >open source A+P >http://opensourcev6transtechnologies.weebly.com/ > >| >|+1 >| >|Tetsuya Murakami wrote: >|> +1 >|> >|> On 2011/07/06, at 8:23, GangChen wrote: >|> >|>> +1 >|>> >|>> >|>> 2011/7/6, Lee, Yiu: >|>>> +1 >|>>> >|>>> On 7/6/11 10:33 AM, "Rajiv Asati >|(rajiva)" =A0wrote: >|>>> >|>>>> Support. >|>>>> >|>>>> Cheers, >|>>>> Rajiv >|>>>> >|>>>> >|>>>>> -----Original Message----- >|>>>>> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] >|>>>>> Sent: Friday, June 17, 2011 2:32 AM >|>>>>> To: >|>>>>> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; >|Lee, Yiu; >|>>>>> Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; >|>>>> chengang@chinamobile.com >|>>>>> Subject: Re: Next step for Stateless Motivations I-D >|>>>>> >|>>>>> Dear Softwires Working Group chairs, >|>>>>> >|>>>>> I support that an request from Mohamed to make WG adoption as >|>>>> appropriate >|>>>>> charter item. >|>>>>> I'm looking forward you to take your kind adoption procedure fo= r >|>>>>> the >|>>>> request. >|>>>>> >|>>>>> Sincerely yours, >|>>>>> >|>>>>> -- >|>>>>> Satoru Matsushima >|>>>>> >|>>>>> >|>>>>> On 2011/06/10, at 20:31, >|>>>>> =A0wrote: >|>>>>> >|>>>>>> Dear all, >|>>>>>> >|>>>>>> An updated version of the "Motivations for Stateless IPv4 over= >|>>>>>> IPv6 >|>>>>> Migration Solutions" I-D has been submitted. The document is >|>>>>> available >|>>>> at: >|>>>>>> >|http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6 >|>>>>>> - >|>>>>> motivation-02 >|>>>>>> >|>>>>>> This document has been largely reviewed and inputs from other >|>>>> contributors >|>>>>> has been taken into account. >|>>>>>> >|>>>>>> Together with my co-authors, we ask the working group >|to consider >|>>>> the >|>>>>> adoption of this document as a WG I-D. >|>>>>>> >|>>>>>> Comments and suggestions are more than welcome. >|>>>>>> >|>>>>>> Cheers, >|>>>>>> Med >|>>>> >|>>> >|>>> _______________________________________________ >|>>> 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 satoru.matsushima@gmail.com Fri Jul 8 00:14:41 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51D721F8874 for ; Fri, 8 Jul 2011 00:14: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZaAtcfOGisS for ; Fri, 8 Jul 2011 00:14:38 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF2B21F883F for ; Fri, 8 Jul 2011 00:14:36 -0700 (PDT) Received: by pwj5 with SMTP id 5so255679pwj.31 for ; Fri, 08 Jul 2011 00:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MKZoUPr5VHHoYq0TfINXKq3VhCcuOTWolXNmkL2xYfw=; b=K9CEJMka6h213tC6lpojJsVn6HkgMoMAyKhMa7+LZ8oqJJZ8KK2ONJLDejxplTrM8T 7mTm5i1NQ5ICasCSF84/SsXnp/lkxkD6k7/PQ38yQLi+xDDei59fwFskHReQ/T4fR4g3 Rl4T6pIWvCrhTAJ91DV0FChIk+Sf2kSvVhcAI= Received: by 10.142.162.7 with SMTP id k7mr130583wfe.313.1310109276649; Fri, 08 Jul 2011 00:14:36 -0700 (PDT) Received: from [10.201.81.48] ([202.45.12.174]) by mx.google.com with ESMTPS id q6sm2121492wfg.8.2011.07.08.00.14.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 00:14:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> Date: Fri, 8 Jul 2011 16:14:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com><27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> <4E1529C4.4000800@cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Preparation for a discussion on 'stateless motivations' at the Quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:14:43 -0000 Dear Alain, I'm very happy to have discussion, not only in Quebec meeting, but also = on the list.=20 Actually, we had two month from we submitted the initial version. While = that time, we received many valuable comments and discussions from = people. Most significant thing we did is that we have unified two drafts = into the one. So we have accordingly asked you to adopt it as a WG = document. IMHO, there's no concern to take this procedure, no = alternatives but there are many supports from community.=20 My understanding here is that this work is an appropriate charter item, = WG document adoption is JUST starting point. Best regards, --satoru On 2011/07/07, at 22:38, Alain Durand wrote: > Following up on the 'stateless' thread from a wg chair perspective. >=20 > Yong and I are preparing a discussion FOR the Quebec meeting on the = so-called stateless solution. >=20 > There are a number of points in the current draft that need = discussion. >=20 > For example, no logging has been presented as a strong reason to do = sateless. However, no logging can be achieved > with static port allocation on a centralized NAT. On this particular = logging point, there are no obvious differences between the > 'distributed on CPE' NAT solution and the centralized NAT solution. >=20 > More generally, it seems that what is described as a 'stateless' = solution should be characterized as a > 'distributed state' solution. As such, the tradeoff of maintaining the = state centrally vs globally > needs to be analyzed. >=20 > Also, it is not clear from this document which set of issues listed in = RFC6269 are mitigated and which ones are not. > In particular, I'd hold that a so-called 'stateless' solution does not = change anything about the recommendations in RFC6302/BCP162 > that are derived from RFC6269... >=20 > We, chairs, would like to prepare a 'organized' discussion around = these points (and others). We need a small number of > volunteers to help frame this discussion. Please contact me and Yong = directly if you want to help. > This is an important topic, and we intend to make sure there is ample = time for discussion in Quebec. >=20 > - Alain. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From xiaohong.deng@orange-ftgroup.com Fri Jul 8 00:51:06 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E77D21F86CD for ; Fri, 8 Jul 2011 00:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6iSTEzLw3yV for ; Fri, 8 Jul 2011 00:51:05 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 09E5E21F86C7 for ; Fri, 8 Jul 2011 00:51:04 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1ADD5FC4003; Fri, 8 Jul 2011 09:51:01 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0A90CFC4001; Fri, 8 Jul 2011 09:51:01 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 09:51:01 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3D43.C5D15438" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Jul 2011 15:50:57 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC01869CA8@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC01869C8A@ch-mailsrv.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[Softwires] Preparation for a discussion on 'statelessmotivations' at the Quebec meeting Thread-Index: Acw9QUUPr375/hEGQCCIgjbQENKevAAABmOQ References: <0962B0BEF842A24191AD9BE41A8DD2FC01869C8A@ch-mailsrv.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 08 Jul 2011 07:51:01.0228 (UTC) FILETIME=[C7DEEAC0:01CC3D43] Cc: softwires@ietf.org Subject: Re: [Softwires] Preparation for a discussion on 'statelessmotivations' at the Quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:51:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3D43.C5D15438 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQoJCUZvciBleGFtcGxlLCBubyBsb2dnaW5nIGhhcyBiZWVuIHByZXNlbnRlZCBhcyBhIHN0 cm9uZyByZWFzb24gdG8gZG8gc2F0ZWxlc3MuIEhvd2V2ZXIsIG5vIGxvZ2dpbmcgY2FuIGJlIGFj aGlldmVkDQoJCXdpdGggc3RhdGljIHBvcnQgYWxsb2NhdGlvbiBvbiBhIGNlbnRyYWxpemVkIE5B VC4gT24gdGhpcyBwYXJ0aWN1bGFyIGxvZ2dpbmcgcG9pbnQsIHRoZXJlIGFyZSBubyBvYnZpb3Vz IGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlDQoJCSdkaXN0cmlidXRlZCBvbiBDUEUnIE5BVCBzb2x1 dGlvbiBhbmQgdGhlIGNlbnRyYWxpemVkIE5BVCBzb2x1dGlvbi4gDQoJCSANCgkJVG8gbXkgdW5k ZXJzdGFuZCwgbm8gbG9nZ2luZyBpcyBvbmUgb2YgYmVuaWZpdHMgYW1vbmcgb3RoZXJzLiANCgkJ SW4gYWRkaXRpb24sIG5vdGUgdGhhdCBldmVuIGlmIGEgY2VudHJhbGl6ZWQgTkFUIGNvbmZpZ3Vl cmVkIHdpdGggc3RhdGljIHBvcnQgYWxsb2NhdGlvbiwgdGhlIGNlbnRyYWxpemVkIE5BVCBzdGls bCBuZWVkcyB0byBtYWludGFpbiBwZXItZmxvdyBzdGF0ZSAoTkFUIGVudGlyZXMpISANCg0KCUFz IHlvdSBwb2ludCBvdXQsIHRoZSAibm8gbG9nZ2luZyIgcGFydCBpcyByZWFsbHkgYSBmdW5jdGlv biBvZiB0aGUgdXNlIG9mIGEgc3RhdGljIG1hcHBpbmcgdG8gYSByYW5nZSBvZiBwb3J0cy4gQW55 IGNlbnRyYWxpemVkIE5BUFQgZnVuY3Rpb24gY2FuIHVzZSBzdGF0aWMgbWFwcGluZy4gV2hlbiB5 b3UgdXNlIHN0YXRpYyBtYXBwaW5nLCB0aGVuIHlvdSBnZXQgYWxsIHRoZSBwcm9zIGFuZCBjb25z IHRoYXQgZ28gYWxvbmcgd2l0aCBpdC4NCgkNCgkNCg0KCQlNb3JlIGdlbmVyYWxseSwgaXQgc2Vl bXMgdGhhdCB3aGF0IGlzIGRlc2NyaWJlZCBhcyBhICdzdGF0ZWxlc3MnIHNvbHV0aW9uIHNob3Vs ZCBiZSBjaGFyYWN0ZXJpemVkIGFzIGENCgkJJ2Rpc3RyaWJ1dGVkIHN0YXRlJyBzb2x1dGlvbi4g QXMgc3VjaCwgdGhlIHRyYWRlb2ZmIG9mIG1haW50YWluaW5nIHRoZSBzdGF0ZSBjZW50cmFsbHkg dnMgZ2xvYmFsbHkNCgkJbmVlZHMgdG8gYmUgYW5hbHl6ZWQuDQoJCQ0KDQoJDQoJDQoJInN0YXRl bGVzcyBvcGVyYXRpb24iIGlmIHlvdSBwcmVmZXIuIFRoZSBwb2ludCBpcyB0aGF0IHdpdGhpbiB0 aGUgSVNQIG5ldHdvcmssIHRoZXJlIGlzIG5vIHBlci1mbG93IHN0YXRlIHRoYXQgcmVzaWRlcyBv biBhbnkgc2luZ2xlIGVuZHBvaW50IHJ1bm5pbmcgdGhlIHByb3RvY29sIGluIHF1ZXN0aW9uLiAg U28sIGNvbmZpZyBjYW4gYmUgc3RhdGljLCBhbmQgQlJzIGNhbiBiZSByZWFjaGVkIHZpYSBhbnlj YXN0LiBUaGF0J3MgdGhlIGhlYXJ0IG9mIGEgc3RhdGVsZXNzIHNvbHV0aW9uLiBKdXN0IGxpa2Ug NnJkLCBpZiB5b3Ugd2lsbC4gIA0KCSANCglJIGxpa2UgdGhpcyBwb2ludCEgTm8gcGVyLWZsb3cg c3RhdGUgaXMgdGhlIGhlYXJ0LiAgICAgDQoJICAgICANCgkgDQoJU2VjdGlvbiAxODogU2luZ2xl IFBvaW50cyBvZiBGYWlsdXJlIC0gaGVyZSwgc3RhdGVsZXNzIHdpbnMgcHJldHR5IG11Y2ggaGFu ZHMgZG93biBhcyBpdCBpcyBub3QgaW50cm9kdWNpbmcgYW55IG5ldyBzaW5nbGUgcG9pbnRzIG9m IGZhaWx1cmUuIA0KCSANCglPbmUgaGFuZC4gDQoJDQoJLVhpYW9ob25nDQoJb3BlbiBzb3VyY2Ug UENQIENsaWVudCwNCglvcGVuIHNvdXJjZSBBK1ANCglodHRwOi8vb3BlbnNvdXJjZXY2dHJhbnN0 ZWNobm9sb2dpZXMud2VlYmx5LmNvbS8NCgkgDQoNCg== ------_=_NextPart_001_01CC3D43.C5D15438 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjYwMDAuMTcwOTUiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT3lrovkvZMgY29sb3I9IzAwMDBmZiBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLUxF RlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlk OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVY+DQogIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUi Pg0KICAgIDxESVY+Rm9yIGV4YW1wbGUsIG5vIGxvZ2dpbmcgaGFzIGJlZW4gcHJlc2VudGVkIGFz IGEgc3Ryb25nIHJlYXNvbiB0byBkbyANCiAgICBzYXRlbGVzcy4gSG93ZXZlciwgbm8gbG9nZ2lu ZyBjYW4gYmUgYWNoaWV2ZWQ8QlI+d2l0aCBzdGF0aWMgcG9ydCBhbGxvY2F0aW9uIA0KICAgIG9u IGEgY2VudHJhbGl6ZWQgTkFULiBPbiB0aGlzIHBhcnRpY3VsYXIgbG9nZ2luZyBwb2ludCwgdGhl cmUgYXJlIG5vIG9idmlvdXMgDQogICAgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGU8QlI+J2Rpc3Ry aWJ1dGVkIG9uIENQRScgTkFUIHNvbHV0aW9uIGFuZCB0aGUgDQogICAgY2VudHJhbGl6ZWQgTkFU IHNvbHV0aW9uLjxGT05UIGZhY2U95a6L5L2TPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQog ICAgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTcxMDQ1MzMwNy0wODA3MjAxMT4mbmJzcDs8L1NQ QU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPeWui+S9 kz48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05UIHNpemU9Mj48U1BBTiANCiAgICBjbGFzcz03MTA0 NTMzMDctMDgwNzIwMTE+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPiZuYnNwOzwvRElWPg0K ICAgIDxESVY+PEZPTlQ+PEZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9 Mj48U1BBTiANCiAgICBjbGFzcz03MTA0NTMzMDctMDgwNzIwMTE+VG8gbXkgdW5kZXJzdGFuZCwg bm8gbG9nZ2luZyBpcyBvbmUgb2YgYmVuaWZpdHMgDQogICAgYW1vbmcgb3RoZXJzLiA8L1NQQU4+ PC9GT05UPjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVD48Rk9OVD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICAgIGNsYXNzPTcxMDQ1MzMw Ny0wODA3MjAxMT5JbiBhZGRpdGlvbiwgbjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48U1BB TiANCiAgICBjbGFzcz03MTA0NTMzMDctMDgwNzIwMTE+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj5vdGUgdGhhdCBldmVuIA0KICAgIGlmIGEgY2VudHJhbGl6ZWQgTkFUIGNv bmZpZ3VlcmVkIHdpdGggc3RhdGljIHBvcnQmbmJzcDthbGxvY2F0aW9uLCB0aGUgDQogICAgY2Vu dHJhbGl6ZWQgTkFUIHN0aWxsIG5lZWRzIHRvIG1haW50YWluJm5ic3A7cGVyLWZsb3cgc3RhdGUg KE5BVCANCiAgICBlbnRpcmVzKSEmbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRElWPjwvQkxPQ0tRVU9U RT4NCiAgPERJVj5BcyB5b3UgcG9pbnQgb3V0LCB0aGUgIm5vIGxvZ2dpbmciIHBhcnQgaXMgcmVh bGx5IGEgZnVuY3Rpb24gb2YgdGhlIHVzZSANCiAgb2YgYSBzdGF0aWMgbWFwcGluZyB0byBhIHJh bmdlIG9mIHBvcnRzLiBBbnkmbmJzcDtjZW50cmFsaXplZCBOQVBUIGZ1bmN0aW9uIA0KICBjYW4g dXNlIHN0YXRpYyBtYXBwaW5nLiBXaGVuIHlvdSB1c2Ugc3RhdGljIG1hcHBpbmcsIHRoZW4geW91 IGdldCBhbGwgdGhlIHByb3MgDQogIGFuZCBjb25zIHRoYXQgZ28gYWxvbmcgd2l0aCBpdC48L0RJ Vj4NCiAgPERJVj48Rk9OVCBmYWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+ PEZPTlQgZmFjZT3lrovkvZMgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48Rk9OVCBm YWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMg DQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPeWui+S9kyBjb2xvcj0j MDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjxCUj48L0RJVj4NCiAgPEJMT0NLUVVPVEUgdHlwZT0i Y2l0ZSI+DQogICAgPERJVj5Nb3JlIGdlbmVyYWxseSwgaXQgc2VlbXMgdGhhdCB3aGF0IGlzIGRl c2NyaWJlZCBhcyBhICdzdGF0ZWxlc3MnIA0KICAgIHNvbHV0aW9uIHNob3VsZCBiZSBjaGFyYWN0 ZXJpemVkIGFzIGE8QlI+J2Rpc3RyaWJ1dGVkIHN0YXRlJyBzb2x1dGlvbi4gQXMgDQogICAgc3Vj aCwgdGhlIHRyYWRlb2ZmIG9mIG1haW50YWluaW5nIHRoZSBzdGF0ZSBjZW50cmFsbHkgdnMgZ2xv YmFsbHk8QlI+bmVlZHMgDQogICAgdG8gYmUgYW5hbHl6ZWQuPEJSPjwvRElWPjwvQkxPQ0tRVU9U RT4NCiAgPERJVj48Rk9OVCBmYWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+ PEZPTlQgZmFjZT3lrovkvZMgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48Rk9OVCBm YWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMg DQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPeWui+S9kyBjb2xvcj0j MDAwMGZmIHNpemU9Mj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U95a6L5L2TIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+InN0YXRlbGVzcyBvcGVyYXRpb24iIGlm IHlvdSBwcmVmZXIuIFRoZSBwb2ludCBpcyB0aGF0IHdpdGhpbiB0aGUgSVNQIA0KICBuZXR3b3Jr LCB0aGVyZSBpcyBubyBwZXItZmxvdyBzdGF0ZSB0aGF0IHJlc2lkZXMgb24gYW55IHNpbmdsZSBl bmRwb2ludCANCiAgcnVubmluZyB0aGUgcHJvdG9jb2wgaW4gcXVlc3Rpb24uICZuYnNwO1NvLCBj b25maWcgY2FuIGJlIHN0YXRpYywgYW5kIEJScyBjYW4gDQogIGJlIHJlYWNoZWQgdmlhIGFueWNh c3QuIFRoYXQncyB0aGUgaGVhcnQgb2YgYSBzdGF0ZWxlc3Mgc29sdXRpb24uJm5ic3A7SnVzdCAN CiAgbGlrZSA2cmQsIGlmIHlvdSB3aWxsLiZuYnNwOzxTUEFOIGNsYXNzPTcxMDQ1MzMwNy0wODA3 MjAxMT48Rk9OVCBmYWNlPeWui+S9kyANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+Jm5ic3A7PC9G T05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03MTA0NTMzMDctMDgwNzIwMTE+ PEZPTlQgZmFjZT3lrovkvZMgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgY29sb3I9IzAwMDBmZj48U1BBTiBjbGFzcz03MTA0 NTMzMDctMDgwNzIwMTE+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPkkgbGlrZSB0aGlzIHBv aW50ISBObyBwZXItZmxvdyBzdGF0ZSBpcyB0aGUgaGVhcnQuPC9GT05UPjwvU1BBTj48U1BBTiAN CiAgY2xhc3M9NzEwNDUzMzA3LTA4MDcyMDExPjxGT05UIGZhY2U95a6L5L2TIA0KICBzaXplPTI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9ESVY+ DQogIDxESVY+PFNQQU4gY2xhc3M9NzEwNDUzMzA3LTA4MDcyMDExPjxGT05UIGZhY2U95a6L5L2T IGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05U PjwvU1BBTj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+U2VjdGlvbiAxODogU2luZ2xlIFBvaW50 cyBvZiBGYWlsdXJlIC0gaGVyZSwgc3RhdGVsZXNzIHdpbnMgcHJldHR5IG11Y2ggDQogIGhhbmRz IGRvd24gYXMgaXQgaXMgbm90IGludHJvZHVjaW5nIGFueSBuZXcgc2luZ2xlIHBvaW50cyBvZiBm YWlsdXJlLjxTUEFOIA0KICBjbGFzcz03MTA0NTMzMDctMDgwNzIwMTE+PEZPTlQgZmFjZT3lrovk vZMgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9ESVY+DQog IDxESVY+PFNQQU4gY2xhc3M9NzEwNDUzMzA3LTA4MDcyMDExPjxGT05UIGZhY2U95a6L5L2TIGNv bG9yPSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElW PjxTUEFOIGNsYXNzPTcxMDQ1MzMwNy0wODA3MjAxMT48Rk9OVCBjb2xvcj0jMDAwMGZmPjxGT05U IGZhY2U9QXJpYWwgDQogIHNpemU9Mj5PbmUgaGFuZC4mbmJzcDs8L0ZPTlQ+PC9GT05UPjwvU1BB Tj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 L0ZPTlQ+PEZPTlQgZmFjZT3lrovkvZMgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48 Rk9OVCBmYWNlPeWui+S9kyBjb2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT3l rovkvZMgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPeWui+S9kyBj b2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjxCUj48U1BBTiBjbGFzcz03MTA0NTMzMDct MDgwNzIwMTE+PEZPTlQgZmFjZT3lrovkvZMgDQogIHNpemU9Mj4tWGlhb2hvbmc8L0ZPTlQ+PC9T UEFOPjwvRElWPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5vcGVuIHNv dXJjZSBQQ1AgQ2xpZW50LDwvRk9OVD48L0RJVj4NCiAgPERJViBhbGlnbj1sZWZ0PjxGT05UIGZh Y2U95a6L5L2TIHNpemU9Mj5vcGVuIHNvdXJjZSBBK1A8L0ZPTlQ+PC9ESVY+DQogIDxESVYgYWxp Z249bGVmdD48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PEEgDQogIGhyZWY9Imh0dHA6Ly9vcGVu c291cmNldjZ0cmFuc3RlY2hub2xvZ2llcy53ZWVibHkuY29tLyI+aHR0cDovL29wZW5zb3VyY2V2 NnRyYW5zdGVjaG5vbG9naWVzLndlZWJseS5jb20vPC9BPjwvRk9OVD48L0RJVj4NCiAgPERJViBh bGlnbj1sZWZ0PjxGT05UIGZhY2U95a6L5L2TIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01CC3D43.C5D15438-- From asaba@iij.ad.jp Fri Jul 8 00:57:35 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1021F874E for ; Fri, 8 Jul 2011 00:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.32 X-Spam-Level: ** X-Spam-Status: No, score=2.32 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9VRLEeT1eHS for ; Fri, 8 Jul 2011 00:57:34 -0700 (PDT) Received: from omgo.iij.ad.jp (mo00.iij.ad.jp [202.232.30.145]) by ietfa.amsl.com (Postfix) with ESMTP id 469DC21F8741 for ; Fri, 8 Jul 2011 00:57:34 -0700 (PDT) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding;i=asaba@iij.ad.jp;s=omgo1;t=1310111849;x= 1311321449; bh=LUyWp1S1Vs+BjsQ7GahSk6e9tEhRFcW0HEg/QnQdVjM=; b=Tcd5pzDwHsqNl+r1 GateYuEyx2cWzuZP2tN9+VgZOh9cPh2hlcvn7CmftZ6BtP43BA9HkPNAcs/N2lZCeSeSHNe2MNWl9 +XKqaBApPYYLHGQpSIedyQm/t07BK36YCZ10z8nwnM4o2DOtuiEPiYFEahEFdJu8Z3z6WyT0UcwwW 4=; Received: by omgo.iij.ad.jp (mo00) id p687vT0f016252; Fri, 8 Jul 2011 16:57:29 +0900 Date: Fri, 08 Jul 2011 16:57:26 +0900 (JST) Message-Id: <20110708.165726.74661024.asaba@iij.ad.jp> To: softwires@ietf.org, softwire-chairs@tools.ietf.org From: Toshiya Asaba In-Reply-To: <20110708.143700.407454645627535350.tsahara@iij.ad.jp> References: <4E1529C4.4000800@cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> <20110708.143700.407454645627535350.tsahara@iij.ad.jp> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:57:35 -0000 +1 Operators love to keep stateless options for simple and robust operations. cheers! asaba > +1 > Stateless protocols are easy to implement. > = > = > Thanks, > Tomoyuki > = > >From: > >Date: Thu, Jul 7, 2011 at 5:03 PM > >Subject: Re: [Softwires] Next step for Stateless Motivations I-D > > > > > >+1 > > > >Cheers, > >Xiaohong. > > > >open source PCP Client, > >open source A+P > >http://opensourcev6transtechnologies.weebly.com/ > > > >| > >|+1 > >| > >|Tetsuya Murakami wrote: > >|> +1 > >|> > >|> On 2011/07/06, at 8:23, GangChen wrote: > >|> > >|>> +1 > >|>> > >|>> > >|>> 2011/7/6, Lee, Yiu: > >|>>> +1 > >|>>> > >|>>> On 7/6/11 10:33 AM, "Rajiv Asati > >|(rajiva)" =A0wrote: > >|>>> > >|>>>> Support. > >|>>>> > >|>>>> Cheers, > >|>>>> Rajiv > >|>>>> > >|>>>> > >|>>>>> -----Original Message----- > >|>>>>> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] > >|>>>>> Sent: Friday, June 17, 2011 2:32 AM > >|>>>>> To: > >|>>>>> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; > >|Lee, Yiu; > >|>>>>> Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; > >|>>>> chengang@chinamobile.com > >|>>>>> Subject: Re: Next step for Stateless Motivations I-D > >|>>>>> > >|>>>>> Dear Softwires Working Group chairs, > >|>>>>> > >|>>>>> I support that an request from Mohamed to make WG adoption as= > >|>>>> appropriate > >|>>>>> charter item. > >|>>>>> I'm looking forward you to take your kind adoption procedure = for > >|>>>>> the > >|>>>> request. > >|>>>>> > >|>>>>> Sincerely yours, > >|>>>>> > >|>>>>> -- > >|>>>>> Satoru Matsushima > >|>>>>> > >|>>>>> > >|>>>>> On 2011/06/10, at 20:31, > >|>>>>> =A0wrote: > >|>>>>> > >|>>>>>> Dear all, > >|>>>>>> > >|>>>>>> An updated version of the "Motivations for Stateless IPv4 ov= er > >|>>>>>> IPv6 > >|>>>>> Migration Solutions" I-D has been submitted. The document is > >|>>>>> available > >|>>>> at: > >|>>>>>> > >|http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6 > >|>>>>>> - > >|>>>>> motivation-02 > >|>>>>>> > >|>>>>>> This document has been largely reviewed and inputs from othe= r > >|>>>> contributors > >|>>>>> has been taken into account. > >|>>>>>> > >|>>>>>> Together with my co-authors, we ask the working group > >|to consider > >|>>>> the > >|>>>>> adoption of this document as a WG I-D. > >|>>>>>> > >|>>>>>> Comments and suggestions are more than welcome. > >|>>>>>> > >|>>>>>> Cheers, > >|>>>>>> Med > >|>>>> > >|>>> > >|>>> _______________________________________________ > >|>>> 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 ichiroumakino@gmail.com Fri Jul 8 01:37:16 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DFC21F85B4 for ; Fri, 8 Jul 2011 01:37:16 -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=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K4u1O4zBGBk for ; Fri, 8 Jul 2011 01:37:15 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA76B21F85A8 for ; Fri, 8 Jul 2011 01:37:11 -0700 (PDT) Received: by bwb17 with SMTP id 17so1799081bwb.31 for ; Fri, 08 Jul 2011 01:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WrEqSxMLgKKqzw8WZnM34fA0PuIppaqnHtSlslTQMAc=; b=toU+D5gKHH3/Ctja9V7uHVUJ6NEaVa34ZXlqG7/eLZ7fpHZrzD3awipmRsghE/AMZY lISH0iUj00JP6twYRIqXvrlQkm4sa9ACSjTL0CP5hlm4qkm3BQcYDlamXjehYPG8JygB k+3LMOcbdsKQH77YnMaN5VGhwUXXIWaAkFJNA= Received: by 10.204.40.201 with SMTP id l9mr257893bke.382.1310114230506; Fri, 08 Jul 2011 01:37:10 -0700 (PDT) Received: from [192.168.2.102] (ip-98-56-72-178.dialup.ice.net [178.72.56.98]) by mx.google.com with ESMTPS id zy11sm148455bkb.53.2011.07.08.01.37.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 01:37:08 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> Date: Fri, 8 Jul 2011 10:37:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <14036D61-265A-4550-8706-4E15FE1967B0@employees.org> References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com><27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> <4E1529C4.4000800@cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Preparation for a discussion on 'stateless motivations' at the Quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:37:16 -0000 Dear So-Called chairs, (you did ask for that one! ;-)) > Following up on the 'stateless' thread from a wg chair perspective. >=20 > Yong and I are preparing a discussion FOR the Quebec meeting on the = so-called stateless solution. >=20 > There are a number of points in the current draft that need = discussion. >=20 > For example, no logging has been presented as a strong reason to do = sateless. However, no logging can be achieved > with static port allocation on a centralized NAT. On this particular = logging point, there are no obvious differences between the > 'distributed on CPE' NAT solution and the centralized NAT solution. indeed you can. then you loose the benefit of the stateful solution of = offering port entropy. the important points for the stateless solutions are: - direct CE to CE traffic (statful is hub and spoke) architecture - no new state to be maintained, or recovered, or scaled for in the = network - implicitly does prefix delegation, full or shared IPv4 address = provisioning > More generally, it seems that what is described as a 'stateless' = solution should be characterized as a > 'distributed state' solution. As such, the tradeoff of maintaining the = state centrally vs globally > needs to be analyzed. see 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). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as = possible." the stateful solutions add new state in the middle of the network. this = state has to be maintained and recovered in case of failure. the stateless solution does not. when we refer to 'state' here, we are = talking about state in the network. you can argue if a CE is the real = end point or not, regardless the stateless class of solutions do not = introduce any _new_ state. > Also, it is not clear from this document which set of issues listed in = RFC6269 are mitigated and which ones are not. > In particular, I'd hold that a so-called 'stateless' solution does not = change anything about the recommendations in RFC6302/BCP162 > that are derived from RFC6269... the stateless solutions on the table can do more than just address = sharing. but, to your point. all solutions that we are discussing for = prolonging the life of IPv4 are based on address sharing. the issues = discussed apply to all the IPv4 address sharing mechanisms, doesn't = it?CGNs (NAT444 or DS-lite) or A+P variants. > We, chairs, would like to prepare a 'organized' discussion around = these points (and others). We need a small number of > volunteers to help frame this discussion. Please contact me and Yong = directly if you want to help. > This is an important topic, and we intend to make sure there is ample = time for discussion in Quebec. I don't understand what is asked for here? or how a small number of = volunteers are going to 'frame' the discussion? does it mean 5 of us = sitting on Randy so he doesn't get to the mike? I'm happy to volunteer = then. ;-) appears to me we are having the discussion on the mailing list. based on = what has been posted to this thread(s) and the discussion at the last = IETF meeting, let us accept the draft as a working group item, and start = working on it as a wg. the draft more than justifies why a stateless = solution is needed, I don't want to see us spend the discussion time in = Quebec on state versus no state. the Internet community made that choice = when I was still in diapers. cheers, Ole= From satoru.matsushima@gmail.com Fri Jul 8 01:37:47 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AFF21F86D1 for ; Fri, 8 Jul 2011 01:37:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENPLU57zMFej for ; Fri, 8 Jul 2011 01:37:46 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9921F86C2 for ; Fri, 8 Jul 2011 01:37:46 -0700 (PDT) Received: by pwj5 with SMTP id 5so305272pwj.31 for ; Fri, 08 Jul 2011 01:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=g2BkaYApYTL9edfRuhoaBHXSf1Z6f4+qTckL97QjHig=; b=H4BfJQu0PX+UAeNXqaE4HKGWtqj2aYZTVuGvi8NGOOf3X3BKZOhZHb4HuJ+1bFmZAT cNaymTPa/BR92d3yu3M1kxv98KflHo6SomEn2LmQT7T/SDpH6mBjYRmsRX4vG653lwWA s5E0WNQDfsT8m388nhV/zPifRlFf2XX2T1m0M= Received: by 10.68.37.41 with SMTP id v9mr2500303pbj.80.1310114266019; Fri, 08 Jul 2011 01:37:46 -0700 (PDT) Received: from [10.201.81.48] ([202.45.12.174]) by mx.google.com with ESMTPS id p7sm4301321pbn.65.2011.07.08.01.37.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 01:37:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <70C5EDAE-4297-47AB-B749-1B749450975E@townsley.net> Date: Fri, 8 Jul 2011 17:37:40 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067E6CE33034954AAC05C9EC85E2577C0560A343@XMB-RCD-111.cisco.com><27C844E0-A887-42D4-9E8C-4C03C74B4BA9@ipinfusion.com> <4E1529C4.4000800@cisco.com> <0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr> <6725CA98-8153-41AE-B83A-9FC4A2243A99@juniper.net> <70C5EDAE-4297-47AB-B749-1B749450975E@townsley.net> To: Townsley Mark , Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Preparation for a discussion on 'stateless motivations' at the Quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:37:47 -0000 On 2011/07/08, at 2:16, Mark Townsley wrote: >=20 > Sure, based on your review of the document that's fine. But, not "the = thread from a WG chair perspective" as stated above. That's ridiculous. >=20 I hope that the chair take adoption to be a WG document. Please discriminate your chair role from your personal technical view. >> For example, no logging has been presented as a strong reason to do = sateless. However, no logging can be achieved >> with static port allocation on a centralized NAT. On this particular = logging point, there are no obvious differences between the >> 'distributed on CPE' NAT solution and the centralized NAT solution. >=20 > As you point out, the "no logging" part is really a function of the = use of a static mapping to a range of ports. Any centralized NAPT = function can use static mapping. When you use static mapping, then you = get all the pros and cons that go along with it. >=20 >> More generally, it seems that what is described as a 'stateless' = solution should be characterized as a >> 'distributed state' solution. As such, the tradeoff of maintaining = the state centrally vs globally >> needs to be analyzed. >=20 > "stateless operation" if you prefer. The point is that within the ISP = network, there is no per-flow state that resides on any single endpoint = running the protocol in question. So, config can be static, and BRs can = be reached via anycast. That's the heart of a stateless solution. Just = like 6rd, if you will.=20 Good point. 'no per-flow state' is goodness for redundancy, = load-sharing, etc., These are usual expectations of IP network = operations. >=20 >> Also, it is not clear from this document which set of issues listed = in RFC6269 are mitigated and which ones are not. >> In particular, I'd hold that a so-called 'stateless' solution does = not change anything about the recommendations in RFC6302/BCP162 >> that are derived from RFC6269... The draft explains motivation of stateless solution for ISP networks = where are going to share IPv4 address. Consequence of server side should = be same with other solutions. -- snip -- >=20 > Section 18: Single Points of Failure - here, stateless wins pretty = much hands down as it is not introducing any new single points of = failure. >=20 Yes. > Perhaps there are a few more, but "most" should be insignificant by = the own document's admission. >=20 Agree. >> We, chairs, would like to prepare a 'organized' discussion around = these points (and others). We need a small number of >> volunteers to help frame this discussion. Please contact me and Yong = directly if you want to help. >> This is an important topic, and we intend to make sure there is ample = time for discussion in Quebec. >=20 > Why don't we just discuss it on the list and have a consensus call = instead? >=20 > If we had a thread of 200 messages as we did for moving 6to4 to = historic, OK maybe we need to have a big coordinated discussion. But, = I'm not seeing anything on the thread here that would suggest that we = need to spend a lot of time preparing some big discussion among a group = of people you and Yong select.=20 Again, would you take appropriate procedure for the adoption? Best regards, --satoru From pacosaddress@googlemail.com Fri Jul 8 01:49:25 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F10621F85D6 for ; Fri, 8 Jul 2011 01:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4xidx-3XTJL for ; Fri, 8 Jul 2011 01:49:24 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 228FD21F877E for ; Fri, 8 Jul 2011 01:49:23 -0700 (PDT) Received: by iye7 with SMTP id 7so1945928iye.31 for ; Fri, 08 Jul 2011 01:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=p+TuOJV9+zvfI1e37BTEiBJGgLSWR5n0hfnYnjRe1bk=; b=wde/UwSeaBS+P2CTPMLTMGj5QcJvhdXMRYyE1muflaIPhd5yAIxLcg6uPH/VR1Iaxu NYaEfVj9F/x6ybD5AHusM058UYECHJMI40LoYUKnmmxbWytNjEjl6w9LnFjCXYWXbK+y s/+eNPbqY31N9L7Yzb+cQCx8mK9kirXIMJkt8= MIME-Version: 1.0 Received: by 10.42.2.212 with SMTP id 20mr1904742icl.318.1310114960037; Fri, 08 Jul 2011 01:49:20 -0700 (PDT) Received: by 10.231.180.79 with HTTP; Fri, 8 Jul 2011 01:49:19 -0700 (PDT) In-Reply-To: References: <0D212BD466921646B58854FB79092CEC062753AF@XMB-AMS-106.cisco.com> Date: Fri, 8 Jul 2011 10:49:19 +0200 Message-ID: From: Paco Cortes To: "Lee, Yiu" , Jim Guichard , "Frank Brockners (fbrockne)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 08:49:25 -0000 Hi Yiu, I believe that the conclusion of the discussion between Jim and me is that the following bullet should be added to section 6: o IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID might be the next MP= LS label in the stack, if present, or the AD's IP address. What do you think of it? In your suggested text, I find the usage of the term "context" confusing. It is already well defined in the draft what a CID is. And the text "if the AFTR is the last hop of the LSP" is redundant, isn't i= t? br, Paco 2011/7/7 Lee, Yiu : > Hi Frank, > > Did Jim and Paco metnion to also allow IP for the CID? So, I suggest to > modify Section 6: > > Section 6: > > - add the following bullet: > =A0 o =A0IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID is the next M= PLS > label in the stack or IPv4 address if the AFTR is the last hop of the LSP= . > The AFTR may use the CID locally to identify context within a given > inbound softwire. > > > > On 7/7/11 5:52 PM, "Frank Brockners (fbrockne)" wrot= e: > >> >>Works for me (and thanks for the suggested text). If I don't hear >>otherwise, I'll post an -05 version by tomorrow including Jim's >>suggestions. >> >>Thanks, Frank >> >>> -----Original Message----- >>> From: Jim Guichard [mailto:jguichard@juniper.net] >>> Sent: Thursday, July 07, 2011 6:54 AM >>> To: Paco Cortes >>> Cc: softwires@ietf.org; Frank Brockners (fbrockne) >>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>> >>> Yes, I agree that this change makes sense and provides more >>flexibility >>> .. >>> thanks >>> >>> On 7/7/11 9:48 AM, "Paco Cortes" wrote: >>> >>> >Thanks Jim, now I get it. >>> >You were aiming at (outer label=3D SWID; inner label =3D CID), and I >>> >misunderstood it as (outer label =3D SWID, inner label =3D something_n= ew; >>> >IP @ =3D CID). >>> >Speaking about "vanilla MPLS" I was actually expecting (only label =3D >>> >SWID; IP @ =3D CID) >>> > >>> >It sounds sensible to me. >>> >But do you really want to restrict the vanilla MPLS case to (outer >>> >label =3D SWID, inner label =3D CID)? In such case, the user IP@ is pu= re >>> >overhead. >>> > >>> >Wouldn't it be better to cover both cases in one go? This could be >>> >done with a change like: >>> > >>> >- SWID is the top MPLS label. CID might be the next MPLS >>> >label in the stack, if present, or the AD's IP address. >>> > >>> >But don't take this email as an opposition to your last proposal to >>> >Frank. If nobody is interested on (single label=3DSWID, IP@=3DCID), th= en >>I >>> >will not be the one pushing for it. >>> > >>> >br, >>> > =A0Paco >>> > >>> > >>> > >>> > >>> > >>> >2011/7/7 Jim Guichard : >>> >> Hi Paco, >>> >> >>> >> Comments inline .. >>> >> >>> >> On 7/7/11 3:39 AM, "Paco Cortes" >>> wrote: >>> >> >>> >>>Hi Jim, >>> >>> >>> >>>can you clarify with the upper case part of your proposal? >>> >>> >>> >>> =A0o =A0IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT >>WITHIN >>> >>>swid >>> >>>MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK. >>> >>> >>> >>>You are speaking about a fully different case than the "MPLS VPN" >>> case >>> >>>currently in the draft, where the VPN label (i.e. the inner MPLS >>> >>>label) is the SWID. >>> >>>To me it sounds like a very significant change to gi-ds-lite, as >>you >>> >>>seem to be proposing that traffic inside a softwire can be further >>> >>>"split" into contexts with some meaning (differentiated handling?) >>> by >>> >>>the AFTR. >>> >> >>> >> Jim> yes, exactly this. In this case the SWID is the top label and >>> the >>> >> next label in the stack is the CID. >>> >> >>> >>> >>> >>>Regarding the overall discussion in this thread (sorry I didn't >>> answer >>> >>>earlier), I disagree on the MPLS VPN case to be an overkill. In >>many >>> >>>cases, the one-label overhead in part of the path is fully >>justified >>> >>>by the gained operational simplicity (given by relaying on MP-BGP >>> and >>> >>>possibly CE-PE protocol for "softwire" setup and control >>> signalling). >>> >>>Also, as already mentioned by Yiu, it enables a very simple >>> >>>implementation of overlapping IP addresses. Although this could >>also >>> >>>be possible with your "vanilla MPLS" proposal, it would require >>some >>> >>>kind of additional (proprietary?) implementation both in Gateway >>and >>> >>>AFTR. >>> >> >>> >> Jim> let me clarify .. I completely agree that VPN should be >>> included. >>> >>My >>> >> overkill comment was more to do with the fact that in some >>> situations it >>> >> is not necessary to deploy the full MPLS VPN machinery. >>> >>> >>> >>>This said, I do see the point on adding "vanilla MPLS" as possible >>> >>>embodiment to the draft. There may be simple scenarios where it is >>> >>>fully sufficient. >>> >>>Maybe adding a bullet to section 6 like: >>> >>> >>> >>> =A0o =A0IPv4/IPv6-in-MPLS: SWID is the MPLS label. >>> >>> >>> >>>Would this be ok for you? >>> >> >>> >> Jim> I would like to see SWID =3D top label, CID =3D next label in >>stack >>> >> noting that the SWID label is not PHP. >>> >>> >>> >>>br, >>> >>> =A0Paco >>> >>> >>> >>> >>> >>>2011/7/6 Frank Brockners (fbrockne) : >>> >>>> Hi Jim, >>> >>>> >>> >>>> ... works for me (any additional opinions from others?). >>> >>>> >>> >>>> In order to get a -05 version out quickly, could you detail the >>> >>>>change - >>> >>>> i.e. possibly expand the bullet you propose below with some >>> additional >>> >>>> explanation, like e.g. what would be used as CID for "vanilla >>> MPLS"; >>> >>>> propose another row for the table in section 6; etc. >>> >>>> >>> >>>> Once we have this, we could quickly compile a -05. >>> >>>> >>> >>>> Thanks, Frank >>> >>>> >>> >>>>> -----Original Message----- >>> >>>>> From: Jim Guichard [mailto:jguichard@juniper.net] >>> >>>>> Sent: Wednesday, July 06, 2011 6:24 AM >>> >>>>> To: Jim Guichard; Frank Brockners (fbrockne) >>> >>>>> Cc: softwires@ietf.org >>> >>>>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds- >>> list-02 >>> >>>>> >>> >>>>> Hi Frank, >>> >>>>> >>> >>>>> Reviewing version 04 of the draft I still do not see "vanilla" >>> MPLS >>> >>>>> encapsulation given as an option. I would like to suggest adding >>> >>>>> something >>> >>>>> like the following to section 6: >>> >>>>> >>> >>>>> =A0 =A0o =A0IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Cont= ext >>> within >>> >>>>> SWID >>> >>>>> may be indicated by the next MPLS label in the stack. >>> >>>>> >>> >>>>> >>> >>>>> On 3/28/11 1:17 PM, "Jim Guichard" >>wrote: >>> >>>>> >>> >>>>> >Hi Frank, >>> >>>>> > >>> >>>>> >What I would like to see is the ability to use TE without >>VPN's. >>> I >>> >>>>>do >>> >>>>> not >>> >>>>> >want to be forced to deploy VPN infrastructure in this case. >>> RSVP-TE >>> >>>>> is an >>> >>>>> >important piece of the puzzle as it provides the ability to >>> steer >>> >>>>> traffic >>> >>>>> >based upon policy that I may wish to enforce. I would be happy >>> to >>> >>>>> supply >>> >>>>> >text for the draft but would like to agree on this alias before >>> >>>>>doing >>> >>>>> so >>> >>>>> >.. >>> >>>>> > >>> >>>>> >On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >>> >>>>> >>> >>>>> >wrote: >>> >>>>> > >>> >>>>> >> >>> >>>>> >>Jim, >>> >>>>> >> >>> >>>>> >>why is VPN "overkill" (kind of delicate wording these >>days...)? >>> TE >>> >>>>> could >>> >>>>> >>also be combined with MPLS VPNs. >>> >>>>> >> >>> >>>>> >>Would also be interested in other folks' thoughts on the need >>> for >>> >>>>> >>"plain" IP-over-MPLS tunnels. >>> >>>>> >> >>> >>>>> >>Thanks, Frank >>> >>>>> >> >>> >>>>> >>> -----Original Message----- >>> >>>>> >>> From: Jim Guichard [mailto:jguichard@juniper.net] >>> >>>>> >>> Sent: Friday, March 25, 2011 8:03 PM >>> >>>>> >>> To: Frank Brockners (fbrockne) >>> >>>>> >>> Cc: softwires@ietf.org >>> >>>>> >>> Subject: Re: [Softwires] >>> >>>>>draft-ietf-softwire-gateway-init-ds-list- >>> >>>>> 02 >>> >>>>> >>> >>> >>>>> >>> VPN is overkill imho plus i want the ability to engineer >>> traffic >>> >>>>> paths >>> >>>>> >>> and for this i need TE >>> >>>>> >>> >>> >>>>> >>> Jim Guichard >>> >>>>> >>> >>> >>>>> >>> Principal Networking Architect >>> >>>>> >>> IPG CTO Office >>> >>>>> >>> Juniper Networks >>> >>>>> >>> >>> >>>>> >>> CCIE #2069 >>> >>>>> >>> >>> >>>>> >>> Sent from my iphone >>> >>>>> >>> >>> >>>>> >>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >>> >>>>> >>> wrote: >>> >>>>> >>> >>> >>>>> >>> > Hi Jim, >>> >>>>> >>> > >>> >>>>> >>> > fully agreed that MPLS should not be absent from the >>draft, >>> and >>> >>>>> it >>> >>>>> >>is >>> >>>>> >>> > not. The current draft-ietf-softwire-gateway-init-ds-list- >>> 03 >>> >>>>> doesn't >>> >>>>> >>> > restrict things to IP tunneling. The draft already allows >>> for >>> >>>>> MPLS >>> >>>>> >>> > transport between Gateway and AFTR using MPLS VPNs. >>> >>>>> >>> > >>> >>>>> >>> > Hence the question: For the use cases you have in mind, >>> >>>>>couldn't >>> >>>>> we >>> >>>>> >>> just >>> >>>>> >>> > use MPLS VPNs (possibly even point-to-point with just two >>> PEs >>> >>>>>in >>> >>>>> a >>> >>>>> >>> VPN - >>> >>>>> >>> > Gateway and the AFTR)? Personally I've nothing against >>> >>>> additional >>> >>>>> >>> > encapsulations, though so far there's always been a push >>in >>> the >>> >>>>> WG >>> >>>>> >>> (and >>> >>>>> >>> > also in 3GPP SA2) to keep the number of encapsulations to >>a >>> >>>>> minimum >>> >>>>> >>> > (e.g. L2TPv3 was dropped from the list of encaps, because >>> we >>> >>>>> could >>> >>>>> >>do >>> >>>>> >>> > the very same thing with GRE). >>> >>>>> >>> > >>> >>>>> >>> > On multicast: Don't fully follow your thought below. Do >>you >>> >>>>> consider >>> >>>>> >>> > running multicast over the softwire between AFTR and >>> Gateway? >>> >>>> The >>> >>>>> >>> > multicast considerations for GI-DS-lite (see >>> >>>>> >>> > draft-brockners-softwire-mcast-gi-ds-lite-00) so far >>assume >>> >>>>>that >>> >>>>> >>this >>> >>>>> >>> > would not be the case. >>> >>>>> >>> > >>> >>>>> >>> > Thanks, Frank >>> >>>>> >>> > >>> >>>>> >>> >> -----Original Message----- >>> >>>>> >>> >> From: Jim Guichard [mailto:jguichard@juniper.net] >>> >>>>> >>> >> Sent: Thursday, March 24, 2011 9:43 PM >>> >>>>> >>> >> >>> >>>>> >>> >> Hi Frank, >>> >>>>> >>> >> >>> >>>>> >>> >> bi-directional tunnels are necessary if you wish for >>> traffic >>> >>>>> flows >>> >>>>> >>> to >>> >>>>> >>> >> take >>> >>>>> >>> >> the same path in both directions across the network. It >>is >>> >>>>> possible >>> >>>>> >>> to >>> >>>>> >>> >> use >>> >>>>> >>> >> point-to-point but this is cumbersome to deploy. >>> >>>>> >>Point-to-multipoint >>> >>>>> >>> >> may >>> >>>>> >>> >> be necessary for multicast. >>> >>>>> >>> >> >>> >>>>> >>> >> Clearly IP-in-MPLS tunneling is a fundamental requirement >>> that >>> >>>>> >>> should >>> >>>>> >>> >> not >>> >>>>> >>> >> be absent from the draft. If an operator has MPLS why >>> restrict >>> >>>>> them >>> >>>>> >>> to >>> >>>>> >>> >> IP >>> >>>>> >>> >> tunneling? >>> >>>>> >>> >> >>> >>>>> >>> >> >>> >>>>> >>> >>> >>> >>>>> >>> >>> to kick-start the discussion, could you outline the >>usage >>> >>>>> >>scenarios >>> >>>>> >>> >> that >>> >>>>> >>> >>> would drive the requirements you mention below? >>> >>>>> >>> >>> >>> >>>>> >>> > >>> >>>>> > >>> >>>>> >_______________________________________________ >>> >>>>> >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 xiaohong.deng@orange-ftgroup.com Fri Jul 8 02:03:49 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4FA21F8781 for ; Fri, 8 Jul 2011 02:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=1.164, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjLlu+J1fAaJ for ; Fri, 8 Jul 2011 02:03:48 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7025521F872E for ; Fri, 8 Jul 2011 02:03:48 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 880D06FCC09; Fri, 8 Jul 2011 11:11:40 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8067D6FCAFA; Fri, 8 Jul 2011 11:11:40 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 11:03:47 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Jul 2011 17:03:43 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC018A3C6F@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Call for Agenda @ IETF 81 Thread-Index: Acw9TfADTp+7NwTXTq+p3d71Pn/pSg== References: From: To: , , X-OriginalArrivalTime: 08 Jul 2011 09:03:47.0391 (UTC) FILETIME=[F24E84F0:01CC3D4D] Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:03:49 -0000 Dear Chairs, We'd like to present 2 drafts: Xiaohong Deng, draft-zhou-softwire-b4-nat-02, http://www.ietf.org/id/draft-zhou-softwire-b4-nat-02.txt Xiaohong Deng, draft-deng-v6ops-aplusp-experiment-results-01.txt, http://www.ietf.org/id/draft-deng-v6ops-aplusp-experiment-results-01.txt 5 minutes for each slot. Thanks, -Xiaohong open source PCP Client, open source A+P http://opensourcev6transtechnologies.weebly.com/ =20 =20 |-----Original Message----- |From: Yong Cui [mailto:cuiyong@tsinghua.edu.cn]=20 |Sent: Thursday, July 07, 2011 9:37 AM |To: Softwires-wg list |Cc: Yong Cui |Subject: [Softwires] Call for Agenda @ IETF 81 | |Hi guys, | |If you are planing to present something in the Softwire WG in=20 |Quebec City, please send your agenda item requests to Alain=20 |and me by 7/12 in the following format: |(presenter's name, draft name, ietf link) | |We also need your slides by Saturday 7/23 (before the meeting starts). | |Thanks. | |- Alain & Yong. | | | | From mkohno@juniper.net Fri Jul 8 02:44:24 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBF021F8770 for ; Fri, 8 Jul 2011 02:44:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OG2KT9jMH5U for ; Fri, 8 Jul 2011 02:44:23 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 48EBD21F861D for ; Fri, 8 Jul 2011 02:44:23 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKThbRcHEicg+VsVAW2nWa8N/IDFLqRpqN@postini.com; Fri, 08 Jul 2011 02:44:23 PDT Received: from EmailHK1.jnpr.net (172.27.128.41) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server id 8.2.254.0; Fri, 8 Jul 2011 02:42:35 -0700 Received: from EMAILHK2.jnpr.net ([172.27.128.49]) by EmailHK1.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jul 2011 17:42:32 +0800 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: Fri, 8 Jul 2011 17:42:20 +0800 Message-ID: In-Reply-To: <20110708.165726.74661024.asaba@iij.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Next step for Stateless Motivations I-D thread-index: Acw9RMlOJEg99aAUQSWfSJwD7IaZdgADhGNw References: <4E1529C4.4000800@cisco.com><0962B0BEF842A24191AD9BE41A8DD2FC01869A74@ch-mailsrv.rd.francetelecom.fr><20110708.143700.407454645627535350.tsahara@iij.ad.jp> <20110708.165726.74661024.asaba@iij.ad.jp> From: Miya Kohno To: Toshiya Asaba , , X-OriginalArrivalTime: 08 Jul 2011 09:42:32.0869 (UTC) FILETIME=[5C664D50:01CC3D53] Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:44:24 -0000 +1 I see no reason to eliminate this option.=20 Miya > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On > Behalf Of Toshiya Asaba > Sent: Friday, July 08, 2011 4:57 PM > To: softwires@ietf.org; softwire-chairs@tools.ietf.org > Subject: Re: [Softwires] Next step for Stateless Motivations I-D >=20 >=20 > +1 >=20 > Operators love to keep stateless options for simple and robust > operations. >=20 > cheers! > asaba >=20 > > +1 > > Stateless protocols are easy to implement. > > > > > > Thanks, > > Tomoyuki > > > > >From: > > >Date: Thu, Jul 7, 2011 at 5:03 PM > > >Subject: Re: [Softwires] Next step for Stateless Motivations I-D > > > > > > > > >+1 > > > > > >Cheers, > > >Xiaohong. > > > > > >open source PCP Client, > > >open source A+P > > >http://opensourcev6transtechnologies.weebly.com/ > > > > > >| > > >|+1 > > >| > > >|Tetsuya Murakami wrote: > > >|> +1 > > >|> > > >|> On 2011/07/06, at 8:23, GangChen wrote: > > >|> > > >|>> +1 > > >|>> > > >|>> > > >|>> 2011/7/6, Lee, Yiu: > > >|>>> +1 > > >|>>> > > >|>>> On 7/6/11 10:33 AM, "Rajiv Asati > > >|(rajiva)" =A0wrote: > > >|>>> > > >|>>>> Support. > > >|>>>> > > >|>>>> Cheers, > > >|>>>> Rajiv > > >|>>>> > > >|>>>> > > >|>>>>> -----Original Message----- > > >|>>>>> From: Satoru Matsushima [mailto:satoru.matsushima@gmail.com] > > >|>>>>> Sent: Friday, June 17, 2011 2:32 AM > > >|>>>>> To: > > >|>>>>> Cc: Satoru Matsushima; Softwires-wg; 'Softwire Chairs'; > > >|Lee, Yiu; > > >|>>>>> Olaf.Bonness@telekom.de; Isabel@ptinovacao.pt; > > >|>>>> chengang@chinamobile.com > > >|>>>>> Subject: Re: Next step for Stateless Motivations I-D > > >|>>>>> > > >|>>>>> Dear Softwires Working Group chairs, > > >|>>>>> > > >|>>>>> I support that an request from Mohamed to make WG adoption = as > > >|>>>> appropriate > > >|>>>>> charter item. > > >|>>>>> I'm looking forward you to take your kind adoption procedure = for > > >|>>>>> the > > >|>>>> request. > > >|>>>>> > > >|>>>>> Sincerely yours, > > >|>>>>> > > >|>>>>> -- > > >|>>>>> Satoru Matsushima > > >|>>>>> > > >|>>>>> > > >|>>>>> On 2011/06/10, at = 20:31, > > >|>>>>> =A0wrote: > > >|>>>>> > > >|>>>>>> Dear all, > > >|>>>>>> > > >|>>>>>> An updated version of the "Motivations for Stateless IPv4 = over > > >|>>>>>> IPv6 > > >|>>>>> Migration Solutions" I-D has been submitted. The document is > > >|>>>>> available > > >|>>>> at: > > >|>>>>>> > > >|http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6 > > >|>>>>>> - > > >|>>>>> motivation-02 > > >|>>>>>> > > >|>>>>>> This document has been largely reviewed and inputs from = other > > >|>>>> contributors > > >|>>>>> has been taken into account. > > >|>>>>>> > > >|>>>>>> Together with my co-authors, we ask the working group > > >|to consider > > >|>>>> the > > >|>>>>> adoption of this document as a WG I-D. > > >|>>>>>> > > >|>>>>>> Comments and suggestions are more than welcome. > > >|>>>>>> > > >|>>>>>> Cheers, > > >|>>>>>> Med > > >|>>>> > > >|>>> > > >|>>> _______________________________________________ > > >|>>> 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 wdec.ietf@gmail.com Fri Jul 8 03:19:47 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7652121F8900 for ; Fri, 8 Jul 2011 03:19:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hKfk23IyfPt for ; Fri, 8 Jul 2011 03:19:46 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1908C21F88E6 for ; Fri, 8 Jul 2011 03:19:46 -0700 (PDT) Received: by pvh18 with SMTP id 18so1459127pvh.31 for ; Fri, 08 Jul 2011 03:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZasENsUf2NSy3jgmHWjsYRaeOD/1wCQA77KtYCVzCOc=; b=Ogi1YCk79KiEwom7ew7vDb7OEAd1WSgKuM6ewHewedAHGBaxZIDNnxMXSFe8hHTprS 8cRo5K0+6P9IOMgTNpuaoRqKxBfs0nKRjUxyXZLbmekQmrWbvO8dT3WrVTg08tDjmQrg X+8uWbKC/Wg7Rg+yqBSQkJDffg8MlKjkCGVNk= MIME-Version: 1.0 Received: by 10.142.248.30 with SMTP id v30mr220174wfh.27.1310120385593; Fri, 08 Jul 2011 03:19:45 -0700 (PDT) Received: by 10.142.136.8 with HTTP; Fri, 8 Jul 2011 03:19:45 -0700 (PDT) In-Reply-To: References: <94C682931C08B048B7A8645303FDC9F33E50162622@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 8 Jul 2011 12:19:45 +0200 Message-ID: From: Wojciech Dec To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires-wg , "Isabel@ptinovacao.pt" , "chengang@chinamobile.com" , Softwire Chairs Subject: Re: [Softwires] Next step for Stateless Motivations I-D X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 10:19:47 -0000 +1 -Wojtek. On 17 June 2011 08:32, Satoru Matsushima wrote: > Dear Softwires Working Group chairs, > > I support that an request from Mohamed to make WG adoption as appropriate charter item. > I'm looking forward you to take your kind adoption procedure for the request. > > Sincerely yours, > > -- > Satoru Matsushima > > > On 2011/06/10, at 20:31, wrote: > >> Dear all, >> >> An updated version of the "Motivations for Stateless IPv4 over IPv6 Migration Solutions" I-D has been submitted. The document is available at: >> http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02 >> >> This document has been largely reviewed and inputs from other contributors has been taken into account. >> >> Together with my co-authors, we ask the working group to consider the adoption of this document as a WG I-D. >> >> Comments and suggestions are more than welcome. >> >> Cheers, >> Med > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From jguichard@juniper.net Fri Jul 8 05:16:38 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C287721F892E for ; Fri, 8 Jul 2011 05:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TxWtRrttTCL for ; Fri, 8 Jul 2011 05:16:37 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 012D121F8991 for ; Fri, 8 Jul 2011 05:16:35 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKThb1IlbgNCl7EZt2OKSTgO/6VKoKkPMQ@postini.com; Fri, 08 Jul 2011 05:16:37 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 8 Jul 2011 05:14:15 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 8 Jul 2011 08:14:15 -0400 From: Jim Guichard To: Paco Cortes Date: Fri, 8 Jul 2011 08:12:37 -0400 Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: Acw9aI231VBVP3JlQg6GBGOUxAVcUQ== Message-ID: References: <0D212BD466921646B58854FB79092CEC062753AF@XMB-AMS-106.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 12:16:38 -0000 I think the other necessary change is for section 5. Could you agree to cha= nge the 1st bullet to allow for dynamic establishment of softwires? It seem= s restrictive to mandate that they be pre-established. Jim Guichard Principal Networking Architect IPG CTO Office Juniper Networks CCIE #2069 Sent from my iphone On Jul 8, 2011, at 4:49, "Paco Cortes" wrote: > Hi Yiu, >=20 > I believe that the conclusion of the discussion between Jim and me is > that the following bullet should be added to section 6: >=20 > o IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID might be the next M= PLS > label in the stack, if present, or the AD's IP address. >=20 > What do you think of it? > In your suggested text, I find the usage of the term "context" > confusing. It is already well defined in the draft what a CID is. > And the text "if the AFTR is the last hop of the LSP" is redundant, isn't= it? >=20 > br, > Paco >=20 >=20 > 2011/7/7 Lee, Yiu : >> Hi Frank, >>=20 >> Did Jim and Paco metnion to also allow IP for the CID? So, I suggest to >> modify Section 6: >>=20 >> Section 6: >>=20 >> - add the following bullet: >> o IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID is the next MPLS >> label in the stack or IPv4 address if the AFTR is the last hop of the LS= P. >> The AFTR may use the CID locally to identify context within a given >> inbound softwire. >>=20 >>=20 >>=20 >> On 7/7/11 5:52 PM, "Frank Brockners (fbrockne)" wro= te: >>=20 >>>=20 >>> Works for me (and thanks for the suggested text). If I don't hear >>> otherwise, I'll post an -05 version by tomorrow including Jim's >>> suggestions. >>>=20 >>> Thanks, Frank >>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard [mailto:jguichard@juniper.net] >>>> Sent: Thursday, July 07, 2011 6:54 AM >>>> To: Paco Cortes >>>> Cc: softwires@ietf.org; Frank Brockners (fbrockne) >>>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >>>>=20 >>>> Yes, I agree that this change makes sense and provides more >>> flexibility >>>> .. >>>> thanks >>>>=20 >>>> On 7/7/11 9:48 AM, "Paco Cortes" wrote: >>>>=20 >>>>> Thanks Jim, now I get it. >>>>> You were aiming at (outer label=3D SWID; inner label =3D CID), and I >>>>> misunderstood it as (outer label =3D SWID, inner label =3D something_= new; >>>>> IP @ =3D CID). >>>>> Speaking about "vanilla MPLS" I was actually expecting (only label = =3D >>>>> SWID; IP @ =3D CID) >>>>>=20 >>>>> It sounds sensible to me. >>>>> But do you really want to restrict the vanilla MPLS case to (outer >>>>> label =3D SWID, inner label =3D CID)? In such case, the user IP@ is p= ure >>>>> overhead. >>>>>=20 >>>>> Wouldn't it be better to cover both cases in one go? This could be >>>>> done with a change like: >>>>>=20 >>>>> - SWID is the top MPLS label. CID might be the next MPLS >>>>> label in the stack, if present, or the AD's IP address. >>>>>=20 >>>>> But don't take this email as an opposition to your last proposal to >>>>> Frank. If nobody is interested on (single label=3DSWID, IP@=3DCID), t= hen >>> I >>>>> will not be the one pushing for it. >>>>>=20 >>>>> br, >>>>> Paco >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> 2011/7/7 Jim Guichard : >>>>>> Hi Paco, >>>>>>=20 >>>>>> Comments inline .. >>>>>>=20 >>>>>> On 7/7/11 3:39 AM, "Paco Cortes" >>>> wrote: >>>>>>=20 >>>>>>> Hi Jim, >>>>>>>=20 >>>>>>> can you clarify with the upper case part of your proposal? >>>>>>>=20 >>>>>>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. CONTEXT >>> WITHIN >>>>>>> swid >>>>>>> MAY BE INDICATED BY THE NEXT mpls LABEL IN THE STACK. >>>>>>>=20 >>>>>>> You are speaking about a fully different case than the "MPLS VPN" >>>> case >>>>>>> currently in the draft, where the VPN label (i.e. the inner MPLS >>>>>>> label) is the SWID. >>>>>>> To me it sounds like a very significant change to gi-ds-lite, as >>> you >>>>>>> seem to be proposing that traffic inside a softwire can be further >>>>>>> "split" into contexts with some meaning (differentiated handling?) >>>> by >>>>>>> the AFTR. >>>>>>=20 >>>>>> Jim> yes, exactly this. In this case the SWID is the top label and >>>> the >>>>>> next label in the stack is the CID. >>>>>>=20 >>>>>>>=20 >>>>>>> Regarding the overall discussion in this thread (sorry I didn't >>>> answer >>>>>>> earlier), I disagree on the MPLS VPN case to be an overkill. In >>> many >>>>>>> cases, the one-label overhead in part of the path is fully >>> justified >>>>>>> by the gained operational simplicity (given by relaying on MP-BGP >>>> and >>>>>>> possibly CE-PE protocol for "softwire" setup and control >>>> signalling). >>>>>>> Also, as already mentioned by Yiu, it enables a very simple >>>>>>> implementation of overlapping IP addresses. Although this could >>> also >>>>>>> be possible with your "vanilla MPLS" proposal, it would require >>> some >>>>>>> kind of additional (proprietary?) implementation both in Gateway >>> and >>>>>>> AFTR. >>>>>>=20 >>>>>> Jim> let me clarify .. I completely agree that VPN should be >>>> included. >>>>>> My >>>>>> overkill comment was more to do with the fact that in some >>>> situations it >>>>>> is not necessary to deploy the full MPLS VPN machinery. >>>>>>>=20 >>>>>>> This said, I do see the point on adding "vanilla MPLS" as possible >>>>>>> embodiment to the draft. There may be simple scenarios where it is >>>>>>> fully sufficient. >>>>>>> Maybe adding a bullet to section 6 like: >>>>>>>=20 >>>>>>> o IPv4/IPv6-in-MPLS: SWID is the MPLS label. >>>>>>>=20 >>>>>>> Would this be ok for you? >>>>>>=20 >>>>>> Jim> I would like to see SWID =3D top label, CID =3D next label in >>> stack >>>>>> noting that the SWID label is not PHP. >>>>>>>=20 >>>>>>> br, >>>>>>> Paco >>>>>>>=20 >>>>>>>=20 >>>>>>> 2011/7/6 Frank Brockners (fbrockne) : >>>>>>>> Hi Jim, >>>>>>>>=20 >>>>>>>> ... works for me (any additional opinions from others?). >>>>>>>>=20 >>>>>>>> In order to get a -05 version out quickly, could you detail the >>>>>>>> change - >>>>>>>> i.e. possibly expand the bullet you propose below with some >>>> additional >>>>>>>> explanation, like e.g. what would be used as CID for "vanilla >>>> MPLS"; >>>>>>>> propose another row for the table in section 6; etc. >>>>>>>>=20 >>>>>>>> Once we have this, we could quickly compile a -05. >>>>>>>>=20 >>>>>>>> Thanks, Frank >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Jim Guichard [mailto:jguichard@juniper.net] >>>>>>>>> Sent: Wednesday, July 06, 2011 6:24 AM >>>>>>>>> To: Jim Guichard; Frank Brockners (fbrockne) >>>>>>>>> Cc: softwires@ietf.org >>>>>>>>> Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds- >>>> list-02 >>>>>>>>>=20 >>>>>>>>> Hi Frank, >>>>>>>>>=20 >>>>>>>>> Reviewing version 04 of the draft I still do not see "vanilla" >>>> MPLS >>>>>>>>> encapsulation given as an option. I would like to suggest adding >>>>>>>>> something >>>>>>>>> like the following to section 6: >>>>>>>>>=20 >>>>>>>>> o IPv4/IPv6-in-MPLS: SWID is the outer MPLS label. Context >>>> within >>>>>>>>> SWID >>>>>>>>> may be indicated by the next MPLS label in the stack. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 3/28/11 1:17 PM, "Jim Guichard" >>> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Frank, >>>>>>>>>>=20 >>>>>>>>>> What I would like to see is the ability to use TE without >>> VPN's. >>>> I >>>>>>>>> do >>>>>>>>> not >>>>>>>>>> want to be forced to deploy VPN infrastructure in this case. >>>> RSVP-TE >>>>>>>>> is an >>>>>>>>>> important piece of the puzzle as it provides the ability to >>>> steer >>>>>>>>> traffic >>>>>>>>>> based upon policy that I may wish to enforce. I would be happy >>>> to >>>>>>>>> supply >>>>>>>>>> text for the draft but would like to agree on this alias before >>>>>>>>> doing >>>>>>>>> so >>>>>>>>>> .. >>>>>>>>>>=20 >>>>>>>>>> On 3/27/11 7:53 AM, "Frank Brockners (fbrockne)" >>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Jim, >>>>>>>>>>>=20 >>>>>>>>>>> why is VPN "overkill" (kind of delicate wording these >>> days...)? >>>> TE >>>>>>>>> could >>>>>>>>>>> also be combined with MPLS VPNs. >>>>>>>>>>>=20 >>>>>>>>>>> Would also be interested in other folks' thoughts on the need >>>> for >>>>>>>>>>> "plain" IP-over-MPLS tunnels. >>>>>>>>>>>=20 >>>>>>>>>>> Thanks, Frank >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Jim Guichard [mailto:jguichard@juniper.net] >>>>>>>>>>>> Sent: Friday, March 25, 2011 8:03 PM >>>>>>>>>>>> To: Frank Brockners (fbrockne) >>>>>>>>>>>> Cc: softwires@ietf.org >>>>>>>>>>>> Subject: Re: [Softwires] >>>>>>>>> draft-ietf-softwire-gateway-init-ds-list- >>>>>>>>> 02 >>>>>>>>>>>>=20 >>>>>>>>>>>> VPN is overkill imho plus i want the ability to engineer >>>> traffic >>>>>>>>> paths >>>>>>>>>>>> and for this i need TE >>>>>>>>>>>>=20 >>>>>>>>>>>> Jim Guichard >>>>>>>>>>>>=20 >>>>>>>>>>>> Principal Networking Architect >>>>>>>>>>>> IPG CTO Office >>>>>>>>>>>> Juniper Networks >>>>>>>>>>>>=20 >>>>>>>>>>>> CCIE #2069 >>>>>>>>>>>>=20 >>>>>>>>>>>> Sent from my iphone >>>>>>>>>>>>=20 >>>>>>>>>>>> On Mar 25, 2011, at 5:17, "Frank Brockners (fbrockne)" >>>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Jim, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> fully agreed that MPLS should not be absent from the >>> draft, >>>> and >>>>>>>>> it >>>>>>>>>>> is >>>>>>>>>>>>> not. The current draft-ietf-softwire-gateway-init-ds-list- >>>> 03 >>>>>>>>> doesn't >>>>>>>>>>>>> restrict things to IP tunneling. The draft already allows >>>> for >>>>>>>>> MPLS >>>>>>>>>>>>> transport between Gateway and AFTR using MPLS VPNs. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hence the question: For the use cases you have in mind, >>>>>>>>> couldn't >>>>>>>>> we >>>>>>>>>>>> just >>>>>>>>>>>>> use MPLS VPNs (possibly even point-to-point with just two >>>> PEs >>>>>>>>> in >>>>>>>>> a >>>>>>>>>>>> VPN - >>>>>>>>>>>>> Gateway and the AFTR)? Personally I've nothing against >>>>>>>> additional >>>>>>>>>>>>> encapsulations, though so far there's always been a push >>> in >>>> the >>>>>>>>> WG >>>>>>>>>>>> (and >>>>>>>>>>>>> also in 3GPP SA2) to keep the number of encapsulations to >>> a >>>>>>>>> minimum >>>>>>>>>>>>> (e.g. L2TPv3 was dropped from the list of encaps, because >>>> we >>>>>>>>> could >>>>>>>>>>> do >>>>>>>>>>>>> the very same thing with GRE). >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On multicast: Don't fully follow your thought below. Do >>> you >>>>>>>>> consider >>>>>>>>>>>>> running multicast over the softwire between AFTR and >>>> Gateway? >>>>>>>> The >>>>>>>>>>>>> multicast considerations for GI-DS-lite (see >>>>>>>>>>>>> draft-brockners-softwire-mcast-gi-ds-lite-00) so far >>> assume >>>>>>>>> that >>>>>>>>>>> this >>>>>>>>>>>>> would not be the case. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, Frank >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Jim Guichard [mailto:jguichard@juniper.net] >>>>>>>>>>>>>> Sent: Thursday, March 24, 2011 9:43 PM >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi Frank, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> bi-directional tunnels are necessary if you wish for >>>> traffic >>>>>>>>> flows >>>>>>>>>>>> to >>>>>>>>>>>>>> take >>>>>>>>>>>>>> the same path in both directions across the network. It >>> is >>>>>>>>> possible >>>>>>>>>>>> to >>>>>>>>>>>>>> use >>>>>>>>>>>>>> point-to-point but this is cumbersome to deploy. >>>>>>>>>>> Point-to-multipoint >>>>>>>>>>>>>> may >>>>>>>>>>>>>> be necessary for multicast. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Clearly IP-in-MPLS tunneling is a fundamental requirement >>>> that >>>>>>>>>>>> should >>>>>>>>>>>>>> not >>>>>>>>>>>>>> be absent from the draft. If an operator has MPLS why >>>> restrict >>>>>>>>> them >>>>>>>>>>>> to >>>>>>>>>>>>>> IP >>>>>>>>>>>>>> tunneling? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> to kick-start the discussion, could you outline the >>> usage >>>>>>>>>>> scenarios >>>>>>>>>>>>>> that >>>>>>>>>>>>>>> would drive the requirements you mention below? >>>>>>>>>>>>>>>=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 >>>>>>=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 From yiu_lee@cable.comcast.com Fri Jul 8 05:37:38 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A73F21F860B for ; Fri, 8 Jul 2011 05:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khdQYnqNXGNK for ; Fri, 8 Jul 2011 05:37:37 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 01B6221F8605 for ; Fri, 8 Jul 2011 05:37:36 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.43802455; Fri, 08 Jul 2011 06:41:21 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Fri, 8 Jul 2011 08:37:11 -0400 From: "Lee, Yiu" To: Paco Cortes , Jim Guichard , "Frank Brockners (fbrockne)" Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: AQHMPWu2YRHOcuH9JU2SR/j2ZfsqBg== Date: Fri, 8 Jul 2011 12:37:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.253.6.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <51E806B19B70D24595A4333CB16AE884@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 12:37:38 -0000 Hi Paco, I am good this is cleaner. Thanks, Yiu On 7/8/11 4:49 AM, "Paco Cortes" wrote: >o IPv4/IPv6-in-MPLS: SWID is the top MPLS label. CID might be the next >MPLS >label in the stack, if present, or the AD's IP address. From yiu_lee@cable.comcast.com Fri Jul 8 05:38:09 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3BF21F88BC for ; Fri, 8 Jul 2011 05:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaeozVv-8oEQ for ; Fri, 8 Jul 2011 05:38:09 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3A43721F87CD for ; Fri, 8 Jul 2011 05:38:09 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.43802525; Fri, 08 Jul 2011 06:42:16 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Fri, 8 Jul 2011 08:38:05 -0400 From: "Lee, Yiu" To: Jim Guichard , Paco Cortes Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: AQHMPWvVYRHOcuH9JU2SR/j2ZfsqBg== Date: Fri, 8 Jul 2011 12:38:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [69.253.6.2] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 12:38:09 -0000 I support that. I am sorry if I get you misunderstood I didn't support Section 5. On 7/8/11 8:12 AM, "Jim Guichard" wrote: >I think the other necessary change is for section 5. Could you agree to >change the 1st bullet to allow for dynamic establishment of softwires? It >seems restrictive to mandate that they be pre-established. From pacosaddress@googlemail.com Fri Jul 8 06:04:40 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58D121F8890 for ; Fri, 8 Jul 2011 06:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGoM4aVL0e-Z for ; Fri, 8 Jul 2011 06:04:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 291C721F8828 for ; Fri, 8 Jul 2011 06:04:40 -0700 (PDT) Received: by iye7 with SMTP id 7so2159662iye.31 for ; Fri, 08 Jul 2011 06:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y1OMdZq6eclAuFG9XNqzTHDazlT4OKLc28idEUb4190=; b=V7PjqiYu3D1Phex2BwcB4iOBaDO6XrbtnsNSgfwHYXJJTgBrMU68vpVCEzb6BVzGB7 K43wN1zQ8Wp9KY10pLijjnRhkeZ/z2KTjjQ3kFyT4xSmgEd/oG1L8HCwJps37MC9emp4 xAEY4n+mlf5yDUlmi64xxi6A+3g7y8OHSN7O0= MIME-Version: 1.0 Received: by 10.231.29.132 with SMTP id q4mr1713631ibc.169.1310130279448; Fri, 08 Jul 2011 06:04:39 -0700 (PDT) Received: by 10.231.180.79 with HTTP; Fri, 8 Jul 2011 06:04:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jul 2011 15:04:39 +0200 Message-ID: From: Paco Cortes To: "Lee, Yiu" Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 13:04:40 -0000 I also support Jim's proposed change to section 5 2011/7/8 Lee, Yiu : > I support that. I am sorry if I get you misunderstood I didn't support > Section 5. > > On 7/8/11 8:12 AM, "Jim Guichard" wrote: > >>I think the other necessary change is for section 5. Could you agree to >>change the 1st bullet to allow for dynamic establishment of softwires? It >>seems restrictive to mandate that they be pre-established. > > From weapon@csnet1.cs.tsinghua.edu.cn Fri Jul 8 10:47:08 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D92221F8539 for ; Fri, 8 Jul 2011 10:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.113 X-Spam-Level: * X-Spam-Status: No, score=1.113 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FROM_EXCESS_BASE64=1.456, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX76uqEl6LIq for ; Fri, 8 Jul 2011 10:47:02 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6E90821F8768 for ; Fri, 8 Jul 2011 10:46:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id 7449430B0B87 for ; Sat, 9 Jul 2011 01:46:50 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Jul 9 01:46:50 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4e17428a39132112617467 X-DSPAM-Factors: 27, and+form, 0.01000, D, 0.01000, just, 0.01000, IPv4+networks, 0.01000, IPv4+networks, 0.01000, txt, 0.01000, txt, 0.01000, Secretariat, 0.01000, ID+Individual, 0.01000, the+softwire, 0.01000, end, 0.01000, end, 0.01000, Remove, 0.01000, IPv4+addresses, 0.01000, mechanism+is, 0.01000, softwire, 0.01000, softwire, 0.01000, To*ietf.org, 0.01000, allocating+public, 0.01000, hosts+or, 0.01000, from, 0.01000, from, 0.01000, Version+Notification, 0.01000, 4+2), 0.01000, new+version, 0.01000, Filename+draft, 0.01000, Wu+and, 0.01000 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MmKGybgyIwV for ; Sat, 9 Jul 2011 01:46:49 +0800 (CST) Received: from weapon-PC (th207057.ip.tsinghua.edu.cn [59.66.207.57]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id A942030B0957 for ; Sat, 9 Jul 2011 01:46:49 +0800 (CST) Date: Sat, 9 Jul 2011 01:46:48 +0800 From: "=?utf-8?B?UGVuZyBXdQ==?=" To: "=?utf-8?B?c29mdHdpcmVzQGlldGYub3Jn?=" Message-ID: <201107090146486310156@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: [Softwires] =?utf-8?q?Fw=3A_New_Version_Notification_for_draft-cu?= =?utf-8?q?i-softwire-host-4over6-06=2Etxt?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 17:47:08 -0000 Rm9sa3MsDQoNCldlJ3ZlIHVwZGF0ZWQgdGhlIHB1YmxpYyA0b3ZlcjYgZHJhZnQgdG8gLTA2IHZl cnNpb24uDQoNClRoZSBtYWpvciBtb2RpZmljYXRpb24gZnJvbSAtMDQgdmVyc2lvbigtMDUgdmVy c2lvbiBpcyBqdXN0IGFuIGludGVybWVkaWF0ZSB2ZXJzaW9uKSBpbmNsdWRlczoNCjEuUmVtb3Zl IHRoZSBjb250ZW50IG9mIERIQ1Agb3ZlciB0dW5uZWwgaXNzdWUgYW5kIGZvcm0gYSBkZWRpY2F0 ZWQgZG9jdW1lbnQgZm9yIHRoYXQuIFNlZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1jdWktc29mdHdpcmUtZGhjcC1vdmVyLXR1bm5lbC8NCjIuQWRkIHVzZSBjYXNlIGFu YWx5c2lzKHNlY3Rpb24gNC4yKS4NCjMuQ2hhbmdlIHRoZSBhZGRyZXNzIG1hcHBpbmcgbWFpbnRh aW5pbmcgbWV0aG9kLCBmcm9tIERIQ1AtZHJpdmVuIHVwZGF0aW5nIG9uIGNvbmNlbnRyYXRvciB0 byBwaW5ob2xlIHByb2NlZHVyZSBieSBpbml0aWF0b3JzLg0KDQpDb21tZW50cyBhbmQgZmVlZGJh Y2tzIGFyZSBzb2xpY2l0ZWQgYW5kIGFwcHJlY2lhdGVkLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb23vvJppbnRl cm5ldC1kcmFmdHMNCkRhdGXvvJoyMDExLTA3LTA5IDAxOjIyOjE1DQpUb++8mndlYXBvbg0KQ0Pv vJpjaG1ldHo7IHdlYXBvbjsgb2xpdmllcjsgeW9uZzsgeWl1X2xlZTsgamlhbnBpbmcNClN1Ympl Y3TvvJpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWN1aS1zb2Z0d2lyZS1ob3N0 LTRvdmVyNi0wNi50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWN1aS1zb2Z0d2ly ZS1ob3N0LTRvdmVyNi0wNi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBQ ZW5nIFd1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBk cmFmdC1jdWktc29mdHdpcmUtaG9zdC00b3ZlcjYNClJldmlzaW9uOgkgMDYNClRpdGxlOgkJIFB1 YmxpYyBJUHY0IG92ZXIgQWNjZXNzIElQdjYgTmV0d29yaw0KQ3JlYXRpb24gZGF0ZToJIDIwMTEt MDctMDgNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAx Nw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZHJhZnQgcHJvcG9zZXMgYSBtZWNoYW5pc20gZm9yIGJp ZGlyZWN0aW9uYWwgSVB2NCBjb21tdW5pY2F0aW9uDQogICBiZXR3ZWVuIElQdjQgSW50ZXJuZXQg YW5kIGVuZCBob3N0cyBvciBJUHY0IG5ldHdvcmtzIHNpdGVkIGluIElQdjYNCiAgIGFjY2VzcyBu ZXR3b3JrLiAgVGhpcyBtZWNoYW5pc20gZm9sbG93cyB0aGUgc29mdHdpcmUgaHViIGFuZCBzcG9r ZQ0KICAgbW9kZWwgYW5kIHVzZXMgSVB2NC1vdmVyLUlQdjYgdHVubmVsIGFzIGJhc2ljIG1ldGhv ZCB0byB0cmF2ZXJzZSBJUHY2DQogICBuZXR3b3JrLiAgQnkgYWxsb2NhdGluZyBwdWJsaWMgSVB2 NCBhZGRyZXNzZXMgdG8gZW5kIGhvc3RzL25ldHdvcmtzDQogICBpbiBJUHY2LCBpdCBjYW4gYWNo aWV2ZSBJUHY0IGVuZC10by1lbmQgYmlkaXJlY3Rpb25hbCBjb21tdW5pY2F0aW9uDQogICBiZXR3 ZWVuIHRoZXNlIGhvc3RzL25ldHdvcmtzIGFuZCBJUHY0IEludGVybmV0LiAgVGhpcyBtZWNoYW5p c20gaXMgYW4NCiAgIElQdjQgYWNjZXNzIG1ldGhvZCBmb3IgaG9zdHMgYW5kIElQdjQgbmV0d29y a3Mgc2l0ZWQgaW4gSVB2Ni4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0DQo= From internet-drafts@ietf.org Fri Jul 8 15:49:08 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EA921F8BF7; Fri, 8 Jul 2011 15:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdyZd5HquD-K; Fri, 8 Jul 2011 15:49:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB7721F8BD6; Fri, 8 Jul 2011 15:49:07 -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: 3.55 Message-ID: <20110708224907.22625.93578.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2011 15:49:07 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-gateway-init-ds-lite-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 22:49:08 -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 : Gateway Initiated Dual-Stack Lite Deployment Author(s) : Frank Brockners Sri Gundavelli Sebastian Speicher David Ward Filename : draft-ietf-softwire-gateway-init-ds-lite-05.txt Pages : 15 Date : 2011-07-08 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-gateway-init-ds-lit= e-05.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-gateway-init-ds-lite= -05.txt From fbrockne@cisco.com Fri Jul 8 15:51:38 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E84421F8C51 for ; Fri, 8 Jul 2011 15:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KqIItZtnn2x for ; Fri, 8 Jul 2011 15:51:37 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 47D5C21F8C4F for ; Fri, 8 Jul 2011 15:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fbrockne@cisco.com; l=959; q=dns/txt; s=iport; t=1310165493; x=1311375093; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=R5RjszeYzHnyzScj3pwGNJGKX7HzulpOxSpW0FPR+U0=; b=AFacNZt98rNwV5abQedAVTOkVf1qoWSwoIV43muxDUCCO5iYiuDA2bEJ ocnvI6+VhQ8imu/gKSfOfvzgSUzcBV/QL4XBRC6i/WLY4b6T4mHVrn8Iw mXYNBYzAQaqv9tLcYebsb5f9b8jpRT/XTAcMEuQGrWh8nsS4bCVvfN0ei Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAAWJF06Q/khN/2dsb2JhbABUmBqPNHerZp1XhjgEl1GLQA X-IronPort-AV: E=Sophos;i="4.65,501,1304294400"; d="scan'208";a="41296818" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Jul 2011 22:51:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p68MpWq2013688; Fri, 8 Jul 2011 22:51:32 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Jul 2011 00:51:32 +0200 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: Sat, 9 Jul 2011 00:51:28 +0200 Message-ID: <0D212BD466921646B58854FB79092CEC06275716@XMB-AMS-106.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 Thread-Index: Acw9b5rJQQ66soFbTfeG3UcFF/StogAUcHRw References: From: "Frank Brockners (fbrockne)" To: "Paco Cortes" , "Lee, Yiu" X-OriginalArrivalTime: 08 Jul 2011 22:51:32.0011 (UTC) FILETIME=[94BA1FB0:01CC3DC1] Cc: softwires@ietf.org Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-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 Jul 2011 22:51:38 -0000 FYI. I just posted draft-ietf-softwire-gateway-init-ds-lite-05 reflecting the discussion (including the two requested changes). Regards, Frank > -----Original Message----- > From: Paco Cortes [mailto:pacosaddress@googlemail.com] > Sent: Friday, July 08, 2011 6:05 AM > To: Lee, Yiu > Cc: Jim Guichard; Frank Brockners (fbrockne); softwires@ietf.org > Subject: Re: [Softwires] draft-ietf-softwire-gateway-init-ds-list-02 >=20 > I also support Jim's proposed change to section 5 >=20 > 2011/7/8 Lee, Yiu : > > I support that. I am sorry if I get you misunderstood I didn't > support > > Section 5. > > > > On 7/8/11 8:12 AM, "Jim Guichard" wrote: > > > >>I think the other necessary change is for section 5. Could you agree > to > >>change the 1st bullet to allow for dynamic establishment of > softwires? It > >>seems restrictive to mandate that they be pre-established. > > > > From jiangdong345@gmail.com Fri Jul 8 20:31:06 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D1921F8BBE for ; Fri, 8 Jul 2011 20:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_29=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9w204Hc2qv3 for ; Fri, 8 Jul 2011 20:31:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C92C21F8B93 for ; Fri, 8 Jul 2011 20:31:05 -0700 (PDT) Received: by iye7 with SMTP id 7so2767335iye.31 for ; Fri, 08 Jul 2011 20:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:x-mailer:mime-version :content-type; bh=l/Hg8xdkjNucCKw/1EyD9RDR1xhMkXu4mTt0pV9jfDQ=; b=NZrJh6B3SaHM7glswtUXmb/DTHVS8oPMHRskNrhl/E5zJMwWRW44Bt2c/oOkF/yAwZ qjto8zpb61NuJ1xaULH8dYvvqU07S/K08el3VuK3NdPUsnyIa6Yozbvo9QKZpyYwH6lz LYTnedhsR4K9RGxpW85FX3kWFSNoAXgL0pDqY= Received: by 10.43.49.8 with SMTP id uy8mr2648308icb.462.1310182264900; Fri, 08 Jul 2011 20:31:04 -0700 (PDT) Received: from DJ-PC ([166.111.68.231]) by mx.google.com with ESMTPS id a9sm3123170icy.18.2011.07.08.20.31.02 (version=SSLv3 cipher=OTHER); Fri, 08 Jul 2011 20:31:04 -0700 (PDT) Date: Sat, 9 Jul 2011 11:31:13 +0800 From: Jiang Dong To: "softwires" Message-ID: <201107091131084017488@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon688138158058_=====" Cc: CUI Yong Subject: [Softwires] Fw: New Version Notification for draft-cui-softwire-mesh-mib-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, 09 Jul 2011 03:31:06 -0000 This is a multi-part message in MIME format. --=====003_Dragon688138158058_===== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, A new version of Softwire Mesh MIB has been submitted. http://tools.ietf.org/html/draft-cui-softwire-mesh-mib-02 This version intrduces the relationship with If MIB and IP Tunnel MIB. Since there's no encapsulation message in the IP tunnel MIB, we add an encapsulation table in the softwire mesh MIB. Some other specific objects about softwire mesh MIB also have been added. Any comments are appreciated! 2011-07-09 Jiang Dong From: internet-drafts Date:2011-07-07 23:26:53 To:dongjiang CC:weapon; yong; dongjiang Subject:New Version Notification for draft-cui-softwire-mesh-mib-02.txt A new version of I-D, draft-cui-softwire-mesh-mib-02.txt has been successfully submitted by Jiang Dong and posted to the IETF repository. Filename: draft-cui-softwire-mesh-mib Revision: 02 Title: Softwire Mesh Management Information Base(MIB) Creation date: 2011-07-07 WG ID: Individual Submission Number of pages: 14 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular it defines objects for managing softwire mesh [RFC5565]. The IETF Secretariat --=====003_Dragon688138158058_===== Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hi,
A new version of Softwire Mesh MIB has been submitted. http://tools.ietf.org/html/draft-cui-softwire-mesh-mib-02
 
This version intrduces the relationship with If MIB and IP Tunnel MIB. Since there's no encapsulation message in the IP tunnel MIB, we add an encapsulation table in the softwire mesh MIB. Some other specific objects about softwire mesh MIB also have been added.
 
Any comments are appreciated!
 
2011-07-09
Jiang Dong
From: internet-drafts
Date：2011-07-07 23:26:53
To：dongjiang
CC：weapon; yong; dongjiang
Subject：New Version Notification for draft-cui-softwire-mesh-mib-02.txt
 
A new version of I-D, draft-cui-softwire-mesh-mib-02.txt has been successfully submitted by Jiang Dong and posted to the IETF repository.
Filename:  draft-cui-softwire-mesh-mib
Revision:  02
Title:  Softwire Mesh Management Information Base(MIB)
Creation date:  2011-07-07
WG ID:  Individual Submission
Number of pages: 14
Abstract:
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular it defines objects for managing softwire mesh
   [RFC5565].
                                                                                  
The IETF Secretariat
 --=====003_Dragon688138158058_=====-- From xing@cernet.edu.cn Sat Jul 9 19:16:59 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D55221F86E3; Sat, 9 Jul 2011 19:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8gpSdhE7L69; Sat, 9 Jul 2011 19:16:59 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 3FA6321F85F6; Sat, 9 Jul 2011 19:16:57 -0700 (PDT) Received: from [127.0.0.1]([127.0.0.25]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1a4e1982e5; Sun, 10 Jul 2011 10:16:56 +0800 Message-ID: <4E190B81.9080508@cernet.edu.cn> Date: Sun, 10 Jul 2011 10:16:33 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: GangChen References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cOo9jf0B Cc: softwires , Behave WG Subject: Re: [Softwires] [BEHAVE] [Softwire] New Version Notification for draft-murakami-softwire-4v6-translation-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: Sun, 10 Jul 2011 02:16:59 -0000 于 2011/7/7 15:46, GangChen 写é“: > Dear all, > > We have submitted a draft regarding 4via6 stateless translation. > http://tools.ietf.org/id/draft-murakami-softwire-4v6-translation-00.txt > comments are welcome. > > A new version of I-D, draft-murakami-softwire-4v6-translation-00.txt > has been successfully submitted by Tetsuya Murakami and posted to the > IETF repository. > > Filename: draft-murakami-softwire-4v6-translation > Revision: 00 > Title: 4via6 Stateless Translation > Creation date: 2011-07-04 > WG ID: Individual Submission > Number of pages: 10 The dual stateless IPv4/IPv6 translation (double translation) was proposed in 2009 in Behave WG, which is an extension of the stateless IPv4/IPv6 translation (IVI) defined in RFC6052, RFC6144, RFC6145 and RFC6219. Currently, there are two drafts. (1) dIVI (a straightforward extension of single translation): https://datatracker.ietf.org/doc/draft-xli-behave-divi/ (2) dIVI-pd (dual translation with prefix delegation): https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd/ Comments are also welcome! Regards, xing > Abstract: > This document specify 4via6, a solution for IPv4 connectivity across > IPv6 network utilizes 4rd algorithmic address mapping rule as a > series of stateless IPv4 over IPv6 migration solutions. 4via6 employ > stateless address translation techniques. It is useful for operators > who want to provide IPv4 connectivity across restricted bandwidth > IPv6 network with stateless operation. > > Many thanks > > Gang > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > From xmw@cernet.edu.cn Sun Jul 10 19:43:23 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2078C21F869E for ; Sun, 10 Jul 2011 19:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.295 X-Spam-Level: X-Spam-Status: No, score=-98.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, FROM_EXCESS_BASE64=1.456, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgBZiMXtdr93 for ; Sun, 10 Jul 2011 19:43:22 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 1912021F865C for ; Sun, 10 Jul 2011 19:43:21 -0700 (PDT) Received: from user-THINK([59.66.24.226]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm74e1ada96; Mon, 11 Jul 2011 10:43:20 +0800 Date: Mon, 11 Jul 2011 10:43:32 +0800 From: "=?utf-8?B?TWluZ3dlaSBYdQ==?=" To: "=?utf-8?B?U29mdHdpcmVz?=" Message-ID: <201107111043321916140@cernet.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-AIMC-AUTH: xmw X-AIMC-MAILFROM: xmw@cernet.edu.cn X-AIMC-Msg-ID: cbu2Gg0B Subject: [Softwires] =?utf-8?q?Fw=3A_New_Version_Notification_for_draft-xu?= =?utf-8?q?-softwire-mesh-multicast-02=2Etxt?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 02:43:23 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgdXBkYXRlZCBvdXIgZHJhZnQgYWJvdXQgc29mdHdpcmUgbWVz aCBtdWx0aWNhc3QuDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LXNv ZnR3aXJlLW1lc2gtbXVsdGljYXN0Lw0KDQpUaGUgbWFpbiBjaGFuZ2UgaXMgYXMgZm9sbG93cy4N Cg0KMS4gSSBjaGFuZ2VkIFNlY3Rpb24gNCBhbmQgNSdzIHN0cnVjdHVyZS4gDQoyLiBJIGRpc2N1 c3NlZCBBU00gYW5kIFNTTSBleHBsaWNpdGx5Lg0KMy4gVGhlIG1hcHBpbmcgYmV0d2VlbiBzb3Vy Y2UgYWRkcmVzcyBTIGFuZCBTJyBpcyBiYXNlZCBvbiBSRkMgNjA1Miwgd2hpY2gga2VlcHMgdGhl IG9uZS10by1vbmUgbWFwcGluZy4NCg0KWW91ciBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KTWlu Z3dlaQ0KDQoJDQoNCg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1zb2Z0d2lyZS1t ZXNoLW11bHRpY2FzdC0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBY dWFuIENoZW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPg0KPkZpbGVuYW1l OgkgZHJhZnQteHUtc29mdHdpcmUtbWVzaC1tdWx0aWNhc3QNCj5SZXZpc2lvbjoJIDAyDQo+VGl0 bGU6CQkgU29mdHdpcmUgTWVzaCBNdWx0aWNhc3QNCj5DcmVhdGlvbiBkYXRlOgkgMjAxMS0wNy0w OQ0KPldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPk51bWJlciBvZiBwYWdlczogMjIN Cj4NCj5BYnN0cmFjdDoNCj4gICBUaGUgSW50ZXJuZXQgbmVlZHMgc3VwcG9ydCBJUHY0IGFuZCBJ UHY2IHBhY2tldHMuICBCb3RoIGFkZHJlc3MNCj4gICBmYW1pbGllcyBhbmQgdGhlaXIgYXR0ZW5k YW50IHByb3RvY29sIHN1aXRlcyBzdXBwb3J0IG11bHRpY2FzdCBvZiB0aGUNCj4gICBzaW5nbGUt c291cmNlIGFuZCBhbnktc291cmNlIHZhcmlldGllcy4gIEFzIHBhcnQgb2YgdGhlIHRyYW5zaXRp b24gdG8NCj4gICBJUHY2LCB0aGVyZSB3aWxsIGJlIHNjZW5hcmlvcyB3aGVyZSBhIGJhY2tib25l IG5ldHdvcmsgcnVubmluZyBvbmUgSVANCj4gICBhZGRyZXNzIGZhbWlseSBpbnRlcm5hbGx5IChy ZWZlcnJlZCB0byBhcyBpbnRlcm5hbCBJUCBvciBJLUlQKSB3aWxsDQo+ICAgcHJvdmlkZSB0cmFu c2l0IHNlcnZpY2VzIHRvIGF0dGFjaGVkIGNsaWVudCBuZXR3b3JrcyBydW5uaW5nIGFub3RoZXIN Cj4gICBJUCBhZGRyZXNzIGZhbWlseSAocmVmZXJyZWQgdG8gYXMgZXh0ZXJuYWwgSVAgb3IgRS1J UCkuICBJdCBpcw0KPiAgIGV4cGVjdGVkIHRoYXQgdGhlIEktSVAgYmFja2JvbmUgd2lsbCBvZmZl ciB1bmljYXN0IGFuZCBtdWx0aWNhc3QNCj4gICB0cmFuc2l0IHNlcnZpY2VzIHRvIHRoZSBjbGll bnQgRS1JUCBuZXR3b3Jrcy4NCj4NCj4gICBTb2Z0d2lyZXMgTWVzaCBpcyBhIHNvbHV0aW9uIGZv ciBzdXBwb3J0aW5nIEUtSVAgdW5pY2FzdCBhbmQNCj4gICBtdWx0aWNhc3QgYWNyb3NzIGFuIEkt SVAgYmFja2JvbmUuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUNCj4gICBtZWNoYW5pc21z IGZvciBzdXBwb3J0aW5nIEludGVybmV0LXN0eWxlIG11bHRpY2FzdCBhY3Jvc3MgYSBzZXQgb2YN Cj4gICBFLUlQIGFuZCBJLUlQIG5ldHdvcmtzIHN1cHBvcnRpbmcgc29mdHdpcmVzIG1lc2guDQo+ DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KPg0KPg0KPlRoZSBJRVRGIFNlY3JldGFy aWF0DQo+DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSANCiAgDQrj gIDjgIDjgIDjgIDjgIDjgIDjgIDjgIDoh7QNCuekvO+8gQ0KDQogIA0K44CA44CA44CA44CA44CA 44CA44CA44CATWluZ3dlaSBYdQ0K44CA44CA44CA44CA44CA44CA44CA44CAeG13QGNlcm5ldC5l ZHUuY24NCuOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgOOAgDIwMTEtMDctMTEgDQo= From xmw@cernet.edu.cn Sun Jul 10 19:49:05 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102BD21F866B for ; Sun, 10 Jul 2011 19:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.697 X-Spam-Level: X-Spam-Status: No, score=-95.697 tagged_above=-999 required=5 tests=[AWL=-2.598, BAYES_50=0.001, FH_HAS_XAIMC=2.696, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGG3StkEMCuR for ; Sun, 10 Jul 2011 19:49:04 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 07A8621F864F for ; Sun, 10 Jul 2011 19:49:03 -0700 (PDT) Received: from user-THINK([59.66.24.226]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm334e1adbec; Mon, 11 Jul 2011 10:49:02 +0800 Date: Mon, 11 Jul 2011 10:49:15 +0800 From: "Mingwei Xu" To: "Yong Cui" , "Softwires-wg list" References: Message-ID: <201107111049147050027@cernet.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-AIMC-AUTH: xmw X-AIMC-MAILFROM: xmw@cernet.edu.cn X-AIMC-Msg-ID: cr08Gg0B Cc: Yong Cui Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 02:49:05 -0000 SGkgY2hhaXJzLA0KDQpJJ2QgbGlrZSB0byBwcmVzZW50IHNvZnR3aXJlIG1lc2ggbXVsdGljYXN0 IGluIHNvZnR3aXJlIFdHIGluIHRoZSB1cGNvbWluZyBJRVRGIG1lZXRpbmcuDQoNClByZXNlbnRl cidzIG5hbWU6ICBNaW5nd2VpIFh1DQpEcmFmdCBuYW1lOiBTb2Z0d2lyZSBNZXNoIE11bHRpY2Fz dA0KSUVURiBsaW5rOiAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC14dS1z b2Z0d2lyZS1tZXNoLW11bHRpY2FzdC8NCg0KVGhhbmsgeW91Lg0KDQpNaW5nd2VpDQoNCgkNCg0K PT09PT09PSAyMDExLTA3LTA3IDA5OjM3OjM1IMT61NrAtNDF1tDQtLXAo7o9PT09PT09DQoNCj5I aSBndXlzLA0KPg0KPklmIHlvdSBhcmUgcGxhbmluZyB0byBwcmVzZW50IHNvbWV0aGluZyBpbiB0 aGUgU29mdHdpcmUgV0cgaW4gUXVlYmVjIENpdHksDQo+cGxlYXNlIHNlbmQgeW91ciBhZ2VuZGEg aXRlbSByZXF1ZXN0cyB0byBBbGFpbiBhbmQgbWUgYnkgNy8xMiBpbiB0aGUNCj5mb2xsb3dpbmcg Zm9ybWF0Og0KPihwcmVzZW50ZXIncyBuYW1lLCBkcmFmdCBuYW1lLCBpZXRmIGxpbmspDQo+DQo+ V2UgYWxzbyBuZWVkIHlvdXIgc2xpZGVzIGJ5IFNhdHVyZGF5IDcvMjMgKGJlZm9yZSB0aGUgbWVl dGluZyBzdGFydHMpLg0KPg0KPlRoYW5rcy4NCj4NCj4tIEFsYWluICYgWW9uZy4NCj4NCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlNvZnR3aXJl cyBtYWlsaW5nIGxpc3QNCj5Tb2Z0d2lyZXNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPg0KDQo9ID0gPSA9ID0gPSA9ID0gPSA9ID0g PSA9ID0gPSA9ID0gPSA9ID0NCgkJCQ0KDQqhoaGhoaGhoaGhoaGhoaGh1sINCsDxo6ENCiANCgkJ CQkgDQqhoaGhoaGhoaGhoaGhoaGhTWluZ3dlaSBYdQ0KoaGhoaGhoaGhoaGhoaGhoXhtd0BjZXJu ZXQuZWR1LmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMTEtMDctMTENCg== From matsuhira@jp.fujitsu.com Sun Jul 10 22:08:39 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22D721F87CB for ; Sun, 10 Jul 2011 22:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.09 X-Spam-Level: X-Spam-Status: No, score=-104.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXz29832UUXZ for ; Sun, 10 Jul 2011 22:08:39 -0700 (PDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3340421F8567 for ; Sun, 10 Jul 2011 22:08:39 -0700 (PDT) Received: from m4.gw.fujitsu.co.jp (unknown [10.0.50.74]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 47D623EE0B5 for ; Mon, 11 Jul 2011 14:08:38 +0900 (JST) Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 2B00545DE81 for ; Mon, 11 Jul 2011 14:08:38 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 15AFF45DE80 for ; Mon, 11 Jul 2011 14:08:38 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 075CD1DB8037 for ; Mon, 11 Jul 2011 14:08:38 +0900 (JST) Received: from m003.s.css.fujitsu.com (m003.s.css.fujitsu.com [10.23.4.33]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id C99E71DB802F for ; Mon, 11 Jul 2011 14:08:37 +0900 (JST) Received: from m003.css.fujitsu.com (m003 [127.0.0.1]) by m003.s.css.fujitsu.com (Postfix) with ESMTP id A49CB2E04A5; Mon, 11 Jul 2011 14:08:37 +0900 (JST) Received: from [127.0.0.1] (fj86077803.sl046.dhcp.css.fujitsu.com [10.77.46.98]) by m003.s.css.fujitsu.com (Postfix) with ESMTP id 6C48E2E0467; Mon, 11 Jul 2011 14:08:37 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1 Message-ID: <4E1A846F.3090003@jp.fujitsu.com> Date: Mon, 11 Jul 2011 14:04:47 +0900 From: Naoki Matsuhira User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Softwires-wg Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [Softwires] Motivation draft for SA46T X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 05:08:39 -0000 Dear all, Initial I-D of the "Motivation for developing Stateless Automatic IPv4 over IPv6 Tunneling (SA46T)" has been submitted. The document is available at: http://tools.ietf.org/html/draft-matsuhira-sa46t-motivation-00 comments and suggestions are welcome. Regards, Naoki Matsuhira From weapon@csnet1.cs.tsinghua.edu.cn Mon Jul 11 00:29:17 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9AB21F898B for ; Mon, 11 Jul 2011 00:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.56 X-Spam-Level: X-Spam-Status: No, score=0.56 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FROM_EXCESS_BASE64=1.456, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9gpK5FiPWKe for ; Mon, 11 Jul 2011 00:29:15 -0700 (PDT) Received: from mail.catc.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id C924F21F8946 for ; Mon, 11 Jul 2011 00:29:14 -0700 (PDT) Received: from weapon-PC (unknown [166.111.68.231]) by mail.catc.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id BB23629B0002 for ; Mon, 11 Jul 2011 15:29:56 +0800 (CST) Date: Mon, 11 Jul 2011 15:29:09 +0800 From: "=?utf-8?B?UGVuZyBXdQ==?=" To: "=?utf-8?B?c29mdHdpcmVzQGlldGYub3Jn?=" Message-ID: <201107111528589020935@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: [Softwires] =?utf-8?q?Fw=3A_New_Version_Notification_for__draft-c?= =?utf-8?q?ui-softwire-b4-translated-ds-lite-01=2Etxt?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:29:17 -0000 SGkgZ3V5cywNCg0KSnVzdCBwb3N0IHRoZSAwMSB2ZXJzaW9uIG9mIGRyYWZ0LWN1aS1zb2Z0d2ly ZS1iNC10cmFuc2xhdGVkLWRzLWxpdGUuDQoNClRoaXMgZHJhZnQgcHJvcG9zZSB0aGUgbGlnaHR3 ZWlnaHQgNG92ZXI2IG1lY2hhbmlzbSB3aGljaCBtb3ZlcyB0aGUgdHJhbnNsYXRpb24gZnVuY3Rp b24gZnJvbSB0dW5uZWwgY29uY2VudHJhdG9yIChBRlRSKSB0byBpbml0aWF0b3JzIChCNHMpLCBh bmQgaGVuY2UgcmVkdWNlIHRoZSBtYXBwaW5nIHNjYWxlIG9uIENHTiB0byBwZXItY3VzdG9tZXIg bGV2ZWwuIFRvIGFjaGlldmUgdGhhdCwgcG9ydCByZXN0cmN0ZWQgSVB2NCBhZGRyZXNzZXMgYXJl IGFsbG9jYXRlZCB0byBpbml0aWF0b3JzIGluIGEgZmxleGlibGUgd2F5IGluZGVwZW5kZW50IG9m IElQdjYgbmV0d29yayBpbiB0aGUgbWlkZGxlLg0KDQpDb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMg d291bGQgYmUgYXBwcmVjaWF0ZWQuICBUaGFua3MuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQkJCQkg DQpQZW5nIFd1DQoyMDExLTA3LTExDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb23vvJppbnRlcm5ldC1kcmFmdHMNCkRh dGXvvJoyMDExLTA3LTExIDE1OjIyOjU4DQpUb++8mndlYXBvbg0KQ0PvvJp4aWVjaGY7IHdlYXBv bjsgc3VucWlvbmc7IGNhdGh5emhvdTsgeW9uZzsgamlhbnBpbmcNClN1YmplY3TvvJpOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yICBkcmFmdC1jdWktc29mdHdpcmUtYjQtdHJhbnNsYXRlZC1k cy1saXRlLTAxLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtY3VpLXNvZnR3aXJl LWI0LXRyYW5zbGF0ZWQtZHMtbGl0ZS0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBQZW5nIFd1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmls ZW5hbWU6CSBkcmFmdC1jdWktc29mdHdpcmUtYjQtdHJhbnNsYXRlZC1kcy1saXRlDQpSZXZpc2lv bjoJIDAxDQpUaXRsZToJCSBMaWdodHdlaWdodCA0b3ZlcjYgaW4gYWNjZXNzIG5ldHdvcmsNCkNy ZWF0aW9uIGRhdGU6CSAyMDExLTA3LTExDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogMTINCg0KQWJzdHJhY3Q6DQogICBUaGUgZHVhbC1zdGFjayBsaXRl IG1lY2hhbmlzbSBwcm92aWRlIGFuIElQdjQgYWNjZXNzIG1ldGhvZCBvdmVyIElQdjYNCiAgIElT UCBuZXR3b3JrIGZvciBlbmQgdXNlcnMuICBEdWFsLVN0YWNrIExpdGUgZW5hYmxlcyBhIGJyb2Fk YmFuZA0KICAgc2VydmljZSBwcm92aWRlciB0byBzaGFyZSBJUHY0IGFkZHJlc3NlcyBhbW9uZyBj dXN0b21lcnMgYnkgY29tYmluaW5nDQogICBJUHY0LWluLUlQdjYgdHVubmVsIGFuZCBDYXJyaWVy IEdyYWRlIE5BVC4gIEhvd2V2ZXIsIGluIGR1YWwtc3RhY2sNCiAgIGxpdGUuICBDR04gaGFzIHRv IG1haW50YWluIHBlci1zZXNzaW9uIGFkZHJlc3MgbWFwcGluZywgd2hpY2ggY291bGQNCiAgIGJl IGEgaGVhdnkgYnVyZGVuLCBhbmQgcHJvZHVjZSBoaWdoIGhhcmR3YXJlIGNvc3QgYXMgd2VsbCBh cw0KICAgcGVyZm9ybWFuY2UgaXNzdWUuICBUaGlzIGRyYWZ0IHByb3Bvc2UgdGhlIGxpZ2h0d2Vp Z2h0IDRvdmVyNg0KICAgbWVjaGFuaXNtIHdoaWNoIG1vdmVzIHRoZSB0cmFuc2xhdGlvbiBmdW5j dGlvbiBmcm9tIHR1bm5lbA0KICAgY29uY2VudHJhdG9yIChBRlRSKSB0byBpbml0aWF0b3JzIChC NHMpLCBhbmQgaGVuY2UgcmVkdWNlIHRoZSBtYXBwaW5nDQogICBzY2FsZSBvbiBDR04gdG8gcGVy LWN1c3RvbWVyIGxldmVsLiAgRm9yIHRyYW5zbGF0aW9uIHVzYWdlLCB0aGUNCiAgIG1lY2hhbmlz bSB3aWxsIGFsbG9jYXRlIHBvcnQgcmVzdHJjdGVkIElQdjQgYWRkcmVzc2VzIHRvIGluaXRpYXRv cnMNCiAgIGluIGEgZmxleGlibGUgd2F5IGluZGVwZW5kZW50IG9mIElQdjYgbmV0d29yayBpbiB0 aGUgbWlkZGxlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg== From weapon@csnet1.cs.tsinghua.edu.cn Mon Jul 11 01:04:51 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2530121F8877 for ; Mon, 11 Jul 2011 01:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.244 X-Spam-Level: X-Spam-Status: No, score=-0.244 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3cIWrimjbd3 for ; Mon, 11 Jul 2011 01:04:50 -0700 (PDT) Received: from mail.catc.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 85FCA21F86FD for ; Mon, 11 Jul 2011 01:04:50 -0700 (PDT) Received: from weapon-PC (unknown [166.111.68.231]) by mail.catc.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id A0E1729B0002; Mon, 11 Jul 2011 16:05:34 +0800 (CST) Date: Mon, 11 Jul 2011 16:04:47 +0800 From: "Peng Wu" To: "Yong Cui" , "adurand@juniper.net" References: <5D36713D8A4E7348A7E10DF7437A4B9286BE98@SZXEML504-MBX.china.huawei.com> Message-ID: <201107111604365820525@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:04:51 -0000 Dear chairs, We would like to present the following two drafts of Public 4over6 together. One time slot of 15 minutes would be great. Presenter Draft Peng Wu DHCPv4 Behavior over IP-IP tunnel http://datatracker.ietf.org/doc/draft-cui-softwire-dhcp-over-tunnel/ Public IPv4 over Access IPv6 Network http://datatracker.ietf.org/doc/draft-cui-softwire-host-4over6/ > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Yong Cui > Sent: Thursday, July 07, 2011 9:37 AM > To: Softwires-wg list > Cc: Yong Cui > Subject: [Softwires] Call for Agenda @ IETF 81 > > Hi guys, > > If you are planing to present something in the Softwire WG in Quebec > City, > please send your agenda item requests to Alain and me by 7/12 in the > following format: > (presenter's name, draft name, ietf link) > > We also need your slides by Saturday 7/23 (before the meeting starts). > > Thanks. > > - Alain & Yong. > > > _______________________________________________ > 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 weapon@csnet1.cs.tsinghua.edu.cn Mon Jul 11 01:11:51 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D121F85EC for ; Mon, 11 Jul 2011 01:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.158 X-Spam-Level: X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FROM_EXCESS_BASE64=1.456, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PYZwRcFPoi9 for ; Mon, 11 Jul 2011 01:11:51 -0700 (PDT) Received: from mail.catc.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8A63A21F8552 for ; Mon, 11 Jul 2011 01:11:50 -0700 (PDT) Received: from weapon-PC (unknown [166.111.68.231]) by mail.catc.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id 518F829B0002 for ; Mon, 11 Jul 2011 16:12:34 +0800 (CST) Date: Mon, 11 Jul 2011 16:11:46 +0800 From: "=?utf-8?B?UGVuZyBXdQ==?=" To: "=?utf-8?B?c29mdHdpcmVzQGlldGYub3Jn?=" Message-ID: <201107111611362192380@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: [Softwires] =?utf-8?q?Fw=3A_New_Version_Notification_for__draft-c?= =?utf-8?q?ui-softwire-dhcp-over-tunnel-01=2Etxt?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:11:52 -0000 SGkgZ3V5cywNCg0Kd2UgaGF2ZSBqdXN0IHN1Ym1pdHRlZCB0aGlzIG5ldyBkcmFmdC4gICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWN1aS1zb2Z0d2lyZS1kaGNwLW92ZXIt dHVubmVsLw0KSXQgZGVzY3JpYmVzIHRoZSBpc3N1ZSBhbmQgcG9zc2libGUgc29sdXRpb25zIG9m IHByZWZvcm1pbmcgREhDUHY0IG92ZXIgSVAtSVAgdHVubmVsLiAgSXQgY2FuIGJlIGFwcGxpY2Fi bGUgdG8gUHVibGljIDRvdmVyNiBtZWNoYW5pc20gYW5kIG90aGVyIHR1bm5lbGluZyB0ZWNobmlx dWVzIHdoZW4gREhDUCBpcyBpbnZvbHZlZC4NCkNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyB3b3Vs ZCBiZSBhcHByZWNpYXRlZC4gIFRoYW5rcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tCQkJCSANClBl bmcgV3UNCjIwMTEtMDctMTENCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJvbe+8mmludGVybmV0LWRyYWZ0cw0KRGF0Ze+8 mjIwMTEtMDctMTEgMTU6NDk6NDgNClRv77yad2VhcG9uDQpDQ++8mndlYXBvbjsgamlhbnBpbmc7 IHlvbmcNClN1YmplY3TvvJpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yICBkcmFmdC1jdWkt c29mdHdpcmUtZGhjcC1vdmVyLXR1bm5lbC0wMS50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LWN1aS1zb2Z0d2lyZS1kaGNwLW92ZXItdHVubmVsLTAxLnR4dCBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBlbmcgV3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWN1aS1zb2Z0d2lyZS1kaGNwLW92ZXItdHVubmVs DQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBESENQdjQgQmVoYXZpb3Igb3ZlciBJUC1JUCB0dW5u ZWwNCkNyZWF0aW9uIGRhdGU6CSAyMDExLTA3LTExDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCk51bWJlciBvZiBwYWdlczogMTENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50 IGFuYWx5emVzIHRoZSBzY2VuYXJpbyBpbiB3aGljaCBESENQdjQgaW50ZXJhY3Rpb24gaXMNCiAg IHBlcmZvcm1lZCBvdmVyIElQLUlQIHR1bm5lbCwgYW5kIHByb3Bvc2VzIG1ldGhvZHMgdG8ga2Vl cCBESENQDQogICB3b3JraW5nIHVuZGVyIHN1Y2ggc2l0dWF0aW9uLiAgVGhlIG1haW4gaXNzdWUg aXMgZW5jYXBzdWxhdGlvbiBvZg0KICAgREhDUCBwYWNrZXRzIG9uIHNlcnZlciBzaWRlLCBhbmQg dGhlcmUgYXJlIGJvdGggaW4tcHJvdG9jb2wgYW5kIG91dC0NCiAgIG9mLXByb3RvY29sIHNvbHV0 aW9ucyBmb3IgdGhpcyBpc3N1ZS4gIFRoZSBpbi1wcm90b2NvbCBzb2x1dGlvbiBpcyB0bw0KICAg aGF2ZSBESENQIGNhcnJ5aW5nIHRoZSBlbmNhcHN1bGF0aW9uIGFkZHJlc3MgaW5mb3JtYXRpb24s IGFuZCB0aGUNCiAgIG91dC1vZi1wcm90b2NvbCBzb2x1dGlvbiBpcyB0byBoYXZlIHRoZSBESENQ IHNlcnZlciBrZWVwaW5nIHRyYWNrIG9mDQogICB0aGUgYWRkcmVzcyBtYXBwaW5nIGJ5IGluc3Bl Y3RpbmcgREhDUCBwYWNrZXRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg== From bingxuere@gmail.com Mon Jul 11 09:53:49 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B583B21F8D25 for ; Mon, 11 Jul 2011 09:53: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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRHS1nVm4PAa for ; Mon, 11 Jul 2011 09:53:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA28921F8CB2 for ; Mon, 11 Jul 2011 09:53:47 -0700 (PDT) Received: by iye7 with SMTP id 7so4688296iye.31 for ; Mon, 11 Jul 2011 09:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=A3Am+m4xGu5wMUDETmbnyG/n+uwIafOqjDBncG2AJys=; b=HKXmLixKXlUTB9eLHUnXC1+Z3cN5o93nGaNMW693+V6RHFvTxdmwVUbDHH1P6a2p6R l987DI3coZkm7Xwnitb9Jxq152ZTyQNEFcJh1R7CKM8ekI7QOmGYzIT74Ol4W4kx4lHA 5KZ3PoR4lTar31QkuQ+n1Fk85poNO04vuDpHQ= Received: by 10.42.19.73 with SMTP id a9mr4984423icb.335.1310403227240; Mon, 11 Jul 2011 09:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.130 with HTTP; Mon, 11 Jul 2011 09:53:27 -0700 (PDT) In-Reply-To: <201107111604365820525@csnet1.cs.tsinghua.edu.cn> References: <5D36713D8A4E7348A7E10DF7437A4B9286BE98@SZXEML504-MBX.china.huawei.com> <201107111604365820525@csnet1.cs.tsinghua.edu.cn> From: Qiong Date: Tue, 12 Jul 2011 00:53:27 +0800 Message-ID: To: cuiyong@tsinghua.edu.cn, adurand@juniper.net, softwires@ietf.org Content-Type: multipart/alternative; boundary=20cf301d4274df486504a7ce06cd Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:53:49 -0000 --20cf301d4274df486504a7ce06cd Content-Type: text/plain; charset=UTF-8 Hi chairs, We would like to present the following draft of Lightweight 4over6 Presenter: Chongfeng Xie Draft: Lightweight 4over6 Link: http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt 5 minutes for this slot. Thanks --20cf301d4274df486504a7ce06cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi chairs,

We would like to present the follow= ing draft of Lightweight 4over6

Presenter: =C2= =A0Chongfeng Xie
Draft: Lightweight 4over6
Link:=C2=A0http://www.ietf.org/id/draft-cui-softwire-b4-translated-ds-lite-01.txt=

5 minutes for this slot.

Thank= s=C2=A0
=C2=A0
--20cf301d4274df486504a7ce06cd-- From shtsuchi@cisco.com Mon Jul 11 10:50:30 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3845821F8E41 for ; Mon, 11 Jul 2011 10:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASRDqRGwwt4l for ; Mon, 11 Jul 2011 10:50:28 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0349F21F8784 for ; Mon, 11 Jul 2011 10:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=935; q=dns/txt; s=iport; t=1310406628; x=1311616228; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vTbnri3oT9d0w+qZXmwn1LDWhUSF+Wv4Z9TXUtYuoDA=; b=Pzx2rIZK7ExfRNsVwnUodjx4YZZo6y2sjyYrWAoFbgqOv8XE6ReL5KUt l9gjNxkOysKwwWy3sOKL7peObsOrl+T0I8H+Qj48M3jAIz9jLEyBuBulX KHWnSXGmr567mTReeJiw3acrMyWf9IlmYxpuF9ZArHNwq5bvmhr9qqb8N s=; X-IronPort-AV: E=Sophos;i="4.65,516,1304294400"; d="scan'208";a="41611308" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 11 Jul 2011 17:50:26 +0000 Received: from [10.71.53.168] (tky-shtsuchi-8917.cisco.com [10.71.53.168]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6BHoM1u017993; Mon, 11 Jul 2011 17:50:23 GMT Message-ID: <4E1B37DF.40809@cisco.com> Date: Mon, 11 Jul 2011 10:50:23 -0700 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: cuiyong@tsinghua.edu.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 17:50:30 -0000 Hi Alain & Yong: We would like to do presentation the draft in IETF81. The draft describes a use case in japan which uses 6rd to and within a datacenter to deploy IPv6 to datacenters themselves and directly to servers within the datacenter. Yong Cui wrote: > Hi guys, > > If you are planing to present something in the Softwire WG in Quebec City, > please send your agenda item requests to Alain and me by 7/12 in the > following format: > (presenter's name, draft name, ietf link) Shishio Tsuchiya,draft-sakura-6rd-datacenter-01,http://www.ietf.org/id/draft-sakura-6rd-datacenter-01.txt reuest 10min -> 15min Regards, -Shishio > > We also need your slides by Saturday 7/23 (before the meeting starts). > > Thanks. > > - Alain& Yong. > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From tetsuya@ipinfusion.com Mon Jul 11 21:22:42 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05811E8158 for ; Mon, 11 Jul 2011 21:22:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZobnxkUrbI-b for ; Mon, 11 Jul 2011 21:22:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9737B11E8071 for ; Mon, 11 Jul 2011 21:22:41 -0700 (PDT) Received: by iye7 with SMTP id 7so5211082iye.31 for ; Mon, 11 Jul 2011 21:22:40 -0700 (PDT) Received: by 10.42.145.196 with SMTP id g4mr5061670icv.267.1310444560478; Mon, 11 Jul 2011 21:22:40 -0700 (PDT) Received: from [192.168.0.6] (c-76-102-170-116.hsd1.ca.comcast.net [76.102.170.116]) by mx.google.com with ESMTPS id hx9sm343188icc.0.2011.07.11.21.22.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jul 2011 21:22:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tetsuya Murakami In-Reply-To: Date: Mon, 11 Jul 2011 21:22:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <38555C21-4AE6-45DC-843A-87620A173212@ipinfusion.com> References: To: Yong Cui , Alain Durand X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg list , Ole Troan Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 04:22:42 -0000 Hi Chairs, We would like to do the following presentation. Presenter's name: Tetsuya Murakami Draft name: IPv4 Residual Deployment on IPv6 infrastructure - protocol = specification IETF link: http://tools.ietf.org/html/draft-murakami-softwire-4rd-00 10min for this slot. Thanks, Tetsuya Murakami On 2011/07/06, at 18:37, Yong Cui wrote: > Hi guys, >=20 > If you are planing to present something in the Softwire WG in Quebec = City, > please send your agenda item requests to Alain and me by 7/12 in the > following format: > (presenter's name, draft name, ietf link) >=20 > We also need your slides by Saturday 7/23 (before the meeting starts). >=20 > Thanks. >=20 > - Alain & Yong. >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From shtsuchi@cisco.com Tue Jul 12 01:45:03 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C96621F903B for ; Tue, 12 Jul 2011 01:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBgrvv8dbKiu for ; Tue, 12 Jul 2011 01:45:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C04FC21F9037 for ; Tue, 12 Jul 2011 01:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=863; q=dns/txt; s=iport; t=1310460302; x=1311669902; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=xwpMioCeLrPW/16Ug00WDrQyfdanEVxCjOfA+trVwUc=; b=RaupAsszuIcjsk2/A0g3o4VrH3ZVHKJDVj8k3m/f/orz6ZpkBdEYy/ZW 0PiUlrJc03ebgpj+o74Eih7ooa69IGwM1csQrMutMOTSow9j2yivmwrR1 IJmcEw7LUhuU/jApfff/MSRrlk2qfwM4BosrFxHLoKICttWVXf1jvCEsj M=; X-IronPort-AV: E=Sophos;i="4.65,520,1304294400"; d="scan'208";a="101227017" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 12 Jul 2011 08:45:00 +0000 Received: from [64.104.52.191] (dhcp-tmt-wirelessdata-64-104-52-191.cisco.com [64.104.52.191]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6C8ixu3020048; Tue, 12 Jul 2011 08:44:59 GMT Message-ID: <4E1C098B.1090808@cisco.com> Date: Tue, 12 Jul 2011 17:44:59 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: cuiyong@tsinghua.edu.cn References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:45:03 -0000 Hi Alain & Yong: Sorry,could you ignore my previous mail? We would like to do presentation the draft in IETF81. Presenter's name: Shishio Tsuchiya Draft name: IPv6 Rapid Deployment (6rd) in a Large Data Center IETF link:http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01 10min for this slot. Regards, -Shishio Yong Cui wrote: > Hi guys, > > If you are planing to present something in the Softwire WG in Quebec City, > please send your agenda item requests to Alain and me by 7/12 in the > following format: > (presenter's name, draft name, ietf link) > > We also need your slides by Saturday 7/23 (before the meeting starts). > > Thanks. > > - Alain& Yong. > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From jacniq@gmail.com Tue Jul 12 07:22:55 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D91D21F9049 for ; Tue, 12 Jul 2011 07:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKqWMSb9fSpn for ; Tue, 12 Jul 2011 07:22:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35821F9047 for ; Tue, 12 Jul 2011 07:22:54 -0700 (PDT) Received: by vxi40 with SMTP id 40so5160200vxi.31 for ; Tue, 12 Jul 2011 07:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M7orqKyuM28ZQXEnNBxEy0hwcAbJWRc1hlEhzchw1jU=; b=UQfQliUwz6dl/Ri7TI19uUQGh7tOtRU665buTCvVSmWiw+6gMmUO2Sy35szNXq1Ser K6obVXSpas4suaMfqBRNHVyqabOPibToAhjR/M0xifaKOY/kJjnuR6hZwCBI6n2qp0YU lLRDaSaDitEUTbDU40wbteRxq2rT5RxrBfSKI= MIME-Version: 1.0 Received: by 10.52.99.74 with SMTP id eo10mr3556271vdb.322.1310480573078; Tue, 12 Jul 2011 07:22:53 -0700 (PDT) Received: by 10.52.110.133 with HTTP; Tue, 12 Jul 2011 07:22:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jul 2011 22:22:52 +0800 Message-ID: From: Jacni Qin To: Yong Cui , Alain Durand Content-Type: multipart/alternative; boundary=20cf307d047a0b1d9d04a7e009b0 Cc: Softwires-wg list Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:22:55 -0000 --20cf307d047a0b1d9d04a7e009b0 Content-Type: text/plain; charset=ISO-8859-1 hi Chairs, We'd like to present the DS-Lite Multicast draft, Presenter: Yiu Lee Draft: Multicast Extensions to DS-Lite http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04 Cheers, Jacni On Thu, Jul 7, 2011 at 9:37 AM, Yong Cui wrote: > Hi guys, > > If you are planing to present something in the Softwire WG in Quebec City, > please send your agenda item requests to Alain and me by 7/12 in the > following format: > (presenter's name, draft name, ietf link) > > We also need your slides by Saturday 7/23 (before the meeting starts). > > Thanks. > > - Alain & Yong. > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf307d047a0b1d9d04a7e009b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Chairs,

We'd like to pr= esent the DS-Lite Multicast draft,

Presenter: Yiu Lee
Draft: Multicast Extensions to DS-Lite=
http= ://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04


Cheers,
Jacni

On Thu= , Jul 7, 2011 at 9:37 AM, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;"> Hi guys,

If you are planing to present something in the Softwire WG in Quebec City,<= br> please send your agenda item requests to Alain and me by 7/12 in the
following format:
(presenter's name, draft name, ietf link)

We also need your slides by Saturday 7/23 (before the meeting starts).

Thanks.

- Alain & Yong.


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

--20cf307d047a0b1d9d04a7e009b0-- From wdec.ietf@gmail.com Thu Jul 14 06:41:46 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53B221F876E for ; Thu, 14 Jul 2011 06:41:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K543IkqMFS7V for ; Thu, 14 Jul 2011 06:41:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5648E21F8736 for ; Thu, 14 Jul 2011 06:41:46 -0700 (PDT) Received: by iye7 with SMTP id 7so258965iye.31 for ; Thu, 14 Jul 2011 06:41:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IhTaTG+Uj2mXbulIBoEc1sHE221tysmsBY6hmS6ZPZQ=; b=VWlcU86ssiJGIhbdQmNfs/Af04qOGuaMXmQ8T9T/Wv8A5hQg8ufdDp4F0qA3mMhidm 89romiyR76M6Oh9glbWPt8+t4HbVpyhmYBRyw6bLrBZ1HmTIIC7je9NqxPbqLrQBDxGy 74gyrZ36dfgp9ELlBjs6qwJXJdWLv+MG94in0= MIME-Version: 1.0 Received: by 10.143.98.14 with SMTP id a14mr994928wfm.198.1310650905570; Thu, 14 Jul 2011 06:41:45 -0700 (PDT) Received: by 10.142.136.8 with HTTP; Thu, 14 Jul 2011 06:41:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Jul 2011 15:41:45 +0200 Message-ID: From: Wojciech Dec To: Yong Cui , adurand@juniper.net Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires-wg list , Congxiao Bao , rajiva@cisco.com Subject: Re: [Softwires] Call for Agenda @ IETF 81 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:41:47 -0000 Hello Yong & Alain, given that there seems to be numerous stateless 4 in/over/across 6 contributions, could you please also add a slot for : http://tools.ietf.org/html/draft-dec-stateless-4v6 , which discusses generally attributed issues, ways of mitigation, as well as transport modes. Thanks, Woj. From adurand@juniper.net Mon Jul 18 06:56:48 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324FC21F8BE1 for ; Mon, 18 Jul 2011 06:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEAf3pUSK6cL for ; Mon, 18 Jul 2011 06:56:47 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 776B021F8BE0 for ; Mon, 18 Jul 2011 06:56:47 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTiQ7nodWF9QubkuVraaLcg4Fx4Gk/B/5@postini.com; Mon, 18 Jul 2011 06:56:47 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; Mon, 18 Jul 2011 06:55:25 -0700 From: Alain Durand To: "softwires@ietf.org list" Date: Mon, 18 Jul 2011 06:55:23 -0700 Thread-Topic: IETF81 agenda Thread-Index: AcxFUlgEHDK244VqR7Stwta8XdKQPA== Message-ID: 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: [Softwires] IETF81 agenda X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:56:48 -0000 The agenda has been posted. - Alain & Yong. From adurand@juniper.net Mon Jul 18 07:00:26 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E4121F8C30 for ; Mon, 18 Jul 2011 07:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ldoBEy71prH for ; Mon, 18 Jul 2011 07:00:25 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8D78821F8C31 for ; Mon, 18 Jul 2011 07:00:25 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTiQ8eAl5cY3iT5zJsHxWxUCjYga7diG0@postini.com; Mon, 18 Jul 2011 07:00:25 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 18 Jul 2011 07:00:03 -0700 From: Alain Durand To: "softwires@ietf.org list" Date: Mon, 18 Jul 2011 07:00:01 -0700 Thread-Topic: WG last call on draft-ietf-softwire-gateway-init-ds-lite-05 Thread-Index: AcxFUv10LWpNXugsQaePVuUROKS0Aw== Message-ID: 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: [Softwires] WG last call on draft-ietf-softwire-gateway-init-ds-lite-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:00:26 -0000 This is a wg last call for draft-ietf-softwire-gateway-init-ds-lite-05. As usual, please send editorial comments to the authors and substantive com= ments to the mailing list. This wg last call will end August 1st at 9am EDT. (after the IETF81 meeting= ) Alain & Yong.= From dongjiang@csnet1.cs.tsinghua.edu.cn Fri Jul 8 20:25:41 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7803921F8C00 for ; Fri, 8 Jul 2011 20:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.114 X-Spam-Level: * X-Spam-Status: No, score=1.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FROM_EXCESS_BASE64=1.456, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBzsUIicSXcj for ; Fri, 8 Jul 2011 20:25:41 -0700 (PDT) Received: from mail.jzland.com (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8621F8BF9 for ; Fri, 8 Jul 2011 20:25:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTP id B77CA30B0AB0; Sat, 9 Jul 2011 11:25:30 +0800 (CST) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sat Jul 9 11:25:30 2011 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 1,4e17ca2a39131522486508 X-DSPAM-Factors: 27, managing , 0.01000, }+OL, 0.01000, D, 0.01000, D, 0.01000, + , 0.01000, Softwire, 0.01000, Softwire, 0.01000, softwire, 0.01000, softwire, 0.01000, relationship, 0.01000, relationship, 0.01000, Type>+BLOCKQUOTE, 0.01000 X-Virus-Scanned: amavisd-new at jzland.com Received: from mail.jzland.com ([127.0.0.1]) by localhost (mail.jzland.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbXk7O64lTWn; Sat, 9 Jul 2011 11:25:29 +0800 (CST) Received: from DJ-PC (unknown [166.111.68.231]) by mail.jzland.com (EMOS V1.4 (Postfix)) with ESMTPA id E7DD830B092B; Sat, 9 Jul 2011 11:25:29 +0800 (CST) Date: Sat, 9 Jul 2011 11:25:40 +0800 From: "=?utf-8?B?SmlhbmcgRG9uZw==?=" To: "=?utf-8?B?c29mdHdpcmVz?=" Message-ID: <201107091125152556485@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon221382837566_=====" X-Mailman-Approved-At: Mon, 18 Jul 2011 09:11:09 -0700 Cc: =?utf-8?B?Q1VJIFlvbmc=?= Subject: [Softwires] =?utf-8?q?Fw=3A_New_Version_Notification_for_draft-cu?= =?utf-8?q?i-softwire-mesh-mib-02=2Etxt?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 03:25:41 -0000 This is a multi-part message in MIME format. --=====003_Dragon221382837566_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpBIG5ldyB2ZXJzaW9uIG9mIFNvZnR3aXJlIE1lc2ggTUlCIGhhcyBiZWVuIHN1Ym1pdHRl ZC4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY3VpLXNvZnR3aXJlLW1lc2gtbWli LTAyIA0KDQpUaGlzIHZlcnNpb24gaW50cmR1Y2VzIHRoZSByZWxhdGlvbnNoaXAgd2l0aCBJZiBN SUIgYW5kIElQIFR1bm5lbCBNSUIuIFNpbmNlIHRoZXJlJ3Mgbm8gZW5jYXBzdWxhdGlvbiBtZXNz YWdlIGluIHRoZSBJUCB0dW5uZWwgTUlCLCB3ZSBhZGQgYW4gZW5jYXBzdWxhdGlvbiB0YWJsZSBp biB0aGUgc29mdHdpcmUgbWVzaCBNSUIuIFNvbWUgb3RoZXIgc3BlY2lmaWMgb2JqZWN0cyBhYm91 dCBzb2Z0d2lyZSBtZXNoIE1JQiBhbHNvIGhhdmUgYmVlbiBhZGRlZC4NCg0KQW55IGNvbW1lbnRz IGFyZSBhcHByZWNpYXRlZCENCg0KMjAxMS0wNy0wOQ0KDQoNCg0KSmlhbmcgRG9uZw0KDQoNCg0K RnJvbTogaW50ZXJuZXQtZHJhZnRzDQpEYXRl77yaMjAxMS0wNy0wNyAyMzoyNjo1Mw0KVG/vvJpk b25namlhbmcNCkND77yad2VhcG9uOyB5b25nOyBkb25namlhbmcNClN1YmplY3TvvJpOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWN1aS1zb2Z0d2lyZS1tZXNoLW1pYi0wMi50eHQN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWN1aS1zb2Z0d2lyZS1tZXNoLW1pYi0wMi50 eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaWFuZyBEb25nIGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCkZpbGVuYW1lOiAgZHJhZnQtY3VpLXNvZnR3aXJl LW1lc2gtbWliDQpSZXZpc2lvbjogIDAyDQpUaXRsZTogIFNvZnR3aXJlIE1lc2ggTWFuYWdlbWVu dCBJbmZvcm1hdGlvbiBCYXNlKE1JQikNCkNyZWF0aW9uIGRhdGU6ICAyMDExLTA3LTA3DQpXRyBJ RDogIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNA0KQWJzdHJhY3Q6 DQogICBUaGlzIG1lbW8gZGVmaW5lcyBhIHBvcnRpb24gb2YgdGhlIE1hbmFnZW1lbnQgSW5mb3Jt YXRpb24gQmFzZSAoTUlCKQ0KICAgZm9yIHVzZSB3aXRoIG5ldHdvcmsgbWFuYWdlbWVudCBwcm90 b2NvbHMgaW4gdGhlIEludGVybmV0IGNvbW11bml0eS4NCiAgIEluIHBhcnRpY3VsYXIgaXQgZGVm aW5lcyBvYmplY3RzIGZvciBtYW5hZ2luZyBzb2Z0d2lyZSBtZXNoDQogICBbUkZDNTU2NV0uDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K --=====003_Dragon221382837566_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxTVFlMRT5CTE9DS1FVT1RFIHsNCglN QVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweDsgTUFSR0lOLUxFRlQ6IDJlbQ0KfQ0K T0wgew0KCU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQpVTCB7DQoJTUFS R0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIG5h bWU9R0VORVJBVE9SIGNvbnRlbnQ9Ik1TSFRNTCA4LjAwLjc2MDAuMTYzODUiPjwvSEVBRD4NCjxC T0RZIHN0eWxlPSJNQVJHSU46IDEwcHgiPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8RElW PkhpLDwvRElWPg0KPERJViBzdHlsZT0iVEVYVC1JTkRFTlQ6IDJlbSI+QSBuZXcgdmVyc2lvbiBv ZiBTb2Z0d2lyZSBNZXNoIE1JQiBoYXMgYmVlbiANCnN1Ym1pdHRlZC4gPEEgDQpocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jdWktc29mdHdpcmUtbWVzaC1taWItMDIiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWN1aS1zb2Z0d2lyZS1tZXNoLW1pYi0wMjwv QT4gDQo8L0RJVj4NCjxESVYgc3R5bGU9IlRFWFQtSU5ERU5UOiAyZW0iPiZuYnNwOzwvRElWPg0K PERJViBzdHlsZT0iVEVYVC1JTkRFTlQ6IDJlbSI+VGhpcyB2ZXJzaW9uIGludHJkdWNlcyB0aGUg cmVsYXRpb25zaGlwIHdpdGggSWYgDQpNSUIgYW5kIElQIFR1bm5lbCBNSUIuIFNpbmNlIHRoZXJl J3Mgbm8gZW5jYXBzdWxhdGlvbiBtZXNzYWdlIGluIHRoZSBJUCB0dW5uZWwgDQpNSUIsIHdlIGFk ZCBhbiBlbmNhcHN1bGF0aW9uIHRhYmxlIGluIHRoZSBzb2Z0d2lyZSBtZXNoIE1JQi4gU29tZSBv dGhlciBzcGVjaWZpYyANCm9iamVjdHMgYWJvdXQgc29mdHdpcmUgbWVzaCBNSUIgYWxzbyBoYXZl IGJlZW4gYWRkZWQuPC9ESVY+DQo8RElWIHN0eWxlPSJURVhULUlOREVOVDogMmVtIj4mbmJzcDs8 L0RJVj4NCjxESVYgc3R5bGU9IlRFWFQtSU5ERU5UOiAyZW0iPkFueSBjb21tZW50cyBhcmUgYXBw cmVjaWF0ZWQhPC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVy ZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzAgc2l6ZT0y IGZhY2U9VmVyZGFuYT4yMDExLTA3LTA5PC9GT05UPjwvRElWPjxGT05UIA0KY29sb3I9IzAwMDA4 MCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHgiIGFsaWduPWxl ZnQgY29sb3I9I2I1YzRkZiBTSVpFPTE+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMw YzAgc2l6ZT0yIGZhY2U9VmVyZGFuYT48U1BBTj5KaWFuZyANCkRvbmc8L1NQQU4+PC9GT05UPjwv RElWPjxGT05UIGNvbG9yPSMwMDAwODAgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxIUiBjb2xvcj0j YjVjNGRmIFNJWkU9MT4NCjwvRk9OVD4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48 U1RST05HPkZyb206IA0KPC9TVFJPTkc+aW50ZXJuZXQtZHJhZnRzPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgDQpmYWNlPVZlcmRhbmE+PFNUUk9ORz5EYXRl77yaPC9TVFJPTkc+MjAx MS0wNy0wNyZuYnNwOzIzOjI2OjUzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFj ZT1WZXJkYW5hPjxTVFJPTkc+VG/vvJo8L1NUUk9ORz5kb25namlhbmc8L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PFNUUk9ORz5DQ++8mjwvU1RST05HPndlYXBv bjsgeW9uZzsgDQpkb25namlhbmc8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNl PVZlcmRhbmE+PFNUUk9ORz5TdWJqZWN077yaPC9TVFJPTkc+TmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIA0KZm9yIGRyYWZ0LWN1aS1zb2Z0d2lyZS1tZXNoLW1pYi0wMi50eHQ8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJVj5BJm5ic3A7bmV3Jm5ic3A7dmVyc2lv biZuYnNwO29mJm5ic3A7SS1ELCZuYnNwO2RyYWZ0LWN1aS1zb2Z0d2lyZS1tZXNoLW1pYi0wMi50 eHQmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c3VjY2Vzc2Z1bGx5Jm5ic3A7c3VibWl0dGVkJm5i c3A7YnkmbmJzcDtKaWFuZyZuYnNwO0RvbmcmbmJzcDthbmQmbmJzcDtwb3N0ZWQmbmJzcDt0byZu YnNwO3RoZSZuYnNwO0lFVEYmbmJzcDtyZXBvc2l0b3J5LjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+RmlsZW5hbWU6ICZuYnNwO2RyYWZ0LWN1aS1zb2Z0d2lyZS1tZXNoLW1pYjwvRElWPg0KPERJ Vj5SZXZpc2lvbjogJm5ic3A7MDI8L0RJVj4NCjxESVY+VGl0bGU6IA0KJm5ic3A7U29mdHdpcmUm bmJzcDtNZXNoJm5ic3A7TWFuYWdlbWVudCZuYnNwO0luZm9ybWF0aW9uJm5ic3A7QmFzZShNSUIp PC9ESVY+DQo8RElWPkNyZWF0aW9uJm5ic3A7ZGF0ZTogJm5ic3A7MjAxMS0wNy0wNzwvRElWPg0K PERJVj5XRyZuYnNwO0lEOiAmbmJzcDtJbmRpdmlkdWFsJm5ic3A7U3VibWlzc2lvbjwvRElWPg0K PERJVj5OdW1iZXImbmJzcDtvZiZuYnNwO3BhZ2VzOiZuYnNwOzE0PC9ESVY+DQo8RElWPjwvRElW Pg0KPERJVj5BYnN0cmFjdDo8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyZuYnNw O21lbW8mbmJzcDtkZWZpbmVzJm5ic3A7YSZuYnNwO3BvcnRpb24mbmJzcDtvZiZuYnNwO3RoZSZu YnNwO01hbmFnZW1lbnQmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO0Jhc2UmbmJzcDsoTUlCKTwvRElW Pg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtmb3ImbmJzcDt1c2UmbmJzcDt3aXRoJm5ic3A7bmV0 d29yayZuYnNwO21hbmFnZW1lbnQmbmJzcDtwcm90b2NvbHMmbmJzcDtpbiZuYnNwO3RoZSZuYnNw O0ludGVybmV0Jm5ic3A7Y29tbXVuaXR5LjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtJ biZuYnNwO3BhcnRpY3VsYXImbmJzcDtpdCZuYnNwO2RlZmluZXMmbmJzcDtvYmplY3RzJm5ic3A7 Zm9yJm5ic3A7bWFuYWdpbmcmbmJzcDtzb2Z0d2lyZSZuYnNwO21lc2g8L0RJVj4NCjxESVY+Jm5i c3A7Jm5ic3A7Jm5ic3A7W1JGQzU1NjVdLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj48 L0RJVj4NCjxESVY+VGhlJm5ic3A7SUVURiZuYnNwO1NlY3JldGFyaWF0PC9ESVY+DQo8RElWPjwv RElWPjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon221382837566_=====-- From despres.remi@laposte.net Sat Jul 16 06:55:45 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E8F21F85BB for ; Sat, 16 Jul 2011 06:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrfnrUCDQ5Tg for ; Sat, 16 Jul 2011 06:55:41 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0A57821F85BA for ; Sat, 16 Jul 2011 06:55:40 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2307.sfr.fr (SMTP Server) with ESMTP id 31770700008C for ; Sat, 16 Jul 2011 15:55:39 +0200 (CEST) Received: from [192.168.1.62] (88.204.170.89.rev.sfr.net [89.170.204.88]) by msfrf2307.sfr.fr (SMTP Server) with ESMTP id 07287700008A for ; Sat, 16 Jul 2011 15:55:38 +0200 (CEST) X-SFR-UUID: 20110716135539294.07287700008A@msfrf2307.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 16 Jul 2011 15:55:38 +0200 Message-Id: <13AEF630-13AC-467C-884C-7F26A1A23284@laposte.net> To: Softwires-wg Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 18 Jul 2011 09:11:09 -0700 Subject: [Softwires] stateless IPv4 via IPv6 - 4rd mapping common to the two 4V6 approaches ("4V6T" & "4V6E") X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:55:45 -0000 Hi all, 1. Being active in the IETF community has been overall enjoyable but, for = various personal reasons including financial, I will no longer contribute as much as before on v4/v6 transition = solutions (6rd, 4rd, 6a44). This is the reason why I didn't pursue authorship responsibility for the = last softwire-4rd draft (thanks to Tetsuya Murakami and Ole Troan for = having taken over). Although not going to Quebec, I hope that my remaining email = contributions, including this one, will be taken in consideration to = optimize the 4v6 end result. 2. Both the proposed translation-based solution = (draft-murakami-softwire-4v6-translation) and the proposed tunnel-based = solution (draft-murakami-softwire-4rd) use the v4v6 address mapping = algorithm, that of 4rd. It would therefore be advantageous to have an autonomous I-D on the 4rd = address mapping, and two I-D's pointing to it (for the translation-based = and for the tunnel-based solution). Proposed respective acronyms: "4V6T" (translation) and "4V6E" (E for = Encapsulation).=20 In the analysis of stateless 4via6 solutions, initiated in = draft-dec-stateless-4v6, issues related to the following specifications = could then be better isolated: 4V6 in general, 4rd, 4V6T, 4V6E. Kind regards, RD From despres.remi@laposte.net Mon Jul 18 08:26:31 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E2221F85AA for ; Mon, 18 Jul 2011 08:26:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSyzrfu4EOUf for ; Mon, 18 Jul 2011 08:26: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 8C39F21F85EE for ; Mon, 18 Jul 2011 08:26:29 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2322.sfr.fr (SMTP Server) with ESMTP id DC1C17000093 for ; Mon, 18 Jul 2011 17:26:27 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2322.sfr.fr (SMTP Server) with ESMTP id B470A7000092 for ; Mon, 18 Jul 2011 17:26:27 +0200 (CEST) X-SFR-UUID: 20110718152627739.B470A7000092@msfrf2322.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 17:26:27 +0200 Message-Id: <2479707A-0742-46DB-9A7F-A25F319ED61E@laposte.net> To: Softwires-wg Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 18 Jul 2011 09:11:09 -0700 Subject: [Softwires] 4V6 - 4rd mapping is part of both stateless approaches (4V6T & 4V6E) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:26:32 -0000 Hi all, Two stateless solutions are proposed for residual deployment of IPv4 = across IPv6-only provider services: - draft-murakami-softwire-4v6-translation, say 4V6T=20 - draft-murakami-softwire-4rd, say 4V6E (with E for encapsulation) They both use the same stateless address mapping, i.e. that of 4rd. It would therefore would be better, IMHO, to have: - a separate I-D on the 4rd address mapping - two solution I-D's pointing to it (one for 4V6T and one for 4V6E)). Thus comments on the I-D's would better separate what relates to: - Stateless IPv4 across IPv6-only in general (4V6) - Stateless address mappings between IPv4 and IPv6 (4rd) - Translation-based 4V6 (4V6T) - Encapsulation-based 4V6 (4V6E) Kind regards, RD NOTE: I really enjoyed working actively for IETF as initiator of 6rd, = 4rd, and 6a44, but, for various personal reasons including financial, I = now have to switch to another activity.=20 In particular: - Going to Quebec won't be possible.=20 - Pursuing with authorship responsibility for new 4rd drafts would have = been too much (thanks to Tetsuya Murakami and Ole Troan for having taken = over). From despres.remi@laposte.net Mon Jul 18 09:40:52 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E841F21F8BB9 for ; Mon, 18 Jul 2011 09:40:52 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1IeU953Ilwe for ; Mon, 18 Jul 2011 09:40:52 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF6821F8BCB for ; Mon, 18 Jul 2011 09:40:52 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2201.sfr.fr (SMTP Server) with ESMTP id 5714970000A2 for ; Mon, 18 Jul 2011 18:40:51 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2201.sfr.fr (SMTP Server) with ESMTP id 403DA700009E for ; Mon, 18 Jul 2011 18:40:51 +0200 (CEST) X-SFR-UUID: 20110718164051263.403DA700009E@msfrf2201.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 18:40:50 +0200 Message-Id: <0DF34D9B-13E3-4B5E-AC07-6582501B5E25@laposte.net> To: Softwires-wg Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] Sorry for the double transmission X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:40:53 -0000 Two messages have just been distributed to the list with different = source addresses but very similar contents . Apologies for that. (I had received a non-delivery response to the first one. It can be = ignored). RD =20= From phdgang@gmail.com Mon Jul 18 23:23:25 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32621F8696 for ; Mon, 18 Jul 2011 23:23:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzlaT-DNzUl9 for ; Mon, 18 Jul 2011 23:23:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED72321F8589 for ; Mon, 18 Jul 2011 23:23:24 -0700 (PDT) Received: by vws12 with SMTP id 12so3631874vws.31 for ; Mon, 18 Jul 2011 23:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dap9LA3Y/t+2yW4gj76i31CgdCzRq0ukuIP+4u/+nCQ=; b=OUaUIButjEj26g0laJMGz5LZ2Z2axUelcrvrnsLLj5zWc8Z6pB1lr81mEP0eONeUsi qPxIs9d+ep651r2808pCxNqZUceIngGlH/HlrzaKgmXgTB/PWsOxv8PpKMjfnlX4acN0 v3egED+1VDGGzstGYh9aPNG8fcpR8FLoPM4dk= MIME-Version: 1.0 Received: by 10.52.32.162 with SMTP id k2mr7488012vdi.50.1311056604463; Mon, 18 Jul 2011 23:23:24 -0700 (PDT) Received: by 10.52.169.194 with HTTP; Mon, 18 Jul 2011 23:23:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Jul 2011 14:23:24 +0800 Message-ID: From: GangChen To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] IETF81 agenda X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 06:23:25 -0000 Dear Chairs, The presentation "4via6 Stateless Translation"(i.e. topic 19) is highly related to topic 8 and 9. May I suggest to move topic 19 together with 8 and 9? That would be helpful for the discussion Many thanks Gang 2011/7/18, Alain Durand : > The agenda has been posted. > > - Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Tue Jul 19 01:56:07 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88B121F86BD for ; Tue, 19 Jul 2011 01:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT1B6q2lnRRl for ; Tue, 19 Jul 2011 01:56:07 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id EFD7621F86AB for ; Tue, 19 Jul 2011 01:56:05 -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 4A6A694011D; Tue, 19 Jul 2011 10:55:59 +0200 (CEST) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jul 2011 10:55:58 +0200 Message-Id: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> To: Softwires-wg Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Wojciech Dec Subject: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:56:07 -0000 Hi, all, 1. The translation-based stateless solution for IPv4 via IPv6 described in = draft-murakami-softwire-4v6-translation-00 seems to have a significant = limitation: - When a 4V6T customer-edge node receives a packet from a CE of the same = 4V6T domain, it doesn't know whether it must treat it as a native IPv6 = packet from this CE or as an IPv4 packet that this CE has translated.=20 <-- 4V6T domain --> <-- IPv4 Internet -- (A) 4V6T CE |---->----. | V---- 4v6T-BR --- - - -=20 | (B) 4V6T CE |----<----' <=3D v4 or v6 ?? For instance, if the IPv4 address of (B) is shared, (B) doesn't know = whether received packets must go to its internal NAT44, or be treated a = real IPv6 packet. (Sending to the NAT44 packets whose ports are currently bound in the = NAT44 wouldn't be satisfactory: all ports may be used in IPv6). 2. Note that this problem doesn't apply to the encapsulation-based = stateless solution (4V6E): - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet = if, and only if, its Next header is IP-in-IP, and the encapsulated = packet is IPv4. There is no ambiguity. =3D> Unless something is wrong in the above, or a palliative is devised, = consideration of this should be added to the comparative analysis of = 4V6T and 4V6E solutions (draft-dec-stateless-4v6). Regards, RD From mark@townsley.net Tue Jul 19 02:24:13 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5641B21F880C for ; Tue, 19 Jul 2011 02:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMr5OPEVG1cX for ; Tue, 19 Jul 2011 02:24:12 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 979CC21F8764 for ; Tue, 19 Jul 2011 02:24:12 -0700 (PDT) Received: by wwe5 with SMTP id 5so2693363wwe.13 for ; Tue, 19 Jul 2011 02:24:08 -0700 (PDT) Received: by 10.227.172.199 with SMTP id m7mr139788wbz.85.1311067448392; Tue, 19 Jul 2011 02:24:08 -0700 (PDT) Received: from [192.168.1.11] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id b13sm4173034wbh.58.2011.07.19.02.24.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 02:24:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Tue, 19 Jul 2011 11:24:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> References: To: Softwire Chairs X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:24:13 -0000 The schedule is obviously rather busy. Here's a suggestion: Softwires = has 30 minutes of Multicast transition presentation, while we have an = entire BoF devoted to the subject earlier in the week. Do we really need = to schedule time for this twice? - Mark On Jul 18, 2011, at 3:55 PM, Alain Durand wrote: > The agenda has been posted. >=20 > - Alain & Yong. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From behcetsarikaya@yahoo.com Tue Jul 19 08:18:54 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC2621F8A71 for ; Tue, 19 Jul 2011 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.943 X-Spam-Level: X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV3SWdXmsF1B for ; Tue, 19 Jul 2011 08:18:53 -0700 (PDT) Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by ietfa.amsl.com (Postfix) with SMTP id 9BC9D21F8A4F for ; Tue, 19 Jul 2011 08:18:53 -0700 (PDT) Received: from [98.139.91.70] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 19 Jul 2011 15:18:51 -0000 Received: from [98.139.91.44] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 19 Jul 2011 15:18:51 -0000 Received: from [127.0.0.1] by omp1044.mail.sp2.yahoo.com with NNFMP; 19 Jul 2011 15:18:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 101624.25343.bm@omp1044.mail.sp2.yahoo.com Received: (qmail 9431 invoked by uid 60001); 19 Jul 2011 15:18:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311088730; bh=Vfeg2YXZnVqGSAPQ9eavxq3Do06vBQPYh86Clp49ow4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ya7LQ5yViqBxii7+sCMasqlnlIPNnhO38QA2Z/1HHgyTqYTS09pwmycN0sJal6680SC+hxtNL1IUuILq3eGPiIcy3e6xgpY7ITQn5ilM39bXO0YPqfdG+1Ldmm0dy/VBFIyqKk18kL3eC2PAwBdN1a3yNf9ZVNT2iIGXrSb3Gzw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=x0xvpLUJtE6pSmeCMUxvJFWEuN6l6+EuoT677Fhfg2Ln/fzpK2RJFZ16PmjrjaNOhVm0oZ/VZa70Gf5jzfXNcXhkGRY8ycgrnvk3cnQuhCJYaAxaEtmnG0dDk0SZ2nkDQazMQ+120gvAtBucEq+I1qgCda5mL8RtCyyQG9AQxHI=; X-YMail-OSG: XPkcN8YVM1l.1J4Hb3j4Nr1KpiVE3eX0OgYTWwEHe.hD7lG FlFoCk9M2RhQ2NuxIyDeKsJGJFuq2TK28TLbD_W6MdL2RPM.5To3Qsb1BLaQ 0MLWsfkgXJBppuXvC4ToZKunc6dcAlP0B1vFdDenyfminhffKVS1vEg5flD4 E6KPBMdZ6nqk.sV7j4EZOoibQg8Py_WkqD2FY0QuBy4H3GIMEhZ3gl.PuoIM I44a3Psz3ErNDubNoYhwwAzNJv5lx.WxMxBR8Z90GI8na8XN.CgcNjYhMWHS fnuybtokaHAxo2M3f0lR5cGPJQBHjXJjiIGll57ojrlfKQmlhoHKrJRTlC9y MN1NQY7y_nsEVuj5i.xHriUKHQMFXREFWikb4qlmZzO2An4YSuO9qaE7xUnL XekB_gPCoW_JOyg-- Received: from [50.58.7.243] by web111407.mail.gq1.yahoo.com via HTTP; Tue, 19 Jul 2011 08:18:50 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.307740 References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> Message-ID: <1311088730.8201.YahooMailRC@web111407.mail.gq1.yahoo.com> Date: Tue, 19 Jul 2011 08:18:50 -0700 (PDT) From: Behcet Sarikaya To: Mark Townsley , Softwire Chairs In-Reply-To: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "softwires@ietf.orglist" Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:18:54 -0000 > > The schedule is obviously rather busy. Here's a suggestion: Softwires has 30 >minutes of Multicast transition presentation, while we have an entire BoF >devoted to the subject earlier in the week. Do we really need to schedule time >for this twice? > Go stateless 4V6 go :-) Mark, Softwire has charter items for multicast solutions for Softwire developed transition technologies like 6rd, DS-Lite, etc. Prioritizing according to the charter deadlines could be a good idea, IMHO. Behcet From mark@townsley.net Tue Jul 19 09:16:26 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A24B21F84EF for ; Tue, 19 Jul 2011 09:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+52hXMZb2V5 for ; Tue, 19 Jul 2011 09:16:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99CED21F84EB for ; Tue, 19 Jul 2011 09:16:25 -0700 (PDT) Received: by wwe5 with SMTP id 5so2947078wwe.13 for ; Tue, 19 Jul 2011 09:16:24 -0700 (PDT) Received: by 10.227.57.211 with SMTP id d19mr6858303wbh.93.1311092184714; Tue, 19 Jul 2011 09:16:24 -0700 (PDT) Received: from [192.168.1.11] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fe4sm4474052wbb.11.2011.07.19.09.16.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 09:16:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <1311088730.8201.YahooMailRC@web111407.mail.gq1.yahoo.com> Date: Tue, 19 Jul 2011 18:16:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5363C9A9-958A-4C7A-A274-A7722F975ECB@townsley.net> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> <1311088730.8201.YahooMailRC@web111407.mail.gq1.yahoo.com> To: Behcet Sarikaya X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.orglist" , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:16:26 -0000 On Jul 19, 2011, at 5:18 PM, Behcet Sarikaya wrote: >=20 >=20 >>=20 >> The schedule is obviously rather busy. Here's a suggestion: Softwires = has 30 =20 >> minutes of Multicast transition presentation, while we have an entire = BoF =20 >> devoted to the subject earlier in the week. Do we really need to = schedule time =20 >> for this twice? >>=20 >=20 > Go stateless 4V6 go :-) >=20 > Mark, Softwire has charter items for multicast solutions for Softwire = developed=20 > transition technologies like 6rd, DS-Lite, etc. That's fine - as long as the presentation and call for discussion is = different than what we will see in the BoF. There is an abundance of = repeat presentation happening these days, and we should do our part to = avoid it. - Mark >=20 > Prioritizing according to the charter deadlines could be a good idea, = IMHO. >=20 > Behcet From phdgang@gmail.com Tue Jul 19 09:53:51 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A5A11E8082 for ; Tue, 19 Jul 2011 09:53:50 -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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWAtG1fMA978 for ; Tue, 19 Jul 2011 09:53:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50C4511E8088 for ; Tue, 19 Jul 2011 09:53:50 -0700 (PDT) Received: by vxi40 with SMTP id 40so4118310vxi.31 for ; Tue, 19 Jul 2011 09:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=pvS5iKCKU0TvSjlYbfDQgJXL+ylDktEvR5Z3W+2Wm44=; b=e1Sevw0fZqTUuOePIre/4tBOE2/ZZJq5N113UaA3HTdLUo8PYw8w4B4TRGFaLsXS7P hLDplpHviF2Fc6sVDZOIT8y9wozgHQwicJLxwzECqyZVd5VqEl3X7+6aaH4e50BM2cU1 58p4W0HVoJN2mNtsuFBZbkee7Jv2RlLzC30yA= MIME-Version: 1.0 Received: by 10.52.96.225 with SMTP id dv1mr7592832vdb.519.1311094429646; Tue, 19 Jul 2011 09:53:49 -0700 (PDT) Received: by 10.52.169.194 with HTTP; Tue, 19 Jul 2011 09:53:49 -0700 (PDT) In-Reply-To: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> References: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> Date: Wed, 20 Jul 2011 00:53:49 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:53:51 -0000 Hello Remi, I guess 4V6 CE need to recognize whether received IPv6 prefix is CE IPv6 prefix, which is used to generate a shared IPv4 address. Then, it should be no problem to distinguish native IPv6 or an IPv6 address CE should translated. Gang 2011/7/19, R=E9mi Despr=E9s : > Hi, all, > > 1. > The translation-based stateless solution for IPv4 via IPv6 described in > draft-murakami-softwire-4v6-translation-00 seems to have a significant > limitation: > - When a 4V6T customer-edge node receives a packet from a CE of the same > 4V6T domain, it doesn't know whether it must treat it as a native IPv6 > packet from this CE or as an IPv4 packet that this CE has translated. > > > <-- 4V6T domain --> <-- IPv4 Internet -- > > (A) 4V6T CE |---->----. > | > V---- 4v6T-BR --- - - - > | > (B) 4V6T CE |----<----' > <=3D v4 or v6 ?? > > For instance, if the IPv4 address of (B) is shared, (B) doesn't know whet= her > received packets must go to its internal NAT44, or be treated a real IPv6 > packet. > (Sending to the NAT44 packets whose ports are currently bound in the NAT4= 4 > wouldn't be satisfactory: all ports may be used in IPv6). > > 2. > Note that this problem doesn't apply to the encapsulation-based stateless > solution (4V6E): > - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet if= , > and only if, its Next header is IP-in-IP, and the encapsulated packet is > IPv4. There is no ambiguity. > > =3D> Unless something is wrong in the above, or a palliative is devised, > consideration of this should be added to the comparative analysis of 4V6T > and 4V6E solutions (draft-dec-stateless-4v6). > > > Regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From adurand@juniper.net Tue Jul 19 10:01:34 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F102E21F855B for ; Tue, 19 Jul 2011 10:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.88 X-Spam-Level: X-Spam-Status: No, score=-104.88 tagged_above=-999 required=5 tests=[AWL=-1.193, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUSPICIOUS_RECIPS=2.912, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwxH9o0GnASq for ; Tue, 19 Jul 2011 10:01:34 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6676721F8512 for ; Tue, 19 Jul 2011 10:01:18 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTiW4WdtL+bBk83SdsXodRAJIjBEToxdd@postini.com; Tue, 19 Jul 2011 10:01:22 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; Tue, 19 Jul 2011 09:59:34 -0700 From: Alain Durand To: Mark Townsley Date: Tue, 19 Jul 2011 09:59:33 -0700 Thread-Topic: [Softwires] IETF81 agenda (bashing) Thread-Index: AcxGNTxlBc2bZmdQQemOVMAIh+ckbA== Message-ID: <15AB825C-775D-4B8A-AAD6-D296393380AD@juniper.net> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> <1311088730.8201.YahooMailRC@web111407.mail.gq1.yahoo.com> <5363C9A9-958A-4C7A-A274-A7722F975ECB@townsley.net> In-Reply-To: <5363C9A9-958A-4C7A-A274-A7722F975ECB@townsley.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: "softwires@ietf.orglist" , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 17:01:35 -0000 Mark: Behcet is right. We have Multicast in our charter. The fact that some of th= ose discussions are repeated elsewhere is, I agree, unfortunate. However, Softwire is the place to discuss multicast on tunnel base transiti= on strategy. Stateless solution have also made it in the charter, and as you see, there = is a large portion of the agenda that is dedicated to this. - Alain. On Jul 19, 2011, at 12:16 PM, Mark Townsley wrote: >=20 > On Jul 19, 2011, at 5:18 PM, Behcet Sarikaya wrote: >=20 >>=20 >>=20 >>>=20 >>> The schedule is obviously rather busy. Here's a suggestion: Softwires h= as 30 =20 >>> minutes of Multicast transition presentation, while we have an entire B= oF =20 >>> devoted to the subject earlier in the week. Do we really need to schedu= le time =20 >>> for this twice? >>>=20 >>=20 >> Go stateless 4V6 go :-) >>=20 >> Mark, Softwire has charter items for multicast solutions for Softwire de= veloped=20 >> transition technologies like 6rd, DS-Lite, etc. >=20 > That's fine - as long as the presentation and call for discussion is diff= erent than what we will see in the BoF. There is an abundance of repeat pre= sentation happening these days, and we should do our part to avoid it. >=20 > - Mark >=20 >>=20 >> Prioritizing according to the charter deadlines could be a good idea, IM= HO. >>=20 >> Behcet >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tetsuya@ipinfusion.com Tue Jul 19 12:18:21 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9C621F857D for ; Tue, 19 Jul 2011 12:18:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZLL+I-JSONF for ; Tue, 19 Jul 2011 12:18:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 084DE21F8579 for ; Tue, 19 Jul 2011 12:18:17 -0700 (PDT) Received: by iwn39 with SMTP id 39so4725971iwn.31 for ; Tue, 19 Jul 2011 12:18:17 -0700 (PDT) Received: by 10.42.28.193 with SMTP id o1mr7589546icc.103.1311103097528; Tue, 19 Jul 2011 12:18:17 -0700 (PDT) Received: from [10.70.2.129] ([12.248.239.142]) by mx.google.com with ESMTPS id k16sm4639992icc.22.2011.07.19.12.18.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 12:18:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Tetsuya Murakami In-Reply-To: Date: Tue, 19 Jul 2011 12:18:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <22E359E7-CCB9-441C-B031-11D9A2BA3B51@ipinfusion.com> References: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec , =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 19:18:21 -0000 Hi Remi, In terms of 4via6 translation, 4via6 CE can process the received IPv6 = packets if the IPv6 destination address is the tunnel end-point address = which is assigned to that 4via6 CE and also the IPv6 source address is = the IPv4-embedded IPv6 address which is defined in RFC6052. If these = condition of IPv6 source and destination address is not matched, 4via6 = CE can process the received IPv6 packets as the normal IPv6 packet. So, = I don't think there is no issue which you raised. Thanks, Tetsuya Murakami On 2011/07/19, at 9:53, GangChen wrote: > Hello Remi, >=20 > I guess 4V6 CE need to recognize whether received IPv6 prefix is CE > IPv6 prefix, which is used to generate a shared IPv4 address. Then, it > should be no problem to distinguish native IPv6 or an IPv6 address CE > should translated. >=20 > Gang >=20 > 2011/7/19, R=C3=A9mi Despr=C3=A9s : >> Hi, all, >>=20 >> 1. >> The translation-based stateless solution for IPv4 via IPv6 described = in >> draft-murakami-softwire-4v6-translation-00 seems to have a = significant >> limitation: >> - When a 4V6T customer-edge node receives a packet from a CE of the = same >> 4V6T domain, it doesn't know whether it must treat it as a native = IPv6 >> packet from this CE or as an IPv4 packet that this CE has translated. >>=20 >>=20 >> <-- 4V6T domain --> <-- IPv4 Internet -- >>=20 >> (A) 4V6T CE |---->----. >> | >> V---- 4v6T-BR --- - - - >> | >> (B) 4V6T CE |----<----' >> <=3D v4 or v6 ?? >>=20 >> For instance, if the IPv4 address of (B) is shared, (B) doesn't know = whether >> received packets must go to its internal NAT44, or be treated a real = IPv6 >> packet. >> (Sending to the NAT44 packets whose ports are currently bound in the = NAT44 >> wouldn't be satisfactory: all ports may be used in IPv6). >>=20 >> 2. >> Note that this problem doesn't apply to the encapsulation-based = stateless >> solution (4V6E): >> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 = packet if, >> and only if, its Next header is IP-in-IP, and the encapsulated packet = is >> IPv4. There is no ambiguity. >>=20 >> =3D> Unless something is wrong in the above, or a palliative is = devised, >> consideration of this should be added to the comparative analysis of = 4V6T >> and 4V6E solutions (draft-dec-stateless-4v6). >>=20 >>=20 >> Regards, >> RD >> _______________________________________________ >> 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 jacniq@gmail.com Tue Jul 19 17:36:39 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7529721F8506 for ; Tue, 19 Jul 2011 17:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SUSPICIOUS_RECIPS=2.912] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLIbGPIJ+ez0 for ; Tue, 19 Jul 2011 17:36:38 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A59C111E808B for ; Tue, 19 Jul 2011 17:36:38 -0700 (PDT) Received: by vws12 with SMTP id 12so4395682vws.31 for ; Tue, 19 Jul 2011 17:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WeKGT/fT3YDoh1OiTsl7WdRfzwL9WOeQrLatWIkM5AE=; b=pFGveuLQgmR+gwkjapbu1YkayQyCe0R5r0Yva5CHkUxW9Ud3WgWRJ9caYHfiqu/1DB v9X8wyEYR5x67uouz+CRmlaIWLRDOZLaf9e8Sw0VmFlPt2Z8+w3QmKgFxczZnP0T5xXq kaf89/TfY9Xa532jiVw+EnvCep+IqF2NqLTvg= MIME-Version: 1.0 Received: by 10.52.89.147 with SMTP id bo19mr8494528vdb.523.1311122197726; Tue, 19 Jul 2011 17:36:37 -0700 (PDT) Received: by 10.52.111.138 with HTTP; Tue, 19 Jul 2011 17:36:37 -0700 (PDT) In-Reply-To: <5363C9A9-958A-4C7A-A274-A7722F975ECB@townsley.net> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> <1311088730.8201.YahooMailRC@web111407.mail.gq1.yahoo.com> <5363C9A9-958A-4C7A-A274-A7722F975ECB@townsley.net> Date: Wed, 20 Jul 2011 08:36:37 +0800 Message-ID: From: Jacni Qin To: Mark Townsley Content-Type: multipart/alternative; boundary=20cf3071c690da469604a8756ca2 Cc: "softwires@ietf.orglist" , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 00:36:39 -0000 --20cf3071c690da469604a8756ca2 Content-Type: text/plain; charset=ISO-8859-1 hi Mark, On Wed, Jul 20, 2011 at 12:16 AM, Mark Townsley wrote: > > On Jul 19, 2011, at 5:18 PM, Behcet Sarikaya wrote: > > > > > > >> > >> The schedule is obviously rather busy. Here's a suggestion: Softwires > has 30 > >> minutes of Multicast transition presentation, while we have an entire > BoF > >> devoted to the subject earlier in the week. Do we really need to > schedule time > >> for this twice? > >> > > > > Go stateless 4V6 go :-) > > > > Mark, Softwire has charter items for multicast solutions for Softwire > developed > > transition technologies like 6rd, DS-Lite, etc. > > That's fine - as long as the presentation and call for discussion is > different than what we will see in the BoF. There is an abundance of repeat > presentation happening these days, and we should do our part to avoid it. > Jacni>: The discussion in the BoF may be different, hopefully, some clarifications and valuable input for SW are expected, IMHO. Cheers, Jacni > - Mark > > > > > Prioritizing according to the charter deadlines could be a good idea, > IMHO. > > > > Behcet > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3071c690da469604a8756ca2 Content-Type: text/html; charset=ISO-8859-1 hi Mark,

On Wed, Jul 20, 2011 at 12:16 AM, Mark Townsley <mark@townsley.net> wrote:

On Jul 19, 2011, at 5:18 PM, Behcet Sarikaya wrote:

>
>
>>
>> The schedule is obviously rather busy. Here's a suggestion: Softwires has 30
>> minutes of Multicast transition presentation, while we have an entire BoF
>> devoted to the subject earlier in the week. Do we really need to schedule time
>> for this twice?
>>
>
> Go stateless 4V6 go :-)
>
> Mark, Softwire has charter items for multicast solutions for Softwire developed
> transition technologies like 6rd, DS-Lite, etc.

That's fine - as long as the presentation and call for discussion is different than what we will see in the BoF. There is an abundance of repeat presentation happening these days, and we should do our part to avoid it.

Jacni>: The discussion in the BoF may be different, hopefully, some clarifications and valuable input for SW are expected, IMHO.


Cheers,
Jacni


- Mark

>
> Prioritizing according to the charter deadlines could be a good idea, IMHO.
>
> Behcet

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

--20cf3071c690da469604a8756ca2-- From jacniq@gmail.com Tue Jul 19 20:07:59 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06A521F86AC for ; Tue, 19 Jul 2011 20:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwsy2MP6qxx3 for ; Tue, 19 Jul 2011 20:07:59 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF9E21F86AB for ; Tue, 19 Jul 2011 20:07:59 -0700 (PDT) Received: by vxi40 with SMTP id 40so4494610vxi.31 for ; Tue, 19 Jul 2011 20:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=KseTPO+qihdeq4GLifX4S3y3rfzHakYbbLxAnnI+BaU=; b=mdAudYvC3TjDNdNSafpK5WryC90b+qfZ2jWAmai/M3uWEH9eno8Zg6fpKUt9oKQcAa n6MJvXnsGrxVHJqapBKCY0mpU7SSOgwOfPfpjJ5l+d9N/mVzqAHeboyi3JFyc3ZI8p5l tIKYfKhTW9RbbbjIoZMZwNxyzo7MUBRAuhBh8= MIME-Version: 1.0 Received: by 10.52.30.197 with SMTP id u5mr7764039vdh.121.1311131278553; Tue, 19 Jul 2011 20:07:58 -0700 (PDT) Received: by 10.52.111.138 with HTTP; Tue, 19 Jul 2011 20:07:58 -0700 (PDT) Date: Wed, 20 Jul 2011 11:07:58 +0800 Message-ID: From: Jacni Qin To: softwires@ietf.org Content-Type: multipart/alternative; boundary=bcaec51d2d7a1cb2ce04a8778a2e Subject: [Softwires] Comments on 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: Wed, 20 Jul 2011 03:08:00 -0000 --bcaec51d2d7a1cb2ce04a8778a2e Content-Type: text/plain; charset=ISO-8859-1 hi Authors, all, I skimed the draft and got a question on the "Domain IPv4 Prefix" involved in the algorithm, Since currently the IPv4 blocks used for accessing residential users are probably fragmented (or not that continuous), I guess the there will be too many domains, IMHO. During the later stage of phasing out IPv4, that might be acceptable. Plus, it makes the algorithm complicated. So, how about removing it, and just using the EA-bits? While, of cource the tradeoff will be shorter IPv6 prefix is required. Please correct me if I missed something. :-) Thoughts? Cheers, Jacni --bcaec51d2d7a1cb2ce04a8778a2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Authors, all,

I skimed the draf= t and got a question on the "Domain IPv4 Prefix" involved in the = algorithm,

Since currently the IPv4 blocks used for accessing reside= ntial users are probably fragmented (or not that continuous), I guess the t= here will be too many domains, IMH= O. During the later stage of phasi= ng out IPv4, that might be acceptable. Plus, it makes the algorithm complic= ated. So, how about removing it, and just using the EA-bits? While, of cour= ce the tradeoff will be shorter IPv6 prefix is required.
Please correct me if I missed something. :-)

Thoughts?


Ch= eers,
Jacni

 --bcaec51d2d7a1cb2ce04a8778a2e-- From despres.remi@laposte.net Wed Jul 20 00:24:13 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BFD21F8779 for ; Wed, 20 Jul 2011 00:24:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jyx9hd3EqTkF for ; Wed, 20 Jul 2011 00:24:13 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD2521F8770 for ; Wed, 20 Jul 2011 00:24:12 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 81CFC7000087; Wed, 20 Jul 2011 09:24:11 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 130457000084; Wed, 20 Jul 2011 09:24:11 +0200 (CEST) X-SFR-UUID: 20110720072411779.130457000084@msfrf2401.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: Wed, 20 Jul 2011 09:24:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0C6CAF14-21FD-4359-888A-5C0AB6B02BAE@laposte.net> References: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:24:13 -0000 Le 19 juil. 2011 =E0 18:53, GangChen a =E9crit : > Hello Remi, >=20 > I guess 4V6 CE need to recognize whether received IPv6 prefix is CE > IPv6 prefix, which is used to generate a shared IPv4 address. You apparently assume that the receiving CE has two IPv6 prefixes, with = one reserved for shared IPv4 addresses. This is possible but, AFAIK, isn't required in 4V6T (and isn't needed in = 4V6E). If 4V6T CE's would be required to have two IPv6 prefixes (or as a = minimum two different addresses), this would become an operational = constraint to be considered when comparing the two solutions. Regards, RD =20 > Then, it > should be no problem to distinguish native IPv6 or an IPv6 address CE > should translated. >=20 > Gang >=20 > 2011/7/19, R=E9mi Despr=E9s : >> Hi, all, >>=20 >> 1. >> The translation-based stateless solution for IPv4 via IPv6 described = in >> draft-murakami-softwire-4v6-translation-00 seems to have a = significant >> limitation: >> - When a 4V6T customer-edge node receives a packet from a CE of the = same >> 4V6T domain, it doesn't know whether it must treat it as a native = IPv6 >> packet from this CE or as an IPv4 packet that this CE has translated. >>=20 >>=20 >> <-- 4V6T domain --> <-- IPv4 Internet -- >>=20 >> (A) 4V6T CE |---->----. >> | >> V---- 4v6T-BR --- - - - >> | >> (B) 4V6T CE |----<----' >> <=3D v4 or v6 ?? >>=20 >> For instance, if the IPv4 address of (B) is shared, (B) doesn't know = whether >> received packets must go to its internal NAT44, or be treated a real = IPv6 >> packet. >> (Sending to the NAT44 packets whose ports are currently bound in the = NAT44 >> wouldn't be satisfactory: all ports may be used in IPv6). >>=20 >> 2. >> Note that this problem doesn't apply to the encapsulation-based = stateless >> solution (4V6E): >> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 = packet if, >> and only if, its Next header is IP-in-IP, and the encapsulated packet = is >> IPv4. There is no ambiguity. >>=20 >> =3D> Unless something is wrong in the above, or a palliative is = devised, >> consideration of this should be added to the comparative analysis of = 4V6T >> and 4V6E solutions (draft-dec-stateless-4v6). >>=20 >>=20 >> Regards, >> RD >> _______________________________________________ >> 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 Wed Jul 20 00:28:18 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF75321F87AF for ; Wed, 20 Jul 2011 00:28:18 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZYT8cbZUYx0 for ; Wed, 20 Jul 2011 00:28:18 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id E97C421F87A4 for ; Wed, 20 Jul 2011 00:28:17 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id 0F7AB700008A; Wed, 20 Jul 2011 09:28:17 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2401.sfr.fr (SMTP Server) with ESMTP id B65A17000084; Wed, 20 Jul 2011 09:28:12 +0200 (CEST) X-SFR-UUID: 20110720072816747.B65A17000084@msfrf2401.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: <22E359E7-CCB9-441C-B031-11D9A2BA3B51@ipinfusion.com> Date: Wed, 20 Jul 2011 09:28:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC43903-D882-4F66-96F2-986BAA423C00@laposte.net> References: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> <22E359E7-CCB9-441C-B031-11D9A2BA3B51@ipinfusion.com> To: Tetsuya Murakami X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:28:19 -0000 Le 19 juil. 2011 =E0 21:18, Tetsuya Murakami a =E9crit : > Hi Remi, >=20 > In terms of 4via6 translation, 4via6 CE can process the received IPv6 = packets if the IPv6 destination address is the tunnel end-point address = which is assigned to that 4via6 CE and also the IPv6 source address is = the IPv4-embedded IPv6 address which is defined in RFC6052. If these = condition of IPv6 source and destination address is not matched, 4via6 = CE can process the received IPv6 packets as the normal IPv6 packet. Then if CE A sends an IPv6 packet to CE B, it will be processed there as = a received IPv4 packet. Right? (Please, see also my answer to Gang.) Regards, RD > So, I don't think there is no issue which you raised. >=20 > Thanks, > Tetsuya Murakami >=20 > On 2011/07/19, at 9:53, GangChen wrote: >=20 >> Hello Remi, >>=20 >> I guess 4V6 CE need to recognize whether received IPv6 prefix is CE >> IPv6 prefix, which is used to generate a shared IPv4 address. Then, = it >> should be no problem to distinguish native IPv6 or an IPv6 address CE >> should translated. >>=20 >> Gang >>=20 >> 2011/7/19, R=E9mi Despr=E9s : >>> Hi, all, >>>=20 >>> 1. >>> The translation-based stateless solution for IPv4 via IPv6 described = in >>> draft-murakami-softwire-4v6-translation-00 seems to have a = significant >>> limitation: >>> - When a 4V6T customer-edge node receives a packet from a CE of the = same >>> 4V6T domain, it doesn't know whether it must treat it as a native = IPv6 >>> packet from this CE or as an IPv4 packet that this CE has = translated. >>>=20 >>>=20 >>> <-- 4V6T domain --> <-- IPv4 Internet -- >>>=20 >>> (A) 4V6T CE |---->----. >>> | >>> V---- 4v6T-BR --- - - - >>> | >>> (B) 4V6T CE |----<----' >>> <=3D v4 or v6 ?? >>>=20 >>> For instance, if the IPv4 address of (B) is shared, (B) doesn't know = whether >>> received packets must go to its internal NAT44, or be treated a real = IPv6 >>> packet. >>> (Sending to the NAT44 packets whose ports are currently bound in the = NAT44 >>> wouldn't be satisfactory: all ports may be used in IPv6). >>>=20 >>> 2. >>> Note that this problem doesn't apply to the encapsulation-based = stateless >>> solution (4V6E): >>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 = packet if, >>> and only if, its Next header is IP-in-IP, and the encapsulated = packet is >>> IPv4. There is no ambiguity. >>>=20 >>> =3D> Unless something is wrong in the above, or a palliative is = devised, >>> consideration of this should be added to the comparative analysis of = 4V6T >>> and 4V6E solutions (draft-dec-stateless-4v6). >>>=20 >>>=20 >>> Regards, >>> RD >>> _______________________________________________ >>> 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 satoru.matsushima@gmail.com Wed Jul 20 01:07:34 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B9621F877F for ; Wed, 20 Jul 2011 01:07:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7aZKNpCnklB for ; Wed, 20 Jul 2011 01:07:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D100721F8761 for ; Wed, 20 Jul 2011 01:07:33 -0700 (PDT) Received: by iye7 with SMTP id 7so5218979iye.31 for ; Wed, 20 Jul 2011 01:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=lgU6WgX8HIunsH20qyka6gbepNQvY82D/6QMPzS/xpg=; b=JG5IaZksYubnCUHPwa8aawKmzKbUq3MOSRQTcjV35MQ9OC1YGhV4n5Umn8okGJ9wPY lq4MmW3JB1RZL1mA6I5hig950IZxJCJMHtSLaL4p2J3Gq8tcRL+yMrEfhWIPQKqZjzw3 /hNqNQrL0tEaS2HLrERzFmzkPTtjOnOI26IPA= Received: by 10.231.84.144 with SMTP id j16mr1096344ibl.145.1311149253501; Wed, 20 Jul 2011 01:07:33 -0700 (PDT) Received: from h094n073.wl17.iiji.jp ([210.130.172.233]) by mx.google.com with ESMTPS id k16sm1043icc.10.2011.07.20.01.07.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jul 2011 01:07:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Wed, 20 Jul 2011 17:07:28 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9C8F1106-07D0-4429-98E0-8085A7974DA1@gmail.com> References: To: Jacni Qin X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on 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: Wed, 20 Jul 2011 08:07:34 -0000 Jacni, On 2011/07/20, at 12:07, Jacni Qin wrote: > hi Authors, all, >=20 > I skimed the draft and got a question on the "Domain IPv4 Prefix" = involved in the algorithm, >=20 > Since currently the IPv4 blocks used for accessing residential users = are probably fragmented (or not that continuous), I guess the there will = be too many domains, IMHO. During the later stage of phasing out IPv4, = that might be acceptable. Plus, it makes the algorithm complicated. So, = how about removing it, and just using the EA-bits? While, of cource the = tradeoff will be shorter IPv6 prefix is required. > Please correct me if I missed something. :-) >=20 > Thoughts? 4rd mapping rule allows '0/0' for a Domain IPv4 Prefix configuration. cheers, --satoru= From jacniq@gmail.com Wed Jul 20 01:46:02 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC1C21F8880 for ; Wed, 20 Jul 2011 01:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7Y9OccOOezN for ; Wed, 20 Jul 2011 01:46:01 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B733121F873D for ; Wed, 20 Jul 2011 01:46:01 -0700 (PDT) Received: by vxi40 with SMTP id 40so4656041vxi.31 for ; Wed, 20 Jul 2011 01:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CZEPRJTKadZJpGUFGOXZoh4I2PnWtYBsgZwYOh8WtZc=; b=rtj7Cb1mu57h/SqYoCfRnPvcsQyTGrdHFDKQGGl8v8/dqD2BKV1gTqXuBqUcLGKLAu OqQp5E8vE+Ziop3yKdVIVhVJ9sMgCsyAFyHaLgAiMXJfCSL2BzThy6AsF49ehR15xqcq 6tpGGhYKrUeCuq3Ye1YJf+EluApuCOzheeKWE= MIME-Version: 1.0 Received: by 10.52.25.168 with SMTP id d8mr5746671vdg.188.1311151561115; Wed, 20 Jul 2011 01:46:01 -0700 (PDT) Received: by 10.52.111.138 with HTTP; Wed, 20 Jul 2011 01:46:01 -0700 (PDT) In-Reply-To: <9C8F1106-07D0-4429-98E0-8085A7974DA1@gmail.com> References: <9C8F1106-07D0-4429-98E0-8085A7974DA1@gmail.com> Date: Wed, 20 Jul 2011 16:46:01 +0800 Message-ID: From: Jacni Qin To: Satoru Matsushima Content-Type: multipart/alternative; boundary=20cf3079bfea0c078104a87c43d0 Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on 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: Wed, 20 Jul 2011 08:46:02 -0000 --20cf3079bfea0c078104a87c43d0 Content-Type: text/plain; charset=ISO-8859-1 hi, On Wed, Jul 20, 2011 at 4:07 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Jacni, > > On 2011/07/20, at 12:07, Jacni Qin wrote: > ... > > > > Thoughts? > > 4rd mapping rule allows '0/0' for a Domain IPv4 Prefix configuration. > Jacni>: Thanks, maybe you should add more text on this to get it clarified. Cheers, Jacni > > cheers, > --satoru --20cf3079bfea0c078104a87c43d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

On Wed, Jul 20, 2011 at 4:07 PM, Satoru Matsushima &l= t;satoru.matsushima@gmail.co= m> wrote:
Jacni,

On 2011/07/20, at 12:07, Jacni Qin wrote:
...
>
> Thoughts?

4rd mapping rule allows '0/0' for a Domain IPv4 Prefix = configuration.

J= acni>: Thanks, maybe you should add more text on this to get it clarifie= d.


Cheers,
Jacni
=A0

cheers,
--satoru

--20cf3079bfea0c078104a87c43d0-- From jacniq@gmail.com Wed Jul 20 01:53:53 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1083C21F889F for ; Wed, 20 Jul 2011 01:53:53 -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.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPoPwUTjpPbD for ; Wed, 20 Jul 2011 01:53:52 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13C5421F8892 for ; Wed, 20 Jul 2011 01:53:51 -0700 (PDT) Received: by vws12 with SMTP id 12so3898vws.31 for ; Wed, 20 Jul 2011 01:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b9YDC+wETRo52NfFLuPUW6YZT67RZHEX283V28eAfYM=; b=apA7Cb9VSTP26RfUdg2ePyIay5YKrwZvXHdDN1eWVNg6NubaeboFoblj1oM+d4ZPV5 bQBu62vDDme8JjETq6Ehmniyz6E1WBeei9+L80j5ZJrUw3XduVGi+oN8UTQkV+J2kIpM RamxQvh9RwUoSu1wr8DAdozLbAXuYI+Q2iWLg= MIME-Version: 1.0 Received: by 10.52.99.74 with SMTP id eo10mr8275944vdb.322.1311152030775; Wed, 20 Jul 2011 01:53:50 -0700 (PDT) Received: by 10.52.111.138 with HTTP; Wed, 20 Jul 2011 01:53:50 -0700 (PDT) In-Reply-To: <9BC43903-D882-4F66-96F2-986BAA423C00@laposte.net> References: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> <22E359E7-CCB9-441C-B031-11D9A2BA3B51@ipinfusion.com> <9BC43903-D882-4F66-96F2-986BAA423C00@laposte.net> Date: Wed, 20 Jul 2011 16:53:50 +0800 Message-ID: From: Jacni Qin To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf307d047a0a778d04a87c5f93 Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:53:53 -0000 --20cf307d047a0a778d04a87c5f93 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, On Wed, Jul 20, 2011 at 3:28 PM, R=E9mi Despr=E9s wrote: > > Le 19 juil. 2011 =E0 21:18, Tetsuya Murakami a =E9crit : > > > Hi Remi, > > > > In terms of 4via6 translation, 4via6 CE can process the received IPv6 > packets if the IPv6 destination address is the tunnel end-point address > which is assigned to that 4via6 CE and also the IPv6 source address is th= e > IPv4-embedded IPv6 address which is defined in RFC6052. If these conditio= n > of IPv6 source and destination address is not matched, 4via6 CE can proce= ss > the received IPv6 packets as the normal IPv6 packet. > > Then if CE A sends an IPv6 packet to CE B, it will be processed there as = a > received IPv4 packet. > Right? > (Please, see also my answer to Gang.) > Jacni>: You mean the CE IPv6 prefix also serves the native IPv6 users on th= e LAN side, right? That's not yet been clearly stated, I just found in the 4r= d draft, Introduction section, "On the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 and IPv4 are implemented as for any native dual-stack service delivered by the SP. " Cheers, Jacni > > Regards, > RD > > > > > So, I don't think there is no issue which you raised. > > > > Thanks, > > Tetsuya Murakami > > > > On 2011/07/19, at 9:53, GangChen wrote: > > > >> Hello Remi, > >> > >> I guess 4V6 CE need to recognize whether received IPv6 prefix is CE > >> IPv6 prefix, which is used to generate a shared IPv4 address. Then, it > >> should be no problem to distinguish native IPv6 or an IPv6 address CE > >> should translated. > >> > >> Gang > >> > >> 2011/7/19, R=E9mi Despr=E9s : > >>> Hi, all, > >>> > >>> 1. > >>> The translation-based stateless solution for IPv4 via IPv6 described = in > >>> draft-murakami-softwire-4v6-translation-00 seems to have a significan= t > >>> limitation: > >>> - When a 4V6T customer-edge node receives a packet from a CE of the > same > >>> 4V6T domain, it doesn't know whether it must treat it as a native IPv= 6 > >>> packet from this CE or as an IPv4 packet that this CE has translated. > >>> > >>> > >>> <-- 4V6T domain --> <-- IPv4 Internet -- > >>> > >>> (A) 4V6T CE |---->----. > >>> | > >>> V---- 4v6T-BR --- - - - > >>> | > >>> (B) 4V6T CE |----<----' > >>> <=3D v4 or v6 ?? > >>> > >>> For instance, if the IPv4 address of (B) is shared, (B) doesn't know > whether > >>> received packets must go to its internal NAT44, or be treated a real > IPv6 > >>> packet. > >>> (Sending to the NAT44 packets whose ports are currently bound in the > NAT44 > >>> wouldn't be satisfactory: all ports may be used in IPv6). > >>> > >>> 2. > >>> Note that this problem doesn't apply to the encapsulation-based > stateless > >>> solution (4V6E): > >>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packe= t > if, > >>> and only if, its Next header is IP-in-IP, and the encapsulated packet > is > >>> IPv4. There is no ambiguity. > >>> > >>> =3D> Unless something is wrong in the above, or a palliative is devis= ed, > >>> consideration of this should be added to the comparative analysis of > 4V6T > >>> and 4V6E solutions (draft-dec-stateless-4v6). > >>> > >>> > >>> Regards, > >>> RD > >>> _______________________________________________ > >>> 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 > --20cf307d047a0a778d04a87c5f93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi,

On Wed, Jul 20, 2011 at 3:28 PM, R=E9mi Despr=E9s <despres.remi@laposte.net<= /a>> wrote:

Le 19 juil. 2011 =E0 21:18, Tetsuya Murakami a =E9crit :

> Hi Remi,
>
> In terms of 4via6 translation, 4via6 CE can process the received IPv6 = packets if the IPv6 destination address is the tunnel end-point address whi= ch is assigned to that 4via6 CE and also the IPv6 source address is the IPv= 4-embedded IPv6 address which is defined in RFC6052. If these condition of = IPv6 source and destination address is not matched, 4via6 CE can process th= e received IPv6 packets as the normal IPv6 packet.

Then if CE A sends an IPv6 packet to CE B, it will be processed there= as a received IPv4 packet.
Right?
(Please, see also my answer to Gang.)

Jacni>: You mean the CE IPv6 prefix also serves = the native IPv6 users on the LAN side, right? That's not yet been clear= ly stated, I just found in the 4rd draft, Introduction section,
"On the "end-user-facing" (i.e., "LAN") side of a = CE, IPv6 and IPv4 are implemented as for any native dual-stack service deli= vered by the SP. "


Cheers,
Jacni



Regards,
RD



> So, I don't think there is no issue which you raised.
>
> Thanks,
> Tetsuya Murakami
>
> On 2011/07/19, at 9:53, GangChen wrote:
>
>> Hello Remi,
>>
>> I guess 4V6 CE need to recognize whether received IPv6 prefix is C= E
>> IPv6 prefix, which is used to generate a shared IPv4 address. Then= , it
>> should be no problem to distinguish native IPv6 or an IPv6 address= CE
>> should translated.
>>
>> Gang
>>
>> 2011/7/19, R=E9mi Despr=E9s <despres.remi@laposte.net>:
>>> Hi, all,
>>>
>>> 1.
>>> The translation-based stateless solution for IPv4 via IPv6 des= cribed in
>>> draft-murakami-softwire-4v6-translation-00 seems to have a sig= nificant
>>> limitation:
>>> - When a 4V6T customer-edge node receives a packet from a CE o= f the same
>>> 4V6T domain, it doesn't know whether it must treat it as a= native IPv6
>>> packet from this CE or as an IPv4 packet that this CE has tran= slated.
>>>
>>>
>>> =A0 =A0 =A0 <-- 4V6T domain --> =A0 <-- IPv4 Internet= --
>>>
>>> (A) 4V6T CE |---->----.
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 V---- 4v6T-BR --- - - = -
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>> (B) 4V6T CE |----<----'
>>> =A0 =A0 =A0 <=3D v4 or v6 ??
>>>
>>> For instance, if the IPv4 address of (B) is shared, (B) doesn&= #39;t know whether
>>> received packets must go to its internal NAT44, or be treated = a real IPv6
>>> packet.
>>> (Sending to the NAT44 packets whose ports are currently bound = in the NAT44
>>> wouldn't be satisfactory: all ports may be used in IPv6).<= br> >>>
>>> 2.
>>> Note that this problem doesn't apply to the encapsulation-= based stateless
>>> solution (4V6E):
>>> - A 4V6E CE treats a received IPv6 packet as containing an IPv= 4 packet if,
>>> and only if, its Next header is IP-in-IP, and the encapsulated= packet is
>>> IPv4. There is no ambiguity.
>>>
>>> =3D> Unless something is wrong in the above, or a palliativ= e is devised,
>>> consideration of this should be added to the comparative analy= sis of 4V6T
>>> and 4V6E solutions (draft-dec-stateless-4v6).
>>>
>>>
>>> Regards,
>>> RD
>>> _______________________________________________
>>> 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

--20cf307d047a0a778d04a87c5f93-- From despres.remi@laposte.net Wed Jul 20 02:47:30 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD1321F8793 for ; Wed, 20 Jul 2011 02:47:30 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leXTV8kZTPQR for ; Wed, 20 Jul 2011 02:47:26 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4979321F8788 for ; Wed, 20 Jul 2011 02:47:25 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2213.sfr.fr (SMTP Server) with ESMTP id 9B6577000092; Wed, 20 Jul 2011 11:47:24 +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 2FB3D7000089; Wed, 20 Jul 2011 11:47:24 +0200 (CEST) X-SFR-UUID: 20110720094724195.2FB3D7000089@msfrf2213.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--12042602 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 20 Jul 2011 11:45:22 +0200 Message-Id: <7FB924B7-0067-45CB-A0F4-02F15504363E@laposte.net> References: To: Jacni Qin X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on 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: Wed, 20 Jul 2011 09:47:30 -0000 --Apple-Mail-1--12042602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Jacni, Le 20 juil. 2011 =E0 05:07, Jacni Qin a =E9crit : > hi Authors, all, >=20 > I skimed the draft and got a question on the "Domain IPv4 Prefix" = involved in the algorithm, >=20 > Since currently the IPv4 blocks used for accessing residential users = are probably fragmented (or not that continuous), I guess the there will = be too many domains, IMHO. During the later stage of phasing out IPv4, = that might be acceptable. Plus, it makes the algorithm complicated. So, = how about removing it, and just using the EA-bits? While, of cource the = tradeoff will be shorter IPv6 prefix is required. > Please correct me if I missed something. :-) >=20 > Thoughts? In addition to Satoru's answer, an ISP that has many IPv4 prefixes can: - use only a few, or even only one, of its shortest IPv4 prefixes, and - use IPv4 address sharing to support as many CE's as needed.=20 Example: an ISP has a /10, a /11, another /11, a /14, a /15, and a /16 = (a real example I met). It can: - use three domains (the /10 and the two /11's), or - use only the /10, extending Port-set ID by one bit to support as many = CE's In both cases, no entropy due to the fragmented IPv4 space needs to be = exported to the IPv6 addressing plan. Leftover IPv4 prefixes can then be returned to the community (for = free... or for a price, whatever applies). =20 Regards, RD >=20 >=20 > Cheers, > Jacni >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-1--12042602 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi, = Jacni,

Le 20 juil. 2011 =E0 05:07, Jacni Qin a =E9crit = :

hi Authors, = all,

I skimed the draft and got a question on the "Domain IPv4 = Prefix" involved in the algorithm,

Since currently the IPv4 = blocks used for accessing residential users are probably fragmented (or = not that continuous), I guess the there will be too many = domains, IMHO. During the later stage of phasing out = IPv4, that might be acceptable. Plus, it makes the algorithm = complicated. So, how about removing it, and just using the EA-bits? = While, of cource the tradeoff will be shorter IPv6 prefix is = required.
Please correct me if I missed something. = :-)

Thoughts?

In = addition to Satoru's answer, an ISP that has many IPv4 prefixes = can:
- use only a few, or even only one, of its shortest IPv4 = prefixes, and
- use IPv4 address sharing to support as many = CE's as needed. 

Example: an ISP has a = /10, a /11, another /11, a /14, a /15, and a /16 (a real example I = met).
It can:
- use three domains (the /10 and the = two /11's), or
- use only the /10, extending Port-set ID by = one bit to support as many CE's
In both cases, no entropy due = to the fragmented IPv4 space needs to be exported to the IPv6 addressing = plan.

Leftover IPv4 prefixes can then be = returned to the community (for free... or for a price, whatever = applies).
  
Regards,
RD

=


Cheers,
Jacni

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

= = --Apple-Mail-1--12042602-- From despres.remi@laposte.net Wed Jul 20 04:42:05 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0D921F86D4 for ; Wed, 20 Jul 2011 04:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF3w19BsFngm for ; Wed, 20 Jul 2011 04:42:04 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC7B21F86C3 for ; Wed, 20 Jul 2011 04:42:03 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 6401F7000094; Wed, 20 Jul 2011 13:41:56 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 4756C7000098; Wed, 20 Jul 2011 13:41:49 +0200 (CEST) X-SFR-UUID: 20110720114149292.4756C7000098@msfrf2206.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--5476898 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 20 Jul 2011 13:34:48 +0200 Message-Id: <93F00FC0-941C-407C-B2B2-5D244661A361@laposte.net> References: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> <22E359E7-CCB9-441C-B031-11D9A2BA3B51@ipinfusion.com> <9BC43903-D882-4F66-96F2-986BAA423C00@laposte.net> To: Jacni Qin X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 11:42:05 -0000 --Apple-Mail-2--5476898 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 20 juil. 2011 =E0 10:53, Jacni Qin a =E9crit : > hi Remi, >=20 > On Wed, Jul 20, 2011 at 3:28 PM, R=E9mi Despr=E9s = wrote: >=20 > Le 19 juil. 2011 =E0 21:18, Tetsuya Murakami a =E9crit : >=20 > > Hi Remi, > > > > In terms of 4via6 translation, 4via6 CE can process the received = IPv6 packets if the IPv6 destination address is the tunnel end-point = address which is assigned to that 4via6 CE and also the IPv6 source = address is the IPv4-embedded IPv6 address which is defined in RFC6052. = If these condition of IPv6 source and destination address is not = matched, 4via6 CE can process the received IPv6 packets as the normal = IPv6 packet. >=20 > Then if CE A sends an IPv6 packet to CE B, it will be processed there = as a received IPv4 packet. > Right? > (Please, see also my answer to Gang.) >=20 > Jacni>: You mean the CE IPv6 prefix also serves the native IPv6 users = on the LAN side, right? That's not yet been clearly stated, I just found = in the 4rd draft, Introduction section, > "On the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 and IPv4 = are implemented as for any native dual-stack service delivered by the = SP. " Yes. For the LAN to have a global IPv6 prefix, it has to use that which is = assigned to the site, i.e. to the CE. OK? RD >=20 >=20 > Cheers, > Jacni >=20 >=20 >=20 > Regards, > RD >=20 >=20 >=20 > > So, I don't think there is no issue which you raised. > > > > Thanks, > > Tetsuya Murakami > > > > On 2011/07/19, at 9:53, GangChen wrote: > > > >> Hello Remi, > >> > >> I guess 4V6 CE need to recognize whether received IPv6 prefix is CE > >> IPv6 prefix, which is used to generate a shared IPv4 address. Then, = it > >> should be no problem to distinguish native IPv6 or an IPv6 address = CE > >> should translated. > >> > >> Gang > >> > >> 2011/7/19, R=E9mi Despr=E9s : > >>> Hi, all, > >>> > >>> 1. > >>> The translation-based stateless solution for IPv4 via IPv6 = described in > >>> draft-murakami-softwire-4v6-translation-00 seems to have a = significant > >>> limitation: > >>> - When a 4V6T customer-edge node receives a packet from a CE of = the same > >>> 4V6T domain, it doesn't know whether it must treat it as a native = IPv6 > >>> packet from this CE or as an IPv4 packet that this CE has = translated. > >>> > >>> > >>> <-- 4V6T domain --> <-- IPv4 Internet -- > >>> > >>> (A) 4V6T CE |---->----. > >>> | > >>> V---- 4v6T-BR --- - - - > >>> | > >>> (B) 4V6T CE |----<----' > >>> <=3D v4 or v6 ?? > >>> > >>> For instance, if the IPv4 address of (B) is shared, (B) doesn't = know whether > >>> received packets must go to its internal NAT44, or be treated a = real IPv6 > >>> packet. > >>> (Sending to the NAT44 packets whose ports are currently bound in = the NAT44 > >>> wouldn't be satisfactory: all ports may be used in IPv6). > >>> > >>> 2. > >>> Note that this problem doesn't apply to the encapsulation-based = stateless > >>> solution (4V6E): > >>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 = packet if, > >>> and only if, its Next header is IP-in-IP, and the encapsulated = packet is > >>> IPv4. There is no ambiguity. > >>> > >>> =3D> Unless something is wrong in the above, or a palliative is = devised, > >>> consideration of this should be added to the comparative analysis = of 4V6T > >>> and 4V6E solutions (draft-dec-stateless-4v6). > >>> > >>> > >>> Regards, > >>> RD > >>> _______________________________________________ > >>> 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 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-2--5476898 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
hi = Remi,

On Wed, Jul 20, 2011 at = 3:28 PM, R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:

Le 19 juil. 2011 =E0 21:18, Tetsuya Murakami a =E9crit :

> Hi Remi,
>
> In terms of 4via6 translation, 4via6 CE can process the received = IPv6 packets if the IPv6 destination address is the tunnel end-point = address which is assigned to that 4via6 CE and also the IPv6 source = address is the IPv4-embedded IPv6 address which is defined in RFC6052. = If these condition of IPv6 source and destination address is not = matched, 4via6 CE can process the received IPv6 packets as the normal = IPv6 packet.

Then if CE A sends an IPv6 packet to CE B, it will be processed = there as a received IPv4 packet.
Right?
(Please, see also my answer to Gang.)

Jacni>: You mean the CE IPv6 prefix also = serves the native IPv6 users on the LAN side, right? That's not yet been = clearly stated, I just found in the 4rd draft, Introduction section,
"On the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 and IPv4 are = implemented as for any native dual-stack service delivered by the SP. = "

Yes.
For = the LAN to have a global IPv6 prefix, it has to use that which is = assigned to the site, i.e. to the = CE.
OK?

RD



Cheers,
Jacni



Regards,
RD



> So, I don't think there is no issue which you raised.
>
> Thanks,
> Tetsuya Murakami
>
> On 2011/07/19, at 9:53, GangChen wrote:
>
>> Hello Remi,
>>
>> I guess 4V6 CE need to recognize whether received IPv6 prefix = is CE
>> IPv6 prefix, which is used to generate a shared IPv4 address. = Then, it
>> should be no problem to distinguish native IPv6 or an IPv6 = address CE
>> should translated.
>>
>> Gang
>>
>> 2011/7/19, R=E9mi Despr=E9s <despres.remi@laposte.net>:=
>>> Hi, all,
>>>
>>> 1.
>>> The translation-based stateless solution for IPv4 via IPv6 = described in
>>> draft-murakami-softwire-4v6-translation-00 seems to have a = significant
>>> limitation:
>>> - When a 4V6T customer-edge node receives a packet from a = CE of the same
>>> 4V6T domain, it doesn't know whether it must treat it as a = native IPv6
>>> packet from this CE or as an IPv4 packet that this CE has = translated.
>>>
>>>
>>>       <-- 4V6T domain -->   = <-- IPv4 Internet --
>>>
>>> (A) 4V6T CE |---->----.
>>>                 =     |
>>>                 =     V---- 4v6T-BR --- - - -
>>>                 =     |
>>> (B) 4V6T CE |----<----'
>>>       <=3D v4 or v6 ??
>>>
>>> For instance, if the IPv4 address of (B) is shared, (B) = doesn't know whether
>>> received packets must go to its internal NAT44, or be = treated a real IPv6
>>> packet.
>>> (Sending to the NAT44 packets whose ports are currently = bound in the NAT44
>>> wouldn't be satisfactory: all ports may be used in = IPv6).
>>>
>>> 2.
>>> Note that this problem doesn't apply to the = encapsulation-based stateless
>>> solution (4V6E):
>>> - A 4V6E CE treats a received IPv6 packet as containing an = IPv4 packet if,
>>> and only if, its Next header is IP-in-IP, and the = encapsulated packet is
>>> IPv4. There is no ambiguity.
>>>
>>> =3D> Unless something is wrong in the above, or a = palliative is devised,
>>> consideration of this should be added to the comparative = analysis of 4V6T
>>> and 4V6E solutions (draft-dec-stateless-4v6).
>>>
>>>
>>> Regards,
>>> RD
>>> _______________________________________________
>>> 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


= --Apple-Mail-2--5476898-- From wdec.ietf@gmail.com Wed Jul 20 04:45:12 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F238F21F8794 for ; Wed, 20 Jul 2011 04:45:12 -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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxnxaMbWxNuI for ; Wed, 20 Jul 2011 04:45:12 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6494F21F86EB for ; Wed, 20 Jul 2011 04:45:12 -0700 (PDT) Received: by pvh18 with SMTP id 18so167577pvh.31 for ; Wed, 20 Jul 2011 04:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=n4XTVewy3O+LpdtHRJ/rzPqe03l/VtaZ3zGRK6RZr3Q=; b=X4Qa18c1X4OoqDzludFeNdEqxO+M5Ufx/dCNJH9kf50lMsOG7ts/WrQrxN8vO/GMO8 kyGoUp/Ftbb0DKFEtErSSQ6XOka7aGfGiUTHOPwsAJ4sfTI2cCHWvz72pCaTh7eonLim O3ibASgmw9mqDerbO5Kvqs6Do2VMT7XjwWkZI= MIME-Version: 1.0 Received: by 10.142.177.1 with SMTP id z1mr3881700wfe.174.1311162311885; Wed, 20 Jul 2011 04:45:11 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Wed, 20 Jul 2011 04:45:11 -0700 (PDT) In-Reply-To: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> References: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> Date: Wed, 20 Jul 2011 13:45:11 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 11:45:13 -0000 Hello Remi, Good question. Thankfully, this is not an issue as answered in Sections 5.4 and 5.5 (and briefly in 5.2) of draft-dec-stateless-4v6, since CPE A would not send non-v4 traffic (e.g. native IPv6 traffic) to CPE-B's 4V6 address. Allow me to expand, along with giving some background 0. The IPv6 4V6 prefix assigned to the CPE is, say, a /64. The CPE thus may use the same /6r prefix to calculate the 4V6 address, using 4V6 domain parameters, as well as other IPv6 addresses in that prefix using SLAAC, say. As an example: When a suitable 4V6 /64 prefix is advertised in an RA, a 4V6 CPE will configure itself both a 4V6 interface address and a SLAAC address. A similar case applies when DHCP-PD is used. 1. ALL 4V6 systems, without distinction between translation or encapsulation mode, need to use the specific 4V6 IPv6 interface address for their stateless 4V6 function - no other address will do for stateless operation (BTW some may like to call the 4V6 interface a virtual interface). 2. In general, a 4V6 CPE working in translation mode will pass to NAT44 all traffic arriving on the IPv6 4V6 interface - while an encapsulating 4V6 system will pass to NAT44 all encapsulated IPv4 traffic arriving on the IPv6 4V6 interface. In both cases there are restrictions on what can be done on/with the 4V6 interface. Some implementation considerations come to the fore, such as the fact that 4V6 is intended to be a custom CPE function and not a user application on a generic host, ie The CPEs kernel typically needs to support 4V6, and all the above can be accomplished optimally. 3. Traffic originating from IPv6 hosts behind the CPE or sourced by IPv6 apps on the 4V6 CPE itself will use a non 4V6 address as their source address, but from the 4V6 prefix (or its subnet). Hence there is no ambiguity with handling any such IPv6 return traffic. Regards, Wojtek. On 19 July 2011 10:55, R=E9mi Despr=E9s wrote: > Hi, all, > > 1. > The translation-based stateless solution for IPv4 via IPv6 described in d= raft-murakami-softwire-4v6-translation-00 seems to have a significant limit= ation: > - When a 4V6T customer-edge node receives a packet from a CE of the same = 4V6T domain, it doesn't know whether it must treat it as a native IPv6 pack= et from this CE or as an IPv4 packet that this CE has translated. > > > =A0 =A0 =A0 =A0<-- 4V6T domain --> =A0 <-- IPv4 Internet -- > > (A) 4V6T CE |---->----. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V---- 4v6T-BR --- - - - > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > (B) 4V6T CE |----<----' > =A0 =A0 =A0 =A0<=3D v4 or v6 ?? > > For instance, if the IPv4 address of (B) is shared, (B) doesn't know whet= her received packets must go to its internal NAT44, or be treated a real IP= v6 packet. > (Sending to the NAT44 packets whose ports are currently bound in the NAT4= 4 wouldn't be satisfactory: all ports may be used in IPv6). > > 2. > Note that this problem doesn't apply to the encapsulation-based stateless= solution (4V6E): > - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet if= , and only if, its Next header is IP-in-IP, and the encapsulated packet is = IPv4. There is no ambiguity. > > =3D> Unless something is wrong in the above, or a palliative is devised, = consideration of this should be added to the comparative analysis of 4V6T a= nd 4V6E solutions (draft-dec-stateless-4v6). > > > Regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From wdec@cisco.com Wed Jul 20 04:37:12 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1796E21F85B9 for ; Wed, 20 Jul 2011 04:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEHRZWxz6kqF for ; Wed, 20 Jul 2011 04:37:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D4A2621F86BB for ; Wed, 20 Jul 2011 04:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=3541; q=dns/txt; s=iport; t=1311161828; x=1312371428; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=QLmwGWCHTWv3pbfraYt7BJoKOIeD53yqb55GSilGZz4=; b=PHrckhwlhBB2ToaqHWZsM7BpRE35jmV9pz36TwKyeN08Cl7W5i4sWNk6 PoVyxDKbq56vKLTd519qnTYN1E27H42rpwltWEV6wYphBByzRWQSkZ5hx /VZIHqxWNu9jHAfjRNveb64gVhOI/EO43QykFoZZ+v8monpQeHV9t2ixw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAW9Jk6Q/khN/2dsb2JhbABUp2J3iHyjXp49hj0EhyaLSIUQi08 Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Jul 2011 11:37:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6KBb6JT018048; Wed, 20 Jul 2011 11:37:06 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 13:37:07 +0200 Received: from 10.61.66.107 ([10.61.66.107]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Wed, 20 Jul 2011 11:37:06 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Wed, 20 Jul 2011 13:37:01 +0200 From: Wojciech Dec To: =?ISO-8859-1?B?UultaQ==?= =?ISO-8859-1?B?IERlc3By6XM=?= , Softwires-wg Message-ID: Thread-Topic: Limitation of "4V6 Translation" between sites of the same domain Thread-Index: AcxG0VcUax7DacnHnEilVFcRjD5RGw== In-Reply-To: <9C5F2B03-27FB-4456-BA2B-6AB48BB46642@laposte.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 20 Jul 2011 11:37:07.0098 (UTC) FILETIME=[5AB767A0:01CC46D1] X-Mailman-Approved-At: Wed, 20 Jul 2011 05:37:11 -0700 Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 11:37:12 -0000 Hello Remi, Good question. Thankfully, this is not an issue as answered in Sections 5.4 and 5.5 (and briefly in 5.2) of draft-dec-stateless-4v6, since CPE A would not send non-v4 traffic (e.g. native IPv6 traffic) to CPE-B's 4V6 address. Allow me to expand, along with giving some background 0. The IPv6 4V6 prefix assigned to the CPE is, say, a /64. The CPE thus may use the same /6r prefix to calculate the 4V6 address, using 4V6 domain parameters, as well as other IPv6 addresses in that prefix using SLAAC, say= . As an example: When a suitable 4V6 /64 prefix is advertised in an RA, a 4V6 CPE will configure itself both a 4V6 interface address and a SLAAC address. A similar case applies when DHCP-PD is used. 1. ALL 4V6 systems, without distinction between translation or encapsulatio= n mode, need to use the specific 4V6 IPv6 interface address for their stateless 4V6 function - no other address will do for stateless operation (BTW some may like to call the 4V6 interface a virtual interface). 2. In general, a 4V6 CPE working in translation mode will pass to NAT44 all traffic arriving on the IPv6 4V6 interface - while an encapsulating 4V6 system will pass to NAT44 all encapsulated IPv4 traffic arriving on the IPv= 6 4V6 interface. In both cases there are restrictions on what can be done on/with the 4V6 interface. Some implementation considerations come to the fore, such as the fact that 4V6 is intended to be a custom CPE function and not a user application on a generic host, ie The CPEs kernel typically need= s to support 4V6, and all the above can be accomplished optimally. 3. Traffic originating from IPv6 hosts behind the CPE or sourced by IPv6 apps on the 4V6 CPE itself will use a non 4V6 address as their source address, but from the 4V6 prefix (or its subnet). Hence there is no ambiguity with handling any such IPv6 return traffic. Regards, Woj. On 19/07/2011 10:55, "R=E9mi Despr=E9s" wrote: > Hi, all, >=20 > 1. > The translation-based stateless solution for IPv4 via IPv6 described in > draft-murakami-softwire-4v6-translation-00 seems to have a significant > limitation: > - When a 4V6T customer-edge node receives a packet from a CE of the same = 4V6T > domain, it doesn't know whether it must treat it as a native IPv6 packet = from > this CE or as an IPv4 packet that this CE has translated. >=20 >=20 > <-- 4V6T domain --> <-- IPv4 Internet -- >=20 > (A) 4V6T CE |---->----. > | > V---- 4v6T-BR --- - - - > | > (B) 4V6T CE |----<----' > <=3D v4 or v6 ?? >=20 > For instance, if the IPv4 address of (B) is shared, (B) doesn't know whet= her > received packets must go to its internal NAT44, or be treated a real IPv6 > packet. > (Sending to the NAT44 packets whose ports are currently bound in the NAT4= 4 > wouldn't be satisfactory: all ports may be used in IPv6). >=20 > 2. > Note that this problem doesn't apply to the encapsulation-based stateless > solution (4V6E): > - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet if= , and > only if, its Next header is IP-in-IP, and the encapsulated packet is IPv4= . > There is no ambiguity. >=20 > =3D> Unless something is wrong in the above, or a palliative is devised, > consideration of this should be added to the comparative analysis of 4V6T= and > 4V6E solutions (draft-dec-stateless-4v6). >=20 >=20 > Regards, > RD From despres.remi@laposte.net Wed Jul 20 06:07:14 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7D621F85B5 for ; Wed, 20 Jul 2011 06:07:14 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJtq42rOaXF2 for ; Wed, 20 Jul 2011 06:07:14 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 85DBE21F8577 for ; Wed, 20 Jul 2011 06:06:53 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 0DCF77000099; Wed, 20 Jul 2011 15:06:53 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2419.sfr.fr (SMTP Server) with ESMTP id 6C8A87000089; Wed, 20 Jul 2011 15:06:52 +0200 (CEST) X-SFR-UUID: 20110720130652444.6C8A87000089@msfrf2419.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: Wed, 20 Jul 2011 15:06:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:07:14 -0000 Le 20 juil. 2011 =E0 13:37, Wojciech Dec a =E9crit : > Hello Remi, >=20 > Good question. Thankfully, this is not an issue as answered in = Sections 5.4 > and 5.5 (and briefly in 5.2) of draft-dec-stateless-4v6, since CPE A = would > not send non-v4 traffic (e.g. native IPv6 traffic) to CPE-B's 4V6 = address.=20 >=20 > Allow me to expand, along with giving some background >=20 > 0. The IPv6 4V6 prefix assigned to the CPE is, say, a /64. The CPE = thus may > use the same /6r prefix to calculate the 4V6 address, using 4V6 domain > parameters, as well as other IPv6 addresses in that prefix using = SLAAC, say. > As an example: When a suitable 4V6 /64 prefix is advertised in an RA, = a 4V6 > CPE will configure itself both a 4V6 interface address and a SLAAC = address. > A similar case applies when DHCP-PD is used. >=20 > 1. ALL 4V6 systems, without distinction between translation or = encapsulation > mode, need to use the specific 4V6 IPv6 interface address for their > stateless 4V6 function - no other address will do for stateless = operation > (BTW some may like to call the 4V6 interface a virtual interface). >=20 > 2. In general, a 4V6 CPE working in translation mode will pass to = NAT44 all > traffic arriving on the IPv6 4V6 interface - while an encapsulating = 4V6 > system will pass to NAT44 all encapsulated IPv4 traffic arriving on = the IPv6 > 4V6 interface. In both cases there are restrictions on what can be = done > on/with the 4V6 interface. Some implementation considerations come to = the > fore, such as the fact that 4V6 is intended to be a custom CPE = function and > not a user application on a generic host, ie The CPEs kernel typically = needs > to support 4V6, and all the above can be accomplished optimally. >=20 > 3. Traffic originating from IPv6 hosts behind the CPE or sourced by = IPv6 > apps on the 4V6 CPE itself will use a non 4V6 address as their source > address, but from the 4V6 prefix (or its subnet). Hence there is no > ambiguity with handling any such IPv6 return traffic. >=20 > Regards, > Woj. Thanks, Wojciech, for the explanation. Sec 5.5 indeed says "A 4V6 CE will have a "self configured" 4V6 IPv6 = interface address, alongside any other SLAAC or DHCPv6 derived = addresses, potentially from the same prefix."=20 But it remains that the "self-configured" 4V6 address looks like a valid = SLAAC or DHCPv6 assigned address. In my understanding, the problem is that a receiving CE cannot make the = difference: - between a source 4V6 address coming from a 4v6 CE and one coming from = a non-4V6 CE - between its CE 4V6 address and a real IPv6 destination starting with = the assigned IPv6 prefix With "4V6 Encapsulation", making these differences is unnecessary, but = with "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK = missing. Regards, RD >=20 >=20 >=20 > On 19/07/2011 10:55, "R=E9mi Despr=E9s" = wrote: >=20 >> Hi, all, >>=20 >> 1. >> The translation-based stateless solution for IPv4 via IPv6 described = in >> draft-murakami-softwire-4v6-translation-00 seems to have a = significant >> limitation: >> - When a 4V6T customer-edge node receives a packet from a CE of the = same 4V6T >> domain, it doesn't know whether it must treat it as a native IPv6 = packet from >> this CE or as an IPv4 packet that this CE has translated. >>=20 >>=20 >> <-- 4V6T domain --> <-- IPv4 Internet -- >>=20 >> (A) 4V6T CE |---->----. >> | >> V---- 4v6T-BR --- - - - >> | >> (B) 4V6T CE |----<----' >> <=3D v4 or v6 ?? >>=20 >> For instance, if the IPv4 address of (B) is shared, (B) doesn't know = whether >> received packets must go to its internal NAT44, or be treated a real = IPv6 >> packet. >> (Sending to the NAT44 packets whose ports are currently bound in the = NAT44 >> wouldn't be satisfactory: all ports may be used in IPv6). >>=20 >> 2. >> Note that this problem doesn't apply to the encapsulation-based = stateless >> solution (4V6E): >> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 = packet if, and >> only if, its Next header is IP-in-IP, and the encapsulated packet is = IPv4. >> There is no ambiguity. >>=20 >> =3D> Unless something is wrong in the above, or a palliative is = devised, >> consideration of this should be added to the comparative analysis of = 4V6T and >> 4V6E solutions (draft-dec-stateless-4v6). >>=20 >>=20 >> Regards, >> RD >=20 From wdec.ietf@gmail.com Wed Jul 20 07:20:50 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521ED21F86AF for ; Wed, 20 Jul 2011 07:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlUGWiwPytGY for ; Wed, 20 Jul 2011 07:20:49 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 400E021F86A8 for ; Wed, 20 Jul 2011 07:20:49 -0700 (PDT) Received: by pzk6 with SMTP id 6so372546pzk.26 for ; Wed, 20 Jul 2011 07:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=elJq7kzddh2bbIgjN5HxWHm5sBrbndxFirzuX+5CK6E=; b=JdkO1Z6mqoQyp8WN4aBqd2xCymlFiqEPYD0+ScaLVtd+4kyREkfSRAGwFQCiMAq/pH 2xhdsJP9i3FeMIflEnAo+hrUrX4LMV+BshqRX3iOgF15GZKmpVNbkPukzY5uqvzuzRgZ 8UzF9+5QvENpfgVC75ByvUKWE/7a5Kan1ceAc= MIME-Version: 1.0 Received: by 10.142.133.7 with SMTP id g7mr4192338wfd.117.1311171648936; Wed, 20 Jul 2011 07:20:48 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Wed, 20 Jul 2011 07:20:48 -0700 (PDT) In-Reply-To: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> Date: Wed, 20 Jul 2011 16:20:48 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:20:50 -0000 Hello Remi, On 20 July 2011 15:06, R=E9mi Despr=E9s wrote: > > Le 20 juil. 2011 =E0 13:37, Wojciech Dec a =E9crit : > >> Hello Remi, >> >> Good question. Thankfully, this is not an issue as answered in Sections = 5.4 >> and 5.5 (and briefly in 5.2) of draft-dec-stateless-4v6, since CPE A wou= ld >> not send non-v4 traffic (e.g. native IPv6 traffic) to CPE-B's 4V6 addres= s. > >> >> Allow me to expand, along with giving some background >> >> 0. The IPv6 4V6 prefix assigned to the CPE is, say, a /64. The CPE thus = may >> use the same /6r prefix to calculate the 4V6 address, using 4V6 domain >> parameters, as well as other IPv6 addresses in that prefix using SLAAC, = say. >> As an example: When a suitable 4V6 /64 prefix is advertised in an RA, a = 4V6 >> CPE will configure itself both a 4V6 interface address and a SLAAC addre= ss. >> A similar case applies when DHCP-PD is used. > > >> >> 1. ALL 4V6 systems, without distinction between translation or encapsula= tion >> mode, need to use the specific 4V6 IPv6 interface address for their >> stateless 4V6 function - no other address will do for stateless operatio= n >> (BTW some may like to call the 4V6 interface a virtual interface). >> >> 2. In general, a 4V6 CPE working in translation mode will pass to NAT44 = all >> traffic arriving on the IPv6 4V6 interface - =A0while an encapsulating 4= V6 >> system will pass to NAT44 all encapsulated IPv4 traffic arriving on the = IPv6 >> 4V6 interface. In both cases there are restrictions on what can be done >> on/with the 4V6 interface. Some implementation considerations come to th= e >> fore, such as the fact that 4V6 is intended to be a custom CPE function = and >> not a user application on a generic host, ie The CPEs kernel typically n= eeds >> to support 4V6, and all the above can be accomplished optimally. >> >> 3. Traffic originating from IPv6 hosts behind the CPE or sourced by IPv6 >> apps on the 4V6 CPE itself will use a non 4V6 address as their source >> address, but from the 4V6 prefix (or its subnet). Hence there is no >> ambiguity with handling any such IPv6 return traffic. >> >> Regards, >> Woj. > > Thanks, Wojciech, for the explanation. > > Sec 5.5 indeed says "A 4V6 CE will have a "self configured" 4V6 IPv6 inte= rface address, alongside any other SLAAC or DHCPv6 derived addresses, poten= tially from the same prefix." > But it remains that the "self-configured" 4V6 address looks like a valid = SLAAC or DHCPv6 assigned address. Well, what it is, and what it looks like is *an IPv6 address* and it is valid, and it is in the 4V6 prefix, so I don't quite see what is the issue you're making out. Are you perhaps thinking of a prefix as being a single address? > > In my understanding, the problem is that a receiving CE cannot make the d= ifference: > - between a source 4V6 address coming from a 4v6 CE and one coming from a= non-4V6 CE > - between its CE 4V6 address and a real IPv6 destination starting with th= e assigned IPv6 prefix > With "4V6 Encapsulation", making these differences is unnecessary, but wi= th "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK missing. As per items 1, 2 and 3 above; the CPE does NOT need to make the distinction you make out. If packets are sent to that address, they get passed to NAT44. Hosts behind the CPE or apps on the CPE will not use/bind to that address. Regards, Woj. > > Regards, > RD > > >> >> >> >> On 19/07/2011 10:55, "R=E9mi Despr=E9s" wrote= : >> >>> Hi, all, >>> >>> 1. >>> The translation-based stateless solution for IPv4 via IPv6 described in >>> draft-murakami-softwire-4v6-translation-00 seems to have a significant >>> limitation: >>> - When a 4V6T customer-edge node receives a packet from a CE of the sam= e 4V6T >>> domain, it doesn't know whether it must treat it as a native IPv6 packe= t from >>> this CE or as an IPv4 packet that this CE has translated. >>> >>> >>> =A0 =A0 =A0 =A0<-- 4V6T domain --> =A0 <-- IPv4 Internet -- >>> >>> (A) 4V6T CE |---->----. >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V---- 4v6T-BR --- - - - >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>> (B) 4V6T CE |----<----' >>> =A0 =A0 =A0 =A0<=3D v4 or v6 ?? >>> >>> For instance, if the IPv4 address of (B) is shared, (B) doesn't know wh= ether >>> received packets must go to its internal NAT44, or be treated a real IP= v6 >>> packet. >>> (Sending to the NAT44 packets whose ports are currently bound in the NA= T44 >>> wouldn't be satisfactory: all ports may be used in IPv6). >>> >>> 2. >>> Note that this problem doesn't apply to the encapsulation-based statele= ss >>> solution (4V6E): >>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet = if, and >>> only if, its Next header is IP-in-IP, and the encapsulated packet is IP= v4. >>> There is no ambiguity. >>> >>> =3D> Unless something is wrong in the above, or a palliative is devised= , >>> consideration of this should be added to the comparative analysis of 4V= 6T and >>> 4V6E solutions (draft-dec-stateless-4v6). >>> >>> >>> Regards, >>> RD >> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Wed Jul 20 07:57:35 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA0521F86E1 for ; Wed, 20 Jul 2011 07:57:35 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqCOkAocYAeC for ; Wed, 20 Jul 2011 07:57:35 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id C0ACA21F8665 for ; Wed, 20 Jul 2011 07:57:34 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 26E4F700008E; Wed, 20 Jul 2011 16:57:34 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id A987F7000094; Wed, 20 Jul 2011 16:57:31 +0200 (CEST) X-SFR-UUID: 20110720145731694.A987F7000094@msfrf2206.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: Wed, 20 Jul 2011 16:57:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:57:35 -0000 Le 20 juil. 2011 =E0 16:20, Wojciech Dec a =E9crit : >> ... >> Sec 5.5 indeed says "A 4V6 CE will have a "self configured" 4V6 IPv6 = interface address, alongside any other SLAAC or DHCPv6 derived = addresses, potentially from the same prefix." >> But it remains that the "self-configured" 4V6 address looks like a = valid SLAAC or DHCPv6 assigned address. >=20 > Well, what it is, and what it looks like is *an IPv6 address* and it > is valid, and it is in the 4V6 prefix, That's what I meant: Although the 4V6 address was obtained neither with SLAAC nor with = DHCPv6, it can't be distinguished from an ordinary SLAA-C of = DHCPv6-obtained address.=20 > so I don't quite see what is > the issue you're making out. Are you perhaps thinking of a prefix as > being a single address? NO (?!) >> In my understanding, the problem is that a receiving CE cannot make = the difference: >> - between a source 4V6 address coming from a 4v6 CE and one coming = from a non-4V6 CE >> - between its CE 4V6 address and a real IPv6 destination starting = with the assigned IPv6 prefix >> With "4V6 Encapsulation", making these differences is unnecessary, = but with "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK = missing. >=20 > As per items 1, 2 and 3 above; the CPE does NOT need to make the > distinction you make out.=20 > If packets are sent to that address, they > get passed to NAT44. Hosts behind the CPE or apps on the CPE will not > use/bind to that address. AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN = side. Such a constraint isn't needed with "4V6 encapsulation". RD > Regards, > Woj. >>=20 >> Regards, >> RD >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> On 19/07/2011 10:55, "R=E9mi Despr=E9s" = wrote: >>>=20 >>>> Hi, all, >>>>=20 >>>> 1. >>>> The translation-based stateless solution for IPv4 via IPv6 = described in >>>> draft-murakami-softwire-4v6-translation-00 seems to have a = significant >>>> limitation: >>>> - When a 4V6T customer-edge node receives a packet from a CE of the = same 4V6T >>>> domain, it doesn't know whether it must treat it as a native IPv6 = packet from >>>> this CE or as an IPv4 packet that this CE has translated. >>>>=20 >>>>=20 >>>> <-- 4V6T domain --> <-- IPv4 Internet -- >>>>=20 >>>> (A) 4V6T CE |---->----. >>>> | >>>> V---- 4v6T-BR --- - - - >>>> | >>>> (B) 4V6T CE |----<----' >>>> <=3D v4 or v6 ?? >>>>=20 >>>> For instance, if the IPv4 address of (B) is shared, (B) doesn't = know whether >>>> received packets must go to its internal NAT44, or be treated a = real IPv6 >>>> packet. >>>> (Sending to the NAT44 packets whose ports are currently bound in = the NAT44 >>>> wouldn't be satisfactory: all ports may be used in IPv6). >>>>=20 >>>> 2. >>>> Note that this problem doesn't apply to the encapsulation-based = stateless >>>> solution (4V6E): >>>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 = packet if, and >>>> only if, its Next header is IP-in-IP, and the encapsulated packet = is IPv4. >>>> There is no ambiguity. >>>>=20 >>>> =3D> Unless something is wrong in the above, or a palliative is = devised, >>>> consideration of this should be added to the comparative analysis = of 4V6T and >>>> 4V6E solutions (draft-dec-stateless-4v6). >>>>=20 >>>>=20 >>>> Regards, >>>> RD >>>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 From wdec.ietf@gmail.com Wed Jul 20 09:02:43 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D359D21F8A6F for ; Wed, 20 Jul 2011 09:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NjabZ-eYE4i for ; Wed, 20 Jul 2011 09:02:42 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3805121F8A71 for ; Wed, 20 Jul 2011 09:02:42 -0700 (PDT) Received: by gxk19 with SMTP id 19so189934gxk.31 for ; Wed, 20 Jul 2011 09:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5mD2V/wNXkSzs6xCw70RM+npRPIBEDJjiK9zOyxCM8c=; b=gJiBKdwHuaymAKPb2chkKn+O/3456XdD6AV5ydTMCbEd2wsSUzsAlsXs5x5/F/5CVh Z6J8q4nXue6h45I10kmuUYYJGoqzmgSpJlQYtvWipBse3XQwv/WofZulb43I33ZYmDlB 2QxKwEeb3GS8qz0uW6uvRLMJjMctYABQIl1Xw= MIME-Version: 1.0 Received: by 10.142.133.7 with SMTP id g7mr4243635wfd.117.1311177760951; Wed, 20 Jul 2011 09:02:40 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Wed, 20 Jul 2011 09:02:40 -0700 (PDT) In-Reply-To: <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> Date: Wed, 20 Jul 2011 18:02:40 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:02:43 -0000 On 20 July 2011 16:57, R=E9mi Despr=E9s wrote: > > Le 20 juil. 2011 =E0 16:20, Wojciech Dec a =E9crit : > >>> ... >>> Sec 5.5 indeed says "A 4V6 CE will have a "self configured" 4V6 IPv6 in= terface address, alongside any other SLAAC or DHCPv6 derived addresses, pot= entially from the same prefix." >>> But it remains that the "self-configured" 4V6 address looks like a vali= d SLAAC or DHCPv6 assigned address. >> >> Well, what it is, and what it looks like is *an IPv6 address* and it >> is valid, and it is in the 4V6 prefix, > > That's what I meant: > Although the 4V6 address was obtained neither with SLAAC nor with DHCPv6,= it can't be distinguished from an ordinary SLAA-C of DHCPv6-obtained addre= ss. It is an IPv6 address, granted. There is however something special about it, as per the 4rd spec. It has a well known IID, and in effect becomes a kind of well-known address. > >> so I don't quite see what is >> the issue you're making out. Are you perhaps thinking of a prefix as >> being a single address? > > NO (?!) > > >>> In my understanding, the problem is that a receiving CE cannot make the= difference: >>> - between a source 4V6 address coming from a 4v6 CE and one coming from= a non-4V6 CE >>> - between its CE 4V6 address and a real IPv6 destination starting with = the assigned IPv6 prefix >>> With "4V6 Encapsulation", making these differences is unnecessary, but = with "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK missin= g. >> >> As per items 1, 2 and 3 above; the CPE does NOT need to make the >> distinction you make out. > >> If packets are sent to that address, they >> get passed to NAT44. Hosts behind the CPE or apps on the CPE will not >> use/bind to that address. > > AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN side. > Such a constraint isn't needed with "4V6 encapsulation". No. A 4v6 prefix can be advertised out of the CE LAN, and an fully formed address (eg SLAAC) from it assigned. In fact, the 4V6 address can be "wherever" on the CPE should you choose to implement it that way - how you do this is subject to CPE implementation. Just as it is implementation specific how you dictate the 4V6 function to source packets from that address, and how you prevent some other CPE based process that wants to use IPv6 from using that 4v6 address (eg another process that also wants to use IPinIP encap, or whatever). Yes, there is a difference when implementing the tunneling and the translation modes on the CPE - that's stating the obvious if you ask me, but point taken, I will remark on this in the draft. -Woj. > > RD > > > > >> Regards, >> Woj. >>> >>> Regards, >>> RD >>> >>> >>>> >>>> >>>> >>>> On 19/07/2011 10:55, "R=E9mi Despr=E9s" wro= te: >>>> >>>>> Hi, all, >>>>> >>>>> 1. >>>>> The translation-based stateless solution for IPv4 via IPv6 described = in >>>>> draft-murakami-softwire-4v6-translation-00 seems to have a significan= t >>>>> limitation: >>>>> - When a 4V6T customer-edge node receives a packet from a CE of the s= ame 4V6T >>>>> domain, it doesn't know whether it must treat it as a native IPv6 pac= ket from >>>>> this CE or as an IPv4 packet that this CE has translated. >>>>> >>>>> >>>>> =A0 =A0 =A0 =A0<-- 4V6T domain --> =A0 <-- IPv4 Internet -- >>>>> >>>>> (A) 4V6T CE |---->----. >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V---- 4v6T-BR --- - - - >>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>>>> (B) 4V6T CE |----<----' >>>>> =A0 =A0 =A0 =A0<=3D v4 or v6 ?? >>>>> >>>>> For instance, if the IPv4 address of (B) is shared, (B) doesn't know = whether >>>>> received packets must go to its internal NAT44, or be treated a real = IPv6 >>>>> packet. >>>>> (Sending to the NAT44 packets whose ports are currently bound in the = NAT44 >>>>> wouldn't be satisfactory: all ports may be used in IPv6). >>>>> >>>>> 2. >>>>> Note that this problem doesn't apply to the encapsulation-based state= less >>>>> solution (4V6E): >>>>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packe= t if, and >>>>> only if, its Next header is IP-in-IP, and the encapsulated packet is = IPv4. >>>>> There is no ambiguity. >>>>> >>>>> =3D> Unless something is wrong in the above, or a palliative is devis= ed, >>>>> consideration of this should be added to the comparative analysis of = 4V6T and >>>>> 4V6E solutions (draft-dec-stateless-4v6). >>>>> >>>>> >>>>> Regards, >>>>> RD >>>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> > > > From wdec.ietf@gmail.com Wed Jul 20 09:25:43 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CBA21F8AFD for ; Wed, 20 Jul 2011 09:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHTxxcD4hFiu for ; Wed, 20 Jul 2011 09:25:42 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4DCE21F8AD8 for ; Wed, 20 Jul 2011 09:25:42 -0700 (PDT) Received: by gyd5 with SMTP id 5so201976gyd.31 for ; Wed, 20 Jul 2011 09:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aLas9mPc6++CMbAQuunXv9xGfGlJlB65KMQ3ICIBTRQ=; b=VK6HacuPIpH8CPz8Wyr4QYCqBswijLpYHWpnfs5xKNY107paApAVX3wYd3nVXq+g7e 89Se2DQqVzrHUDMAFL38XHEf48TDCNuZ/mpbCYE68yeVYZJxp4KG2VsWZBezQA0kvq+r PB2MSsFqCSwsH70zpxBjcIHB6gi+iawAfWzqc= MIME-Version: 1.0 Received: by 10.142.133.7 with SMTP id g7mr4254889wfd.117.1311179141412; Wed, 20 Jul 2011 09:25:41 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Wed, 20 Jul 2011 09:25:41 -0700 (PDT) In-Reply-To: References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> Date: Wed, 20 Jul 2011 18:25:41 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:25:43 -0000 Correcting typo and truncated sentence. On 20 July 2011 18:02, Wojciech Dec wrote: > On 20 July 2011 16:57, R=E9mi Despr=E9s wrote: >> >> Le 20 juil. 2011 =E0 16:20, Wojciech Dec a =E9crit : >> >>>> ... >>>> Sec 5.5 indeed says "A 4V6 CE will have a "self configured" 4V6 IPv6 i= nterface address, alongside any other SLAAC or DHCPv6 derived addresses, po= tentially from the same prefix." >>>> But it remains that the "self-configured" 4V6 address looks like a val= id SLAAC or DHCPv6 assigned address. >>> >>> Well, what it is, and what it looks like is *an IPv6 address* and it >>> is valid, and it is in the 4V6 prefix, >> >> That's what I meant: >> Although the 4V6 address was obtained neither with SLAAC nor with DHCPv6= , it can't be distinguished from an ordinary SLAA-C of DHCPv6-obtained addr= ess. > > It is an IPv6 address, granted. There is however something special > about it, as per the 4rd spec. It has a well known IID, and in effect > becomes a kind of well-known address. > >> >>> so I don't quite see what is >>> the issue you're making out. Are you perhaps thinking of a prefix as >>> being a single address? >> >> NO (?!) >> >> >>>> In my understanding, the problem is that a receiving CE cannot make th= e difference: >>>> - between a source 4V6 address coming from a 4v6 CE and one coming fro= m a non-4V6 CE >>>> - between its CE 4V6 address and a real IPv6 destination starting with= the assigned IPv6 prefix >>>> With "4V6 Encapsulation", making these differences is unnecessary, but= with "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK missi= ng. >>> >>> As per items 1, 2 and 3 above; the CPE does NOT need to make the >>> distinction you make out. >> >>> If packets are sent to that address, they >>> get passed to NAT44. Hosts behind the CPE or apps on the CPE will not >>> use/bind to that address. >> >> AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN side= . >> Such a constraint isn't needed with "4V6 encapsulation". > > No. A 4v6 prefix can be advertised out of the CE LAN, and any fully > formed address (eg SLAAC) from it assigned to the CE's LAN or host. > In fact, the 4V6 address can be "wherever" on the CPE should you > choose to implement it that way - how you do this is subject to CPE > implementation. Just as it is implementation specific how you dictate > the 4V6 function to source packets from that address, and how you > prevent some other CPE based process that wants to use IPv6 from using > that 4v6 address (eg another process that also wants to use IPinIP > encap, or whatever). > Yes, there is a difference when implementing the tunneling and the > translation modes on the CPE - that's stating the obvious if you ask > me, but point taken, I will remark on this in the draft. > > -Woj. > > >> >> RD >> >> >> >> >>> Regards, >>> Woj. >>>> >>>> Regards, >>>> RD >>>> >>>> >>>>> >>>>> >>>>> >>>>> On 19/07/2011 10:55, "R=E9mi Despr=E9s" wr= ote: >>>>> >>>>>> Hi, all, >>>>>> >>>>>> 1. >>>>>> The translation-based stateless solution for IPv4 via IPv6 described= in >>>>>> draft-murakami-softwire-4v6-translation-00 seems to have a significa= nt >>>>>> limitation: >>>>>> - When a 4V6T customer-edge node receives a packet from a CE of the = same 4V6T >>>>>> domain, it doesn't know whether it must treat it as a native IPv6 pa= cket from >>>>>> this CE or as an IPv4 packet that this CE has translated. >>>>>> >>>>>> >>>>>> =A0 =A0 =A0 =A0<-- 4V6T domain --> =A0 <-- IPv4 Internet -- >>>>>> >>>>>> (A) 4V6T CE |---->----. >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0V---- 4v6T-BR --- - - - >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>>>>> (B) 4V6T CE |----<----' >>>>>> =A0 =A0 =A0 =A0<=3D v4 or v6 ?? >>>>>> >>>>>> For instance, if the IPv4 address of (B) is shared, (B) doesn't know= whether >>>>>> received packets must go to its internal NAT44, or be treated a real= IPv6 >>>>>> packet. >>>>>> (Sending to the NAT44 packets whose ports are currently bound in the= NAT44 >>>>>> wouldn't be satisfactory: all ports may be used in IPv6). >>>>>> >>>>>> 2. >>>>>> Note that this problem doesn't apply to the encapsulation-based stat= eless >>>>>> solution (4V6E): >>>>>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 pack= et if, and >>>>>> only if, its Next header is IP-in-IP, and the encapsulated packet is= IPv4. >>>>>> There is no ambiguity. >>>>>> >>>>>> =3D> Unless something is wrong in the above, or a palliative is devi= sed, >>>>>> consideration of this should be added to the comparative analysis of= 4V6T and >>>>>> 4V6E solutions (draft-dec-stateless-4v6). >>>>>> >>>>>> >>>>>> Regards, >>>>>> RD >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >> >> >> > From brian.e.carpenter@gmail.com Wed Jul 20 19:11:23 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ADE21F854E for ; Wed, 20 Jul 2011 19:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.613 X-Spam-Level: X-Spam-Status: No, score=-103.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvFF+7DfKKF6 for ; Wed, 20 Jul 2011 19:11:22 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87E7121F8506 for ; Wed, 20 Jul 2011 19:11:21 -0700 (PDT) Received: by vxi40 with SMTP id 40so727240vxi.31 for ; Wed, 20 Jul 2011 19:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ndG8UvGKbrUhP5NVqTI34i3XIQI02HMkU2qny0RFBis=; b=GqIcP/LGIBZQFsX24LhX4Il1GfB/aALvjsYpsuS93ipe7cxtm4FEdoboAQVX1kdRql LiL708mPfPv9mIKl+mxFiqYhMZdg1M/Wgn3h8XRYxqnoVrwCGcCF3cbxLIKMcic0U7d6 ZukPjvD83c/Dv51SZ98nBhba1AGDGd0kCOjSs= Received: by 10.52.26.105 with SMTP id k9mr6878720vdg.270.1311214280852; Wed, 20 Jul 2011 19:11:20 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y4sm446635vdv.1.2011.07.20.19.11.18 (version=SSLv3 cipher=OTHER); Wed, 20 Jul 2011 19:11:20 -0700 (PDT) Message-ID: <4E278ACE.8050304@gmail.com> Date: Thu, 21 Jul 2011 14:11:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Softwires , draft-donley-softwire-dslite-flowlabel@tools.ietf.org References: <20110711200014.3862.73602.idtracker@ietfa.amsl.com> In-Reply-To: <20110711200014.3862.73602.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] I-D Action: draft-donley-softwire-dslite-flowlabel-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, 21 Jul 2011 02:11:23 -0000 Hi, The work on updating RFC 3697 has moved on and is currently in IESG discussion. The editorial impact on draft-donley-softwire-dslite-flowlabel is that the references to [RFC3697] and [I-D.ietf-6man-flow-update] need to be replaced by a single reference to [I-D.ietf-6man-flow-3697bis]. The 6man WG consensus is to document only a stateless approach to the flow label, with a recommendation that the flow label values should belong to a uniform distribution, so that load balancing will work better. As far as I can see, this suggestion in draft-donley is consistent with that: > Implementations could use a 20-bit hash of the IPv4 5-tuple such that > subsequent IPv4 packets with the same 5-tuple will receive the same > flow label. However, since the discussion in draft-ietf-6man-flow-3697bis is about using a 20-bit hash of the IPv6 5-tuple, a few extra words may be needed here, e.g. , in the same way that [I-D.ietf-6man-flow-3697bis] recommends a hash of the IPv6 5-tuple. More seriously, I don't understand the following text: > As directed by [RFC3697] and [I-D.ietf-6man-flow-update], Flow Label > information is only significant to the B4 or AFTR transmitting the > particular DS-Lite flow. Since the Flow Label will be consistently > applied to all packets in the flow, however, intermediate devices > between the B4 and AFTR can use the Flow Label in packet classifiers > to provide quality of service treatment to the flow. The first sentence isn't obvious to me. The point is that the bits in the flow label don't have any semantics; you could think of it as a nonce. How will the downstream nodes know what treatment to apply? Who tells them that a given new flow is, for example, VoIP? That would need a signaling mechanism - not forbidden by 3697bis, but not specified either. I thought that's what diffserv was for. Regards Brian Carpenter From phdgang@gmail.com Wed Jul 20 19:12:43 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720CF21F8581 for ; Wed, 20 Jul 2011 19:12:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNgUuMNohNxb for ; Wed, 20 Jul 2011 19:12:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5321F856C for ; Wed, 20 Jul 2011 19:12:42 -0700 (PDT) Received: by vws12 with SMTP id 12so731397vws.31 for ; Wed, 20 Jul 2011 19:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OZbb8dSzxhBy8/k6SRjApBwYhKpP5lCysY9PGqaQp7s=; b=JPoa0LBDh+1SnFP9R+vpe6OwchAjf9PMLuEXb+1i+zsLZ3Q7TLXon8KozC3VW2p8uo XejxGJTFHKFdh1dJ5d8sdnZQM9s8HRqpkOEMwRvBUVWVtybdAcUKat7MLal7CquOxGNC Trj/9CxNs8eHze/55Kvevp7jhc7a3YBYsjAaA= MIME-Version: 1.0 Received: by 10.52.32.162 with SMTP id k2mr9991344vdi.50.1311214362372; Wed, 20 Jul 2011 19:12:42 -0700 (PDT) Received: by 10.52.169.194 with HTTP; Wed, 20 Jul 2011 19:12:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Jul 2011 10:12:42 +0800 Message-ID: From: GangChen To: Alain Durand , Cui Yong Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org list" Subject: Re: [Softwires] IETF81 agenda X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 02:12:43 -0000 Dear Chairs, Allow me to explain the suggestion on the agenda. Topic 8 presents 4via6 stateless tunneling solution. Topic 9 presents the analysis on both 4via6 tunneling and translation schemes. So, it is the most logical way to move topic19 in between. Please consider this proposal. Many thanks Gang 2011/7/19, GangChen : > Dear Chairs, > > The presentation "4via6 Stateless Translation"(i.e. topic 19) is > highly related to topic 8 and 9. > May I suggest to move topic 19 together with 8 and 9? > That would be helpful for the discussion > > Many thanks > > Gang > > 2011/7/18, Alain Durand : >> The agenda has been posted. >> >> - Alain & Yong. >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > From jacniq@gmail.com Wed Jul 20 21:09:14 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2299B21F85C7 for ; Wed, 20 Jul 2011 21:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDhaok+n8RsE for ; Wed, 20 Jul 2011 21:09:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54A0B21F85CA for ; Wed, 20 Jul 2011 21:09:13 -0700 (PDT) Received: by vxi40 with SMTP id 40so777549vxi.31 for ; Wed, 20 Jul 2011 21:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EVXJMpMferDLLhJF1127wxL/HgdFph3zN7t2Qb2Th0Q=; b=py/ScsFUay8q4Y4Fjx/00FCBXanbKd6CR9OEzEyLk5ly16SHSnuXoISOJfheU+qrpq +yC7VY6P89KzL72cO8MlC/xlrcKsK/RZJ+SqErOXiN36VL5pUh1Hx6YSd4DoIahQtmpU ecGdi469aaG8+eiiznJxh1Upje4NymBJgJz0w= MIME-Version: 1.0 Received: by 10.52.89.147 with SMTP id bo19mr10023038vdb.523.1311221352492; Wed, 20 Jul 2011 21:09:12 -0700 (PDT) Received: by 10.52.111.138 with HTTP; Wed, 20 Jul 2011 21:09:12 -0700 (PDT) In-Reply-To: <7FB924B7-0067-45CB-A0F4-02F15504363E@laposte.net> References: <7FB924B7-0067-45CB-A0F4-02F15504363E@laposte.net> Date: Thu, 21 Jul 2011 12:09:12 +0800 Message-ID: From: Jacni Qin To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3071c690efecda04a88c828f Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on 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, 21 Jul 2011 04:09:14 -0000 --20cf3071c690efecda04a88c828f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Remi, Thanks, inline please, On Wed, Jul 20, 2011 at 5:45 PM, R=E9mi Despr=E9s wrote: > Hi, Jacni, > > ... > > In addition to Satoru's answer, an ISP that has many IPv4 prefixes can: > - use only a few, or even only one, of its shortest IPv4 prefixes, and > - use IPv4 address sharing to support as many CE's as needed. > > Example: an ISP has a /10, a /11, another /11, a /14, a /15, and a /16 (a > real example I met). > It can: > - use three domains (the /10 and the two /11's), or > - use only the /10, extending Port-set ID by one bit to support as many > CE's > In both cases, no entropy due to the fragmented IPv4 space needs to be > exported to the IPv6 addressing plan. > Jacni>: Ok, I got you point, Another question is to make sure that continuous IPv6 pools (with EA) are assigned on multiple Access Gateways (BNG) within the same 4rd domain. Plus, the reality is even more complicated, For example, there are group/HQ and branches. The shorter prefixes are probably held by the group level, and several/many 4rd domains (according t= o the sizes of cities under given branch) will be maintained by the branches who can only get fragmented spaces, since a large amount of these spaces come from leftover prefixes returned. Cheers, Jacni > Leftover IPv4 prefixes can then be returned to the community (for free... > or for a price, whatever applies). > > Regards, > RD > > > > Cheers, > Jacni > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --20cf3071c690efecda04a88c828f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Remi,

Thanks, inline please,
On Wed, Jul 20, 2011 at 5:45 PM, R= =E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Hi, Jac= ni,

...

In addition to Satoru's answer, an ISP that has ma= ny IPv4 prefixes can:
- use only a few, or even only one, of its = shortest IPv4 prefixes, and
- use IPv4 address sharing to support= as many CE's as needed.=A0

Example: an ISP has a /10, a /11, another /11, a /14, a= /15, and a /16 (a real example I met).
It can:
- use t= hree domains (the /10 and the two /11's), or
- use only the /= 10, extending Port-set ID by one bit to support as many CE's
In both cases, no entropy due to the fragmented IPv4 space needs to be= exported to the IPv6 addressing plan.
=

Jacni>: Ok, I got you point, =
Another question is to make sure t= hat=20 continuous IPv6 pools (with EA) are assigned on multiple Access Gateways (B= NG)=20 within the same 4rd domain.

Plus, the reality is even more complicated,
For example, there are grou= p/HQ and branches. The shorter prefixes are probably held by the group leve= l, and several/many 4rd domains (according to the sizes of cities under giv= en branch) will be maintained by the branches who can only get fragmented s= paces, since a large amount of these spaces come from leftover prefixes ret= urned.


Cheers,
Jacni


Leftover IPv4 prefixes can then be returned to the community= (for free... or for a price, whatever applies).
=A0=A0
Rega= rds,
RD



Cheers,
Jacni

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


--20cf3071c690efecda04a88c828f-- From despres.remi@laposte.net Thu Jul 21 00:13:08 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4226221F8B5A for ; Thu, 21 Jul 2011 00:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbKjYu0HFW-j for ; Thu, 21 Jul 2011 00:13:05 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA6221F85EA for ; Thu, 21 Jul 2011 00:13:04 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 348E07000081; Thu, 21 Jul 2011 09:13:02 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 8E1E67000084; Thu, 21 Jul 2011 09:13:01 +0200 (CEST) X-SFR-UUID: 20110721071301582.8E1E67000084@msfrf2218.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-65216124 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 21 Jul 2011 09:13:01 +0200 Message-Id: <4D5B99EF-30C7-4485-91AC-C436C383C3C5@laposte.net> References: <7FB924B7-0067-45CB-A0F4-02F15504363E@laposte.net> To: Jacni Qin X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on 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, 21 Jul 2011 07:13:08 -0000 --Apple-Mail-11-65216124 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 21 juil. 2011 =E0 06:09, Jacni Qin a =E9crit : > Hi Remi, >=20 > Thanks, inline please, >=20 > On Wed, Jul 20, 2011 at 5:45 PM, R=E9mi Despr=E9s = wrote: > Hi, Jacni, >=20 > ... >=20 > In addition to Satoru's answer, an ISP that has many IPv4 prefixes = can: > - use only a few, or even only one, of its shortest IPv4 prefixes, and > - use IPv4 address sharing to support as many CE's as needed.=20 >=20 > Example: an ISP has a /10, a /11, another /11, a /14, a /15, and a /16 = (a real example I met). > It can: > - use three domains (the /10 and the two /11's), or > - use only the /10, extending Port-set ID by one bit to support as = many CE's > In both cases, no entropy due to the fragmented IPv4 space needs to be = exported to the IPv6 addressing plan. >=20 > Jacni>: Ok, I got you point,=20 Thanks. > Another question is to make sure that continuous IPv6 pools (with EA) = are assigned on multiple Access Gateways (BNG) within the same 4rd = domain. I don't understand the question. Could you clarify? > Plus, the reality is even more complicated, > For example, there are group/HQ and branches. The shorter prefixes are = probably held by the group level, and several/many 4rd domains = (according to the sizes of cities under given branch) will be maintained = by the branches who can only get fragmented spaces, since a large amount = of these spaces come from leftover prefixes returned. Again, not sure to get the question. The simple approach is "one IPv6 prefix" =3D> "one 4rd prefix" (no = fragmented spaces). Changing the length of one changes the length of the other. Cheers, RD =20 >=20 >=20 > Cheers, > Jacni >=20 >=20 > Leftover IPv4 prefixes can then be returned to the community (for = free... or for a price, whatever applies). > =20 > Regards, > RD >=20 >>=20 >>=20 >> Cheers, >> Jacni >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-11-65216124 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Remi,

Thanks, = inline please,

On Wed, Jul 20, = 2011 at 5:45 PM, R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:
Hi, Jacni,

...

In addition to Satoru's answer, an ISP that has = many IPv4 prefixes can:
- use only a few, or even only one, of = its shortest IPv4 prefixes, and
- use IPv4 address sharing to = support as many CE's as needed. 

Example: an ISP has a /10, a /11, another /11, a = /14, a /15, and a /16 (a real example I met).
It = can:
- use three domains (the /10 and the two /11's), = or
- use only the /10, extending Port-set ID by one bit to = support as many CE's
In both cases, no entropy due to the fragmented IPv4 space needs to = be exported to the IPv6 addressing = plan.

Jacni>: Ok, I got you point, =

Thanks.

<= blockquote type=3D"cite">
Another question is to make = sure that=20 continuous IPv6 pools (with EA) are assigned on multiple Access Gateways = (BNG)=20 within the same 4rd = domain.

I don't = understand the question.
Could you = clarify?

Plus, the = reality is even more complicated,
For example, there are group/HQ and = branches. The shorter prefixes are probably held by the group level, and = several/many 4rd domains (according to the sizes of cities under given = branch) will be maintained by the branches who can only get fragmented = spaces, since a large amount of these spaces come from leftover prefixes = returned.

Again, = not sure to get the question.
The simple approach is "one IPv6 = prefix" =3D> "one 4rd prefix" (no fragmented = spaces).
Changing the length of one changes the length of the = other.

Cheers,
RD

<= div>

 



Cheers,
Jacni


Leftover IPv4 prefixes can then be returned to the = community (for free... or for a price, whatever = applies).
  
Regards,
RD

=


Cheers,
Jacni

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



= --Apple-Mail-11-65216124-- From despres.remi@laposte.net Thu Jul 21 02:06:45 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459BA21F8B8F for ; Thu, 21 Jul 2011 02:06:45 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUpZIIOvWGxl for ; Thu, 21 Jul 2011 02:06:44 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8568021F8B8D for ; Thu, 21 Jul 2011 02:06:43 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2103.sfr.fr (SMTP Server) with ESMTP id 65802700008A; Thu, 21 Jul 2011 11:06:42 +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 23B997000096; Thu, 21 Jul 2011 11:06:38 +0200 (CEST) X-SFR-UUID: 20110721090638146.23B997000096@msfrf2103.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, 21 Jul 2011 11:06:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:06:45 -0000 Le 20 juil. 2011 =E0 18:25, Wojciech Dec a =E9crit : >>> ... >>>> If packets are sent to that address, they >>>> get passed to NAT44. Hosts behind the CPE or apps on the CPE will = not >>>> use/bind to that address. >>>=20 >>> AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN = side. >>> Such a constraint isn't needed with "4V6 encapsulation". >>=20 >> No. A justification of this "no" is missing, because: - The CE 4V6 address is synonymous with a valid IPv6 address in the = range defined by the CE IPv6 prefix. - With 4V6T, a translated IPv4 packet entering a 4V6 site cannot be = distinguished from an IPv6 packet destined to this valid IPv6 address. An example: Host=20 H +-+ router | |< 2001:db8:a:: =20 | |--------------. .-. | | | | |< 2001:db8:a::/64 4V6T CE +-+ LAN |--| |-----------------. +-+ | | | | | |< 2001:db8:a:/56=20 --------------' '-' LAN |---| |------------ | +-+ <=3D IPv6 packet ----------------' sent to host H - The IPv6 address of host H has a permitted value (at least per sec = 3.2.1 of RFC 3041 on privacy addresses). - It is the same as the CE 4V6 address, per current drafts on 4V6 = specifications. =3D> The IPv6 packet sent to X form the Internet is taken by the 4V6T CE = as a translated IPv4 packet. It is submitted to the CE NAT44. It won't therefore reach its destination. With a 4V6E CE, the CE recognizes that the IPv6 packet doesn't contain = an encapsulated IPv4 packet. It therefore forwards it in IPv6 on its LAN side. If this is wrong, thank you for an explanation. RD =20 =20 =20= From wdec.ietf@gmail.com Thu Jul 21 02:08:55 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8304E21F8B8F for ; Thu, 21 Jul 2011 02:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cF2jBC7ZKy7 for ; Thu, 21 Jul 2011 02:08:51 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6A55A21F8B91 for ; Thu, 21 Jul 2011 02:08:51 -0700 (PDT) Received: by pzk6 with SMTP id 6so1510708pzk.26 for ; Thu, 21 Jul 2011 02:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WH85Ytvx5eBhIQi0ND1PXxkSvIIp90qKszNkgtiWGi0=; b=xoHgjFnKL6nL3TqJjov/+JUASUJ9mBcRcEeDcD0GQvvBj+umhCiWcs+QAwCzBFfIys ELsW7AxPeg131+mLOlI5DQyWCG11PkgBBx41FimzuugnCu/v+mud7VqN8NF1t213DPnV +PYt3Fnqe+VijPM9uyRZ0obm08AVEeq18r2F0= MIME-Version: 1.0 Received: by 10.142.133.7 with SMTP id g7mr7024wfd.117.1311239331102; Thu, 21 Jul 2011 02:08:51 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Thu, 21 Jul 2011 02:08:51 -0700 (PDT) In-Reply-To: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> Date: Thu, 21 Jul 2011 11:08:51 +0200 Message-ID: From: Wojciech Dec To: Mark Townsley , Softwire Chairs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org list" Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:08:55 -0000 I would like to support Mark's observation and add one more: While fine and chartered drafts like MIBs (20 minutes) and multicast (30 minutes) surely have discussion merit, besides merit of non-chartered drafts like B4-NAT-bypass, DHCP- .., etc, (30 minutes in all), given that WG facetime comes at a premium it would be fair to prioritize discussions around the issues that appear to be in most need of such facetime. In view of this assigning 4 drafts of stateless46 into collectively 20 minutes appears to be questionable, and more so given past precedent in terms of the difficulty in getting a discussion going in this WG. Thanks, Wojciech. On 19 July 2011 11:24, Mark Townsley wrote: > > The schedule is obviously rather busy. Here's a suggestion: Softwires has= 30 minutes of Multicast transition presentation, while we have an entire B= oF devoted to the subject earlier in the week. Do we really need to schedul= e time for this twice? > > - Mark > > > On Jul 18, 2011, at 3:55 PM, Alain Durand wrote: > >> The agenda has been posted. >> >> =A0- Alain & Yong. >> _______________________________________________ >> 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 Thu Jul 21 02:30:30 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE64521F8BB3 for ; Thu, 21 Jul 2011 02:30:30 -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.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8pTyBzQxcKY for ; Thu, 21 Jul 2011 02:30:30 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02EF721F8B8C for ; Thu, 21 Jul 2011 02:30:24 -0700 (PDT) Received: by pvh18 with SMTP id 18so1329338pvh.31 for ; Thu, 21 Jul 2011 02:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=94o3m5Gl0kV2mPqWM+0edLeikliUmFrXA/rX5SvvbnA=; b=j/1Z0TObbKN+P0mIwz58YGkljNa9MuDLeixqvv1n96XLRCJ/sLaSZoHjWSjRnyyEpR RrwN+lkPMVSEf1BVrMz+FWmYveKfInLcavNeXXzcuiU3JbCFbA4kg6iz1mTyNUF+r15F dLMwLVrfY2VjevIIkSZrMIHCc/TS+4UBhPR7s= MIME-Version: 1.0 Received: by 10.142.177.1 with SMTP id z1mr13353wfe.174.1311240624492; Thu, 21 Jul 2011 02:30:24 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Thu, 21 Jul 2011 02:30:24 -0700 (PDT) In-Reply-To: References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> Date: Thu, 21 Jul 2011 11:30:24 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:30:30 -0000 On 21 July 2011 11:06, R=E9mi Despr=E9s wrote: > > Le 20 juil. 2011 =E0 18:25, Wojciech Dec a =E9crit : > >>>> ... >>>>> If packets are sent to that address, they >>>>> get passed to NAT44. Hosts behind the CPE or apps on the CPE will not >>>>> use/bind to that address. > >>>> >>>> AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN si= de. >>>> Such a constraint isn't needed with "4V6 encapsulation". >>> >>> No. > > A justification of this "no" is missing, because: It's not missing. Please do read once more the rest of the mail, as well as those of others. > - The CE 4V6 address is synonymous with a valid IPv6 address in the range= defined by the CE IPv6 prefix. > - With 4V6T, a translated IPv4 packet entering a 4V6 site cannot be disti= nguished from an IPv6 packet destined to this valid IPv6 address. > > An example: > > Host > =A0H > +-+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router > | |< 2001:db8:a:: > | |--------------. =A0.-. > | | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0| |< 2001:db8:a::/64 =A0 4V6T CE > +-+ =A0 =A0 =A0 =A0 LAN =A0|--| |-----------------. =A0 +-+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0| | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = | =A0 | |< 2001:db8:a:/56 > =A0 --------------' =A0'-' =A0 =A0 =A0 =A0 =A0 LAN =A0 |---| |-----------= - > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 +-+ =A0<=3D IPv6 packet > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0----------------' =A0 =A0 = =A0 =A0 sent to host H > > - The IPv6 address of host H has a permitted value (at least per sec 3.2.= 1 of RFC 3041 on privacy addresses). No. The above indicates some confusion between a prefix and an address Aside from the fact that Host H above has an address that is clearly not derived via SLAAC (not to mention very bogus in the context of rfc3041), on the above link you either have TWO/THREE(?) devices with the same IP address (2001:db8:a::) all on different links, or the 4V6 routers without any address. In either case the set-up is not correct (or at least your model set-up is the problem). Thanks, Woj. From despres.remi@laposte.net Thu Jul 21 03:21:25 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2312121F89A7 for ; Thu, 21 Jul 2011 03:21:25 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGN1GTHXYEG0 for ; Thu, 21 Jul 2011 03:21:24 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 467E821F8906 for ; Thu, 21 Jul 2011 03:21:24 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 787727000090; Thu, 21 Jul 2011 12:21:23 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 07824700008D; Thu, 21 Jul 2011 12:21:20 +0200 (CEST) X-SFR-UUID: 20110721102121308.07824700008D@msfrf2409.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, 21 Jul 2011 12:21:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 10:21:25 -0000 Le 21 juil. 2011 =E0 11:30, Wojciech Dec a =E9crit : > On 21 July 2011 11:06, R=E9mi Despr=E9s = wrote: >>=20 >> Le 20 juil. 2011 =E0 18:25, Wojciech Dec a =E9crit : >>=20 >>>>> ... >>>>>> If packets are sent to that address, they >>>>>> get passed to NAT44. Hosts behind the CPE or apps on the CPE will = not >>>>>> use/bind to that address. >>=20 >>>>>=20 >>>>> AFAIK, this prohibits using the full CE-assigned IPv6 on the CE = LAN side. >>>>> Such a constraint isn't needed with "4V6 encapsulation". >>>>=20 >>>> No. >>=20 >> A justification of this "no" is missing, because: >=20 > It's not missing. Please do read once more the rest of the mail, as > well as those of others. >=20 >> - The CE 4V6 address is synonymous with a valid IPv6 address in the = range defined by the CE IPv6 prefix. >> - With 4V6T, a translated IPv4 packet entering a 4V6 site cannot be = distinguished from an IPv6 packet destined to this valid IPv6 address. >>=20 >> An example: >>=20 >> Host >> H >> +-+ router >> | |< 2001:db8:a:: >> | |--------------. .-. >> | | | | |< 2001:db8:a::/64 4V6T CE >> +-+ LAN |--| |-----------------. +-+ >> | | | | | |< 2001:db8:a:/56 >> --------------' '-' LAN |---| |------------ >> | +-+ <=3D IPv6 packet >> ----------------' sent to host H >>=20 >> - The IPv6 address of host H has a permitted value (at least per sec = 3.2.1 of RFC 3041 on privacy addresses). >=20 > No. > The above indicates some confusion between a prefix and an address > Aside from the fact that Host H above has an address that is clearly > not derived via SLAAC (not to mention very bogus in the context of > rfc3041), > on the above link you either have TWO/THREE(?) devices with > the same IP address (2001:db8:a::) Not two or three! Just one. Having a delegated prefix at an interface (e.g. < 2001:db8:a::/64) = doesn't mean that this prefix is the interface address, does it?=20 Confusing prefixes, like 2001:db8:a::/64), and addresses, like = 2001:db8:a::, seems to be what YOU did, not me ;-). As you know, we both agreed, in an of-list discussion, that the IID of = 4V6 addresses would better be a 1 than a 0.=20 This would avoid, as you pointed out, a conflict the IID of the = Subnet-Router anycast address of RFC 4291.=20 This being done, replace the host address by 2001:db8:a::1, and the = example holds better. If the IID of 4V6 addresses is not permitted on a link, the 4V6 CE's = could be difficult to reach from the Internet. If it is a permitted one, a host behind the CE may have this IID. Regards, RD > all on different links, or the 4V6 > routers without any address. In either case the set-up is not correct > (or at least your model set-up is the problem). >=20 > Thanks, > Woj. From wdec.ietf@gmail.com Thu Jul 21 03:37:01 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2EA21F8620 for ; Thu, 21 Jul 2011 03:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54WlXIj-Dgza for ; Thu, 21 Jul 2011 03:37:00 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9103421F8AF0 for ; Thu, 21 Jul 2011 03:37:00 -0700 (PDT) Received: by pvh18 with SMTP id 18so1409387pvh.31 for ; Thu, 21 Jul 2011 03:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KTUxjMwa0UnhPl3ANF35X1PkOprO8YcUDs48ACs1bOY=; b=kO2kQjr5mmIoA1QGMKNYNLV4yanZ4w9dn5WYOJO7+u524jSE/GT67jHBQh3na+7oLa YT5hZiGk1EnFnmLAH6tVOSeA766elNwx8OW1ABvC9/AyiLnxNyAf7NfriIHr1t4OBkl0 qwSXXhqEaYeoTIhC0VyoCLWaTlqxTJ8hi+DmM= MIME-Version: 1.0 Received: by 10.142.177.1 with SMTP id z1mr43519wfe.174.1311244620161; Thu, 21 Jul 2011 03:37:00 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Thu, 21 Jul 2011 03:37:00 -0700 (PDT) In-Reply-To: References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> Date: Thu, 21 Jul 2011 12:37:00 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 10:37:01 -0000 On 21 July 2011 12:21, R=E9mi Despr=E9s wrote: > > Le 21 juil. 2011 =E0 11:30, Wojciech Dec a =E9crit : > >> On 21 July 2011 11:06, R=E9mi Despr=E9s wrote= : >>> >>> Le 20 juil. 2011 =E0 18:25, Wojciech Dec a =E9crit : >>> >>>>>> ... >>>>>>> If packets are sent to that address, they >>>>>>> get passed to NAT44. Hosts behind the CPE or apps on the CPE will n= ot >>>>>>> use/bind to that address. >>> >>>>>> >>>>>> AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN = side. >>>>>> Such a constraint isn't needed with "4V6 encapsulation". >>>>> >>>>> No. >>> >>> A justification of this "no" is missing, because: >> >> It's not missing. Please do read once more the rest of the mail, as >> well as those of others. >> >>> - The CE 4V6 address is synonymous with a valid IPv6 address in the ran= ge defined by the CE IPv6 prefix. >>> - With 4V6T, a translated IPv4 packet entering a 4V6 site cannot be dis= tinguished from an IPv6 packet destined to this valid IPv6 address. >>> >>> An example: >>> >>> Host >>> =A0H >>> +-+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router >>> | |< 2001:db8:a:: >>> | |--------------. =A0.-. >>> | | =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0| |< 2001:db8:a::/64 =A0 4V6T CE >>> +-+ =A0 =A0 =A0 =A0 LAN =A0|--| |-----------------. =A0 +-+ >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0| | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 | =A0 | |< 2001:db8:a:/56 >>> =A0 --------------' =A0'-' =A0 =A0 =A0 =A0 =A0 LAN =A0 |---| |---------= --- >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0| =A0 +-+ =A0<=3D IPv6 packet >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0----------------' =A0 = =A0 =A0 =A0 sent to host H >>> >>> - The IPv6 address of host H has a permitted value (at least per sec 3.= 2.1 of RFC 3041 on privacy addresses). >> >> No. >> The above indicates some confusion between a prefix and an address >> Aside from the fact that Host H above has an address that is clearly >> not derived via SLAAC (not to mention very bogus in the context of >> rfc3041), > >> on the above link you either have TWO/THREE(?) devices with >> the same IP address (2001:db8:a::) > > Not two or three! Just one. > Having a delegated prefix at an interface (e.g. < 2001:db8:a::/64) doesn'= t mean that this prefix is the interface address, does it? > Confusing prefixes, like 2001:db8:a::/64), and addresses, like =A02001:db= 8:a::, seems to be what YOU did, not me ;-). Your diagram says otherwise, as it shows the routers either without an IP address, or with bogus subnetting (subnet 0 cannot be in two places/links). Good luck with making the set-up work in any case. > > As you know, we both agreed, in an of-list discussion, that the IID of 4V= 6 addresses would better be a 1 than a 0. > This would avoid, as you pointed out, a conflict the IID of the Subnet-Ro= uter anycast address of RFC 4291. > This being done, replace the host address by 2001:db8:a::1, and the examp= le holds better. > > If the IID of 4V6 addresses is not permitted on a link, the 4V6 CE's coul= d be difficult to reach from the Internet. > If it is a permitted one, a host behind the CE may have this IID. Indeed, and what you seem to be trying very hard to say is that building an IPv6 network where multiple IPv6 devices have *the same* IPv6 address is ok and reasonable, and will somehow work unambiguously with the encapsulated mode... Interesting... In general, this is known as an IPv6 addressing violation/conflict, and there are specific procedures to prevent that for good reason. Thanks, Woj. > > Regards, > RD > >> all on different links, or the 4V6 >> routers without any address. In either case the set-up is not correct >> (or at least your model set-up is the problem). >> >> Thanks, >> Woj. > > > From adurand@juniper.net Thu Jul 21 05:22:20 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D4321F8B3D for ; Thu, 21 Jul 2011 05:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRA6esYa9C+I for ; Thu, 21 Jul 2011 05:22:20 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id F296021F8B19 for ; Thu, 21 Jul 2011 05:22:19 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTigZ++NClQCiKi26OCkidHQ213tcMQUc@postini.com; Thu, 21 Jul 2011 05:22:20 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 21 Jul 2011 05:21:39 -0700 From: Alain Durand To: "softwires@ietf.orglist list" Date: Thu, 21 Jul 2011 05:21:37 -0700 Thread-Topic: Slides for Softwires quebec meeting Thread-Index: AcxHoL1T9vnnUo3lRCq7y5KzLsqkJA== Message-ID: <2FDDA297-6C55-4F3F-BD7C-53CD9050EB7F@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 Subject: [Softwires] Slides for Softwires quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 12:22:20 -0000 This is a reminder for presenters to send their slides to the chairs NO LAT= ER THAN SUNDAY 5PM EDT. - Alain & Yong.= From adurand@juniper.net Thu Jul 21 05:28:30 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09D521F8B48 for ; Thu, 21 Jul 2011 05:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.243 X-Spam-Level: X-Spam-Status: No, score=-106.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyELgaEhH4oQ for ; Thu, 21 Jul 2011 05:28:30 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id D889521F86AE for ; Thu, 21 Jul 2011 05:28:29 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTigbaKCHuCuXK4hl1xUN2WyFI8Gc6qoc@postini.com; Thu, 21 Jul 2011 05:28:29 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 21 Jul 2011 05:26:44 -0700 From: Alain Durand To: Wojciech Dec Date: Thu, 21 Jul 2011 05:26:42 -0700 Thread-Topic: [Softwires] IETF81 agenda (bashing) Thread-Index: AcxHoXNscQaOLyaYTLaKiMItXKyWdg== Message-ID: References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 12:28:30 -0000 On Jul 21, 2011, at 5:08 AM, Wojciech Dec wrote: > I would like to support Mark's observation and add one more: While > fine and chartered drafts like MIBs (20 minutes) and multicast (30 > minutes) surely have discussion merit, besides merit of non-chartered > drafts like B4-NAT-bypass, DHCP- .., etc, (30 minutes in all), given > that WG facetime comes at a premium it would be fair to prioritize > discussions around the issues that appear to be in most need of such > facetime. In view of this assigning 4 drafts of stateless46 into > collectively 20 minutes appears to be questionable, and more so given > past precedent in terms of the difficulty in getting a discussion > going in this WG. Wojciech, B4-NAT bypass is in the charter. It is specifically called out in work ar= ea #3: 3. Developments for Dual-Stack Lite (DS-Lite):=20 - multicast=20 - operational specification=20 - RADIUS attribute for AFTR=20 - proxy extensions; GI-DS-Lite; No NAT on AFTR=20 - Alain.= From despres.remi@laposte.net Thu Jul 21 08:00:20 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3576E21F8B4E for ; Thu, 21 Jul 2011 08:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lNFtfISpzjZ for ; Thu, 21 Jul 2011 08:00:19 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 016A021F8A7B for ; Thu, 21 Jul 2011 08:00:16 -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 32FC594012C; Thu, 21 Jul 2011 17:00:10 +0200 (CEST) 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, 21 Jul 2011 17:00:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <215E14F3-6FDB-410B-8B10-54BB4C5FA8B8@laposte.net> References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:00:20 -0000 Wojciech, Le 21 juil. 2011 =E0 12:37, Wojciech Dec a =E9crit : (with my typos corrected) >>>> ... >>>>=20 >>>> Host >>>> H >>> +-+ router >>> | |< 2001:db8:a:: >>> | |--------------. .-. >>> | | | | |< 2001:db8:a::/64 4V6T CE >>> +-+ LAN |--| |-----------------. +-+ >>> | | | | | |< 2001:db8:a:/56 >>> --------------' '-' LAN |---| |------------ >>> | +-+ <=3D IPv6 packet >>> ----------------' sent to host H >=20 > ... Your diagram (...) shows the routers either without an > IP address, or with bogus subnetting (subnet 0 cannot be in two > places/links). The picture doesn't show a router IP address because it was unnecessary = for the explanation, but this doesn't imply there is none (everybody = knows that each interface must have at least one address!). Similarly, the picture doesn't show the subnet ID of the rightmost LAN, = but this by no means imply that it should be 0 (everybody knows that all = links that have global link prefixes must have them with different = values). =20 If the new picture below is insufficiently clear, please ask, rather = than making interpretations that don't make sense, and then objecting to = them. >> ... As you know, we both agreed, in an off-list discussion, that the = IID of 4V6 addresses would better be a 1 than a 0 ... Here is now a more complete example (with 1 as IID of 4V6 addresses in = view of the above)=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Host router CE +-+ Interface address Interface address | |< 2001:db8:a::1 < 2001:db8:a:ffff::10 | |--------------. .-. Delegated prefix Interface address | | | | |< 2001:db8:a::/64 < 2001:db8:0:a:4:5:6:7=20= +-+ |--| |-----------------. +-+ Assigned IPv6 prefix | | | | | | < 2001:db8:a::/48=20 | '-' |---| |------------ LAN-2 | | +-+ =20 Link prefix | <=3D packet X (IPv6) =20= 2001:db8:a::/64 LAN-1 | <=3D packet Y = (IPv4-in-IPv6) Link prefix IPv6 = destinations=3D2001:db8:a::1 2001:db8:a:ffff::/64 =20 Both packets X (IPv6) and Y (IPv4-in-IPv6) reach the CE because of their = IPv6 destinations start with the CE assigned prefix 2001:db8:a::/48.=20 Now: - If the CE is 4V6T, how packet X reaches the host is unclear to me.=20 - If the CE is 4V6E,=20 . Packet X is submitted to ordinary IPv6 routing because its payload = IS NOT an IPv4 packet. =20 . Packet Y has its contents directly submitted to the CE NAT44 because = its payload IS an IPv4 packet. (The 4V6 address 2001:db8:a::1, never = treated as a destination on any IPv6 link, is in fact a "dummy = address".) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An explanation of how 4V6T can work, on a configuration as detailed as = this one, would be welcome. It would help to reach common understanding. Regards, RD =20 From wdec.ietf@gmail.com Thu Jul 21 08:26:02 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A71521F89BA for ; Thu, 21 Jul 2011 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZthqn3-Cqf1 for ; Thu, 21 Jul 2011 08:26:01 -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 A6C2221F8A7B for ; Thu, 21 Jul 2011 08:26:01 -0700 (PDT) Received: by yxp4 with SMTP id 4so812143yxp.31 for ; Thu, 21 Jul 2011 08:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MnKG3/aOdEIJaltubxCSf+lAZPDM692haVBUWlp0inM=; b=iMYEdCjWDW8HOA7IQF+jIJHYZtmCrLN6Fn9BfTRFR1vmOz4ciYMw2gW0KO51EQ3QRv D8SrRzQnjHDUMROjQpV6DJ/8n4TX6bimsjxiffyZRg9HQ5d2ybDRsvpr+pygJdlMgwcf jFwBaMXNO/7LicjKDHBErKnPKWPgWlubobL1E= MIME-Version: 1.0 Received: by 10.142.204.9 with SMTP id b9mr178707wfg.3.1311261960877; Thu, 21 Jul 2011 08:26:00 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Thu, 21 Jul 2011 08:26:00 -0700 (PDT) In-Reply-To: References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> Date: Thu, 21 Jul 2011 17:26:00 +0200 Message-ID: From: Wojciech Dec To: Alain Durand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org list" , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:26:02 -0000 So is stateless (apparently), yet the agenda seems to prefer to generously assign time to everything but this topic, which by many accounts is what the WG is very interested in discussing. It also seems that I'm not the the only one thinking that this does not look quite reasonable... -Wojciech On 21 July 2011 14:26, Alain Durand wrote: > > On Jul 21, 2011, at 5:08 AM, Wojciech Dec wrote: > >> I would like to support Mark's observation and add one more: While >> fine and chartered drafts like MIBs (20 minutes) and multicast (30 >> minutes) surely have discussion merit, besides merit of non-chartered >> drafts like B4-NAT-bypass, DHCP- .., etc, (30 minutes in all), given >> that WG facetime comes at a premium it would be fair to prioritize >> discussions around the issues that appear to be in most need of such >> facetime. =A0In view of this assigning 4 drafts of stateless46 into >> collectively 20 minutes appears to be questionable, and more so given >> past precedent in terms of the difficulty in getting a discussion >> going in this WG. > > > Wojciech, > > =A0B4-NAT bypass is in the charter. It is specifically called out =A0in w= ork area #3: > > 3. Developments for Dual-Stack Lite (DS-Lite): > - multicast > - operational specification > - RADIUS attribute for AFTR > - proxy extensions; GI-DS-Lite; No NAT on AFTR > > =A0 - Alain. From adurand@juniper.net Thu Jul 21 08:49:32 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A1E21F877B for ; Thu, 21 Jul 2011 08:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.303 X-Spam-Level: X-Spam-Status: No, score=-106.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3zDlT54qsqo for ; Thu, 21 Jul 2011 08:49:31 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 78BA121F86B3 for ; Thu, 21 Jul 2011 08:49:31 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTihKh5YkbW7VTAhS4R8F9GV6m8b72HCg@postini.com; Thu, 21 Jul 2011 08:49:31 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; Thu, 21 Jul 2011 08:48:12 -0700 From: Alain Durand To: Wojciech Dec Date: Thu, 21 Jul 2011 08:48:10 -0700 Thread-Topic: [Softwires] IETF81 agenda (bashing) Thread-Index: AcxHvZihg2E+6ST1Q4Cepf9cM771Jw== Message-ID: <9AD5BB73-5B9B-4E5B-AC73-C91454AF679D@juniper.net> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:49:32 -0000 On Jul 21, 2011, at 11:26 AM, Wojciech Dec wrote: > So is stateless (apparently), yet the agenda seems to prefer to > generously assign time to everything but this topic, which by many > accounts is what the WG is very interested in discussing. It also > seems that I'm not the the only one thinking that this does not look > quite reasonable... >=20 > -Wojciech items related to stateless are #5, #6. #7, #8, #9 and #19 for a total of 55= mm out of 150min This does not quite look like assigning time to everything but this topic. Alain.= From adurand@juniper.net Thu Jul 21 08:52:58 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2487A21F8760 for ; Thu, 21 Jul 2011 08:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.325 X-Spam-Level: X-Spam-Status: No, score=-106.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzxq+6DZtwKq for ; Thu, 21 Jul 2011 08:52:57 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 654B421F8757 for ; Thu, 21 Jul 2011 08:52:57 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTihLBUPhKnm9xVAC/Atq+ewaFkYQtm03@postini.com; Thu, 21 Jul 2011 08:52:57 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; Thu, 21 Jul 2011 08:49:35 -0700 From: Alain Durand To: GangChen Date: Thu, 21 Jul 2011 08:49:32 -0700 Thread-Topic: [Softwires] IETF81 agenda Thread-Index: AcxHvcnDbIZESpeOT9GVT5DOTr8SGg== Message-ID: <717E99C4-0669-4467-B5FF-BC6D9C2D826B@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org list" , Cui Yong Subject: Re: [Softwires] IETF81 agenda X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:52:58 -0000 I agree we should move topic #19 up in the agenda. - Alain. On Jul 20, 2011, at 10:12 PM, GangChen wrote: > Dear Chairs, >=20 > Allow me to explain the suggestion on the agenda. > Topic 8 presents 4via6 stateless tunneling solution. > Topic 9 presents the analysis on both 4via6 tunneling and translation sch= emes. > So, it is the most logical way to move topic19 in between. > Please consider this proposal. >=20 > Many thanks >=20 > Gang >=20 >=20 > 2011/7/19, GangChen : >> Dear Chairs, >>=20 >> The presentation "4via6 Stateless Translation"(i.e. topic 19) is >> highly related to topic 8 and 9. >> May I suggest to move topic 19 together with 8 and 9? >> That would be helpful for the discussion >>=20 >> Many thanks >>=20 >> Gang >>=20 >> 2011/7/18, Alain Durand : >>> The agenda has been posted. >>>=20 >>> - Alain & Yong. >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 From mark@townsley.net Thu Jul 21 09:00:37 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E6F21F8A67 for ; Thu, 21 Jul 2011 09:00:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytOOW8Ir09iz for ; Thu, 21 Jul 2011 09:00:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0D0521F88A5 for ; Thu, 21 Jul 2011 09:00:36 -0700 (PDT) Received: by wwe5 with SMTP id 5so944982wwe.13 for ; Thu, 21 Jul 2011 09:00:35 -0700 (PDT) Received: by 10.227.11.134 with SMTP id t6mr386610wbt.21.1311264035627; Thu, 21 Jul 2011 09:00:35 -0700 (PDT) Received: from [192.168.1.11] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fc2sm1163476wbb.35.2011.07.21.09.00.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jul 2011 09:00:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <15AB825C-775D-4B8A-AAD6-D296393380AD@juniper.net> Date: Thu, 21 Jul 2011 18:00:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7063D234-EBDF-43DE-B4A1-59C6292C7D0D@townsley.net> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> <1311088730.8201.YahooMailRC@web111407.mail.gq1.yahoo.com> <5363C9A9-958A-4C7A-A274-A7722F975ECB@townsley.net> <15AB825C-775D-4B8A-AAD6-D296393380AD@juniper.net> To: Alain Durand X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.orglist" , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:00:37 -0000 On Jul 19, 2011, at 6:59 PM, Alain Durand wrote: > Mark: >=20 > Behcet is right. We have Multicast in our charter. The fact that some = of those discussions are repeated elsewhere is, I agree, unfortunate. Let's just try and avoid having a repeat of the BoF.=20 > However, Softwire is the place to discuss multicast on tunnel base = transition strategy. >=20 > Stateless solution have also made it in the charter, and as you see, = there is a large portion of the agenda that is dedicated to this. In the charter, or the agenda for Quebec? - Mark >=20 > - Alain. >=20 > On Jul 19, 2011, at 12:16 PM, Mark Townsley wrote: >=20 >>=20 >> On Jul 19, 2011, at 5:18 PM, Behcet Sarikaya wrote: >>=20 >>>=20 >>>=20 >>>>=20 >>>> The schedule is obviously rather busy. Here's a suggestion: = Softwires has 30 =20 >>>> minutes of Multicast transition presentation, while we have an = entire BoF =20 >>>> devoted to the subject earlier in the week. Do we really need to = schedule time =20 >>>> for this twice? >>>>=20 >>>=20 >>> Go stateless 4V6 go :-) >>>=20 >>> Mark, Softwire has charter items for multicast solutions for = Softwire developed=20 >>> transition technologies like 6rd, DS-Lite, etc. >>=20 >> That's fine - as long as the presentation and call for discussion is = different than what we will see in the BoF. There is an abundance of = repeat presentation happening these days, and we should do our part to = avoid it. >>=20 >> - Mark >>=20 >>>=20 >>> Prioritizing according to the charter deadlines could be a good = idea, IMHO. >>>=20 >>> Behcet >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From despres.remi@laposte.net Thu Jul 21 09:44:53 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F3E21F888A for ; Thu, 21 Jul 2011 09:44:53 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Jvsx2qvgWH for ; Thu, 21 Jul 2011 09:44:52 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CBC21F87FA for ; Thu, 21 Jul 2011 09:44:52 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id A3C8E700008B; Thu, 21 Jul 2011 18:44:51 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 27B26700008E; Thu, 21 Jul 2011 18:44:45 +0200 (CEST) X-SFR-UUID: 20110721164447162.27B26700008E@msfrf2118.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: <9AD5BB73-5B9B-4E5B-AC73-C91454AF679D@juniper.net> Date: Thu, 21 Jul 2011 18:44:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47CFF73C-3EBE-4883-8A18-92715CF05B5D@laposte.net> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> <9AD5BB73-5B9B-4E5B-AC73-C91454AF679D@juniper.net> To: Softwire Chairs X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:44:53 -0000 Le 21 juil. 2011 =E0 17:48, Alain Durand a =E9crit : >=20 > On Jul 21, 2011, at 11:26 AM, Wojciech Dec wrote: >=20 >> So is stateless (apparently), yet the agenda seems to prefer to >> generously assign time to everything but this topic, which by many >> accounts is what the WG is very interested in discussing. It also >> seems that I'm not the the only one thinking that this does not look >> quite reasonable... >>=20 >> -Wojciech >=20 > items related to stateless are #5, #6. #7, #8, #9 and #19 for a total = of 55mm out of 150min Yes, but among these 55 mn, 40 mn are to discuss motivations while the = consensus, on the discussion list, is clear that = draft-operators-softwire-stateless-4v6-motivation expresses well why the = work on solutions should start. (Incidentally, if the chairs have much to say about motivations that = wasn't expressed on the list, having a document well before the meeting = would be appreciated.) Compared to these 40 min, 5 mn for each of the major ID's on solutions = is dramatically disproportionate. Thank you for what you can do. RD > This does not quite look like assigning time to everything but this = topic. >=20 > Alain. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wdec.ietf@gmail.com Thu Jul 21 10:27:25 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC86E21F8713 for ; Thu, 21 Jul 2011 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.337 X-Spam-Level: X-Spam-Status: No, score=-3.337 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU1CNX2RrzB6 for ; Thu, 21 Jul 2011 10:27:25 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A13421F870F for ; Thu, 21 Jul 2011 10:27:25 -0700 (PDT) Received: by pvh18 with SMTP id 18so1812474pvh.31 for ; Thu, 21 Jul 2011 10:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vPops/qaB3HtM5vro+Rbz9HUT9gitB7fayz39dxeduQ=; b=CXRVvVrxFwFxkTqzCfX3ft4QPmmVVaesNTqYWkB/JB7ZyMIY9xf2z4jydYcZ+8Qudb tPsVXqB82NZq3DLv28QkTWHD5CxPlaiKgnsa8rUUEi2eQ/55MD1CVjuXzBgnwHulmDlj IdumWKWoNOdKXqs21ilaV5lbCJBX9JYazQ5W0= MIME-Version: 1.0 Received: by 10.142.204.9 with SMTP id b9mr251239wfg.3.1311269245169; Thu, 21 Jul 2011 10:27:25 -0700 (PDT) Received: by 10.142.210.4 with HTTP; Thu, 21 Jul 2011 10:27:25 -0700 (PDT) In-Reply-To: <215E14F3-6FDB-410B-8B10-54BB4C5FA8B8@laposte.net> References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> <215E14F3-6FDB-410B-8B10-54BB4C5FA8B8@laposte.net> Date: Thu, 21 Jul 2011 19:27:25 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 17:27:26 -0000 On 21 July 2011 17:00, R=E9mi Despr=E9s wrote: > =A0. Packet X is submitted to ordinary IPv6 routing because its payload I= S NOT an IPv4 packet. > =A0. Packet Y has its contents directly submitted to the CE NAT44 because= its payload IS an IPv4 packet. (The 4V6 address 2001:db8:a::1, never treat= ed as a destination on any IPv6 link, is in fact a "dummy address".) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please describe what you mean by an IPv6 "dummy address", or where can one find it described? In your model you seem to have an address on the 4V6 CE. This address, whatever you want to call it is either a duplicate address (somehow host H has it too) or an anycast address (that again somehow host H ended up with). On top of that somehow the CE is able to ignore regular IPv6 local/forward processing rules by looking at the payload (whether is IPinIP or not). Apart from this being rather far fetched, how does that line up with native IPv6 forwarding that you claim to be at issue here? Oh, one other thing: Say that IPv6 Host H was actually running an IPinIP tunnel/application and wants to receive such traffic. How does the model you describe work then? Thanks, Woj. PS In terms of exotic set-ups, I'm sure we can find plenty of other ones. This does not change the fact that in the S46 set-up with the characteristics as outlined in my initial reply, without system elements having duplicate IPv6 addresses, the problem you mention does not appear in neither translation nor tunneling modes. From denghui02@gmail.com Thu Jul 21 18:53:46 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C583521F8686 for ; Thu, 21 Jul 2011 18:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.373 X-Spam-Level: X-Spam-Status: No, score=-103.373 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGthMHCT--iH for ; Thu, 21 Jul 2011 18:53:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8427621F85F7 for ; Thu, 21 Jul 2011 18:53:45 -0700 (PDT) Received: by wyj26 with SMTP id 26so1380192wyj.31 for ; Thu, 21 Jul 2011 18:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uu3+CUdIywQ0lwpqLHj0gZ3J8xSu/3Lj38IUX61RwSA=; b=EE+9beI1BUlAGyX8A3nBV8xUOzKC5CU3MJJLAhm+/4ASqxzgzdn4057FHohWziyYvI 2Yy+zyM6yBLKZijd1q3WCcgQBvqdpgaJNIwXMxI9pmj+LRnIQrMHQj19JS3jnK8RzwkT vYnN1JcJ9STGqlepoCuMIBgko73RvazWmFgyY= MIME-Version: 1.0 Received: by 10.216.175.206 with SMTP id z56mr781213wel.66.1311299619535; Thu, 21 Jul 2011 18:53:39 -0700 (PDT) Received: by 10.216.23.129 with HTTP; Thu, 21 Jul 2011 18:53:39 -0700 (PDT) In-Reply-To: <47CFF73C-3EBE-4883-8A18-92715CF05B5D@laposte.net> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> <9AD5BB73-5B9B-4E5B-AC73-C91454AF679D@juniper.net> <47CFF73C-3EBE-4883-8A18-92715CF05B5D@laposte.net> Date: Fri, 22 Jul 2011 09:53:39 +0800 Message-ID: From: Hui Deng To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0016e65b6048043c7704a89ebc38 Cc: "softwires@ietf.org list" , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 01:53:46 -0000 --0016e65b6048043c7704a89ebc38 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would agree that people in the floor are interested in technologies and comparision et al. would better to allocate more time on Quite more importantly, those stuffs have been discussed in the ML more tha= n others which just post the submission information Thanks -Hui 2011/7/22 R=E9mi Despr=E9s > > Le 21 juil. 2011 =E0 17:48, Alain Durand a =E9crit : > > > > > On Jul 21, 2011, at 11:26 AM, Wojciech Dec wrote: > > > >> So is stateless (apparently), yet the agenda seems to prefer to > >> generously assign time to everything but this topic, which by many > >> accounts is what the WG is very interested in discussing. It also > >> seems that I'm not the the only one thinking that this does not look > >> quite reasonable... > >> > >> -Wojciech > > > > items related to stateless are #5, #6. #7, #8, #9 and #19 for a total o= f > 55mm out of 150min > > Yes, but among these 55 mn, 40 mn are to discuss motivations while the > consensus, on the discussion list, is clear that > draft-operators-softwire-stateless-4v6-motivation expresses well why the > work on solutions should start. > (Incidentally, if the chairs have much to say about motivations that wasn= 't > expressed on the list, having a document well before the meeting would be > appreciated.) > > Compared to these 40 min, 5 mn for each of the major ID's on solutions is > dramatically disproportionate. > > Thank you for what you can do. > RD > > > > This does not quite look like assigning time to everything but this > topic. > > > > 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 > --0016e65b6048043c7704a89ebc38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would agree that people in the floor are interested in technologies = and comparision et al.
would better to allocate more time on
=A0
Quite more importantly, those=A0stuffs have been discussed in the ML m= ore than others which just post the submission information
=A0
Thanks
=A0
-Hui

2011/7/22 R=E9mi Despr=E9s <= ;despres.remi= @laposte.net>

Le 21 juil. 2011 =E0 17:48, = Alain Durand a =E9crit :

>
> On Jul 21, 2011, at 11:26 AM, Wojciech Dec wrote:
= >
>> So is stateless (apparently), yet the agenda seems to pref= er to
>> generously assign time to everything but this topic, whic= h by many
>> accounts is what the WG is very interested in discussing. It also<= br>>> seems that I'm not the the only one thinking that this does= not look
>> quite reasonable...
>>
>> -Wojciech=
>
> items related to stateless are #5, #6. #7, #8, #9 and #19 for = a total of 55mm out of 150min

Yes, but among these 55 mn, 40 m= n are to discuss motivations while the consensus, on the discussion list, i= s clear that draft-operators-softwire-stateless-4v6-motivation expresses we= ll why the work on solutions should start.
(Incidentally, if the chairs have much to say about motivations that wasn&#= 39;t expressed on the list, having a document well before the meeting would= be appreciated.)

Compared to these 40 min, 5 mn for each of the maj= or ID's on solutions is dramatically disproportionate.

Thank you for what you can do.
RD


> This does not quite look like assigning time to everythin= g but this topic.
>
> 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

--0016e65b6048043c7704a89ebc38-- From despres.remi@laposte.net Fri Jul 22 03:20:16 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3683621F85B5 for ; Fri, 22 Jul 2011 03:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjAGHw-4axjC for ; Fri, 22 Jul 2011 03:20:15 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB0521F84FE for ; Fri, 22 Jul 2011 03:20:14 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2103.sfr.fr (SMTP Server) with ESMTP id 99C7C700008F; Fri, 22 Jul 2011 12:20:13 +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 4A0517000089; Fri, 22 Jul 2011 12:20:05 +0200 (CEST) X-SFR-UUID: 20110722102005303.4A0517000089@msfrf2103.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, 22 Jul 2011 12:20:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <38EF68DC-93A0-4B54-9318-B8287E136939@laposte.net> References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> <215E14F3-6FDB-410B-8B10-54BB4C5FA8B8@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 10:20:16 -0000 Le 21 juil. 2011 =E0 19:27, Wojciech Dec a =E9crit : ... >> . Packet X is submitted to ordinary IPv6 routing because its payload = IS NOT an IPv4 packet. >> . Packet Y has its contents directly submitted to the CE NAT44 = because its payload IS an IPv4 packet. (The 4V6 address 2001:db8:a::1, = never treated as a destination on any IPv6 link, is in fact a "dummy = address".) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Please describe what you mean by an IPv6 "dummy address", or where can > one find it described? OK, ignore the "dummy address" bit. (The behavior is AFAIK clear, with no need for a new name.) Let's now be constructive, with solutions. > Oh, one other thing: Say that IPv6 Host H was actually running an > IPinIP tunnel/application and wants to receive such traffic. How does > the model you describe work then? OK, that's a good point: if hosts behind a 4V6 CE are permitted to have = any addresses that start with the CE assigned IPv6 prefix, a host whose = address is the same as the specified 4V6 address won't be able to do = IPv4 in IPv6 tunneling per RFC 2473. SOLUTION: This is easily avoided if the 4V6E encapsulation is done with a Protocol = number different from 41.=20 Since Protocol 41 is in IANA for point-to-point tunnels of RFC 2473, it = makes sense to have a new one for stateless multipoint tunnels. > ... in the S46 set-up with the > characteristics as outlined in my initial reply, without system > elements having duplicate IPv6 addresses, the problem you mention does > not appear in neither translation nor tunneling modes. OK, but the setup of your initial reply is only for CE's being assigned = a /64, which imposes a single LAN-side link. Shorter IPv6 prefixes = assigned to multiple-link sites lead to more complex analysis.=20 SOLUTION:=20 If the IID of 4V6 addresses is one that never needs to be assigned to = work in IPv6, which isn't difficult to ensure, no conflict is possible = between a hosts IPv6 address and a 4V6 address. A possible IID value is that of an embedded IPv4 address (as in ISATAP), = with a reserved IPv4 address that no network would use. If this address is 0.0.0.0, the 4V6 IID is 0:5efe:0:0.=20 (If a completely new address is preferred,it could for instance be = 192.0.0.0, to be registered by IANA to mean "unspecified IPv4 address", = the equivalent of :: in IPv6.=20 Both solutions are AFAIK extremely simple, and do solve the two issues. I hope they will be looked at constructively. =20 Regards, RD =20 From behcetsarikaya@yahoo.com Fri Jul 22 14:44:43 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CC221F8B6F for ; Fri, 22 Jul 2011 14:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QlR9T3eFQ18P for ; Fri, 22 Jul 2011 14:44:42 -0700 (PDT) Received: from nm8-vm0.bullet.mail.sp2.yahoo.com (nm8-vm0.bullet.mail.sp2.yahoo.com [98.139.91.194]) by ietfa.amsl.com (Postfix) with SMTP id BFE1821F8B34 for ; Fri, 22 Jul 2011 14:44:42 -0700 (PDT) Received: from [98.139.91.68] by nm8.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 21:44:39 -0000 Received: from [98.139.91.31] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 21:44:39 -0000 Received: from [127.0.0.1] by omp1031.mail.sp2.yahoo.com with NNFMP; 22 Jul 2011 21:44:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 934641.19910.bm@omp1031.mail.sp2.yahoo.com Received: (qmail 95441 invoked by uid 60001); 22 Jul 2011 21:44:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311371079; bh=iCuMUM8840QYcYz9mhJ6gK/Gapdqv2oyCRiWLBv9fLs=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rYW+2GfkY275ErJYX6yWmP2fGsYdwXAnIPFAlxaUyXr6t4mvG1oAn4sSeGZUibcqyl7yMD0THkcmNNolk1YcNJeVgCSQZ694nnUVLFtTt3ROUChYCU3oPyQosKi5bcclm+cMYXxdAnrgr03FgMY4ysgO1q/sHzpgJTjds+oQjF0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kIu79x2vbg+KplLwBZvWlZnxW3FgoVxJpC8mmXZ7MdigLZlBipHnzIVahTrg6NwXKsKPRwl6EaaczlD3MQ+wBLAd67XTNaDNZlLsve9N28dJcoxG9FoGBBNq3G/iFMy0MKYIZx1RFqXvRemmSTHbREXw9csnRPHNrPDhHMTT5jo=; X-YMail-OSG: WFOu3E8VM1nkuQRjtrQGyYwSq8g5wJmA8Kg2c3QzGHEsgNR vmyPdTl3pXUChXMlVZCUW_EYAFEAaEmzInNCqM24sUrj5QoAywGWV1WbQqoF C9JPJkH4f1oDaIbV15E8CU332Xo69g2bDVZiEOjd65DuX8s.4qSP8WftqAQq eUZgyOjx0aIrxWC.nG3msTMFFjH1k_Fh00x4fQ9ulAF.W33sLQcUOQE_HWGw TNzjmWeS2.k2kM5ESY.VLnbFa3sqbkQTjlHRCXq5IAyc34GF9f_r9VZyTNrO _E2i_mdnFkSTuhTxK7VLPxjG5iGgyaLSd7e6.LgqELb.1x5wHcYDoGv6ioEJ fSY91uq3u2rdM.ss5pw1txrpRWY.Y0Kn.6THGXJFP3uSXQb83q_LgvjET98n pB__AYy4ug3aViA-- Received: from [50.58.7.243] by web111413.mail.gq1.yahoo.com via HTTP; Fri, 22 Jul 2011 14:44:39 PDT X-Mailer: YahooMailRC/572 YahooMailWebService/0.8.112.310352 References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> <215E14F3-6FDB-410B-8B10-54BB4C5FA8B8@laposte.net> <38EF68DC-93A0-4B54-9318-B8287E136939@laposte.net> Message-ID: <1311371079.58732.YahooMailRC@web111413.mail.gq1.yahoo.com> Date: Fri, 22 Jul 2011 14:44:39 -0700 (PDT) From: Behcet Sarikaya To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Wojciech Dec In-Reply-To: <38EF68DC-93A0-4B54-9318-B8287E136939@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg Subject: Re: [Softwires] Limitation of "4V6 Translation" between sites of the same domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 21:44:43 -0000 I wanted to write to my 4rd friends that I think that CE is not the right t= erm =0Ato use and would suggest using Customer Edge (CE) router instead. Th= is is what =0ARFC 6204 uses and is consistent with BBF terminology. So use = CE router anywhere =0Ainstead of CE.=0A=0A--b=0A=0A> =0A> Le 21 juil. 2011 = =E0 19:27, Wojciech Dec a =E9crit :=0A> ...=0A> >> . Packet X is submitte= d to ordinary IPv6 routing because its payload IS =0A>NOT an IPv4 packet.= =0A> >> . Packet Y has its contents directly submitted to the CE NAT44 be= cause its =0A>payload IS an IPv4 packet. (The 4V6 address 2001:db8:a::1, n= ever treated as a =0A>destination on any IPv6 link, is in fact a "dummy ad= dress".)=0A> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A> > =0A> > = Please describe what you mean by an IPv6 "dummy address", or where can=0A>= > one find it described?=0A> =0A> OK, ignore the "dummy address" bit.=0A>= (The behavior is AFAIK clear, with no need for a new name.)=0A> =0A> Let'= s now be constructive, with solutions.=0A> =0A> > Oh, one other thing: Say= that IPv6 Host H was actually running an=0A> > IPinIP tunnel/application = and wants to receive such traffic. How does=0A> > the model you describe w= ork then?=0A> =0A> OK, that's a good point: if hosts behind a 4V6 CE are p= ermitted to have any =0A>addresses that start with the CE assigned IPv6 pr= efix, a host whose address is =0A>the same as the specified 4V6 address wo= n't be able to do IPv4 in IPv6 =0A>tunneling per RFC 2473.=0A> =0A> SOLUT= ION:=0A> This is easily avoided if the 4V6E encapsulation is done with a P= rotocol =0A>number different from 41. =0A>=0A> Since Protocol 41 is in IANA= for point-to-point tunnels of RFC 2473, it makes =0A>sense to have a new = one for stateless multipoint tunnels.=0A> =0A> =0A> > ... in the S46 set-u= p with the=0A> > characteristics as outlined in my initial reply, without = system=0A> > elements having duplicate IPv6 addresses, the problem you men= tion does=0A> > not appear in neither translation nor tunneling modes.=0A>= =0A> OK, but the setup of your initial reply is only for CE's being assig= ned a /64, =0A>which imposes a single LAN-side link. Shorter IPv6 prefixes= assigned to =0A>multiple-link sites lead to more complex analysis. =0A>= =0A> =0A> SOLUTION: =0A> If the IID of 4V6 addresses is one that never nee= ds to be assigned to work in =0A>IPv6, which isn't difficult to ensure, no= conflict is possible between a hosts =0A>IPv6 address and a 4V6 address.= =0A> =0A> A possible IID value is that of an embedded IPv4 address (as in = ISATAP), with =0A>a reserved IPv4 address that no network would use.=0A> If= this address is 0.0.0.0, the 4V6 IID is 0:5efe:0:0. =0A> (If a completely= new address is preferred,it could for instance be 192.0.0.0, =0A>to be re= gistered by IANA to mean "unspecified IPv4 address", the equivalent of =0A= >:: in IPv6. =0A>=0A> =0A> =0A> Both solutions are AFAIK extremely simple,= and do solve the two issues.=0A> I hope they will be looked at constructi= vely.=0A> =0A> =0A> Regards,=0A> RD=0A> =0A> =0A> =0A> ____________________= ___________________________=0A> Softwires mailing list=0A> Softwires@ietf.= org=0A> https://www.ietf.org/mailman/listinfo/softwires=0A> From denghui02@gmail.com Fri Jul 22 16:38:50 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D5321F8BF0 for ; Fri, 22 Jul 2011 16:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.535 X-Spam-Level: X-Spam-Status: No, score=-103.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QkcEh30orTZ for ; Fri, 22 Jul 2011 16:38:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B640321F8BEE for ; Fri, 22 Jul 2011 16:38:49 -0700 (PDT) Received: by wwe5 with SMTP id 5so1792539wwe.13 for ; Fri, 22 Jul 2011 16:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=DFrEhTwp6pH6QvihmhE10uU39L2NSBEge3ImNNsMj7s=; b=Q7/aHbugVJTHyymhyUpL3Zz+NY4G6+c24g0oweSzyWsF/lKJX3pVxIHh38eRTI6zV6 FPmdIaT/RIePZO9UpMKfQ8wF++FYqhnNOqETWu47Bb2e4+4OV00WotywRL9nxnqRqhdN jGfiCs+4zyU3hXgak+912I6JxyuChunZ7YkIM= MIME-Version: 1.0 Received: by 10.216.140.141 with SMTP id e13mr1622005wej.85.1311377898562; Fri, 22 Jul 2011 16:38:18 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Fri, 22 Jul 2011 16:38:18 -0700 (PDT) Date: Sat, 23 Jul 2011 07:38:18 +0800 Message-ID: From: Hui Deng To: ietf softwire Content-Type: multipart/alternative; boundary=0016e6dab349cf646904a8b0f516 Subject: [Softwires] Comments on draft-sakura-6rd-datacenter-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, 22 Jul 2011 23:38:50 -0000 --0016e6dab349cf646904a8b0f516 Content-Type: text/plain; charset=ISO-8859-1 Hello authors, Just wondering how you handle those issues which were mentioned in the draft-jjmb-v6ops-comcast-ipv6-experiences-01 for example, 1) have you supported Ipv4 any cast? 2) implemented DHCPv4 options? 3) the number of implementations? 4) Data center normally has high end routers and switches, would that possible to deploy 6rd CE without any influences of performance? you may deployed it on the server? Best regards, -Hui --0016e6dab349cf646904a8b0f516 Content-Type: text/html; charset=ISO-8859-1

Hello authors,

Just wondering how you handle those issues which were mentioned in the draft-jjmb-v6ops-comcast-ipv6-experiences-01
for example,
1) have you supported Ipv4 any cast?
2) implemented DHCPv4 options?
3) the number of implementations?
4) Data center normally has high end routers and switches, would that possible to deploy 6rd CE without any influences of performance? you may deployed it on the server?

Best regards,

-Hui

--0016e6dab349cf646904a8b0f516-- From shtsuchi@cisco.com Fri Jul 22 19:33:20 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6042421F8BD0 for ; Fri, 22 Jul 2011 19:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHscNyJaIGIe for ; Fri, 22 Jul 2011 19:33:20 -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 A7CEB21F8BC8 for ; Fri, 22 Jul 2011 19:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1239; q=dns/txt; s=iport; t=1311388392; x=1312597992; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=5i1uefp3CjWQvuiFN2vZI2onvdva9sgubL6A74K+DwY=; b=cYziXG5A13wva6CDS1+oPySnTPVrKd2dbwyNTjhoXPwsyhxKukSCwogv Kag5icdqnUfSwIz/RSPdw9eu0g/Ag53az14FVvT55b9C08UjrVQL9NtTN 56HZtx/FB4OZMiuxc+ycsVUPsNSwx/07JdP6lRFlqYXJnrv/0A+TQ5MnK A=; X-IronPort-AV: E=Sophos;i="4.67,250,1309737600"; d="scan'208";a="5678112" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jul 2011 02:33:12 +0000 Received: from [10.82.235.123] (rtp-vpn5-888.cisco.com [10.82.235.123]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6N2X8dc011155; Sat, 23 Jul 2011 02:33:09 GMT Message-ID: <4E2A32E1.5090803@cisco.com> Date: Fri, 22 Jul 2011 22:33:05 -0400 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: denghui02@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org Subject: Re: [Softwires] Comments on draft-sakura-6rd-datacenter-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, 23 Jul 2011 02:33:20 -0000 Hui Thanks for your comment. Hui Deng wrote: > Hello authors, > > Just wondering how you handle those issues which were mentioned in the draft-jjmb-v6ops-comcast-ipv6-experiences-01 > for example, > 1) have you supported Ipv4 any cast? I'm not sure what is issue in comcast case yet. But Sakura is not using IPv4 anycast for 6rd BR now. > 2) implemented DHCPv4 options? We mentioned about this. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01#section-4.2 The server-based 6rd does not needs automatic configuration because the server usually configure IPv4 address statically. > 3) the number of implementations? Many OS already supported 6rd feature. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01#section-3 > 4) Data center normally has high end routers and switches, would that possible to deploy 6rd CE without any influences of performance? you may deployed it on the server? In Sakura's case,switches has high performance for IPv4 switching,but IPv6 switching poor or not support. To provide IPv6 internet without any influence of existing service,Sakura is providing information of server-based 6rd to customers. Regards, -Shishio > > Best regards, > > -Hui > From satoru.matsushima@gmail.com Fri Jul 22 21:21:34 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF4A21F856F for ; Fri, 22 Jul 2011 21:21:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puJ8UDW9eVlK for ; Fri, 22 Jul 2011 21:21:34 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 0811821F855F for ; Fri, 22 Jul 2011 21:21:33 -0700 (PDT) Received: by pzk6 with SMTP id 6so4426232pzk.26 for ; Fri, 22 Jul 2011 21:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Vz9nDFo0mbzUq9gWGNEZE/hYEUwa19kCrJglvnmT9CA=; b=LpsMR2xe8A7dqylhbEPPPf8oYqcaSSKqe5BOcKKYJR0xy/OZbwv58eKVxcKvLJ8nDT jNLYNJsSn/e4Kl2m1HhszFDJYbJHVZwcVm8GCJINISOpT8vCfwlvWBAbpp7AygOscYpw 4ymDDDjv9YTVtPVTqvtX5//2dNSICjVMnR0gU= Received: by 10.68.22.232 with SMTP id h8mr3096478pbf.528.1311394893603; Fri, 22 Jul 2011 21:21:33 -0700 (PDT) Received: from [192.168.10.60] (softbank221038132005.bbtec.net [221.38.132.5]) by mx.google.com with ESMTPS id d1sm2351981pbj.88.2011.07.22.21.21.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 21:21:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_5D6E35AD-50B6-49FA-9358-2A2309AEBB60" From: Satoru Matsushima In-Reply-To: Date: Sat, 23 Jul 2011 13:21:28 +0900 Message-Id: <5B06E803-625E-4398-8969-630F9B95C3AE@gmail.com> References: <67EDE75D-AA52-48AE-B5F1-6B01A10D4201@townsley.net> <9AD5BB73-5B9B-4E5B-AC73-C91454AF679D@juniper.net> <47CFF73C-3EBE-4883-8A18-92715CF05B5D@laposte.net> To: Hui Deng X-Mailer: Apple Mail (2.1244.3) Cc: "softwires@ietf.org list" , =?utf-8?Q?R=C3=A9mi_Despr=C3=A9s?= , Softwire Chairs Subject: Re: [Softwires] IETF81 agenda (bashing) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 04:21:34 -0000 --Apple-Mail=_5D6E35AD-50B6-49FA-9358-2A2309AEBB60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree with Remi and Hui. The motivation draft has been understood = enough and has consented around people. But I'm very curious what 'Chairs Discussion' is in the agenda to have = 10 minutes. What the chairs want to discuss about the motivation? Isn't = it possible in the list? cheers, --satoru On 2011/07/22, at 10:53, Hui Deng wrote: > I would agree that people in the floor are interested in technologies = and comparision et al. > would better to allocate more time on > =20 > Quite more importantly, those stuffs have been discussed in the ML = more than others which just post the submission information > =20 > Thanks > =20 > -Hui >=20 > 2011/7/22 R=E9mi Despr=E9s >=20 > Le 21 juil. 2011 =E0 17:48, Alain Durand a =E9crit : >=20 > > > > On Jul 21, 2011, at 11:26 AM, Wojciech Dec wrote: > > > >> So is stateless (apparently), yet the agenda seems to prefer to > >> generously assign time to everything but this topic, which by many > >> accounts is what the WG is very interested in discussing. It also > >> seems that I'm not the the only one thinking that this does not = look > >> quite reasonable... > >> > >> -Wojciech > > > > items related to stateless are #5, #6. #7, #8, #9 and #19 for a = total of 55mm out of 150min >=20 > Yes, but among these 55 mn, 40 mn are to discuss motivations while the = consensus, on the discussion list, is clear that = draft-operators-softwire-stateless-4v6-motivation expresses well why the = work on solutions should start. > (Incidentally, if the chairs have much to say about motivations that = wasn't expressed on the list, having a document well before the meeting = would be appreciated.) >=20 > Compared to these 40 min, 5 mn for each of the major ID's on solutions = is dramatically disproportionate. >=20 > Thank you for what you can do. > RD >=20 >=20 > > This does not quite look like assigning time to everything but this = topic. > > > > Alain. > > _______________________________________________ > > 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 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_5D6E35AD-50B6-49FA-9358-2A2309AEBB60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = agree with Remi and Hui. The motivation draft has been understood enough = and has consented around people.

But I'm = very curious what 'Chairs Discussion' is in the agenda to have 10 = minutes. What the chairs want to discuss about the motivation? = Isn't it possible in the = list?

cheers,
--satoru


On 2011/07/22, at 10:53, Hui Deng wrote:

I = would agree that people in the floor are interested in technologies and = comparision et al.
would better to allocate more time on
 
Quite more importantly, those stuffs have been discussed in = the ML more than others which just post the submission information
 
Thanks
 
-Hui

2011/7/22 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 21 juil. 2011 =E0 = 17:48, Alain Durand a =E9crit :

>
> On Jul 21, 2011, at 11:26 AM, Wojciech Dec = wrote:
>
>> So is stateless (apparently), yet the agenda = seems to prefer to
>> generously assign time to everything but = this topic, which by many
>> accounts is what the WG is very interested in discussing. It = also
>> seems that I'm not the the only one thinking that this = does not look
>> quite reasonable...
>>
>> = -Wojciech
>
> items related to stateless are #5, #6. #7, #8, #9 and #19 = for a total of 55mm out of 150min

Yes, but among these 55 = mn, 40 mn are to discuss motivations while the consensus, on the = discussion list, is clear that = draft-operators-softwire-stateless-4v6-motivation expresses well why the = work on solutions should start.
(Incidentally, if the chairs have much to say about motivations that = wasn't expressed on the list, having a document well before the meeting = would be appreciated.)

Compared to these 40 min, 5 mn for each of = the major ID's on solutions is dramatically disproportionate.

Thank you for what you can do.
RD


> This does not quite look like assigning time to = everything but this topic.
>
> Alain.
> = _______________________________________________
> Softwires = mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
<= br>
_______________________________________________
Softwires = mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
<= /div>

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

<= /body>= --Apple-Mail=_5D6E35AD-50B6-49FA-9358-2A2309AEBB60-- From jari.arkko@piuha.net Sat Jul 23 07:36:19 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD2521F84EA for ; Sat, 23 Jul 2011 07:36:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrJYX4tS7n+Y for ; Sat, 23 Jul 2011 07:36:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 95DB221F84E9 for ; Sat, 23 Jul 2011 07:36:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D25462CEFF for ; Sat, 23 Jul 2011 17:36:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JetyI1TojfEb for ; Sat, 23 Jul 2011 17:36:17 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 88C502CC4B for ; Sat, 23 Jul 2011 17:36:16 +0300 (EEST) Message-ID: <4E2ADC5E.1000101@piuha.net> Date: Sat, 23 Jul 2011 10:36:14 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "softwires@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] review of draft-operators-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: Sat, 23 Jul 2011 14:36:20 -0000 I have reviewed this draft in preparation for discussions in the upcoming meeting. Thanks for writing this. In general, I agree with many of the points raised in the document. I do have a number of issues with the document as well, however. In some cases listed below, the document appears to be claiming a little bit too broad benefit where it should have argued for a specific difference between stateful and stateless solutions. Secondly, and more, seriously, I wish the document would contain a description of the actual trade-offs, including some of the issues that seem apparent in the stateless solution. To name some: - difficulty in supporting widely different numbers of ports that different users employ ("cookie-cutter") - operational impacts of having to make changes to port allocations for some users (does it change my addressing plan?) - port randomization Note: I'm not saying that these things are showstoppers for the the deployment of stateless solutions, but I think the document would come across are more balanced if it actually did consider both the negative and positive aspects. Finally, I think the document would benefit from describing differences between stateful solutions with dynamic mappings (traditional NAT44-like CGNs), network-based solutions with a static mappings, and approaches that are based on static/stateless mappings at the protocol level. Understanding the difference between these three I think is key to making a decision on moving ahead with stateless solutions work. Technical: > Service providers need to consider > optimizing the form of packet processing when encapsulation is used. > Since existing header compression techniques are stateful, it is > expected that stateless solution minimize overhead introduced by the > solution. > I'm not sure I understand this. First off, both stateless and stateful solutions appear to be sending relatively static data from CPEs to the central network equipment (same source addresses etc). Is you argument that the stateless approach is even more static in this sense, and that this would be beneficial from the point of commonly used header compression tools? Can you be more specific about the exact differences between the two approaches in this case? FWIW, my experience is that fixed wireless solutions -- such as those involving a home access point communicating over 3G/LTE towards an operator network -- do not today use header compression as much as they theoretically could. I think we'll see more header compression deployment in coming years, and that would also provide an opportunity to push the right compression technology. > 3.1.4. No Additional Protocol for Port Control is Required > > The deployment of stateless solution does not require the deployment > of new dynamic signaling protocols to the end-user CPE in addition to > those already used. In particular, existing protocols (e.g., UPnP > IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE. I think this point, while valid, needs some reformulation. As I can see: * A new protocol will be required between CPE and network equipment. The question is if this protocol needs both a data path and control path component or not. And its not clear to me how provisioning works, somehow the CPE needs to learn what port ranges to use. So _some_ amount of control protocols are needed. * Stateless/full aspect does not seem to matter with regards to whether you can use existing protocols to talk to the closest NAT, whether its at the CPE or in the network. Where you need new protocols and new code is if (a) there are multiple layers of NATs, and e.g., the home NAT needs to talk to the service provider NAT or (b) security and resource model of the NAT changes from "I have all ports" to "I can only give you some ports". > 3.2.1. Preserve Current Practices > > > Service Providers require as much as possible to preserve the same > operations as for current IP networking environments. > > If stateless solutions are deployed, common practices are preserved. > In particular, the maintenance and operation of the network do not > require any additional constraints such as: path optimization > practices, enforcing traffic engineering policies, issues related to > traffic oscillation between stateful devices, load-balancing the > traffic or load sharing the traffic among egress/ingress points can > be used, etc. In particular: > > o anycast-based schemes can be used for load-balancing and > redundancy purposes. > > o asymmetric routing to/from the IPv4 Internet is natively supported > and no path-pinning mechanisms have to be additionally > implemented. I think the issues at the bottom are valid requirements. However, the general point seems a bit overstated, IMO. The network is changing. Both with stateless and stateful solutions. I would suggest reformulating this point to be more about the specific issues than the general point. > 3.2.5. Simplification of Qualification Procedures IMHO, this point is perhaps a little bit overstated as well. The general argument is that stateless mechanisms are simpler and therefore easier to test. I think the reality is that any solution involving major fraction of traffic from the ISP and involving significant multi-vendor interoperability requirements (CPE - network node) is something that I would like to test very, very carefully. And remember that this is not just TCP port forwarding to static port ranges per subscriber. Its UDP, too. And ICMP. And some provisioning mechanism so that CPEs learn what ranges they can use. > 3.3.2. No Organizational Impact > > Stateless solutions rely on IP-related techniques to share and to > deliver IPv4 packets over an IPv6 network. In particular, IPv4 > packets are delivered without any modification to their destination > CPE. As such there is a clear separation between the IP/transport > layers and the service layers; no service interference is to be > observed when a stateless solution is deployed. This clear > separation: > > Facilitates service evolution: Since the payload of IPv4 packets is > not altered in the path, services can evolve without requiring any > specific function in the Service Provider's network; > > Limits vendor dependency: The upgrade of value-added services does > not involve any particular action from vendors that provide > devices embedding the stateless IPv4/IPv6 interconnection > function. > > No service-related skills are required for network operators who > manage devices that embed the IPv4/IPv6 interconnection function: IP > teams can be in charge of these devices; there is a priori no need > to create a dedicated team to manage and to operate devices > embedding the stateless IPv4/IPv6 interconnection function. The > introduction of stateless capabilities in the network are unlikely > to degrade management costs. I think the point about less involvement between transport and service functions is a valid one. That being said, I think the introduction of either stateless or stateful solutions does have an organizational impact. For instance, now the capabilities and configuration of your CPE equipment are very relevant with respect to what you can deploy in the network side. I would suggest focusing on the specific point and not arguing the general point. Editorial: > most sensitive problems ... most pressing? sensitive doesn't seem like the right word. > stateless solutions optimizes CPE-to-CPE > ... optimize ... Jari From despres.remi@laposte.net Sat Jul 23 08:14:04 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9890221F8A4E for ; Sat, 23 Jul 2011 08:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.737 X-Spam-Level: X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=-0.388, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRTJkwW5+bhu for ; Sat, 23 Jul 2011 08:14:04 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id CA21821F8A4D for ; Sat, 23 Jul 2011 08:14:03 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2307.sfr.fr (SMTP Server) with ESMTP id 2FC10700008C; Sat, 23 Jul 2011 17:14:02 +0200 (CEST) Received: from [192.168.1.62] (75.204.170.89.rev.sfr.net [89.170.204.75]) by msfrf2307.sfr.fr (SMTP Server) with ESMTP id DA68B700008A; Sat, 23 Jul 2011 17:13:59 +0200 (CEST) X-SFR-UUID: 20110723151401894.DA68B700008A@msfrf2307.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: <38EF68DC-93A0-4B54-9318-B8287E136939@laposte.net> Date: Sat, 23 Jul 2011 17:13:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99AFD6E9-3C6B-4F32-999D-271574D9FE11@laposte.net> References: <2BAF5083-1DB8-4EB4-884C-0EB37EF0B5C9@laposte.net> <4D625B0F-2E81-470D-BEE8-64CEEE0B2A84@laposte.net> <215E14F3-6FDB-410B-8B10-54BB4C5FA8B8@laposte.net> <38EF68DC-93A0-4B54-9318-B8287E136939@laposte.net> To: Softwires-wg X-Mailer: Apple Mail (2.1084) Subject: Re: [Softwires] 4V6 specific IID, and 4V6E-specific protocol X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:14:04 -0000 Hi, all, One remark, and one correction, about this recent email: Remark: If the second solution below is adopted (4V6-specific IID in 4rd-4V6 = IPv6 addresses), the first solution (4V6-specific protocol number) is no = longer necessary. However, it better separates functions, and makes no harm. The suggestion remains therefore to adopt both solutions (but I have no = objection if only the second is adopted). Correction: The proposed 4V6 IID (ISATAP based with null IPv4 address), because it = is globally unique, must have its "u" bit has to be 1 (ref sec. 6.1 of = RFC 5214). It is then 20:5efe:0:0. (This is in fact what ensures that this IID differs from all = non-globally-unique IID's that hosts are permitted to have.)=20 Regards, RD =20 Le 22 juil. 2011 =E0 12:20, R=E9mi Despr=E9s a =E9crit : >=20 > Le 21 juil. 2011 =E0 19:27, Wojciech Dec a =E9crit : > ... >>> . Packet X is submitted to ordinary IPv6 routing because its payload = IS NOT an IPv4 packet. >>> . Packet Y has its contents directly submitted to the CE NAT44 = because its payload IS an IPv4 packet. (The 4V6 address 2001:db8:a::1, = never treated as a destination on any IPv6 link, is in fact a "dummy = address".) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Please describe what you mean by an IPv6 "dummy address", or where = can >> one find it described? >=20 > OK, ignore the "dummy address" bit. > (The behavior is AFAIK clear, with no need for a new name.) >=20 > Let's now be constructive, with solutions. >=20 >> Oh, one other thing: Say that IPv6 Host H was actually running an >> IPinIP tunnel/application and wants to receive such traffic. How does >> the model you describe work then? >=20 > OK, that's a good point: if hosts behind a 4V6 CE are permitted to = have any addresses that start with the CE assigned IPv6 prefix, a host = whose address is the same as the specified 4V6 address won't be able to = do IPv4 in IPv6 tunneling per RFC 2473. >=20 > SOLUTION: > This is easily avoided if the 4V6E encapsulation is done with a = Protocol number different from 41.=20 > Since Protocol 41 is in IANA for point-to-point tunnels of RFC 2473, = it makes sense to have a new one for stateless multipoint tunnels. >=20 >=20 >> ... in the S46 set-up with the >> characteristics as outlined in my initial reply, without system >> elements having duplicate IPv6 addresses, the problem you mention = does >> not appear in neither translation nor tunneling modes. >=20 > OK, but the setup of your initial reply is only for CE's being = assigned a /64, which imposes a single LAN-side link. Shorter IPv6 = prefixes assigned to multiple-link sites lead to more complex analysis.=20= >=20 > SOLUTION:=20 > If the IID of 4V6 addresses is one that never needs to be assigned to = work in IPv6, which isn't difficult to ensure, no conflict is possible = between a hosts IPv6 address and a 4V6 address. >=20 > A possible IID value is that of an embedded IPv4 address (as in = ISATAP), with a reserved IPv4 address that no network would use. > If this address is 0.0.0.0, the 4V6 IID is 0:5efe:0:0.=20 > (If a completely new address is preferred,it could for instance be = 192.0.0.0, to be registered by IANA to mean "unspecified IPv4 address", = the equivalent of :: in IPv6.=20 >=20 >=20 > Both solutions are AFAIK extremely simple, and do solve the two = issues. > I hope they will be looked at constructively. >=20 >=20 > Regards, > RD >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Sat Jul 23 10:27:39 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A417921F8AFB for ; Sat, 23 Jul 2011 10:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVhfiEgCBGWn for ; Sat, 23 Jul 2011 10:27:38 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2630A21F8AF7 for ; Sat, 23 Jul 2011 10:27:37 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 5DFD27000097; Sat, 23 Jul 2011 19:27:36 +0200 (CEST) Received: from [192.168.1.62] (75.204.170.89.rev.sfr.net [89.170.204.75]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id C0B487000086; Sat, 23 Jul 2011 19:27:33 +0200 (CEST) X-SFR-UUID: 20110723172733789.C0B487000086@msfrf2208.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: <4E2ADC5E.1000101@piuha.net> Date: Sat, 23 Jul 2011 19:27:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6127FC36-A28F-411C-93DC-48EFAB1897FB@laposte.net> References: <4E2ADC5E.1000101@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] review of draft-operators-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: Sat, 23 Jul 2011 17:27:39 -0000 Hi, Jari, Good to have substantial comments on this milestone document. Le 23 juil. 2011 =E0 16:36, Jari Arkko a =E9crit : > I have reviewed this draft in preparation for discussions in the = upcoming meeting. >=20 > Thanks for writing this. In general, I agree with many of the points = raised in the document. I do have a number of issues with the document = as well, however. In some cases listed below, the document appears to be = claiming a little bit too broad benefit where it should have argued for = a specific difference between stateful and stateless solutions. = Secondly, and more, seriously, I wish the document would contain a = description of the actual trade-offs, > including some of the issues that seem apparent in the stateless = solution. What "seems apparent" would be easier to discuss if we would know which = stateless solutions we talk about . Making progress on these specifications is key, IMHO, to avoid = unverifiable comments on unspecified designs. > To name some: >=20 > - difficulty in supporting widely different numbers of ports that = different users employ ("cookie-cutter") If different customers need different service levels in IPv4, a simple = approach is to also give them different service levels in IPv6. With the 4rd mapping rules, an IPv6 prefix shorter by 1 bit can give = twice as many IPv4 ports. This can be done locally in provider-edge routers. It would be useful, IMHO, to make it clear in the specification of 4rd = mapping rules. > - operational impacts of having to make changes to port allocations = for some users (does it change my addressing plan?) As just explained, this can be done by a change of IPv6-prefix length.=20= > - port randomization I agree that sec. 5.3 could be somewhat expanded, but it does discuss = the issue. Points worth to add, IMHO, include: - With an provider DNS server that is IPv6 accessible, port = randomization isn't restricted. - The increasing risk of port-guessing attacks in IPv4, as IPv4 = addresses have more and more to be shared, is a good reason activate = dual-stack operation as generally and as quickly and as possible. > Note: I'm not saying that these things are showstoppers for the the = deployment of stateless solutions, but I think the document would come = across are more balanced if it actually did consider both the negative = and positive aspects. 1. The document does mention negative aspects. 2. The motivation document for stateless solutions isn't the right place = to list all motivations for stateful solutions.=20 A separate document could be written for that, in particular concerning = the need for PCP (not obvious IMHO).=20 > Finally, I think the document would benefit from describing = differences between stateful solutions with dynamic mappings = (traditional NAT44-like CGNs), network-based solutions with a static = mappings, and approaches that are based on static/stateless mappings at = the protocol level. Understanding the difference between these three I = think is key to making a decision on moving ahead with stateless = solutions work. A tutorial on stateful solutions would be nice to have, I agree, but = these solutions are described in other documents (DS-lite, PCP...) This should in no way delay real work on proposed stateless solutions. There are subjects that lack volunteers to contribute but this isn't the = case for stateless solutions. They have volunteers from very significant = actors of the Internet. Delaying their work would be counterproductive for the final decision to = be made. =20 =20 >=20 > Technical: >=20 >> Service providers need to consider >> optimizing the form of packet processing when encapsulation is used. >> Since existing header compression techniques are stateful, it is >> expected that stateless solution minimize overhead introduced by the >> solution. >> =20 >=20 > I'm not sure I understand this. First off, both stateless and stateful = solutions appear to be sending relatively static data from CPEs to the = central network equipment (same source addresses etc). Is you argument = that the stateless approach is even more static in this sense, and that = this would be beneficial from the point of commonly used header = compression tools? Can you be more specific about the exact differences = between the two approaches in this case? >=20 > FWIW, my experience is that fixed wireless solutions -- such as those = involving a home access point communicating over 3G/LTE towards an = operator network -- do not today use header compression as much as they = theoretically could. I share this understanding. A possible reason is that the benefit is insufficient today in fixed = wireless solutions. > I think we'll see more header compression deployment in coming years, = and that would also provide an opportunity to push the right compression = technology. Same view. Now, ignoring header compression for a while, there isn't much = difference of transmission efficiency between translation-based and = encapsulation based IPv4/IPv6 solutions. I plan to have a separate comment on this point of Wojciech's comparison = of 4V6T and 4V6E.=20 >> 3.1.4. No Additional Protocol for Port Control is Required >>=20 >> The deployment of stateless solution does not require the deployment >> of new dynamic signaling protocols to the end-user CPE in addition to >> those already used. In particular, existing protocols (e.g., UPnP >> IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE. >=20 > I think this point, while valid, needs some reformulation. As I can = see: >=20 > * A new protocol will be required between CPE and network equipment. = The question is if this protocol needs both a data path and control path = component or not. And its not clear to me how provisioning works, = somehow the CPE needs to learn what port ranges to use. So _some_ amount = of control protocols are needed. With the 4rd address mapping (common to 4V6T and 4V6E), the CPE needs = only parameters that can be statelessly delivered in DHCPv6 or other = parameter provisioning protocols. No new protocol is therefore needed. =20 > * Stateless/full aspect does not seem to matter with regards to = whether you can use existing protocols to talk to the closest NAT, = whether its at the CPE or in the network. Where you need new protocols = and new code is if (a) there are multiple layers of NATs, and e.g., the = home NAT needs to talk to the service provider NAT or (b) security and = resource model of the NAT changes from "I have all ports" to "I can only = give you some ports". Unless I miss something,=20 DS-lite specialists can answer why PCP (new protocol) is needed for port = reservation in CGN's, but the point remains that with statelessly shared = addresses no new protocol is needed. >> 3.2.1. Preserve Current Practices >>=20 >>=20 >> Service Providers require as much as possible to preserve the same >> operations as for current IP networking environments. >>=20 >> If stateless solutions are deployed, common practices are preserved. >> In particular, the maintenance and operation of the network do not >> require any additional constraints such as: path optimization >> practices, enforcing traffic engineering policies, issues related to >> traffic oscillation between stateful devices, load-balancing the >> traffic or load sharing the traffic among egress/ingress points can >> be used, etc. In particular: >>=20 >> o anycast-based schemes can be used for load-balancing and >> redundancy purposes. >>=20 >> o asymmetric routing to/from the IPv4 Internet is natively supported >> and no path-pinning mechanisms have to be additionally >> implemented. >=20 > I think the issues at the bottom are valid requirements. However, the = general point seems a bit overstated, IMO. The network is changing. Both = with stateless and stateful solutions. I would suggest reformulating = this point to be more about the specific issues than the general point. Experience with 6rd gives an idea of how much stateless solutions can be = non-intrusive in operation practices. More specific answers will better be given when stateless solutions are = better specified, IMHO. >=20 >> 3.2.5. Simplification of Qualification Procedures >=20 > IMHO, this point is perhaps a little bit overstated as well. The = general argument is that stateless mechanisms are simpler and therefore = easier to test. I think the reality is that any solution involving major = fraction of traffic from the ISP and involving significant multi-vendor = interoperability requirements (CPE - network node) is something that I = would like to test very, very carefully. And remember that this is not = just TCP port forwarding to static port ranges per subscriber. Its UDP, = too. And ICMP. That is orthogonality of functions that facilitates qualification. Having on ALG concern of any kind is a great simplification. ICMP needs a specific treatment, but the solution of = draft-murakami-softwire-4rd sec.9 is in my understanding simple to = implement and qualify. > And some provisioning mechanism so that CPEs learn what ranges they = can use. See above (same parameter provisioning protocol as for other = parameters). Best regards, RD >=20 >> 3.3.2. No Organizational Impact >>=20 >> Stateless solutions rely on IP-related techniques to share and to >> deliver IPv4 packets over an IPv6 network. In particular, IPv4 >> packets are delivered without any modification to their destination >> CPE. As such there is a clear separation between the IP/transport >> layers and the service layers; no service interference is to be >> observed when a stateless solution is deployed. This clear >> separation: >>=20 >> Facilitates service evolution: Since the payload of IPv4 packets is >> not altered in the path, services can evolve without requiring any >> specific function in the Service Provider's network; >>=20 >> Limits vendor dependency: The upgrade of value-added services does >> not involve any particular action from vendors that provide >> devices embedding the stateless IPv4/IPv6 interconnection >> function. >>=20 >> No service-related skills are required for network operators who >> manage devices that embed the IPv4/IPv6 interconnection function: IP >> teams can be in charge of these devices; there is a priori no need >> to create a dedicated team to manage and to operate devices >> embedding the stateless IPv4/IPv6 interconnection function. The >> introduction of stateless capabilities in the network are unlikely >> to degrade management costs. >=20 > I think the point about less involvement between transport and service = functions is a valid one. That being said, I think the introduction of = either stateless or stateful solutions does have an organizational = impact. For instance, now the capabilities and configuration of your CPE = equipment are very relevant with respect to what you can deploy in the = network side. >=20 > I would suggest focusing on the specific point and not arguing the = general point. >=20 > Editorial: >=20 >> most sensitive problems=20 >=20 > ... most pressing? sensitive doesn't seem like the right word. >=20 >> stateless solutions optimizes CPE-to-CPE >> =20 >=20 > ... optimize ... >=20 > Jari >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jari.arkko@piuha.net Sat Jul 23 10:53:27 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE2E21F8B0B for ; Sat, 23 Jul 2011 10:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTbgbHD+omiJ for ; Sat, 23 Jul 2011 10:53:26 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 824ED21F8B09 for ; Sat, 23 Jul 2011 10:53:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5C4E02CEFF; Sat, 23 Jul 2011 20:53:25 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nswnkgw+Ys9z; Sat, 23 Jul 2011 20:53:24 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6AA402CC4B; Sat, 23 Jul 2011 20:53:24 +0300 (EEST) Message-ID: <4E2B0A93.2080703@piuha.net> Date: Sat, 23 Jul 2011 13:53:23 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4E2ADC5E.1000101@piuha.net> <6127FC36-A28F-411C-93DC-48EFAB1897FB@laposte.net> In-Reply-To: <6127FC36-A28F-411C-93DC-48EFAB1897FB@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] review of draft-operators-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: Sat, 23 Jul 2011 17:53:27 -0000 Rémi, > What "seems apparent" would be easier to discuss if we would know which stateless solutions we talk about . > Making progress on these specifications is key, IMHO, to avoid unverifiable comments on unspecified designs. > That's a fair comment. I was thinking in terms of a hypothetical solution that I had in my mind, but you are right that there may be differences between different approach. In the last IETF I was worried about making ICMP to the outside work without adding state, and someone helped me understand that it can be made to work. There may be similar eye-opening experiences to come. Jari From jacniq@gmail.com Sat Jul 23 22:32:01 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC78521F8A70 for ; Sat, 23 Jul 2011 22:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXoquhIOaxUI for ; Sat, 23 Jul 2011 22:32:01 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C61C21F8A4D for ; Sat, 23 Jul 2011 22:32:01 -0700 (PDT) Received: by vws12 with SMTP id 12so2993317vws.31 for ; Sat, 23 Jul 2011 22:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2rcQF/DkEK5i/jSf+FGxVbZDym4BfmfxfYIbFJiUnAs=; b=pQlURut2SSmzprPmYMWaYA85tUGluL063VFbQrp79Ur403bQyV9vYPuY5gAwlUDc8S g3aYP/7A7HHAvSbAK9pDjnLlNa/VBi5Dosk6y9wTl5qaOaW03qwqDyZV0LCwcdY2iumU HR0Y47wyXK0o5rW/gyweBeRvJXjDS60m5l1JE= MIME-Version: 1.0 Received: by 10.52.98.36 with SMTP id ef4mr3045128vdb.70.1311485520507; Sat, 23 Jul 2011 22:32:00 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Sat, 23 Jul 2011 22:32:00 -0700 (PDT) In-Reply-To: <4D5B99EF-30C7-4485-91AC-C436C383C3C5@laposte.net> References: <7FB924B7-0067-45CB-A0F4-02F15504363E@laposte.net> <4D5B99EF-30C7-4485-91AC-C436C383C3C5@laposte.net> Date: Sun, 24 Jul 2011 13:32:00 +0800 Message-ID: From: Jacni Qin To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf307f343493f25904a8ca0413 Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on 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: Sun, 24 Jul 2011 05:32:01 -0000 --20cf307f343493f25904a8ca0413 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Remi, On Thu, Jul 21, 2011 at 3:13 PM, R=E9mi Despr=E9s wrote: > > Le 21 juil. 2011 =E0 06:09, Jacni Qin a =E9crit : > ... > > Plus, the reality is even more complicated, > For example, there are group/HQ and branches. The shorter prefixes are > probably held by the group level, and several/many 4rd domains (according= to > the sizes of cities under given branch) will be maintained by the branche= s > who can only get fragmented spaces, since a large amount of these spaces > come from leftover prefixes returned. > > > Again, not sure to get the question. > The simple approach is "one IPv6 prefix" =3D> "one 4rd prefix" (no fragme= nted > spaces). > Changing the length of one changes the length of the other. > Jacni>: Yes, one IPv6 prefix to one 4rd domain, then the Access Gateway has to serve multiple domains, with hundreds of users each (according to the length of IPv4 prefix available). In this case, it's better to embed the BR function in the Gateway, otherwise the topology will be weird. Cheers, Jacni > Cheers, > RD > > > > --20cf307f343493f25904a8ca0413 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Remi,

On Thu, Jul 21, 2011 at 3:13 PM, R=E9mi Despr=E9s <despres.remi@laposte.net<= /a>> wrote:

Le 21 juil. 2011 =E0 06:09, Jacni Qin a =E9crit :
...
Plus, the reality is even more complicated,
For = example, there are group/HQ and branches. The shorter prefixes are probably= held by the group level, and several/many 4rd domains (according to the si= zes of cities under given branch) will be maintained by the branches who ca= n only get fragmented spaces, since a large amount of these spaces come fro= m leftover prefixes returned.

Again, not sure t= o get the question.
The simple approach is "one IPv6 prefix&= quot; =3D> "one 4rd prefix" (no fragmented spaces).
Changing the length of one changes the length of the other.
--20cf307f343493f25904a8ca0413-- From denghui02@gmail.com Sun Jul 24 01:34:33 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDE221F89C2 for ; Sun, 24 Jul 2011 01:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.923 X-Spam-Level: X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8bcekhpPwEK for ; Sun, 24 Jul 2011 01:34:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3703221F8568 for ; Sun, 24 Jul 2011 01:34:33 -0700 (PDT) Received: by wwe5 with SMTP id 5so2210534wwe.13 for ; Sun, 24 Jul 2011 01:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8aYylgRE5bvdEE04Wd6xBr0uvmQkQ8eKfbtX3ytWScg=; b=IfkHzIOgWVDDt5P8uxthL8kj+LT8AJX0WvRGE5GfQVVGf2nerOMg50fyP2jM7AiSTu tu+8aVCunZd9DxMX741ACNLyIHJjL3t2Z5dBbiWE3/jLuN07NU91y7uYNwkmHCvsMFo/ Qh5ZqHoGIzgg0c6xF61qN6OAaaxpsHBh282Cw= MIME-Version: 1.0 Received: by 10.216.20.143 with SMTP id p15mr3224762wep.0.1311496472318; Sun, 24 Jul 2011 01:34:32 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Sun, 24 Jul 2011 01:34:32 -0700 (PDT) In-Reply-To: <4E2A32E1.5090803@cisco.com> References: <4E2A32E1.5090803@cisco.com> Date: Sun, 24 Jul 2011 04:34:32 -0400 Message-ID: From: Hui Deng To: Shishio Tsuchiya Content-Type: multipart/alternative; boundary=0016364d21615b571a04a8cc91a8 Cc: softwires@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org Subject: Re: [Softwires] Comments on draft-sakura-6rd-datacenter-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: Sun, 24 Jul 2011 08:34:34 -0000 --0016364d21615b571a04a8cc91a8 Content-Type: text/plain; charset=ISO-8859-1 Shishio Thanks for your explaination, just one more comment Server based solution will expereience bottleneck once the traffic grows up? Regards, -Hui 2011/7/22 Shishio Tsuchiya > Hui > Thanks for your comment. > > Hui Deng wrote: > > Hello authors, > > > > Just wondering how you handle those issues which were mentioned in the > draft-jjmb-v6ops-comcast-ipv6-experiences-01 > > for example, > > 1) have you supported Ipv4 any cast? > > I'm not sure what is issue in comcast case yet. > But Sakura is not using IPv4 anycast for 6rd BR now. > > > 2) implemented DHCPv4 options? > We mentioned about this. > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01#section-4.2 > The server-based 6rd does not needs automatic configuration because the > server usually configure IPv4 address statically. > > > 3) the number of implementations? > Many OS already supported 6rd feature. > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01#section-3 > > > > 4) Data center normally has high end routers and switches, would that > possible to deploy 6rd CE without any influences of performance? you may > deployed it on the server? > > In Sakura's case,switches has high performance for IPv4 switching,but IPv6 > switching poor or not support. > To provide IPv6 internet without any influence of existing service,Sakura > is providing information of server-based 6rd to customers. > > Regards, > -Shishio > > > > > > Best regards, > > > > -Hui > > > > > --0016364d21615b571a04a8cc91a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Shishio
=A0
Thanks for your explaination, just one more comment
=A0
Server based solution will expereience bottleneck once the traffic gro= ws up?
=A0
Regards,
=A0
-Hui
2011/7/22 Shishio Tsuchiya <= ;shtsuchi@cisco.com>
Hui
Thanks for your comment.<= br>

Hui Deng wrote:
> Hello authors,
>
>= ; Just wondering how you handle those issues which were mentioned in the dr= aft-jjmb-v6ops-comcast-ipv6-experiences-01
> for example,
> 1) = have you supported Ipv4 any cast?

I'm not sure what is issue in comcast case yet.
But Sakura= is not using IPv4 anycast for 6rd BR now.

> 2) implemented DHCPv= 4 options?
We mentioned about this.
http://t= ools.ietf.org/html/draft-sakura-6rd-datacenter-01#section-4.2
The server-based 6rd does not needs automatic configuration because the ser= ver usually configure IPv4 address statically.

> 3) the number of implementations?
Many = OS already supported 6rd feature.
http://tools.ie= tf.org/html/draft-sakura-6rd-datacenter-01#section-3


> 4) Data center normally has high end routers= and switches, would that possible to deploy 6rd CE without any influences = of performance? you may deployed it on the server?

In Sakura&#= 39;s case,switches has high performance for IPv4 switching,but IPv6 switchi= ng poor or not support.
To provide IPv6 internet without any influence of existing service,Sakura i= s providing information of server-based 6rd to customers.

Regards,-Shishio


>
> Best regards,
>
> -Hui
>



--0016364d21615b571a04a8cc91a8-- From yong@csnet1.cs.tsinghua.edu.cn Sun Jul 24 17:17:40 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4A121F85AA for ; Sun, 24 Jul 2011 17:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.616 X-Spam-Level: **** X-Spam-Status: No, score=4.616 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, FROM_EXCESS_BASE64=1.456, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikYVLmAzRmlI for ; Sun, 24 Jul 2011 17:17:39 -0700 (PDT) Received: from mail.catc.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id A14D121F856B for ; Sun, 24 Jul 2011 17:17:39 -0700 (PDT) Received: from localhost.localdomain (mail.catc.edu.cn [127.0.0.1]) by mail.catc.edu.cn (EMOS V1.5 (Postfix)) with ESMTP id D04A32A2003C; Fri, 22 Jul 2011 00:23:34 +0800 (CST) From: "=?ISO-8859-1?B?WW9uZyBDdWk=?=" To: softwires@ietf.org Date: Fri, 22 Jul 2011 00:23:34 +0800 Mime-version: 1.0 X-Originating-Ip: [69.70.1.98] X-Mailer: ExtMail 1.1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Message-Id: <20110721162334.D04A32A2003C@mail.catc.edu.cn> Subject: [Softwires] =?iso-8859-1?q?Slides_for_Softwires_quebec_meeting?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 00:17:40 -0000 SGkgZm9sa3MsDQoNCkFjY29yZGluZyB0byBvdXIgZHJhZnQgYWdlbmRhIGJlbG93Og0KaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84MS9hZ2VuZGEvc29mdHdpcmUuaHRtDQppdCBzZWVt cyB0aGF0IHdlIGhhdmUgTk9UIHJlY2VpdmVkIHRoZSBmb2xsb3dpbmcgc2xpZGVzOg0KTm8uIDIu IEZyYW5rIEJyb2NrbmVycw0KTm8uIDQuIFlpdSBMZWUNCk5vLiA4LiBUZXRzdXlhIE11cmFrYW1p DQpOby4gOS4gV29qY2llY2ggRGVjDQoNClBsZWFzZSBzZW5kIChvciByZXNlbmQpIHlvdXIgc2xp ZGVzIHRvIEFsYWluIGFuZCBtZSBieSBNb25kYXkgM3BtDQpRdWViZWMgdGltZSwgT3IgeW91ciB0 aW1lIHNsb3Qgd2lsbCBiZSBnaXZlbiB0byBvdGhlcnMuDQoNCg0KQWxhaW4gJiBZb25nDQo= From shtsuchi@cisco.com Sun Jul 24 20:25:00 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFC311E8079 for ; Sun, 24 Jul 2011 20:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4faOPY-hlYBh for ; Sun, 24 Jul 2011 20:25:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 27FC111E8072 for ; Sun, 24 Jul 2011 20:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2530; q=dns/txt; s=iport; t=1311564300; x=1312773900; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pCkEDOSg1rR/4gB/uJXcV+sL/lXODpjUx6RNYN+AmLE=; b=XOhj9jkP9qhh/1iRT50biiImT70z1jNgvkW1Ke46ShCVa7bdk0ArHtYB 0ju8ric6eFO08Io/tVPO/4mysEBCz87ElM4qq5LPZMbLHwDI1qD81U/+i Gi4AnERDHZpRPJWqNujdPTHU09FmWxNZNfKOVFgUC8oGFN7KM2hhcz6Vb s=; X-IronPort-AV: E=Sophos;i="4.67,258,1309737600"; d="scan'208";a="5975581" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jul 2011 03:25:00 +0000 Received: from [10.82.236.85] (rtp-vpn5-1105.cisco.com [10.82.236.85]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6P3Ox5I022859; Mon, 25 Jul 2011 03:24:59 GMT Message-ID: <4E2CE215.5090408@cisco.com> Date: Sun, 24 Jul 2011 23:25:09 -0400 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: denghui02@gmail.com References: <4E2A32E1.5090803@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org Subject: Re: [Softwires] Comments on draft-sakura-6rd-datacenter-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, 25 Jul 2011 03:25:01 -0000 Hui I appreciate your comment. Hui Deng wrote: > Shishio > Thanks for your explaination, just one more comment > Server based solution will expereience bottleneck once the traffic grows up? > Regards, In current datacenter services,user can select type of service by expected traffic. traffic is small-VPS->Dedicated Server->Housing Service--traffic is huge In housing service,router based 6rd CE would be fine. If user would select this architecture,user also can use some native IPv6 technics such as loadbalancing. I mensioned on section-2. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-00#section-2 -For Housing users, there are two options. Either the 6rd CE function is performed on the Gateway router itself, or the servers themselves can run 6rd directly. But I felt it need more detail description. The former is for huge performance request users. The later is for IPv6 small start users who not needs server load balancer. Regards, -Shishio > -Hui > 2011/7/22 Shishio Tsuchiya > > > Hui > Thanks for your comment. > > Hui Deng wrote: > > Hello authors, > > > > Just wondering how you handle those issues which were mentioned in the draft-jjmb-v6ops-comcast-ipv6-experiences-01 > > for example, > > 1) have you supported Ipv4 any cast? > > I'm not sure what is issue in comcast case yet. > But Sakura is not using IPv4 anycast for 6rd BR now. > > > 2) implemented DHCPv4 options? > We mentioned about this. > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01#section-4.2 > The server-based 6rd does not needs automatic configuration because the server usually configure IPv4 address statically. > > > 3) the number of implementations? > Many OS already supported 6rd feature. > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-01#section-3 > > > > 4) Data center normally has high end routers and switches, would that possible to deploy 6rd CE without any influences of performance? you may deployed it on the server? > > In Sakura's case,switches has high performance for IPv4 switching,but IPv6 switching poor or not support. > To provide IPv6 internet without any influence of existing service,Sakura is providing information of server-based 6rd to customers. > > Regards, > -Shishio > > > > > > Best regards, > > > > -Hui > > > > > From despres.remi@laposte.net Mon Jul 25 02:34:32 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6316821F8B37 for ; Mon, 25 Jul 2011 02:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZq1lvgsncq7 for ; Mon, 25 Jul 2011 02:34:31 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7766921F8B2C for ; Mon, 25 Jul 2011 02:34:30 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id AA249700009D; Mon, 25 Jul 2011 11:34:28 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 22BB1700008D; Mon, 25 Jul 2011 11:34:24 +0200 (CEST) X-SFR-UUID: 20110725093426142.22BB1700008D@msfrf2218.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: <20110721162334.D04A32A2003C@mail.catc.edu.cn> Date: Mon, 25 Jul 2011 11:34:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110721162334.D04A32A2003C@mail.catc.edu.cn> To: Yong Cui X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Slides for Softwires quebec meeting X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:34:32 -0000 Hi, Yong, Le 21 juil. 2011 =E0 18:23, Yong Cui a =E9crit : > Hi folks, >=20 > According to our draft agenda below: > http://www.ietf.org/proceedings/81/agenda/softwire.htm > it seems that we have NOT received the following slides: > No. 2. Frank Brockners > No. 4. Yiu Lee > No. 8. Tetsuya Murakami > No. 9. Wojciech Dec Could you please, then, post on = datatracker.ietf.org/meeting/81/materials.html slides you already have?=20= What about slides of presentation No. 6, scheduled for Chairs before = opening an open-mike discussion on Stateless 4V6 motivation. (Having an = idea of chairs comments about the I-D on the subject will help getting = prepared for the discussion.) =20 =20 > Please send (or resend) your slides to Alain and me by Monday 3pm > Quebec time, > Or your time slot will be given to others. =20 This seems to me completely unfair, with Monday 3pm for presentations on = Wednesday morning! Now: - Finalizing slides makes more sense with a good knowledge of allocated = time slots.=20 - The agenda-bashing discussion on the mailing list suggested that = chairs, in view of received comments, would allocate more to drafts = describing these stateless solutions.=20 (The motivation discussion makes more sense if it doesn't refer to some = supposed limitations of stateless that one or more of the proposed = solutions deny. In this context, a menace like this one is, AFAIK, a regrettable first. Thank you for what you can do to be more friendly to WG contributors. Regards, RD >=20 >=20 > Alain & Yong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Jul 25 02:59:31 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B97A21F85A1 for ; Mon, 25 Jul 2011 02:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhhgkWPzMIbh for ; Mon, 25 Jul 2011 02:59:30 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA3F21F85A0 for ; Mon, 25 Jul 2011 02:59:30 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id BCE3C70000A1; Mon, 25 Jul 2011 11:59:29 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2218.sfr.fr (SMTP Server) with ESMTP id 6AE30700009E; Mon, 25 Jul 2011 11:59:29 +0200 (CEST) X-SFR-UUID: 20110725095929437.6AE30700009E@msfrf2218.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 11:59:28 +0200 Message-Id: To: Wojciech Dec Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:59:31 -0000 Wojciech, =20 IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too = much in favor of translation (4v6T) vs encapsulation (4V6E).=20 The draft has: =20 +------------------------+--------------------+---------------------+ | Item | 4V6 Translation | 4V6 Mapped Tunnel | | | mode | Mode | +------------------------+-------- ... -------+---------------------+ | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% | | to average payload of | | | | a) ~550 bytes b) 1400 | | | | bytes). | | | | ------------------ | ------------------ | ------------------ | An IPv4 packet having a 550 B payload is 570 B long (ignoring possible = IPv4 options): - 4V6T adds 20 B (3.5 %). - 4V6E adds 40 B, (7.0 %). =20 An IPv4 packet having a 1400 B payload is 1420 B long (at least) - Translation adds 20/1420 =3D 1,4 % - Encapsulation adds 40/1420 =3D 2,8 % This gives: | ------------------ | ------------------ | ------------------ | | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% | | to average payload of | | | | a) ~550 bytes b) 1400 | | | | bytes). | | | | ------------------ | ------------------ | ------------------ | In addition, a complete comparison should take in consideration the = length of layer-2 headers, as well as that of the physical preambles if = any. This leads to even less different overhead ratios. Also, 4V6 devices can be expected to soon have an increasing part of = their traffic in IPv6. With this, the 4V6 overhead in % will soon = decrease accordingly.=20 =20 Conclusion: this line of the table deals with a difference that, = although it is real, is not significant compared to other considerations = (e2e transparency is one that deserves a separate discussion). Regards, RD= From mark@townsley.net Mon Jul 25 04:53:23 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A421F84C7 for ; Mon, 25 Jul 2011 04:53: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbsOh7KWA8Ow for ; Mon, 25 Jul 2011 04:53:22 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E07521F84E8 for ; Mon, 25 Jul 2011 03:26:14 -0700 (PDT) Received: by qwc23 with SMTP id 23so3063576qwc.31 for ; Mon, 25 Jul 2011 03:26:14 -0700 (PDT) Received: by 10.229.105.72 with SMTP id s8mr3256174qco.98.1311589573946; Mon, 25 Jul 2011 03:26:13 -0700 (PDT) Received: from [10.255.255.14] ([70.25.120.2]) by mx.google.com with ESMTPS id w12sm2729635qct.36.2011.07.25.03.26.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 03:26:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: Date: Mon, 25 Jul 2011 06:26:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 11:53:23 -0000 Header overhead percentage is fairly useless alone. A real-world = comparison would need take into account the speed of a given connection. - Mark On Jul 25, 2011, at 5:59 AM, R=E9mi Despr=E9s wrote: >=20 > Wojciech, >=20 > IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too = much in favor of translation (4v6T) vs encapsulation (4V6E).=20 >=20 > The draft has: =20 > = +------------------------+--------------------+---------------------+ > | Item | 4V6 Translation | 4V6 Mapped Tunnel = | > | | mode | Mode = | > +------------------------+-------- ... = -------+---------------------+ > | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | > | to average payload of | | = | > | a) ~550 bytes b) 1400 | | = | > | bytes). | | = | > | ------------------ | ------------------ | ------------------ = | >=20 > An IPv4 packet having a 550 B payload is 570 B long (ignoring possible = IPv4 options): > - 4V6T adds 20 B (3.5 %). > - 4V6E adds 40 B, (7.0 %). =20 > An IPv4 packet having a 1400 B payload is 1420 B long (at least) > - Translation adds 20/1420 =3D 1,4 % > - Encapsulation adds 40/1420 =3D 2,8 % >=20 > This gives: > | ------------------ | ------------------ | ------------------ = | > | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | > | to average payload of | | = | > | a) ~550 bytes b) 1400 | | = | > | bytes). | | = | > | ------------------ | ------------------ | ------------------ = | >=20 > In addition, a complete comparison should take in consideration the = length of layer-2 headers, as well as that of the physical preambles if = any. This leads to even less different overhead ratios. >=20 > Also, 4V6 devices can be expected to soon have an increasing part of = their traffic in IPv6. With this, the 4V6 overhead in % will soon = decrease accordingly.=20 >=20 > Conclusion: this line of the table deals with a difference that, = although it is real, is not significant compared to other considerations = (e2e transparency is one that deserves a separate discussion). >=20 > Regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Mon Jul 25 06:02:34 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC121F89C1; Mon, 25 Jul 2011 06:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8kdBfuaxB2H; Mon, 25 Jul 2011 06:02:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B021F87A4; Mon, 25 Jul 2011 06:02:33 -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: 3.56 Message-ID: <20110725130233.21462.41410.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2011 06:02:33 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-radius-ext-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: Mon, 25 Jul 2011 13:02:34 -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 : RADIUS Extensions for Dual-Stack Lite Author(s) : Roberta Maglione Alain Durand Filename : draft-ietf-softwire-dslite-radius-ext-03.txt Pages : 11 Date : 2011-07-25 Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers which are addressed only with an IPv6 prefix. DS-Lite requires to pre-configure the DS-Lite Address Family Transition Router tunnel information on the Basic Bridging BroadBand element. In many networks, the customer profile information may be stored in AAA servers while client configurations are mainly provided through DHC protocol. This document specifies a new RADIUS attribute to carry Dual-Stack Lite Address Family Transition Router Tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS Server and the NAS, it is not intended to be used directly between the B4 element and the RADIUS Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-radius-ext-0= 3.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-dslite-radius-ext-03= .txt From wdec.ietf@gmail.com Mon Jul 25 12:22:56 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755AE228011 for ; Mon, 25 Jul 2011 12:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2RkFIDk+LVO for ; Mon, 25 Jul 2011 12:22:55 -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 76AE522800F for ; Mon, 25 Jul 2011 12:22:55 -0700 (PDT) Received: by yxp4 with SMTP id 4so3028162yxp.31 for ; Mon, 25 Jul 2011 12:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uMTWufWsJvORHRYce7P+6BOq/K+9v8ZEwzTUUpM/XZI=; b=YTUcsq4q87NXP4yI6ae23JNeyLlcKfAvF6VDG8Kj0RKioYIOHWoExA4w7dPRmL0GZr l6Kqsg/HEuqIhMnqxRqwYZweZekbxWG+dScO7k6UQHQmfRsklsWoCQcDaKPwAt6Rq374 ZWuPMe0BDhOQBKbqNW+/EqPEDt4cvQMqdztYs= MIME-Version: 1.0 Received: by 10.142.173.8 with SMTP id v8mr3031072wfe.60.1311621774550; Mon, 25 Jul 2011 12:22:54 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Mon, 25 Jul 2011 12:22:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jul 2011 21:22:54 +0200 Message-ID: From: Wojciech Dec To: Mark Townsley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , =?ISO-8859-1?B?UultaSBEZXNwculz?= , Wojciech Dec Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 19:22:56 -0000 When the access medium's capacity is expensive (read radio spectrum), even single digit percentage points translate to significant expense. That is independent of the access speed. -Woj. On 25 July 2011 12:26, Mark Townsley wrote: > > Header overhead percentage is fairly useless alone. A real-world comparis= on would need take into account the speed of a given connection. > > - Mark > > > On Jul 25, 2011, at 5:59 AM, R=E9mi Despr=E9s wrote: > >> >> Wojciech, >> >> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too muc= h in favor of translation (4v6T) vs encapsulation (4V6E). >> >> The draft has: >> =A0 +------------------------+--------------------+---------------------= + >> =A0 | Item =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 4V6 Translation =A0 =A0= | 4V6 Mapped Tunnel =A0 | >> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| mode =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | Mode =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> =A0 +------------------------+-------- ... -------+---------------------= + >> =A0 | Overhead in relation =A0 | a) 0% b) 0% =A0 =A0 =A0 =A0| a) 4.36% b= ) 1.71% =A0 | >> =A0 | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 | ------------------ =A0 =A0 | ------------------ | ----------------= -- =A0| >> >> An IPv4 packet having a 550 B payload is 570 B long (ignoring possible I= Pv4 options): >> - 4V6T adds 20 B (3.5 %). >> - 4V6E adds 40 B, (7.0 %). >> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >> - Translation adds 20/1420 =3D 1,4 % >> - Encapsulation adds 40/1420 =3D 2,8 % >> >> This gives: >> =A0 | ------------------ =A0 =A0 | ------------------ | ----------------= -- =A0| >> =A0 | Overhead in relation =A0 | a) 3.5% b) 1.4% =A0 =A0| a) 7% b) 2.8% = =A0 =A0 =A0 | >> =A0 | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >> =A0 | ------------------ =A0 =A0 | ------------------ | ----------------= -- =A0| >> >> In addition, a complete comparison should take in consideration the leng= th of layer-2 headers, as well as that of the physical preambles if any. Th= is leads to even less different overhead ratios. >> >> Also, 4V6 devices can be expected to soon have an increasing part of the= ir traffic in IPv6. With this, the 4V6 overhead in % will soon decrease acc= ordingly. >> >> Conclusion: this line of the table deals with a difference that, althoug= h it is real, is not significant compared to other considerations (e2e tran= sparency is one that deserves a separate discussion). >> >> Regards, >> RD >> _______________________________________________ >> 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 Tue Jul 26 06:52:25 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0E21F8B16 for ; Tue, 26 Jul 2011 06:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POiKBpvfHmbS for ; Tue, 26 Jul 2011 06:52:25 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD0D21F893C for ; Tue, 26 Jul 2011 06:52:25 -0700 (PDT) Received: by gyd5 with SMTP id 5so320662gyd.31 for ; Tue, 26 Jul 2011 06:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/9gO0USFT627z1GgqnWRQvuT2AS3p4tPQwKPQAdNWsc=; b=Fizw9Y70xg+aQHDJB5ioaBiRTRgRLkv+CquXGmjFvKkxOGr45ebfzNj9t1wX1/uXlM orWIQxkzlFhFmQfTwRB3Sz0Xp9OcRGPdAoLrgUJwjLmza2baM0IBJw5Jd7Yd5b84Sh59 beuCABIRinCMgZyagzfFoOt8raHGrrpnC/90c= MIME-Version: 1.0 Received: by 10.142.173.8 with SMTP id v8mr3654617wfe.60.1311688344471; Tue, 26 Jul 2011 06:52:24 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Tue, 26 Jul 2011 06:52:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jul 2011 09:52:24 -0400 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:52:26 -0000 Remi, On 25 July 2011 11:59, R=E9mi Despr=E9s wrote: > > Wojciech, > > IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too much= in favor of translation (4v6T) vs encapsulation (4V6E). > > The draft has: > +------------------------+--------------------+---------------------+ > | Item | 4V6 Translation | 4V6 Mapped Tunnel | > | | mode | Mode | > +------------------------+-------- ... -------+---------------------+ > | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% | > | to average payload of | | | > | a) ~550 bytes b) 1400 | | | > | bytes). | | | > | ------------------ | ------------------ | ------------------ | > > An IPv4 packet having a 550 B payload is 570 B long (ignoring possible IP= v4 options): > - 4V6T adds 20 B (3.5 %). > - 4V6E adds 40 B, (7.0 %). > An IPv4 packet having a 1400 B payload is 1420 B long (at least) > - Translation adds 20/1420 =3D 1,4 % > - Encapsulation adds 40/1420 =3D 2,8 % > > This gives: > | ------------------ | ------------------ | ------------------ | > | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% | > | to average payload of | | | > | a) ~550 bytes b) 1400 | | | > | bytes). | | | > | ------------------ | ------------------ | ------------------ | Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 transport. It thus seemed fair to measure and compare the overhead as relative to IPv6 encapsulation, and not IPv4, since there is no way to send an IPv4-only packet, and the useful data is the Layer4+ payload. Doing it your way you show mixes the basic IPv6 overhead. In any case, subtract the left column from the right and one arrives at the figure at pretty much the figures in the original table. > > In addition, a complete comparison should take in consideration the lengt= h of layer-2 headers, as well as that of the physical preambles if any. Thi= s leads to even less different overhead ratios. With the relative consideration, this actually doesn't matter... And we can choose to ignore the detail of specific radio link protocols that can segment longer packets into many many more. -Woj. From despres.remi@laposte.net Tue Jul 26 07:46:59 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB1721F8CA7 for ; Tue, 26 Jul 2011 07:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaHmlNd4JV9a for ; Tue, 26 Jul 2011 07:46:59 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id A526A21F8CA9 for ; Tue, 26 Jul 2011 07:46:57 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id 30052700008D; Tue, 26 Jul 2011 16:46:57 +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 ABE0A7000097; Tue, 26 Jul 2011 16:46:54 +0200 (CEST) X-SFR-UUID: 20110726144654704.ABE0A7000097@msfrf2209.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: Tue, 26 Jul 2011 16:46:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:46:59 -0000 Well, I made my point (with one more comment below, at the end). =20 Up to WG contributors, and to operators, to appreciate what is really = important to them. Note also that, in 3GPP where power consumption is important, the IPv4v6 = bearer option completely avoids the IPv6 header overhead (no need for = 4V6). In wifi, I am still convinced that the impact on power consumption of = +6O vs +40 octets per IPv4 packet will remain negligible in real life, = especially as IPv6 will become the majority. The impact of translation on e2e transparency will be discussed in = another email. RD Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : > Remi, >=20 > On 25 July 2011 11:59, R=E9mi Despr=E9s = wrote: >>=20 >> Wojciech, >>=20 >> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too = much in favor of translation (4v6T) vs encapsulation (4V6E). >>=20 >> The draft has: >> = +------------------------+--------------------+---------------------+ >> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | >> | | mode | Mode = | >> +------------------------+-------- ... = -------+---------------------+ >> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | >> | to average payload of | | = | >> | a) ~550 bytes b) 1400 | | = | >> | bytes). | | = | >> | ------------------ | ------------------ | ------------------ = | >>=20 >> An IPv4 packet having a 550 B payload is 570 B long (ignoring = possible IPv4 options): >> - 4V6T adds 20 B (3.5 %). >> - 4V6E adds 40 B, (7.0 %). >> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >> - Translation adds 20/1420 =3D 1,4 % >> - Encapsulation adds 40/1420 =3D 2,8 % >>=20 >> This gives: >> | ------------------ | ------------------ | ------------------ = | >> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | >> | to average payload of | | = | >> | a) ~550 bytes b) 1400 | | = | >> | bytes). | | = | >> | ------------------ | ------------------ | ------------------ = | >=20 > Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 > transport. It thus seemed fair to measure and compare the overhead as > relative to IPv6 encapsulation, and not IPv4, since there is no way to > send an IPv4-only packet, and the useful data is the Layer4+ payload. > Doing it your way you show mixes the basic IPv6 overhead. In any case, > subtract the left column from the right and one arrives at the figure > at pretty much the figures in the original table. >=20 >>=20 >> In addition, a complete comparison should take in consideration the = length of layer-2 headers, as well as that of the physical preambles if = any. This leads to even less different overhead ratios. >=20 > With the relative consideration, this actually doesn't matter... And > we can choose to ignore the detail of specific radio link protocols > that can segment longer packets into many many more. Different view here. The _ratio_ of power-consumption increase, if n bytes are added to each = packet, does depend on the total length of packets (with their headers = of all layers, including link and physiscal).=20 >=20 > -Woj. From despres.remi@laposte.net Tue Jul 26 07:53:37 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E6411E80AD for ; Tue, 26 Jul 2011 07:53:37 -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=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+JE40qEQL5g for ; Tue, 26 Jul 2011 07:53:36 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 732F311E80A3 for ; Tue, 26 Jul 2011 07:53:36 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2209.sfr.fr (SMTP Server) with ESMTP id A440F700009D; Tue, 26 Jul 2011 16:53:35 +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 6A9BB7000085; Tue, 26 Jul 2011 16:53:35 +0200 (CEST) X-SFR-UUID: 20110726145335436.6A9BB7000085@msfrf2209.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, 26 Jul 2011 16:53:35 +0200 Message-Id: <9B93871C-C40A-4999-918C-3A7EE88F6AAD@laposte.net> To: Softwires-wg Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Wojciech Dec Subject: [Softwires] Transparency limitations of 4V6 Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:53:37 -0000 Hi, all, Wojciech's draft-dec-stateless-4v6-02 is overall very good IMHO, and = deserves to soon become a WG. However, concerning differences between = translation-based and encapsulation-based solutions (4V6T and 4V6E = respectively), it can and should be more complete.=20 Concerning the relationship of 4V6T and 4V6E with e2e transparency, I = noted the following points. 1. IPV4 OPTIONS The draft has:=20 (4V6T) (4V6E) | ------------------ | ------------------ | ------------------ | | Supports IPv4 Header | Yes - limited as | Yes, except source | | Options | per NAT64 | route option | | | [RFC6145] | | | ------------------ | ------------------ | ------------------ | Suggested clarification: (4V6T) (4V6E) | ------------------ | ------------------ | ------------------ | | Supports IPv4 Header | No - limited per | Yes | | Options | SIIT [RFC6145] | | | ------------------ | ------------------ | ------------------ | Justification: - RFC 6145 says in sec. 1.2: "the translating function specified in this = document does not translate any IPv4 options" - Traversal of a 4V6E domain is treated as a single IPv4 link traversal. = This, AFAIK, doesn't restrict IPv4 options that traverse the link. 2. UDP NULL CHECKSUM RFC 6145 sec. 1.2 says: "Fragmented IPv4 UDP packets that do not contain = a UDP checksum (i.e., the UDP checksum field is zero) are not of = significant use in the Internet, and in general will not be translated = by the IP/ICMP translator. However, when the translator is configured = to forward the packet without a UDP checksum, the fragmented IPv4 UDP = packets will be translated." Suggested presentation: (4V6T) (4V6E) | ------------------ | ------------------ | ------------------ | | Transparency to UDP | TBD - No with full | Yes | | null checksums | [RFC6145] | | | ------------------ | ------------------ | ------------------ | 3. DONT FRAGMENT BIT RFC 6145 says in sec. 4: "When the IPv4 sender does not set the DF bit, = the translator SHOULD always include an IPv6 Fragment Header to indicate = that the sender allows fragmentation. The translator MAY provide a = configuration function that allows the translator not to include the = Fragment Header for the non-fragmented IPv6 packets." Suggested presentation: (4V6T) (4V6E) | ------------------ | ------------------ | ------------------ | | Transparency to DF bit | TBD - No with full | Yes | | | [RFC6145] | | | ------------------ | ------------------ | ------------------ | 4. TOS RFC 6145 says in sec. 4.1: "An implementation of a translator SHOULD = provide the ability to ignore the IPv6 traffic class and always set the = IPv4 TOS Octet to a specified value." This opens the door to losses of TOS values across 4V6T domains. In 4V6E the original TOS is always preserved. Suggested presentation: (4V6T) (4V6E) | ------------------ | ------------------ | ------------------ | | Transparency to IPv4 | TBD - No with full | Yes | | TOS | [RFC6145] | | | ------------------ | ------------------ | ------------------ | All the above points happen to be favorable to 4V6E, but this is not = because of a religion about it. It is just because encapsulations inherently preserve e2e transparency, = which itself simplifies architectural properties and facilitates = qualification tests of deployed solutions. =20 Cheers, RD From wdec.ietf@gmail.com Tue Jul 26 07:56:48 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE58011E80D3 for ; Tue, 26 Jul 2011 07:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.329 X-Spam-Level: X-Spam-Status: No, score=-3.329 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr+kx4OvhOVp for ; Tue, 26 Jul 2011 07:56:48 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8083721F855C for ; Tue, 26 Jul 2011 07:56:46 -0700 (PDT) Received: by gwb20 with SMTP id 20so383230gwb.31 for ; Tue, 26 Jul 2011 07:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Cd3vLn2rg2kI6Re5FN29MQzLsRl6iDMP+Ffs36ctemw=; b=cRnfBZ7WukbiXubQnpoiqzqT7ZE3uderFQaDjbD60da80bANCZXAbeSdy2dVjl+5rk uRXNPdfkm/ZmCaHm4BE7inWljFHxjYbmeRVZ+lXiG3n+zkEj5zSOIdVj+wsbImA0cd1L 2/+UGlBf3ekbD/u+mhC/eKDulubaVyDrCB97w= MIME-Version: 1.0 Received: by 10.142.177.1 with SMTP id z1mr3688124wfe.174.1311692205527; Tue, 26 Jul 2011 07:56:45 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Tue, 26 Jul 2011 07:56:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jul 2011 16:56:45 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:56:49 -0000 On 26 July 2011 16:46, R=E9mi Despr=E9s wrote: > Well, I made my point (with one more comment below, at the end). > Up to WG contributors, and to operators, to appreciate what is really imp= ortant to them. > > Note also that, in 3GPP where power consumption is important, the IPv4v6 = bearer option completely avoids the IPv6 header overhead (no need for 4V6). That is totally orthogonal... > > In wifi, I am still convinced that the impact on power consumption of +6O= vs +40 octets per IPv4 packet will remain negligible in real life, especia= lly as IPv6 will become the majority. > > The impact of translation on e2e transparency will be discussed in anothe= r email. I trust that it will explain how to build an e2e transparent system with a stateful port restricted NAT44 in the path. If not, the IPv4 e2e transparency of encapped or translated transports is very much the same. -Woj. > > RD > > Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : > >> Remi, >> >> On 25 July 2011 11:59, R=E9mi Despr=E9s wrote= : >>> >>> Wojciech, >>> >>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too mu= ch in favor of translation (4v6T) vs encapsulation (4V6E). >>> >>> The draft has: >>> =A0+------------------------+--------------------+---------------------= + >>> =A0| Item =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 4V6 Translation =A0 =A0= | 4V6 Mapped Tunnel =A0 | >>> =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| mode =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | Mode =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>> =A0+------------------------+-------- ... -------+---------------------= + >>> =A0| Overhead in relation =A0 | a) 0% b) 0% =A0 =A0 =A0 =A0| a) 4.36% b= ) 1.71% =A0 | >>> =A0| to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >>> =A0| a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >>> =A0| bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >>> =A0| ------------------ =A0 =A0 | ------------------ | ----------------= -- =A0| >>> >>> An IPv4 packet having a 550 B payload is 570 B long (ignoring possible = IPv4 options): >>> - 4V6T adds 20 B (3.5 %). >>> - 4V6E adds 40 B, (7.0 %). >>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >>> - Translation adds 20/1420 =3D 1,4 % >>> - Encapsulation adds 40/1420 =3D 2,8 % >>> >>> This gives: >>> =A0| ------------------ =A0 =A0 | ------------------ | ----------------= -- =A0| >>> =A0| Overhead in relation =A0 | a) 3.5% b) 1.4% =A0 =A0| a) 7% b) 2.8% = =A0 =A0 =A0 | >>> =A0| to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >>> =A0| a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >>> =A0| bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | >>> =A0| ------------------ =A0 =A0 | ------------------ | ----------------= -- =A0| >> >> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >> transport. It thus seemed fair to measure and compare the overhead as >> relative to IPv6 encapsulation, and not IPv4, since there is no way to >> send an IPv4-only packet, and the useful data is the Layer4+ payload. >> Doing it your way you show mixes the basic IPv6 overhead. In any case, >> subtract the left column from the right and one arrives at the figure >> at pretty much the figures in the original table. >> >>> >>> In addition, a complete comparison should take in consideration the len= gth of layer-2 headers, as well as that of the physical preambles if any. T= his leads to even less different overhead ratios. >> >> With the relative consideration, this actually doesn't matter... And >> we can choose to ignore the detail of specific radio link protocols >> that can segment longer packets into many many more. > > Different view here. > The _ratio_ of power-consumption increase, if n bytes are added to each p= acket, does depend on the total length of packets (with their headers of al= l layers, including link and physiscal). > > >> >> -Woj. > > > From satoru.matsushima@gmail.com Tue Jul 26 08:19:15 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDD91F0C38 for ; Tue, 26 Jul 2011 08:19:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGmv5AERsTRt for ; Tue, 26 Jul 2011 08:19:14 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAEE1F0C37 for ; Tue, 26 Jul 2011 08:19:14 -0700 (PDT) Received: by pzk6 with SMTP id 6so939522pzk.26 for ; Tue, 26 Jul 2011 08:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4TpHlSMna4KbHo6TYBr8nxTvvV4jsEf9tcwg9lKImLc=; b=TTBr1J2xfAKyiPjZqk2eIa6LnbQ6JOcXdlWAohdME81EUzyZXt02IV3x1VOQZCBv+P T8TrBZ+G2mgp6+NYrP7frnjnWupSJ+oKyhxBAifiShyx8Bq3udykSAlScKepsqnTF+69 OXr2msymXZaMPnOGZX7BaoXIPptmIDjFuFNRY= Received: by 10.68.55.73 with SMTP id q9mr10428724pbp.353.1311693554091; Tue, 26 Jul 2011 08:19:14 -0700 (PDT) Received: from dhcp-53a8.meeting.ietf.org (dhcp-53a8.meeting.ietf.org [130.129.83.168]) by mx.google.com with ESMTPS id p7sm659878pbn.49.2011.07.26.08.19.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 08:19:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <4E2ADC5E.1000101@piuha.net> Date: Tue, 26 Jul 2011 11:19:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2ADC5E.1000101@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1244.3) Cc: "softwires@ietf.org" Subject: Re: [Softwires] review of draft-operators-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, 26 Jul 2011 15:19:15 -0000 Hi Jari,=20 Thank you for your comments. Please see inline: On 2011/07/23, at 10:36, Jari Arkko wrote: > I have reviewed this draft in preparation for discussions in the = upcoming meeting. >=20 > Thanks for writing this. In general, I agree with many of the points = raised in the document. I do have a number of issues with the document = as well, however. In some cases listed below, the document appears to be = claiming a little bit too broad benefit where it should have argued for = a specific difference between stateful and stateless solutions. = Secondly, and more, seriously, I wish the document would contain a = description of the actual trade-offs, including some of the issues that = seem apparent in the stateless solution. Thanks, actually we had some trade-off explanation in previous version. = But due to focus more on the motivation, current version doesn't mention = the trade-off. Since the purpose of this document is to describe = motivations, and kick-off to develop stateless solution, the authors = focus to motivation otherwise analysis work. I agree that trade-off = analysis is significant, but it would be better to be another document = outside of which the motivation draft bears. > To name some: >=20 > - difficulty in supporting widely different numbers of ports that = different users employ ("cookie-cutter") > - operational impacts of having to make changes to port allocations = for some users (does it change my addressing plan?) > - port randomization >=20 > Note: I'm not saying that these things are showstoppers for the the = deployment of stateless solutions, but I think the document would come = across are more balanced if it actually did consider both the negative = and positive aspects. My thoughts for these question: (1) stateless solution is not exclusive with other solution in theory. = CPE can use statefull solution for such purpose. (2) 4rd as for example, multiple mapping rule can be helpful to change = port allocation without address plan changing and renumbering. (3) Port randomization still preserve host side. Restrict ports should = be in CPE. Appropriate NAT session filtering is helpful to avoid the = issues of port scan threats. (i.e., address and address-and-port = dependent filtering) >=20 > Finally, I think the document would benefit from describing = differences between stateful solutions with dynamic mappings = (traditional NAT44-like CGNs), network-based solutions with a static = mappings, and approaches that are based on static/stateless mappings at = the protocol level. Understanding the difference between these three I = think is key to making a decision on moving ahead with stateless = solutions work. As Remi pointed out, we couldn't assume any stateless solution in the = motivation draft. So again, I think that it would be better to be = another document to do it if we needed. Then, let me try to make technical discussion: >=20 > Technical: >=20 >> Service providers need to consider >> optimizing the form of packet processing when encapsulation is used. >> Since existing header compression techniques are stateful, it is >> expected that stateless solution minimize overhead introduced by the >> solution. >> =20 >=20 > I'm not sure I understand this. First off, both stateless and stateful = solutions appear to be sending relatively static data from CPEs to the = central network equipment (same source addresses etc). Is you argument = that the stateless approach is even more static in this sense, and that = this would be beneficial from the point of commonly used header = compression tools? Can you be more specific about the exact differences = between the two approaches in this case? >=20 > FWIW, my experience is that fixed wireless solutions -- such as those = involving a home access point communicating over 3G/LTE towards an = operator network -- do not today use header compression as much as they = theoretically could. I think we'll see more header compression = deployment in coming years, and that would also provide an opportunity = to push the right compression technology. >=20 Yes, it is not header compression technology itself. It is operational = effort to be by choosing translation method in tunneling network = architecture, which I meant that within same address-family = communication. >> 3.1.4. No Additional Protocol for Port Control is Required >>=20 >> The deployment of stateless solution does not require the deployment >> of new dynamic signaling protocols to the end-user CPE in addition to >> those already used. In particular, existing protocols (e.g., UPnP >> IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE. >=20 > I think this point, while valid, needs some reformulation. As I can = see: >=20 > * A new protocol will be required between CPE and network equipment. = The question is if this protocol needs both a data path and control path = component or not. And its not clear to me how provisioning works, = somehow the CPE needs to learn what port ranges to use. So _some_ amount = of control protocols are needed. Thanks, we'll clarify it, and improve the text. >=20 > * Stateless/full aspect does not seem to matter with regards to = whether you can use existing protocols to talk to the closest NAT, = whether its at the CPE or in the network. Where you need new protocols = and new code is if (a) there are multiple layers of NATs, and e.g., the = home NAT needs to talk to the service provider NAT or (b) security and = resource model of the NAT changes from "I have all ports" to "I can only = give you some ports". Agreed. But point (b), current NAT implementation already can control to = port range/number to force its port pool. As long as we utilize it, I = don't think we need new code to do (b). >=20 >> 3.2.1. Preserve Current Practices >>=20 >>=20 >> Service Providers require as much as possible to preserve the same >> operations as for current IP networking environments. >>=20 >> If stateless solutions are deployed, common practices are preserved. >> In particular, the maintenance and operation of the network do not >> require any additional constraints such as: path optimization >> practices, enforcing traffic engineering policies, issues related to >> traffic oscillation between stateful devices, load-balancing the >> traffic or load sharing the traffic among egress/ingress points can >> be used, etc. In particular: >>=20 >> o anycast-based schemes can be used for load-balancing and >> redundancy purposes. >>=20 >> o asymmetric routing to/from the IPv4 Internet is natively supported >> and no path-pinning mechanisms have to be additionally >> implemented. >=20 > I think the issues at the bottom are valid requirements. However, the = general point seems a bit overstated, IMO. The network is changing. Both = with stateless and stateful solutions. I would suggest reformulating = this point to be more about the specific issues than the general point. I think we can clarify it. But I don't understand your point clearly. = Can you give some example about 'network changing'. >=20 >> 3.2.5. Simplification of Qualification Procedures >=20 > IMHO, this point is perhaps a little bit overstated as well. The = general argument is that stateless mechanisms are simpler and therefore = easier to test. I think the reality is that any solution involving major = fraction of traffic from the ISP and involving significant multi-vendor = interoperability requirements (CPE - network node) is something that I = would like to test very, very carefully. And remember that this is not = just TCP port forwarding to static port ranges per subscriber. Its UDP, = too. And ICMP. And some provisioning mechanism so that CPEs learn what = ranges they can use. Thanks, we'll revisit about it. In general, we usually try to keep = current procedure when we change something. =46rom my tiny experience of = deployment stateless solution into any area, qualification procedure of = these are lightweight than statefull. >=20 >> 3.3.2. No Organizational Impact >>=20 >> Stateless solutions rely on IP-related techniques to share and to >> deliver IPv4 packets over an IPv6 network. In particular, IPv4 >> packets are delivered without any modification to their destination >> CPE. As such there is a clear separation between the IP/transport >> layers and the service layers; no service interference is to be >> observed when a stateless solution is deployed. This clear >> separation: >>=20 >> Facilitates service evolution: Since the payload of IPv4 packets is >> not altered in the path, services can evolve without requiring any >> specific function in the Service Provider's network; >>=20 >> Limits vendor dependency: The upgrade of value-added services does >> not involve any particular action from vendors that provide >> devices embedding the stateless IPv4/IPv6 interconnection >> function. >>=20 >> No service-related skills are required for network operators who >> manage devices that embed the IPv4/IPv6 interconnection function: IP >> teams can be in charge of these devices; there is a priori no need >> to create a dedicated team to manage and to operate devices >> embedding the stateless IPv4/IPv6 interconnection function. The >> introduction of stateless capabilities in the network are unlikely >> to degrade management costs. >=20 > I think the point about less involvement between transport and service = functions is a valid one. That being said, I think the introduction of = either stateless or stateful solutions does have an organizational = impact. For instance, now the capabilities and configuration of your CPE = equipment are very relevant with respect to what you can deploy in the = network side. >=20 > I would suggest focusing on the specific point and not arguing the = general point. Thanks, we'll revisit it. >=20 > Editorial: >=20 >> most sensitive problems=20 >=20 > ... most pressing? sensitive doesn't seem like the right word. >=20 >> stateless solutions optimizes CPE-to-CPE >> =20 >=20 > ... optimize ... >=20 > Jari >=20 Thanks, cheers, --satoru= From cb.list6@gmail.com Tue Jul 26 08:50:54 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633E411E810B for ; Tue, 26 Jul 2011 08:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8aCkGs+dQaG for ; Tue, 26 Jul 2011 08:50:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D44C811E80D8 for ; Tue, 26 Jul 2011 08:50:52 -0700 (PDT) Received: by wyj26 with SMTP id 26so127924wyj.31 for ; Tue, 26 Jul 2011 08:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mt69Tkp42kYq0UarDdoH8EwGB/6+Fl/aDnODdjwCTfc=; b=MDYEC3w8YC6oSbhGVUfMhgF9Z9ST4cdFrNwTNpO0esF2rvYjQZljZBUWod1maVoYhF q3MwVbB/RlzQD4RBqiSwHUdaEdHwbMXlvXtEd2TRXAPQ+TVQyCtKColkKglZbf5ZS2aX Bws+QCFTPhPQt1Q8gPaqtgANXHs2mK0OwfLEQ= MIME-Version: 1.0 Received: by 10.216.62.3 with SMTP id x3mr1698995wec.77.1311695450574; Tue, 26 Jul 2011 08:50:50 -0700 (PDT) Received: by 10.216.161.136 with HTTP; Tue, 26 Jul 2011 08:50:50 -0700 (PDT) In-Reply-To: References: <4E2ADC5E.1000101@piuha.net> Date: Tue, 26 Jul 2011 08:50:50 -0700 Message-ID: From: Cameron Byrne To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] review of draft-operators-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, 26 Jul 2011 15:50:54 -0000 On Tue, Jul 26, 2011 at 8:19 AM, Satoru Matsushima wrote: > Hi Jari, > > Thank you for your comments. Please see inline: > > On 2011/07/23, at 10:36, Jari Arkko wrote: > >> I have reviewed this draft in preparation for discussions in the upcomin= g meeting. >> >> Thanks for writing this. In general, I agree with many of the points rai= sed in the document. I do have a number of issues with the document as well= , however. In some cases listed below, the document appears to be claiming = a little bit too broad benefit where it should have argued for a specific d= ifference between stateful and stateless solutions. Secondly, and more, ser= iously, I wish the document would contain a description of the actual trade= -offs, including some of the issues that seem apparent in the stateless sol= ution. > > Thanks, actually we had some trade-off explanation in previous version. B= ut due to focus more on the motivation, current version doesn't mention the= trade-off. Since the purpose of this document is to describe motivations, = and kick-off to develop stateless solution, the authors focus to motivation= otherwise analysis work. I agree that trade-off analysis is significant, b= ut it would be better to be another document outside of which the motivatio= n draft bears. > > >> To name some: >> >> - difficulty in supporting widely different numbers of ports that differ= ent users employ ("cookie-cutter") >> - operational impacts of having to make changes to port allocations for = some users (does it change my addressing plan?) >> - port randomization >> >> Note: I'm not saying that these things are showstoppers for the the depl= oyment of stateless solutions, but I think the document would come across a= re more balanced if it actually did consider both the negative and positive= aspects. > > My thoughts for these question: > > (1) stateless solution is not exclusive with other solution in theory. CP= E can use statefull solution for such purpose. > (2) 4rd as for example, multiple mapping rule can be helpful to change po= rt allocation without address plan changing and renumbering. > (3) Port randomization still preserve host side. Restrict ports should be= in CPE. Appropriate NAT session filtering is helpful to avoid the issues o= f port scan threats. (i.e., address and address-and-port dependent filterin= g) > > >> >> Finally, I think the document would benefit from describing differences = between stateful solutions with dynamic mappings (traditional NAT44-like CG= Ns), network-based solutions with a static mappings, and approaches that ar= e based on static/stateless mappings at the protocol level. Understanding t= he difference between these three I think is key to making a decision on mo= ving ahead with stateless solutions work. > > As Remi pointed out, we couldn't assume any stateless solution in the mot= ivation draft. So again, I think that it would be better to be another docu= ment to do it if we needed. > > Then, let me try to make technical discussion: > >> >> Technical: >> >>> Service providers need to consider >>> optimizing the form of packet processing when encapsulation is used. >>> Since existing header compression techniques are stateful, it is >>> expected that stateless solution minimize overhead introduced by the >>> solution. >>> >> >> I'm not sure I understand this. First off, both stateless and stateful s= olutions appear to be sending relatively static data from CPEs to the centr= al network equipment (same source addresses etc). Is you argument that the = stateless approach is even more static in this sense, and that this would b= e beneficial from the point of commonly used header compression tools? Can = you be more specific about the exact differences between the two approaches= in this case? >> >> FWIW, my experience is that fixed wireless solutions -- such as those in= volving a home access point communicating over 3G/LTE towards an operator n= etwork -- do not today use header compression as much as they theoretically= could. I think we'll see more header compression deployment in coming year= s, and that would also provide an opportunity to push the right compression= technology. >> > > Yes, it is not header compression technology itself. It is operational ef= fort to be by choosing translation method in tunneling network architecture= , which I meant that within same address-family communication. > > Since i have seen 3G/LTE on a few of these related threads, i will state that it is unlikely that mobile wireless providers and the 3GPP/GSMA will adopt yet another tunneling protocol or user equipment modification. cb > >>> 3.1.4. No Additional Protocol for Port Control is Required >>> >>> The deployment of stateless solution does not require the deployment >>> of new dynamic signaling protocols to the end-user CPE in addition to >>> those already used. =A0In particular, existing protocols (e.g., UPnP >>> IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the CPE. >> >> I think this point, while valid, needs some reformulation. As I can see: >> >> * A new protocol will be required between CPE and network equipment. The= question is if this protocol needs both a data path and control path compo= nent or not. And its not clear to me how provisioning works, somehow the CP= E needs to learn what port ranges to use. So _some_ amount of control proto= cols are needed. > > Thanks, we'll clarify it, and improve the text. > > >> >> * Stateless/full aspect does not seem to matter with regards to whether = you can use existing protocols to talk to the closest NAT, whether its at t= he CPE or in the network. Where you need new protocols and new code is if (= a) there are multiple layers of NATs, and e.g., the home NAT needs to talk = to the service provider NAT or (b) security and resource model of the NAT c= hanges from "I have all ports" to "I can only give you some ports". > > Agreed. But point (b), current NAT implementation already can control to = port range/number to force its port pool. As long as we utilize it, I don't= think we need new code to do (b). > > >> >>> 3.2.1. Preserve Current Practices >>> >>> >>> Service Providers require as much as possible to preserve the same >>> operations as for current IP networking environments. >>> >>> If stateless solutions are deployed, common practices are preserved. >>> In particular, the maintenance and operation of the network do not >>> require any additional constraints such as: path optimization >>> practices, enforcing traffic engineering policies, issues related to >>> traffic oscillation between stateful devices, load-balancing the >>> traffic or load sharing the traffic among egress/ingress points can >>> be used, etc. =A0In particular: >>> >>> o =A0anycast-based schemes can be used for load-balancing and >>> =A0 =A0 redundancy purposes. >>> >>> o =A0asymmetric routing to/from the IPv4 Internet is natively supported >>> =A0 =A0and no path-pinning mechanisms have to be additionally >>> =A0 =A0implemented. >> >> I think the issues at the bottom are valid requirements. However, the ge= neral point seems a bit overstated, IMO. The network is changing. Both with= stateless and stateful solutions. I would suggest reformulating this point= to be more about the specific issues than the general point. > > I think we can clarify it. But I don't understand your point clearly. Can= you give some example about 'network changing'. > > >> >>> 3.2.5. Simplification of Qualification Procedures >> >> IMHO, this point is perhaps a little bit overstated as well. The general= argument is that stateless mechanisms are simpler and therefore easier to = test. I think the reality is that any solution involving major fraction of = traffic from the ISP and involving significant multi-vendor interoperabilit= y requirements (CPE - network node) is something that I would like to test = very, very carefully. And remember that this is not just TCP port forwardin= g to static port ranges per subscriber. Its UDP, too. And ICMP. And some pr= ovisioning mechanism so that CPEs learn what ranges they can use. > > Thanks, we'll revisit about it. In general, we usually try to keep curren= t procedure when we change something. From my tiny experience of deployment= stateless solution into any area, qualification procedure of these are lig= htweight than statefull. > > >> >>> 3.3.2. No Organizational Impact >>> >>> Stateless solutions rely on IP-related techniques to share and to >>> deliver IPv4 packets over an IPv6 network. =A0In particular, IPv4 >>> packets are delivered without any modification to their destination >>> CPE. =A0As such there is a clear separation between the IP/transport >>> layers and the service layers; no service interference is to be >>> observed when a stateless solution is deployed. =A0This clear >>> separation: >>> >>> Facilitates service evolution: =A0Since the payload of IPv4 packets is >>> not altered in the path, services can evolve without requiring any >>> specific function in the Service Provider's network; >>> >>> Limits vendor dependency: =A0The upgrade of value-added services does >>> not involve any particular action from vendors that provide >>> devices embedding the stateless IPv4/IPv6 interconnection >>> function. >>> >>> No service-related skills are required for network operators who >>> manage devices that embed the IPv4/IPv6 interconnection function: =A0IP >>> teams can be in charge of these devices; there is a priori no need >>> to create a dedicated team to manage and to operate devices >>> embedding the stateless IPv4/IPv6 interconnection function. =A0The >>> introduction of stateless capabilities in the network are unlikely >>> to degrade management costs. >> >> I think the point about less involvement between transport and service f= unctions is a valid one. That being said, I think the introduction of eithe= r stateless or stateful solutions does have an organizational impact. For i= nstance, now the capabilities and configuration of your CPE equipment are v= ery relevant with respect to what you can deploy in the network side. >> >> I would suggest focusing on the specific point and not arguing the gener= al point. > > Thanks, we'll revisit it. > > >> >> Editorial: >> >>> most sensitive problems >> >> ... most pressing? sensitive doesn't seem like the right word. >> >>> stateless solutions optimizes CPE-to-CPE >>> >> >> ... optimize ... >> >> Jari >> > > Thanks, > > cheers, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From rajiva@cisco.com Tue Jul 26 13:30:38 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AA621F87C6 for ; Tue, 26 Jul 2011 13:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLNe+IjtTxwL for ; Tue, 26 Jul 2011 13:30:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CE39821F87C2 for ; Tue, 26 Jul 2011 13:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4488; q=dns/txt; s=iport; t=1311712238; x=1312921838; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=eCEgBmFhBNS8jBQ1bViMKztqmwf7XReAX/OcX+HKa3A=; b=Yf15GbnPhmeENJ9y0lwOb2bqa+Nk2VhxAl4cfcFpIRQqrAO9F6PBUtRL R0HTf9ZB7WF7UdLZlIc3Iky2Km4Cb2OB7V0R89hQHUgQfxAwqx6DuKg5H LTt99DkVltuO0jlU0IecSua53+YH+yMX/hKZ0bd0DOQGQNRT24qBaObEj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAAsjL06tJV2d/2dsb2JhbAA1AQEBAQIBAQEBEQEhRAQHBQcFAgEJEQQBAQEKBiMBBgETGCMOCAEBBQEWDBIJl06PXHeIfASjM55VhWFfBIcoL5Ari24 X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6635558" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 26 Jul 2011 20:30:37 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKUbEk008077; Tue, 26 Jul 2011 20:30:37 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 15:30:36 -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: Tue, 26 Jul 2011 15:30:35 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Header overheads - 4V6T vs 4V6E Thread-Index: AcxLouNG2QWF8d//QZ+usLvPxaWgewAHXPIg References: From: "Rajiv Asati (rajiva)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Wojciech Dec" X-OriginalArrivalTime: 26 Jul 2011 20:30:36.0702 (UTC) FILETIME=[E067DBE0:01CC4BD2] Cc: Softwires-wg , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 20:30:38 -0000 Remi, > Note also that, in 3GPP where power consumption is important, the = IPv4v6 > bearer option completely avoids the IPv6 header overhead (no need for = 4V6). Don't follow this. Could you please expand? Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf > Of R=E9mi Despr=E9s > Sent: Tuesday, July 26, 2011 10:47 AM > To: Wojciech Dec > Cc: Softwires-wg; Wojciech Dec (wdec) > Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >=20 > Well, I made my point (with one more comment below, at the end). > Up to WG contributors, and to operators, to appreciate what is really > important to them. >=20 > Note also that, in 3GPP where power consumption is important, the = IPv4v6 > bearer option completely avoids the IPv6 header overhead (no need for = 4V6). >=20 > In wifi, I am still convinced that the impact on power consumption of = +6O vs > +40 octets per IPv4 packet will remain negligible in real life, = especially as > IPv6 will become the majority. >=20 > The impact of translation on e2e transparency will be discussed in = another > email. >=20 > RD >=20 > Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : >=20 > > Remi, > > > > On 25 July 2011 11:59, R=E9mi Despr=E9s = wrote: > >> > >> Wojciech, > >> > >> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK = too much > in favor of translation (4v6T) vs encapsulation (4V6E). > >> > >> The draft has: > >> = +------------------------+--------------------+---------------------+ > >> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | > >> | | mode | Mode = | > >> +------------------------+-------- ... = -------+---------------------+ > >> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | > >> | to average payload of | | = | > >> | a) ~550 bytes b) 1400 | | = | > >> | bytes). | | = | > >> | ------------------ | ------------------ | ------------------ = | > >> > >> An IPv4 packet having a 550 B payload is 570 B long (ignoring = possible IPv4 > options): > >> - 4V6T adds 20 B (3.5 %). > >> - 4V6E adds 40 B, (7.0 %). > >> An IPv4 packet having a 1400 B payload is 1420 B long (at least) > >> - Translation adds 20/1420 =3D 1,4 % > >> - Encapsulation adds 40/1420 =3D 2,8 % > >> > >> This gives: > >> | ------------------ | ------------------ | ------------------ = | > >> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | > >> | to average payload of | | = | > >> | a) ~550 bytes b) 1400 | | = | > >> | bytes). | | = | > >> | ------------------ | ------------------ | ------------------ = | > > > > Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 > > transport. It thus seemed fair to measure and compare the overhead = as > > relative to IPv6 encapsulation, and not IPv4, since there is no way = to > > send an IPv4-only packet, and the useful data is the Layer4+ = payload. > > Doing it your way you show mixes the basic IPv6 overhead. In any = case, > > subtract the left column from the right and one arrives at the = figure > > at pretty much the figures in the original table. > > > >> > >> In addition, a complete comparison should take in consideration the = length > of layer-2 headers, as well as that of the physical preambles if any. = This > leads to even less different overhead ratios. > > > > With the relative consideration, this actually doesn't matter... And > > we can choose to ignore the detail of specific radio link protocols > > that can segment longer packets into many many more. >=20 > Different view here. > The _ratio_ of power-consumption increase, if n bytes are added to = each > packet, does depend on the total length of packets (with their headers = of all > layers, including link and physiscal). >=20 >=20 > > > > -Woj. >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From mark@townsley.net Tue Jul 26 13:39:15 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D9011E8130 for ; Tue, 26 Jul 2011 13:39:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQXftMspvpEk for ; Tue, 26 Jul 2011 13:39:14 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id A160511E812D for ; Tue, 26 Jul 2011 13:39:14 -0700 (PDT) Received: by pzk6 with SMTP id 6so1332852pzk.26 for ; Tue, 26 Jul 2011 13:39:14 -0700 (PDT) Received: by 10.68.55.103 with SMTP id r7mr6769213pbp.94.1311712754057; Tue, 26 Jul 2011 13:39:14 -0700 (PDT) Received: from dhcp-153b.meeting.ietf.org (dhcp-153b.meeting.ietf.org [130.129.21.59]) by mx.google.com with ESMTPS id q2sm912228pbj.3.2011.07.26.13.39.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 13:39:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> Date: Tue, 26 Jul 2011 16:39:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> To: "Rajiv Asati (rajiva)" X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 20:39:15 -0000 On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote: > Remi, >=20 >> Note also that, in 3GPP where power consumption is important, the = IPv4v6 >> bearer option completely avoids the IPv6 header overhead (no need for = 4V6). >=20 > Don't follow this. Could you please expand? I read that statement as in "cellular mobile" networks, dual-stack will = be deployed predominately with native dual-stack rather than 4V6 = solutions. I do think that the jury is likely still out on that. In any case, anyone who lived through the dial-up years with all the = different header negotiation options we had then and happily left behind = will likely roll their eyes at this "my header is shorter than yours!" = discussion. Header size is the tail wagging the dog in a solution, and = outside of the low-power/sensor world well within the point of = diminishing returns as an advantage of one approach vs. another. - Mark >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf >> Of R=E9mi Despr=E9s >> Sent: Tuesday, July 26, 2011 10:47 AM >> To: Wojciech Dec >> Cc: Softwires-wg; Wojciech Dec (wdec) >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >>=20 >> Well, I made my point (with one more comment below, at the end). >> Up to WG contributors, and to operators, to appreciate what is really >> important to them. >>=20 >> Note also that, in 3GPP where power consumption is important, the = IPv4v6 >> bearer option completely avoids the IPv6 header overhead (no need for = 4V6). >>=20 >> In wifi, I am still convinced that the impact on power consumption of = +6O vs >> +40 octets per IPv4 packet will remain negligible in real life, = especially as >> IPv6 will become the majority. >>=20 >> The impact of translation on e2e transparency will be discussed in = another >> email. >>=20 >> RD >>=20 >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : >>=20 >>> Remi, >>>=20 >>> On 25 July 2011 11:59, R=E9mi Despr=E9s = wrote: >>>>=20 >>>> Wojciech, >>>>=20 >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK = too much >> in favor of translation (4v6T) vs encapsulation (4V6E). >>>>=20 >>>> The draft has: >>>> = +------------------------+--------------------+---------------------+ >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | >>>> | | mode | Mode = | >>>> +------------------------+-------- ... = -------+---------------------+ >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | >>>> | to average payload of | | = | >>>> | a) ~550 bytes b) 1400 | | = | >>>> | bytes). | | = | >>>> | ------------------ | ------------------ | ------------------ = | >>>>=20 >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring = possible IPv4 >> options): >>>> - 4V6T adds 20 B (3.5 %). >>>> - 4V6E adds 40 B, (7.0 %). >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >>>> - Translation adds 20/1420 =3D 1,4 % >>>> - Encapsulation adds 40/1420 =3D 2,8 % >>>>=20 >>>> This gives: >>>> | ------------------ | ------------------ | ------------------ = | >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | >>>> | to average payload of | | = | >>>> | a) ~550 bytes b) 1400 | | = | >>>> | bytes). | | = | >>>> | ------------------ | ------------------ | ------------------ = | >>>=20 >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >>> transport. It thus seemed fair to measure and compare the overhead = as >>> relative to IPv6 encapsulation, and not IPv4, since there is no way = to >>> send an IPv4-only packet, and the useful data is the Layer4+ = payload. >>> Doing it your way you show mixes the basic IPv6 overhead. In any = case, >>> subtract the left column from the right and one arrives at the = figure >>> at pretty much the figures in the original table. >>>=20 >>>>=20 >>>> In addition, a complete comparison should take in consideration the = length >> of layer-2 headers, as well as that of the physical preambles if any. = This >> leads to even less different overhead ratios. >>>=20 >>> With the relative consideration, this actually doesn't matter... And >>> we can choose to ignore the detail of specific radio link protocols >>> that can segment longer packets into many many more. >>=20 >> Different view here. >> The _ratio_ of power-consumption increase, if n bytes are added to = each >> packet, does depend on the total length of packets (with their = headers of all >> layers, including link and physiscal). >>=20 >>=20 >>>=20 >>> -Woj. >>=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 rajiva@cisco.com Tue Jul 26 13:50:50 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B431211E80BF for ; Tue, 26 Jul 2011 13:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puM12xJtgnxd for ; Tue, 26 Jul 2011 13:50:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF3B11E80B9 for ; Tue, 26 Jul 2011 13:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=12441; q=dns/txt; s=iport; t=1311713449; x=1312923049; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0iMnEQFY/KH0XspScr4+WP6a6+9xSZo2SSZ4T44Qzjo=; b=HDUtM4Oh4Ls4fyyUmEdL9ou6ZwQO8olJ/Wjivp+lDaj1ouaTEcZa3I7F pW6RIY472U3ZBl97AjqqAZ63qt1hbEm4+dAtuUUZlCeyoawFk3fLpOZQS xdhXr7pree5o9DaO9+8A8evDWqLY2Ei3FOkqLl6fk2WXJokYGQuecOWhM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAFYoL06tJV2d/2dsb2JhbAA1AQEBAQIBAQEBEQEhOwkLBQcFAgEJDgMBAwEBAQoGIwEGARMSBiMDCwgBAQUBFgwUB5dOj1x3iHwEozOeVYVhXwSHKC+QK4RZhxU X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6648485" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jul 2011 20:50:48 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKom1H012916; Tue, 26 Jul 2011 20:50:48 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 15:50:48 -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: Tue, 26 Jul 2011 15:50:46 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0581BB7B@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] review ofdraft-operators-softwire-stateless-4v6-motivation-02.txt Thread-Index: AcxLq9FGPt6IUx7DQmucBvK6IWuXfwAJ5AEw References: <4E2ADC5E.1000101@piuha.net> From: "Rajiv Asati (rajiva)" To: "Cameron Byrne" , "Satoru Matsushima" X-OriginalArrivalTime: 26 Jul 2011 20:50:48.0139 (UTC) FILETIME=[B27A79B0:01CC4BD5] Cc: softwires@ietf.org Subject: Re: [Softwires] review ofdraft-operators-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, 26 Jul 2011 20:50:50 -0000 Cameron, > Since i have seen 3G/LTE on a few of these related threads, i will > state that it is unlikely that mobile wireless providers and the > 3GPP/GSMA will adopt yet another tunneling protocol or user equipment > modification.=09 Thanks for sharing your opinion, as most of us may not be caring about = the 3GPP environment while thinking about various transition options. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf > Of Cameron Byrne > Sent: Tuesday, July 26, 2011 11:51 AM > To: Satoru Matsushima > Cc: softwires@ietf.org > Subject: Re: [Softwires] review = ofdraft-operators-softwire-stateless-4v6- > motivation-02.txt >=20 > On Tue, Jul 26, 2011 at 8:19 AM, Satoru Matsushima > wrote: > > Hi Jari, > > > > Thank you for your comments. Please see inline: > > > > On 2011/07/23, at 10:36, Jari Arkko wrote: > > > >> I have reviewed this draft in preparation for discussions in the = upcoming > meeting. > >> > >> Thanks for writing this. In general, I agree with many of the = points raised > in the document. I do have a number of issues with the document as = well, > however. In some cases listed below, the document appears to be = claiming a > little bit too broad benefit where it should have argued for a = specific > difference between stateful and stateless solutions. Secondly, and = more, > seriously, I wish the document would contain a description of the = actual > trade-offs, including some of the issues that seem apparent in the = stateless > solution. > > > > Thanks, actually we had some trade-off explanation in previous = version. But > due to focus more on the motivation, current version doesn't mention = the > trade-off. Since the purpose of this document is to describe = motivations, and > kick-off to develop stateless solution, the authors focus to = motivation > otherwise analysis work. I agree that trade-off analysis is = significant, but > it would be better to be another document outside of which the = motivation > draft bears. > > > > > >> To name some: > >> > >> - difficulty in supporting widely different numbers of ports that = different > users employ ("cookie-cutter") > >> - operational impacts of having to make changes to port allocations = for > some users (does it change my addressing plan?) > >> - port randomization > >> > >> Note: I'm not saying that these things are showstoppers for the the > deployment of stateless solutions, but I think the document would come = across > are more balanced if it actually did consider both the negative and = positive > aspects. > > > > My thoughts for these question: > > > > (1) stateless solution is not exclusive with other solution in = theory. CPE > can use statefull solution for such purpose. > > (2) 4rd as for example, multiple mapping rule can be helpful to = change port > allocation without address plan changing and renumbering. > > (3) Port randomization still preserve host side. Restrict ports = should be in > CPE. Appropriate NAT session filtering is helpful to avoid the issues = of port > scan threats. (i.e., address and address-and-port dependent filtering) > > > > > >> > >> Finally, I think the document would benefit from describing = differences > between stateful solutions with dynamic mappings (traditional = NAT44-like > CGNs), network-based solutions with a static mappings, and approaches = that are > based on static/stateless mappings at the protocol level. = Understanding the > difference between these three I think is key to making a decision on = moving > ahead with stateless solutions work. > > > > As Remi pointed out, we couldn't assume any stateless solution in = the > motivation draft. So again, I think that it would be better to be = another > document to do it if we needed. > > > > Then, let me try to make technical discussion: > > > >> > >> Technical: > >> > >>> Service providers need to consider > >>> optimizing the form of packet processing when encapsulation is = used. > >>> Since existing header compression techniques are stateful, it is > >>> expected that stateless solution minimize overhead introduced by = the > >>> solution. > >>> > >> > >> I'm not sure I understand this. First off, both stateless and = stateful > solutions appear to be sending relatively static data from CPEs to the = central > network equipment (same source addresses etc). Is you argument that = the > stateless approach is even more static in this sense, and that this = would be > beneficial from the point of commonly used header compression tools? = Can you > be more specific about the exact differences between the two = approaches in > this case? > >> > >> FWIW, my experience is that fixed wireless solutions -- such as = those > involving a home access point communicating over 3G/LTE towards an = operator > network -- do not today use header compression as much as they = theoretically > could. I think we'll see more header compression deployment in coming = years, > and that would also provide an opportunity to push the right = compression > technology. > >> > > > > Yes, it is not header compression technology itself. It is = operational > effort to be by choosing translation method in tunneling network = architecture, > which I meant that within same address-family communication. > > > > >=20 > Since i have seen 3G/LTE on a few of these related threads, i will > state that it is unlikely that mobile wireless providers and the > 3GPP/GSMA will adopt yet another tunneling protocol or user equipment > modification.=09 >=20 > cb >=20 > > > >>> 3.1.4. No Additional Protocol for Port Control is Required > >>> > >>> The deployment of stateless solution does not require the = deployment > >>> of new dynamic signaling protocols to the end-user CPE in addition = to > >>> those already used. =A0In particular, existing protocols (e.g., = UPnP > >>> IGD:2 [UPnP-IGD]) can be used to control the NAT mapping in the = CPE. > >> > >> I think this point, while valid, needs some reformulation. As I can = see: > >> > >> * A new protocol will be required between CPE and network = equipment. The > question is if this protocol needs both a data path and control path = component > or not. And its not clear to me how provisioning works, somehow the = CPE needs > to learn what port ranges to use. So _some_ amount of control = protocols are > needed. > > > > Thanks, we'll clarify it, and improve the text. > > > > > >> > >> * Stateless/full aspect does not seem to matter with regards to = whether you > can use existing protocols to talk to the closest NAT, whether its at = the CPE > or in the network. Where you need new protocols and new code is if (a) = there > are multiple layers of NATs, and e.g., the home NAT needs to talk to = the > service provider NAT or (b) security and resource model of the NAT = changes > from "I have all ports" to "I can only give you some ports". > > > > Agreed. But point (b), current NAT implementation already can = control to > port range/number to force its port pool. As long as we utilize it, I = don't > think we need new code to do (b). > > > > > >> > >>> 3.2.1. Preserve Current Practices > >>> > >>> > >>> Service Providers require as much as possible to preserve the same > >>> operations as for current IP networking environments. > >>> > >>> If stateless solutions are deployed, common practices are = preserved. > >>> In particular, the maintenance and operation of the network do not > >>> require any additional constraints such as: path optimization > >>> practices, enforcing traffic engineering policies, issues related = to > >>> traffic oscillation between stateful devices, load-balancing the > >>> traffic or load sharing the traffic among egress/ingress points = can > >>> be used, etc. =A0In particular: > >>> > >>> o =A0anycast-based schemes can be used for load-balancing and > >>> =A0 =A0 redundancy purposes. > >>> > >>> o =A0asymmetric routing to/from the IPv4 Internet is natively = supported > >>> =A0 =A0and no path-pinning mechanisms have to be additionally > >>> =A0 =A0implemented. > >> > >> I think the issues at the bottom are valid requirements. However, = the > general point seems a bit overstated, IMO. The network is changing. = Both with > stateless and stateful solutions. I would suggest reformulating this = point to > be more about the specific issues than the general point. > > > > I think we can clarify it. But I don't understand your point = clearly. Can > you give some example about 'network changing'. > > > > > >> > >>> 3.2.5. Simplification of Qualification Procedures > >> > >> IMHO, this point is perhaps a little bit overstated as well. The = general > argument is that stateless mechanisms are simpler and therefore easier = to > test. I think the reality is that any solution involving major = fraction of > traffic from the ISP and involving significant multi-vendor = interoperability > requirements (CPE - network node) is something that I would like to = test very, > very carefully. And remember that this is not just TCP port forwarding = to > static port ranges per subscriber. Its UDP, too. And ICMP. And some > provisioning mechanism so that CPEs learn what ranges they can use. > > > > Thanks, we'll revisit about it. In general, we usually try to keep = current > procedure when we change something. From my tiny experience of = deployment > stateless solution into any area, qualification procedure of these are > lightweight than statefull. > > > > > >> > >>> 3.3.2. No Organizational Impact > >>> > >>> Stateless solutions rely on IP-related techniques to share and to > >>> deliver IPv4 packets over an IPv6 network. =A0In particular, IPv4 > >>> packets are delivered without any modification to their = destination > >>> CPE. =A0As such there is a clear separation between the = IP/transport > >>> layers and the service layers; no service interference is to be > >>> observed when a stateless solution is deployed. =A0This clear > >>> separation: > >>> > >>> Facilitates service evolution: =A0Since the payload of IPv4 = packets is > >>> not altered in the path, services can evolve without requiring any > >>> specific function in the Service Provider's network; > >>> > >>> Limits vendor dependency: =A0The upgrade of value-added services = does > >>> not involve any particular action from vendors that provide > >>> devices embedding the stateless IPv4/IPv6 interconnection > >>> function. > >>> > >>> No service-related skills are required for network operators who > >>> manage devices that embed the IPv4/IPv6 interconnection function: = =A0IP > >>> teams can be in charge of these devices; there is a priori no need > >>> to create a dedicated team to manage and to operate devices > >>> embedding the stateless IPv4/IPv6 interconnection function. =A0The > >>> introduction of stateless capabilities in the network are unlikely > >>> to degrade management costs. > >> > >> I think the point about less involvement between transport and = service > functions is a valid one. That being said, I think the introduction of = either > stateless or stateful solutions does have an organizational impact. = For > instance, now the capabilities and configuration of your CPE equipment = are > very relevant with respect to what you can deploy in the network side. > >> > >> I would suggest focusing on the specific point and not arguing the = general > point. > > > > Thanks, we'll revisit it. > > > > > >> > >> Editorial: > >> > >>> most sensitive problems > >> > >> ... most pressing? sensitive doesn't seem like the right word. > >> > >>> stateless solutions optimizes CPE-to-CPE > >>> > >> > >> ... optimize ... > >> > >> Jari > >> > > > > Thanks, > > > > 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 rajiva@cisco.com Tue Jul 26 13:58:31 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9B721F880C for ; Tue, 26 Jul 2011 13:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vCahbpDtd8W for ; Tue, 26 Jul 2011 13:58:30 -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 000FA21F861E for ; Tue, 26 Jul 2011 13:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6177; q=dns/txt; s=iport; t=1311713910; x=1312923510; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tGKgFnC0JPuC4ugFPbAE0SZ5Dj8XtcV5/tnz9pE43cs=; b=fAhaS4ADdNnXCKLWpQBhs1s1CfhZM4SpqdjxEvZtioaV+smwuq743j9o TBO8t+gNmXBW7sjoBAQhnfXut1bmcwFoMPNu/LDeCKIBmwuJRVHb1rjxv hJrtNq5fLN5ysymi4VjggE8fMSjnSzAoe2DKAC65klV6zrp2ILFBe7E0m s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYAAAkqL06tJXG9/2dsb2JhbAA1AQEBAQIBAQEBEQEhRAQHDAUCAQkRBAEBAQoGIwEGARMYIw4IAQEFFwwSAgeXTo9cd4h8BKMqnlaFYV8EhygvkCuLbg X-IronPort-AV: E=Sophos;i="4.67,271,1309737600"; d="scan'208";a="6645501" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 26 Jul 2011 20:58:24 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QKwN79026722; Tue, 26 Jul 2011 20:58:23 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 15:58:23 -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: Tue, 26 Jul 2011 15:58:21 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0581BB85@XMB-RCD-111.cisco.com> In-Reply-To: <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Header overheads - 4V6T vs 4V6E Thread-Index: AcxL1BVnWArZGrgMS/aWtvwxqfRAhAAATxBA References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> From: "Rajiv Asati (rajiva)" To: "Mark Townsley" X-OriginalArrivalTime: 26 Jul 2011 20:58:23.0831 (UTC) FILETIME=[C2178E70:01CC4BD6] Cc: Softwires-wg , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 20:58:31 -0000 Mark, You raise a good point. Header compression could be useful, however, = that comes at a cost.=20 Are you suggesting 'header compression' on the radio interface, or = between the UE and the GGSN/P-GW? Cheers, Rajiv > -----Original Message----- > From: Mark Townsley [mailto:mark@townsley.net] > Sent: Tuesday, July 26, 2011 4:39 PM > To: Rajiv Asati (rajiva) > Cc: R=E9mi Despr=E9s; Wojciech Dec; Softwires-wg; Wojciech Dec (wdec) > Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >=20 >=20 > On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote: >=20 > > Remi, > > > >> Note also that, in 3GPP where power consumption is important, the = IPv4v6 > >> bearer option completely avoids the IPv6 header overhead (no need = for 4V6). > > > > Don't follow this. Could you please expand? >=20 > I read that statement as in "cellular mobile" networks, dual-stack = will be > deployed predominately with native dual-stack rather than 4V6 = solutions. I do > think that the jury is likely still out on that. >=20 > In any case, anyone who lived through the dial-up years with all the = different > header negotiation options we had then and happily left behind will = likely > roll their eyes at this "my header is shorter than yours!" discussion. = Header > size is the tail wagging the dog in a solution, and outside of the = low- > power/sensor world well within the point of diminishing returns as an > advantage of one approach vs. another. >=20 > - Mark >=20 > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] On > Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Tuesday, July 26, 2011 10:47 AM > >> To: Wojciech Dec > >> Cc: Softwires-wg; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E > >> > >> Well, I made my point (with one more comment below, at the end). > >> Up to WG contributors, and to operators, to appreciate what is = really > >> important to them. > >> > >> Note also that, in 3GPP where power consumption is important, the = IPv4v6 > >> bearer option completely avoids the IPv6 header overhead (no need = for 4V6). > >> > >> In wifi, I am still convinced that the impact on power consumption = of +6O > vs > >> +40 octets per IPv4 packet will remain negligible in real life, = especially > as > >> IPv6 will become the majority. > >> > >> The impact of translation on e2e transparency will be discussed in = another > >> email. > >> > >> RD > >> > >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : > >> > >>> Remi, > >>> > >>> On 25 July 2011 11:59, R=E9mi Despr=E9s = wrote: > >>>> > >>>> Wojciech, > >>>> > >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK = too much > >> in favor of translation (4v6T) vs encapsulation (4V6E). > >>>> > >>>> The draft has: > >>>> = +------------------------+--------------------+---------------------+ > >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | > >>>> | | mode | Mode = | > >>>> +------------------------+-------- ... = -------+---------------------+ > >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | = ------------------ | > >>>> > >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring = possible > IPv4 > >> options): > >>>> - 4V6T adds 20 B (3.5 %). > >>>> - 4V6E adds 40 B, (7.0 %). > >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) > >>>> - Translation adds 20/1420 =3D 1,4 % > >>>> - Encapsulation adds 40/1420 =3D 2,8 % > >>>> > >>>> This gives: > >>>> | ------------------ | ------------------ | = ------------------ | > >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | = ------------------ | > >>> > >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 > >>> transport. It thus seemed fair to measure and compare the overhead = as > >>> relative to IPv6 encapsulation, and not IPv4, since there is no = way to > >>> send an IPv4-only packet, and the useful data is the Layer4+ = payload. > >>> Doing it your way you show mixes the basic IPv6 overhead. In any = case, > >>> subtract the left column from the right and one arrives at the = figure > >>> at pretty much the figures in the original table. > >>> > >>>> > >>>> In addition, a complete comparison should take in consideration = the > length > >> of layer-2 headers, as well as that of the physical preambles if = any. This > >> leads to even less different overhead ratios. > >>> > >>> With the relative consideration, this actually doesn't matter... = And > >>> we can choose to ignore the detail of specific radio link = protocols > >>> that can segment longer packets into many many more. > >> > >> Different view here. > >> The _ratio_ of power-consumption increase, if n bytes are added to = each > >> packet, does depend on the total length of packets (with their = headers of > all > >> layers, including link and physiscal). > >> > >> > >>> > >>> -Woj. > >> > >> > >> _______________________________________________ > >> 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 Tue Jul 26 14:02:06 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4507C11E80A7 for ; Tue, 26 Jul 2011 14:02:06 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-d4Uxgzx66l for ; Tue, 26 Jul 2011 14:02:05 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9335111E809D for ; Tue, 26 Jul 2011 14:02:04 -0700 (PDT) Received: by qyk29 with SMTP id 29so607494qyk.10 for ; Tue, 26 Jul 2011 14:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LXKjYzqH4kjINIu920a004HCZYDyJPxP4HMvQB1d7hU=; b=N/KABbd6Sr87sGyXJEnAHgStk9nGxEpggo+DM3wvKqraxYqLDCqBD2q2UXMpMDF7sG clwJcCzZs3H63fsNzcQg4DrwioVxKLihP+rEtQOG+vK/YHSr54W5gGrYQ5M1vqqN/ENH tBiS2cSN5J5WcDvBMUkkQKaoSl8H+blUAjHZg= MIME-Version: 1.0 Received: by 10.142.177.1 with SMTP id z1mr3903413wfe.174.1311714122192; Tue, 26 Jul 2011 14:02:02 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Tue, 26 Jul 2011 14:02:02 -0700 (PDT) In-Reply-To: <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> Date: Tue, 26 Jul 2011 23:02:02 +0200 Message-ID: From: Wojciech Dec To: Mark Townsley Content-Type: multipart/alternative; boundary=000e0cd14f0a4cd6a504a8ff3e6a Cc: Softwires-wg , =?ISO-8859-1?B?UultaSBEZXNwculz?= , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 21:02:06 -0000 --000e0cd14f0a4cd6a504a8ff3e6a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 26 July 2011 22:39, Mark Townsley wrote: > > On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote: > > > Remi, > > > >> Note also that, in 3GPP where power consumption is important, the IPv4= v6 > >> bearer option completely avoids the IPv6 header overhead (no need for > 4V6). > > > > Don't follow this. Could you please expand? > > I read that statement as in "cellular mobile" networks, dual-stack will b= e > deployed predominately with native dual-stack rather than 4V6 solutions. = I > do think that the jury is likely still out on that. > > In any case, anyone who lived through the dial-up years with all the > different header negotiation options we had then and happily left behind > will likely roll their eyes at this "my header is shorter than yours!" > discussion. Header size is the tail wagging the dog in a solution, and > outside of the low-power/sensor world well within the point of diminishin= g > returns as an advantage of one approach vs. another. > > - Mark > > There is another perspective here: Overhead (of any kind) that consumes a resource which could be used by other users, or by the user, is a waste, an= d thereby cost. This is more applicable to certain environments rather than others, but it is not something that can be dismissed as not applying. The overhead can be "optimized" (eg compressed), but that involves making more system changes and other trade-offs (eg IPinIP compression, which is anything but common) -Woj. > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n > Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Tuesday, July 26, 2011 10:47 AM > >> To: Wojciech Dec > >> Cc: Softwires-wg; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E > >> > >> Well, I made my point (with one more comment below, at the end). > >> Up to WG contributors, and to operators, to appreciate what is really > >> important to them. > >> > >> Note also that, in 3GPP where power consumption is important, the IPv4= v6 > >> bearer option completely avoids the IPv6 header overhead (no need for > 4V6). > >> > >> In wifi, I am still convinced that the impact on power consumption of > +6O vs > >> +40 octets per IPv4 packet will remain negligible in real life, > especially as > >> IPv6 will become the majority. > >> > >> The impact of translation on e2e transparency will be discussed in > another > >> email. > >> > >> RD > >> > >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : > >> > >>> Remi, > >>> > >>> On 25 July 2011 11:59, R=E9mi Despr=E9s wr= ote: > >>>> > >>>> Wojciech, > >>>> > >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too > much > >> in favor of translation (4v6T) vs encapsulation (4V6E). > >>>> > >>>> The draft has: > >>>> +------------------------+--------------------+---------------------= + > >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | > >>>> | | mode | Mode = | > >>>> +------------------------+-------- ... -------+---------------------= + > >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | ------------------ = | > >>>> > >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring possib= le > IPv4 > >> options): > >>>> - 4V6T adds 20 B (3.5 %). > >>>> - 4V6E adds 40 B, (7.0 %). > >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) > >>>> - Translation adds 20/1420 =3D 1,4 % > >>>> - Encapsulation adds 40/1420 =3D 2,8 % > >>>> > >>>> This gives: > >>>> | ------------------ | ------------------ | ------------------ = | > >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | ------------------ = | > >>> > >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 > >>> transport. It thus seemed fair to measure and compare the overhead as > >>> relative to IPv6 encapsulation, and not IPv4, since there is no way t= o > >>> send an IPv4-only packet, and the useful data is the Layer4+ payload. > >>> Doing it your way you show mixes the basic IPv6 overhead. In any case= , > >>> subtract the left column from the right and one arrives at the figure > >>> at pretty much the figures in the original table. > >>> > >>>> > >>>> In addition, a complete comparison should take in consideration the > length > >> of layer-2 headers, as well as that of the physical preambles if any. > This > >> leads to even less different overhead ratios. > >>> > >>> With the relative consideration, this actually doesn't matter... And > >>> we can choose to ignore the detail of specific radio link protocols > >>> that can segment longer packets into many many more. > >> > >> Different view here. > >> The _ratio_ of power-consumption increase, if n bytes are added to eac= h > >> packet, does depend on the total length of packets (with their headers > of all > >> layers, including link and physiscal). > >> > >> > >>> > >>> -Woj. > >> > >> > >> _______________________________________________ > >> 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 > > --000e0cd14f0a4cd6a504a8ff3e6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 26 July 2011 22:39, Mark Townsley <mark@townsley.net> wrote:

On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote:

> Remi,
>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>
> Don't follow this. Could you please expand?

I read that statement as in "cellular mobile" networks, dua= l-stack will be deployed predominately with native dual-stack rather than 4= V6 solutions. I do think that the jury is likely still out on that.

In any case, anyone who lived through the dial-up years with all the differ= ent header negotiation options we had then and happily left behind will lik= ely roll their eyes at this "my header is shorter than yours!" di= scussion. Header size is the tail wagging the dog in a solution, and outsid= e of the low-power/sensor world well within the point of diminishing return= s as an advantage of one approach vs. another.

- Mark

= There is another perspective here: Overhead (of any kind) that consumes a r= esource which could be used by other users, or by the user, is a waste, and= thereby cost. This is more applicable to certain environments rather than = others, but it is not something that can be dismissed as not applying.
The overhead can be "optimized" (eg compressed), but that involve= s making more system changes and other trade-offs (eg IPinIP compression, w= hich is anything but common)

-Woj.

>
> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: softwires-boun= ces@ietf.org [mailto:soft= wires-bounces@ietf.org] On Behalf
>> Of R=E9mi Despr=E9s
>> Sent: Tuesday, July 26, 2011 10:47 AM
>> To: Wojciech Dec
>> Cc: Softwires-wg; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E
>>
>> Well, I made my point (with one more comment below, at the end). >> Up to WG contributors, and to operators, to appreciate what is rea= lly
>> important to them.
>>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>>
>> In wifi, I am still convinced that the impact on power consumption= of +6O vs
>> +40 octets per IPv4 packet will remain negligible in real life, es= pecially as
>> IPv6 will become the majority.
>>
>> The impact of translation on e2e transparency will be discussed in= another
>> email.
>>
>> RD
>>
>> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit :
>>
>>> Remi,
>>>
>>> On 25 July 2011 11:59, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>>>
>>>> Wojciech,
>>>>
>>>> IPv4-header computations of draft-dec-stateless-4v6-02 are= AFAIK too much
>> in favor of translation (4v6T) vs encapsulation (4V6E).
>>>>
>>>> The draft has:
>>>> +------------------------+--------------------+-----------= ----------+
>>>> | Item =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 4V6 Translati= on =A0 =A0| 4V6 Mapped Tunnel =A0 |
>>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| mode = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mode =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>>> +------------------------+-------- ... -------+-----------= ----------+
>>>> | Overhead in relation =A0 | a) 0% b) 0% =A0 =A0 =A0 =A0| = a) 4.36% b) 1.71% =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>>
>>>> An IPv4 packet having a 550 B payload is 570 B long (ignor= ing possible IPv4
>> options):
>>>> - 4V6T adds 20 B (3.5 %).
>>>> - 4V6E adds 40 B, (7.0 %).
>>>> An IPv4 packet having a 1400 B payload is 1420 B long (at = least)
>>>> - Translation adds 20/1420 =3D 1,4 %
>>>> - Encapsulation adds 40/1420 =3D 2,8 %
>>>>
>>>> This gives:
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>> | Overhead in relation =A0 | a) 3.5% b) 1.4% =A0 =A0| a) 7= % b) 2.8% =A0 =A0 =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>
>>> Sure. However, 4V6, as per Figure 1 in the draft is based on I= Pv6
>>> transport. It thus seemed fair to measure and compare the over= head as
>>> relative to IPv6 encapsulation, and not IPv4, since there is n= o way to
>>> send an IPv4-only packet, and the useful data is the Layer4+ p= ayload.
>>> Doing it your way you show mixes the basic IPv6 overhead. In a= ny case,
>>> subtract the left column from the right and one arrives at the= figure
>>> at pretty much the figures in the original table.
>>>
>>>>
>>>> In addition, a complete comparison should take in consider= ation the length
>> of layer-2 headers, as well as that of the physical preambles if a= ny. This
>> leads to even less different overhead ratios.
>>>
>>> With the relative consideration, this actually doesn't mat= ter... And
>>> we can choose to ignore the detail of specific radio link prot= ocols
>>> that can segment longer packets into many many more.
>>
>> Different view here.
>> The _ratio_ of power-consumption increase, if n bytes are added to= each
>> packet, does depend on the total length of packets (with their hea= ders of all
>> layers, including link and physiscal).
>>
>>
>>>
>>> -Woj.
>>
>>
>> _______________________________________________
>> 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


--000e0cd14f0a4cd6a504a8ff3e6a-- From wdec.ietf@gmail.com Tue Jul 26 14:07:49 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408A711E80A7 for ; Tue, 26 Jul 2011 14:07:49 -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.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O89jthThhRv7 for ; Tue, 26 Jul 2011 14:07:48 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07E5211E8097 for ; Tue, 26 Jul 2011 14:07:47 -0700 (PDT) Received: by yie30 with SMTP id 30so720227yie.31 for ; Tue, 26 Jul 2011 14:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V862zalujWUPgV5TF6gfNoi5KGnsXbhVDd0+wbwJEkM=; b=DFy2f5JUALGKo/ixIom0EMV5mXsp9LrhX5kR+0n3qfLjEg9JkZMofo6I/Mt1kbySOj ueOGjpVIkSmVf9VGEQWUGIXZPkyRm4vaP4+wv/mRz748xxuxLqFzJ/dHIVTXolKSpzTX jhSYHxtgSWkarNaRT8on52xseyU5HdjovrkTc= MIME-Version: 1.0 Received: by 10.142.177.1 with SMTP id z1mr3906824wfe.174.1311714466877; Tue, 26 Jul 2011 14:07:46 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Tue, 26 Jul 2011 14:07:46 -0700 (PDT) In-Reply-To: References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> Date: Tue, 26 Jul 2011 23:07:46 +0200 Message-ID: From: Wojciech Dec To: Mark Townsley Content-Type: multipart/alternative; boundary=000e0cd14f0ad851d704a8ff52a1 Cc: Softwires-wg , =?ISO-8859-1?B?UultaSBEZXNwculz?= , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 21:07:49 -0000 --000e0cd14f0ad851d704a8ff52a1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 26 July 2011 23:02, Wojciech Dec wrote: > Typo... > > On 26 July 2011 22:39, Mark Townsley wrote: > >> >> On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote: >> >> > Remi, >> > >> >> Note also that, in 3GPP where power consumption is important, the >> IPv4v6 >> >> bearer option completely avoids the IPv6 header overhead (no need for >> 4V6). >> > >> > Don't follow this. Could you please expand? >> >> I read that statement as in "cellular mobile" networks, dual-stack will = be >> deployed predominately with native dual-stack rather than 4V6 solutions.= I >> do think that the jury is likely still out on that. >> >> In any case, anyone who lived through the dial-up years with all the >> different header negotiation options we had then and happily left behind >> will likely roll their eyes at this "my header is shorter than yours!" >> discussion. Header size is the tail wagging the dog in a solution, and >> outside of the low-power/sensor world well within the point of diminishi= ng >> returns as an advantage of one approach vs. another. >> >> - Mark >> >> There is another perspective here: Overhead (of any kind) that consumes = a > resource which could be used by other users, or by the user, is a waste, = and > thereby cost. This is more applicable to certain environments rather than > others, but it is not something that can not be dismissed as not applying= . > The overhead can be "optimized" (eg compressed), but that involves making > more system changes and other trade-offs (eg IPinIP compression, which is > anything but common) > > -Woj. > > > >> > Cheers, >> > Rajiv >> > >> > >> >> -----Original Message----- >> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] >> On Behalf >> >> Of R=E9mi Despr=E9s >> >> Sent: Tuesday, July 26, 2011 10:47 AM >> >> To: Wojciech Dec >> >> Cc: Softwires-wg; Wojciech Dec (wdec) >> >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >> >> >> >> Well, I made my point (with one more comment below, at the end). >> >> Up to WG contributors, and to operators, to appreciate what is really >> >> important to them. >> >> >> >> Note also that, in 3GPP where power consumption is important, the >> IPv4v6 >> >> bearer option completely avoids the IPv6 header overhead (no need for >> 4V6). >> >> >> >> In wifi, I am still convinced that the impact on power consumption of >> +6O vs >> >> +40 octets per IPv4 packet will remain negligible in real life, >> especially as >> >> IPv6 will become the majority. >> >> >> >> The impact of translation on e2e transparency will be discussed in >> another >> >> email. >> >> >> >> RD >> >> >> >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : >> >> >> >>> Remi, >> >>> >> >>> On 25 July 2011 11:59, R=E9mi Despr=E9s w= rote: >> >>>> >> >>>> Wojciech, >> >>>> >> >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK to= o >> much >> >> in favor of translation (4v6T) vs encapsulation (4V6E). >> >>>> >> >>>> The draft has: >> >>>> +------------------------+--------------------+--------------------= -+ >> >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | >> >>>> | | mode | Mode = | >> >>>> +------------------------+-------- ... -------+--------------------= -+ >> >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | >> >>>> | to average payload of | | = | >> >>>> | a) ~550 bytes b) 1400 | | = | >> >>>> | bytes). | | = | >> >>>> | ------------------ | ------------------ | ------------------ = | >> >>>> >> >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring >> possible IPv4 >> >> options): >> >>>> - 4V6T adds 20 B (3.5 %). >> >>>> - 4V6E adds 40 B, (7.0 %). >> >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >> >>>> - Translation adds 20/1420 =3D 1,4 % >> >>>> - Encapsulation adds 40/1420 =3D 2,8 % >> >>>> >> >>>> This gives: >> >>>> | ------------------ | ------------------ | ------------------ = | >> >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | >> >>>> | to average payload of | | = | >> >>>> | a) ~550 bytes b) 1400 | | = | >> >>>> | bytes). | | = | >> >>>> | ------------------ | ------------------ | ------------------ = | >> >>> >> >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >> >>> transport. It thus seemed fair to measure and compare the overhead a= s >> >>> relative to IPv6 encapsulation, and not IPv4, since there is no way = to >> >>> send an IPv4-only packet, and the useful data is the Layer4+ payload= . >> >>> Doing it your way you show mixes the basic IPv6 overhead. In any cas= e, >> >>> subtract the left column from the right and one arrives at the figur= e >> >>> at pretty much the figures in the original table. >> >>> >> >>>> >> >>>> In addition, a complete comparison should take in consideration the >> length >> >> of layer-2 headers, as well as that of the physical preambles if any. >> This >> >> leads to even less different overhead ratios. >> >>> >> >>> With the relative consideration, this actually doesn't matter... And >> >>> we can choose to ignore the detail of specific radio link protocols >> >>> that can segment longer packets into many many more. >> >> >> >> Different view here. >> >> The _ratio_ of power-consumption increase, if n bytes are added to ea= ch >> >> packet, does depend on the total length of packets (with their header= s >> of all >> >> layers, including link and physiscal). >> >> >> >> >> >>> >> >>> -Woj. >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> > --000e0cd14f0ad851d704a8ff52a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 26 July 2011 23:02, Wojciech Dec <wdec.ietf@gmail.co= m> wrote:
Typo...

On 26 July 2011= 22:39, Mark Townsley <mark@townsley.net> wrote:

On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote:

> Remi,
>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>
> Don't follow this. Could you please expand?

I read that statement as in "cellular mobile" networks, dua= l-stack will be deployed predominately with native dual-stack rather than 4= V6 solutions. I do think that the jury is likely still out on that.

In any case, anyone who lived through the dial-up years with all the differ= ent header negotiation options we had then and happily left behind will lik= ely roll their eyes at this "my header is shorter than yours!" di= scussion. Header size is the tail wagging the dog in a solution, and outsid= e of the low-power/sensor world well within the point of diminishing return= s as an advantage of one approach vs. another.

- Mark

There i= s another perspective here: Overhead (of any kind) that consumes a resource= which could be used by other users, or by the user, is a waste, and thereb= y cost. This is more applicable to certain environments rather than others,= but it is not something that can not be dismissed as not applying.
The overhead can be "optimized" (eg compressed), but that involve= s making more system changes and other trade-offs (eg IPinIP compression, w= hich is anything but common)

-Woj.

>
> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf >> Of R=E9mi Despr=E9s
>> Sent: Tuesday, July 26, 2011 10:47 AM
>> To: Wojciech Dec
>> Cc: Softwires-wg; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E
>>
>> Well, I made my point (with one more comment below, at the end). >> Up to WG contributors, and to operators, to appreciate what is rea= lly
>> important to them.
>>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>>
>> In wifi, I am still convinced that the impact on power consumption= of +6O vs
>> +40 octets per IPv4 packet will remain negligible in real life, es= pecially as
>> IPv6 will become the majority.
>>
>> The impact of translation on e2e transparency will be discussed in= another
>> email.
>>
>> RD
>>
>> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit :
>>
>>> Remi,
>>>
>>> On 25 July 2011 11:59, R=E9mi Despr=E9s <despres.remi@laposte.net>= ; wrote:
>>>>
>>>> Wojciech,
>>>>
>>>> IPv4-header computations of draft-dec-stateless-4v6-02 are= AFAIK too much
>> in favor of translation (4v6T) vs encapsulation (4V6E).
>>>>
>>>> The draft has:
>>>> +------------------------+--------------------+-----------= ----------+
>>>> | Item =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 4V6 Translati= on =A0 =A0| 4V6 Mapped Tunnel =A0 |
>>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| mode = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mode =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>>> +------------------------+-------- ... -------+-----------= ----------+
>>>> | Overhead in relation =A0 | a) 0% b) 0% =A0 =A0 =A0 =A0| = a) 4.36% b) 1.71% =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>>
>>>> An IPv4 packet having a 550 B payload is 570 B long (ignor= ing possible IPv4
>> options):
>>>> - 4V6T adds 20 B (3.5 %).
>>>> - 4V6E adds 40 B, (7.0 %).
>>>> An IPv4 packet having a 1400 B payload is 1420 B long (at = least)
>>>> - Translation adds 20/1420 =3D 1,4 %
>>>> - Encapsulation adds 40/1420 =3D 2,8 %
>>>>
>>>> This gives:
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>> | Overhead in relation =A0 | a) 3.5% b) 1.4% =A0 =A0| a) 7= % b) 2.8% =A0 =A0 =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>
>>> Sure. However, 4V6, as per Figure 1 in the draft is based on I= Pv6
>>> transport. It thus seemed fair to measure and compare the over= head as
>>> relative to IPv6 encapsulation, and not IPv4, since there is n= o way to
>>> send an IPv4-only packet, and the useful data is the Layer4+ p= ayload.
>>> Doing it your way you show mixes the basic IPv6 overhead. In a= ny case,
>>> subtract the left column from the right and one arrives at the= figure
>>> at pretty much the figures in the original table.
>>>
>>>>
>>>> In addition, a complete comparison should take in consider= ation the length
>> of layer-2 headers, as well as that of the physical preambles if a= ny. This
>> leads to even less different overhead ratios.
>>>
>>> With the relative consideration, this actually doesn't mat= ter... And
>>> we can choose to ignore the detail of specific radio link prot= ocols
>>> that can segment longer packets into many many more.
>>
>> Different view here.
>> The _ratio_ of power-consumption increase, if n bytes are added to= each
>> packet, does depend on the total length of packets (with their hea= ders of all
>> layers, including link and physiscal).
>>
>>
>>>
>>> -Woj.
>>
>>
>> _______________________________________________
>> 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



--000e0cd14f0ad851d704a8ff52a1-- From denghui02@gmail.com Tue Jul 26 14:21:07 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58F621F893E for ; Tue, 26 Jul 2011 14:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdUVaxTgnzgW for ; Tue, 26 Jul 2011 14:21:05 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2721F893C for ; Tue, 26 Jul 2011 14:21:01 -0700 (PDT) Received: by wyj26 with SMTP id 26so401719wyj.31 for ; Tue, 26 Jul 2011 14:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZR0ENnc3j0qJesa2QjwS417NshUAPdgThpKUqYv4OSg=; b=C3ea6PGqZJQ+h8lXhUzqIqp+2vwFifqDCdFy7afGD9AGOUNwxv9LrXHj1S0sjQ8baz LLPABzCzEFbIh0m6yv17RgFYIW+30xuVLlMIgsyptYyXZwigDSroLfgdiC4vyg+uRJAu DzGaAoK/w0EIOeb2XZ68OHx89dZJgLx7i9NXM= MIME-Version: 1.0 Received: by 10.216.20.143 with SMTP id p15mr1951460wep.0.1311715259093; Tue, 26 Jul 2011 14:20:59 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Tue, 26 Jul 2011 14:20:59 -0700 (PDT) In-Reply-To: <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> Date: Tue, 26 Jul 2011 17:20:59 -0400 Message-ID: From: Hui Deng To: Mark Townsley Content-Type: multipart/alternative; boundary=0016364d216110940b04a8ff8263 Cc: Softwires-wg , =?ISO-8859-1?B?UultaSBEZXNwculz?= , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 21:21:07 -0000 --0016364d216110940b04a8ff8263 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mark, Most today 3GPP discussion yesterday is about UE mobile case, other than UE as the CPE case, I believe this work should be taken sooner or later. Regards, -Hui 2011/7/26 Mark Townsley > > On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote: > > > Remi, > > > >> Note also that, in 3GPP where power consumption is important, the IPv4= v6 > >> bearer option completely avoids the IPv6 header overhead (no need for > 4V6). > > > > Don't follow this. Could you please expand? > > I read that statement as in "cellular mobile" networks, dual-stack will b= e > deployed predominately with native dual-stack rather than 4V6 solutions. = I > do think that the jury is likely still out on that. > > In any case, anyone who lived through the dial-up years with all the > different header negotiation options we had then and happily left behind > will likely roll their eyes at this "my header is shorter than yours!" > discussion. Header size is the tail wagging the dog in a solution, and > outside of the low-power/sensor world well within the point of diminishin= g > returns as an advantage of one approach vs. another. > > - Mark > > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n > Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Tuesday, July 26, 2011 10:47 AM > >> To: Wojciech Dec > >> Cc: Softwires-wg; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E > >> > >> Well, I made my point (with one more comment below, at the end). > >> Up to WG contributors, and to operators, to appreciate what is really > >> important to them. > >> > >> Note also that, in 3GPP where power consumption is important, the IPv4= v6 > >> bearer option completely avoids the IPv6 header overhead (no need for > 4V6). > >> > >> In wifi, I am still convinced that the impact on power consumption of > +6O vs > >> +40 octets per IPv4 packet will remain negligible in real life, > especially as > >> IPv6 will become the majority. > >> > >> The impact of translation on e2e transparency will be discussed in > another > >> email. > >> > >> RD > >> > >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : > >> > >>> Remi, > >>> > >>> On 25 July 2011 11:59, R=E9mi Despr=E9s wr= ote: > >>>> > >>>> Wojciech, > >>>> > >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too > much > >> in favor of translation (4v6T) vs encapsulation (4V6E). > >>>> > >>>> The draft has: > >>>> +------------------------+--------------------+---------------------= + > >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | > >>>> | | mode | Mode = | > >>>> +------------------------+-------- ... -------+---------------------= + > >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | ------------------ = | > >>>> > >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring possib= le > IPv4 > >> options): > >>>> - 4V6T adds 20 B (3.5 %). > >>>> - 4V6E adds 40 B, (7.0 %). > >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) > >>>> - Translation adds 20/1420 =3D 1,4 % > >>>> - Encapsulation adds 40/1420 =3D 2,8 % > >>>> > >>>> This gives: > >>>> | ------------------ | ------------------ | ------------------ = | > >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | ------------------ = | > >>> > >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 > >>> transport. It thus seemed fair to measure and compare the overhead as > >>> relative to IPv6 encapsulation, and not IPv4, since there is no way t= o > >>> send an IPv4-only packet, and the useful data is the Layer4+ payload. > >>> Doing it your way you show mixes the basic IPv6 overhead. In any case= , > >>> subtract the left column from the right and one arrives at the figure > >>> at pretty much the figures in the original table. > >>> > >>>> > >>>> In addition, a complete comparison should take in consideration the > length > >> of layer-2 headers, as well as that of the physical preambles if any. > This > >> leads to even less different overhead ratios. > >>> > >>> With the relative consideration, this actually doesn't matter... And > >>> we can choose to ignore the detail of specific radio link protocols > >>> that can segment longer packets into many many more. > >> > >> Different view here. > >> The _ratio_ of power-consumption increase, if n bytes are added to eac= h > >> packet, does depend on the total length of packets (with their headers > of all > >> layers, including link and physiscal). > >> > >> > >>> > >>> -Woj. > >> > >> > >> _______________________________________________ > >> 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 > --0016364d216110940b04a8ff8263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Mark,
=A0
Most today 3GPP discussion yesterday is about UE mobile case, other th= an UE as the CPE case, I believe this work should be taken sooner or later.=
=A0
Regards,
=A0
-Hui


=A0
2011/7/26 Mark Townsley <mark@townsley.net>

On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wro= te:

> Remi,
>
>> Note also that, in 3GPP where pow= er consumption is important, the IPv4v6
>> bearer option completel= y avoids the IPv6 header overhead (no need for 4V6).
>
> Don't follow this. Could you please expand?

I= read that statement as in "cellular mobile" networks, dual-stack= will be deployed predominately with native dual-stack rather than 4V6 solu= tions. I do think that the jury is likely still out on that.

In any case, anyone who lived through the dial-up years with all the di= fferent header negotiation options we had then and happily left behind will= likely roll their eyes at this "my header is shorter than yours!"= ; discussion. Header size is the tail wagging the dog in a solution, and ou= tside of the low-power/sensor world well within the point of diminishing re= turns as an advantage of one approach vs. another.

- Mark

>
> Cheers,
> Rajiv
>
>>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beha= lf
>> Of R=E9mi Despr=E9s
>> Sent: Tuesday, July 26, 2011 10:47= AM
>> To: Wojciech Dec
>> Cc: Softwires-wg; Wojciech Dec= (wdec)
>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6= E
>>
>> Well, I made my point (with one more comment below, at= the end).
>> Up to WG contributors, and to operators, to apprecia= te what is really
>> important to them.
>>
>> No= te also that, in 3GPP where power consumption is important, the IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>>
>> In wifi, I am still convinced that the im= pact on power consumption of +6O vs
>> +40 octets per IPv4 packet = will remain negligible in real life, especially as
>> IPv6 will become the majority.
>>
>> The impact = of translation on e2e transparency will be discussed in another
>>= email.
>>
>> RD
>>
>> Le 26 juil. 2011= =E0 15:52, Wojciech Dec a =E9crit :
>>
>>> Remi,
>>>
>>> On 25 July 2= 011 11:59, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>>>
>>>= ;> Wojciech,
>>>>
>>>> IPv4-header computations of draft-dec-= stateless-4v6-02 are AFAIK too much
>> in favor of translation (4v= 6T) vs encapsulation (4V6E).
>>>>
>>>> The dr= aft has:
>>>> +------------------------+--------------------+-----------= ----------+
>>>> | Item =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = | 4V6 Translation =A0 =A0| 4V6 Mapped Tunnel =A0 |
>>>> | = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| mode =A0 =A0 =A0 =A0 =A0 = =A0 =A0 | Mode =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>>> +------------------------+-------- ... -------+-----------= ----------+
>>>> | Overhead in relation =A0 | a) 0% b) 0% = =A0 =A0 =A0 =A0| a) 4.36% b) 1.71% =A0 |
>>>> | to average p= ayload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> = | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | --= ---------------- =A0 =A0 | ------------------ | ------------------ =A0|
>>>>
>>>> An IPv4 packet having a 550 B payload = is 570 B long (ignoring possible IPv4
>> options):
>>>= > - 4V6T adds 20 B (3.5 %).
>>>> - 4V6E adds 40 B, (7.0 %= ).
>>>> An IPv4 packet having a 1400 B payload is 1420 B long (at = least)
>>>> - Translation adds 20/1420 =3D 1,4 %
>>= >> - Encapsulation adds 40/1420 =3D 2,8 %
>>>>
>= >>> This gives:
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>> | Overhead in relation =A0 | a) 3.5% = b) 1.4% =A0 =A0| a) 7% b) 2.8% =A0 =A0 =A0 |
>>>> | to avera= ge payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> = | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | --= ---------------- =A0 =A0 | ------------------ | ------------------ =A0|
>>>
>>> Sure. However, 4V6, as per Figure 1 in the dra= ft is based on IPv6
>>> transport. It thus seemed fair to measu= re and compare the overhead as
>>> relative to IPv6 encapsulati= on, and not IPv4, since there is no way to
>>> send an IPv4-only packet, and the useful data is the Layer4+ p= ayload.
>>> Doing it your way you show mixes the basic IPv6 ove= rhead. In any case,
>>> subtract the left column from the right= and one arrives at the figure
>>> at pretty much the figures in the original table.
>>&= gt;
>>>>
>>>> In addition, a complete compari= son should take in consideration the length
>> of layer-2 headers,= as well as that of the physical preambles if any. This
>> leads to even less different overhead ratios.
>>>
&= gt;>> With the relative consideration, this actually doesn't matt= er... And
>>> we can choose to ignore the detail of specific ra= dio link protocols
>>> that can segment longer packets into many many more.
>&g= t;
>> Different view here.
>> The _ratio_ of power-consum= ption increase, if n bytes are added to each
>> packet, does depen= d on the total length of packets (with their headers of all
>> layers, including link and physiscal).
>>
>>
= >>>
>>> -Woj.
>>
>>
>> ____= ___________________________________________
>> Softwires mailing l= ist
>> Softwires@ietf.org
&g= t;> https://www.ietf.org/mailman/listinfo/softwires
> ___= ____________________________________________
> Softwires mailing list
> S= oftwires@ietf.org
> https://www.ietf.org/mailman/listinfo/soft= wires

_______________________________________________
Softwires mailing li= st
Softwires@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/softwires

--0016364d216110940b04a8ff8263-- From bingxuere@gmail.com Tue Jul 26 18:06:24 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442EA21F86AF for ; Tue, 26 Jul 2011 18:06:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrQy9UbMTpkq for ; Tue, 26 Jul 2011 18:06:23 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9569E21F86A5 for ; Tue, 26 Jul 2011 18:06:23 -0700 (PDT) Received: by iye7 with SMTP id 7so1365727iye.31 for ; Tue, 26 Jul 2011 18:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=31be4eu6UffTvCFNF9FsfrhV/86GR3JU4XCCAYPLVEY=; b=VyB5BKHWTpwZXQcPqJSUsTWCL8X/DiiuNhZ2cQbZuLCDYmhkxHsJQLPCRfkR9CnSvG q9cRliQ3rvEski3OJ/JAhEdT+dQAyI/eFwUlvhwCAQeHFJ8M9Gg11fSwZ6GyaMXPKzKp wMwgi+dfcv2P/WPeaR0OADQrcgZsuVCmFReL8= Received: by 10.231.111.39 with SMTP id q39mr6159562ibp.106.1311728779150; Tue, 26 Jul 2011 18:06:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Tue, 26 Jul 2011 18:05:59 -0700 (PDT) From: Qiong Date: Wed, 27 Jul 2011 09:05:59 +0800 Message-ID: To: softwires@ietf.org Content-Type: multipart/alternative; boundary=0016367d72e0ec45aa04a902a752 Subject: [Softwires] lightweight 4over6 demo in IETF X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 01:06:24 -0000 --0016367d72e0ec45aa04a902a752 Content-Type: text/plain; charset=UTF-8 Dear all, We have hold a lightweight 4over6 Demo in the terminal room, 2000D, together with PCP demo. Welcome to have a try and your comments are more than welcome. draft: http://tools.ietf.org/html//draft-cui-softwire-b4-translated-ds-lite-01 Best regards Qiong SUN --0016367d72e0ec45aa04a902a752 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

We have hold a lightweight 4over6 Demo in the = terminal room, 2000D,=C2=A0together=C2=A0with PCP demo. Welcome to have a t= ry and your comments are more than welcome.


Best regards

Qiong SUN
--0016367d72e0ec45aa04a902a752-- From yiu_lee@cable.comcast.com Tue Jul 26 18:40:29 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439C621F8665 for ; Tue, 26 Jul 2011 18:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.851 X-Spam-Level: X-Spam-Status: No, score=-104.851 tagged_above=-999 required=5 tests=[AWL=3.612, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhv6gvyYk5v6 for ; Tue, 26 Jul 2011 18:40:28 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9169221F8663 for ; Tue, 26 Jul 2011 18:40:28 -0700 (PDT) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.135271231; Tue, 26 Jul 2011 21:40:24 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Tue, 26 Jul 2011 21:40:24 -0400 From: "Lee, Yiu" To: Satoru Matsushima , Jari Arkko Thread-Topic: [Softwires] review of draft-operators-softwire-stateless-4v6-motivation-02.txt Thread-Index: AQHMS/4mlxjnIv4v7EuYPNGIsJMFbA== Date: Wed, 27 Jul 2011 01:40:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [147.191.125.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <703C9D6632786149BCA52C16918FEACB@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] review of draft-operators-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, 27 Jul 2011 01:40:29 -0000 I want to eacho Satoru's comment that this draft wasn't intended to compare stateless and stateful transition mechanisms. This draft only describes the motivations. On 7/26/11 11:19 AM, "Satoru Matsushima" wrote: >Thanks, actually we had some trade-off explanation in previous version. >But due to focus more on the motivation, current version doesn't mention >the trade-off. Since the purpose of this document is to describe >motivations, and kick-off to develop stateless solution, the authors >focus to motivation otherwise analysis work. I agree that trade-off >analysis is significant, but it would be better to be another document >outside of which the motivation draft bears. From mark@townsley.net Tue Jul 26 20:41:00 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C495E801F for ; Tue, 26 Jul 2011 20:41:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrRqUMnSoJXq for ; Tue, 26 Jul 2011 20:41:00 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0FE75E801C for ; Tue, 26 Jul 2011 20:40:59 -0700 (PDT) Received: by gwb20 with SMTP id 20so927453gwb.31 for ; Tue, 26 Jul 2011 20:40:59 -0700 (PDT) Received: by 10.142.149.20 with SMTP id w20mr4101082wfd.188.1311738057377; Tue, 26 Jul 2011 20:40:57 -0700 (PDT) Received: from [10.255.254.113] (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id v17sm719095wfd.5.2011.07.26.20.40.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 20:40:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Mark Townsley In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0581BB85@XMB-RCD-111.cisco.com> Date: Tue, 26 Jul 2011 23:40:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> <067E6CE33034954AAC05C9EC85E2577C0581BB85@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 03:41:00 -0000 On Jul 26, 2011, at 4:58 PM, Rajiv Asati (rajiva) wrote: > Mark, >=20 > You raise a good point. Header compression could be useful, however, = that comes at a cost.=20 >=20 > Are you suggesting 'header compression' on the radio interface, or = between the UE and the GGSN/P-GW? It's a general statement.=20 For example, in the dial-up days virtually every layer had some way to = reduce encapsulation size. PPP could compress away HDLC-like framing, = protocol ID, etc. We had VJ TCP Header Compression and even payload = compression as well. L2TP published an L2TP Header Compression document = to show that it could have a header-size smaller than PPTP. And of = course ROHC. As link-speeds increased, these progressively fell by the = wayside in terms of wide support and usage. There are good reasons for = that. - Mark >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: Mark Townsley [mailto:mark@townsley.net] >> Sent: Tuesday, July 26, 2011 4:39 PM >> To: Rajiv Asati (rajiva) >> Cc: R=E9mi Despr=E9s; Wojciech Dec; Softwires-wg; Wojciech Dec (wdec) >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >>=20 >>=20 >> On Jul 26, 2011, at 4:30 PM, Rajiv Asati (rajiva) wrote: >>=20 >>> Remi, >>>=20 >>>> Note also that, in 3GPP where power consumption is important, the = IPv4v6 >>>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6). >>>=20 >>> Don't follow this. Could you please expand? >>=20 >> I read that statement as in "cellular mobile" networks, dual-stack = will be >> deployed predominately with native dual-stack rather than 4V6 = solutions. I do >> think that the jury is likely still out on that. >>=20 >> In any case, anyone who lived through the dial-up years with all the = different >> header negotiation options we had then and happily left behind will = likely >> roll their eyes at this "my header is shorter than yours!" = discussion. Header >> size is the tail wagging the dog in a solution, and outside of the = low- >> power/sensor world well within the point of diminishing returns as an >> advantage of one approach vs. another. >>=20 >> - Mark >>=20 >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] On >> Behalf >>>> Of R=E9mi Despr=E9s >>>> Sent: Tuesday, July 26, 2011 10:47 AM >>>> To: Wojciech Dec >>>> Cc: Softwires-wg; Wojciech Dec (wdec) >>>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >>>>=20 >>>> Well, I made my point (with one more comment below, at the end). >>>> Up to WG contributors, and to operators, to appreciate what is = really >>>> important to them. >>>>=20 >>>> Note also that, in 3GPP where power consumption is important, the = IPv4v6 >>>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6). >>>>=20 >>>> In wifi, I am still convinced that the impact on power consumption = of +6O >> vs >>>> +40 octets per IPv4 packet will remain negligible in real life, = especially >> as >>>> IPv6 will become the majority. >>>>=20 >>>> The impact of translation on e2e transparency will be discussed in = another >>>> email. >>>>=20 >>>> RD >>>>=20 >>>> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : >>>>=20 >>>>> Remi, >>>>>=20 >>>>> On 25 July 2011 11:59, R=E9mi Despr=E9s = wrote: >>>>>>=20 >>>>>> Wojciech, >>>>>>=20 >>>>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK = too much >>>> in favor of translation (4v6T) vs encapsulation (4V6E). >>>>>>=20 >>>>>> The draft has: >>>>>> = +------------------------+--------------------+---------------------+ >>>>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | >>>>>> | | mode | Mode = | >>>>>> +------------------------+-------- ... = -------+---------------------+ >>>>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | >>>>>> | to average payload of | | = | >>>>>> | a) ~550 bytes b) 1400 | | = | >>>>>> | bytes). | | = | >>>>>> | ------------------ | ------------------ | = ------------------ | >>>>>>=20 >>>>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring = possible >> IPv4 >>>> options): >>>>>> - 4V6T adds 20 B (3.5 %). >>>>>> - 4V6E adds 40 B, (7.0 %). >>>>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >>>>>> - Translation adds 20/1420 =3D 1,4 % >>>>>> - Encapsulation adds 40/1420 =3D 2,8 % >>>>>>=20 >>>>>> This gives: >>>>>> | ------------------ | ------------------ | = ------------------ | >>>>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | >>>>>> | to average payload of | | = | >>>>>> | a) ~550 bytes b) 1400 | | = | >>>>>> | bytes). | | = | >>>>>> | ------------------ | ------------------ | = ------------------ | >>>>>=20 >>>>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >>>>> transport. It thus seemed fair to measure and compare the overhead = as >>>>> relative to IPv6 encapsulation, and not IPv4, since there is no = way to >>>>> send an IPv4-only packet, and the useful data is the Layer4+ = payload. >>>>> Doing it your way you show mixes the basic IPv6 overhead. In any = case, >>>>> subtract the left column from the right and one arrives at the = figure >>>>> at pretty much the figures in the original table. >>>>>=20 >>>>>>=20 >>>>>> In addition, a complete comparison should take in consideration = the >> length >>>> of layer-2 headers, as well as that of the physical preambles if = any. This >>>> leads to even less different overhead ratios. >>>>>=20 >>>>> With the relative consideration, this actually doesn't matter... = And >>>>> we can choose to ignore the detail of specific radio link = protocols >>>>> that can segment longer packets into many many more. >>>>=20 >>>> Different view here. >>>> The _ratio_ of power-consumption increase, if n bytes are added to = each >>>> packet, does depend on the total length of packets (with their = headers of >> all >>>> layers, including link and physiscal). >>>>=20 >>>>=20 >>>>>=20 >>>>> -Woj. >>>>=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 >=20 From despres.remi@laposte.net Wed Jul 27 00:17:31 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF01E11E8076 for ; Wed, 27 Jul 2011 00:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 658xDu5UxNa7 for ; Wed, 27 Jul 2011 00:17:30 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4C69B11E8072 for ; Wed, 27 Jul 2011 00:17:26 -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 838FE940163; Wed, 27 Jul 2011 09:17:20 +0200 (CEST) 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: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> Date: Wed, 27 Jul 2011 09:17:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <196666F4-FF0F-401E-81DD-35E84FD50B83@laposte.net> References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:17:31 -0000 Rajiv, As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2, = 3GPP has introduced the IPv4v6 bearer. With it, mobile nodes exchange packets natively in bot IPv4 and IPv6. This saves 20 octets per IPv4 packet compared to a translation that = replaces an IPv4 header by an IPv6 header. Regards, RD Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit : > Remi, >=20 >> Note also that, in 3GPP where power consumption is important, the = IPv4v6 >> bearer option completely avoids the IPv6 header overhead (no need for = 4V6). >=20 > Don't follow this. Could you please expand? >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf >> Of R=E9mi Despr=E9s >> Sent: Tuesday, July 26, 2011 10:47 AM >> To: Wojciech Dec >> Cc: Softwires-wg; Wojciech Dec (wdec) >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >>=20 >> Well, I made my point (with one more comment below, at the end). >> Up to WG contributors, and to operators, to appreciate what is really >> important to them. >>=20 >> Note also that, in 3GPP where power consumption is important, the = IPv4v6 >> bearer option completely avoids the IPv6 header overhead (no need for = 4V6). >>=20 >> In wifi, I am still convinced that the impact on power consumption of = +6O vs >> +40 octets per IPv4 packet will remain negligible in real life, = especially as >> IPv6 will become the majority. >>=20 >> The impact of translation on e2e transparency will be discussed in = another >> email. >>=20 >> RD >>=20 >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : >>=20 >>> Remi, >>>=20 >>> On 25 July 2011 11:59, R=E9mi Despr=E9s = wrote: >>>>=20 >>>> Wojciech, >>>>=20 >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK = too much >> in favor of translation (4v6T) vs encapsulation (4V6E). >>>>=20 >>>> The draft has: >>>> = +------------------------+--------------------+---------------------+ >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | >>>> | | mode | Mode = | >>>> +------------------------+-------- ... = -------+---------------------+ >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | >>>> | to average payload of | | = | >>>> | a) ~550 bytes b) 1400 | | = | >>>> | bytes). | | = | >>>> | ------------------ | ------------------ | ------------------ = | >>>>=20 >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring = possible IPv4 >> options): >>>> - 4V6T adds 20 B (3.5 %). >>>> - 4V6E adds 40 B, (7.0 %). >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >>>> - Translation adds 20/1420 =3D 1,4 % >>>> - Encapsulation adds 40/1420 =3D 2,8 % >>>>=20 >>>> This gives: >>>> | ------------------ | ------------------ | ------------------ = | >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | >>>> | to average payload of | | = | >>>> | a) ~550 bytes b) 1400 | | = | >>>> | bytes). | | = | >>>> | ------------------ | ------------------ | ------------------ = | >>>=20 >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >>> transport. It thus seemed fair to measure and compare the overhead = as >>> relative to IPv6 encapsulation, and not IPv4, since there is no way = to >>> send an IPv4-only packet, and the useful data is the Layer4+ = payload. >>> Doing it your way you show mixes the basic IPv6 overhead. In any = case, >>> subtract the left column from the right and one arrives at the = figure >>> at pretty much the figures in the original table. >>>=20 >>>>=20 >>>> In addition, a complete comparison should take in consideration the = length >> of layer-2 headers, as well as that of the physical preambles if any. = This >> leads to even less different overhead ratios. >>>=20 >>> With the relative consideration, this actually doesn't matter... And >>> we can choose to ignore the detail of specific radio link protocols >>> that can segment longer packets into many many more. >>=20 >> Different view here. >> The _ratio_ of power-consumption increase, if n bytes are added to = each >> packet, does depend on the total length of packets (with their = headers of all >> layers, including link and physiscal). >>=20 >>=20 >>>=20 >>> -Woj. >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Jul 27 00:34:31 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454D221F8696 for ; Wed, 27 Jul 2011 00:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvJ3eSoHIXgM for ; Wed, 27 Jul 2011 00:34:30 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id B739E21F8686 for ; Wed, 27 Jul 2011 00:34:29 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2213.sfr.fr (SMTP Server) with ESMTP id 872BA700008C; Wed, 27 Jul 2011 09:34:28 +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 DFF2E700008B; Wed, 27 Jul 2011 09:34:27 +0200 (CEST) X-SFR-UUID: 20110727073427917.DFF2E700008B@msfrf2213.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-584902327 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 27 Jul 2011 09:34:27 +0200 Message-Id: <36FF9972-776B-43B0-9EB8-BFB2131C6292@laposte.net> References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <3221C331-4AF2-4D3D-B8DB-A96783D4B43C@townsley.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:34:31 -0000 --Apple-Mail-2-584902327 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 26 juil. 2011 =E0 23:07, Wojciech Dec a =E9crit : =95=95=95 >=20 > There is another perspective here: Overhead (of any kind) that = consumes a resource which could be used by other users, or by the user, = is a waste, and thereby cost. This is more applicable to certain = environments rather than others, but it is not something that can not be = dismissed as not applying. Right. However, if by accepting a small overhead, one significantly simplifies = service specification, implementation validation, training, operation, = maintenance, this cost can be largely compensated by other costs that = are saved. For a transition solution, this can be even more so. The perspective has to be global.=20 Cheers, RD --Apple-Mail-2-584902327 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

There is another = perspective here: Overhead (of any kind) that consumes a resource which = could be used by other users, or by the user, is a waste, and thereby = cost. This is more applicable to certain environments rather than = others, but it is not something that can not be dismissed as not = applying.

Right.
However, if by accepting a small overhead, one = significantly simplifies service specification, implementation = validation, training, operation, maintenance, this cost can be largely = compensated by other costs that are saved.
For a transition = solution, this can be even more so.

The = perspective has to be = global. 

Cheers,
RD
= --Apple-Mail-2-584902327-- From despres.remi@laposte.net Wed Jul 27 01:58:12 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB8A21F8BA9 for ; Wed, 27 Jul 2011 01:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJa0TYK-dP15 for ; Wed, 27 Jul 2011 01:58:11 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9C61621F8BA8 for ; Wed, 27 Jul 2011 01:58:11 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id 9B2F37000095; Wed, 27 Jul 2011 10:58:10 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2314.sfr.fr (SMTP Server) with ESMTP id 1F8477000094; Wed, 27 Jul 2011 10:58:10 +0200 (CEST) X-SFR-UUID: 20110727085810129.1F8477000094@msfrf2314.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: Wed, 27 Jul 2011 10:58:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] e2e transparency in 4V6 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:58:12 -0000 Le 26 juil. 2011 =E0 16:56, Wojciech Dec a =E9crit : ... >> The impact of translation on e2e transparency will be discussed in = another email. >=20 > I trust that it will explain how to build an e2e transparent system > with a stateful port restricted NAT44 in the path. OK, there may be ambiguity about e2e. Here, I meant _network_ e2e transparency, i.e. from customer site to = customer site. 1. With network e2e transparency: - There is no assumption to be made about NAT44 behaviors in CE's. (We all know that there are many different NAT and FW behaviors, so that = any assumption may prove to be wrong with a few existing NAT devices.) - Except for the port-set restriction of shared IPv4 addresses, complete = backward compatibility of the IPv4 service is ensured. 2. If some CE's are given full IPv4 addresses, they may use protocols for = which NAT44 isn't needed. With network e2e transparency, no restriction on IP options they may use = is needed. Regards, RD > If not, the IPv4 e2e transparency of encapped or translated transports > is very much the same. >=20 > -Woj. >>=20 >> RD >>=20 >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : >>=20 >>> Remi, >>>=20 >>> On 25 July 2011 11:59, R=E9mi Despr=E9s = wrote: >>>>=20 >>>> Wojciech, >>>>=20 >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK = too much in favor of translation (4v6T) vs encapsulation (4V6E). >>>>=20 >>>> The draft has: >>>> = +------------------------+--------------------+---------------------+ >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | >>>> | | mode | Mode = | >>>> +------------------------+-------- ... = -------+---------------------+ >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | >>>> | to average payload of | | = | >>>> | a) ~550 bytes b) 1400 | | = | >>>> | bytes). | | = | >>>> | ------------------ | ------------------ | ------------------ = | >>>>=20 >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring = possible IPv4 options): >>>> - 4V6T adds 20 B (3.5 %). >>>> - 4V6E adds 40 B, (7.0 %). >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >>>> - Translation adds 20/1420 =3D 1,4 % >>>> - Encapsulation adds 40/1420 =3D 2,8 % >>>>=20 >>>> This gives: >>>> | ------------------ | ------------------ | ------------------ = | >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | >>>> | to average payload of | | = | >>>> | a) ~550 bytes b) 1400 | | = | >>>> | bytes). | | = | >>>> | ------------------ | ------------------ | ------------------ = | >>>=20 >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >>> transport. It thus seemed fair to measure and compare the overhead = as >>> relative to IPv6 encapsulation, and not IPv4, since there is no way = to >>> send an IPv4-only packet, and the useful data is the Layer4+ = payload. >>> Doing it your way you show mixes the basic IPv6 overhead. In any = case, >>> subtract the left column from the right and one arrives at the = figure >>> at pretty much the figures in the original table. >>>=20 >>>>=20 >>>> In addition, a complete comparison should take in consideration the = length of layer-2 headers, as well as that of the physical preambles if = any. This leads to even less different overhead ratios. >>>=20 >>> With the relative consideration, this actually doesn't matter... And >>> we can choose to ignore the detail of specific radio link protocols >>> that can segment longer packets into many many more. >>=20 >> Different view here. >> The _ratio_ of power-consumption increase, if n bytes are added to = each packet, does depend on the total length of packets (with their = headers of all layers, including link and physiscal). >>=20 >>=20 >>>=20 >>> -Woj. >>=20 >>=20 >>=20 From internet-drafts@ietf.org Wed Jul 27 04:11:16 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F6C21F8B9B; Wed, 27 Jul 2011 04:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUZEC71JupnJ; Wed, 27 Jul 2011 04:11:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF5521F8784; Wed, 27 Jul 2011 04:11:15 -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: 3.56 Message-ID: <20110727111115.18207.9131.idtracker@ietfa.amsl.com> Date: Wed, 27 Jul 2011 04:11:15 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-radius-ext-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 11:11:16 -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 : RADIUS Extensions for Dual-Stack Lite Author(s) : Roberta Maglione Alain Durand Filename : draft-ietf-softwire-dslite-radius-ext-04.txt Pages : 11 Date : 2011-07-27 Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers which are addressed only with an IPv6 prefix. DS-Lite requires to pre-configure the DS-Lite Address Family Transition Router tunnel information on the Basic Bridging BroadBand element. In many networks, the customer profile information may be stored in AAA servers while client configurations are mainly provided through DHC protocol. This document specifies a new RADIUS attribute to carry Dual-Stack Lite Address Family Transition Router Tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS Server and the NAS, it is not intended to be used directly between the B4 element and the RADIUS Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-radius-ext-0= 4.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-dslite-radius-ext-04= .txt From jari.arkko@piuha.net Wed Jul 27 05:09:09 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD36D21F8B3C for ; Wed, 27 Jul 2011 05:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUziZOf7IjkC for ; Wed, 27 Jul 2011 05:09:09 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3462021F8B66 for ; Wed, 27 Jul 2011 05:09:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AF8012CEFF; Wed, 27 Jul 2011 15:09:01 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HEPO9vcRWTN; Wed, 27 Jul 2011 15:09:01 +0300 (EEST) Received: from [IPv6:::1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 5501A2CC4B; Wed, 27 Jul 2011 15:09:00 +0300 (EEST) Message-ID: <4E2FFFDB.3000301@piuha.net> Date: Wed, 27 Jul 2011 08:08:59 -0400 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Softwires-wg Subject: Re: [Softwires] review of draft-operators-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, 27 Jul 2011 12:09:09 -0000 Rémi, >> I want to eacho Satoru's comment that this draft wasn't intended to >> compare stateless and stateful transition mechanisms. This draft only >> describes the motivations. >> And I don't want a full blown comparison either, but if the argument is that we need to do this because is better/cheaper/more efficient than something else, I think we do need to explain the main differences to that something else (positive and negative). Jari P.S. I hope you'll have a productive discussion about this today, but unfortunately I'm presenting in another working group so I can't be at the SOFTWIRE meeting. From wdec.ietf@gmail.com Wed Jul 27 07:02:55 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B374A21F86A1 for ; Wed, 27 Jul 2011 07:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnWJVynIR+2v for ; Wed, 27 Jul 2011 07:02:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9193D21F86BE for ; Wed, 27 Jul 2011 07:02:54 -0700 (PDT) Received: by qwc23 with SMTP id 23so1081447qwc.31 for ; Wed, 27 Jul 2011 07:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+razU4Qpi1xTgX4FgnzbzkgH7yJ8GLzjN2E5OEKkBzI=; b=Na0KMdW6akKrJGZESOwZbRF4XLEtKUMOWu1gpGxjRs/5YRnZrA937vTx8j8tsxVTLF 8AthzxhOGKssLqgFWX2qQg9NNPPSU2JGLp4zQZ1ujFzCPryMMC8b/aX0Jb8rNEWMVDZU ic9VNrgvz6ZKe4aKYtj7KkHvCEeUm7uMwAplo= MIME-Version: 1.0 Received: by 10.142.173.8 with SMTP id v8mr58632wfe.60.1311775371920; Wed, 27 Jul 2011 07:02:51 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Wed, 27 Jul 2011 07:02:51 -0700 (PDT) In-Reply-To: <196666F4-FF0F-401E-81DD-35E84FD50B83@laposte.net> References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <196666F4-FF0F-401E-81DD-35E84FD50B83@laposte.net> Date: Wed, 27 Jul 2011 16:02:51 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=000e0cd2e33e11864304a90d81b5 Cc: Softwires-wg , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:02:55 -0000 --000e0cd2e33e11864304a90d81b5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27 July 2011 09:17, R=E9mi Despr=E9s wrote: > Rajiv, > > As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2, > 3GPP has introduced the IPv4v6 bearer. > With it, mobile nodes exchange packets natively in bot IPv4 and IPv6. > This saves 20 octets per IPv4 packet compared to a translation that > replaces an IPv4 header by an IPv6 header. > Sure, but it's fair to say that in the context of a (any) 4V6 solution (the= y run on IPv6, not IPv4), the native v4 leg/bearer/capability/pdp type isn't used or needed. As such this aspect looks orthogonal to the 4v6 overhead discussion... Regards, Wojciech. > > Regards, > RD > > > Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit : > > > Remi, > > > >> Note also that, in 3GPP where power consumption is important, the IPv4= v6 > >> bearer option completely avoids the IPv6 header overhead (no need for > 4V6). > > > > Don't follow this. Could you please expand? > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n > Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Tuesday, July 26, 2011 10:47 AM > >> To: Wojciech Dec > >> Cc: Softwires-wg; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E > >> > >> Well, I made my point (with one more comment below, at the end). > >> Up to WG contributors, and to operators, to appreciate what is really > >> important to them. > >> > >> Note also that, in 3GPP where power consumption is important, the IPv4= v6 > >> bearer option completely avoids the IPv6 header overhead (no need for > 4V6). > >> > >> In wifi, I am still convinced that the impact on power consumption of > +6O vs > >> +40 octets per IPv4 packet will remain negligible in real life, > especially as > >> IPv6 will become the majority. > >> > >> The impact of translation on e2e transparency will be discussed in > another > >> email. > >> > >> RD > >> > >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : > >> > >>> Remi, > >>> > >>> On 25 July 2011 11:59, R=E9mi Despr=E9s wr= ote: > >>>> > >>>> Wojciech, > >>>> > >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK too > much > >> in favor of translation (4v6T) vs encapsulation (4V6E). > >>>> > >>>> The draft has: > >>>> +------------------------+--------------------+---------------------= + > >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | > >>>> | | mode | Mode = | > >>>> +------------------------+-------- ... -------+---------------------= + > >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | ------------------ = | > >>>> > >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring possib= le > IPv4 > >> options): > >>>> - 4V6T adds 20 B (3.5 %). > >>>> - 4V6E adds 40 B, (7.0 %). > >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) > >>>> - Translation adds 20/1420 =3D 1,4 % > >>>> - Encapsulation adds 40/1420 =3D 2,8 % > >>>> > >>>> This gives: > >>>> | ------------------ | ------------------ | ------------------ = | > >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | ------------------ = | > >>> > >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 > >>> transport. It thus seemed fair to measure and compare the overhead as > >>> relative to IPv6 encapsulation, and not IPv4, since there is no way t= o > >>> send an IPv4-only packet, and the useful data is the Layer4+ payload. > >>> Doing it your way you show mixes the basic IPv6 overhead. In any case= , > >>> subtract the left column from the right and one arrives at the figure > >>> at pretty much the figures in the original table. > >>> > >>>> > >>>> In addition, a complete comparison should take in consideration the > length > >> of layer-2 headers, as well as that of the physical preambles if any. > This > >> leads to even less different overhead ratios. > >>> > >>> With the relative consideration, this actually doesn't matter... And > >>> we can choose to ignore the detail of specific radio link protocols > >>> that can segment longer packets into many many more. > >> > >> Different view here. > >> The _ratio_ of power-consumption increase, if n bytes are added to eac= h > >> packet, does depend on the total length of packets (with their headers > of all > >> layers, including link and physiscal). > >> > >> > >>> > >>> -Woj. > >> > >> > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > > --000e0cd2e33e11864304a90d81b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 27 July 2011 09:17, R=E9mi Despr=E9s = <despres.r= emi@laposte.net> wrote:
Rajiv,

As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2, 3G= PP has introduced the IPv4v6 bearer.
With it, mobile nodes exchange packets natively in bot IPv4 and IPv6.
This saves 20 octets per IPv4 packet compared to a translation that replace= s an IPv4 header by an IPv6 header.

Sure, but it&#= 39;s fair to say that in the context of a (any) 4V6 solution (they run on I= Pv6, not IPv4), the native v4 leg/bearer/capability/pdp type isn't used= or needed. As such this aspect looks=A0 orthogonal to the 4v6 overhead dis= cussion...

Regards,
Wojciech.

Regards,
RD


Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit :

> Remi,
>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>
> Don't follow this. Could you please expand?
>
> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: softwires-boun= ces@ietf.org [mailto:soft= wires-bounces@ietf.org] On Behalf
>> Of R=E9mi Despr=E9s
>> Sent: Tuesday, July 26, 2011 10:47 AM
>> To: Wojciech Dec
>> Cc: Softwires-wg; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E
>>
>> Well, I made my point (with one more comment below, at the end). >> Up to WG contributors, and to operators, to appreciate what is rea= lly
>> important to them.
>>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>>
>> In wifi, I am still convinced that the impact on power consumption= of +6O vs
>> +40 octets per IPv4 packet will remain negligible in real life, es= pecially as
>> IPv6 will become the majority.
>>
>> The impact of translation on e2e transparency will be discussed in= another
>> email.
>>
>> RD
>>
>> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit :
>>
>>> Remi,
>>>
>>> On 25 July 2011 11:59, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>>>
>>>> Wojciech,
>>>>
>>>> IPv4-header computations of draft-dec-stateless-4v6-02 are= AFAIK too much
>> in favor of translation (4v6T) vs encapsulation (4V6E).
>>>>
>>>> The draft has:
>>>> +------------------------+--------------------+-----------= ----------+
>>>> | Item =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 4V6 Translati= on =A0 =A0| 4V6 Mapped Tunnel =A0 |
>>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| mode = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mode =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>>> +------------------------+-------- ... -------+-----------= ----------+
>>>> | Overhead in relation =A0 | a) 0% b) 0% =A0 =A0 =A0 =A0| = a) 4.36% b) 1.71% =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>>
>>>> An IPv4 packet having a 550 B payload is 570 B long (ignor= ing possible IPv4
>> options):
>>>> - 4V6T adds 20 B (3.5 %).
>>>> - 4V6E adds 40 B, (7.0 %).
>>>> An IPv4 packet having a 1400 B payload is 1420 B long (at = least)
>>>> - Translation adds 20/1420 =3D 1,4 %
>>>> - Encapsulation adds 40/1420 =3D 2,8 %
>>>>
>>>> This gives:
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>> | Overhead in relation =A0 | a) 3.5% b) 1.4% =A0 =A0| a) 7= % b) 2.8% =A0 =A0 =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>
>>> Sure. However, 4V6, as per Figure 1 in the draft is based on I= Pv6
>>> transport. It thus seemed fair to measure and compare the over= head as
>>> relative to IPv6 encapsulation, and not IPv4, since there is n= o way to
>>> send an IPv4-only packet, and the useful data is the Layer4+ p= ayload.
>>> Doing it your way you show mixes the basic IPv6 overhead. In a= ny case,
>>> subtract the left column from the right and one arrives at the= figure
>>> at pretty much the figures in the original table.
>>>
>>>>
>>>> In addition, a complete comparison should take in consider= ation the length
>> of layer-2 headers, as well as that of the physical preambles if a= ny. This
>> leads to even less different overhead ratios.
>>>
>>> With the relative consideration, this actually doesn't mat= ter... And
>>> we can choose to ignore the detail of specific radio link prot= ocols
>>> that can segment longer packets into many many more.
>>
>> Different view here.
>> The _ratio_ of power-consumption increase, if n bytes are added to= each
>> packet, does depend on the total length of packets (with their hea= ders of all
>> layers, including link and physiscal).
>>
>>
>>>
>>> -Woj.
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires


--000e0cd2e33e11864304a90d81b5-- From xing@cernet.edu.cn Wed Jul 27 07:16:41 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D77C5E801A for ; Wed, 27 Jul 2011 07:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.678 X-Spam-Level: X-Spam-Status: No, score=-99.678 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt-huPIiHK4i for ; Wed, 27 Jul 2011 07:16:38 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id E40D15E800C for ; Wed, 27 Jul 2011 07:16:37 -0700 (PDT) Received: from [127.0.0.1]([130.129.19.192]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jmb4e305b6a; Wed, 27 Jul 2011 22:16:33 +0800 Message-ID: <4E301DBC.8060104@cernet.edu.cn> Date: Wed, 27 Jul 2011 22:16:28 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <9B93871C-C40A-4999-918C-3A7EE88F6AAD@laposte.net> In-Reply-To: <9B93871C-C40A-4999-918C-3A7EE88F6AAD@laposte.net> Content-Type: multipart/alternative; boundary="------------090601040000050301090001" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cJ7uEm0B Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Transparency limitations of 4V6 Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:16:41 -0000 This is a multi-part message in MIME format. --------------090601040000050301090001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Rémi, Comments inline. ? 2011/7/26 22:53, Rémi Després ??: > Hi, all, > > Wojciech's draft-dec-stateless-4v6-02 is overall very good IMHO, and deserves to soon become a WG. However, concerning differences between translation-based and encapsulation-based solutions (4V6T and 4V6E respectively), it can and should be more complete. > > Concerning the relationship of 4V6T and 4V6E with e2e transparency, I noted the following points. > > 1. IPV4 OPTIONS > > The draft has: > > (4V6T) (4V6E) > | ------------------ | ------------------ | ------------------ | > | Supports IPv4 Header | Yes - limited as | Yes, except source | > | Options | per NAT64 | route option | > | | [RFC6145] | | > | ------------------ | ------------------ | ------------------ | > > > Suggested clarification: > (4V6T) (4V6E) > | ------------------ | ------------------ | ------------------ | > | Supports IPv4 Header | No - limited per | Yes | > | Options | SIIT [RFC6145] | | > | ------------------ | ------------------ | ------------------ | > > Justification: > - RFC 6145 says in sec. 1.2: "the translating function specified in this document does not translate any IPv4 options" > - Traversal of a 4V6E domain is treated as a single IPv4 link traversal. This, AFAIK, doesn't restrict IPv4 options that traverse the link. > (1) RFC6145 does not support IPv4 header options. (2) The name "SIIT" is not used in RFC6145, it should refer as "statless NAT64". (3) When tunnel is treated as a single link, all hops inside the tunnel are hidden, therefore "except source route option" is still true in this sense. > 2. UDP NULL CHECKSUM > > RFC 6145 sec. 1.2 says: "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant use in the Internet, and in general will not be translated by the IP/ICMP translator. However, when the translator is configured to forward the packet without a UDP checksum, the fragmented IPv4 UDP packets will be translated." > > Suggested presentation: > (4V6T) (4V6E) > | ------------------ | ------------------ | ------------------ | > | Transparency to UDP | TBD - No with full | Yes | > | null checksums | [RFC6145] | | > | ------------------ | ------------------ | ------------------ | > (1) Dual stateless translation is not "Transparency to UDP null checksums" by default. However, as stated in RFC6145, "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant in the Internet". (2) It can be configured to forward the packet without a UDP checksum. > 3. DONT FRAGMENT BIT > > RFC 6145 says in sec. 4: "When the IPv4 sender does not set the DF bit, the translator SHOULD always include an IPv6 Fragment Header to indicate that the sender allows fragmentation. The translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets." > > Suggested presentation: > (4V6T) (4V6E) > | ------------------ | ------------------ | ------------------ | > | Transparency to DF bit | TBD - No with full | Yes | > | | [RFC6145] | | > | ------------------ | ------------------ | ------------------ | > > (1) In general, RFC6145 is "Transparency to DF bit". The exception is defined by "MAY" cited above. (2) The tunnel has its own issues when dealing with fragmentation. See Section "5.3. Fragmentation and Reassembly" and "6.3. Fragmentation and Reassembly" of http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-11.txt > 4. TOS > > RFC 6145 says in sec. 4.1: "An implementation of a translator SHOULD provide the ability to ignore the IPv6 traffic class and always set the IPv4 TOS Octet to a specified value." > > This opens the door to losses of TOS values across 4V6T domains. > In 4V6E the original TOS is always preserved. > > Suggested presentation: > > (4V6T) (4V6E) > | ------------------ | ------------------ | ------------------ | > | Transparency to IPv4 | TBD - No with full | Yes | > | TOS | [RFC6145] | | > | ------------------ | ------------------ | ------------------ | > > In general, RFC6145 is "Transparency to IPv4 TOS". The exception is defined by "SHOULD provide the ability to ignore the IPv6 traffic class" cited above. > All the above points happen to be favorable to 4V6E, but this is not because of a religion about it. > It is just because encapsulations inherently preserve e2e transparency, which itself simplifies architectural properties and facilitates qualification tests of deployed solutions. > In summary, the dual stateless translator can be configured to have "Yes" to (2), (3), (4). The only "No" is (1). > Cheers, > RD > > Regards, xing > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --------------090601040000050301090001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Rémi,

Comments inline.

于 2011/7/26 22:53, Rémi Després 写道: 
Hi, all,

Wojciech's draft-dec-stateless-4v6-02 is overall very good IMHO, and deserves to soon become a WG. However, concerning differences between translation-based and encapsulation-based solutions (4V6T and 4V6E respectively), it can and should be more complete. 

Concerning the relationship of 4V6T and 4V6E with e2e transparency, I noted the following points.

1. IPV4 OPTIONS

The draft has: 

                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Supports IPv4 Header   | Yes - limited as   | Yes, except source  |
| Options                | per NAT64          | route option        |
|                        | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |


Suggested clarification:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Supports IPv4 Header   | No - limited per   | Yes                 |
| Options                | SIIT  [RFC6145]    |                     |
| ------------------     | ------------------ | ------------------  |

Justification:
- RFC 6145 says in sec. 1.2: "the translating function specified in this document does not translate any IPv4 options"
- Traversal of a 4V6E domain is treated as a single IPv4 link traversal. This, AFAIK, doesn't restrict IPv4 options that traverse the link.
(1) RFC6145 does not support IPv4 header options.
(2) The name "SIIT" is not used in RFC6145, it should refer as "statless NAT64".
(3) When tunnel is treated as a single link, all hops inside the tunnel are hidden, therefore "except source route option" is still true in this sense. 
2. UDP NULL CHECKSUM

RFC 6145 sec. 1.2 says: "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant use in the Internet, and in general will not be translated by the IP/ICMP translator.  However, when the translator is configured to forward the packet without a UDP checksum, the fragmented IPv4 UDP packets will be translated."

Suggested presentation:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to UDP    | TBD - No with full | Yes                 |
| null checksums         | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |
(1) Dual stateless translation is not "Transparency to UDP null checksums" by default. However, as stated in RFC6145, "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant in the Internet".
(2) It can be configured to forward the packet without a UDP checksum. 
3. DONT FRAGMENT BIT

RFC 6145 says in sec. 4: "When the IPv4 sender does not set the DF bit, the translator SHOULD always include an IPv6 Fragment Header to indicate that the sender allows fragmentation.  The translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets."

Suggested presentation:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to DF bit | TBD - No with full | Yes                 |
|                        | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |
(1) In general, RFC6145 is "Transparency to DF bit". The exception is defined by "MAY" cited above.
(2) The tunnel has its own issues when dealing with fragmentation. See Section "5.3. Fragmentation and Reassembly" and "6.3. Fragmentation and Reassembly" of http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-11.txt 

4. TOS

RFC 6145 says in sec. 4.1: "An implementation of a translator SHOULD provide the ability to ignore the IPv6 traffic class and always set the IPv4 TOS Octet to a specified value."

This opens the door to losses of TOS values across 4V6T domains.
In 4V6E the original TOS is always preserved.

Suggested presentation:

                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to IPv4   | TBD - No with full | Yes                 |
| TOS                    | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |
In general, RFC6145 is "Transparency to IPv4 TOS". The exception is defined by "SHOULD provide the ability to ignore the IPv6 traffic class" cited above.

 
All the above points happen to be favorable to 4V6E, but this is not because of a religion about it.
It is just because encapsulations inherently preserve e2e transparency, which itself simplifies architectural properties and facilitates qualification tests of deployed solutions.
In summary, the dual stateless translator can be configured to have "Yes" to (2), (3), (4). The only "No" is (1). 
Cheers,
RD

Regards,

xing


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

--------------090601040000050301090001-- From despres.remi@laposte.net Wed Jul 27 08:47:38 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042F211E8099 for ; Wed, 27 Jul 2011 08:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CICnFIsOjf5C for ; Wed, 27 Jul 2011 08:47:37 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id A367D11E8071 for ; Wed, 27 Jul 2011 08:47:36 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 7753F700008A; Wed, 27 Jul 2011 17:47:35 +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 05D6D700008D; Wed, 27 Jul 2011 17:47:30 +0200 (CEST) X-SFR-UUID: 20110727154731240.05D6D700008D@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-614485087 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 27 Jul 2011 17:47:30 +0200 Message-Id: <8CDE1D62-924B-401F-AA62-569D44D4C13C@laposte.net> References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <196666F4-FF0F-401E-81DD-35E84FD50B83@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:47:38 -0000 --Apple-Mail-1-614485087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 27 juil. 2011 =E0 16:02, Wojciech Dec a =E9crit : >=20 >=20 > On 27 July 2011 09:17, R=E9mi Despr=E9s = wrote: > Rajiv, >=20 > As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. = 6.2, 3GPP has introduced the IPv4v6 bearer. > With it, mobile nodes exchange packets natively in bot IPv4 and IPv6. > This saves 20 octets per IPv4 packet compared to a translation that = replaces an IPv4 header by an IPv6 header. >=20 > Sure, but it's fair to say that in the context of a (any) 4V6 solution = (they run on IPv6, not IPv4), the native v4 leg/bearer/capability/pdp = type isn't used or needed. As such this aspect looks orthogonal to the = 4v6 overhead discussion... The question that remains is "why does one need a translation" if: - There already exists a solution for native IPv6 AND IPv4 (the IPv4v6 = bearer) - This solution consumes less energy than both translation and = encapsulation. Note that, for stateless address sharing, the 4rd address mapping can be = directly combined with the IPv4v6 bearer. Cheers, RD=20 >=20 > Regards, > Wojciech. >=20 > Regards, > RD >=20 >=20 > Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit : >=20 > > Remi, > > > >> Note also that, in 3GPP where power consumption is important, the = IPv4v6 > >> bearer option completely avoids the IPv6 header overhead (no need = for 4V6). > > > > Don't follow this. Could you please expand? > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] On Behalf > >> Of R=E9mi Despr=E9s > >> Sent: Tuesday, July 26, 2011 10:47 AM > >> To: Wojciech Dec > >> Cc: Softwires-wg; Wojciech Dec (wdec) > >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E > >> > >> Well, I made my point (with one more comment below, at the end). > >> Up to WG contributors, and to operators, to appreciate what is = really > >> important to them. > >> > >> Note also that, in 3GPP where power consumption is important, the = IPv4v6 > >> bearer option completely avoids the IPv6 header overhead (no need = for 4V6). > >> > >> In wifi, I am still convinced that the impact on power consumption = of +6O vs > >> +40 octets per IPv4 packet will remain negligible in real life, = especially as > >> IPv6 will become the majority. > >> > >> The impact of translation on e2e transparency will be discussed in = another > >> email. > >> > >> RD > >> > >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : > >> > >>> Remi, > >>> > >>> On 25 July 2011 11:59, R=E9mi Despr=E9s = wrote: > >>>> > >>>> Wojciech, > >>>> > >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK = too much > >> in favor of translation (4v6T) vs encapsulation (4V6E). > >>>> > >>>> The draft has: > >>>> = +------------------------+--------------------+---------------------+ > >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | > >>>> | | mode | Mode = | > >>>> +------------------------+-------- ... = -------+---------------------+ > >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | = ------------------ | > >>>> > >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring = possible IPv4 > >> options): > >>>> - 4V6T adds 20 B (3.5 %). > >>>> - 4V6E adds 40 B, (7.0 %). > >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) > >>>> - Translation adds 20/1420 =3D 1,4 % > >>>> - Encapsulation adds 40/1420 =3D 2,8 % > >>>> > >>>> This gives: > >>>> | ------------------ | ------------------ | = ------------------ | > >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | > >>>> | to average payload of | | = | > >>>> | a) ~550 bytes b) 1400 | | = | > >>>> | bytes). | | = | > >>>> | ------------------ | ------------------ | = ------------------ | > >>> > >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 > >>> transport. It thus seemed fair to measure and compare the overhead = as > >>> relative to IPv6 encapsulation, and not IPv4, since there is no = way to > >>> send an IPv4-only packet, and the useful data is the Layer4+ = payload. > >>> Doing it your way you show mixes the basic IPv6 overhead. In any = case, > >>> subtract the left column from the right and one arrives at the = figure > >>> at pretty much the figures in the original table. > >>> > >>>> > >>>> In addition, a complete comparison should take in consideration = the length > >> of layer-2 headers, as well as that of the physical preambles if = any. This > >> leads to even less different overhead ratios. > >>> > >>> With the relative consideration, this actually doesn't matter... = And > >>> we can choose to ignore the detail of specific radio link = protocols > >>> that can segment longer packets into many many more. > >> > >> Different view here. > >> The _ratio_ of power-consumption increase, if n bytes are added to = each > >> packet, does depend on the total length of packets (with their = headers of all > >> layers, including link and physiscal). > >> > >> > >>> > >>> -Woj. > >> > >> > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-1-614485087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On 27 July 2011 09:17, = R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:
Rajiv,

As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2, = 3GPP has introduced the IPv4v6 bearer.
With it, mobile nodes exchange packets natively in bot IPv4 and = IPv6.
This saves 20 octets per IPv4 packet compared to a translation that = replaces an IPv4 header by an IPv6 = header.

Sure, but it's fair to say that in the = context of a (any) 4V6 solution (they run on IPv6, not IPv4), the native = v4 leg/bearer/capability/pdp type isn't used or needed. As such this = aspect looks  orthogonal to the 4v6 overhead = discussion...

The question = that remains is "why does one need a translation" if:
- There = already exists a solution for native IPv6 AND IPv4 (the IPv4v6 = bearer)
- This solution consumes less energy than both = translation and encapsulation.

Note that, for = stateless address sharing, the 4rd address mapping can be directly = combined with the IPv4v6 = bearer.

Cheers,
RD 

=




Regards,
Wojciech.

Regards,
RD


Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit :

> Remi,
>
>> Note also that, in 3GPP where power consumption is important, = the IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no = need for 4V6).
>
> Don't follow this. Could you please expand?
>
> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org]= On Behalf
>> Of R=E9mi Despr=E9s
>> Sent: Tuesday, July 26, 2011 10:47 AM
>> To: Wojciech Dec
>> Cc: Softwires-wg; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E
>>
>> Well, I made my point (with one more comment below, at the = end).
>> Up to WG contributors, and to operators, to appreciate what is = really
>> important to them.
>>
>> Note also that, in 3GPP where power consumption is important, = the IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no = need for 4V6).
>>
>> In wifi, I am still convinced that the impact on power = consumption of +6O vs
>> +40 octets per IPv4 packet will remain negligible in real life, = especially as
>> IPv6 will become the majority.
>>
>> The impact of translation on e2e transparency will be discussed = in another
>> email.
>>
>> RD
>>
>> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit :
>>
>>> Remi,
>>>
>>> On 25 July 2011 11:59, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
>>>>
>>>> Wojciech,
>>>>
>>>> IPv4-header computations of draft-dec-stateless-4v6-02 = are AFAIK too much
>> in favor of translation (4v6T) vs encapsulation (4V6E).
>>>>
>>>> The draft has:
>>>> = +------------------------+--------------------+---------------------+
>>>> | Item               =     | 4V6 Translation    | 4V6 Mapped Tunnel   = |
>>>> |               =          | mode         =       | Mode             =    |
>>>> +------------------------+-------- ... = -------+---------------------+
>>>> | Overhead in relation   | a) 0% b) 0%   =      | a) 4.36% b) 1.71%   |
>>>> | to average payload of  |       =              |       =               |
>>>> | a) ~550 bytes b) 1400  |       =              |       =               |
>>>> | bytes).             =    |                 =    |                 =     |
>>>> | ------------------     | ------------------ = | ------------------  |
>>>>
>>>> An IPv4 packet having a 550 B payload is 570 B long = (ignoring possible IPv4
>> options):
>>>> - 4V6T adds 20 B (3.5 %).
>>>> - 4V6E adds 40 B, (7.0 %).
>>>> An IPv4 packet having a 1400 B payload is 1420 B long = (at least)
>>>> - Translation adds 20/1420 =3D 1,4 %
>>>> - Encapsulation adds 40/1420 =3D 2,8 %
>>>>
>>>> This gives:
>>>> | ------------------     | ------------------ = | ------------------  |
>>>> | Overhead in relation   | a) 3.5% b) 1.4%   =  | a) 7% b) 2.8%       |
>>>> | to average payload of  |       =              |       =               |
>>>> | a) ~550 bytes b) 1400  |       =              |       =               |
>>>> | bytes).             =    |                 =    |                 =     |
>>>> | ------------------     | ------------------ = | ------------------  |
>>>
>>> Sure. However, 4V6, as per Figure 1 in the draft is based = on IPv6
>>> transport. It thus seemed fair to measure and compare the = overhead as
>>> relative to IPv6 encapsulation, and not IPv4, since there = is no way to
>>> send an IPv4-only packet, and the useful data is the = Layer4+ payload.
>>> Doing it your way you show mixes the basic IPv6 overhead. = In any case,
>>> subtract the left column from the right and one arrives at = the figure
>>> at pretty much the figures in the original table.
>>>
>>>>
>>>> In addition, a complete comparison should take in = consideration the length
>> of layer-2 headers, as well as that of the physical preambles = if any. This
>> leads to even less different overhead ratios.
>>>
>>> With the relative consideration, this actually doesn't = matter... And
>>> we can choose to ignore the detail of specific radio link = protocols
>>> that can segment longer packets into many many more.
>>
>> Different view here.
>> The _ratio_ of power-consumption increase, if n bytes are added = to each
>> packet, does depend on the total length of packets (with their = headers of all
>> layers, including link and physiscal).
>>
>>
>>>
>>> -Woj.
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires



= --Apple-Mail-1-614485087-- From despres.remi@laposte.net Wed Jul 27 09:30:34 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A84A21F84DF for ; Wed, 27 Jul 2011 09:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DryBfLSDBK5 for ; Wed, 27 Jul 2011 09:30:33 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id A715521F847D for ; Wed, 27 Jul 2011 09:30:32 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id 50C9B7000091; Wed, 27 Jul 2011 18:30:31 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2301.sfr.fr (SMTP Server) with ESMTP id A0BC47000089; Wed, 27 Jul 2011 18:30:30 +0200 (CEST) X-SFR-UUID: 20110727163030658.A0BC47000089@msfrf2301.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-617064628 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4E301DBC.8060104@cernet.edu.cn> Date: Wed, 27 Jul 2011 18:30:29 +0200 Message-Id: <28607E67-0383-4AB3-BA17-7ABE55793A06@laposte.net> References: <9B93871C-C40A-4999-918C-3A7EE88F6AAD@laposte.net> <4E301DBC.8060104@cernet.edu.cn> To: Xing Li X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Transparency limitations of 4V6 Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 16:30:34 -0000 --Apple-Mail-2-617064628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 27 juil. 2011 =C3=A0 16:16, Xing Li a =C3=A9crit : > Hi, R=C3=A9mi, >=20 > Comments inline. >=20 > =E4=BA=8E 2011/7/26 22:53, R=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93: >>=20 >> Hi, all, >>=20 >> Wojciech's draft-dec-stateless-4v6-02 is overall very good IMHO, and = deserves to soon become a WG. However, concerning differences between = translation-based and encapsulation-based solutions (4V6T and 4V6E = respectively), it can and should be more complete.=20 >>=20 >> Concerning the relationship of 4V6T and 4V6E with e2e transparency, I = noted the following points. >>=20 >> 1. IPV4 OPTIONS >>=20 >> The draft has:=20 >>=20 >> (4V6T) (4V6E) >> | ------------------ | ------------------ | ------------------ | >> | Supports IPv4 Header | Yes - limited as | Yes, except source | >> | Options | per NAT64 | route option | >> | | [RFC6145] | | >> | ------------------ | ------------------ | ------------------ | >>=20 >>=20 >> Suggested clarification: >> (4V6T) (4V6E) >> | ------------------ | ------------------ | ------------------ | >> | Supports IPv4 Header | No - limited per | Yes | >> | Options | SIIT [RFC6145] | | >> | ------------------ | ------------------ | ------------------ | >>=20 >> Justification: >> - RFC 6145 says in sec. 1.2: "the translating function specified in = this document does not translate any IPv4 options" >> - Traversal of a 4V6E domain is treated as a single IPv4 link = traversal. This, AFAIK, doesn't restrict IPv4 options that traverse the = link. >>=20 > (1) RFC6145 does not support IPv4 header options.=20 Exactly. That's the point. > (2) The name "SIIT" is not used in RFC6145, it should refer as = "statless NAT64".=20 Well, as the draft doesn't specify an acronym and describes an algorithm = for "Stateless IP/ICMP Translation", I felt authorized. Sorry for that. One could say just "limited per RFC6145" or "limited per Stateless NAT64 = [RFC6145]". Thanks=20 > (3) When tunnel is treated as a single link, all hops inside the = tunnel are hidden, therefore "except source route option" is still true = in this sense. I agree that just "yes" may be too short. One could say something like "Yes, (domain traversal treated as on = hop)". Thanks >> 2. UDP NULL CHECKSUM >>=20 >> RFC 6145 sec. 1.2 says: "Fragmented IPv4 UDP packets that do not = contain a UDP checksum (i.e., the UDP checksum field is zero) are not of = significant use in the Internet, and in general will not be translated = by the IP/ICMP translator. However, when the translator is configured = to forward the packet without a UDP checksum, the fragmented IPv4 UDP = packets will be translated." >>=20 >> Suggested presentation: >> (4V6T) (4V6E) >> | ------------------ | ------------------ | ------------------ | >> | Transparency to UDP | TBD - No with full | Yes | >> | null checksums | [RFC6145] | | >> | ------------------ | ------------------ | ------------------ | >>=20 > (1) Dual stateless translation is not "Transparency to UDP null = checksums" by default. However, as stated in RFC6145, "Fragmented IPv4 = UDP packets that do not contain a UDP checksum (i.e., the UDP checksum = field is zero) are not of significant in the Internet".=20 It remains that some customers may be impacted, even if their number is = believed to be to =20 be insignificant. A note with the sentence you quoted could be added. =20 > (2) It can be configured to forward the packet without a UDP checksum. OK. That's the reason of the TBD. If it becomes a rule for 4V6T, that solves the problem, but it has to be = specified in the solution draft. >> 3. DONT FRAGMENT BIT >>=20 >> RFC 6145 says in sec. 4: "When the IPv4 sender does not set the DF = bit, the translator SHOULD always include an IPv6 Fragment Header to = indicate that the sender allows fragmentation. The translator MAY = provide a configuration function that allows the translator not to = include the Fragment Header for the non-fragmented IPv6 packets." >>=20 >> Suggested presentation: >> (4V6T) (4V6E) >> | ------------------ | ------------------ | ------------------ | >> | Transparency to DF bit | TBD - No with full | Yes | >> | | [RFC6145] | | >> | ------------------ | ------------------ | ------------------ | >>=20 >>=20 > (1) In general, RFC6145 is "Transparency to DF bit". The exception is = defined by "MAY" cited above.=20 OK. That's the reason of the TBD, as above. > (2) The tunnel has its own issues when dealing with fragmentation. See = Section "5.3. Fragmentation and Reassembly" and "6.3. Fragmentation and = Reassembly" of = http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-11.txt=20 >=20 >> 4. TOS >>=20 >> RFC 6145 says in sec. 4.1: "An implementation of a translator SHOULD = provide the ability to ignore the IPv6 traffic class and always set the = IPv4 TOS Octet to a specified value." >>=20 >> This opens the door to losses of TOS values across 4V6T domains. >> In 4V6E the original TOS is always preserved. >>=20 >> Suggested presentation: >>=20 >> (4V6T) (4V6E) >> | ------------------ | ------------------ | ------------------ | >> | Transparency to IPv4 | TBD - No with full | Yes | >> | TOS | [RFC6145] | | >> | ------------------ | ------------------ | ------------------ | >>=20 >>=20 > In general, RFC6145 is "Transparency to IPv4 TOS". The exception is = defined by "SHOULD provide the ability to ignore the IPv6 traffic class" = cited above. First, it should be stated if it is a requirement in the solution draft, = as above. But, in addition, this would make it impossible to have a specific = Traffic Class for tunnels. This is another constraint that should IMHO be mentioned to be complete. >> All the above points happen to be favorable to 4V6E, but this is not = because of a religion about it. >> It is just because encapsulations inherently preserve e2e = transparency, which itself simplifies architectural properties and = facilitates qualification tests of deployed solutions. =20 >>=20 > In summary, the dual stateless translator can be configured to have = "Yes" to (2), (3), (4). The only "No" is (1). Agreed for (2) and (3) (provided the solution draft is completed). Concerning (4) both the solution and the comparison drafts deserve = updates, IMHO. Regards, RD >> Cheers, >> RD >>=20 >>=20 >=20 > Regards, >=20 > xing >=20 >=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >=20 --Apple-Mail-2-617064628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=20 =20
Hi, R=C3=A9mi,

Comments inline.

=E4=BA=8E 2011/7/26 22:53, R=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93: 
Hi, all,

Wojciech's draft-dec-stateless-4v6-02 is overall very good IMHO, and =
deserves to soon become a WG. However, concerning differences between =
translation-based and encapsulation-based solutions (4V6T and 4V6E =
respectively), it can and should be more complete.=20

Concerning the relationship of 4V6T and 4V6E with e2e transparency, I =
noted the following points.

1. IPV4 OPTIONS

The draft has:=20

                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Supports IPv4 Header   | Yes - limited as   | Yes, except source  |
| Options                | per NAT64          | route option        |
|                        | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |


Suggested clarification:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Supports IPv4 Header   | No - limited per   | Yes                 |
| Options                | SIIT  [RFC6145]    |                     |
| ------------------     | ------------------ | ------------------  |

Justification:
- RFC 6145 says in sec. 1.2: "the translating function specified in this =
document does not translate any IPv4 options"
- Traversal of a 4V6E domain is treated as a single IPv4 link traversal. =
This, AFAIK, doesn't restrict IPv4 options that traverse the link.
(1) RFC6145 does not support IPv4 header options. =

Exactly. That's the = point.

(2) The name "SIIT" is not used in RFC6145, it should refer as "statless NAT64". =

Well, as the draft = doesn't specify an acronym and describes an algorithm for "Stateless = IP/ICMP Translation", I felt authorized. Sorry for that.
One = could say just "limited per RFC6145" or "limited per Stateless NAT64 = [RFC6145]".
Thanks 

(3) When tunnel is treated as a single link, all hops inside the tunnel are hidden, therefore "except source route option" is still true in this sense.

I agree that just "yes" may = be too short.
One could say something like "Yes, (domain = traversal treated as on hop)".
Thanks

2. UDP NULL CHECKSUM

RFC 6145 sec. 1.2 says: "Fragmented IPv4 UDP packets that do not contain =
a UDP checksum (i.e., the UDP checksum field is zero) are not of =
significant use in the Internet, and in general will not be translated =
by the IP/ICMP translator.  However, when the translator is configured =
to forward the packet without a UDP checksum, the fragmented IPv4 UDP =
packets will be translated."

Suggested presentation:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to UDP    | TBD - No with full | Yes                 |
| null checksums         | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |
(1) Dual stateless translation is not "Transparency to UDP null checksums" by default. However, as stated in RFC6145, "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant in the Internet". =

It remains that = some customers may be impacted, even if their number is believed to be = to  
be insignificant.
A note with the sentence = you quoted could be added.   

(2) It can be configured to forward the packet without a UDP checksum.

OK.
That's the reason of = the TBD.
If it becomes a rule for 4V6T, that solves the = problem, but it has to be specified in the solution = draft.

3. DONT FRAGMENT BIT

RFC 6145 says in sec. 4: "When the IPv4 sender does not set the DF bit, =
the translator SHOULD always include an IPv6 Fragment Header to indicate =
that the sender allows fragmentation.  The translator MAY provide a =
configuration function that allows the translator not to include the =
Fragment Header for the non-fragmented IPv6 packets."

Suggested presentation:
                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to DF bit | TBD - No with full | Yes                 |
|                        | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |
(1) In general, RFC6145 is "Transparency to DF bit". The exception is defined by "MAY" cited above. =

OK.
That's the reason of the TBD, as = above.


(2) The tunnel has its own issues when dealing with fragmentation. See Section "5.3. Fragmentation and Reassembly" and "6.3. Fragmentation and Reassembly" of http://www.ietf.org/id/draft-ietf-softwire-dual-stack-lite-11.txt 

4. TOS

RFC 6145 says in sec. 4.1: "An implementation of a translator SHOULD =
provide the ability to ignore the IPv6 traffic class and always set the =
IPv4 TOS Octet to a specified value."

This opens the door to losses of TOS values across 4V6T domains.
In 4V6E the original TOS is always preserved.

Suggested presentation:

                                   (4V6T)                (4V6E)
| ------------------     | ------------------ | ------------------  |
| Transparency to IPv4   | TBD - No with full | Yes                 |
| TOS                    | [RFC6145]          |                     |
| ------------------     | ------------------ | ------------------  |
In general, RFC6145 is "Transparency to IPv4 TOS". The exception is defined by "SHOULD provide the ability to ignore the IPv6 traffic class" cited = above.

First, it = should be stated if it is a requirement in the solution draft, as = above.
But, in addition, this would make it impossible to have = a specific Traffic Class for tunnels.
This is another = constraint that should IMHO be mentioned to be = complete.

=20 
All the above points happen to be favorable to =
4V6E, but this is not because of a religion about it.
It is just because encapsulations inherently preserve e2e transparency, =
which itself simplifies architectural properties and facilitates =
qualification tests of deployed solutions. =20
In summary, the dual stateless translator can be configured to have "Yes" to (2), (3), (4). The only "No" is (1).

Agreed for (2) and (3) = (provided the solution draft is completed).
Concerning (4) = both the solution and the comparison drafts deserve updates, = IMHO.

Regards,
RD

Cheers,
RD

Regards,

xing


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


= --Apple-Mail-2-617064628-- From behcetsarikaya@yahoo.com Wed Jul 27 10:20:18 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3F21F8772 for ; Wed, 27 Jul 2011 10:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA-WvY6meQBm for ; Wed, 27 Jul 2011 10:20:17 -0700 (PDT) Received: from nm4-vm0.bullet.mail.sp2.yahoo.com (nm4-vm0.bullet.mail.sp2.yahoo.com [98.139.91.190]) by ietfa.amsl.com (Postfix) with SMTP id A54F521F8760 for ; Wed, 27 Jul 2011 10:20:10 -0700 (PDT) Received: from [98.139.91.62] by nm4.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 17:20:08 -0000 Received: from [98.139.91.30] by tm2.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 17:20:08 -0000 Received: from [127.0.0.1] by omp1030.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 17:20:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 157899.49369.bm@omp1030.mail.sp2.yahoo.com Received: (qmail 5756 invoked by uid 60001); 27 Jul 2011 17:20:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311787202; bh=c29MrnIIwfW1XxUkL7u9ETTNUctHcdHue2M+Dim3VrQ=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=yW8N9mZkqwExrHdDD3Abc8bjkj4gk5hgiiUeFn/zfm/W2bM24uaB6jRcMP1MywdL7XxoqX5jjKewgYJBKuXQYCajkNY4cZTTmGJ1Ir8ytLIZuK5TcKD5z2v+6Z8G3WkoJK6Yeg4r534UJeQJ9eNA0le7Y/ZoVbfKpKZibe7G+6c= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=Cy08Ln7QHr4/TQ7ZauIm8W7pPDewDfmMXB82xbLIp29rB8amnbnXb8ZtykisoSca0lKs+eorJ8D4YnFa5IYNkyP2Y+BssG31c4SAj81B0zAY8Bf1kctdpvCKuxSbEErxmrh+o7VaCrfjhXsJT2bo2OmAZ2MQCqivLiojfrGLZCk=; X-YMail-OSG: KtfDBDMVM1nwUJJHg2OxVRgMwkxINwy3RI5Jok4HpxRRBog vg2ZurCht8WlceeUl7D1oXcKI0JR883eYSJbbl.NJd8cLw.3Orcz6460LhWc czjKHYL5M578oVZvJn6fBJ3U3Rh73aJ_m2dlFnqcvPR8EMiNyXuM0FxKDyAx I18zqy5K6AWuWdMKxe3AUyn1Cr_i05tUXDHe0kavNZJKVsYehMPogXglBdXk kOv40_wZlyag8rIdpuwoQm4G_W5jhUSTQlMllXQq8j3AQddAkRDMH1OT6bjC 4eOFtVnmlXukMUeCMY63LHHMQ0T.lh_bXhPVIRUh9Sscnp37UJzAirAopwyB Or29NwYjZm3Gu7SZ7OijiVcB4L9EQ5.LZSmMdRs0e1CWxAUnU2l8tP7EqB71 GhNyoLYjMnZMYFw-- Received: from [130.129.87.243] by web111403.mail.gq1.yahoo.com via HTTP; Wed, 27 Jul 2011 10:20:01 PDT X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.112.310352 Message-ID: <1311787201.96355.YahooMailRC@web111403.mail.gq1.yahoo.com> Date: Wed, 27 Jul 2011 10:20:01 -0700 (PDT) From: Behcet Sarikaya To: softwires@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Softwires] Requirements on DS-Lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:20:18 -0000 Hi all, In Softwire session this morning someone (I forgot who) raised a concern on Section 6 Solution Based on Layer 2 Multicast Support in draft-sarikaya-softwire-dslitemulticast-00.txt. Yes there are some additional constraints that this solution requires, but I think that we should compare it with any other solutions proposed like draft-qin-softwire-dslite-multicast-04 which requires every CE router or B4 of DS-Lite to have IGMP-MLD translator with all its complications. It is well known fact that CE routers are the most difficult to change entities in fixed networks. How are you going to cope with this compared with a very simple way of having that same capability? Regards, Behcet From yiu_lee@cable.comcast.com Wed Jul 27 11:19:35 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4005A21F8BFF for ; Wed, 27 Jul 2011 11:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.614 X-Spam-Level: X-Spam-Status: No, score=-103.614 tagged_above=-999 required=5 tests=[AWL=-1.880, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00QJC9XYp3Qr for ; Wed, 27 Jul 2011 11:19:34 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 90A3A21F8BFE for ; Wed, 27 Jul 2011 11:19:34 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46406864; Wed, 27 Jul 2011 12:24:15 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 14:19:30 -0400 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: DS-lite Multicast Thread-Index: AQHMTIm5LUBdbbYgxkWSDb2ph5Pq4A== Date: Wed, 27 Jul 2011 18:19:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CA55CEF112B22yiuleecablecomcastcom_" MIME-Version: 1.0 Subject: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 18:19:35 -0000 --_000_CA55CEF112B22yiuleecablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, In today meeting, we presented two drafts on to enable multicast in DS-lite= . I think they target different use cases: The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite-multic= ast-04 is to deliver multicast over DS-lite in an IPv6 multicast enabled ne= twork. The use case of http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemu= lticast-00 is to deliver multicast over DS-lite in an IPv6 multicast disabl= ed network. I think both drafts target different use cases. My question to the WG is: S= hould we work on both use cases? If not, which use case the WG should work = on first? I really want to hear people comments. Please raise your voice in the ML. Thanks, /Yiu --_000_CA55CEF112B22yiuleecablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7F41C3D81A32174DA836AFC61DF128B6@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Hi WG,

In today meeting, we presented two drafts on to enable multicast in DS= -lite. I think they target different use cases:

The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04 = is to deliver multicast over DS-lite in an IPv6 multicast enabled network.<= /div>

The use case of http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-00&n= bsp;is to deliver multicast over DS-lite in an IPv6 multicast disabled netw= ork.

I think both drafts target different use cases. My question to the WG = is: Should we work on both use cases? If not, which use case the WG should = work on first?

I really want to hear people comments. Please raise your voice in the = ML.

Thanks,
/Yiu
  


--_000_CA55CEF112B22yiuleecablecomcastcom_-- From jacniq@gmail.com Wed Jul 27 11:24:07 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4DC11E8101 for ; Wed, 27 Jul 2011 11:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXqqmRMMota9 for ; Wed, 27 Jul 2011 11:24:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C02011E809E for ; Wed, 27 Jul 2011 11:24:05 -0700 (PDT) Received: by vxi40 with SMTP id 40so1718762vxi.31 for ; Wed, 27 Jul 2011 11:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p0QQYL53uoP21qVnG4pzSzRPWOdumM7Cq0ZMvz6RsP4=; b=BR5GiSxwZcmNlViWb3Eon5pxvvWGAV/d4Y78shnOZdOE2EgJdGtwc8gCp7EJdA79F5 bzqKsgPbo8B+YVXyxDMzXAG/8S9DpL8LAL/KN5eHeGr5ABsaQ5A4PSZowl0OcWK3SvX1 kkkd9+DpOGE35NJ6tI9Bdk0Wu+dTrbd3EDk2g= MIME-Version: 1.0 Received: by 10.52.21.163 with SMTP id w3mr112428vde.472.1311791043670; Wed, 27 Jul 2011 11:24:03 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Wed, 27 Jul 2011 11:24:03 -0700 (PDT) In-Reply-To: <1311787201.96355.YahooMailRC@web111403.mail.gq1.yahoo.com> References: <1311787201.96355.YahooMailRC@web111403.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 02:24:03 +0800 Message-ID: From: Jacni Qin To: Behcet Sarikaya Content-Type: multipart/alternative; boundary=20cf307ca3922d71f804a911275d Cc: softwires@ietf.org Subject: Re: [Softwires] Requirements on DS-Lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 18:24:07 -0000 --20cf307ca3922d71f804a911275d Content-Type: text/plain; charset=ISO-8859-1 hi, On Thu, Jul 28, 2011 at 1:20 AM, Behcet Sarikaya wrote: > Hi all, > In Softwire session this morning someone (I forgot who) raised a concern > on > Section 6 > > Solution Based on Layer 2 Multicast Support > > in draft-sarikaya-softwire-dslitemulticast-00.txt. > > Yes there are some additional constraints that this solution requires, but > I > think that we should compare it with any other solutions proposed like > > > draft-qin-softwire-dslite-multicast-04 > > which requires every CE router or B4 of DS-Lite to have IGMP-MLD translator > with > all its complications. > It is well known fact that CE routers are the most difficult to change > entities > in fixed networks. > Jacni>: I wish we could get the IPv6 transition done without changing anything, no matter by DS-Lite or any other means. But it's just a wish. :-) How are you going to cope with this compared with a very simple way of > having > that same capability? > Jacni>: Again, there are different capabilities. Cheers, Jacni > > Regards, > > Behcet > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf307ca3922d71f804a911275d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi,

On Thu, Jul 28, 2011 at 1:20 AM, Behcet Sarikaya <= behcetsarikaya@yahoo.com>= ; wrote:
Hi all,
=A0In Softwire session this morning someone (I forgot who) raised a concer= n on
Section 6

Solution Based on Layer 2 Multicast Support

in draft-sarikaya-softwire-dslitemulticast-00.txt.

Yes there are some additional constraints that this solution requires, but = I
think that we should compare it with any other solutions proposed like


draft-qin-softwire-dslite-multicast-04

which requires every CE router or B4 of DS-Lite to have IGMP-MLD translator= with
all its complications.
It is well known fact that CE routers are the most difficult to change enti= ties
in fixed networks.

Jacni>: I wish we could get the IPv6 transition done without changing= anything, no matter by DS-Lite or any other means. But it's just a wis= h. :-)

How are you going to cope with this compared with a very simple way of havi= ng
that same capability?

Jacni>: Again, there are different capabilities.


Cheers= ,
Jacni

Regards,

Behcet

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

--20cf307ca3922d71f804a911275d-- From wdec.ietf@gmail.com Wed Jul 27 12:00:45 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E318E21F84DE for ; Wed, 27 Jul 2011 12:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvXGxxagwvWl for ; Wed, 27 Jul 2011 12:00:42 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id D496211E8118 for ; Wed, 27 Jul 2011 12:00:38 -0700 (PDT) Received: by yie30 with SMTP id 30so1561633yie.31 for ; Wed, 27 Jul 2011 12:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BgVJcOXg0ivJpUe9n9epuh4BM2SeRSFnAbYkjZM/V9w=; b=wFip5wQKxxUNlrUrehw+mlBnDfm6bUG0rmy9BisNAzrw7wRufOS/Ry+fYFljl9mSIP oM1BZx4jNQl7c+CrexqViebdynAwal3cM9CMiqF3r/+pi8VJv+w9mAKq0atIA7eeM2ws JMqXdK6y5SH/fU+c0khWSA6xPY4t3ed9vh3yA= MIME-Version: 1.0 Received: by 10.142.133.7 with SMTP id g7mr97922wfd.117.1311793237902; Wed, 27 Jul 2011 12:00:37 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Wed, 27 Jul 2011 12:00:37 -0700 (PDT) In-Reply-To: <8CDE1D62-924B-401F-AA62-569D44D4C13C@laposte.net> References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <196666F4-FF0F-401E-81DD-35E84FD50B83@laposte.net> <8CDE1D62-924B-401F-AA62-569D44D4C13C@laposte.net> Date: Wed, 27 Jul 2011 21:00:37 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=000e0cd32f32f6c79404a911a9fd Cc: Softwires-wg , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 19:00:45 -0000 --000e0cd32f32f6c79404a911a9fd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, On 27 July 2011 17:47, R=E9mi Despr=E9s wrote: > > Le 27 juil. 2011 =E0 16:02, Wojciech Dec a =E9crit : > > > > On 27 July 2011 09:17, R=E9mi Despr=E9s wrote: > >> Rajiv, >> >> As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2, >> 3GPP has introduced the IPv4v6 bearer. >> With it, mobile nodes exchange packets natively in bot IPv4 and IPv6. >> This saves 20 octets per IPv4 packet compared to a translation that >> replaces an IPv4 header by an IPv6 header. >> > > Sure, but it's fair to say that in the context of a (any) 4V6 solution > (they run on IPv6, not IPv4), the native v4 leg/bearer/capability/pdp typ= e > isn't used or needed. As such this aspect looks orthogonal to the 4v6 > overhead discussion... > > > The question that remains is "why does one need a translation" if: > - There already exists a solution for native IPv6 AND IPv4 (the IPv4v6 > bearer) > - This solution consumes less energy than both translation and > encapsulation. > Sure, the IPv4v6 bearer is for *plain* IPv4 and IPv6 traffic - it's plain/regular dual stack. By definition, the 4V6 translated or encapsulated solutions would use only the v6 dimension (the v4 dimension not being useful), along with their respective overheads (or lack thereof). > > Note that, for stateless address sharing, the 4rd address mapping can be > directly combined with the IPv4v6 bearer. > Yes, and that applies to *any* 4V6 variant. Regards, -Woj. > > Cheers, > RD > > > > > > Regards, > Wojciech. > >> >> Regards, >> RD >> >> >> Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit : >> >> > Remi, >> > >> >> Note also that, in 3GPP where power consumption is important, the >> IPv4v6 >> >> bearer option completely avoids the IPv6 header overhead (no need for >> 4V6). >> > >> > Don't follow this. Could you please expand? >> > >> > Cheers, >> > Rajiv >> > >> > >> >> -----Original Message----- >> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] >> On Behalf >> >> Of R=E9mi Despr=E9s >> >> Sent: Tuesday, July 26, 2011 10:47 AM >> >> To: Wojciech Dec >> >> Cc: Softwires-wg; Wojciech Dec (wdec) >> >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >> >> >> >> Well, I made my point (with one more comment below, at the end). >> >> Up to WG contributors, and to operators, to appreciate what is really >> >> important to them. >> >> >> >> Note also that, in 3GPP where power consumption is important, the >> IPv4v6 >> >> bearer option completely avoids the IPv6 header overhead (no need for >> 4V6). >> >> >> >> In wifi, I am still convinced that the impact on power consumption of >> +6O vs >> >> +40 octets per IPv4 packet will remain negligible in real life, >> especially as >> >> IPv6 will become the majority. >> >> >> >> The impact of translation on e2e transparency will be discussed in >> another >> >> email. >> >> >> >> RD >> >> >> >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : >> >> >> >>> Remi, >> >>> >> >>> On 25 July 2011 11:59, R=E9mi Despr=E9s w= rote: >> >>>> >> >>>> Wojciech, >> >>>> >> >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK to= o >> much >> >> in favor of translation (4v6T) vs encapsulation (4V6E). >> >>>> >> >>>> The draft has: >> >>>> +------------------------+--------------------+--------------------= -+ >> >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel = | >> >>>> | | mode | Mode = | >> >>>> +------------------------+-------- ... -------+--------------------= -+ >> >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% = | >> >>>> | to average payload of | | = | >> >>>> | a) ~550 bytes b) 1400 | | = | >> >>>> | bytes). | | = | >> >>>> | ------------------ | ------------------ | ------------------ = | >> >>>> >> >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring >> possible IPv4 >> >> options): >> >>>> - 4V6T adds 20 B (3.5 %). >> >>>> - 4V6E adds 40 B, (7.0 %). >> >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >> >>>> - Translation adds 20/1420 =3D 1,4 % >> >>>> - Encapsulation adds 40/1420 =3D 2,8 % >> >>>> >> >>>> This gives: >> >>>> | ------------------ | ------------------ | ------------------ = | >> >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% = | >> >>>> | to average payload of | | = | >> >>>> | a) ~550 bytes b) 1400 | | = | >> >>>> | bytes). | | = | >> >>>> | ------------------ | ------------------ | ------------------ = | >> >>> >> >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >> >>> transport. It thus seemed fair to measure and compare the overhead a= s >> >>> relative to IPv6 encapsulation, and not IPv4, since there is no way = to >> >>> send an IPv4-only packet, and the useful data is the Layer4+ payload= . >> >>> Doing it your way you show mixes the basic IPv6 overhead. In any cas= e, >> >>> subtract the left column from the right and one arrives at the figur= e >> >>> at pretty much the figures in the original table. >> >>> >> >>>> >> >>>> In addition, a complete comparison should take in consideration the >> length >> >> of layer-2 headers, as well as that of the physical preambles if any. >> This >> >> leads to even less different overhead ratios. >> >>> >> >>> With the relative consideration, this actually doesn't matter... And >> >>> we can choose to ignore the detail of specific radio link protocols >> >>> that can segment longer packets into many many more. >> >> >> >> Different view here. >> >> The _ratio_ of power-consumption increase, if n bytes are added to ea= ch >> >> packet, does depend on the total length of packets (with their header= s >> of all >> >> layers, including link and physiscal). >> >> >> >> >> >>> >> >>> -Woj. >> >> >> >> >> >> _______________________________________________ >> >> Softwires mailing list >> >> Softwires@ietf.org >> >> https://www.ietf.org/mailman/listinfo/softwires >> >> > > --000e0cd32f32f6c79404a911a9fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi,

On 27 July 2011 17:47, R=E9mi Despr= =E9s <desp= res.remi@laposte.net> wrote:

Le 27 juil. 2011 =E0 16= :02, Wojciech Dec a =E9crit :



On 27 July 2011 09:17, R=E9mi = Despr=E9s <despres.remi@laposte.net> wrote:
Rajiv,

As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2, 3G= PP has introduced the IPv4v6 bearer.
With it, mobile nodes exchange packets natively in bot IPv4 and IPv6.
This saves 20 octets per IPv4 packet compared to a translation that replace= s an IPv4 header by an IPv6 header.

Sure, but it&#= 39;s fair to say that in the context of a (any) 4V6 solution (they run on I= Pv6, not IPv4), the native v4 leg/bearer/capability/pdp type isn't used= or needed. As such this aspect looks=A0 orthogonal to the 4v6 overhead dis= cussion...

The question that remains is = "why does one need a translation" if:
- There already e= xists a solution for native IPv6 AND IPv4 (the IPv4v6 bearer)
- This solution consumes less energy than both translation and encapsulatio= n.

Sure, the IPv4v6 bearer is for *plain* = IPv4 and IPv6 traffic - it's plain/regular dual stack. By definition, t= he 4V6 translated or encapsulated solutions would use only the v6 dimension= (the v4 dimension not being useful), along with their respective overheads= (or lack thereof).
=A0

Note that, for stateless = address sharing, the 4rd address mapping can be directly combined with the = IPv4v6 bearer.

Yes, and that applies to *any* 4V6 variant.=A0 =

Regards,
-Woj.

=A0

Cheers,
RD=A0





Regards,
Wojciech.

Regards,
RD


Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit :

> Remi,
>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>
> Don't follow this. Could you please expand?
>
> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf >> Of R=E9mi Despr=E9s
>> Sent: Tuesday, July 26, 2011 10:47 AM
>> To: Wojciech Dec
>> Cc: Softwires-wg; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E
>>
>> Well, I made my point (with one more comment below, at the end). >> Up to WG contributors, and to operators, to appreciate what is rea= lly
>> important to them.
>>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>>
>> In wifi, I am still convinced that the impact on power consumption= of +6O vs
>> +40 octets per IPv4 packet will remain negligible in real life, es= pecially as
>> IPv6 will become the majority.
>>
>> The impact of translation on e2e transparency will be discussed in= another
>> email.
>>
>> RD
>>
>> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit :
>>
>>> Remi,
>>>
>>> On 25 July 2011 11:59, R=E9mi Despr=E9s <despres.remi@laposte.net>= ; wrote:
>>>>
>>>> Wojciech,
>>>>
>>>> IPv4-header computations of draft-dec-stateless-4v6-02 are= AFAIK too much
>> in favor of translation (4v6T) vs encapsulation (4V6E).
>>>>
>>>> The draft has:
>>>> +------------------------+--------------------+-----------= ----------+
>>>> | Item =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 4V6 Translati= on =A0 =A0| 4V6 Mapped Tunnel =A0 |
>>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| mode = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mode =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>>> +------------------------+-------- ... -------+-----------= ----------+
>>>> | Overhead in relation =A0 | a) 0% b) 0% =A0 =A0 =A0 =A0| = a) 4.36% b) 1.71% =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>>
>>>> An IPv4 packet having a 550 B payload is 570 B long (ignor= ing possible IPv4
>> options):
>>>> - 4V6T adds 20 B (3.5 %).
>>>> - 4V6E adds 40 B, (7.0 %).
>>>> An IPv4 packet having a 1400 B payload is 1420 B long (at = least)
>>>> - Translation adds 20/1420 =3D 1,4 %
>>>> - Encapsulation adds 40/1420 =3D 2,8 %
>>>>
>>>> This gives:
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>> | Overhead in relation =A0 | a) 3.5% b) 1.4% =A0 =A0| a) 7= % b) 2.8% =A0 =A0 =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>
>>> Sure. However, 4V6, as per Figure 1 in the draft is based on I= Pv6
>>> transport. It thus seemed fair to measure and compare the over= head as
>>> relative to IPv6 encapsulation, and not IPv4, since there is n= o way to
>>> send an IPv4-only packet, and the useful data is the Layer4+ p= ayload.
>>> Doing it your way you show mixes the basic IPv6 overhead. In a= ny case,
>>> subtract the left column from the right and one arrives at the= figure
>>> at pretty much the figures in the original table.
>>>
>>>>
>>>> In addition, a complete comparison should take in consider= ation the length
>> of layer-2 headers, as well as that of the physical preambles if a= ny. This
>> leads to even less different overhead ratios.
>>>
>>> With the relative consideration, this actually doesn't mat= ter... And
>>> we can choose to ignore the detail of specific radio link prot= ocols
>>> that can segment longer packets into many many more.
>>
>> Different view here.
>> The _ratio_ of power-consumption increase, if n bytes are added to= each
>> packet, does depend on the total length of packets (with their hea= ders of all
>> layers, including link and physiscal).
>>
>>
>>>
>>> -Woj.
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@= ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires




--000e0cd32f32f6c79404a911a9fd-- From wdec.ietf@gmail.com Wed Jul 27 12:04:53 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D225E800F for ; Wed, 27 Jul 2011 12:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.363 X-Spam-Level: X-Spam-Status: No, score=-3.363 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEto1xWqjFTp for ; Wed, 27 Jul 2011 12:04:52 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D354F5E800B for ; Wed, 27 Jul 2011 12:04:51 -0700 (PDT) Received: by gxk19 with SMTP id 19so1560503gxk.31 for ; Wed, 27 Jul 2011 12:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EIcTayZ9IN/wMWjoeQXuUM+OkdmnV7wfdBHGTv+/Og4=; b=sy9EMqkQCuhLpxIb9IB2MIBHsczUtoRJFWYkMGG1mv4wayLfXSZq+f0olFD8hZ98jX BNMwmhl7eyHJOqRRmmTX1DK0ql29IosHIzDCfAdtF1VT4mbSA1pu9nL2lOVgcdjIuUxp Mzq2gs3+yGlkLdi8XC2P1err22s78tksehHio= MIME-Version: 1.0 Received: by 10.142.204.9 with SMTP id b9mr101322wfg.3.1311793490819; Wed, 27 Jul 2011 12:04:50 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Wed, 27 Jul 2011 12:04:50 -0700 (PDT) In-Reply-To: References: <067E6CE33034954AAC05C9EC85E2577C0581BB5F@XMB-RCD-111.cisco.com> <196666F4-FF0F-401E-81DD-35E84FD50B83@laposte.net> <8CDE1D62-924B-401F-AA62-569D44D4C13C@laposte.net> Date: Wed, 27 Jul 2011 21:04:50 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=000e0cd1a07a09fd4704a911b97a Cc: Softwires-wg , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 19:04:53 -0000 --000e0cd1a07a09fd4704a911b97a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also note that the same applies to any dual stack access set-up (eg DSL wit= h PPP). On 27 July 2011 21:00, Wojciech Dec wrote: > Remi, > > On 27 July 2011 17:47, R=E9mi Despr=E9s wrote: > >> >> Le 27 juil. 2011 =E0 16:02, Wojciech Dec a =E9crit : >> >> >> >> On 27 July 2011 09:17, R=E9mi Despr=E9s wrote= : >> >>> Rajiv, >>> >>> As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2= , >>> 3GPP has introduced the IPv4v6 bearer. >>> With it, mobile nodes exchange packets natively in bot IPv4 and IPv6. >>> This saves 20 octets per IPv4 packet compared to a translation that >>> replaces an IPv4 header by an IPv6 header. >>> >> >> Sure, but it's fair to say that in the context of a (any) 4V6 solution >> (they run on IPv6, not IPv4), the native v4 leg/bearer/capability/pdp ty= pe >> isn't used or needed. As such this aspect looks orthogonal to the 4v6 >> overhead discussion... >> >> >> The question that remains is "why does one need a translation" if: >> - There already exists a solution for native IPv6 AND IPv4 (the IPv4v6 >> bearer) >> - This solution consumes less energy than both translation and >> encapsulation. >> > > Sure, the IPv4v6 bearer is for *plain* IPv4 and IPv6 traffic - it's > plain/regular dual stack. By definition, the 4V6 translated or encapsulat= ed > solutions would use only the v6 dimension (the v4 dimension not being > useful), along with their respective overheads (or lack thereof). > > >> >> Note that, for stateless address sharing, the 4rd address mapping can be >> directly combined with the IPv4v6 bearer. >> > > Yes, and that applies to *any* 4V6 variant. > > Regards, > -Woj. > > > >> >> Cheers, >> RD >> >> >> >> >> >> Regards, >> Wojciech. >> >>> >>> Regards, >>> RD >>> >>> >>> Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit : >>> >>> > Remi, >>> > >>> >> Note also that, in 3GPP where power consumption is important, the >>> IPv4v6 >>> >> bearer option completely avoids the IPv6 header overhead (no need fo= r >>> 4V6). >>> > >>> > Don't follow this. Could you please expand? >>> > >>> > Cheers, >>> > Rajiv >>> > >>> > >>> >> -----Original Message----- >>> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] >>> On Behalf >>> >> Of R=E9mi Despr=E9s >>> >> Sent: Tuesday, July 26, 2011 10:47 AM >>> >> To: Wojciech Dec >>> >> Cc: Softwires-wg; Wojciech Dec (wdec) >>> >> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E >>> >> >>> >> Well, I made my point (with one more comment below, at the end). >>> >> Up to WG contributors, and to operators, to appreciate what is reall= y >>> >> important to them. >>> >> >>> >> Note also that, in 3GPP where power consumption is important, the >>> IPv4v6 >>> >> bearer option completely avoids the IPv6 header overhead (no need fo= r >>> 4V6). >>> >> >>> >> In wifi, I am still convinced that the impact on power consumption o= f >>> +6O vs >>> >> +40 octets per IPv4 packet will remain negligible in real life, >>> especially as >>> >> IPv6 will become the majority. >>> >> >>> >> The impact of translation on e2e transparency will be discussed in >>> another >>> >> email. >>> >> >>> >> RD >>> >> >>> >> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit : >>> >> >>> >>> Remi, >>> >>> >>> >>> On 25 July 2011 11:59, R=E9mi Despr=E9s >>> wrote: >>> >>>> >>> >>>> Wojciech, >>> >>>> >>> >>>> IPv4-header computations of draft-dec-stateless-4v6-02 are AFAIK t= oo >>> much >>> >> in favor of translation (4v6T) vs encapsulation (4V6E). >>> >>>> >>> >>>> The draft has: >>> >>>> >>> +------------------------+--------------------+---------------------+ >>> >>>> | Item | 4V6 Translation | 4V6 Mapped Tunnel >>> | >>> >>>> | | mode | Mode >>> | >>> >>>> +------------------------+-------- ... >>> -------+---------------------+ >>> >>>> | Overhead in relation | a) 0% b) 0% | a) 4.36% b) 1.71% >>> | >>> >>>> | to average payload of | | >>> | >>> >>>> | a) ~550 bytes b) 1400 | | >>> | >>> >>>> | bytes). | | >>> | >>> >>>> | ------------------ | ------------------ | ------------------ >>> | >>> >>>> >>> >>>> An IPv4 packet having a 550 B payload is 570 B long (ignoring >>> possible IPv4 >>> >> options): >>> >>>> - 4V6T adds 20 B (3.5 %). >>> >>>> - 4V6E adds 40 B, (7.0 %). >>> >>>> An IPv4 packet having a 1400 B payload is 1420 B long (at least) >>> >>>> - Translation adds 20/1420 =3D 1,4 % >>> >>>> - Encapsulation adds 40/1420 =3D 2,8 % >>> >>>> >>> >>>> This gives: >>> >>>> | ------------------ | ------------------ | ------------------ >>> | >>> >>>> | Overhead in relation | a) 3.5% b) 1.4% | a) 7% b) 2.8% >>> | >>> >>>> | to average payload of | | >>> | >>> >>>> | a) ~550 bytes b) 1400 | | >>> | >>> >>>> | bytes). | | >>> | >>> >>>> | ------------------ | ------------------ | ------------------ >>> | >>> >>> >>> >>> Sure. However, 4V6, as per Figure 1 in the draft is based on IPv6 >>> >>> transport. It thus seemed fair to measure and compare the overhead = as >>> >>> relative to IPv6 encapsulation, and not IPv4, since there is no way >>> to >>> >>> send an IPv4-only packet, and the useful data is the Layer4+ payloa= d. >>> >>> Doing it your way you show mixes the basic IPv6 overhead. In any >>> case, >>> >>> subtract the left column from the right and one arrives at the figu= re >>> >>> at pretty much the figures in the original table. >>> >>> >>> >>>> >>> >>>> In addition, a complete comparison should take in consideration th= e >>> length >>> >> of layer-2 headers, as well as that of the physical preambles if any= . >>> This >>> >> leads to even less different overhead ratios. >>> >>> >>> >>> With the relative consideration, this actually doesn't matter... An= d >>> >>> we can choose to ignore the detail of specific radio link protocols >>> >>> that can segment longer packets into many many more. >>> >> >>> >> Different view here. >>> >> The _ratio_ of power-consumption increase, if n bytes are added to >>> each >>> >> packet, does depend on the total length of packets (with their heade= rs >>> of all >>> >> layers, including link and physiscal). >>> >> >>> >> >>> >>> >>> >>> -Woj. >>> >> >>> >> >>> >> _______________________________________________ >>> >> Softwires mailing list >>> >> Softwires@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> >> > --000e0cd1a07a09fd4704a911b97a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also note that the same applies to any dual stack access set-up (eg DSL wit= h PPP).

On 27 July 2011 21:00, Wojciech = Dec <wdec.ietf@= gmail.com> wrote:
Remi,

On 27 July 2011 17:47, R=E9mi Desp= r=E9s <despres.remi@laposte.net> wrote:

Le 27 juil. 2011 =E0 16= :02, Wojciech Dec a =E9crit :


<= br>
On 27 July 2011 09:17, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Rajiv,

As explained in particular in draft-korhonen-v6ops-3gpp-eps-06 sec. 6.2, 3G= PP has introduced the IPv4v6 bearer.
With it, mobile nodes exchange packets natively in bot IPv4 and IPv6.
This saves 20 octets per IPv4 packet compared to a translation that replace= s an IPv4 header by an IPv6 header.

Sure, but it&#= 39;s fair to say that in the context of a (any) 4V6 solution (they run on I= Pv6, not IPv4), the native v4 leg/bearer/capability/pdp type isn't used= or needed. As such this aspect looks=A0 orthogonal to the 4v6 overhead dis= cussion...

The question that remains is = "why does one need a translation" if:
- There already e= xists a solution for native IPv6 AND IPv4 (the IPv4v6 bearer)
- This solution consumes less energy than both translation and encapsulatio= n.

Sure, the IPv4v6 bearer is for *p= lain* IPv4 and IPv6 traffic - it's plain/regular dual stack. By definit= ion, the 4V6 translated or encapsulated solutions would use only the v6 dim= ension (the v4 dimension not being useful), along with their respective ove= rheads (or lack thereof).
=A0

Note th= at, for stateless address sharing, the 4rd address mapping can be directly = combined with the IPv4v6 bearer.

Yes, and that applies to *any* 4V6 varian= t.=A0

Regards,
-Woj.
=

=A0

Cheers,
RD=A0





Regards,
Wojciech.

Regards,
RD


Le 26 juil. 2011 =E0 22:30, Rajiv Asati (rajiva) a =E9crit :

> Remi,
>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>
> Don't follow this. Could you please expand?
>
> Cheers,
> Rajiv
>
>
>> -----Original Message-----
>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf >> Of R=E9mi Despr=E9s
>> Sent: Tuesday, July 26, 2011 10:47 AM
>> To: Wojciech Dec
>> Cc: Softwires-wg; Wojciech Dec (wdec)
>> Subject: Re: [Softwires] Header overheads - 4V6T vs 4V6E
>>
>> Well, I made my point (with one more comment below, at the end). >> Up to WG contributors, and to operators, to appreciate what is rea= lly
>> important to them.
>>
>> Note also that, in 3GPP where power consumption is important, the = IPv4v6
>> bearer option completely avoids the IPv6 header overhead (no need = for 4V6).
>>
>> In wifi, I am still convinced that the impact on power consumption= of +6O vs
>> +40 octets per IPv4 packet will remain negligible in real life, es= pecially as
>> IPv6 will become the majority.
>>
>> The impact of translation on e2e transparency will be discussed in= another
>> email.
>>
>> RD
>>
>> Le 26 juil. 2011 =E0 15:52, Wojciech Dec a =E9crit :
>>
>>> Remi,
>>>
>>> On 25 July 2011 11:59, R=E9mi Despr=E9s <despres.remi@laposte.net>= ; wrote:
>>>>
>>>> Wojciech,
>>>>
>>>> IPv4-header computations of draft-dec-stateless-4v6-02 are= AFAIK too much
>> in favor of translation (4v6T) vs encapsulation (4V6E).
>>>>
>>>> The draft has:
>>>> +------------------------+--------------------+-----------= ----------+
>>>> | Item =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | 4V6 Translati= on =A0 =A0| 4V6 Mapped Tunnel =A0 |
>>>> | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| mode = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mode =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>>>> +------------------------+-------- ... -------+-----------= ----------+
>>>> | Overhead in relation =A0 | a) 0% b) 0% =A0 =A0 =A0 =A0| = a) 4.36% b) 1.71% =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>>
>>>> An IPv4 packet having a 550 B payload is 570 B long (ignor= ing possible IPv4
>> options):
>>>> - 4V6T adds 20 B (3.5 %).
>>>> - 4V6E adds 40 B, (7.0 %).
>>>> An IPv4 packet having a 1400 B payload is 1420 B long (at = least)
>>>> - Translation adds 20/1420 =3D 1,4 %
>>>> - Encapsulation adds 40/1420 =3D 2,8 %
>>>>
>>>> This gives:
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>> | Overhead in relation =A0 | a) 3.5% b) 1.4% =A0 =A0| a) 7= % b) 2.8% =A0 =A0 =A0 |
>>>> | to average payload of =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | a) ~550 bytes b) 1400 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | bytes). =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>>>> | ------------------ =A0 =A0 | ------------------ | ------= ------------ =A0|
>>>
>>> Sure. However, 4V6, as per Figure 1 in the draft is based on I= Pv6
>>> transport. It thus seemed fair to measure and compare the over= head as
>>> relative to IPv6 encapsulation, and not IPv4, since there is n= o way to
>>> send an IPv4-only packet, and the useful data is the Layer4+ p= ayload.
>>> Doing it your way you show mixes the basic IPv6 overhead. In a= ny case,
>>> subtract the left column from the right and one arrives at the= figure
>>> at pretty much the figures in the original table.
>>>
>>>>
>>>> In addition, a complete comparison should take in consider= ation the length
>> of layer-2 headers, as well as that of the physical preambles if a= ny. This
>> leads to even less different overhead ratios.
>>>
>>> With the relative consideration, this actually doesn't mat= ter... And
>>> we can choose to ignore the detail of specific radio link prot= ocols
>>> that can segment longer packets into many many more.
>>
>> Different view here.
>> The _ratio_ of power-consumption increase, if n bytes are added to= each
>> packet, does depend on the total length of packets (with their hea= ders of all
>> layers, including link and physiscal).
>>
>>
>>>
>>> -Woj.
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@= ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires




--000e0cd1a07a09fd4704a911b97a-- From behcetsarikaya@yahoo.com Wed Jul 27 14:29:18 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B3411E80C8 for ; Wed, 27 Jul 2011 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5fHUiQiTIdF for ; Wed, 27 Jul 2011 14:29:17 -0700 (PDT) Received: from nm26.bullet.mail.sp2.yahoo.com (nm26.bullet.mail.sp2.yahoo.com [98.139.91.96]) by ietfa.amsl.com (Postfix) with SMTP id E7BC211E80B5 for ; Wed, 27 Jul 2011 14:29:17 -0700 (PDT) Received: from [98.139.91.68] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 21:29:15 -0000 Received: from [98.139.91.58] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 21:29:15 -0000 Received: from [127.0.0.1] by omp1058.mail.sp2.yahoo.com with NNFMP; 27 Jul 2011 21:29:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 225458.67999.bm@omp1058.mail.sp2.yahoo.com Received: (qmail 60051 invoked by uid 60001); 27 Jul 2011 21:29:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311802154; bh=c2PrMikgAdh47dSEG9LcgYCKCf+bGaLc0jCVZPjn2OU=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2g8j8H7wt0JhJRfO/JnkvWunaxoSpjE+tJ1VsQpuZ8QCkbqoCWAZ04NTaZEX05wJKUfrwpCBtMo6AoEKuJ2hzA6xUlQO2tqDPdjS/Y8WhfAhKUcUFwLtuQBMulPanNMxDOc/Ci2JCcpWWd3ewTZQFe001SxjL5CvrWv8j9SH1VQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=L1CuVaAtZYVyL1gWSMK+rL50tO9OD6+LiJ2iztek2gcIduCESj7F1jxqNRcWU0VVK4vbYQcX8XNkpk68EZYlQ2zNEl4NLxafvMw0hbF/W1JwGBW0gZ50g8SiWyV71/p0YYPjmbC8bg8VktdJyQNe6pw4fZOz7AyTi2X3kP1LZZQ=; X-YMail-OSG: 1XANsXsVM1kKW.WBI0lfXOvQXsZS8wNhl73MHvXi9j_TfEk XJL2aimi_a4oB0zzrp79dcMtU_gkkGvrVu.52xmXA8LPxm9UcP0oDp4E4N.Y 45XM5ljNuCw0ylxgClSqId7h4MQXtHizmw2es8gpdXbWjwT_aaZxaP2nNnAj BgharNSmMW8PcjyzjLR.89MviqtB8Y3ZetpZrHUD9abuW9eiRTIY6KrENQYl io0xeELUmWLU1fpfxiGamy9sdyxO5o.hhH7wSYgMYD_sr_2d0R_53jKeVUXF bZfG4o5CjwiTUYyoR0WWyqMzO0kSAjz9vxd2QlqGjgjRSTWYLStlI420Eohd D7MORhSpgchFmWBpvPo76Eric2j3S0o4qQv0Z.T9jIeBnlVa6xbgqt76fBzh aDnc9eydJ_iWQ6g-- Received: from [130.129.87.243] by web111408.mail.gq1.yahoo.com via HTTP; Wed, 27 Jul 2011 14:29:14 PDT X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.112.310352 References: <1311787201.96355.YahooMailRC@web111403.mail.gq1.yahoo.com> Message-ID: <1311802154.30858.YahooMailRC@web111408.mail.gq1.yahoo.com> Date: Wed, 27 Jul 2011 14:29:14 -0700 (PDT) From: Behcet Sarikaya To: softwires@ietf.org In-Reply-To: <1311787201.96355.YahooMailRC@web111403.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-53656238-1311802154=:30858" Subject: Re: [Softwires] Requirements on DS-Lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 21:29:18 -0000 --0-53656238-1311802154=:30858 Content-Type: text/plain; charset=us-ascii > > Hi all, > In Softwire session this morning someone (I forgot who) raised a concern on > Section 6 > > Solution Based on Layer 2 Multicast Support > > in draft-sarikaya-softwire-dslitemulticast-00.txt. > > Yes there are some additional constraints that this solution requires, Just now I checked in Broadband Forum IPv6 transition document where it says that The BNG MAY be an AFTR element AFTR could be in the service provider broadband IP network. If I revise the draft, I am going to explain L2 Multicast Support considerations for this case as well. BTW the above applies to Cable networks as well, just replace BNG with CMTS :-). > but I > think that we should compare it with any other solutions proposed like > > > draft-qin-softwire-dslite-multicast-04 > > which requires every CE router or B4 of DS-Lite to have IGMP-MLD translator >with > > all its complications. > It is well known fact that CE routers are the most difficult to change >entities > > in fixed networks. > How are you going to cope with this compared with a very simple way of having > that same capability? > > Regards, > > Behcet > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --0-53656238-1311802154=:30858 Content-Type: text/html; charset=us-ascii

>
> Hi all,
>   In Softwire session this morning someone (I forgot who) raised a concern on
> Section 6
>
> Solution Based on Layer 2 Multicast Support
>
> in draft-sarikaya-softwire-dslitemulticast-00.txt.
>
> Yes there are some additional constraints that this solution requires,

Just now I checked in Broadband Forum IPv6 transition document where it says that
The BNG MAY be an AFTR element

AFTR could be in the service provider broadband IP network. If I revise the draft, I am going to explain L2 Multicast Support considerations for this case as well.
BTW the above applies to Cable networks as well, just replace BNG with CMTS :-).

> but I
> think that we should compare it with any other solutions proposed like
>
>
> draft-qin-softwire-dslite-multicast-04
>
> which requires every CE router or B4 of DS-Lite to have IGMP-MLD translator with
> all its complications.
> It is well known fact that CE routers are the most difficult to change entities
> in fixed networks.
> How are you going to cope with this compared with a very simple way of having
> that same capability?
>
> Regards,
>
> Behcet
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>

--0-53656238-1311802154=:30858-- From wdec.ietf@gmail.com Wed Jul 27 15:13:33 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA9911E8178 for ; Wed, 27 Jul 2011 15:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.324 X-Spam-Level: X-Spam-Status: No, score=-3.324 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBy-KwLBQjIS for ; Wed, 27 Jul 2011 15:13:32 -0700 (PDT) Received: from mail-gw0-f43.google.com (mail-gw0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 19B9C11E80C3 for ; Wed, 27 Jul 2011 15:13:32 -0700 (PDT) Received: by gwm11 with SMTP id 11so2107258gwm.16 for ; Wed, 27 Jul 2011 15:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X0Yp/Cmdo7eigczdvcehmozlkKTkaE58BRQKvqncWlo=; b=NnaizAGkGa5OwwsYLSPE0rVaW8sfxfbYv1A22HFZSOeTJGJv6TKy5nhzzwp19ucIoW GZYxQ/dwkspvtB8oodHbqc5VK/xzPo4ou0RGL8Os8P0XIb3wBGCGb43SfaepHL2gjb4/ edOYUQgTNN3jqycCYfu5ODrbIyld94C9OYgtk= MIME-Version: 1.0 Received: by 10.142.204.9 with SMTP id b9mr195815wfg.3.1311804811074; Wed, 27 Jul 2011 15:13:31 -0700 (PDT) Received: by 10.142.207.1 with HTTP; Wed, 27 Jul 2011 15:13:31 -0700 (PDT) In-Reply-To: <28607E67-0383-4AB3-BA17-7ABE55793A06@laposte.net> References: <9B93871C-C40A-4999-918C-3A7EE88F6AAD@laposte.net> <4E301DBC.8060104@cernet.edu.cn> <28607E67-0383-4AB3-BA17-7ABE55793A06@laposte.net> Date: Thu, 28 Jul 2011 00:13:31 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=000e0cd1a07ac75c7904a9145bf0 Cc: Softwires-wg , Wojciech Dec Subject: Re: [Softwires] Transparency limitations of 4V6 Translation X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 22:13:33 -0000 --000e0cd1a07ac75c7904a9145bf0 Content-Type: text/plain; charset=ISO-8859-1 In summary, the dual stateless translator can be configured to have "Yes" to (2), (3), (4). The only "No" is (1). > > Agreed for (2) and (3) (provided the solution draft is completed). > Concerning (4) both the solution and the comparison drafts deserve updates, > IMHO. > > Regards, > RD > Agreed. WIll include the remarks in the next draft version. Thanks, Woj. --000e0cd1a07ac75c7904a9145bf0 Content-Type: text/html; charset=ISO-8859-1 In summary, the dual stateless translator can be configured to have "Yes" to (2), (3), (4). The only "No" is (1).

Agreed for (2) and (3) (provided the solution draft is completed).
Concerning (4) both the solution and the comparison drafts deserve updates, IMHO.

Regards,
RD

Agreed. WIll include the remarks in the next draft version.

Thanks,
Woj.


--000e0cd1a07ac75c7904a9145bf0-- From bingxuere@gmail.com Wed Jul 27 17:12:48 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B321F8BAD for ; Wed, 27 Jul 2011 17:12:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE39untxKoTV for ; Wed, 27 Jul 2011 17:12:47 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4F921F871E for ; Wed, 27 Jul 2011 17:12:47 -0700 (PDT) Received: by gyd5 with SMTP id 5so1755258gyd.31 for ; Wed, 27 Jul 2011 17:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=15uEObPfUU6oZOdV2DmN7N7wZ2OFPzjg9vKyE1fmNkI=; b=udc2ZkiBFWDTRqqlzRoboPFXqhCv2hNq+6kv6AWMwESlW3d+vOMlu+ve9niKWRBmX1 hMSBYLblDpglmblvRgMTI2mFrBQOF7CUFQtc6doPBwk7ZvGzEyrY15DFjpEIP0cu3XM3 mnbSPQxgVRY2euLf3736ESY6jPV2/G6teijD8= Received: by 10.42.159.199 with SMTP id m7mr349568icx.326.1311811966139; Wed, 27 Jul 2011 17:12:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Wed, 27 Jul 2011 17:12:26 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Thu, 28 Jul 2011 08:12:26 +0800 Message-ID: To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=90e6ba6e8a0c40fbd504a916069c Cc: "softwires@ietf.org" Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 00:12:48 -0000 --90e6ba6e8a0c40fbd504a916069c Content-Type: text/plain; charset=UTF-8 Dear Yiu, >From the perspective of an operator, we strongly support the first use case. For transmission efficiency, we need to deliver streaming contents through multicast-capable network. And we are doing our effort to make it multicast-capable. Thanks. Qiong SUN On Thu, Jul 28, 2011 at 2:19 AM, Lee, Yiu wrote: > Hi WG, > > In today meeting, we presented two drafts on to enable multicast in > DS-lite. I think they target different use cases: > > The use case of > http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04 is to > deliver multicast over DS-lite in an IPv6 multicast enabled network. > > The use case of > http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-00 is > to deliver multicast over DS-lite in an IPv6 multicast disabled network. > > I think both drafts target different use cases. My question to the WG is: > Should we work on both use cases? If not, which use case the WG should work > on first? > > I really want to hear people comments. Please raise your voice in the ML. > > Thanks, > /Yiu > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --90e6ba6e8a0c40fbd504a916069c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Yiu,

From=C2=A0t= he=C2=A0perspective=C2=A0of=C2=A0an operator,=C2=A0we=C2=A0strongly=C2=A0su= pport=C2=A0the=C2=A0first=C2=A0use=C2=A0case.=C2=A0For=C2=A0transmission=C2= =A0efficiency,=C2=A0we=C2=A0need=C2=A0to=C2=A0deliver=C2=A0streaming=C2=A0c= ontents=C2=A0through=C2=A0multicast-capable=C2=A0network. And we are doing = our effort to make it=C2=A0multic= ast-capable.

<= div>Thanks.
=
<= /span>
<= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">Qiong = SUN


On Thu, Jul 28, 2011 at = 2:19 AM, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Hi WG,

In today meeting, we presented two drafts on to enable multicast in DS= -lite. I think they target different use cases:

The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04=C2=A0= is to deliver multicast over DS-lite in an IPv6 multicast enabled network.<= /div>

The use case of http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-00= =C2=A0is to deliver multicast over DS-lite in an IPv6 multicast disabled ne= twork.

I think both drafts target different use cases. My question to the WG = is: Should we work on both use cases? If not, which use case the WG should = work on first?

I really want to hear people comments. Please raise your voice in the = ML.

Thanks,
/Yiu
=C2=A0=C2=A0



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


--90e6ba6e8a0c40fbd504a916069c-- From xiaohong.deng@orange-ftgroup.com Wed Jul 27 18:46:19 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033EE21F8B20 for ; Wed, 27 Jul 2011 18:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLe1ulrOsdUp for ; Wed, 27 Jul 2011 18:46:18 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 99BD721F8B11 for ; Wed, 27 Jul 2011 18:46:06 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 379E78B800A; Thu, 28 Jul 2011 03:46:54 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 047DA8B8008; Thu, 28 Jul 2011 03:46:54 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 03:46:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4CC8.1B09CC01" Date: Thu, 28 Jul 2011 09:45:58 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC018DE5E5@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] DS-lite Multicast Thread-Index: AcxMyBjYumvL4RtyQO6lbG/7mBFPDg== References: From: To: , X-OriginalArrivalTime: 28 Jul 2011 01:46:04.0693 (UTC) FILETIME=[1CC7D450:01CC4CC8] Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 01:46:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4CC8.1B09CC01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yiu,all, =20 I see the first use case worth good value to work on, as the reason I stated during meeting: operators would happy with it because otherwise (the second case), means moving AFTR lower location, which ends up with more CAPEX. =20 Xiaohong ________________________________ From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 Sent: Thursday, July 28, 2011 2:19 AM To: softwires@ietf.org Subject: [Softwires] DS-lite Multicast =09 =09 Hi WG, In today meeting, we presented two drafts on to enable multicast in DS-lite. I think they target different use cases: The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04 is to deliver multicast over DS-lite in an IPv6 multicast enabled network. The use case of http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-00 is to deliver multicast over DS-lite in an IPv6 multicast disabled network. I think both drafts target different use cases. My question to the WG is: Should we work on both use cases? If not, which use case the WG should work on first? I really want to hear people comments. Please raise your voice in the ML. Thanks, /Yiu =20 ------_=_NextPart_001_01CC4CC8.1B09CC01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Yiu,all,
 
I see the=20 first use case worth good value to work on, as the reason I stated = during=20 meeting: operators would happy with it because otherwise (the second=20 case), means moving AFTR lower location, which ends up with = more=20 CAPEX.
 
Xiaohong

From: Lee, Yiu=20 [mailto:Yiu_Lee@Cable.Comcast.com]
Sent: Thursday, July 28, = 2011=20 2:19 AM
To: softwires@ietf.org
Subject: = [Softwires]=20 DS-lite Multicast

Hi WG,

In today meeting, we presented two drafts on to enable multicast = in=20 DS-lite. I think they target different use cases:

The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04&n= bsp;is=20 to deliver multicast over DS-lite in an IPv6 multicast enabled = network.

The use case of http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-= 00 is=20 to deliver multicast over DS-lite in an IPv6 multicast disabled = network.

I think both drafts target different use cases. My question to = the WG is:=20 Should we work on both use cases? If not, which use case the WG should = work on=20 first?

I really want to hear people comments. Please raise your voice in = the=20 ML.

Thanks,
/Yiu
  


------_=_NextPart_001_01CC4CC8.1B09CC01-- From xiaohong.deng@orange-ftgroup.com Wed Jul 27 18:56:32 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CCE21F8B8A for ; Wed, 27 Jul 2011 18:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ov2cytRH-OnP for ; Wed, 27 Jul 2011 18:56:31 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0185921F8B89 for ; Wed, 27 Jul 2011 18:56:31 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C62CF6D8003; Thu, 28 Jul 2011 03:57:48 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id B2DD96C8002; Thu, 28 Jul 2011 03:57:48 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 03:56:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4CC9.8F4B885B" Date: Thu, 28 Jul 2011 09:56:23 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC018DE5F0@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <1311802154.30858.YahooMailRC@web111408.mail.gq1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Requirements on DS-Lite Multicast Thread-Index: AcxMyY3QgfvlpmZCRwWOhMRta4Ft9Q== References: <1311787201.96355.YahooMailRC@web111403.mail.gq1.yahoo.com> <1311802154.30858.YahooMailRC@web111408.mail.gq1.yahoo.com> From: To: , X-OriginalArrivalTime: 28 Jul 2011 01:56:29.0404 (UTC) FILETIME=[912329C0:01CC4CC9] Subject: Re: [Softwires] Requirements on DS-Lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 01:56:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4CC9.8F4B885B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > but I=20 > think that we should compare it with any other solutions proposed like >=20 >=20 > draft-qin-softwire-dslite-multicast-04 >=20 > which requires every CE router or B4 of DS-Lite to have IGMP-MLD translator with=20 > all its complications. > It is well known fact that CE routers are the most difficult to change entities=20 > in fixed networks.=20 =20 How comes? I mean many operators custormize&provide their own CE routers to customers. =20 Besides,the most difficult part to change is rather the *host* than the CE.;) =20 Xiaohong =20 > How are you going to cope with this compared with a very simple way of having=20 > that same capability? >=20 > Regards, >=20 > Behcet >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 ------_=_NextPart_001_01CC4CC9.8F4B885B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> but I
> think that we should = compare it with=20 any other solutions proposed like
>
>
>=20 draft-qin-softwire-dslite-multicast-04
>
> which requires = every CE=20 router or B4 of DS-Lite to have IGMP-MLD translator with
> all = its=20 complications.
> It is well known fact that CE routers are the = most=20 difficult to change entities
> in fixed networks. 
 
How comes? I mean many operators = custormize&provide=20 their own CE routers to customers.
 
Besides,the most difficult part to = change is rather=20 the *host* than the CE.;)
 
Xiaohong
 
> How=20 are you going to cope with this compared with a very simple way of = having=20
> that same capability?
>
> Regards,
> =
>=20 Behcet
>
> = _______________________________________________
>=20 Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
&g= t;=20

------_=_NextPart_001_01CC4CC9.8F4B885B-- From bingxuere@gmail.com Wed Jul 27 23:28:53 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF421F8891 for ; Wed, 27 Jul 2011 23:28:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mimsIltHXzWo for ; Wed, 27 Jul 2011 23:28:53 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 082F721F8880 for ; Wed, 27 Jul 2011 23:28:52 -0700 (PDT) Received: by iye7 with SMTP id 7so3065058iye.31 for ; Wed, 27 Jul 2011 23:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=LrdGvsJhwLqIQAJ9DHOKBEaRcI5ueAqB1I9IeBWxVZk=; b=pApAIE8YbV4xOAOobhgKPVXqeJa7CbyK0y3aWyBFau4z4BfIAHtgJKQTsbDQpr2joM SyET7OkA2ujtMFmwfmGC0XdYM/WrVgl9yPhguamHBY+4I/cRy5gdZ5vqE55+qpsNNAV3 hm5SQmSPUK64/5Hs/bGGcEBjYqNk1eLUqMPmQ= Received: by 10.42.159.199 with SMTP id m7mr555293icx.326.1311834532241; Wed, 27 Jul 2011 23:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Wed, 27 Jul 2011 23:28:32 -0700 (PDT) From: Qiong Date: Thu, 28 Jul 2011 14:28:32 +0800 Message-ID: To: softwires@ietf.org, wdec.ietf@gmail.com Content-Type: multipart/alternative; boundary=90e6ba6e8a0c4c603b04a91b476c Subject: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 06:28:53 -0000 --90e6ba6e8a0c4c603b04a91b476c Content-Type: text/plain; charset=UTF-8 Dear all, Following the recent discussion on stateless 4v6 solutions, I'm still wondering how to define or plan a reasonable stateless 4v6 domain in reality. My main concern is how to distinguish between multiple different domains with lower cost ? I have noticed that we can define multiple stateless 4v6 domains in draft-dec-stateless-4v6, 4rd, etc., within the same local-area. This can be very helpful to apply different strategies for our customers. For example, our legacy users can just have non-shared public IPv4 address while our new customers would have shared-IPv4 address, or even with different multiplex ratio. In this situation, multiple domains can be defined for different type of users and need to be distinguished accordingly. Here, the ideal way is to define one IPv4 pool for one stateless 4v6 prefix. However, our current situation is quite different. Not only does it has been too difficult to retrieve the existing IPv4 addresses and re-plan them again, but also the remaining IPv4 prefix pool is quite scattered. As a result, the larger the domain covers, the more IPv4 prefix becomes. So, it might be normal to have up to thousands of rules indicating specific IPv4 prefix pool and corresponding IPv6 prefix in stateless gateway. Every packet arriving at the stateless gateway has to firstly lookup the rule table and find its 4v6 domain. This seems have turned a totally stateless solution into partial stateful. Please correct me if I missed something. :-) Thanks in advance. Best wishes Qiong Sun --90e6ba6e8a0c4c603b04a91b476c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all,

Following the recent discussion on stateless 4= v6 solutions, I'm still wondering how to define or plan a reasonable st= ateless 4v6 domain in reality. My main concern is how to distinguish betwee= n multiple different domains with lower cost ?

I have noticed that we can define multiple stateless 4v= 6 domains in draft-dec-stateless-4v6, 4rd, etc., within the same local-area= . This can be very helpful to apply different strategies for our customers.= For example, our legacy users can just have non-shared public IPv4 address= while our new customers would have shared-IPv4 address, or even with diffe= rent multiplex ratio. =C2=A0In this situation, multiple domains can be defi= ned for different type of users and need to be distinguished accordingly.= =C2=A0

Here, the ideal way is to define one IPv4 pool for one = stateless 4v6 prefix. However, our current situation is quite different. No= t only does it has been too difficult to retrieve the existing IPv4 address= es and re-plan them again, but also the remaining IPv4 prefix pool is quite= =C2=A0scattered. As a result, the larger the domain covers, the more IPv4 p= refix becomes. So, it might be normal to have up to thousands of rules indi= cating specific IPv4 prefix pool and corresponding IPv6 prefix in stateless= gateway. =C2=A0Every packet arriving at the stateless gateway has to first= ly lookup the rule table and find its 4v6 domain.=C2=A0This seems have turn= ed a totally stateless solution into partial stateful.

Please correct me if I missed something. :-) Thanks in = advance.

Best wishes=C2=A0

Qiong Sun


--90e6ba6e8a0c4c603b04a91b476c-- From christian.jacquenet@orange-ftgroup.com Wed Jul 27 23:53:01 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458FB21F8C2D for ; Wed, 27 Jul 2011 23:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmeBhPEMr+gI for ; Wed, 27 Jul 2011 23:53:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3B85B21F8B02 for ; Wed, 27 Jul 2011 23:53:00 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 8BC8E374619; Thu, 28 Jul 2011 08:52:58 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6D01B38403A; Thu, 28 Jul 2011 08:52:58 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Thu, 28 Jul 2011 08:52:58 +0200 From: To: "Lee, Yiu" , "softwires@ietf.org" Date: Thu, 28 Jul 2011 08:52:56 +0200 Thread-Topic: DS-lite Multicast Thread-Index: AQHMTIm5LUBdbbYgxkWSDb2ph5Pq4JUBTLxg Message-ID: <3256_1311835978_4E31074A_3256_189264_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF2E28CDA@PUEXCB1C.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: multipart/alternative; boundary="_000_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF2E28CDAPUEXCB1Cnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.28.54214 Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 06:53:01 -0000 --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF2E28CDAPUEXCB1Cnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I would privilege the first use case, as described in http://tools.ietf.or= g/html/draft-qin-softwire-dslite-multicast-04. Cheers, Christian. ________________________________ De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p= art de Lee, Yiu Envoy=E9 : mercredi 27 juillet 2011 20:19 =C0 : softwires@ietf.org Objet : [Softwires] DS-lite Multicast Hi WG, In today meeting, we presented two drafts on to enable multicast in DS-lite= . I think they target different use cases: The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite-multic= ast-04 is to deliver multicast over DS-lite in an IPv6 multicast enabled ne= twork. The use case of http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemu= lticast-00 is to deliver multicast over DS-lite in an IPv6 multicast disabl= ed network. I think both drafts target different use cases. My question to the WG is: S= hould we work on both use cases? If not, which use case the WG should work = on first? I really want to hear people comments. Please raise your voice in the ML. Thanks, /Yiu ***************************************************************************= ***** IMPORTANT.Les informations contenues dans ce message electronique y compris= les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) men= tionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve= uillez immediatement le signaler a l expediteur et effacer ce message=20 et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans= ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment= s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout vi= rus. IMPORTANT.This e-mail message and any attachments are strictly confidential= and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(= s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not b= e liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ***************************************************************************= ***** --_000_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF2E28CDAPUEXCB1Cnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
I would privilege the first use case, as described= =20 in  = http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04.
 
Cheers,
 
Christian.

De : softwires-bounces@ietf.org= =20 [mailto:softwires-bounces@ietf.org] De la part de Lee,=20 Yiu
Envoy=E9 : mercredi 27 juillet 2011 20:19
=C0&nb= sp;:=20 softwires@ietf.org
Objet : [Softwires] DS-lite=20 Multicast

Hi WG,

In today meeting, we presented two drafts on to enable multicast in= =20 DS-lite. I think they target different use cases:

The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04&nbs= p;is=20 to deliver multicast over DS-lite in an IPv6 multicast enabled network.

The use case of http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-00=  is=20 to deliver multicast over DS-lite in an IPv6 multicast disabled network.<= /DIV>

I think both drafts target different use cases. My question to the W= G is:=20 Should we work on both use cases? If not, which use case the WG should wo= rk on=20 first?

I really want to hear people comments. Please raise your voice in th= e=20 ML.

Thanks,
/Yiu
  


****************************************=
****************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris=
 les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) men=
tionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, ve=
uillez immediatement le signaler  a l expediteur et effacer ce message=20
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans=
 ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment=
 s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout vi=
rus.

IMPORTANT.This e-mail message and any attachments are strictly confidential=
 and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(=
s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not b=
e liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
***************************************************************************=
*****
--_000_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF2E28CDAPUEXCB1Cnante_-- From satoru.matsushima@gmail.com Thu Jul 28 00:08:14 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F4411E80A5 for ; Thu, 28 Jul 2011 00:08:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyViT0QmnDxv for ; Thu, 28 Jul 2011 00:08:14 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8AF11E8070 for ; Thu, 28 Jul 2011 00:08:14 -0700 (PDT) Received: by qyk29 with SMTP id 29so1505285qyk.10 for ; Thu, 28 Jul 2011 00:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3VRhKS0Jrm4jrbqs+s6wVj4x2j8o/dWlZ3mHWcZsAw4=; b=wZM/dN+QTd51HcH9KwjrVdlpAw6GMufwJGyP0XW8DtwLKefrw/gusjXhRQ+gLaDnv4 ZUu6Jop1UCd+xkPHPqJVVNwlMMseXYrQ00nxN4WUaoN82Ky2E6w60oX1/ILoaY8ToCMD ptKpa7nQ0Pqhj4YfABJ2BOU/vnMS/e6RXlWac= Received: by 10.229.2.97 with SMTP id 33mr476265qci.232.1311836893391; Thu, 28 Jul 2011 00:08:13 -0700 (PDT) Received: from dhcp-4258.meeting.ietf.org (dhcp-4258.meeting.ietf.org [130.129.66.88]) by mx.google.com with ESMTPS id u12sm515880qct.27.2011.07.28.00.08.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 00:08:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Thu, 28 Jul 2011 03:08:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> References: To: Qiong X-Mailer: Apple Mail (2.1244.3) Cc: softwires@ietf.org Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:08:14 -0000 Hello Qiong, On 2011/07/28, at 2:28, Qiong wrote: > Dear all, >=20 > Following the recent discussion on stateless 4v6 solutions, I'm still = wondering how to define or plan a reasonable stateless 4v6 domain in = reality. My main concern is how to distinguish between multiple = different domains with lower cost ? >=20 > I have noticed that we can define multiple stateless 4v6 domains in = draft-dec-stateless-4v6, 4rd, etc., within the same local-area. This can = be very helpful to apply different strategies for our customers. For = example, our legacy users can just have non-shared public IPv4 address = while our new customers would have shared-IPv4 address, or even with = different multiplex ratio. In this situation, multiple domains can be = defined for different type of users and need to be distinguished = accordingly.=20 >=20 > Here, the ideal way is to define one IPv4 pool for one stateless 4v6 = prefix. However, our current situation is quite different. Not only does = it has been too difficult to retrieve the existing IPv4 addresses and = re-plan them again, but also the remaining IPv4 prefix pool is quite = scattered. As a result, the larger the domain covers, the more IPv4 = prefix becomes. So, it might be normal to have up to thousands of rules = indicating specific IPv4 prefix pool and corresponding IPv6 prefix in = stateless gateway. Every packet arriving at the stateless gateway has = to firstly lookup the rule table and find its 4v6 domain. This seems = have turned a totally stateless solution into partial stageful. Routing always supports us. You can choose a tunnel which have = appropriate mapping rule by your routing table. Even it is 'totally = stateless solution', you have to lookup routing table as far as it is = routing network. Hope it helps your network design. Best regards, --satoru= From bingxuere@gmail.com Thu Jul 28 01:32:06 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CD521F8C3B for ; Thu, 28 Jul 2011 01:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMQnoV9+9-Ex for ; Thu, 28 Jul 2011 01:32:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E63D21F8C31 for ; Thu, 28 Jul 2011 01:32:05 -0700 (PDT) Received: by iye7 with SMTP id 7so3194716iye.31 for ; Thu, 28 Jul 2011 01:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9gDJ1pVV5I3NScbS/v7ym/RBNlmncK/MAsYqE4NDqMo=; b=XjHgc9ZI81oeVQfHNHPDbdCfeh34uB8TeUKut4b6ZsXL6kPV0X0bEUMQsIVBOQQno3 7Beo4z2CMnyhxVT7Zp8WOph9kFG5IskTIfEsb4pJxnbuqy7sQc2fPSOa9MeIRID/dfNF 8yLjoWP/rluQppDW0OQzmaVSNOI9OfJZmLkOk= Received: by 10.231.34.4 with SMTP id j4mr533616ibd.156.1311841925206; Thu, 28 Jul 2011 01:32:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Thu, 28 Jul 2011 01:31:45 -0700 (PDT) In-Reply-To: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> References: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> From: Qiong Date: Thu, 28 Jul 2011 16:31:45 +0800 Message-ID: To: Satoru Matsushima Content-Type: multipart/alternative; boundary=0022154012faf411a804a91cff95 Cc: softwires@ietf.org Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 08:32:06 -0000 --0022154012faf411a804a91cff95 Content-Type: text/plain; charset=UTF-8 Hi, Satoru, Thanks a lot for your suggestion and I understand it can work. But in my understanding, it still lies some differences with the so-called "totally stateless solution". Suppose there is only one domain, when an IPv4 downstream packet arrives at stateless gateway, it would firstly forward to the virtual tunnel interface (take 4V6 Mapped Tunnel for example) with only one default route. Then after encapsulated with a uniform IPv6 prefix and IPv4 prefix, etc, it will lookup IPv6 routing table and forward to 4v6 CE. Here, actually there is no need to do routing lookup for IPv4 address expect one default route. However, if we introduce multiple domains with multiple IPv4 prefix pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, Nm would not be a small number anymore. So maybe some more optimization work will still be needed to make it more "stateless" ? Best wishes On Thu, Jul 28, 2011 at 3:08 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hello Qiong, > > > Routing always supports us. You can choose a tunnel which have appropriate > mapping rule by your routing table. Even it is 'totally stateless solution', > you have to lookup routing table as far as it is routing network. Hope it > helps your network design. > > Best regards, > --satoru --0022154012faf411a804a91cff95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,=C2=A0Satoru,

Thanks a lot for your suggestion and I = understand it can work.=C2=A0But in my understanding, it still lies some di= fferences with the so-called "totally stateless solution".=C2=A0<= /div>

Suppose there is only one domain,=C2=A0when an IPv4 downstream p= acket arrives at stateless gateway,=C2=A0it would firstly forward to the vi= rtual tunnel interface (take 4V6 Mapped Tunnel for example) with only one d= efault route. Then after encapsulated with a uniform IPv6 prefix and IPv4 p= refix, etc, it will lookup IPv6 routing table and forward to 4v6 CE. Here, = actually there is no need to do routing lookup for IPv4 address expect one = default route. However, if we introduce multiple domains with multiple IPv4= prefix pools ( the number of each domain is N1, N2, N3,... Nm) , then the = entry number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situa= tion, Nm would not be a small number anymore. So maybe some more optimizati= on work will still be needed to make it more "stateless" ? =C2=A0=

Best wishes


On Thu, Jul 28, 2011 at 3:08 PM, Satoru Matsushima <satoru.matsushi= ma@gmail.com> wrote:
Hello Qiong,


Routing always supports us. You can choose a tunnel which have appropriate = mapping rule by your routing table. Even it is 'totally stateless solut= ion', you have to lookup routing table as far as it is routing network.= Hope it helps your network design.

Best regards,
--satoru

--0022154012faf411a804a91cff95-- From bingxuere@gmail.com Thu Jul 28 02:53:22 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12521F8C62 for ; Thu, 28 Jul 2011 02:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzxq5iFM9Q7y for ; Thu, 28 Jul 2011 02:53:21 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 870B321F8C58 for ; Thu, 28 Jul 2011 02:53:21 -0700 (PDT) Received: by iye7 with SMTP id 7so3280087iye.31 for ; Thu, 28 Jul 2011 02:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bHS6V5LIKWmc/rpgARRfsKX/6rqRoTH6H91UZAtd6fg=; b=FU7j8OoWqNJKSssP/VV0r7L5n6Nng4wHy+jwx1br9VmkhVcqVh8XohSPJNzHEJUwv0 Ul2ZW7b5267+D3xI4pShUDXjOKxLW1I2pbx/4O1KtgI+PBnE5rLSkMw8a1XDbgbtotBX N3KgEv3G341xw3fCtAD6wlB2s1PdGsfWHi/X8= Received: by 10.42.159.199 with SMTP id m7mr732912icx.326.1311846801121; Thu, 28 Jul 2011 02:53:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Thu, 28 Jul 2011 02:53:00 -0700 (PDT) In-Reply-To: <741D71AA-24D1-4EA7-9409-45175D603213@free.fr> References: <741D71AA-24D1-4EA7-9409-45175D603213@free.fr> From: Qiong Date: Thu, 28 Jul 2011 17:53:00 +0800 Message-ID: To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Content-Type: multipart/alternative; boundary=90e6ba6e8a0c94a13b04a91e22b1 Cc: softwires@ietf.org Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:53:22 -0000 --90e6ba6e8a0c94a13b04a91e22b1 Content-Type: text/plain; charset=UTF-8 Hi, Remi, Thanks for your comments. I agree with you that in this situation, stateless solution still superior to stateful ones from scalability aspect. It is "per independent IPv4 prefix" mapping rule database, rather than customer-based. But it still may have some tradeoff for domain realm. The larger the domain it covers, the more independent IPv4 prefix there will be. And also the whole domain has to synchronize these mapping rules. I think this problem would be quite common for large broadband service providers who already have a huge amount of customers. Do we have to transfer all these legacy customers with public IPv4 address into shared-mode directly? In our consideration, we think it might be better to offer shared-mode solution for new customers only and leave the legacy customers with non-shared-mode solution to avoid complaint from address sharing. As a result, we have to deal with the co-existence scenario for at least shared-mode and non-shared-mode. I agree that this mapping specification can be applied to all stateless solutions, separated from specific solution. Thanks for your suggestion. Best wishes Qiong Sun --90e6ba6e8a0c94a13b04a91e22b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Remi,

Thanks for your comments. I agree with you tha= t in this situation, stateless solution still superior to stateful ones fro= m scalability aspect. It is "per independent IPv4 prefix" mapping= rule database, rather than customer-based.=C2=A0But it still may have some= tradeoff for domain realm. The larger the domain it covers, the more=C2=A0= independent IPv4 prefix there will be. And also the whole domain has to syn= chronize these mapping rules.=C2=A0

I think this problem would be quite common for large br= oadband service providers who already have a huge amount of customers. Do w= e have to transfer all these legacy customers with public IPv4 address into= shared-mode directly? In our consideration, we think it might be better to= offer shared-mode solution for new customers only and leave the legacy cus= tomers with non-shared-mode solution to avoid=C2=A0complaint from address s= haring. As a result, we have to deal with the co-existence=C2=A0scenario fo= r=C2=A0at least shared-mode and non-shared-mode. =C2=A0

I agree that this=C2=A0mapping specification can be app= lied to all stateless solutions,=C2=A0separated=C2=A0from specific solution= . Thanks for your suggestion.

Best wishes

Qiong Sun=C2=A0
=C2=A0

--90e6ba6e8a0c94a13b04a91e22b1-- From satoru.matsushima@gmail.com Thu Jul 28 02:55:49 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4B221F8764 for ; Thu, 28 Jul 2011 02:55:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe0FebF-NcAE for ; Thu, 28 Jul 2011 02:55:48 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 65B3721F8754 for ; Thu, 28 Jul 2011 02:55:48 -0700 (PDT) Received: by qyk29 with SMTP id 29so1578915qyk.10 for ; Thu, 28 Jul 2011 02:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uqkXoHEBkAPFKTlsxzbIfZxpZw3gk6QhN8m43NbhFf0=; b=ZHXPdV6SUWtRENDtR+JNLt5Uk+CCw7f81oUPq5nL6f+2WJMAyDhWfEZhV9+uCg38a3 nvaYD9WR3Xr9wBlR4nI9rXsuDiiNknLwL/KXHisilmUVz/vkTGWftqtcKbOhzEacINxX tLOY6iMLBIngX+PxPmmiM9K7ISyuesGfsCBMA= Received: by 10.229.68.94 with SMTP id u30mr669380qci.92.1311846947943; Thu, 28 Jul 2011 02:55:47 -0700 (PDT) Received: from dhcp-4258.meeting.ietf.org (dhcp-4258.meeting.ietf.org [130.129.66.88]) by mx.google.com with ESMTPS id p15sm572832qct.34.2011.07.28.02.55.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 02:55:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Thu, 28 Jul 2011 05:55:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> To: Qiong X-Mailer: Apple Mail (2.1244.3) Cc: softwires@ietf.org Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:55:49 -0000 Hi Qiong, On 2011/07/28, at 4:31, Qiong wrote: > Hi, Satoru, >=20 > Thanks a lot for your suggestion and I understand it can work. But in = my understanding, it still lies some differences with the so-called = "totally stateless solution".=20 I don't mean that 'totally stateless solution' isn't a part of routing = system.=20 > Suppose there is only one domain, when an IPv4 downstream packet = arrives at stateless gateway, it would firstly forward to the virtual = tunnel interface (take 4V6 Mapped Tunnel for example) with only one = default route. Then after encapsulated with a uniform IPv6 prefix and = IPv4 prefix, etc, it will lookup IPv6 routing table and forward to 4v6 = CE. Here, actually there is no need to do routing lookup for IPv4 = address expect one default route. You already did routing when you found default route. > However, if we introduce multiple domains with multiple IPv4 prefix = pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry = number of IPv4 routing table will be N1+N2+N3+..+Nm. In current = situation, Nm would not be a small number anymore. So maybe some more = optimization work will still be needed to make it more "stateless" ? =20 What do you mean 'the entry number of IPv4 routing table'?=20 Do you presume that your IGP routing has almost 300K routes as same = number of current internet full routes? Best regards, --satoru From Tina.Tsou.Zouting@huawei.com Thu Jul 28 04:10:56 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7983321F8AD8 for ; Thu, 28 Jul 2011 04:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.792 X-Spam-Level: X-Spam-Status: No, score=-5.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYisihlZxLMG for ; Thu, 28 Jul 2011 04:10:54 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9C20F21F8AFA for ; Thu, 28 Jul 2011 04:10:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP100CAQJ252G@szxga04-in.huawei.com> for softwires@ietf.org; Thu, 28 Jul 2011 19:10:53 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP1005BXJ25YX@szxga04-in.huawei.com> for softwires@ietf.org; Thu, 28 Jul 2011 19:10:53 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACW22346; Thu, 28 Jul 2011 19:10:52 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Jul 2011 19:10:46 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.19]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 19:10:47 +0800 Date: Thu, 28 Jul 2011 11:10:47 +0000 From: Tina TSOU X-Originating-IP: [10.212.246.67] To: Satoru Matsushima , Qiong Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Softwires] [softwire]comments on stateless 4v6 domain Thread-index: AQHMTO/PDEl+CLgJXUy4AkZF7chel5UAyjqAgAAXW4CAABd3AIAAk8LQgAACbZA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> Cc: "softwires@ietf.org" Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 11:10:56 -0000 Matsushima-san, In this draft, we may need to refer or define the definition of - Stateful operation - Stateless operation - Dynamic port allocation - Static port allocation Hope in this way, the discussion could be easier. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Satoru Matsushima Sent: Thursday, July 28, 2011 5:56 AM To: Qiong Cc: softwires@ietf.org Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain Hi Qiong, On 2011/07/28, at 4:31, Qiong wrote: > Hi, Satoru, > > Thanks a lot for your suggestion and I understand it can work. But in my understanding, it still lies some differences with the so-called "totally stateless solution". I don't mean that 'totally stateless solution' isn't a part of routing system. > Suppose there is only one domain, when an IPv4 downstream packet arrives at stateless gateway, it would firstly forward to the virtual tunnel interface (take 4V6 Mapped Tunnel for example) with only one default route. Then after encapsulated with a uniform IPv6 prefix and IPv4 prefix, etc, it will lookup IPv6 routing table and forward to 4v6 CE. Here, actually there is no need to do routing lookup for IPv4 address expect one default route. You already did routing when you found default route. > However, if we introduce multiple domains with multiple IPv4 prefix pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, Nm would not be a small number anymore. So maybe some more optimization work will still be needed to make it more "stateless" ? What do you mean 'the entry number of IPv4 routing table'? Do you presume that your IGP routing has almost 300K routes as same number of current internet full routes? Best regards, --satoru _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From pacosaddress@googlemail.com Thu Jul 28 05:08:04 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7FE21F8C44 for ; Thu, 28 Jul 2011 05:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-FxbJ+7Oysg for ; Thu, 28 Jul 2011 05:08:03 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D586A21F8C42 for ; Thu, 28 Jul 2011 05:08:03 -0700 (PDT) Received: by iye7 with SMTP id 7so3416560iye.31 for ; Thu, 28 Jul 2011 05:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=owFpior12L2LhBYR3j/tpoOuWLOtzRdGN/EIHySswPA=; b=cav3oEx0RYsX2POCMUJO71EbXlYxLV3Taj4sLrY92tFAuGsU8mYP/2EBFB6OcHb78J L8wsGoJmg3YivAZbiPL3Lun5m0VqiQwsfpBL4jc3wrh9rdIogKXir1iHhX9yHsz5tY6B krYrCZzW/tSasQj1o2xr0e9xUqHIfs8sAj+/0= MIME-Version: 1.0 Received: by 10.231.20.133 with SMTP id f5mr649618ibb.197.1311854882973; Thu, 28 Jul 2011 05:08:02 -0700 (PDT) Received: by 10.231.111.20 with HTTP; Thu, 28 Jul 2011 05:08:02 -0700 (PDT) Date: Thu, 28 Jul 2011 14:08:02 +0200 Message-ID: From: Paco Cortes To: wdec@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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 Jul 2011 12:08:04 -0000 Hi Wojciech, two comments on the 3gpp sections of draft-dec-stateless-4v6-02. First, the definition of "Rx" is missing in section 4.2.1. Second, the table in section 4.2.2 claims "No discernible impact" for "AF Application Function" for the 4V6 translation mode. This is not fully correct. The PCC architecture support a plurality of AFs communication over Rx with the PCRF, and most of them "interact" in some way with the end user payload. An AF might terminate, proxy or transparently inspect a subset of the UE traffic (for instance control signalling, like SIP). An AF might also terminate, proxy or transparently inspect all UE traffic (application server acting as AF, deep packet inspection device, ...). And the most important point: An AF might located in different locations inside the operators networks, or even outside the operators network. Referring to your own "Figure 2" in the draft, this means that for IPv4 traffic an AF might "intercept" traffic between the "PDN-Gw" and the "S46 Gateway", i.e. with an IPv6 header, BUT it might also intercept traffic behind the "S46 Gateway", i.e., with an IPv4 header. I propose to change the impact to "No impact for IPv6. Feature to map IPv4-IPv6 addresses may be needed only in case of IPv4-only applications". I'm aware that it would be theoretically possible to "hide" this impact from an AF by using a more complex PCRF implementation that "translates" IPv4 addresses in Rx message (including TFTs) into the mapped IPv6, but this would imply limitations, and would just be one implementation possibility. I believe that this draft should not assume a specific implementation, unless clearly documented. br, Paco From satoru.matsushima@gmail.com Thu Jul 28 06:03:31 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9843F21F8C90 for ; Thu, 28 Jul 2011 06:03:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otOgrW2D-fzw for ; Thu, 28 Jul 2011 06:03:31 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2E3921F8C8F for ; Thu, 28 Jul 2011 06:03:30 -0700 (PDT) Received: by qwc23 with SMTP id 23so1743778qwc.31 for ; Thu, 28 Jul 2011 06:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ehqlBvX/P1WCqp+dnsx65dqzTQIkCCFLRbx60083cGQ=; b=CCB1dhOiGDqrLVAVCmV9qU5euOeyyPw1IqdpjViuTvo0vRYV2XT5uCjSpSXOHfBTmZ BN4w1dyncbJ91NKbD33bRzTKYd4PbVrC00Pn4gmj7xqBbh3FoZYPsZyA5Ufe51RRsODF 8qPS2ttCwGXyOx1I2BV/G0eY8Cc5zaF6P6mY4= Received: by 10.229.44.27 with SMTP id y27mr737118qce.249.1311858209539; Thu, 28 Jul 2011 06:03:29 -0700 (PDT) Received: from dhcp-53a8.meeting.ietf.org (dhcp-53a8.meeting.ietf.org [130.129.83.168]) by mx.google.com with ESMTPS id s14sm652925qct.42.2011.07.28.06.03.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 06:03:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Thu, 28 Jul 2011 09:03:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4731A0B0-AB42-435D-835E-31D59B0AA867@gmail.com> References: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> To: Tina TSOU X-Mailer: Apple Mail (2.1244.3) Cc: "softwires@ietf.org" Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:03:31 -0000 Thank you Tina, it is also pointed out by Dave yesterday. Interestingly, Qiong pointed out another issue, which is routing = scalability. I agree with Qiong that routing scalability is significant issue. FWIW, I would recommend something, LISP for example, could help him. Best regards, --satoru On 2011/07/28, at 6:46, Tina TSOU wrote: > Matsushima-san, > In this draft, we may need to refer or define the definition of=20 > - Stateful operation > - Stateless operation > - Dynamic port allocation > - Static port allocation >=20 > Hope in this way, the discussion could be easier. >=20 >=20 > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html >=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Satoru Matsushima > Sent: Thursday, July 28, 2011 5:56 AM > To: Qiong > Cc: softwires@ietf.org > Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain >=20 > Hi Qiong, >=20 > On 2011/07/28, at 4:31, Qiong wrote: >=20 >> Hi, Satoru, >>=20 >> Thanks a lot for your suggestion and I understand it can work. But in = my understanding, it still lies some differences with the so-called = "totally stateless solution".=20 >=20 > I don't mean that 'totally stateless solution' isn't a part of routing = system.=20 >=20 >> Suppose there is only one domain, when an IPv4 downstream packet = arrives at stateless gateway, it would firstly forward to the virtual = tunnel interface (take 4V6 Mapped Tunnel for example) with only one = default route. Then after encapsulated with a uniform IPv6 prefix and = IPv4 prefix, etc, it will lookup IPv6 routing table and forward to 4v6 = CE. Here, actually there is no need to do routing lookup for IPv4 = address expect one default route. >=20 > You already did routing when you found default route. >=20 >=20 >> However, if we introduce multiple domains with multiple IPv4 prefix = pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry = number of IPv4 routing table will be N1+N2+N3+..+Nm. In current = situation, Nm would not be a small number anymore. So maybe some more = optimization work will still be needed to make it more "stateless" ? =20 >=20 > What do you mean 'the entry number of IPv4 routing table'?=20 > Do you presume that your IGP routing has almost 300K routes as same = number of current internet full routes? >=20 > Best regards, > --satoru >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Thu Jul 28 06:37:39 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A06B21F874A for ; Thu, 28 Jul 2011 06:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiIL-hapwdYP for ; Thu, 28 Jul 2011 06:37:37 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 50EE621F8569 for ; Thu, 28 Jul 2011 06:37:36 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id 49F977000087; Thu, 28 Jul 2011 15:37:35 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id 11DE0700008D; Thu, 28 Jul 2011 15:37:31 +0200 (CEST) X-SFR-UUID: 20110728133735732.11DE0700008D@msfrf2111.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 Jul 2011 15:37:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99815557-036E-469D-AACB-473403B59393@laposte.net> References: <741D71AA-24D1-4EA7-9409-45175D603213@free.fr> To: Softwires-wg X-Mailer: Apple Mail (2.1084) Subject: Re: [Softwires] Support of multiple IPv4 prefixes in a network with 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 Jul 2011 13:37:39 -0000 Hi, all, How to use the 4rd stateless address mapping to support, in a provider = network having multiple IPv4 prefixes, both exclusive and shared IPv4 = addresses, is an typical question. Starting from a comment from Quiong Sun, here are some views on the = subject.=20 Le 28 juil. 2011 =E0 11:53, Qiong a =E9crit : > Hi, Remi, >=20 > Thanks for your comments. I agree with you that in this situation, = stateless solution still superior to stateful ones from scalability = aspect. It is "per independent IPv4 prefix" mapping rule database, = rather than customer-based. But it still may have some tradeoff for = domain realm. The larger the domain it covers, the more independent IPv4 = prefix there will be. And also the whole domain has to synchronize these = mapping rules.=20 >=20 > I think this problem would be quite common for large broadband service = providers who already have a huge amount of customers. Do we have to = transfer all these legacy customers with public IPv4 address into = shared-mode directly? In our consideration, we think it might be better = to offer shared-mode solution for new customers only and leave the = legacy customers with non-shared-mode solution to avoid complaint from = address sharing. > As a result, we have to deal with the co-existence scenario for at = least shared-mode and non-shared-mode. =20 Yes, I think this will prove a frequent requirement. Complementary comments: 1. A possible approach, to progressively reduce the number of used IPv4 = prefixes, consists in proposing two different tariffs: - one for length L of IPv6 prefixes, and full IPv4 address per customer, - the other, slightly lower, for length L+K of IPv6 prefixes, and shared = IPv4 address per customer. Thus the number of full-address customers can be expected to decrease, = and the longest IPv4 prefixes can be expected to progressively be = reclaimed. 2. With a dihcotomic search for a prefix match in BR's and CE', the = performance impact of having a large number of rules can remain quite = limited, both in CE's and in BR's. (Scalability of the BR function is in any case ensured by the fact that = BR's are, with respect to individual-customer states, completely = stateless (and also, of course, with respect to transport-connection = states). 3. By configuring appropriately as many mapping rules as there are IPv4 = prefixes, all IPv4 prefixes can be used without any impact on IPv6 = routing (no "IPv4 entropy" exported to IPv6). This is illustrated in sec 3.2 of = tools.ietf.org/html/draft-despres-softwire-sam-01 (not too easy to read, = sorry for that, but the subject had some intrinsic sophistication and = was new). (Incidentally this 4rd founding draft wasn't included Ole's 4rd-history = slide yesterday, but is IMHO worth looking at for anyone interested in = the genesis of 4rd.)=20 Hope it helps. Regards, RD > I agree that this mapping specification can be applied to all = stateless solutions, separated from specific solution. Thanks for your = suggestion. >=20 > Best wishes >=20 > Qiong Sun=20 > =20 >=20 From behcetsarikaya@yahoo.com Thu Jul 28 06:45:11 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3476121F8B99 for ; Thu, 28 Jul 2011 06:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_50=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mxDJwJunVLG for ; Thu, 28 Jul 2011 06:45:10 -0700 (PDT) Received: from nm19-vm4.bullet.mail.ne1.yahoo.com (nm19-vm4.bullet.mail.ne1.yahoo.com [98.138.91.179]) by ietfa.amsl.com (Postfix) with SMTP id 8C07321F8B98 for ; Thu, 28 Jul 2011 06:45:10 -0700 (PDT) Received: from [98.138.90.53] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 28 Jul 2011 13:45:06 -0000 Received: from [98.138.89.250] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 28 Jul 2011 13:45:06 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 28 Jul 2011 13:45:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 315279.42365.bm@omp1042.mail.ne1.yahoo.com Received: (qmail 7681 invoked by uid 60001); 28 Jul 2011 13:45:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311860705; bh=V3ruIEFVwX6cW0Ruo0IIpEH3yrBwnHTN8FmJwiYxu1k=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=6Rhi0256XTYgbuBAZog5TzK8So9wbwFV65q6/d6d0cvVEwIZW7bkSZQe+DnCEHeoAfd6U8doE+IfqJ7QVBwySspsUGwtMbmlYC2fpU0NMxAC82mHifBzNWsCbg86zvALC98f64xIjf8SfFqN7uRT4g5f9gUEZd3zZBHbrLXjbMI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=vPK3T1iaui0psQPktVO6FVzQnEg7smXCWhYmaE2o07a0bZ4oaT/Fq5s2JWFh/ElrF7dB+WM3+ONkciz4RU3KQej7lCqb3KnHnSB59WG7+T7xVDhwMT7s7N2b1vSw/QWMeRX8zIEoBALuWUick8MkpI/DZxngqkoQW7BO+dAkobo=; X-YMail-OSG: MOW8PW4VM1mruQ48sentr21rwoGu8s.exYdovq_XPsqAAqv n7sQGL6BTAEGuEqOMlb63xZ7HtJTmRU_ft1cB0ygZQxyPfTJZDFx737_bDOg TA3epQoe8amHUZWt842BtqG234vLLkbrHrtZNXsyZQOAgkeRUa9olWj6jIeS NnHyRub.gLone1fPwhm99OnS61UBNFoO.8sM5JbZuw0J6wy0Ur._QFtN4f2A LIwJ8aDPzDsxr67oOr5t0ih5isCL0COOjfK2yleB_1kHtd2O8LGEui_.FzL3 eHvVR.9VwNDnkXj94pZ67bj6SFQkECzS6A_KcaRbXu0QxPtpd2xSOkJ_Lw3v kKa7oFTSZqOrJ61qiD_hfR2wpWihqa8nO_QfOyaiWSGlgxmIH1vOAm_kGFbi aCg6yRjqP_hq2Lg-- Received: from [130.129.87.243] by web111407.mail.gq1.yahoo.com via HTTP; Thu, 28 Jul 2011 06:45:05 PDT X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.112.310352 References: <0962B0BEF842A24191AD9BE41A8DD2FC018DE5E5@ch-mailsrv.rd.francetelecom.fr> Message-ID: <1311860705.91619.YahooMailRC@web111407.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 06:45:05 -0700 (PDT) From: Behcet Sarikaya To: xiaohong.deng@orange-ftgroup.com, Yiu_Lee@Cable.Comcast.com, softwires@ietf.org In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC018DE5E5@ch-mailsrv.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:45:11 -0000 > >Hi Yiu,all, > >I see the first use case worth good value to work on, as the reason I stated >during meeting: operators would happy with it because otherwise (the second >case), means moving AFTR lower location, which ends up with more CAPEX. > This is not correct. Please take a look at Broadband Forum document WT-242 on IPv6 migration (or read my previous mail :-) ). You can not make one correct from two wrongs. Regards, Behcet From yiu_lee@cable.comcast.com Thu Jul 28 06:48:37 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EE921F8B99 for ; Thu, 28 Jul 2011 06:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.135 X-Spam-Level: X-Spam-Status: No, score=-101.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4MV3P2wJ5+z for ; Thu, 28 Jul 2011 06:48:36 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 74DF521F8B43 for ; Thu, 28 Jul 2011 06:48:36 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46518923; Thu, 28 Jul 2011 07:52:58 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Thu, 28 Jul 2011 09:48:17 -0400 From: "Lee, Yiu" To: Behcet Sarikaya , "xiaohong.deng@orange-ftgroup.com" , "softwires@ietf.org" Thread-Topic: [Softwires] DS-lite Multicast Thread-Index: AQHMTS0An2I976xkE0yADZNNKdVvAA== Date: Thu, 28 Jul 2011 13:48:16 +0000 Message-ID: In-Reply-To: <1311860705.91619.YahooMailRC@web111407.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [130.129.22.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1096D2270F4FDC4C9810A7AEF01AB273@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:48:37 -0000 Dear Behcat, Can you elaborate it a little more? I don=B9t quite follow what makes one correct from two wrongs. What is the technical argument of this statement? Thanks, Yiu On 7/28/11 9:45 AM, "Behcet Sarikaya" wrote: > > >> >>Hi Yiu,all, >>=20 >>I see the first use case worth good value to work on, as the reason I >>stated=20 >>during meeting: operators would happy with it because otherwise (the >>second =20 >>case), means moving AFTR lower location, which ends up with more CAPEX. >>=20 > >This is not correct. >Please take a look at Broadband Forum document WT-242 on IPv6 migration >(or read=20 >my previous mail :-) ). >You can not make one correct from two wrongs. > >Regards, > >Behcet > From cb.list6@gmail.com Thu Jul 28 06:57:35 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9377F21F8BFE for ; Thu, 28 Jul 2011 06:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69kECZTKmKY3 for ; Thu, 28 Jul 2011 06:57:34 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 525C221F8BF0 for ; Thu, 28 Jul 2011 06:57:34 -0700 (PDT) Received: by wwg11 with SMTP id 11so4015560wwg.1 for ; Thu, 28 Jul 2011 06:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nk58C37V+sk2MRckOea5VQZ+EgTWsNEJfhHm1973aQQ=; b=C6cOLnWCNpiKKJwEAkYJ6VHuRnEj/eavcEboN9XelQHmMxxyrz+VLYjWhgHqIUTRWT rrs7z4o1FJxstJBdRa19DTQ1Hx/luotJ6Nl9I7Y6xLYKIkZf77L2RLQWzQzwufStwKv5 iMIK8TE95W2XClL8TVEHzyw8TFenbMO3tj7tY= MIME-Version: 1.0 Received: by 10.227.12.18 with SMTP id v18mr44245wbv.72.1311861453219; Thu, 28 Jul 2011 06:57:33 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 06:57:33 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 06:57:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 06:57:33 -0700 Message-ID: From: Cameron Byrne To: Paco Cortes Content-Type: multipart/alternative; boundary=002215975fe2e9e81604a9218b57 Cc: softwires@ietf.org, wdec@cisco.com Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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 Jul 2011 13:57:35 -0000 --002215975fe2e9e81604a9218b57 Content-Type: text/plain; charset=ISO-8859-1 On Jul 28, 2011 5:08 AM, "Paco Cortes" wrote: > > Hi Wojciech, > > two comments on the 3gpp sections of draft-dec-stateless-4v6-02. > > First, the definition of "Rx" is missing in section 4.2.1. > > Second, the table in section 4.2.2 claims "No discernible impact" for > "AF Application Function" for the 4V6 translation mode. This is not > fully correct. > The PCC architecture support a plurality of AFs communication over Rx > with the PCRF, and most of them "interact" in some way with the end > user payload. > An AF might terminate, proxy or transparently inspect a subset of the > UE traffic (for instance control signalling, like SIP). > An AF might also terminate, proxy or transparently inspect all UE > traffic (application server acting as AF, deep packet inspection > device, ...). > And the most important point: An AF might located in different > locations inside the operators networks, or even outside the operators > network. > Referring to your own "Figure 2" in the draft, this means that for > IPv4 traffic an AF might "intercept" traffic between the "PDN-Gw" and > the "S46 Gateway", i.e. with an IPv6 header, BUT it might also > intercept traffic behind the "S46 Gateway", i.e., with an IPv4 header. > > I propose to change the impact to "No impact for IPv6. Feature to map > IPv4-IPv6 addresses may be needed only in case of IPv4-only > applications". > > I'm aware that it would be theoretically possible to "hide" this > impact from an AF by using a more complex PCRF implementation that > "translates" IPv4 addresses in Rx message (including TFTs) into the > mapped IPv6, but this would imply limitations, and would just be one > implementation possibility. I believe that this draft should not > assume a specific implementation, unless clearly documented. > +1, I believe this section causes confusion. I have not had time to do a full review. Tunneling traffic breaks pcc and a new bearer type is a tall order. We already visited these issues when concluding 6rd and ds-lite were not good fits for 3gpp. Cb > br, > Paco > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --002215975fe2e9e81604a9218b57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 28, 2011 5:08 AM, "Paco Cortes" <pacosaddress@googlemail.com> wrote:
>
> Hi Wojciech,
>
> two comments on the 3gpp sections of draft-dec-stateless-4v6-02.
>
> First, the definition of "Rx" is missing in section 4.2.1. >
> Second, the table in section 4.2.2 claims "No discernible impact&= quot; for
> "AF Application Function" for the 4V6 translation mode. This= is not
> fully correct.
> The PCC architecture support a plurality of AFs communication over Rx<= br> > with the PCRF, and most of them "interact" in some way with = the end
> user payload.
> An AF might terminate, proxy or transparently inspect a subset of the<= br> > UE traffic (for instance control signalling, like SIP).
> An AF might also terminate, proxy or transparently inspect all UE
> traffic (application server acting as AF, deep packet inspection
> device, ...).
> And the most important point: An AF might located in different
> locations inside the operators networks, or even outside the operators=
> network.
> Referring to your own "Figure 2" in the draft, this means th= at for
> IPv4 traffic an AF might "intercept" traffic between the &qu= ot;PDN-Gw" and
> the "S46 Gateway", i.e. with an IPv6 header, BUT it might al= so
> intercept traffic behind the "S46 Gateway", i.e., with an IP= v4 header.
>
> I propose to change the impact to "No impact for IPv6. Feature to= map
> IPv4-IPv6 addresses may be needed only in case of =A0IPv4-only
> applications".
>
> I'm aware that it would be theoretically possible to "hide&qu= ot; this
> impact from an AF by using a more complex PCRF implementation that
> "translates" IPv4 addresses in Rx message (including TFTs) i= nto the
> mapped IPv6, but this would imply limitations, and would just be one > implementation possibility. I believe that this draft should not
> assume a specific implementation, unless clearly documented.
>

+1, I believe this section causes confusion.

I have not had time to do a full review.

Tunneling traffic breaks pcc and a new bearer type is a tall order. We a= lready visited these issues when concluding 6rd and ds-lite were not good f= its for 3gpp.

Cb

> br,
> =A0Paco
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/softwires

--002215975fe2e9e81604a9218b57-- From behcetsarikaya@yahoo.com Thu Jul 28 07:10:30 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E6821F8784 for ; Thu, 28 Jul 2011 07:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRBU93e6Sz5D for ; Thu, 28 Jul 2011 07:10:30 -0700 (PDT) Received: from nm3-vm0.bullet.mail.sp2.yahoo.com (nm3-vm0.bullet.mail.sp2.yahoo.com [98.139.90.230]) by ietfa.amsl.com (Postfix) with SMTP id 445D421F86DC for ; Thu, 28 Jul 2011 07:10:30 -0700 (PDT) Received: from [98.139.91.66] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 14:10:12 -0000 Received: from [98.139.91.60] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 14:10:12 -0000 Received: from [127.0.0.1] by omp1060.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 14:10:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 204791.16954.bm@omp1060.mail.sp2.yahoo.com Received: (qmail 21061 invoked by uid 60001); 28 Jul 2011 14:10:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311862211; bh=lZ8lm5ytWOlSrAASIZfhfkEWCnQ+J/XZqmfq4ngbxew=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=V5RGzbcaOYOO7pl9S/En4+0N6LYnGUCEQVaiMr2dAwDUAVNG+wyQYF9oZilFxamwJklFI8LKX3397IcDspTEfXgqJJQdIhCA4C1u+qFMCM4hSRjHhxkAy0jFgrC+/jo1Ui7nMY/VAPLGoYyPcMpwBZyz/s7lwxr318PRoanfpGs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zk6ATaapMHW3YhWHRtdrS/+FesmE/mqAlUK5zkv6CYMMVIWyX5/pb3WL8VgLPvkc2+Zn5w56BQ8ftP8MBOydv/xVynQVjJ/yGp/phdtrTJES+dd79Sb3x8smENow8ceLWsH7/ikP8WlFe+7ibBNqyh3Jr1YLjUxoRRnXPKD4ALU=; X-YMail-OSG: 579DxJgVM1nL4xgQGj0wMhgjUABFEtxgCHtIO.g1dxfHdJS TTNnYqJ9u0Bnlpk3SM0CM0GRqSP2xrmI4zAOiu1DRxX0GXT6sf2FCN1XYMnu udnI412ROFhRWGAkkNZ6XS3q_BKR66YoVSGsZTpePdXzZZtcsN8AzpUvsNIv qMG2TpCv0nsHfp4.fkcLqTIQeeYRoVKDirAceygTyfZZIpvf9zKKOMtheGbb FIUWD4GgRUnOnWCef2F9bfHHdwT5amVooJtpu8oVFZlPrN58o8tCIowM.qZA 5Wgp9C0BkknPnqf85tpG_QYa1SzINtf_29lV8iQlagpopAI0g74.Plr8r1zR EOFIpXXEoQSc6gNjo9e..BNTemdtHmR8v4YHkmyBqUZBn34qA28G01acqZ3_ VwARC5ZO80.XeHQ-- Received: from [130.129.87.243] by web111407.mail.gq1.yahoo.com via HTTP; Thu, 28 Jul 2011 07:10:11 PDT X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.112.310352 References: <3256_1311835978_4E31074A_3256_189264_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF2E28CDA@PUEXCB1C.nanterre.francetelecom.fr> Message-ID: <1311862211.15521.YahooMailRC@web111407.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 07:10:11 -0700 (PDT) From: Behcet Sarikaya To: christian.jacquenet@orange-ftgroup.com, "Lee, Yiu" , "softwires@ietf.org" In-Reply-To: <3256_1311835978_4E31074A_3256_189264_1_983A1D8DA0DA5F4EB747BF34CBEE5CD14AF2E28CDA@PUEXCB1C.nanterre.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:10:31 -0000 +1=0A=0ABehcet=0A=0A=0A>=0A>From: "christian.jacquenet@orange-ftgroup.com" = =0A>=0A>To: "Lee, Yiu" ; "softwires@ietf.org" =0A>=0A>Sent: Thu= , July 28, 2011 1:52:56 AM=0A>Subject: Re: [Softwires] DS-lite Multicast=0A= >=0A>=0A>Dear all,=0A> =0A>I would privilege the first use case, as describ= ed =0A>in http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-0= 4.=0A> =0A>Cheers,=0A> =0A>Christian.=0A>=0A>=0A___________________________= _____=0ADe : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.o= rg] De la =0Apart de Lee, Yiu=0A>>Envoy=E9 : mercredi 27 juillet 2011 20= :19=0A>>=C0 : softwires@ietf.org=0A>>Objet : [Softwires] DS-lite Multica= st=0A>>=0A>>=0A>>Hi WG,=0A>>=0A>>=0A>>In today meeting, we presented two dr= afts on to enable multicast in DS-lite. =0A>=0A>>I think they target dif= ferent use cases:=0A>>=0A>>=0A>>The use case of =0A>>http://tools.ietf.org/= html/draft-qin-softwire-dslite-multicast-04 is to =0A>>deliver multicast= over DS-lite in an IPv6 multicast enabled network.=0A>>=0A>>=0A>>The use c= ase of =0A>>http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemultic= ast-00 is to =0A=0A>>deliver multicast over DS-lite in an IPv6 multicast= disabled network.=0A>>=0A>>=0A>>I think both drafts target different use c= ases. My question to the WG is: =0A>>Should we work on both use cases? I= f not, which use case the WG should work =0A>>on =0A>>first?=0A>>=0A>>= =0A>>I really want to hear people comments. Please raise your voice in the = ML.=0A>>=0A>>=0A>>Thanks,=0A>>/Yiu=0A>> =0A>>=0A>>=0A>>=0A>>=0A********= ************************************************************************ = =0A=0AIMPORTANT.Les informations contenues dans ce message electronique y c= ompris les =0Afichiers attaches sont strictement confidentielles et peuvent= etre protegees par =0A=0Ala loi. Ce message electronique est destine exclu= sivement au(x) destinataire(s) =0Amentionne(s) ci-dessus. Si vous avez recu= ce message par erreur ou s il ne vous =0Aest pas destine, veuillez immedia= tement le signaler a l expediteur et effacer =0Ace message et tous les fi= chiers eventuellement attaches. Toute lecture, =0Aexploitation ou transmiss= ion des informations contenues dans ce message est =0Ainterdite. Tout messa= ge electronique est susceptible d alteration. A ce titre, =0Ale Groupe Fran= ce Telecom decline toute responsabilite notamment s il a ete =0Aaltere, def= orme ou falsifie. De meme, il appartient au destinataire de s assurer =0A= =0Ade l absence de tout virus. IMPORTANT.This e-mail message and any attac= hments =0Aare strictly confidential and may be protected by law. This messa= ge is intended =0Aonly for the named recipient(s) above. If you have receiv= ed this message in =0Aerror, or are not the named recipient(s), please imme= diately notify the sender =0Aand delete this e-mail message. Any unauthoriz= ed view, usage or disclosure =0Aofthis message is prohibited. Since e-mail = messages may not be reliable, France =0ATelecom Group shall not be liable f= or any message if modified, changed or =0Afalsified. Additionally the recip= ient should ensure they are actually virus =0Afree. =0A********************= ************************************************************ From despres.remi@laposte.net Thu Jul 28 07:12:13 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E46021F8C8A for ; Thu, 28 Jul 2011 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOs9JuY1ECIY for ; Thu, 28 Jul 2011 07:12:13 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id B645821F8C8E for ; Thu, 28 Jul 2011 07:12:10 -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 95078940103; Thu, 28 Jul 2011 16:12:05 +0200 (CEST) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 16:12:04 +0200 Message-Id: To: Alain Durand Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: [Softwires] With 6rd, reducing the number of assigned ports needs not be difficult X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:12:13 -0000 Alain, Unless I misheard, you said yesterday in the Softwires meeting that you = thought it whould be difficult to reduce assigned numbers of ports in a = completely stateless solution (without per customer state in BR's). AFAIK, this isn't difficult with the 4rd stateless address mapping. It = would only require a slight amendment of the current spec. Thus, a = reduction of the number of ports of a particular customer, or of a class = of customers, is done by increasing the length of its assigned IPv6 = prefix(es). Thus, each bit added to the IPv6-prefix length divides by = two the number of ports. Details of the amendment can be discussed in = due time. In many typical environments, the fact that each port-set reduction is = at least a division by 2 shouldn't be AFAIK a problem . (Address = prefixes have always defined addressing spaces whose sizes vary by 2^k = factors.) Regards, RD From behcetsarikaya@yahoo.com Thu Jul 28 07:13:48 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A22121F8C8E for ; Thu, 28 Jul 2011 07:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqDNjZ347+93 for ; Thu, 28 Jul 2011 07:13:47 -0700 (PDT) Received: from nm3-vm0.bullet.mail.sp2.yahoo.com (nm3-vm0.bullet.mail.sp2.yahoo.com [98.139.90.230]) by ietfa.amsl.com (Postfix) with SMTP id C555B21F8C88 for ; Thu, 28 Jul 2011 07:13:47 -0700 (PDT) Received: from [98.139.91.68] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 14:13:44 -0000 Received: from [98.139.91.11] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 14:13:44 -0000 Received: from [127.0.0.1] by omp1011.mail.sp2.yahoo.com with NNFMP; 28 Jul 2011 14:13:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 620913.77897.bm@omp1011.mail.sp2.yahoo.com Received: (qmail 23455 invoked by uid 60001); 28 Jul 2011 14:13:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1311862424; bh=kpQ/n15JPp4hbX1w3mZ6EMxxCv5yR0pf50SYmZ7jC2Q=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aA7Ilwm591SB4EBArpkMaNj0345zD+cKvAhfp60uUNcvOUIgyhnhxlw+65ICk7uAvCqiI4TTkzW1RnvhaOrVnN+LeRgLdyrjVLZzFA4C0Lvn27J43YoJ1S68Ai5ZbGh58x1oha7NAxLHwIKvd3JgTCy+1W6A6w1sv4ifaP+tSKo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=18os/+p+U/Tf9NULMDQFtFm0tZ8p8xqPDX6UxZCdl1ke0rin0PRYs3dWkyaL7c7mbVYWO3xT0mAB4as5I259GsmYAL82oRc7+aAiZVLmtpIaYp35GPjy3qaCIC7j00lJhkSlHpKeAU2lZ6+UptTnF0+F6ADFHK9xNPfig/SvMsM=; X-YMail-OSG: RTIpyr4VM1k4x6hDQCs6U7LhO9kF0DKEQYdmHzpIPPCx0Ol diyKeQhQEnetkujPXXmeAz1uCBIvuz2_H3Di0_F1pTgAUSfo7BwcFZh8RMjX VRz_DyfykfNNJORVGuWrf9IK39JzfuqNFTDsEEu3wI2xnN9d0m.ACqk9rxbG hJq.LLNBc5KhQyypkZ6DOJt45qw6eNx0cRbmBCmyYN.BxLzK2U9ti1.JU91W aBGc_RdizDCJJHeMrVwRoUzqynfYF1XibOhwg1ohjYGbIzxLOli9MC9KIn7E yMiWGrRhdRNpxIK7CWA1BigavZR5IgRI3rt2bLPYH_REUF0R7IVWl_BilYYS 4JHs3.yDFp1VdsFtkDURAuH9U4e98474fQ1bHD3r0WJT1fZCPJCFsvG8rRw3 8ERHTP146_0ocsUJf3UuUPPpgIODEMfsXZTSra2mfteCWG8noP_8rDu.WNdZ MEBkfUouc5sOSftRzzcLAGhmPg_1Vh57z1X_zC8XCC.qvfwHw2D1W1eu9VxX bIr9.iQI- Received: from [130.129.87.243] by web111407.mail.gq1.yahoo.com via HTTP; Thu, 28 Jul 2011 07:13:43 PDT X-Mailer: YahooMailRC/574 YahooMailWebService/0.8.112.310352 References: Message-ID: <1311862423.23432.YahooMailRC@web111407.mail.gq1.yahoo.com> Date: Thu, 28 Jul 2011 07:13:43 -0700 (PDT) From: Behcet Sarikaya To: "Lee, Yiu" , "xiaohong.deng@orange-ftgroup.com" , "softwires@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:13:48 -0000 =0A=0AHi Yiu,=0A=0AIt was a joke.=0A=0AWe need some sense of humor in IETF.= =0A=0AI also support http://tools.ietf.org/html/draft-qin-softwire-dslite-m= ulticast-04=0A=0ABehcet=0A=0A> Dear Behcat,=0A> =0A> Can you elaborate it a= little more? I don=B9t quite follow what makes one=0A> correct from two w= rongs. What is the technical argument of this statement?=0A> =0A> Thanks,= =0A> Yiu=0A> =0A> On 7/28/11 9:45 AM, "Behcet Sarikaya" wrote:=0A> =0A> >=0A> >=0A> >>=0A> >>Hi Yiu,all,=0A> >> =0A> >>I= see the first use case worth good value to work on, as the reason I=0A> = >>stated =0A> >>during meeting: operators would happy with it because oth= erwise (the=0A> >>second =0A> >>case), means moving AFTR lower location, = which ends up with more CAPEX.=0A> >> =0A> >=0A> >This is not correct.=0A= > >Please take a look at Broadband Forum document WT-242 on IPv6 migration= =0A> >(or read =0A> >my previous mail :-) ).=0A> >You can not make one corr= ect from two wrongs.=0A> >=0A> >Regards,=0A> >=0A> >Behcet=0A> >=0A> =0A> From yiu_lee@cable.comcast.com Thu Jul 28 07:16:04 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0E421F8AF5 for ; Thu, 28 Jul 2011 07:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.258 X-Spam-Level: X-Spam-Status: No, score=-100.258 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_33=0.6, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUAKFp1Oq+Bf for ; Thu, 28 Jul 2011 07:16:04 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id DC41621F88A5 for ; Thu, 28 Jul 2011 07:16:03 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.46525468; Thu, 28 Jul 2011 08:20:48 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 28 Jul 2011 10:15:59 -0400 From: "Lee, Yiu" To: Behcet Sarikaya , "xiaohong.deng@orange-ftgroup.com" , "softwires@ietf.org" Thread-Topic: [Softwires] DS-lite Multicast Thread-Index: AQHMTTDekCuVuBJm1kW3fJKtJPOAeQ== Date: Thu, 28 Jul 2011 14:15:57 +0000 Message-ID: In-Reply-To: <1311862423.23432.YahooMailRC@web111407.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [130.129.22.164] Content-Type: text/plain; charset="euc-kr" Content-ID: <332B7B130FBCA84581A3CF3C367E6FFC@cable.comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:16:04 -0000 QWguIE9rIDotKSBFbmdsaXNoIGlzbid0IG15IGZpcnN0IGxhbmd1YWdlLiBQbGVhc2UgYmVhciB3 aXRoIG1lIDotcA0KDQpPbiA3LzI4LzExIDEwOjEzIEFNLCAiQmVoY2V0IFNhcmlrYXlhIiA8YmVo Y2V0c2FyaWtheWFAeWFob28uY29tPiB3cm90ZToNCg0KPg0KPg0KPkhpIFlpdSwNCj4NCj5JdCB3 YXMgYSBqb2tlLg0KPg0KPldlIG5lZWQgc29tZSBzZW5zZSBvZiBodW1vciBpbiBJRVRGLg0KPg0K PkkgYWxzbyBzdXBwb3J0IA0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXFpbi1z b2Z0d2lyZS1kc2xpdGUtbXVsdGljYXN0LTA0DQo+DQo+QmVoY2V0DQo+DQo+PiBEZWFyIEJlaGNh dCwNCj4+IA0KPj4gQ2FuIHlvdSBlbGFib3JhdGUgaXQgYSBsaXR0bGUgbW9yZT8gSSBkb26p9nQg cXVpdGUgZm9sbG93ICB3aGF0IG1ha2VzIG9uZQ0KPj4gY29ycmVjdCBmcm9tIHR3byB3cm9uZ3Mu IFdoYXQgaXMgdGhlIHRlY2huaWNhbCBhcmd1bWVudCBvZiAgdGhpcw0KPj5zdGF0ZW1lbnQ/DQo+ PiANCj4+IFRoYW5rcywNCj4+IFlpdQ0KPj4gDQo+PiBPbiA3LzI4LzExIDk6NDUgQU0sICJCZWhj ZXQgIFNhcmlrYXlhIiA8YmVoY2V0c2FyaWtheWFAeWFob28uY29tPg0KPj53cm90ZToNCj4+IA0K Pj4gPg0KPj4gPg0KPj4gPj4NCj4+ID4+SGkgIFlpdSxhbGwsDQo+PiA+PiANCj4+ID4+SSBzZWUg dGhlICBmaXJzdCB1c2UgY2FzZSB3b3J0aCBnb29kIHZhbHVlIHRvIHdvcmsgb24sIGFzIHRoZSAg cmVhc29uDQo+PkkNCj4+ID4+c3RhdGVkIA0KPj4gPj5kdXJpbmcgIG1lZXRpbmc6IG9wZXJhdG9y cyB3b3VsZCAgaGFwcHkgd2l0aCBpdCBiZWNhdXNlIG90aGVyd2lzZSAodGhlDQo+PiA+PnNlY29u ZCAgDQo+PiA+PmNhc2UpLCAgbWVhbnMgbW92aW5nIEFGVFIgbG93ZXIgbG9jYXRpb24sIHdoaWNo IGVuZHMgdXAgd2l0aCBtb3JlDQo+PkNBUEVYLg0KPj4gPj4gDQo+PiA+DQo+PiA+VGhpcyBpcyBu b3QgY29ycmVjdC4NCj4+ID5QbGVhc2UgdGFrZSBhICBsb29rIGF0IEJyb2FkYmFuZCBGb3J1bSBk b2N1bWVudCBXVC0yNDIgb24gSVB2Ng0KPj5taWdyYXRpb24NCj4+ID4ob3IgcmVhZCANCj4+ID5t eSBwcmV2aW91cyBtYWlsIDotKSApLg0KPj4gPllvdSBjYW4gbm90IG1ha2Ugb25lIGNvcnJlY3Qg ZnJvbSB0d28gIHdyb25ncy4NCj4+ID4NCj4+ID5SZWdhcmRzLA0KPj4gPg0KPj4gPkJlaGNldA0K Pj4gPg0KPj4gDQo+PiANCg0K From jacniq@gmail.com Thu Jul 28 07:19:13 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DDF21F8C1A for ; Thu, 28 Jul 2011 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRquLBjNjiZH for ; Thu, 28 Jul 2011 07:19:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E509421F8B20 for ; Thu, 28 Jul 2011 07:19:11 -0700 (PDT) Received: by vxi40 with SMTP id 40so2472773vxi.31 for ; Thu, 28 Jul 2011 07:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EejckwP3HjYxaByoZFhWeiBZnTQRyUUKuj/avtj14Qw=; b=jCxmweGVuMoHit2ROrTEWi17yT7PRXl+D5XVV7SqFbGWiDXelwjwiAW+UePWSt171x JwLYDy06uJUrEi2sOI9JnoTW2MiW4aGGSbt9zVeE8R87mebarvDEttrTY7cLqAK/NbpQ moASm7A9Xqgt3Q0ekM2zdPn/MyPu7/ywR+fqY= MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr97337vdg.137.1311862749630; Thu, 28 Jul 2011 07:19:09 -0700 (PDT) Received: by 10.52.115.9 with HTTP; Thu, 28 Jul 2011 07:19:09 -0700 (PDT) In-Reply-To: <99815557-036E-469D-AACB-473403B59393@laposte.net> References: <741D71AA-24D1-4EA7-9409-45175D603213@free.fr> <99815557-036E-469D-AACB-473403B59393@laposte.net> Date: Thu, 28 Jul 2011 22:19:09 +0800 Message-ID: From: Jacni Qin To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf307811802f921804a921d945 Cc: Softwires-wg Subject: Re: [Softwires] Support of multiple IPv4 prefixes in a network with 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 Jul 2011 14:19:13 -0000 --20cf307811802f921804a921d945 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, On Thu, Jul 28, 2011 at 9:37 PM, R=E9mi Despr=E9s wrote: > Hi, all, > > How to use the 4rd stateless address mapping to support, in a provider > network having multiple IPv4 prefixes, both exclusive and shared IPv4 > addresses, is an typical question. > Jacni>: Yes, it is. As I mentioned in another thread, maybe in different way. I'd suggest some discussions about this should be added in the document. > Starting from a comment from Quiong Sun, here are some views on the > subject. > > > Le 28 juil. 2011 =E0 11:53, Qiong a =E9crit : > > > Hi, Remi, > > > > Thanks for your comments. I agree with you that in this situation, > stateless solution still superior to stateful ones from scalability aspec= t. > It is "per independent IPv4 prefix" mapping rule database, rather than > customer-based. But it still may have some tradeoff for domain realm. The > larger the domain it covers, the more independent IPv4 prefix there will = be. > And also the whole domain has to synchronize these mapping rules. > > > > I think this problem would be quite common for large broadband service > providers who already have a huge amount of customers. Do we have to > transfer all these legacy customers with public IPv4 address into > shared-mode directly? In our consideration, we think it might be better t= o > offer shared-mode solution for new customers only and leave the legacy > customers with non-shared-mode solution to avoid complaint from address > sharing. > > > As a result, we have to deal with the co-existence scenario for at leas= t > shared-mode and non-shared-mode. > > Yes, I think this will prove a frequent requirement. > > Complementary comments: > > 1. > A possible approach, to progressively reduce the number of used IPv4 > prefixes, consists in proposing two different tariffs: > - one for length L of IPv6 prefixes, and full IPv4 address per customer, > - the other, slightly lower, for length L+K of IPv6 prefixes, and shared > IPv4 address per customer. > > Thus the number of full-address customers can be expected to decrease, an= d > the longest IPv4 prefixes can be expected to progressively be reclaimed. > > Jacni>: The addresses are reclaimed progressively, that is one reason why we get fragmented prefixes. 2. > With a dihcotomic search for a prefix match in BR's and CE', the > performance impact of having a large number of rules can remain quite > limited, both in CE's and in BR's. > (Scalability of the BR function is in any case ensured by the fact that > BR's are, with respect to individual-customer states, completely stateles= s > (and also, of course, with respect to transport-connection states). > > 3. > By configuring appropriately as many mapping rules as there are IPv4 > prefixes, all IPv4 prefixes can be used without any impact on IPv6 routin= g > (no "IPv4 entropy" exported to IPv6). > Jacni>: In favor of this one, if I could. The Access gateway can be where the first aggregation happens. And we can have a *big* BR serving numerous Access Gateways belonging to seperate domains. Cheers, Jacni > This is illustrated in sec 3.2 of > tools.ietf.org/html/draft-despres-softwire-sam-01 (not too easy to read, > sorry for that, but the subject had some intrinsic sophistication and was > new). > (Incidentally this 4rd founding draft wasn't included Ole's 4rd-history > slide yesterday, but is IMHO worth looking at for anyone interested in th= e > genesis of 4rd.) > > Hope it helps. > > Regards, > RD > > > > I agree that this mapping specification can be applied to all stateless > solutions, separated from specific solution. Thanks for your suggestion. > > > > Best wishes > > > > Qiong Sun > > > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf307811802f921804a921d945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi,

On Thu, Jul 28, 2011 at 9:37 PM, R=E9mi Despr=E9s <despres.remi@laposte.net<= /a>> wrote:
Hi, all,

How to use the 4rd stateless address mapping to support, in a provider netw= ork having multiple IPv4 prefixes, both exclusive and shared IPv4 addresses= , is an typical question.

Jacni>: Yes, it is. As I mentioned in another thread, maybe in= different way.
I'd suggest some discussions about this should be added in the document= .


Starting from a comment from Quiong Sun, here are some views on the subject= .


Le 28 juil. 2011 =E0 11:53, Qiong a =E9crit :

> Hi, Remi,
>
> Thanks for your comments. I agree with you that in this situation, sta= teless solution still superior to stateful ones from scalability aspect. It= is "per independent IPv4 prefix" mapping rule database, rather t= han customer-based. But it still may have some tradeoff for domain realm. T= he larger the domain it covers, the more independent IPv4 prefix there will= be. And also the whole domain has to synchronize these mapping rules.
>
> I think this problem would be quite common for large broadband service= providers who already have a huge amount of customers. Do we have to trans= fer all these legacy customers with public IPv4 address into shared-mode di= rectly? In our consideration, we think it might be better to offer shared-m= ode solution for new customers only and leave the legacy customers with non= -shared-mode solution to avoid complaint from address sharing.

> As a result, we have to deal with the co-existence scenario for at lea= st shared-mode and non-shared-mode.

Yes, I think this will prove a frequent requirement.

Complementary comments:

1.
A possible approach, to progressively reduce the number of used IPv4 prefix= es, consists in proposing two different tariffs:
- one for length L of IPv6 prefixes, and full IPv4 address per customer, - the other, slightly lower, for length L+K of IPv6 prefixes, and shared IP= v4 address per customer.

Thus the number of full-address customers can be expected to decrease, and = the longest IPv4 prefixes can be expected to progressively be reclaimed.
Jacni>: The addr= esses are reclaimed progressively, that is one reason why we get fragmented= prefixes.

2.
With a dihcotomic search for a prefix match in BR's and CE', the pe= rformance impact of having a large number of rules can remain quite limited= , both in CE's and in BR's.
(Scalability of the BR function is in any case ensured by the fact that BR&= #39;s are, with respect to individual-customer states, completely stateless= (and also, of course, with respect to transport-connection states).

3.
By configuring appropriately as many mapping rules as there are IPv4 prefix= es, all IPv4 prefixes can be used without any impact on IPv6 routing (no &q= uot;IPv4 entropy" exported to IPv6).

Jacni>: In favor of this one, if I could. The = Access gateway can be where the first aggregation happens. And we can have = a *big* BR serving numerous Access Gateways belonging to seperate domains.<= br>

Cheers,
Jacni


This is illustrated in sec 3.2 of tools.ietf.org/html/draft-des= pres-softwire-sam-01 (not too easy to read, sorry for that, but the sub= ject had some intrinsic sophistication and was new).
(Incidentally this 4rd founding draft wasn't included Ole's 4rd-his= tory slide yesterday, but is IMHO worth looking at for anyone interested in= the genesis of 4rd.)

Hope it helps.

Regards,
RD


> I agree that this mapping specification can be applied to all stateles= s solutions, separated from specific solution. Thanks for your suggestion.<= br> >
> Best wishes
>
> Qiong Sun
>
>


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

--20cf307811802f921804a921d945-- From despres.remi@laposte.net Thu Jul 28 07:50:57 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1B421F86AF for ; Thu, 28 Jul 2011 07:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmLh2fu9fRTA for ; Thu, 28 Jul 2011 07:50:56 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9532A21F8686 for ; Thu, 28 Jul 2011 07:50:47 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2407.sfr.fr (SMTP Server) with ESMTP id C55FD7000090; Thu, 28 Jul 2011 16:50:46 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2407.sfr.fr (SMTP Server) with ESMTP id 651E0700008E; Thu, 28 Jul 2011 16:50:46 +0200 (CEST) X-SFR-UUID: 20110728145046414.651E0700008E@msfrf2407.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-697480821 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 28 Jul 2011 16:50:46 +0200 Message-Id: References: <741D71AA-24D1-4EA7-9409-45175D603213@free.fr> <99815557-036E-469D-AACB-473403B59393@laposte.net> To: Jacni Qin X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Support of multiple IPv4 prefixes in a network with 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 Jul 2011 14:50:57 -0000 --Apple-Mail-6-697480821 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Jacni, Le 28 juil. 2011 =E0 16:19, Jacni Qin a =E9crit : ... > By configuring appropriately as many mapping rules as there are IPv4 = prefixes, all IPv4 prefixes can be used without any impact on IPv6 = routing (no "IPv4 entropy" exported to IPv6). >=20 > Jacni>: In favor of this one, if I could. AFAIK, you can. > The Access gateway can be where the first aggregation happens. And we = can have a *big* BR serving numerous Access Gateways belonging to = seperate domains. It is also possible to have several different BR sets, each set having = its own BR anycast address and its set of IPv4 prefixes. Thus, these BR's can be placed close to where these IPv4 prefixes enter = the provider network.=20 Cheers, RD --Apple-Mail-6-697480821 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi, = Jacni,

Le 28 juil. 2011 =E0 16:19, Jacni Qin a =E9crit = :
...

By configuring appropriately as many mapping rules as there are IPv4 = prefixes, all IPv4 prefixes can be used without any impact on IPv6 = routing (no "IPv4 entropy" exported to = IPv6).

Jacni>: In favor of this one, if I could. =

AFAIK, you = can.

The Access = gateway can be where the first aggregation happens. And we can have a = *big* BR serving numerous Access Gateways belonging to seperate = domains.

It is = also possible to have several different BR sets, each set having its own = BR anycast address and its set of IPv4 prefixes.
Thus, these = BR's can be placed close to where these IPv4 prefixes enter the provider = network. 

Cheers,
RD


= --Apple-Mail-6-697480821-- From cb.list6@gmail.com Thu Jul 28 08:10:49 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C02321F8C13 for ; Thu, 28 Jul 2011 08:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuBW6R1Hp214 for ; Thu, 28 Jul 2011 08:10:48 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3AAE21F8B07 for ; Thu, 28 Jul 2011 08:10:41 -0700 (PDT) Received: by wwe5 with SMTP id 5so1724788wwe.13 for ; Thu, 28 Jul 2011 08:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VPasMc6cl8PQFOApWmtg+LJdV+SlsHQXVR6mJ7hQ8Uo=; b=hlt9HWrx+WBKXsyTFYv4wh2MutazAiVLvHGSSL3SEBkqq/EhCkmXXw1QYY8/FfLkMk svixi0EkgV4B7QI7RhWprK6SwVo/OER1j6LiBsoa7iD+EM5QkVLifwtcgJIzs2TUBuWz b3icABVD2IBWu5rE+LELx2qcX2PYgHKaJ9sKc= MIME-Version: 1.0 Received: by 10.227.19.130 with SMTP id a2mr126777wbb.88.1311865807171; Thu, 28 Jul 2011 08:10:07 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 08:10:06 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 08:10:06 -0700 (PDT) In-Reply-To: <4731A0B0-AB42-435D-835E-31D59B0AA867@gmail.com> References: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> <4731A0B0-AB42-435D-835E-31D59B0AA867@gmail.com> Date: Thu, 28 Jul 2011 08:10:06 -0700 Message-ID: From: Cameron Byrne To: Satoru Matsushima Content-Type: multipart/alternative; boundary=002215b033ae6df51504a9228f34 Cc: "softwires@ietf.org" Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:10:49 -0000 --002215b033ae6df51504a9228f34 Content-Type: text/plain; charset=ISO-8859-1 On Jul 28, 2011 6:03 AM, "Satoru Matsushima" wrote: > > Thank you Tina, it is also pointed out by Dave yesterday. > > Interestingly, Qiong pointed out another issue, which is routing scalability. > I agree with Qiong that routing scalability is significant issue. > FWIW, I would recommend something, LISP for example, could help him. > My advice is that you do not want to tie your solution to LISP. Cb. > Best regards, > --satoru > > On 2011/07/28, at 6:46, Tina TSOU wrote: > > > Matsushima-san, > > In this draft, we may need to refer or define the definition of > > - Stateful operation > > - Stateless operation > > - Dynamic port allocation > > - Static port allocation > > > > Hope in this way, the discussion could be easier. > > > > > > Best Regards, > > Tina TSOU > > http://tinatsou.weebly.com/contact.html > > > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Satoru Matsushima > > Sent: Thursday, July 28, 2011 5:56 AM > > To: Qiong > > Cc: softwires@ietf.org > > Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain > > > > Hi Qiong, > > > > On 2011/07/28, at 4:31, Qiong wrote: > > > >> Hi, Satoru, > >> > >> Thanks a lot for your suggestion and I understand it can work. But in my understanding, it still lies some differences with the so-called "totally stateless solution". > > > > I don't mean that 'totally stateless solution' isn't a part of routing system. > > > >> Suppose there is only one domain, when an IPv4 downstream packet arrives at stateless gateway, it would firstly forward to the virtual tunnel interface (take 4V6 Mapped Tunnel for example) with only one default route. Then after encapsulated with a uniform IPv6 prefix and IPv4 prefix, etc, it will lookup IPv6 routing table and forward to 4v6 CE. Here, actually there is no need to do routing lookup for IPv4 address expect one default route. > > > > You already did routing when you found default route. > > > > > >> However, if we introduce multiple domains with multiple IPv4 prefix pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, Nm would not be a small number anymore. So maybe some more optimization work will still be needed to make it more "stateless" ? > > > > What do you mean 'the entry number of IPv4 routing table'? > > Do you presume that your IGP routing has almost 300K routes as same number of current internet full routes? > > > > Best regards, > > --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 --002215b033ae6df51504a9228f34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 28, 2011 6:03 AM, "Satoru Matsushima" <satoru.matsushima@gmail.com> wrote: >
> Thank you Tina, it is also pointed out by Dave yesterday.
>
> Interestingly, Qiong pointed out another issue, which is routing scala= bility.
> I agree with Qiong that routing scalability is significant issue.
> FWIW, I would recommend something, LISP for example, could help him. >

My advice is that you do not want to tie your solution to LISP.

Cb.

> Best regards,
> --satoru
>
> On 2011/07/28, at 6:46, Tina TSOU wrote:
>
> > Matsushima-san,
> > In this draft, we may need to refer or define the definition of > > - Stateful operation
> > - Stateless operation
> > - Dynamic port allocation
> > - Static port allocation
> >
> > Hope in this way, the discussion could be easier.
> >
> >
> > Best Regards,
> > Tina TSOU
> > http://tinats= ou.weebly.com/contact.html
> >
> > -----Original Message-----
> > From: softwires-bou= nces@ietf.org [mailto:sof= twires-bounces@ietf.org] On Behalf Of Satoru Matsushima
> > Sent: Thursday, July 28, 2011 5:56 AM
> > To: Qiong
> > Cc: softwires@ietf.org<= br> > > Subject: Re: [Softwires] [softwire]comments on stateless 4v6 doma= in
> >
> > Hi Qiong,
> >
> > On 2011/07/28, at 4:31, Qiong wrote:
> >
> >> Hi, Satoru,
> >>
> >> Thanks a lot for your suggestion and I understand it can work= . But in my understanding, it still lies some differences with the so-calle= d "totally stateless solution".
> >
> > I don't mean that 'totally stateless solution' isn= 9;t a part of routing system.
> >
> >> Suppose there is only one domain, when an IPv4 downstream pac= ket arrives at stateless gateway, it would firstly forward to the virtual t= unnel interface (take 4V6 Mapped Tunnel for example) with only one default = route. Then after encapsulated with a uniform IPv6 prefix and IPv4 prefix, = etc, it will lookup IPv6 routing table and forward to 4v6 CE. Here, actuall= y there is no need to do routing lookup for IPv4 address expect one default= route.
> >
> > You already did routing when you found default route.
> >
> >
> >> However, if we introduce multiple domains with multiple IPv4 = prefix pools ( the number of each domain is N1, N2, N3,... Nm) , then the e= ntry number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situat= ion, Nm would not be a small number anymore. So maybe some more optimizatio= n work will still be needed to make it more "stateless" ?
> >
> > What do you mean 'the entry number of IPv4 routing table'= ?
> > Do you presume that your IGP routing has almost 300K routes as sa= me number of current internet full routes?
> >
> > Best regards,
> > --satoru
> >
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https= ://www.ietf.org/mailman/listinfo/softwires
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://ww= w.ietf.org/mailman/listinfo/softwires

--002215b033ae6df51504a9228f34-- From despres.remi@laposte.net Thu Jul 28 08:59:02 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D497C21F8CC3 for ; Thu, 28 Jul 2011 08:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik44cGN3TRNc for ; Thu, 28 Jul 2011 08:59:02 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FF21F8C73 for ; Thu, 28 Jul 2011 08:59:02 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2121.sfr.fr (SMTP Server) with ESMTP id 5A3BB7000093; Thu, 28 Jul 2011 17:59:01 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2121.sfr.fr (SMTP Server) with ESMTP id 2FFA17000092; Thu, 28 Jul 2011 17:58:57 +0200 (CEST) X-SFR-UUID: 20110728155857196.2FFA17000092@msfrf2121.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 17:58:56 +0200 Message-Id: <71F7C208-9C83-448A-A2B1-C323C1537A6A@laposte.net> To: Dave Thaler Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: [Softwires] The Framing discussion of yesterday X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:59:02 -0000 Hi, Dave, 1. I completely agree with the need you expressed to clarify what is meant = by stateless depending on which states it applies to. 2. Unless I misinterpreted, you asked about the failure mode of a host that = isn't part of a shared IPv4 address system and is attached to such a = system.=20 Assuming that, in the context of the discussion, this implicitly = referred to a "static" shared-address system, I don't see which problem = there would be: - If a node is attached to an IPv6 network and ignores the static = shared-address system of this network, it won't be able to = receive/accept parameters of this-system mapping rule(s).=20 - It will therefore ignore that it could have used an exclusive port set = of a global IPv4 address.=20 - It will do nothing with its assigned address-and-port-set. =20 Is this OK, or did you have in mind something more complicated which you = could detail? Kind regards, RD= From satoru.matsushima@gmail.com Thu Jul 28 10:29:01 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDACE11E80E5 for ; Thu, 28 Jul 2011 10:29:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3dHU3oAI7QJ for ; Thu, 28 Jul 2011 10:29:01 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id C07B811E80D0 for ; Thu, 28 Jul 2011 10:29:00 -0700 (PDT) Received: by qyk29 with SMTP id 29so1866997qyk.10 for ; Thu, 28 Jul 2011 10:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=Mr9c4KSUNFfLZeWYIajpgVfk1wHZ7bd996OdMI9Bytg=; b=iSIHkTIT/l5+DO5iiORxIGak+WyOexspJ3FCws3Zz3k/vhooNEv5UUTnPFnmIYSqRX 0/eoGR/ifBqGoXBTbjeqdS0UvkhYD1SdU9fv3gnNLH8hrkI1NU62pPFFVrSor7epvqKO UXsqfNLUKy7oaCrdOxyXd6SqyIcNt9rqqTdp0= Received: by 10.224.196.1 with SMTP id ee1mr251711qab.109.1311874139760; Thu, 28 Jul 2011 10:28:59 -0700 (PDT) Received: from dhcp-4258.meeting.ietf.org (dhcp-4258.meeting.ietf.org [130.129.66.88]) by mx.google.com with ESMTPS id s14sm817738qct.18.2011.07.28.10.28.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 10:28:58 -0700 (PDT) From: Satoru Matsushima Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 28 Jul 2011 13:28:56 -0400 Message-Id: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> To: "softwires@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [Softwires] Yesterday's slides X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 17:29:01 -0000 Hi, Could someone tell me where is Dave Thaler's slides? Best regards, --satoru From denghui02@gmail.com Thu Jul 28 10:46:54 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58689228015 for ; Thu, 28 Jul 2011 10:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4518fhiNnMf for ; Thu, 28 Jul 2011 10:46:53 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E922228012 for ; Thu, 28 Jul 2011 10:46:53 -0700 (PDT) Received: by wwe5 with SMTP id 5so1844216wwe.13 for ; Thu, 28 Jul 2011 10:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9MLH8DmORk4sFPUgCPHHpV/QJlVO08uCs2ehup/oXGE=; b=OiAQ992wbevg7vzq/bRYguMBFBSNQfhIOyU1opvtc6imlG1FIGIeB7At9diHD8HrDk hq0J7zFTwGvAMJe8xfh3/fPU/chUJo1N617FNFsAQrcxndr4irsL5n2HEqEBMenVLaZw d3tNr0/La/aYKXMnMB1fQjWL31vVQuKpy7VPk= MIME-Version: 1.0 Received: by 10.227.195.13 with SMTP id ea13mr382892wbb.0.1311875212292; Thu, 28 Jul 2011 10:46:52 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Thu, 28 Jul 2011 10:46:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 13:46:52 -0400 Message-ID: From: Hui Deng To: Paco Cortes Content-Type: multipart/alternative; boundary=20cf30025a5804b42f04a924c034 Cc: softwires@ietf.org, wdec@cisco.com Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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 Jul 2011 17:46:54 -0000 --20cf30025a5804b42f04a924c034 Content-Type: text/plain; charset=ISO-8859-1 Hi Paco, To have such complicated DPI functionality in the network is totally out of scope of IETF. I don't think IETF should discuss this type of complicated DPI here. Best regards, -Hui 2011/7/28 Paco Cortes > Hi Wojciech, > > two comments on the 3gpp sections of draft-dec-stateless-4v6-02. > > First, the definition of "Rx" is missing in section 4.2.1. > > Second, the table in section 4.2.2 claims "No discernible impact" for > "AF Application Function" for the 4V6 translation mode. This is not > fully correct. > The PCC architecture support a plurality of AFs communication over Rx > with the PCRF, and most of them "interact" in some way with the end > user payload. > An AF might terminate, proxy or transparently inspect a subset of the > UE traffic (for instance control signalling, like SIP). > An AF might also terminate, proxy or transparently inspect all UE > traffic (application server acting as AF, deep packet inspection > device, ...). > And the most important point: An AF might located in different > locations inside the operators networks, or even outside the operators > network. > Referring to your own "Figure 2" in the draft, this means that for > IPv4 traffic an AF might "intercept" traffic between the "PDN-Gw" and > the "S46 Gateway", i.e. with an IPv6 header, BUT it might also > intercept traffic behind the "S46 Gateway", i.e., with an IPv4 header. > > I propose to change the impact to "No impact for IPv6. Feature to map > IPv4-IPv6 addresses may be needed only in case of IPv4-only > applications". > > I'm aware that it would be theoretically possible to "hide" this > impact from an AF by using a more complex PCRF implementation that > "translates" IPv4 addresses in Rx message (including TFTs) into the > mapped IPv6, but this would imply limitations, and would just be one > implementation possibility. I believe that this draft should not > assume a specific implementation, unless clearly documented. > > br, > Paco > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf30025a5804b42f04a924c034 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paco,
=A0
To have such complicated DPI functionality in the network is totally o= ut of scope of IETF.
I don't think IETF should discuss this type of complicated DPI her= e.
=A0
Best regards,
=A0
-Hui

2011/7/28 Paco Cortes <pacosaddress@googlemail.com&= gt;
Hi Wojciech,

two comments= on the 3gpp sections of draft-dec-stateless-4v6-02.

First, the defi= nition of "Rx" is missing in section 4.2.1.

Second, the table in section 4.2.2 claims "No discernible impact&q= uot; for
"AF Application Function" for the 4V6 translation mod= e. This is not
fully correct.
The PCC architecture support a pluralit= y of AFs communication over Rx
with the PCRF, and most of them "interact" in some way with the e= nd
user payload.
An AF might terminate, proxy or transparently inspec= t a subset of the
UE traffic (for instance control signalling, like SIP)= .
An AF might also terminate, proxy or transparently inspect all UE
traffi= c (application server acting as AF, deep packet inspection
device, ...).=
And the most important point: An AF might located in different
locat= ions inside the operators networks, or even outside the operators
network.
Referring to your own "Figure 2" in the draft, this m= eans that for
IPv4 traffic an AF might "intercept" traffic bet= ween the "PDN-Gw" and
the "S46 Gateway", i.e. with a= n IPv6 header, BUT it might also
intercept traffic behind the "S46 Gateway", i.e., with an IPv4 he= ader.

I propose to change the impact to "No impact for IPv6. Fe= ature to map
IPv4-IPv6 addresses may be needed only in case of =A0IPv4-o= nly
applications".

I'm aware that it would be theoretically pos= sible to "hide" this
impact from an AF by using a more complex= PCRF implementation that
"translates" IPv4 addresses in Rx me= ssage (including TFTs) into the
mapped IPv6, but this would imply limitations, and would just be one
imp= lementation possibility. I believe that this draft should not
assume a s= pecific implementation, unless clearly documented.

br,
=A0Paco _______________________________________________
Softwires mailing listSoftwires@ietf.org
http= s://www.ietf.org/mailman/listinfo/softwires

--20cf30025a5804b42f04a924c034-- From denghui02@gmail.com Thu Jul 28 10:48:27 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370345E8014 for ; Thu, 28 Jul 2011 10:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEJyujFCGRso for ; Thu, 28 Jul 2011 10:48:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB6ED5E800D for ; Thu, 28 Jul 2011 10:48:17 -0700 (PDT) Received: by wwe5 with SMTP id 5so1845045wwe.13 for ; Thu, 28 Jul 2011 10:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1n8Y9ZNMTKpLKZG6yp00xWYTFCkWATmU4R/Yq35HQ6Q=; b=uqxkAlp+ROvLSawVUd9kkYeA3T+trjgtsD8QjvCbsZT1TMTe3W/b9tLIsskeBrjGiV 2l7OUlUEOC2rKoS3kyYgSKIbxNBJfyrfjtYF7mnApMjoztRQuKIpey4S6dsSrpcE9hLf RjG5EKx5YpuK+HXvvT5c23MIrj8v+V9teA27g= MIME-Version: 1.0 Received: by 10.227.29.87 with SMTP id p23mr341132wbc.70.1311875296756; Thu, 28 Jul 2011 10:48:16 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Thu, 28 Jul 2011 10:48:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 13:48:16 -0400 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=0022159755720d82ee04a924c54e Cc: softwires@ietf.org, wdec@cisco.com, Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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 Jul 2011 17:48:27 -0000 --0022159755720d82ee04a924c54e Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron, You may need spend time to review it later, it's different from 6RD and DS-Lite, Secondly, I am wondering whether it could fit for mobile CPE case. Best regards, -Hui 2011/7/28 Cameron Byrne > > On Jul 28, 2011 5:08 AM, "Paco Cortes" > wrote: > > > > Hi Wojciech, > > > > two comments on the 3gpp sections of draft-dec-stateless-4v6-02. > > > > First, the definition of "Rx" is missing in section 4.2.1. > > > > Second, the table in section 4.2.2 claims "No discernible impact" for > > "AF Application Function" for the 4V6 translation mode. This is not > > fully correct. > > The PCC architecture support a plurality of AFs communication over Rx > > with the PCRF, and most of them "interact" in some way with the end > > user payload. > > An AF might terminate, proxy or transparently inspect a subset of the > > UE traffic (for instance control signalling, like SIP). > > An AF might also terminate, proxy or transparently inspect all UE > > traffic (application server acting as AF, deep packet inspection > > device, ...). > > And the most important point: An AF might located in different > > locations inside the operators networks, or even outside the operators > > network. > > Referring to your own "Figure 2" in the draft, this means that for > > IPv4 traffic an AF might "intercept" traffic between the "PDN-Gw" and > > the "S46 Gateway", i.e. with an IPv6 header, BUT it might also > > intercept traffic behind the "S46 Gateway", i.e., with an IPv4 header. > > > > I propose to change the impact to "No impact for IPv6. Feature to map > > IPv4-IPv6 addresses may be needed only in case of IPv4-only > > applications". > > > > I'm aware that it would be theoretically possible to "hide" this > > impact from an AF by using a more complex PCRF implementation that > > "translates" IPv4 addresses in Rx message (including TFTs) into the > > mapped IPv6, but this would imply limitations, and would just be one > > implementation possibility. I believe that this draft should not > > assume a specific implementation, unless clearly documented. > > > > +1, I believe this section causes confusion. > > I have not had time to do a full review. > > Tunneling traffic breaks pcc and a new bearer type is a tall order. We > already visited these issues when concluding 6rd and ds-lite were not good > fits for 3gpp. > > Cb > > > br, > > Paco > > _______________________________________________ > > 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 > > --0022159755720d82ee04a924c54e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Cameron,
=A0
You may need spend time to review it later, it's different from 6R= D and DS-Lite,
=A0
Secondly, I am wondering whether it could fit for mobile CPE case.
=A0
Best regards,
=A0
-Hui

2011/7/28 Cameron Byrne <cb.list6@gmail.com>


On Jul 28, 2011 5:08 AM, "Paco Cortes" <pacosaddress@googlemail.c= om> wrote:
>
> Hi Wojciech,
>
> two comments= on the 3gpp sections of draft-dec-stateless-4v6-02.
>
> First, the definition of "Rx" is missing in section = 4.2.1.
>
> Second, the table in section 4.2.2 claims "No d= iscernible impact" for
> "AF Application Function" for= the 4V6 translation mode. This is not
> fully correct.
> The PCC architecture support a plurality of AFs= communication over Rx
> with the PCRF, and most of them "intera= ct" in some way with the end
> user payload.
> An AF might= terminate, proxy or transparently inspect a subset of the
> UE traffic (for instance control signalling, like SIP).
> An AF = might also terminate, proxy or transparently inspect all UE
> traffic= (application server acting as AF, deep packet inspection
> device, .= ..).
> And the most important point: An AF might located in different
>= locations inside the operators networks, or even outside the operators
= > network.
> Referring to your own "Figure 2" in the dra= ft, this means that for
> IPv4 traffic an AF might "intercept" traffic between the &qu= ot;PDN-Gw" and
> the "S46 Gateway", i.e. with an IPv6 = header, BUT it might also
> intercept traffic behind the "S46 Ga= teway", i.e., with an IPv4 header.
>
> I propose to change the impact to "No impact for IPv6. Fe= ature to map
> IPv4-IPv6 addresses may be needed only in case of =A0I= Pv4-only
> applications".
>
> I'm aware that it = would be theoretically possible to "hide" this
> impact from an AF by using a more complex PCRF implementation that
= > "translates" IPv4 addresses in Rx message (including TFTs) i= nto the
> mapped IPv6, but this would imply limitations, and would ju= st be one
> implementation possibility. I believe that this draft should not
&g= t; assume a specific implementation, unless clearly documented.
>

=

+1, I believe this section causes confusion.

I have not had time to do a full review.

Tunneling traffic breaks pcc and a new bearer type is a tall order. We a= lready visited these issues when concluding 6rd and ds-lite were not good f= its for 3gpp.

Cb

> br,
> =A0Paco
> _______________________________________= ________
> Softwires mailing list
> Softwires@ietf.org
> https://www.= ietf.org/mailman/listinfo/softwires


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


--0022159755720d82ee04a924c54e-- From weapon@csnet1.cs.tsinghua.edu.cn Thu Jul 28 11:10:50 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F75021F8B25 for ; Thu, 28 Jul 2011 11:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.366 X-Spam-Level: * X-Spam-Status: No, score=1.366 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hoy72xnbY1Tg for ; Thu, 28 Jul 2011 11:10:49 -0700 (PDT) Received: from mail.catc.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7200B21F8B0B for ; Thu, 28 Jul 2011 11:10:49 -0700 (PDT) Received: from PengWu-laptop (dhcp-17a0.meeting.ietf.org [130.129.23.160]) by mail.catc.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id BD1EF2A20828; Fri, 29 Jul 2011 02:10:38 +0800 (CST) Date: Fri, 29 Jul 2011 02:10:38 +0800 From: "Peng Wu" To: "Satoru Matsushima" , "Qiong" References: , <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com>, Message-ID: <201107290210325157354@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Cc: softwires Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 18:10:50 -0000 Hi Satoru, >> However, if we introduce multiple domains with multiple IPv4 prefix pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, Nm would not be a small number anymore. So maybe some more optimization work will still be needed to make it more "stateless" ? > >What do you mean 'the entry number of IPv4 routing table'? >Do you presume that your IGP routing has almost 300K routes as same number of current internet full routes? If I get Qiong correctly, she means that, suppose the IPv4 IGP addresses blocks are quite de-aggregated already. If the ISP upgrade the network to IPv6, and support IPv4 using stateless 4v6 with the same IPv4 address distribution, then the IPv4 IGP kind of introduce the IPv4 IGP routing table into IPv6. If this situation does exists, then it's an interesting operation problem. From weapon@csnet1.cs.tsinghua.edu.cn Thu Jul 28 11:32:47 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C505D11E8078 for ; Thu, 28 Jul 2011 11:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.036 X-Spam-Level: * X-Spam-Status: No, score=1.036 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-Dxdpk+3sTW for ; Thu, 28 Jul 2011 11:32:47 -0700 (PDT) Received: from mail.catc.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id C123011E8077 for ; Thu, 28 Jul 2011 11:32:46 -0700 (PDT) Received: from PengWu-laptop (dhcp-17a0.meeting.ietf.org [130.129.23.160]) by mail.catc.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id 0463E2A208D9; Fri, 29 Jul 2011 02:32:16 +0800 (CST) Date: Fri, 29 Jul 2011 02:32:14 +0800 From: "Peng Wu" To: "Tina TSOU" , "Satoru Matsushima" , "Qiong" References: , <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com>, , Message-ID: <201107290232123413994@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Cc: "softwires@ietf.org" Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 18:32:47 -0000 KzENClRoZSBmaXJzdCBjYXRlZ29yeSBpcyBzdGF0ZWxlc3MgZW5jYXBzdWxhdGlvbiwgbm8gdGFi bGUgbG9va3VwLCBzb21ldGhpbmcgbGlrZSB0aGF0OyB0aGUgc2Vjb25kIGNhdGVnb3J5IGlzIHBv cnQgYWxsb2NhdGlvbiBtYW5uZXIuDQpOb3cgdGhlIG1vdGl2YXRpb24gZHJhZnQga2luZCBvZiBt aXggdGhlbSB0b2dldGhlci4gSSBndWVzcyBDbGFzc2lmaWNhdGlvbiBpcyBuZWVkZWQuIE1heWJl IGRlc2NyaWJlIGJvdGggaW4gc2VwYXJhdGVkIHBhcnRzPyBEZXBlbmRpbmcgb24gd2hhdCB5b3Ug Z3V5cyByZWFsbHkgd2FudC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tCQkJCSANClBlbmcgV3UNClBo RCBjYW5kaWRhdGUNCkRlcGFydG1lbnQgb2YgQ29tcHV0ZXIgU2NpZW5jZSAmIFRlY2hub2xvZ3kN ClRzaW5naHVhIFVuaXZlcnNpdHksIEJlaWppbmcsIENoaW5hDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb22julRpbmEg VFNPVQ0KRGF0ZaO6MjAxMS0wNy0yOCAxOTowNDo0Nw0KVG+julNhdG9ydSBNYXRzdXNoaW1hOyBR aW9uZw0KQ0OjunNvZnR3aXJlc0BpZXRmLm9yZw0KU3ViamVjdKO6UmU6IFtTb2Z0d2lyZXNdIFtz b2Z0d2lyZV1jb21tZW50cyBvbiBzdGF0ZWxlc3MgNHY2IGRvbWFpbg0KDQo+TWF0c3VzaGltYS1z YW4sDQo+SW4gdGhpcyBkcmFmdCwgd2UgbWF5IG5lZWQgdG8gcmVmZXIgb3IgZGVmaW5lIHRoZSBk ZWZpbml0aW9uIG9mIA0KPi0gU3RhdGVmdWwgb3BlcmF0aW9uDQo+LSBTdGF0ZWxlc3Mgb3BlcmF0 aW9uDQo+LSBEeW5hbWljIHBvcnQgYWxsb2NhdGlvbg0KPi0gU3RhdGljIHBvcnQgYWxsb2NhdGlv bg0KPg0KPkhvcGUgaW4gdGhpcyB3YXksIHRoZSBkaXNjdXNzaW9uIGNvdWxkIGJlIGVhc2llci4N Cj4NCj4NCj5CZXN0IFJlZ2FyZHMsDQo+VGluYSBUU09VDQo+aHR0cDovL3RpbmF0c291LndlZWJs eS5jb20vY29udGFjdC5odG1sDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9t OiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgU2F0b3J1IE1hdHN1c2hpbWENCj5TZW50OiBUaHVyc2RheSwg SnVseSAyOCwgMjAxMSA1OjU2IEFNDQo+VG86IFFpb25nDQo+Q2M6IHNvZnR3aXJlc0BpZXRmLm9y Zw0KPlN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBbc29mdHdpcmVdY29tbWVudHMgb24gc3RhdGVs ZXNzIDR2NiBkb21haW4NCj4NCj5IaSBRaW9uZywNCj4NCj5PbiAyMDExLzA3LzI4LCBhdCA0OjMx LCBRaW9uZyB3cm90ZToNCj4NCj4+IEhpLCBTYXRvcnUsDQo+PiANCj4+IFRoYW5rcyBhIGxvdCBm b3IgeW91ciBzdWdnZXN0aW9uIGFuZCBJIHVuZGVyc3RhbmQgaXQgY2FuIHdvcmsuIEJ1dCBpbiBt eSB1bmRlcnN0YW5kaW5nLCBpdCBzdGlsbCBsaWVzIHNvbWUgZGlmZmVyZW5jZXMgd2l0aCB0aGUg c28tY2FsbGVkICJ0b3RhbGx5IHN0YXRlbGVzcyBzb2x1dGlvbiIuIA0KPg0KPkkgZG9uJ3QgbWVh biB0aGF0ICd0b3RhbGx5IHN0YXRlbGVzcyBzb2x1dGlvbicgaXNuJ3QgYSBwYXJ0IG9mIHJvdXRp bmcgc3lzdGVtLiANCj4NCj4+IFN1cHBvc2UgdGhlcmUgaXMgb25seSBvbmUgZG9tYWluLCB3aGVu IGFuIElQdjQgZG93bnN0cmVhbSBwYWNrZXQgYXJyaXZlcyBhdCBzdGF0ZWxlc3MgZ2F0ZXdheSwg aXQgd291bGQgZmlyc3RseSBmb3J3YXJkIHRvIHRoZSB2aXJ0dWFsIHR1bm5lbCBpbnRlcmZhY2Ug KHRha2UgNFY2IE1hcHBlZCBUdW5uZWwgZm9yIGV4YW1wbGUpIHdpdGggb25seSBvbmUgZGVmYXVs dCByb3V0ZS4gVGhlbiBhZnRlciBlbmNhcHN1bGF0ZWQgd2l0aCBhIHVuaWZvcm0gSVB2NiBwcmVm aXggYW5kIElQdjQgcHJlZml4LCBldGMsIGl0IHdpbGwgbG9va3VwIElQdjYgcm91dGluZyB0YWJs ZSBhbmQgZm9yd2FyZCB0byA0djYgQ0UuIEhlcmUsIGFjdHVhbGx5IHRoZXJlIGlzIG5vIG5lZWQg dG8gZG8gcm91dGluZyBsb29rdXAgZm9yIElQdjQgYWRkcmVzcyBleHBlY3Qgb25lIGRlZmF1bHQg cm91dGUuDQo+DQo+WW91IGFscmVhZHkgZGlkIHJvdXRpbmcgd2hlbiB5b3UgZm91bmQgZGVmYXVs dCByb3V0ZS4NCj4NCj4NCj4+IEhvd2V2ZXIsIGlmIHdlIGludHJvZHVjZSBtdWx0aXBsZSBkb21h aW5zIHdpdGggbXVsdGlwbGUgSVB2NCBwcmVmaXggcG9vbHMgKCB0aGUgbnVtYmVyIG9mIGVhY2gg ZG9tYWluIGlzIE4xLCBOMiwgTjMsLi4uIE5tKSAsIHRoZW4gdGhlIGVudHJ5IG51bWJlciBvZiBJ UHY0IHJvdXRpbmcgdGFibGUgd2lsbCBiZSBOMStOMitOMysuLitObS4gSW4gY3VycmVudCBzaXR1 YXRpb24sIE5tIHdvdWxkIG5vdCBiZSBhIHNtYWxsIG51bWJlciBhbnltb3JlLiBTbyBtYXliZSBz b21lIG1vcmUgb3B0aW1pemF0aW9uIHdvcmsgd2lsbCBzdGlsbCBiZSBuZWVkZWQgdG8gbWFrZSBp dCBtb3JlICJzdGF0ZWxlc3MiID8gIA0KPg0KPldoYXQgZG8geW91IG1lYW4gJ3RoZSBlbnRyeSBu dW1iZXIgb2YgSVB2NCByb3V0aW5nIHRhYmxlJz8gDQo+RG8geW91IHByZXN1bWUgdGhhdCB5b3Vy IElHUCByb3V0aW5nIGhhcyBhbG1vc3QgMzAwSyByb3V0ZXMgYXMgc2FtZSBudW1iZXIgb2YgY3Vy cmVudCBpbnRlcm5ldCBmdWxsIHJvdXRlcz8NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+LS1zYXRvcnUN Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlNv ZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj5Tb2Z0d2lyZXNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+U29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPlNv ZnR3aXJlc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c29mdHdpcmVzDQo+DQo= From xumwcs@gmail.com Thu Jul 28 12:46:43 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DB821F86AD for ; Thu, 28 Jul 2011 12:46:43 -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_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQOUEI34wRzN for ; Thu, 28 Jul 2011 12:46:42 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D53421F86A8 for ; Thu, 28 Jul 2011 12:46:42 -0700 (PDT) Received: by yie30 with SMTP id 30so2542294yie.31 for ; Thu, 28 Jul 2011 12:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pM3g4h5d1g7ORlLugamsDXVxoiejtXtzjlMq8kZ/96U=; b=TGUFumYA7eVEMzHSXsjjfLW0f6US69am8aHQarOQWK24bD5scj3PVKWHipLQ6RKKnH gXBfwE371VPHBohvma+Dal3WOn26qXfibIpRJc/FcYzepaCtxyTn1eovxcd+v9TTDTsP rswKUn03WM+LLovdTQC2KuvBHZxy/tWFNu9y0= MIME-Version: 1.0 Received: by 10.151.51.7 with SMTP id d7mr35751ybk.426.1311882399206; Thu, 28 Jul 2011 12:46:39 -0700 (PDT) Received: by 10.150.67.9 with HTTP; Thu, 28 Jul 2011 12:46:39 -0700 (PDT) In-Reply-To: References: <1311862423.23432.YahooMailRC@web111407.mail.gq1.yahoo.com> Date: Fri, 29 Jul 2011 03:46:39 +0800 Message-ID: From: Mingwei Xu To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=0015174c0e88644d1304a9266c47 Cc: "softwires@ietf.org" , "xiaohong.deng@orange-ftgroup.com" Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 19:46:43 -0000 --0015174c0e88644d1304a9266c47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the first use case, delivering multicast over DS-lite in an IPv6 multicast enabled network, is more valuable. Mingwei 2011/7/28 Lee, Yiu > Ah. Ok :-) English isn't my first language. Please bear with me :-p > > On 7/28/11 10:13 AM, "Behcet Sarikaya" wrote: > > > > > > >Hi Yiu, > > > >It was a joke. > > > >We need some sense of humor in IETF. > > > >I also support > >http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04 > > > >Behcet > > > >> Dear Behcat, > >> > >> Can you elaborate it a little more? I don=B9t quite follow what makes= one > >> correct from two wrongs. What is the technical argument of this > >>statement? > >> > >> Thanks, > >> Yiu > >> > >> On 7/28/11 9:45 AM, "Behcet Sarikaya" > >>wrote: > >> > >> > > >> > > >> >> > >> >>Hi Yiu,all, > >> >> > >> >>I see the first use case worth good value to work on, as the reaso= n > >>I > >> >>stated > >> >>during meeting: operators would happy with it because otherwise (t= he > >> >>second > >> >>case), means moving AFTR lower location, which ends up with more > >>CAPEX. > >> >> > >> > > >> >This is not correct. > >> >Please take a look at Broadband Forum document WT-242 on IPv6 > >>migration > >> >(or read > >> >my previous mail :-) ). > >> >You can not make one correct from two wrongs. > >> > > >> >Regards, > >> > > >> >Behcet > >> > > >> > >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --0015174c0e88644d1304a9266c47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the first use case, delivering multicast over DS-lite in an IPv6 mu= lticast enabled network, is more valuable.
=A0
Mingwei

2011/7/28 Lee, Yiu <Yiu_Lee@cable.comcast.com>
Ah. Ok :-) English isn't my = first language. Please bear with me :-p

On 7/28/11 10:13 AM, "Behcet Sarikaya" <= behcetsarikaya@yahoo.com>= ; wrote:

>
>
>Hi Yiu,
>
>It was a joke. >
>We need some sense of humor in IETF.
>
>I also supp= ort
>http://tools.ietf.org/html/draft-qin-softwi= re-dslite-multicast-04
>
>Behcet
>
>> Dear Behcat,
>>
>>= Can you elaborate it a little more? I don=B9t quite follow =A0what makes o= ne
>> correct from two wrongs. What is the technical argument of = =A0this
>>statement?
>>
>> Thanks,
>> Yiu
>&= gt;
>> On 7/28/11 9:45 AM, "Behcet =A0Sarikaya" <behcetsarikaya@yahoo.com> >>wrote:
>>
>> >
>> >
>> &g= t;>
>> >>Hi =A0Yiu,all,
>> >>
>> = >>I see the =A0first use case worth good value to work on, as the =A0= reason
>>I
>> >>stated
>> >>during =A0meeting:= operators would =A0happy with it because otherwise (the
>> >&g= t;second
>> >>case), =A0means moving AFTR lower location, wh= ich ends up with more
>>CAPEX.
>> >>
>> >
>> >This i= s not correct.
>> >Please take a =A0look at Broadband Forum doc= ument WT-242 on IPv6
>>migration
>> >(or read
>&= gt; >my previous mail :-) ).
>> >You can not make one correct from two =A0wrongs.
>> &= gt;
>> >Regards,
>> >
>> >Behcet
>= ;> >
>>
>>

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

--0015174c0e88644d1304a9266c47-- From satoru.matsushima@gmail.com Thu Jul 28 13:21:36 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B4611E8147 for ; Thu, 28 Jul 2011 13:21: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5HdN7O-RJhY for ; Thu, 28 Jul 2011 13:21:36 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3804411E8083 for ; Thu, 28 Jul 2011 13:21:36 -0700 (PDT) Received: by qyk9 with SMTP id 9so3363892qyk.10 for ; Thu, 28 Jul 2011 13:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zEDcri/a9MvgMqh6+KNTvHt0/D416BYqDE2zqitS7Fk=; b=E53G83k+riTxqqs5odeAZo6lm7CzHvuVbsxa/IUZIHqPpFvOtb65/opTV2MXb/DxXg g2uKV6XKis4PtOH2BDQEMLMOp19j2SEV7d/qNYW79uzCBDX+jlshH1GNsQEs/pxUOIoY 3DLY68bxcxLHHLHsMM7P10Bmhzr2sOtW/0LQw= Received: by 10.224.173.136 with SMTP id p8mr362974qaz.374.1311884495743; Thu, 28 Jul 2011 13:21:35 -0700 (PDT) Received: from ?IPv6:2001:df8::80:e5bf:e79b:ac50:25ea? ([2001:df8:0:80:e5bf:e79b:ac50:25ea]) by mx.google.com with ESMTPS id e10sm919026qcq.40.2011.07.28.13.21.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 13:21:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 28 Jul 2011 16:21:32 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Dave Thaler X-Mailer: Apple Mail (2.1244.3) Cc: "softwires@ietf.org list" Subject: Re: [Softwires] Yesterday's slides X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 20:21:37 -0000 Dave, thank you to share your slides. --satoru On 2011/07/28, at 15:45, Dave Thaler wrote: > Attaching here since they don't seem to be posted yet. > > -Dave > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >> Behalf Of Satoru Matsushima >> Sent: Thursday, July 28, 2011 1:29 PM >> To: softwires@ietf.org list >> Subject: [Softwires] Yesterday's slides >> >> Hi, >> >> Could someone tell me where is Dave Thaler's slides? >> >> Best regards, >> --satoru >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > > From cb.list6@gmail.com Thu Jul 28 14:42:35 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC74221F8C0C for ; Thu, 28 Jul 2011 14:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bShOIK4HiUbc for ; Thu, 28 Jul 2011 14:42:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB3FD21F8C0B for ; Thu, 28 Jul 2011 14:42:34 -0700 (PDT) Received: by wyj26 with SMTP id 26so122595wyj.31 for ; Thu, 28 Jul 2011 14:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gp9knLxQ5jP7YdleDX4fNmLAWqu9ti9HDo8CAaJ8vk4=; b=owtrxeE2ah7mrSYiVpGP1Nq1l+n4bOpbfcq1rCMM0C1HwTcMqioX4anBLiMu56uunK sZZkMdy6HWCPwA8Js14/bU9UsyOudHkUyU+T7f8GGjdBcG2ihxYqMi7na68ME42FNa1U ur5bEJsYRQq6Qbf5OwsfzW8UoE361Nmc/nG6o= MIME-Version: 1.0 Received: by 10.227.197.196 with SMTP id el4mr596601wbb.103.1311889354039; Thu, 28 Jul 2011 14:42:34 -0700 (PDT) Received: by 10.216.179.71 with HTTP; Thu, 28 Jul 2011 14:42:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 14:42:33 -0700 Message-ID: From: Cameron Byrne To: Hui Deng Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org, wdec@cisco.com, Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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 Jul 2011 21:42:35 -0000 On Thu, Jul 28, 2011 at 10:48 AM, Hui Deng wrote: > Hi Cameron, > > You may need spend time to review it later, it's different from 6RD and > DS-Lite, > I just now read it in more detail. My first piece of feedback is that it is too long :) I assume future revisions will be more tight. I would also say that the translation part be put into a separate draft that goes to BEHAVE. I believe the mapped mode has some similar challenges in mobile as DS-lite. It is an IP in IP tunnel. It is really a non-starter in 3GPP networks as the draft amply notes. I believe it is best to state that clearly for the 3GPP case, and move on without elaboration. The translation mode looks like NAT464, and i like it NAT464 + DNS64 since it solves a real problem, as noted here http://www.ietf.org/mail-archive/web/behave/current/msg09480.html Is the reference to RFC6053 right? "The operation of the 4V6 CE and gateway are very similar, if not identical, to that of stateless NAT64 as specified in RFC 6053." So is this right? CPE/UE (NAT46) --->ipv6 only network--> NAT64 (stateless port restricted) And the port-set is delivered via some encoding in the IPv6 address assigned to the UE? This is clever. I remain concerned about being able to engineer stateless port allocations that sufficiently meet everyone's needs with a limited free public IPv4 pool vs. dynamic allocation. I do not have much experience with stateless LSN, i am not sure anyone has much experience at scale with port restricted stateless? I believe there are ways of going beyond 65k ports per IPv4 address in stateful, what about in stateless? I think this will be a requirement as the IPv4 pool keeps getting stretched thin. Right now, i feel like it would be easier for the IETF to just define NAT464 in general and stateless translation 4V6 is a flavor of NAT464. I understand the allure of stateless. But, IMHO the address multiplexing of stateful is very useful and many large SPs already run this way, and that operational experience is very important. The IPv6 transition space is becoming very crowded, i personally would like to see more work to make IPv6 a true replacement for IPv4 instead of yet another transition mechanism that meets some set for checkboxs. This architecture is complicated. CB From Tina.Tsou.Zouting@huawei.com Thu Jul 28 03:46:47 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDA821F8C06 for ; Thu, 28 Jul 2011 03:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCk8vKal28x6 for ; Thu, 28 Jul 2011 03:46:47 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BE4BD21F8C01 for ; Thu, 28 Jul 2011 03:46:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP100F6JHXWU6@szxga05-in.huawei.com> for softwires@ietf.org; Thu, 28 Jul 2011 18:46:44 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP1003VXHXS9H@szxga05-in.huawei.com> for softwires@ietf.org; Thu, 28 Jul 2011 18:46:44 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACW21564; Thu, 28 Jul 2011 18:46:41 +0800 (CST) Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 28 Jul 2011 18:46:34 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.19]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Thu, 28 Jul 2011 18:46:38 +0800 Date: Thu, 28 Jul 2011 10:46:38 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.246.67] To: Satoru Matsushima , Qiong Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Softwires] [softwire]comments on stateless 4v6 domain Thread-index: AQHMTO/PDEl+CLgJXUy4AkZF7chel5UAyjqAgAAXW4CAABd3AIAAk8LQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> X-Mailman-Approved-At: Thu, 28 Jul 2011 16:25:42 -0700 Cc: "softwires@ietf.org" Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 10:46:47 -0000 Matsushima-san, In this draft, we may need to refer or define the definition of - Stateful operation - Stateless operation - Dynamic port allocation - Static port allocation Hope in this way, the discussion could be easier. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Satoru Matsushima Sent: Thursday, July 28, 2011 5:56 AM To: Qiong Cc: softwires@ietf.org Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain Hi Qiong, On 2011/07/28, at 4:31, Qiong wrote: > Hi, Satoru, > > Thanks a lot for your suggestion and I understand it can work. But in my understanding, it still lies some differences with the so-called "totally stateless solution". I don't mean that 'totally stateless solution' isn't a part of routing system. > Suppose there is only one domain, when an IPv4 downstream packet arrives at stateless gateway, it would firstly forward to the virtual tunnel interface (take 4V6 Mapped Tunnel for example) with only one default route. Then after encapsulated with a uniform IPv6 prefix and IPv4 prefix, etc, it will lookup IPv6 routing table and forward to 4v6 CE. Here, actually there is no need to do routing lookup for IPv4 address expect one default route. You already did routing when you found default route. > However, if we introduce multiple domains with multiple IPv4 prefix pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, Nm would not be a small number anymore. So maybe some more optimization work will still be needed to make it more "stateless" ? What do you mean 'the entry number of IPv4 routing table'? Do you presume that your IGP routing has almost 300K routes as same number of current internet full routes? Best regards, --satoru _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From dthaler@microsoft.com Thu Jul 28 12:45:07 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8440411E8147 for ; Thu, 28 Jul 2011 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.552 X-Spam-Level: X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqXj2dA6R04z for ; Thu, 28 Jul 2011 12:45:06 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 204C011E80F0 for ; Thu, 28 Jul 2011 12:45:06 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 28 Jul 2011 12:45:05 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.1.323.2; Thu, 28 Jul 2011 12:45:05 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.230]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Thu, 28 Jul 2011 12:45:04 -0700 From: Dave Thaler To: Satoru Matsushima , "softwires@ietf.org list" Thread-Topic: [Softwires] Yesterday's slides Thread-Index: AQHMTUvbTxfJJyZcp0uk7fBnTS8kdpUCIpYg Date: Thu, 28 Jul 2011 19:45:04 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> In-Reply-To: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: multipart/mixed; boundary="_002_9B57C850BB53634CACEC56EF4853FF653B1A3F4DTK5EX14MBXW601w_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 28 Jul 2011 16:25:42 -0700 Subject: Re: [Softwires] Yesterday's slides X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 19:45:07 -0000 --_002_9B57C850BB53634CACEC56EF4853FF653B1A3F4DTK5EX14MBXW601w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attaching here since they don't seem to be posted yet. -Dave > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Satoru Matsushima > Sent: Thursday, July 28, 2011 1:29 PM > To: softwires@ietf.org list > Subject: [Softwires] Yesterday's slides >=20 > Hi, >=20 > Could someone tell me where is Dave Thaler's slides? >=20 > Best regards, > --satoru > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --_002_9B57C850BB53634CACEC56EF4853FF653B1A3F4DTK5EX14MBXW601w_ Content-Type: application/pdf; name="Framing Discussion.pdf" Content-Description: Framing Discussion.pdf Content-Disposition: attachment; filename="Framing Discussion.pdf"; size=142992; creation-date="Thu, 28 Jul 2011 14:19:29 GMT"; modification-date="Thu, 28 Jul 2011 14:19:29 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDI0IDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDQvS2lkc1sgMyAwIFIgNyAw IFIgMTkgMCBSIDIxIDAgUl0gPj4NCmVuZG9iag0KMyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVu dCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9J bWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMg NCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1Rh YnMvUy9TdHJ1Y3RQYXJlbnRzIDA+Pg0KZW5kb2JqDQo0IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDIyMT4+DQpzdHJlYW0NCnicdY7BasJAFEX3A/MPd5m4eHlvMpmZgLgw0aIg VAh0IV2UUiULU2ro/5vEKrGtu4G575yD5BnTabIpViV4NsO8LPClFYOJmcUY9vCGkVnG6UOrlwka rQSH24bZCdu70X6i1VYrLDYFMBLIj2BeaZUsBdYSO4tq3xM7HAQSAoUUJs8p636OvWZwPWm1i5an WEL0dqybA2IblXX7/t229WcTv6Jaa7XowD38SstSIbFj2i7CaPun0PwqFHNX5zyTczBMuQmXOspS PxQOj6FSHtQ478iH8fU/NWdHok/SDQplbmRzdHJlYW0NCmVuZG9iag0KNSAwIG9iag0KPDwvVHlw ZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GMS9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaS9F bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgNiAwIFIvRmlyc3RDaGFyIDMy L0xhc3RDaGFyIDEyMS9XaWR0aHMgMTA0IDAgUj4+DQplbmRvYmoNCjYgMCBvYmoNCjw8L1R5cGUv Rm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbGlicmkvRmxhZ3MgMzIvSXRhbGljQW5n bGUgMC9Bc2NlbnQgNzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUyMS9N YXhXaWR0aCAxNzQzL0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUyL0ZvbnRCQm94 WyAtNTAzIC0yNTAgMTI0MCA3NTBdIC9Gb250RmlsZTIgMTAyIDAgUj4+DQplbmRvYmoNCjcgMCBv YmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBS L0YyIDkgMCBSL0YzIDE0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1h Z2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA4IDAgUi9Hcm91cDw8L1R5 cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVu dHMgMT4+DQplbmRvYmoNCjggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzk3 Pj4NCnN0cmVhbQ0KeJydVk1v2kAQvSPxH+a4Gymbnf20pYiqIUmbSpHSFimHqAcXTLAKNsWkaf99 ZxeSYoNR1JPxMm9mdt6bGcPZHZyfn90Oby5BDgZwcTmEn/2eBCmklKiU9OCVBGskrPJ+7/4Eyn4P 4fHVRkqH0jSMpif93ud+D65uhwA7AXAb4GLU751dIxgjpDMwmgaP5A4Q0KOgkMYmwqYwWoQwMdaH fu+BfeHoWT7PeMLWRVXW/FSzWbEEbtiao2QV8FPDPlb8VLGap2xd828w+tTvXVHEEPUljDWpkGo3 zAODHdu91FUjdQVa7aVutKDzRAptNx7PpUz8oJnA2bU+hPVSKGVaaG2v9tB4CJ1o4VwTzdaznGu2 4qhYDh1VQCdF2sIVNcGgrLowSqUCdROTc7Ts9zIfEwmaZdwTO0RJVXY50UkqVMtJp23qhGnZTrki 9yvISq6Q/YEfRTmhgMS+ZdUU8nLS9vZSucNlNyjSF9+zqg5FW8c6BIfxUkFZmn3PYZmt1iFUFd6n QGXuTNx5oWzTeT3LiBLD8gnc3FGAX6YLbZUVupVaNpmsQjJ5Xe/fTx+5n9TCvsoKUzlQkp5DP/Cb V9Th+X7zxCuJ3pL6rjvU1+5YLXzSiHG8lXSrlZQXqWumnca0lVOhgC+9dIEH8tkHo8SQzy6Y3c+y MA0inUUdSZtyTFlWzImEJyqqC11C/y6qSR6pfp7lJN/ThFScA2HCWVR2IGCj83EcP/nkXQeFjuZb 2srkaGXMmyujSBX6fyuzA2bDarEMkrTb+6+pTt29T2JMbNNB9hQhY+6oUtxSa3Z0QxiPLWxn59B0 dti0fZ4V4xml6NkiI4rqYlFQtHm2imfjeVYsumjQLky5zsh7NNg2DbSmVEv0aIkIwMQJ5Y5NezyI 1rqNZl+Lx7KYFmOOyGis0TIjudKyo1U3DW808mi/rehQv+46w5Yb6sIkiZO+3MpcbexJ309bcoOw u0aNlmEZNtI5WiDX2uP7QyHuQjQqXPMNDn3LIaqGN0dzzDlQtK1UsvkoEFb7+GEQf8SPA9XFv3dR 9v/QB7L5C96Z30QNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3Vi dHlwZS9UeXBlMC9CYXNlRm9udC9BcmlhbC9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRG b250cyAxMCAwIFIvVG9Vbmljb2RlIDEwNSAwIFI+Pg0KZW5kb2JqDQoxMCAwIG9iag0KWyAxMSAw IFJdIA0KZW5kb2JqDQoxMSAwIG9iag0KPDwvQmFzZUZvbnQvQXJpYWwvU3VidHlwZS9DSURGb250 VHlwZTIvVHlwZS9Gb250L0NJRFRvR0lETWFwL0lkZW50aXR5L0RXIDEwMDAvQ0lEU3lzdGVtSW5m byAxMiAwIFIvRm9udERlc2NyaXB0b3IgMTMgMCBSL1cgMTA3IDAgUj4+DQplbmRvYmoNCjEyIDAg b2JqDQo8PC9PcmRlcmluZyhJZGVudGl0eSkgL1JlZ2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAw Pj4NCmVuZG9iag0KMTMgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQXJp YWwvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMC9DYXBIZWln aHQgNzI4L0F2Z1dpZHRoIDQ0MS9NYXhXaWR0aCAyNjY1L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQg MjUwL0xlYWRpbmcgMzMvU3RlbVYgNDQvRm9udEJCb3hbIC02NjUgLTIxMCAyMDAwIDcyOF0gL0Zv bnRGaWxlMiAxMDYgMCBSPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBl L1R5cGUwL0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2Vu ZGFudEZvbnRzIDE1IDAgUi9Ub1VuaWNvZGUgMTAxIDAgUj4+DQplbmRvYmoNCjE1IDAgb2JqDQpb IDE2IDAgUl0gDQplbmRvYmoNCjE2IDAgb2JqDQo8PC9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaS9T dWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRlbnRpdHkvRFcgMTAw MC9DSURTeXN0ZW1JbmZvIDE3IDAgUi9Gb250RGVzY3JpcHRvciAxOCAwIFIvVyAxMDMgMCBSPj4N CmVuZG9iag0KMTcgMCBvYmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUp IC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQoxOCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRv ci9Gb250TmFtZS9BQkNERUUrQ2FsaWJyaS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3 NTAvRGVzY2VudCAtMjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGggNTIxL01heFdpZHRoIDE3NDMv Rm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNTIvRm9udEJCb3hbIC01MDMgLTI1MCAx MjQwIDc1MF0gL0ZvbnRGaWxlMiAxMDIgMCBSPj4NCmVuZG9iag0KMTkgMCBvYmoNCjw8L1R5cGUv UGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSL0Yz IDE0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRp YUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAyMCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1Mv VHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDI+Pg0KZW5k b2JqDQoyMCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5NzA+Pg0Kc3RyZWFt DQp4nJ1WS2/jNhC+G/B/4JFa1MwMH6IEGAISx1tsgS22qIEegh78kL0GHCu15G3z7zuk5ERULCXY g216OM9vHhx2841NpzdfZ1/uGWQZu7ufsX/GI2AgAAClBMusBGY0sFM+Hv31iR3HI2S7Fx6AGEEH TNtP49Ef4xGbf50x1jKAjYG7xXh08xmZSkWaaLbYOo2kjiEzRoCSTCdKpMgWj86Mt/XrePTA/6wi RL6MEl7t1yz6my1+G4/mpM1pvKhAo4RWbRVsAgJTxRbrB/6j7BNLYsffFgMv0WsnjQXEbYEHvnk+ Lh+da4Y/FaeKRRPFl2W53x0f86PzvSpZRe4XXaUXOOIADSlTEZMJZV5NfPn2Q7PyvCIT5fq0X+Wn SALvi0qnILQONbRtv8mRDHIkmZIUZJgjrQTRE02Y1hqnAInNugGpa7IWhJS6K6014J0BRCo5c5sp IoECtPdUgYk7ZxM5BUxv3TWxzS8syszrK2tqds9yn2kizSBD9wsys9PgxjHamIQ/v+p2pnHu6Fnq uTNU05qUzDIJjgaeXXmdnoxxo805TxoRbz3LldwSFNeR0JRi1WSmjFDxyn0tI0s1Him+Zk9FNJGc iqnMKedVX6ZljAJMqG8w06qTaWm75WfT2kVEYfElWXd4Jb63wggklQTCvn+b2KKU5/TZng+9/ZgK DI0PtKIRJmRdHg6EXkGff8lcyVZF9Z3aMXmDMTXrRPPlceNvN8+R5k0P09+XJm6w/+Va37rYO2Os CV4mKLS5JLfwlvYlWaCT4Y/FKULDc7Y95K6H/9uv6IrO14NUEAu0oc7BBOuPJlhqLXT6kwluC/Nb ikjz3Xl/pEh2FGXMt5GUvDj52N9i3wCcXAD2bJsirw/Hoqoxc+q+06TDmLs5Crw6PBN/bz00rqEW 8gLV8uTs7s4EdyTReUTeSB5W5CEvqWL6WkxBKjSGagczYD44TNFKkeqhYYoDw7QtzX/P840vMFOH VtDYeFr6N6KOkmj5TYQpXx+Wpz2xbp99hW+oMA1fn0v3sy+ORLR8uSrOVQ8aMaGBofFBMOKPliPS YwXyJ8uxLdydN012+6pGQiJUYN4vDiYZXhykIsM2EBteHKRKXP0EnnY6493pqKQSSoU6BtG3V9Dv DK0G/jTxT9V76F+feC1hj75uv2R93Up1HIh62OP0nX0tpRUikHoHdQC3S7Ud3LgZ4oa9K3yqd5or NI/I1ZeRFPe/txqoc22gbzABSWf5RRngF1vvngSRyqRefIVR1i+//uAXYNXXizb2A+9V+oo3/wPP Z3xEDQplbmRzdHJlYW0NCmVuZG9iag0KMjEgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAw IFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSPj4vUHJvY1NldFsvUERGL1Rl eHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRl bnRzIDIyIDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC Pj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMz4+DQplbmRvYmoNCjIyIDAgb2JqDQo8PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDczMz4+DQpzdHJlYW0NCnicnVVbT9swFH6PlP9wniYbDde32ImE mEZhiElMTKvEA+whlJRGo3HXhMv+/Y6TMurSdBUPrVr73L7vfOcYBhdwcDA4H54dAz88hKPjIfyO Iw6ccc6FlNyClRwSzWFRxNHlHlRxJODunw3nRnAdGE324uh7HMHJ+RBgJYFYJjgaxdHgiwCtGTca RhMfEcOBAGFTZhPQScqSDEYzn6bNdRpHV+SCipS4mu4rUpc39wXk8/mCCk1cPp7606KmP2H0NY5O MIVP8xI30YJJuRr3isCK7ZtaZVCrBCXf1KoVw/OUM5V0EQ84T+1hWIDHucHXcixHB95k6KqaioQ0 CyolycsK6L4hDRWKOKjnxbicUE3KMVAEWlFhyGOJ6C1x1cz/56TphS8yZmyYbit8tQZfWpaZEEHW IVAZQ4284D8SG/C/dRZcMJsGzuTkeX6fl4jN41Zk6mhCnloKJh0f93j3sPC4CzxOyMzdFq1pWYOX AbKC/Dx6IpZ00IwUt4NZiZGa8o6KjOTULo97mDKJZjYsbCtReleiZNYq+31ErTqTzw+NR+fG1GDr EdukB4vkmkkTOn9ExjQxnkuHn6d57unGcN+Oqcz89eZYyis2CWN5ult5jnucNBaQrTn1JdBCMCVC W98p535hgZI00xLT1fgbu+jHXnI/9q1U+nopFTNyt/QvROOC0GKXxicbFsSG/SAFfmf/3w8b18Oq M/nhJs1T2a67og8Eak2FXr14U8NUGtpekw9wU0xz39JujK4pdFq7zf3q/QOrl1A53xioH1BI4+l6 pu2bT1jNUrNMPKa41v3yU6/LrxvgPmFzlqzF2Noss+uUCqVYkr5zSledyVkFruoWlZtAMy3qoh29 S9T0aQ1u0V5VrvnUNxCSM5uFQbeCtGvPa9+TlaLEdY88tuLTlomd6E7XKhEyCGdQAwb3EmeZ7JBh O5VtH/r2R/vY676ptqad1FfvDdX8BTxK04ANCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9iag0K PDwvVGl0bGUoUG93ZXJQb2ludCBQcmVzZW50YXRpb24pIC9BdXRob3IoRGF2ZSBUaGFsZXIpIC9D cmVhdGlvbkRhdGUoRDoyMDExMDcyODEwMTkyOS0wNCcwMCcpIC9Nb2REYXRlKEQ6MjAxMTA3Mjgx MDE5MjktMDQnMDAnKSAvUHJvZHVjZXIo/v8ATQBpAGMAcgBvAHMAbwBmAHQArgAgAFAAbwB3AGUA cgBQAG8AaQBuAHQArgAgADIAMAAxADApIC9DcmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4A IABQAG8AdwBlAHIAUABvAGkAbgB0AK4AIAAyADAAMQAwKSA+Pg0KZW5kb2JqDQozMCAwIG9iag0K PDwvVHlwZS9PYmpTdG0vTiA3Ni9GaXJzdCA1ODgvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAx MTY0Pj4NCnN0cmVhbQ0KeJydWNtu2zgUfC/Qfzh/IPFOAkWB7bZFi2yDIA6wD8E+qIk2MepYgasA zd/v0Dx2vDFJuQLiUJQ4Z86FHJGSnlpSkowgJUi0ipQiYQ0pQ1LikSbpBH64j2eOtNCkW9JxSAAM dzQZF0grshitHdkg8JwcfjqQh03tyRtPRlIQJnIF15JpwQfD2qD1GCRJCKMIf0IKYOGPtI4Mnitl yWi0Ho5YEhqGjSMMb8nCjvEIIcBxuG0xzgYPb0g4gGBCeCHJAuct7mNckJZwKQJwiES2CCmGKVpN cA306CN0KTw5hRYdZ0kqpMphvPK4L0lqxGjRGgE/gDfxvidpEaNzSBuCN8A5kHvY9TETsBfalkAt A4KNIbWI11u0MBqQdYG4fECLm0GiQEgysqpUxHm0yGbQqI7EeNRFgzTAjkFyAuwYgAIqZJFkj9a1 jpAS5dDxwHlUUsCWCvEBiAKyF4vYSniHKooWURrUBAVGrrQ20WvUKs4QjxYdE1t462O50Xn3rrmI M6Wly2bRLB67dXP1/Ng3i3HzdDN+WvUPzcUdqe3zM2rfv3/7ZgvBxEuQL+IIcHZN4h/a4/aYPc1V /2v8PvzKAVErjJmJzsEwvRPsIkcnZ/tpin7uCBer5W2fJY3r95JTGNfuttElg5ge9eq44+qEU6rj 8jSVqLHi9k7+H60Vo//6MNw+V1L9CiZ3sK9ZPl3ks1N8KgszdT5X5PNTfHoOXyjxGTHFZ7Kwtspn ZDG+vaNZnCjiZA2XqsTJY+eyVkTVSloh2kzCs2vczp7tMrmtikWqaouby2uKgU5ri3JJTUJKWZIY U1xGZkpbRDgSF3OSuCTgMVElbnswP17B7any8hpX1xery4ynCsxrXH3FW1dmPFVifpMxlBmrizdl gN3K4l075bGZUxUnyoyT88DmcROM5XngzBSjm8VoZ1YlZYDdyuOrYppWEk8ariA7O3/hluFut5fK SqSfTenKs3JaJE0SySRknC/2NB/ETvFKKinFkUr6XRWrKpmAx0SVyP3B6+gV3E9qlszj6griXZkx TDGqPM5XGUNbZAyTGyM9i1GWY6xujVIG2K28x5OaZeZUJegy4+Q8sHncBGNlHlRzFGwZqKvJTa+g VDtOJHtZt1bbkM1Zc0ktgy+nPNSY/WzmeOAvcU4LnU/ynrSIs8OuZiweGLja9P3lMIzN5bDqv3WP 8btC5LroNv16+zR+Ydhq3jWfl3lry+rNwUWWPeQcYZ71z6SZ7zMI1sPYN+fx36f17Utnl5FFfzM2 X/rutt+k64jZXX9dr5brfnHfRbfjjT/WsNCNy2HN/c24/LfDxbb397D58X0YfjQfh5unB/i0vfPz vu/H6OTYfOtuNsNB/897/D/of1x2q+Hu4EbK+8vYxINhd5vuofm8vHva9Bzr+dPDz2tkRCa5EPGD TLyQ8YvMNnvxk8w2YxHx8pEglW73uSE+4S1+OovzEZlPrnyg5HMen1z254kI5ldf2mrz/pc3pbxT 5O0X74l4o7J/30Ybu1mVrKe3A0s26yiLEysGr5uXufz2zX8gqk2IDQplbmRzdHJlYW0NCmVuZG9i ag0KMTAxIDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMzOT4+DQpzdHJlYW0N CnicfZLLboMwEEX3fIWX6SIC84iDhJBSaCQWfai0H0DsIUUqxjJkwd/XzJBUzaKWwDqae80dxn5R lZXuJua/2UHWMLG208rCOFysBHaCc6c9HjHVyWklfMu+MZ7vzPU8TtBXuh28LGP+uyuOk53Z5qCG Ezx4/qtVYDt9ZpvPonZcX4z5hh70xAIvz5mC1h303JiXpgfmo21bKVfvpnnrPL+Kj9kAC5E5hZGD gtE0Emyjz+BlgVs5y45u5R5odVdPyXVq5VdjUR05dRCEQb5QHCPF5UI8CJF2HIkHRBHRgSgmeiJK kMI90Q4pWZV7opIoxXRrDn5NdW2Ci2SRcbEjdbmqqS7umuBiPfSIn9gXSCJESim2oNgphREU+zEh otjFqqTYhSD6P2iUYOdRcnRb6Fx/gi7/f7kmt+HKi7VurniXcKDLKDsNt+tmBrO4lucHKwC7ww0K ZW5kc3RyZWFtDQplbmRvYmoNCjEwMiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCA5MDMzNC9MZW5ndGgxIDE5MDg3Mj4+DQpzdHJlYW0NCnic7HwHXJxVuv45801jCjPDDDAwwAwM DCFASCAJpDKhpScQmASSkEAg3fQe0+yKxt5i7y2WYTAGe9TYu+uqq6vG1VV312is6yYC9znfOyfN 8te7e+/e/f848MzznPeU77zvKd+ZDS7jjLF4fGhZdUXt2NGH1n2TyTQv2RnznFlZVlHXbnOFGHvd zVjcVZVlE8rXfr9+I2MvbmNMf/noisqqT574+gemec7HmPL56OrJtQtbh53M2Mf3Mn6VZXRtqOzJ 9z7sYZqT9zA2etbk2oLCf3z01reM8bfw1KaWJc3Lr9t3/XDG+rRiAK6Wtat94Sv3vsZYw02M6VLm LZ+/5LvvJloYy1vPWEzy/OZVy1kK8+P5y9HePv+EDfM+aK1ewdgs9D+0bcHc5taPs7pHoP+ZKB+8 AAbrXYZByF+MfOaCJavXv+5MtDGmKWEskLd47sqlb6e8e4ix3Sg33HTCspbmqxddOJixHRMYS6ta 0rx+eXr/rBi070R739LmJXMDa2u+YexRtI9NWL5s1eoeDzsd46kW5ctXzl2++B5NN2OD0F+mnYnY 6q7prE2fvH22bfi3LMnIRHrwb5teEPxkxuUbDx3sOjvmM8N9yMYwDaOEdnrWzfhe03WHDh68LuYz taejkvKNsNgy2BamY2PRTsPsrIDNZcxxvvpczhRtLj8fpUbdDl0RukwjVl5hp2uYkWlsOo1Go1U0 2g+YpifI7uxRR4A0sdbnY0G4k0pjMFyjCfgYv1Z97m5drPAUvcceGQ1/GbN3vZiX3560Faz5J+2f sTuP8fjTY/M/l5S72J06C5vxo/5+ONJeo/11ff2WpH8Tz+37r+lXm3GkH239cXG4i43+Vzzj+GRI YyP+J/rtTf9/J+X3bOZvbaMdyHYoc9j0X1m36ZjnHWKNv6adZgXL+q3j+t9Myl426NfUE7GSmr/B TvtvP+/GY/rZ8VN19K1sx9HP+9FYSn7dnB2uf1RfmueO7VdJZzW/pg/N3Sz9tzzzn0kY78W/tq5y NcvQdf54DpV1LEe5lmX8a0fWm3pTb+pNvek/LWmu5CaplV2//P7mPazv/6s/pYGdCeT+1nEoicd/ h/zvJc0Sdhqw8V/R188lZRA7W7fmf/IJ/3sJ35MX/7vHIBPGcjewEpgP9I/a/s+Mrzf1pt7Um3pT b+pNvak39abe1Jt6U2/qTb2pN/Wm3tSbetN/XFKiSKF/heAZyEEpsUzL9TDkMR/TMguUlWWwAMuB pYANZINZKRvFxrJJrJrVsmlsIVvONrDrfKk9PWq/VrQLsD5q7QHR2uVsImpPQe1mtpitRO0U1OY9 3+J5K5WpSo4yQnkIP7E9TzDW83dmQD+pNMyelg/Lov9O0udHPqSon5kqBrKR0jNlnHIZi2NulAdY tjqS6WwW13Abt/Nknsb78Go+nTfyE/gyvoav5Zv5Wfwcfj6/gu/ie/hj/Cn+NNPzz9TevvzRv9Jw 9a/7RNKwX078qPGQvBzYomxVdUj9PAHYr3yufKEcgPrqR9M0kYm/BGXH+UOpglXicxoA/6K21T8x jB95DttRviN3vPf/15NyXHaWMvuf6K13xWPOg6NbZ89qnDljekN9qK52Sk315EkTJ4wfN3bM6KrK ivKyUcHSkSOGDxs6pKR48KCCfvl5fQJZmf4Mr9vlsNusZlOM0aDXaRUNZ3mV/qomXzjQFNYG/GPG 5Iu8vxmG5qMMTWEfTFXH1gn7mtRqvmNrBlFz3nE1g1QzeLgmt/uGs+H5eb5Kvy/8YoXf18mn19RD b6/wN/jC+1U9UdXagJqxIpOejha+SveCCl+YN/kqw1VrF7RVNlWgv3azqdxfPteUn8faTWZIM1S4 j395O+8zkqtC06dyaLuGGa3isWElq7K5NVxdU19Z4UlPb1BtrFztK6wvDxvUvnwLxZjZ2b72vD1t 53Ta2ZymXEurv7V5Zn1YaUajNqWyre2MsCM3nOOvCOds/MgNl+eG8/wVleFcPzobP+XwA3hYl2X3 +9q+ZRi8f/9nx1qaoxZ9lv1bJqRw8XCYUC41w9gwQviXni7GcnZnkM1BJrytpp7yPjbHE2HBgtyG sKZJlOyRJfEhUbJNlhxu3uRPF1NV2RT9XbvAHd42x5efh+irv1n4RbkvrASa5rQsENw8t81fUUFx q6sPBysggs1RXyvb+xegfnMTnFgowlBTHy7wLw+7/GVUAQafmIOFtfVqk2izsKs8zJpaoq3CBZUV Yly+yramChqg6MtfU38/K+rZ1z7Q5+kows5qEOMIJ5RjUgKVbfWt88LeJk8r1uc8X70nPRxsQPga /PVzG8Qs+e3hnH14XLr6RLUVfDuutqwsPDdkGX31Go/SIGYLBl8VPvxlw1Fgx3SpWTGjZcN99dzD ZDU8JVpDqGP6QUbJKh8jihTRtHyMJ70hndIvDMkTHZMuK2w8qi87DIfHRM/52aFRbTGgHF/l3Iqj BnhMp7roAKO9/fQ4NSIW0QejhVFM5xhZpGRh58KmQTeqScyi2xdm1b56/1x/gx9rKFhdL3wTsVbn d3ytf3zN9Hp1tqOrpO6YHJWXUC7M0lEsM5pyrMGqXI+cVjU/Ws0fzo45rnisLPa1Gf3ja9tE5/5o h8yHHQSn9YGxzWeXxA3E1qzC6eavavb77L6qtubOnm1z2tqDwbbllU0Lhoo+/GNb2/y19cM96lin 1G/2bBSPimPj+fi6svw8nD1l7X5+Zk17kJ9ZO73+fjtjvjPr6iMarilvKmtoz0RZ/f0+xoKqVSOs wigyPpERPU1BxqjW99wfZGybWqpVDWq+pZMz1WaUNs5aOjVks0ubBjYt2YKqTSRMknsBQozjttLX KqZnU8OCtqYGsblYAqYSvzzM/SNZWOMf2c41ekvY5J9bFjb7y4S9VNhLya4XdgMWBk/gCI44k9qa /DinsKDqmYfTUlREl77Onp66+vQXPfsb0rHUZgLT68MxuTj7dVnjUG+0QBPMo8PbWprFOFioXrQ1 ZI1tacCylR2iythwDHqIifaAGlVqG7Ec0agFc4MJVNtvQya8rSHckCseWr+wQV3O9jAb4x+Kaac+ dQHxoIKGtjh/obo3sRVMWWcIisHYWG09WTzI4mENFCSDBSNv8aOopcmHaGtZSy2WOp2lJg9Z5uJI 1AbmqjB5ooVMuKVkma2mcEw/dIhfoc39xJbUZRkaGmjwau6MaAU82x42Y0SBo0IZbYDooGisGAt+ z8BQRdXHRDc1nWyKfz1OFjFotScDisPWrLHNOPypvRkWf4lsbBRnhDnax16yGoTnFsRdyarr7LnV vyH9qJSf5xcvB7Ewmed+LGzW0Ha8ITwjNz/PeLzVqprb2ozWn25A8TJaD7Mw+irx1mAsEqP4OjWn 3hvj5uMgTpHiZClOkmKbFFul2CLFZik2SXGiFBul2CDFeinWSbFWijVSrJZilRQrpFguxTIplkqx RIoTpFgsxSIpFkqxQIr5UsyTYq4UrVK0SDFHimYpmqSYLcUsKRqlmCnFDCmmS9EgRb0U06SYKkVI ijopaqWYIkWNFNVSTJZikhQTpZggxXgpxkkxVooxUoyWokqKSikqpCiXokyKUVIEpSiVYqQUI6QY LsUwKYZKMUSKEimKpRgsxSApBkpRJEWhFAOk6C9FgRT9pMiXIk+KXCn6SpEjRR8psqUISJElRaYU fikypEiXwieFV4o0KVKlSJHCI0WyFElSuKVIlCJBingpXFI4pYiTwiGFXQqbFLFSWKWwSGGWwiRF jBRGKQxS6KXQSaGVQpFCIwWXgkUF75GiW4ouKX6Q4pAUB6X4hxTfS/F3Kb6T4lspvpHiaym+kuJL KQ5I8YUUn0uxX4rPpPibFH+V4i9SfCrFJ1J8LMWfpfhIig+l+JMUH0ixT4r3pXhPinel+KMU70jx thR/kOItKd6U4g0pfi/F61L8TorXpHhVilekeFmKl6R4UYoXpHheiuekeFaKZ6R4WoqnpHhSir1S PCHF41I8JsUeKR6V4hEpHpbiISkelOIBKe6XolOK3VLcJ8UuKe6VokOKiBTtUoSluEeKu6W4S4o7 pdgpxR1S3C7FbVLcKsUtUtwsxU1S3CjFDVJcL8V1UlwrxTVSXC3FVVJcKcUVUuyQ4nIpLpPiUiku keJiKS6S4kIpLpDifCnOk+JcKbZLcY4UZ0vRJsVZUpwpxRlSnC7FaVLIaw+X1x4urz1cXnu4vPZw ee3h8trD5bWHy2sPl9ceLq89XF57uLz2cHnt4fLaw+W1h8trD5fXHr5SCnn/4fL+w+X9h8v7D5f3 Hy7vP1zef7i8/3B5/+Hy/sPl/YfL+w+X9x8u7z9c3n+4vP9wef/h8v7D5f2Hy/sPl/cfLu8/XN5/ uLz/cHn/4fL+w+X9h8v7D5f3Hy7vP1zef7i8/3B57eHy2sPltYfL2w6Xtx0ubztc3na4vO1wedvh 8rbD5W2Hy9sOL+8QArfmSNpIL+7MkbR40MmUOymSNhS0jXJbibZE0iygzZTbRHQi0UaiDZHUUaD1 kdRy0DqitURrqGw15VYRrSTjikhqGWg50TKipVRlCdEJRIsjKZWgRUQLiRYQzSeaF0mpAM2lXCtR C9EcomaiJqLZRLOoXSPlZhLNIJpO1EBUTzSNaCpRiKiOqJZoClENUTXRZKJJRBOJJhCNJxoX8YwF jSUaE/GMA40mqop4xoMqI54JoAqicqIyKhtF7YJEpdRuJNEIouFUcxjRUGo+hKiEqJhoMNEg6mwg URH1Ukg0gKg/dVZA1I/a5RPlEeUS9SXKIepDlE1dB4iyqM9MIj9RBnWdTuSjdl6iNKJUohQiD1Fy JHkSKInIHUmeDEokSiBjPJGLjE6iOCIHldmJbGSMJbISWajMTGQiiqEyI5GBSB9JqgbpIkk1IC2R QkYN5TgRU4n3EHWrVXgX5X4gOkR0kMr+Qbnvif5O9B3RtxF3HeibiLsW9DXlviL6kugAlX1Buc+J 9hN9RmV/I/orGf9C9CnRJ0QfU5U/U+4jyn1IuT8RfUC0j8reJ3qPjO8S/ZHoHaK3qcofKPcW0ZuR xGmgNyKJU0G/J3qdjL8jeo3oVaJXqMrLRC+R8UWiF4ieJ3qOqjxL9AwZnyZ6iuhJor1ET1DNxyn3 GNEeokep7BGih8n4ENGDRA8Q3U/USTV3U+4+ol1E9xJ1RBJKQZFIwgxQO1GY6B6iu4nuIrqTaCfR HZEEnNf8durlNqJbqewWopuJbiK6kegGouuJriO6ljq7hnq5mugqKruS6AqiHUSXU4PLKHcp0SVE F1PZRdTLhUQXUNn5ROcRnUu0negcqnk25dqIziI6k+gMotMj8c2g0yLxc0CnEp0SiZ8HOpnopEh8 CLQtEo/DmG+NxA8GbSHaTM03UbsTiTZG4ltBG6j5eqJ1RGuJ1hCtJlpFXa+k5iuIlkfiW0DLqLOl VHMJ0QlEi4kWES2kdguI5tPI5lHzuUStVLOFaA5RM1ET0WyiWeR0I41sJtEMcno6dd1AD6onmkbD nUoPClEvdUS1RFOIaiKuIKg64hJPmBxxieU9KeI6BTQx4soHTaAq44nGRVy4F/CxlBtDNJqMVRHX FlBlxHUGqCLi2goqj7i2gcoicVWgUURBolKikZE4vN/5CMoNjzgaQMOIhkYcYmkMISqJOEaDiiOO etDgiGM6aBCVDSQqijjyQIVUc0DEIRzrH3GIvVlA1I+a59MT8ohyqbO+RDnUWR+ibKIAUVbEIaKU SeSnPjOoz3TqzEe9eInSqF0qUQqRhyiZKClibwS5I/ZZoMSIfTYogSieyEXkJIqjBg5qYCejjSiW yEpkoZpmqmkiYwyRkchApKeaOqqpJaNCpCHiRCzYY5vjFei2tXi7bK3eH6APAQeBf8D2PWx/B74D vgW+gf1r4CuUfYn8AeAL4HNgP+yfAX9D2V+R/wvwKfAJ8HHsfO+fYxd4PwI+BP4EfADbPvD7wHvA u8j/EfwO8DbwB+At62Lvm9YB3jfAv7ee4H3dGvD+DngN+lVrrvcV4GXgJZS/CNsL1iXe56Gfg34W +hnrIu/T1oXep6wLvE9a53v3ou0T6O9x4DEg2LMHn48CjwAPW1Z4H7Ks9D5oWeV9wLLaez/QCeyG /T5gF8ruRVkHbBGgHQgD95g3eO82b/TeZd7kvdO82bvTvMV7B3A7cBtwK3ALcLM533sT+EbgBrS5 HnydebH3WuhroK8GroK+En1dgb52oK/LYbsMuBS4BLgYuAi4EO0uQH/nmyZ5zzNN9p5rmu/dbrrZ e47pVu9pSpb3VKXEewov8Z4c2hY6aee20NbQ5tCWnZtD5s3cvNmzefzmEzfv3PzO5mCc3rQptDF0 4s6NoQ2hdaH1O9eFHtCczuZpTgsOD63duSakXeNas3qN8s0avnMNr1jD+6/hGrbGvsa3RrGsDq0M rdq5MsRWVq/ctjK8UjssvHLfSg1byU2dPXs6VnrSqsDBTSut9qoVoWWh5TuXhZbOWxJahAEuLJkf WrBzfmheSWto7s7WUEvJnFBzSVNodkljaNbOxtDMkumhGTunhxpK6kPTUH9qSV0otLMuVFtSE5qy syY0uWRSaBLsE0vGhybsHB8aVzImNHbnmNDokqpQJZxnKfYUX4piFwOYlIKRMA8v6+8JevZ5Dni0 zBP27PEocbZkb7Imx5bEyycn8WVJW5POS1Js7pfdmqA7J6/Klvhy4vuJXyRqncHEnH5VLMGe4EtQ 4oVvCRPrqlQurSAeMEj1dWKCP1Bli+e2eG+8ptIbz5ljn+OAQ4l/1P6yXWOzcZutx6YJ2lDdFuuN 1YiPnlglGDuguMpm9Vo14qPHqiQErbCIHrMt1XVVNrPXrAmVmiebNUFzaXlV0Jzfv4op3Mc543aQ YhSj4PHeKuzrjgSu43ift9fV5uaO7zSyKePDxuoZYX5mOKtWfAZrpof1Z4ZZaPqM+nbOz21o55ry urBL/Iutmj9t+3ZWljo+nFpbH74utWF8eBtEUIgeCJbansDKGnJnrVqzKjd39Sx8zFq1Olf9RY6v EblcYRS/q1YjL37WqHmW+4uJqoFmr0JaLY2rf7nV//XE/90D+M9P7Uz8kcGoHs2prFVzCnAycBKw DdgKbAE2A5uAE4GNwAZgPbAOWAusAVYDq4AVwHJgGbAUWAKcACwGFgELgQXAfGAeMBdoBVqAOUAz 0ATMBmYBjcBMYAYwHWgA6oFpwFQgBNQBtcAUoAaoBiYDk4CJwARgPDAOGAuMAUYDVUAlUAGUA2XA KCAIlAIjgRHAcGAYMBQYApQAxcBgYBAwECgCCoEBQH+gAOgH5AN5QC7QF8gB+gDZQADIAjIBP5AB pAM+wAukAalACuABkoEkwA0kAglAPOACnEAc4ADsgA2IBayABTADJiAGMAIGQA/oAO2oHnwqgAbg AGOtHDbeDXQBPwCHgIPAP4Dvgb8D3wHfAt8AXwNfAV8CB4AvgM+B/cBnwN+AvwJ/AT4FPgE+Bv4M fAR8CPwJ+ADYB7wPvAe8C/wReAd4G/gD8BbwJvAG8HvgdeB3wGvAq8ArwMvAS8CLwAvA88BzwLPA M8DTwFPAk8Be4AngceAxYA/wKPAI8DDwEPAg8ABwP9AJ7AbuA3YB9wIdQARoB8LAPcDdwF3AncBO 4A7gduA24FbgFuBm4CbgRuAG4HrgOuBa4BrgauAq4ErgCmAHcDlwGXApcAlwMXARcCFwAXA+cB5w LrAdOAc4G2gDzgLOBM4ATgdOY62jtnHsf479z7H/OfY/x/7n2P8c+59j/3Psf479z7H/OfY/x/7n 2P8c+59j/3Psf479z1cCOAM4zgCOM4DjDOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4Dj DOA4AzjOAI4zgOMM4DgDOM4AjjOA4wzgOAM4zgCOM4DjDOA4AzjOAI4zgOMM4Nj/HPufY/9z7H2O vc+x9zn2Psfe59j7HHufY+9z7H2Ovf/vPof/w1PDv3sA/+HJPXsWY4ZrGOu+6Ji/za5mi9gqtg0/ p7Pt7CL2KHuHzWGnQO1g17Fb2O0szB5jz7I3/4m/VP9R6t6gW8Isym6mZ07Geg727O++BejUxR5l uQg5p9Z3xNJj7/n8ONvn3Rf12Ls79XHMpLa1al6D9Wve1XMQ71fkewaLvOYMaJva4kvDNd33dN96 XAxq2HQ2g81kjayJNcP/VraALURkFrMT2BK2VM0tRdl8fM5DbjZq4SxR9ZFay9hyYCVbzdawtfhZ Dr0qmhNlK9T8GrYOP+vZBraRncg2sc3Rz3WqZRNKNqr59cAWthUzcxI7WVWSyXIKO5Wdhlk7g53J zvrF3FmHVRs7m52DeT6XnfezevsxufPxcwG7EOvhYnYJu5RdjnVxJbvqOOtlqv0Kdg27FmtGlF0C y7WqEqUPsafYLnY3u4fdp8ayBVGjiMi4zFNjKP4bhU3w8JSjRkzxW3c4Wlvgu/CtLerpethPPqrF 2mgcRc1TUJN6oXkQvWw+LhLnwwfSRzyi3CWq/0esR0fll6wyHlcdFZkr1ZxQx1t/Tl/KrsYOvB6f IqpC3QBN6lpVH22/5nDd69T8jewmdjPm4lZVSSbLLdC3stuwt+9gO9md+Dmij1bEd7O71JkLs3YW YR3sXszkfWw361Ttv1T2U/aOqD1y2HI/e4A9iBXyCNuDk+Zx/EjLw7A9GrXuVW2Uf5w9gbyoRbmn 2NM4oZ5jz7MX2MvsSeReUj+fQe4V9hr7HXuTW6FeZX/BZxd7RfcRi2WjGNM9gDhfxWbhR4dTaZXy Gk4RhRnYEDaRTWIzHmJWvO4T2FC+a1d8RYUx3/AIXuUa5sNlwMg4Lw/atBrr7uTkUv/uQfrtimNs J8+/t9SwHdfc0q73ul4q6Hpvf9yQgv284N0P3vvA/uVLjiEFRR+8/sGA/tyR7lDhitUYDC69P6Of ZlB2YHBRUeFIzaCBAX9GrEa1DRxcPFIpKkzTKC5pGakRea689sN0ZXKXXrPFXzq1SJeWbHNZ9TpN ijsuf3iWvXZG1vB+qQbFoFd0RkOf4rKM8SdUZrxtcKTGJ6TGGY1xqQnxqQ5D1zu62INf6WIPlWtP OHSxoh82szRTudxk1Gj1+s40d1LfYeljp9qcdq3ZaXckGA1xDkufipldp8eniD5S4uOpr66JCIu/ 56B2i86l/ndIV9/PMns+vddi5xP8nVER6Ow5cK8ZwiyFCSKYLFSWXXxa1U+L+hnsw7NEcZ6ZT8z0 B7K+sZgt7oxUv8nKE7QWZrFbNPf4H/W/7Ff8Fr8lLnVKXEgXYqWlpXFDhhQUNDY6Eoc4IB1F9v2F jiJEPLeRXoUsNzcrIUGvhjxbSVdiFX9GIDC4mFOcEw1+JV27xsjtWV5vljNGu6zr40WKyelPSc2y cSOPaK1J2Wm+vsmx2hP5+/zxEQmeWK1isMTwYd3PxlhjtLpYT4I2Yo41KorRZt7edaL4b+qaew5o Lbo0rKw5HSlsWC5i0mHnE8EHOmwqf9ZhVfnzDovKn3bA8dxH8L0vlrl5AUtnAZ4XcdZqH+R92SDW n/drj5mKZfb6fgFe8IHqnP2NvQP6Z7li9UctFX18dOmIRRXvStOINSZc1Vo0OqMrOPvEsVueP29i 7aWvbi1ZNL3KY9QpWqPZGFs4ecXkqdtbiwe1nD9j4qqagTaDSa/strvjYl052Z66m768+vof7pkZ 7+vriXUmx7lSnDHZBdmVpz+26cSHt44KFAT0jjSsijsZ056HfRXHvGxdMLU0nTvd8Nxph9tOF3x2 xsFhpxveOh/EN1zGkik2ydHYqGxV+TsRm+RobJIfxHfRGMTGEomt8XTyQLuujpXuLz0ci9eJBvRv FLvMn54RGOQYOLgoHZ4bBiIafocIhPa8qTcfuKX788ScnESeddunV9fsGrjsjtPvad90x8ohmitu O3TzFG+29uRs77QbP92xcNep435wjNz2mJhTeKZsgmd5bG17cnZ0RrOjo86Ojjo7Ours6KizOzWO YEyM0+f0YfDJndwYtG4L8D0B/kqABwL6JPGPBtaabFC7nvzBCdK4YiXcKlCXtp3cKlTn+Vi31IlO dxwnlU1ak9XYdZHwUDPPaDXqdPjo1vOIEctVGwM9ScONVpN2dJwnzkjeGuM8rjiPw9i9KMae4oxL thu6BxgdHtXvnoNKHfzOZjPbDc6o386o386o386o386o3074vcuaytJSDXCtw+lM0nfyPh0ZNUli 00ZPyYK9jiGHveM/ckaegNJdpQ6OGboRPQMGr+qg0eVLdme4jHC1SrXudabAizEGuyfe6XHEdP3Z YDXodPjQ3i28TBUezej5XLte52Ol7IZgakqKzS1WqFusULcdvrhNFqHghVvMnpU9ms192cHspmwl 2xb13xb13xbdybboTrZF/beJv1guGMgHuju56d6MjCEFIx/kJrx3TDwnMqTW1cnz2gumivnGbnZQ OBqj67ixcS8pmKNxOWY3Dy52iFUgdrsaLQRKe9T+12rXa40Wg6Vk1inTF9+xtrRy4+1zh584qPt1 h0Mbg3PrSnNCnClu6Mw5rQMu/ezGqY237z9/3MlzK5NN2lnOVKcx0C8wqe2RZZv2nFqRmso3ZGQi jEajPSWu25kcSM1wWxrvPHDxFQfDzcn+nOQMWh/aarwHCljnvaUDuN8SDZElGiJLdIlYokvEEg2R RQQ3JTHTLKJvFtE3i+ibRfTN4nwwd2rswUQWjOcTWdApPuwOfP8Oopwliv8hHQWC70NZYt8pmYhp 0LbHwl+xcMuxbwhsqP2lvACxFWGNLrkjG6sx6/BSO3rV0akZD5uU2mqjK92d7HMZuzqgksTKM7oy 3EnpLqNmoroWoZIRfSw5i1EzsutxqbVvS9V1UKOXOrq/eD3iF8+qd5cmTk68J1Fh0RCyaAhZNIQs GkIWDSF7AGeiqWfPbkTCZJ+iugs3Dx+EWT9yhtfLccfEpycmHT3aIyOMjkqfi10/nN0ZtDeNXD5S Y+3fP7GgwNTP7U7u/JVHtpjhtMwBFotJzLFJzLFJzLFJzLFJzLFJeMB69gSThDuZg2vM7kRrgXtA P723T403JKewNA6v9yL49rqcPbzoDyvHkBEFRUXirX+Ux34u3vR453P/MSeJ+tLnReL1r0ZEn2t0 eZMS051GTXeRYo5PdcWnucya7tEc85nk9jkNeZ4Fvv6Z7hi+TsdPNyd7A0lLbB6n5Ujg5h+62GAy KFq8MHGt2nHYfkvfTEtyH88P05Rb0vommWOcqfHR/bJF52Aj2Gkd2TabKxpMlW1Rtqp8QATTFQ2m Sw1mmqlfv0IRzEK3TXygYqHdIhSqFIoqdpZWMsXUz5atTRKnrXipqOETwftR7AqKoq8VilQgkO1P SIj/iXilKYlFgcCRdaTdYo1PthYnZ/v98d0LfKNSNBqN0el1u71xxrzkKanZ3lQHH5o6uHCAm+Nl 4/QmJfjijKNduEeaUwuzNfuGbB425tJxP3x9+Hi+o0+GKTHH2/XMwJamxoLJOydrHsEtC+8ri0H8 vxiIt9DTWI8pLIetb8/UR6Omjy5BfXQJ6qNLUB+Nml6EJNGRKkKWKtZfqt1i5RNSfShLFX+6xxxZ OKE79HqLv5ObO+JrLEe9oChg9mPfUf7jX0zao64XytPBdXetvyjGmZ4kNlffZB7fd+LCJRNydg2b 1ph37ZWT5ldlKhc1X7V0eHe/w+sErhsSS2dumDZ50cDYrn/0Gd0S9VhrhseDWQW7IJhm7+coNmLU xcKLYtWLYuFVsZj54k5N0e6cILI5pQ4RCihHNDSOaGgc0dA4oqFxiD/pS+lnx53kvuVBHgwmjkAE dqXXJEY3nXoT2T9E3q8K5d7DtSS6atQrdT/lRyFJSExTxEvcgGXjTEjgAwPZgYC8gJn1rsy05HSX WbsuPn9k3bBVMli4kDkHjEoev2pStr9s5hDfwPw+rtWxxu6uiuqk0qILbqtoKfNi0xmxJrDkBwyc Vurv+sPhIOL1rlOsJVOXlY+aP3moKzZ3+KQB3R9mpiqnTViYaNB3T0gfVo3dN7pnv9KiS2dj2Sf3 s1H4qmLDl49R0RCNioZuVHTvjYqGalSnJi+YWxh0uviEwqAD31AKMwstHrdo6xEHmsduFx9o4hHT 4XlAM0Ccah0e9aze05EUZRfxfTbxIrP0e5Bns2JcCQJBs8NXzIuDZguf4BD/nmwSqthR7EgYjvvT rlEeXU5tQifPadeplwZMwX6HuB3m5jba99vFUj3yZoujAvkWiF4gtPKbJH3l7Kf/ma8LeqWlfN31 jaOWTRuWaMZFwhhbVL1iXEljeWbhlIVLF0wpGrbwgrrcaROHO/VajaI3G8wFFY1DB1cPTC6sXbR0 UW0RXzzj3JbCBF+GO8uL756GjD7+tOLqouJJwwYUjaxbMblm69R8W5LXaXa4nXH4FpHiT03tX5Y1 eNLwwqIRtSswRyPw7tmHN+JwNr8jMJwXdvZ8HywXAckq5AVGIfoUcHyFFJYsnuEWIieDu31C5A/g +f15fibP9/8Xe18eHsVx7dvV3bNvPTOaXZrp0Yxm0Ugz2oUk0AxoQ0ICARabkcRIGgkZbUgjNhuv 2AnX5AvXz8l95uZ7cV4SO8m714kXjLCzwPcRc+08/HASYye2E2dxbJPgxEmud6bfqeqekQCR5X55 fz2p0K9ruqurTp06deqcUyUG1W4o3uAr0zALjQHQhHFYKOAHu4hSKsqtFUw2Bz5izYK1YkEOvEmF 7C6Wyw+7PZF8PZt5l/6I0TvDvLck38BkviFHxgDv8ZsVNPIhlMeo8orc+d48FYPCNCpg5GZfgdvH IVlAb8T6zahnXvgkls2z/8sGriaj1Gs+PsPWawwg7eBWfvwM26CGvEzvtGHdsB2kOM48R1VSCepb Cd6wyrMqtorRqGxVWpDBKiySVVgQqzgsolVz6P0EGPBBA4W0FNYfVL0k4fXSalMvSTq+kilRP0cr E3lG2/epKq6KbjhVhSiwZquiK4vnkCthOF+ICgvZgovRjhWvartYKpb1XIgx27u7rzfrl52J9PXW SV5MBSiOPlijsTcOq0m1fN5vrayuEkVQusOSZUYhCqUVG71MnMt3OT36hn9e3zazvrQx/bXRW6zl a+tWJNvLtUpYKhSuVZuGq5KfviHwlc80D63ybO1eObnCrtWCbtdui7cWtQ6v7JzqKGqt6q52FfgK lJzD4Chw+grMJT233nDGVhoPt25c1QzcfQC4+6JsN1WM1+jjYFKpvTWS8qyRNEWNxC/8mfCrZg59 kHBZIti7jfDYt8f8j2ANHeGIy0+rEyrKoq6p9rKysjkkezLQ4WrlOusg+6isC89qrHJtdbl1ep5n vVknIGi51jwVhVMhsU9htFrJQvRi5eDR3kh7a2sQfDsLLLxyhZm3O2AVDq1ZvTo0cO/m0COWqk0J vjHREmy+palxS60DvTn79KFWY6A+PAF6lWVBr8qWEY0LcPmN8DIft/aub8223Dm0wlS8qiLzwMbN ywdvhhm7DTjGM89S1dThR/OJphOt19clq/WtJ7B5t4jT/M6VzrJwUXSiaU1CF9MjveNNT0KtW+0B 255+wtzB/LYc6n5CpVtdXjKH5I+qunBEJHKJQM6BOpNzl68Ki8hFNSdfGBRheFqmcCxfsyWW/Hyq euXuB7ZG1jdX21Vy2qQzBJf31O+9zZvoXV63KR7RYiPvfxodRp2jqMCUuPnx2bu/d6CBcxba9Wa7 KejxhrwnHtl815aIP+JTmgvwPN0BfPmCbJwKUHXUvQlPvAFpXHV4dtZhC7gOrxp1WDrqsLDUPY0+ pCgqJnItJjErJjErJs3YmMSsGBYotdnbqqkLulh9MT5MaO+Aqc4+ru+SdWIjhohT/Kr4CJGnnJm8 cArCsp2TKiYQWBg+qmW+oDDm5+EwYNsDNw4e2RyqGPjn/nV3JRR5HixTqoeaDjbHQYJAolZ6VyRa g46sAO3t2tR116MD6acPtbU00ZqsvXe5BWRn4JZE850pkKWmcsytXuDWA6DVIlQV9UiiOFYTr5ms Ycx4Npl5HGwwe0vwGluCuVWC2VhC9BvIwofHmyNfidA4wHYcz7YqVhI+VpIx8llDrqKCYzH/vN6S s7ezR1n6FIvOs4hl82OvBjrsF3fop/S0XnUxnwhY78KojDgpX4uIwga3pZCT3OddIFaWK4WPtgRr CEMVzANBx+XH3K1T6xND7TGtQiNnaEahqdm0OzH58HT98t0PDt70uR2lDzH7967Y3lgIZnXQu2bf pqjFaVHoHSad2aDVOOzmxgNzB9In72hpnvnXLeY77492pmqx11YkfETfI9sHK+fQY1YOT0Ay8VyS 1nJltZVLUmcuSZhc+M8myoqL5oTzCRP2sovUl2ranIFLZav5Tm41sQYrcKgtcqbyXXGOVZ65KjZh EfstX2gN+qQ4RWU2NkHfw8qUcoXFHXYVVfH6Z5UalcxkeFYJqglcLeVtHIdVzW2+1eMdvlV+rZKR Gcw2vUylUdkr19cPKIxOs5//5LdKDdZJGiVj4f1mp1HR2/epTWGdQWt24f93qzrz35jDzH9QjdRa qp86n7CYStvwLGtTQpfbeM6MOtsq42BVYBbEpfkF19efxI/iinWQTegMJtS5zsUayphKhQJLD0f4 dSqhg0xppcLlUlSWspjHiSrM5C24iS08B69tKS5KaOBaZChTMMs6fqrd+JbFsmMZ8/by1cX8qp8s 67jxJ/w6KdgXF8M/F0TVH6k8h5lrAwsO23BGuMmdi8C/SBYw14HH4KYRLgeCctBnVptkcWdlrhaW 16oaguLMBqMcVQVyy2kjbQajPKhnpE/MYbPhDl9+Re/ta2sHXSbbyprfNk1tiFbtemj3+AMDJZy3 nC+PVRR5/FXb7+gMt3kQZzRmMqnesraYLXVj+eqYbWP/+rf5sF11aM+aVKOLSfs8/s2xtfs2lhRY TVG3L0qrae+KrQ2NUz3lRYmtVd7GZZUOR2fJih2Bot5VXQduKFUpvZl3t4/wy9pDW4c9tasv99XH aaWjNByyrGwqKGvE8v0AeIEPwspcQe1/Il6FiufDjZJgL4hDSnFJWJZtbjGoRMJLJLJE1IYGP1OL 8STwz8ERkp8o7fC3OjqJ+iQOEIpJ4RRxMa67MqhCVhPFIiEj0XS0MA8qTeKaa4+2lzXe0gwfSUgh uxS3HW3fdnOn15GVZ9rQ1dfs39Jz+d7snYXr75r2FcOHk1hT3i18hNbLYpSF8lJHTsR963yTPsYq 2XJWiQfks5lcifBaJUm3SkyzPk3vBn/aInLKIr1lkZ5asiy1AJueVHsS8Cb+A4InHFw74c+FSxFJ G0ory+IRJzNedrEwghSixqsZYC5pqI/g3xwLmEMKscMKVFZfHK6D3+zI3wIjX0V9LqGN16BwOSpP mFAXGATnCZnlksIvx0aEllyJwi9/mg5ShZRW6s31o5EgDE5raSmFOyoKhbVQIwu157caswIBnhWK gXkB9izRghWvZ/ud63gQLSIOkgMBylGBkNXK3KI0FzpdPrtBnjl0NUfQDUqTo9DuKLSodIbMU2hC pyFOL6PQqdAfM7prBeOTH6I9ap2KgWVEpbVzmacyRUaLxDPUCDyzUAkSWZwkkcXFI4nZ0abwf7Cg 5lpJj6XxXTySeM1YOq4lTaJCdh5W9W7qYsJlwmF1svsTIP5bkDhvUxtQ67U7CKIvvmCn4WJuRrvd Vsi63RViJJHEFEk4kUxsNaxmJ7qxn97deO2GjFjtNRs3T6MPQK1wSP7Ymg4wN+UJ3cqOxtbSZe2l nY4F479wx6lOiogY67IxV6wfyNHpv6Qkrqc1LJLDKQmL7LyoPMzKvJLmaN1MC14kbV6zwlrSFK1L 53SJ3JRvsxZwis7Pti/b2lzGla5f0+bfvKfdM69VfHVXaZVr7zCHYClmGJVGubdnnTO2MlTeXGwG ddOZ1bowghXU/QmDOIIYJAV89ShdZz8Iu0duDcdl9TAJ+C+I9aMPTkiqGCvihLq0o9jhb8+yHq+T OV2cjchJ3P4bFLLlrynkHBP/peuvKOQrGAUM2oH1MfZ/fgYcMlNB6muJ/HgYhUwobEQBHQpoUUCJ AgpUTPx/t2TWuyWGuSW15ZbsVLfEMDc2T90xNVLnYR8yD7MrD1vCedjDzMM8y3uKVuMo0wkD1TUF w+TAfzNk6PCBryQ5lNgnkliWdY7E0Af5QQvshYUuZNboZ35WP/Pv05Nfnaipm/m3GbjWPuJqvGld +2iz1xW/ad3qm5p59MbEyXvWrLr1iWm4dsD1lvY7B+qq+u/s6rgzWVfVdyf2pjP3My8Cb7A3fTv2 pr01aklK1JKUqLPaRy31Xk2WbYvoSBOXmsTaRJ96UU+6nVt3XU96MUd6ERm5viN9X1+oeWXCv0BY 8iwukyLc2bW+dOCfsCNdSRzp1mDzgabGrbVO9Paeb9/VxhVW+TKNWV3Ivg0ywzAgPfuLG8OWzkPf nG25Y2i5OdxUnjm2ccvyoVskbUk/TCI7g09MVaOAQWLR/MaixCqDxEMDZpVJ2iADlUdhnlFO4GBR QhXpCBgsfLsFzyGivMjyFcnZMgsN+MWmDWGJnH6YlquUSluB3+Ioq673XT1pilbW1xXovP4CLcsg ZsDqNqpUKmVetLP28reunTZ31TQHDYxSrVbpyf7yeuES/Tz0uJ16PqGNrYmvWbfmtjXfXCNbEJR9 TwrGkhmzEocXzFcFa0mQFr2a8IiRWRKTxcpFCsxiFwfPINdT6D2y3aTGi7w2QRZ++BiA+uLab2pp bfS1WvVvjd3GHcYpIyMGYF/B0dcO61uiaOVCr1LgtRfvKi4IvM7bQn9v4JV+vrLvzrVlm1vKrGoW B1Yj8U3LipsrXMFEd8/6RDC84eYN/tX1YYuCgbVeLVcV1rTHihNhSyixoWdjIoj0LWMw3jZHnt9j dnIKF+8y+WqKAlUhT2GkcdPy6mR7idZk4bQGK2d0cAqrw2r2leUHq0N8YfHyG/BYeIXf0+Psv1P1 1PYnwpTRVyrxvFQai1JpLEolLVYqSWUpFkKtTVd6ybe6QHfJtrp8DrGPKkQldA6LXaUUfTh3RgzN sIs7iFe6kdasO02PKzk+HLW1DiUKbjWY8IGGg1mz400c+zMZ3qxts/nz85QylYy9saCQ06vkRWtm 1tJ60UO8kN1MuiD6kBl1b79KrZLp7bjf9+M4DfNtWOHuS3hgXdMEsQQFsQQF8aZLkNgVQY4YEOjD J8WZ5pG44pG4AtcPyNzEGcwWT3ayeiQZBQP6w4TKXNoe1Mgc7WBmyOaDNXh+Zi2LnEgtGqyZNyyz 5wFyYZsvKEwFFluBUd71ebKQKfJEx9oWW13WeHOLIs8DM9ekyq1ve3vWLh85PEAXZmfn5T+v628q 2tJDz2bvYP4UggVwM/CnhPrVScongG7GZpuHxOKLPMgtZtzIKvXTIl3z5o05cjXl9p6EPyRq8cYV rJFGFORQSIYKQ3BjRSHyFyIvzsa9yO9FPLnLIz+Pgga0x4u8OEihMlpWe3mYtfDprYQKRNGLI0T4 Ex4JL65fCy96Q+1ejbNdIypAcgYggs+E9ZJ1MCL+Q3g1FPmOdwMi5JRebvt4foG0mW21Zul43s2I ZujMOVbnDLndIYeezTzPyvBGp63AZ1axGZb5mFabvS6b26hgvsiq1FrFJ1/Hp8RYpV7NbNaaVAy4 ODSA6rJTq6V/o9IqGVqpwdyuBov5EHC7hfrZSaoN1NMK6NoyHLwIL0O1+FoURQEvCvAo4EEBNwoU oGA+CrEozKD6BtRQjxpK0XL8/01bUBcnuX/4mlCDuHI81MAZpNv4mtDihQTfNqxsJ+UwM+PcOm6S u41juYTJupqrbC9qrz9agkrwsxKsNTmzdfVIyd4SugXu2jpVmMkvYk72nonHzwEnRX7HRH1IEZsj Z32IjJbn+MwEFQv2XhZh+YKs7BAry7zP6Gwht6fYoWW+Q9PfZHTOsNsThE+ZD2Us2Mq2/EKTkvkJ TZ+lVSYQe49JSb9Eowu0yux12gvwsCjyDPODQn9Gpbo8Mz9EhjyFSgMjBH7XZadKBSOkA8WLD3DY s59opRqPVxhmxxoYrxh1z0mqHBhjxPFZrDeiWGM0RJEd5PFJvB9jRzZJN1izt6xIhaW1GHth+J3l FFrmQzUapOGxsYxHRaMpLwu3+zTGgnZjziCuixtNSAw/UpixWHhF+Y0UWfOyBx7nzzvO72iZzdlt LMQ0Kc1Bj9tn0bAvv8RqLIX5BUVGpEL2zPtKZA7yBb48NXvuPKs2elwFRSZalfmwRG/WysDXVKBU 5l/hwsi0Zj06gR7Wm3UsI1crMo+idXJ8HkKTZ8j0Ye0BFuAtwB8/teEk5YK+VuOZ70JhF7ITV9CO AvoaPR1UISdekuudyLEMM86BPO0OtbldvYZdR62RXDC8excRJy2evF5G7GqtORAAyanK7dqZSeDL mqegK/fJyyucvJGW36LimMz3lJzf7S7MU8kQYj6QGwv5fL9RnjnOGWXaPD2qY01qZrvFrpcxSoPu cpS+YNbIYJ0wUTRSC++hV2V94FGHKf1xWZGri2sFsl57fj4WWs0EcpGPq47wfkeBj9DmmxRGpLT4 8l0+i1KvcoQ8njBIlD3s8YQcKjSbtReZp7QmrUyuNWo/rvNGXBqNK+L1ljo0GkcpiQC9x2wGSqqo 1VQgoff7Paq8x2WyMlVzPV5l0KNlrXjxfQ2fQSYRRpHC3OFjQqVkkVyz73a1Z8Bsrth2a5fCF7S4 TUo5UpnyTdaV2+ucfCK5qn5zIqxWwHIiz6tbn6zadWyoLHMGeuPmoTfQO94NvWN+vuXTO2pk7xoM eAIhWKHMinDz9oq6/paAw22XGwusdofZ4zSt2Hnkk4are4uo4szP0Az1OuWi1I9pbPkU9+Nz4hEE hULUGbXmHJdn5Hqb8bBMZ3aYjTY1Yu/W2P1Oh9+m+aynKlrqeF6hVpJpjMy3u3hOLud47MF9mtnL RGX7oIVaSveEvNBa0UbFK8/hQx9XxFWl49mKRe4SWXtIY/PZ7YVWjVxn4z4l05ocJs6qRrKMbZEH MOvYtludvEkuN/FOdyWQd06pVuDzxcrMpes8wNRGmL30CzlqNUFbZY7aHFMCgap5rsgW5RX9Aibm 06zOZMfEMIfUNp/D5rNqMscWPADyWfIEUy8LeoAa+zmlBqiBxQsZb4OZJZcbeef1HsD4ocybjFr2 XZg3ykc5GRUDabRJxEixMcXXWF1egcXhNbFyupfVmd0WMO5Y2bs6g5JV6Mw6+c06gwr6n6eD+u7O PIz+JLuX8lGFCQuDlSyDzXuGHIthLB7N3VQ8BkaneABCDvakyZY7BB5lyJiJ7aLf9/f23yhD+gKH yWnWMjUbluV76jZUIhWXb7Xlc7Rs4NnM1gsvZbb9QGvUyGi5Ujb8wsuv7d796k9+OMLK5aDwOLwG HACK3gSKvFTlScokWj8myXrG1+OYMhM5/KEh/plIYaQid0ZDkdXUNabqKjooaRGb1YTezF+2vobR mp0mZ4EOybb39fWxNJdvs+QblfTILO3Y/drLLwzLlHJapjFqn0MPv3QBPfysilMDdXL2XGYdSMy9 zDB9TDab1VyuQBsHIhPPioyoE7KBgKvuWC30XXLOZjLZDXKbOs9rs3vzVCjzqSvulQWYe7KqC/2f bC5TfuU9jsPfFCO8I/PIOqgbqJ3kL3diCXX7TJV7n2ObwjAxh5jja7vCYQO48/LjzV1DvzO0Zs9F E6++vMyMh08cRWmvjZw0amSq570I8R4Yx2SjRLQryIVFeSTGltV7THaLM8pAATTmToy0h+qKuOLe +3ZuuaMnErjhrt7C7s03loAlrVVwHofVkwcWRLm7tCnmUatNGuC6lnfmlSV66op7R2ea4rt3dFaD QWbwlHraB5e7LNHW8ur2mDXtax5uCq9tS7iqRnZsLapoCpsyv0A9tYO9m0tqtnS2+Bp3b64MtA6u aBjYfmNFeOu2zSFXS1d32K/WqVhaYdA5lo2N9IX8ZW4trbQ7HG6DWqn3LY8W1odt1nDjugGGdi1b 0RoJtyQS/oLqsN1VuvxyqGpT3GcsCNtKkwPJKB+PJ5i7QRp2gb/zHRlPVo8HTlIdYLPYDHTXjg4U mY2j4ThqiqOqOPLHUXyObkrkafPztQeq0U3VaE01qq9GkWpUDQ+enKIQnt7YlBSPqb51AqqhyrQI 3OqPwMumu7T1QlmZLDCHqMfMW5vnkOVRWX92PPGGYu+PwWrp/QWxCU34oAjJ4VO5kQUONHu1w6y4 KlqTjVl9p2rsod3rb9m+oogzRdftfWiiqDNRolewNFJoVJpATVdl7z09Yca5smtT+ejRrYFHbDXb VhV1tMSd3nhfPNHXWIC+3PPF/e2hjrF/+krfxm/8j3tHlqsMJo3OYNabnJxSb9R33v717Qa33VCX Oryjvn+VX2fzmO54ZLS0bH0Ka4JHKIr5osxGRak3En6/G/kLkD8f+VzI70R+B8LGjg2FSXjQhC28 MrKniLlfhih8LpEKS951WNIfYcnPDEt+ZlgyIcP4cKPebccv2TUYNUZpKOD648ehTqN0FmPB/VPS IcA/JFTwxoNGZDSb5lD8cd+GMDeHFOKfIVTEL58jsQ38cw5v95INj8j3cWAD/Kd5O75X+rMEyVrw GhVyuWi/1xZJkWwjsSG+KFfrFJe3K7QauVylUyL9R3hnl5FrVKiY1cJCA46p/CJYRLJmHL1QcE6z yWlUMS9/Ts3q3DajndPKv8ewLGIVGvnHn1UZnZjb08DtL8i8VCN1f0IXrkERNwoXYJ8oMZcV6gSy 4hCqlSwOVp7Y3nTpk5VFkKg6idd1T9G3URqRORrsAWlwfNq4rI7n61xzKPpkpVUe3ciBUgplOSRG gmJkUwjH1M7l/lyD8Ij4OlcwB7svV5lb8pwCU5A/cfiCTGVQXa7WWwwKRm3Qfrx5tM6UX91dRQ45 gbHN0jKlvWHrroa+z/RGrW33TJ6jK5UGjawDn6RTcG5rnttm0yH19vv2DUQiXfWFhaFCpcltMVg5 vcXvs1dvP9DSePNnvzl9QWUi0bcR0AT3Af+2INlJahuwLB+zbBsqVwJTyvGiWk74Vo75Vj5HVyfU azcG1q61g++dwL53AIoEsEuYgLuBBKN3KblstI286eLJAQNRZF3A+ePEzSGngrCy0EuiqZekXY8H zgzDoG/AW3EN2DntjDUgIrqSCCfU+GaDscForZlDGlg/Npb8iedl7fiQpCZ3SDJ2qY7LnZMEdzNG IivZaB3ZZMfbN6Y6LrvPldU5crJhmYvZiQekxUjVtTbz/CBa3AxzX2P6G7tW7t5Sb1DKGb1OVb1x snnVUHNhZOP+rpthrBRyjV61e9Voe9BZtb66PtlZocZeFFgW5vqeycS2T99Yyjdua2ia7C5F01s/ O1xrKfDo9WAb+fP5Ir6wsaeidkuiEKaHxewwKAoTW2tD7TUeX8gnM7isBptRb4Zxjt4w27ZidH2d hlZUd+8CjV8GPuqPZHlUMeiljxP1OIBQioIlyB9E/gAqykcBF/IRBVVkR0U2FLCigAUF8lCAQzDE fhnysyjiQkRbmURtVWq1Q8bKc9Ies7i3/PoJvPecH41yc8IniQIoweHpx2GJ4HBYjcNhNQ4bbRz+ m64gxYq6ip0TzmeP6iTU+KwOWxYLuqJkgNmIl+PU3g3qHhLJgVlXeamiQvKAI1J0ER9tPxcRj39l Z+BVP+jKAyq5qYnmdZUV+ZCX+VGe6b7sXwBcvqjldGD7qRXohzKzu8QNyz93n9GS+RKduRE9jKa8 gcwfsiE1xMk5t93sdth0jAn7cTKlTvXJMz767cv1lCBk115azjwn/UX6l8SEYn8h/dt8oh1S+twi KcN8NZvYFpKO/q1JtkL28l9P8vUkfSImxfN/e1L2L6XrJZX+uulhdeUi6TkxaXYtkt75xybtK9cm XT9JL/+lpJ8m6fh8MnyeC16Rji+ejJ0kfV9MpnuvTWbFfyn9y2Ipb60lkEtPWl1LaSn9f592kPTS lcmmvCb1205cN/38ryd7yL7v70zfddz2/z45S/8h6deuQ/n7ClZAallKS2kpLaWltJSW0lJaSktp KS2lpbSUltJSWkpLaSktpaW0lP7+RPaREUUpHsT/UbGcopToPoqlTMK7gEGCaeFbFIuOCf8b8JTw U8CzwksUy3QJ3wbsoQyAfcIawH7hMcoEb71DmZge4X3APkoL2E9tpewUK/wSMC38kbLD02cB+4Tf A/ZTDJUPTy8CmoS3AIME+4TfUfmIFn4GyAm/BnRCDfnILbwCGBJOAR4k+WO4PNB2HvA0KX8W8gGo 8zOAJqAnQKgKQJ2/ogJQ57OAuM4A1Pk7QDfUHIDa8J2jwmtUACisAsS0BZgx4XtUECh/nwpCK78C PA3UBtEz0JcgtPVLqoT0ZTO0OEpthvp/DMgJLwI6gZ7NUP9LgCHgxmZoBeePCq8DHiN3zmKEFmnA PkoH2E+VAY4J91PbCP3bgP5LgH3CG4BpfAfqfBXwoHAB8JTwG8DTws8BzwL2ASXvAqYxwtO3AU8D hX3w9E2qj8G87YPx+iOVhpJfBjRBj9LQCsY+4T0qDb04CcjBmKahF3OAbuE4YLfwHOCscAZwD8GD wjcAD5P8EYJHhROAx0n+FHAgDe3+gEpDH0OA/ZQe0TCCfwY8JlwChDKAp4U/Aj5D7pwVfopooPMV ZICSvwc8KrwHeEx4H/AUyZ8m+IzwEuBZnIfyFxEHlP8e8CCgG959B/CY8J+A+C03ecsNb/0C8Kzw J+SGt95BIXjrZUBO+BGgU/gBoFs4BxgSfgfYLZwBPCi8CHhUeAPwFKUDPE3JAc9SahSC3t0J2Ec5 APupccDbKDfqhpp/CshBf7uh5kuAbqCtG3VTZsCD0OtuoPAXqBtmkw0QZACwn9oIOEa1o22EV9sI r7YRXm0jvNpGeLWN8Gob4VUvvGVFY9Dia4CccB7QKfwHoFv4LuBB4WnAo/DWGNT2HuBx4TdoltQ/ S+qfJfXPkvpnSf2zpP5ZUv8eUnIPKbmHlNxDSu4hJfeQkntIyYPw9H3A08IHgM8Abw/C0/9EB4FL r6DDZEwPkzE9TMb0MBmdw2R0DpMxPUzG9DAZ0yPQowuAnPBLQKfwa0A3jMIRGBecPyj8HBBmLuAp 4OoRGBcNIB6XI9BiN2Af6IUjwJ8b0VFo/RLgMeFtwFPA+aOk3aPQ7kXAs0DhUWj3DXQM2n0TkCPo hPLHoN2LgAdBKo5BDb9Cx6BmDWA/1YZOQflfAuLyp7BuAXQTDEGZU4TaU/DuJcCj0OtToAHUgKco LeBpgmcxAs1JwD4KZB1qXo5OQ81vA3JQ22mo+R1AN8EQSOBpqBnncc2noWacPwaa+jSp+TTUrATE NZ8m3DhNaj5Nan4Gan4FkBN+COgUfgzoFp4DPCg8C3gURvwZqE0OeBxafwbeqkRn4a1fAHIgP2fh rbcA3dDrs0CPGrCb3D9I7mN5O0t6epbQc5bQc5aMzlmgZwIQ03MWam5kugB9MBNYygiYFm5ieoDP LzI9eJUB7BfSDNZvNwAGhVcB05Sa6QN6ngfkhC8BOoUvA7qFrwN2C48AHhSeAjwqvMD0QYuroA02 8wGgSfg2YFB4nOmHGnYBcsIYoFOYBHQT7BZmAHspJeCs8CPAPQQPkpKHSf4IwaPCXYDHSf6U8Abg aYLPQLv9IFcvMv3Qej3MalY4yeB5+gqD5ylGN8Fu4TUGz1OMR4WfMLeCllDDGl1KF1L4/yjCP0ME GbJy68knnKcpPcNKeYYqY0xSnl1QRgbr7SopL19wX0F9xGyT8kqqmDkv5VUUz94g5dX0g7nyGmoT m5byWqqYfU7K6+j/zv5ZyuupMcURbFuQnwrFB1IeUQplsZSnKYXqgJRnKLvqDinPLigjo7SqB6S8 fMF9BXVQ9VUpr6QsqtelvIri1IVSXo26c+U1VERdIeW1lEXdK+V1qFM9LeX1VI3mu0AJYlUSn8W8 yGcxL/JZzIt8FvPsgjIin8W8fMF9kc9iXuSzmBf5LOZFPot5kc9iXuSzmBf5LOZFPn+d4qkKsBrK qGWQ6yLfnjJNTVIz8DsMM4Snmsi3zojfPZOEO6OQm6Ci8GQlNQaJpzbAvRFqJzybIZ9ScE1B6T2A Q1CyCd4bgzIDcG8USoySckn4HYe6hkjZCfg0A/cmyDPx/VGggIffJJQbhRr2w6e9kEtDWzz5rpsB yI9BWZ7QPAtvD5Hv0hkhtUxKtaahxLjUJi7BQx8nSZsp8p05uC/tpK/DcCdJvstlmvSCJ9ck6SVu V+zHIDwpITWPkztjpMYk8Ei8n21lHOoZIxybkqicgDvjpFWxTtzP9AIKcItTpC/Z7/oRuS3Sjlua BA7w5FtuRggXRsn32uDvC0qTT7jH6dx4iDwTW+EJ7RNSvyYJbwdIyXmKF/YIc20feU/s9S74HCXy sHA0g6S2cVLDfsKHWWnkF/Ibj5jY/xShH/dfHJdpIg34KraIx5qHOqZyvRFpHJHKzMCnA1LtaeiF OEJ7cqOUJDKShLvjV/QrK82DQEmStD8otR8lEjtCxgo/uXYO1F/T6/rcrKmmNklSNCrJWzXUWANP F5f6lCS/Ym+SEv0j5KlIT0riGKZxiEgupmoXGbPsO4s/Hf67ZvC8tIhj0wOfRgkNuP2NRNrTV4xj TKJgckEPBqV5lya9TBFZ7oQ7g1SIjHEYygyR+tsIVeK7aUhTwMUYpL0kRckcv5LyKKl9HMqkQbYw /SOkB1NQw364i0dwmPQFz5wra83eHybfuDVN5Ddb31ZCsyi1+4m0zRAK02RezRA9IL7Nkz7gOZki EjVK2hA5NEDezXKvBfjXCRpRfHd6wRNxPg8RnszP0b3SN1XtvE674mdcdhCkaJbwcCgn80Pk+RSR 2P0L5HyK9HRCknSxrhRBPHOv7jd+LmqIELwVJtI5Dv1K5ebstVRNXFPz386j+dqzWpqX9KwoPYNX 6Ltr+z4vr1fS1bCAA7gnYl9ErZ+V+uncCjJEdOgE0aXJ6/ZU5HPyCp6mJOm/eg5grmLJmyVvDhF9 hHuTytWDS44RnfaXRugfNS/m50SMUIPngLgSRclYTVH7vs5XlJUt47tGB6cnZyaH03zT5PTU5HQy PTo5EeVXjo3xG0ZHdqZn+A2pmdT0ntRQtCk5NjowPcqPzvBJfnxyKDU9wc8kJ2Z4eD46zA8nx0fH 9vN7R9M7+ZnZgfRYip+enJ0YGp0YmeEnoWg6NQ5vTgzxg5PTE6npmSjfnuaHU8n07HRqhp9OJcf4 0TS0MThTws+MJ4GCweQU5PEr47Nj6dEpqHJidjw1DSVnUmlSwQw/NT0JdGOyofaxscm9/E4gnB8d n0oOpvnRCT6N+wGUwSv82OgEtDU5zA+MjpCKxYbSqX1peHl0VyrKS90MzvDjyYn9/OAsdF6kO70T 2k/t5aeT0JfpUeg2vJgc52encDNQ4wjcmRk9AMXTk9ChPbhLSX5vcnpcbAuzeXBnchoIS01HN6RG ZseS07kRqM82XY+HpnoTsAg6xVdHayoWsD4F/IVmklD/yCimIwWETSeHUuPJ6V38JH6y4OPw4gNM 2AK96ZkYTcP7G9PJtNjHGFQwSRoYhLFLT4+mZqKds4Oh5EyYH0rxbdOT8DSdnqqPxfbu3Rsdz1Ye HZwcj6X3T02OTCendu6PDaaHJyfSM1JRnB9OQgd24XJbJ2eBtfv52ZkUEAFdwo/5JIxkanp8NI0J GthPyGvp6VwJT6fJBxjnoVlxRPfuHB3cueBduI5ODI7NDv1f4s4FPorq7vtndjazs7eQBIQEUBJA DBchKoUUIkaNCgFDRFGKFVcu0RXEcDUglzUCBsyj8VLESzVSRKoWqfFeaheSRpCIiCGmhCpEg5VG SSkb8tiUeb/n7CbZIO1D38/zft49fGfncs6Z/+9//ucygQzSF/cmz/QvyJ/DDaTP8+f7yTCDXLPm Lhya3Hbve+cSEKn+gcmz7pkuC3VUNbct81ktUtllSOP+BbhnRjju2u+u/Bqpa7QyINXPXQh96fr5 soPMvPe+uXPuvSP6pth8R9hSHN/eAvcuWpi/aCFuX+yfMUvmuWvWnPwzBJ1LW6iWGDZzVt4ddKKh dyzIL2h/HhRWolgjzvbRyMEThegqHJYluvDsEn6KEjylC/GX8M9+/83Hrp/weDTy2OLONb/Xq/K3 nGv+Ll1kfv3wueaPi5P57bvONX98vMwfs+1c83ftSn6+hXyqtKv88ql6uNomCK9IFD3lz6jFAM5d xEphiMhhfL5VZDFqX8P4fIsoFFPFo2KaeI6R+teaTXygdRG7tThRo/UUR7QLxPd4/7+1XM3Qpmpd tdu0ZG2OdrF2rzZKW6Rdpy3WJmnLObtWu0sr5kyJFtCe0R7W3tKe0oLaRm2H9hutUvtA+1DbrWdr Nfr12lf6ZK1Jn6a16LfbhD7HZuorbIn6SttF+lO2EfoG2xj9O9t4/XvbFP24bZbeZJuvn7CtpI2K O+u0lfwHOpejcx06n0LnJnT+Fp2V6PwUnV+i8xg6W7RUTUdnPDovQNEQdP4UndehajI6feicjc7F 6HwQnY+g82l0bkbnb9G5HZ0fo7MWnQ3o/Ls+2abp02xOdMajMwmdA9H5U3SOQ+cN6LwdnXPQuQSd a9D5BLpKO+uMSYvS2QOdF6LzMnReic6J6LwNnbPRuQSdJeh8Hp2vofN9dO5C55fo/Cs6f9B60oYX aOehMwWdaei8Ap056Pw5Omejcynq/gudT6PzJXS+KX/iiM4qdB5k7yg6T2iVthjtQzRl25L1623D 0DkGndehMxedP0PnbHQuR+ej6NyAzpfR+RY6y9H5KTq/ROd3nXWa50fpTEJnKjpHovNadE5Gp3wS WIDOQnQ+i85X0PkeOneh83N0NqGzVYvTPOhMlD9LJw1HZxY6b0TnDHTOQ+cD6HwMnZvQuQ2d29G5 B52fo/MrdP4Nnf/Udtic6OyNzlR0jkTndei8BZ0+dPrROR+dq9D5FDpfQWeZLt/w973tz+hsROc/ 9BO6i7EiqbNO94gonb3QORido9E5Hp23yv93D52PofNFdG5H5+fo/Aadp8RCzaHZtL5aF20YOjPR eT06p6FzNjqXobMYnb9E52vo/D0696LzK3Q2ofOfWrHNq5XYemrP2C7S3rKN0IK2q9GZi85Z6JyP zkJ0PoHOTej8DTrfRucf0LkfnUfR+YO+Qdd1+b8gfK+n6cf1TL1Jz0WnD535nXXGbo7SeT46R6Hz FnTehc4l6FyPzjJ0VqDzCFdOi6m04DRtCDovRydHjClxxGRPrUj+rQg6t6Dzfa7sQaf8O4Pj2r02 TVtk66ottg3SltvStbW2a9F5CzpnoXMBOh9E52Po3ILOP6DzY3QeQ2erPlmP1afpifrtel99jj5E X6Ffpa/Ub9Gf4miDvhidv0DnZnS+g85d6GxAZ7Ocl0wHf+LiUlOzlhUWmjGaaeQXBfgU5ZuGZppN Rav4FDWZdq40BQL8CXQ6CKhs6VmBwHOrstLVAQVaZSlT00x7IPIxTc10lZe/xOfpp1W2iopNm558 srhY3bSpqKhIVicPHOqgpKhI3cdXEshMjivxmW5hulclr0rOzszOvIGUHEgOGDGa4WgyC4qKClRJ bCqShQ27ZsTky/vmq/OmzEImlT+/qCUQKDDtwrSnZTZlyg+ZDKOgpMQXyEdruKZtu2SRsAgRESEN CgRKSoOlpSWd5BmmZrje3r2Wj7pHuHDkdnykGYYjbBy5dc2wHw4XxFIjPxBMizvssAuHPWxQmiop c2+4y4gRRkxRUW5ucrLhFIazKFAUmMxA0pcUvsaV3CKzIxt6OmwTYasPx8X5MjNFpm4Tmp6ZGdA5 GZNbWqrjhpjc3FJ3jHDGmGZcXLIsHwi4bNQgd+QnM1Mdyh35CQR0ndKlpaWmg4ZMGzs2bVJx8Xws oLlKk+WnRR3kF1Fjcmb7Qb5pSk9wkJaWm1vSEhenDtIzVbPld45FYsQh4yoQiMTV/14sOjXTvSOw I7CR9CRJuvRHMek4t5j0/JuYdMZoTkcgOiiNcFCqC2Z7VMoLvpImecEunETl2cKyrbKzxKXTrjmJ y0hgOjXN2a71P41M2XG2Bc+ITNVXMs8emsa/CU2jIzSNttCMtk6ELfeV/Dg4nZHgdJ4tON026mgL ToJSHbdFZzg8nTI8nQ7N6ZThOf1xFZ+0Y0d8ctARn+GDSHxy0BGfMgoj8el0CqfTFN1EN6XwSvm/ vUvvcxcz4yply1UZ6p4tqwrlZ1WLarSWQDg+O45a2so5ZblHCgsj5WSh03LTuQ2dLs3pCfJ5MfPF zMdVKiY5Tc3p2vHii4+tXbt69YNOAzNaiPVw5e1HRXQbdWM5sCuFTrfm9MqwXRcJ3EsCMnAdMZpD eqGAlnUZmsukmncrqKLiXXkpPDEU5atLdrt9YTGXihc6DM1hFtDNAoFlLrtwxbRHbyY5HY5l0nMB MhR0qhOblMRIBAdcMZpLRneRjOGSIpemuTr0BxxOzeEpE1Wqp4aTum+kqjYbVoXvEjlf8a4sadcc kYBW+7ID+uLiDsuOFtNmaZqqQJVHkHSDjFbC1eESDndWZlbmoIBM8SJehC9zMTe3yBWVlcB0aTZX THtohyXJEEtLThbJyXabsNlleNo5b4wtKSmxxwh2xo4t8RrCbdjtURHu1TVXTHJUiCerM3In/JH1 2KmHakpcpuZypWdlMQyvW7VmiWrsSJwnt0SaXtWd2XEUDgSCxJGYmjp2bFGraaprxHo42F08wBLs HeG+koBXLcXdnGOuDBt25Rh189bCB9SnsFU1cmtbiLcqH7RHvCrrUmUffeCBSFlZzlKlz2h0l1tz eYO+oI+eXPpY8mOE67pkGbaqmIz7cOCrW8pQD0e+y4F94UMivzDSCrLVpWRZaeyq5LZBOyr6wzFk X0YIuA3NLSM1OvwdkfBX1+xnj3+3Xbhl/Ld3AAfXVsioDDCjLetc7Zk9wB2juWUPaOsCbk1zR3nj f6sPSCkFaiBo+n/RB9yazd3WB6Q0pUoG3Fl6gdsR7gVy56y9IFbX3FG9QEa/OtXRDSL9wK36gdup ud3prMSzxFiRJm4Qa8VqnrJWiwL6os1lJrd3ChUyNLZdjf+t7YcFtGtkoEps7xfqMCMz0mwFbpdw uzw8C8iUQsoMrAxwNTOQ6TY1t/OCO8L2Zt5xgTx2tawJd47CNS0qAGTniPSOjuPWcAhIAX2EL5Ap 8J14NFxPwBfoI9SljmCwogLjzEBxezV3l2BiMLE0tTS1ZGzJWDlZrzZXm4WmqiUYKCWVkIoCq0iF pAcCbge2q3kr3I3aj8PdqFDZWrAKe9JM6SR1l0LqvCYunFLl7UrjMuMy1VJKdSVCyePQPM5w0MuJ reLdTgs7ddXGZ9S18uq1oyJLONmduBojPDHpHf0p0y3Xm+0dqnDZGZUXFoaHkLYuFfAYmseM6lOr PJrmifZVwHRrZux7wcrkVVFJLmudbVWqg/QsuZuV7u64orqWWg5GulYgsoyQIw0DjRzlMzNbwoan q1rCFSKSha5JdVmpqSwxoheRbT1MVaVWTHQxd3R2+oZHs3mMdgUiIjO/iOA9Sy/ztPUyj+plsQ7h cdhsbf1Mdq4uuuaR3aytn7GXrM6pvbZ+pjqaxyE7mseleTzhjpYlUulquYSS7GpXi4ygCpy0XNZ0 6nNaHResoo3tsrN1HNPbbDYCSXYaT7du/bOyVllIUNfD3U253OMWHnesiBW9VLokcEnAF1zJvCCn Bo9T87j6iPyATwSjko8zfYQy87QoZ6UfjPrsCJQHTgsVOqflcas6e7rjxOlwPlW8TyA/M1z3h5Hi vmB+sE9AXeyo04q+QdBjo4E6nYjVPHGHex/u3ZSxb0jtnNo5uyZUVVUUf1hc7in3qKoOB5uC+4K1 pCpSJWlnsDy4I+gxEdhaWV5eXhm2UyluFZWiXKVKIffDRzsCSkNGXjB4uKB3rGFUFXi6aJ74HcYO o3zNjOIZxXlVeVUjaodPyShITEtMU0vOZZWGsaKycu9ir6l5XfIOh46Wy8/RQ+GFbZ66bV6Guq7z GX2nun7naLn+5G6VlThseobX0LxGhs/na/FFPh55fWUln2XBFZRYceYtysu9Ns1rDwaFaHeV16F5 nXKnsqq2qam2qqoykifq4/Rozi6HDn+TVtkpqfVwe9XqKCNP7edleKKuHT0k65CrndrDbTXK5XJB hfSbp7hATlpGh5B0VVWkWmTLxwD5+DhDyDSC1JvkjOWPbM8ZiXdumLlh+LaMpkRfoo81lNMsz8vL SMzIyyv3nL1sIilNeG02b1TYiIgzCooNw/Ckp6WlibS0GF2zxWBTMBDDNbNvXlVVVYxDeM28vLyq oniHiHXI/0DVk5iYSIE0mTMYZ6dlwruREPb50tRJtRf5yOsxtKFZJT9et+b1jhFhM/NEhkgPziEo ZV+aEczwqbBML6hNjHwsdWJZJeHB7RPTfB0njAyDs5XLVODGigtEd0QPoM5rCVsrYAiZVO4LsCGo Yj0vQ/0NgEtstE0R+owl8+eIbnfOnzVbjJpzx8K5YgJXtBsnXZWM2+Q72uTP5gzhZaEaPtIEfhDn qfPhMzYWsl24c3ehj8vNHSv6T5p4fbJIu2nS+GQxJpJH/p1NnOihjnTuEN9eO8s69bPc8BGTkugq eopeM/IX5ItNavuK2m5T27fVdrva7pw9a/5csUtt96pttdoeVNvDantUbRvl3zmKE3KrGWrbU22H qu1Vanuz2t59z+x7Zmsr1HaN2j6ituvV9nm13ay2W9v/5uV/2mrnuDXxpI4PDDxMYOOX/3/nbLSD 9z/+lhEo/82S/FctheJxsVG8IXaK/aJenNBswqmUmhG1jUL+e0Gdct3opJr8eak2KvxdtCb8/cuW qDLE2/cbOx1rntbOx7EDOh/HJ3Q+7vpM5+MLT3c+Tj3j+qCenY+HpwmnLfr4ZNR1Q2jXZXQ+nrCO bxcxnSpy5b+xpEwhrkqz5YqVtk22z0Wp/kv9l6LavtD+ojgQ85lRpOmuG113aO+5HmLhucsT57nG drXnVs/ztiXemd67bb/3rvQW2ypibbGmbX/sqdhTtj8JLdAsfWPUeN8+a9pHOuj9Oiodi6R9Z0kn Y/u2p1TSKFIW6W6VNpyZvPtiN8a+Gbc+kkqj0isyyeXWWZIrPrc9rYt/sj01h1NC77OkoaTh3Z6J SpvCSV05I3V7o9uu9rT3vMOkozJ1t58tJQztntA9tce6qPSkSjvPmvb1+KEtJXZL7NmesiIp+6wp V6WbI9+dUyCylfkqVapuT+HSXyQ2JQ1Kmpn0fNIWmc6sPWnr2VK49qR3k+oj6WRHkndJ+kHdKyA5 f0K/Ue1pQr9J7WlmJN1NCvS7W/6nUv0zLxx6YVa/u9kOvXDngF0X1ah0MnUqKX/gANKQgfUDW6B+ 4OlBuwY/L9PA+sHbBx8bfGyIfUjskG5D3idVDx1Dyh06ddhzkfTBJYHLBlz2l+GPjxhOGjMyceTU kQXpb0TS9vTK9OpRg0jpo9aMPnS5oVLJ5TtVah0zYsxrkfT25a0cvzamSR01XWG7wjbmtSuGZD6S uf3KoddMIX1x3V2Xl4Rz890UzjVujMw3bkJ23+y07DHZW8YPUCl3/N0qFYxfM/45tgXjPyIdnrB0 QmDCF9fnk9bn+MiVm7M3Z+/4j9geknuk+pzGnB8mBlTaPLFKpS8mNsIXE5tz7RObud6YOzX3UG79 DQtJj09KJt/mic3hK5OWTmye9PWk7yfn3lw5ZcptCbf1vm3AnfY7p95Ze+cPbd93DSG9MTdubt/8 gvzC/GB+fX5jfvM8+7xL52XNy5uXP2/pvKJ56+e9Nu/teRXz9s/Pn//4/C3zTywQCxIWjF0wfcH2 BTULhy+cvvC5RTcvKlr0waKTi43FQxZfu/i1xUfvy7rvh4LeBdcW+ArmFzxXsLWgdknfJT9f8vaS 2iU/LPUs7b40felVS2cu3by09v5B92fdP+3+Dfe/cv+h+5uXZS5bumz7cmN55vL5y7ctr1zeuqLn irtWbF7RuHLUyoKVWwO5/2KsevvM8ajzaBNY3JHkOKKetSMpPIL8i76XfWaP69xPwpF+1lGnbeSJ Sp3HjkBlR5KjQ6C6I4XHBTmGxr2SWNnjScbhg2OaGDXVGKy+GW/jcxlfN8RujFvv3dc+ZpI3vrnf TFnW+3bsho6xM+wlRucsNf6Gc/WN3djmPXlWjsUq70F5XeWPeJB63/Z+zUi+kRIHVW37sG493wdV 6pgdjp0xK2RFzQMdM8FGafePRv9XfjT6uyJj/jo13qtRXtVD6dgs9je0jYS0x5ZIezE2hcef8PgW aUfGREZA2Woz20fHthZljEvMDtTLEh1t3G9SoD5QT20y10mu5SbV95v045hgHKyOGlHPMs5Gj6s/ HlMjI3eliqbwKDqhbfyU4zpnuGugMWkLZyYl5o4YnrO3uz08j6lv5qweP5x3mKhKaJt92maVhN7d 7R0zUDgq5dymcttlDsru7J4gr8gzMpc8n9Dbu68tUhN7JvRmBkyQ5eV++GzHPBo9k0pb1KwZmTej Zs4Eajhznnyy0+y4LzIzdmuznus/hO8u7z8+97zDiVnY08n70mvSx7RUVI9t83G4J0pvhiOl30z8 nS1bU3oiMbfbM6q9t8i2ierVo5K2orVthq0O1xpoTAwEGsNJ3kF+95skW0XuhSNNfgcaLxza/9Iw 4Rmu/6VqVopKcoYLz25qfvy/TGpOjUo/zqFm2qgUmXHb049LyJn2P0tqLj7n1D5j/4t0pqdkap/H /0VSM/s5J7XaOMd0pnfUGiUq/dh/au0SlWTch1v6P0s/rvl/tu7cUtjPcu0Su/FyI7vv5a3eg3LV o1KJOmPIlY46KsnuK9dAkWskVlDpctUUPivHfrknk1odTVErK7mGahrTpNZHrI7Y23l5iVqdBNpX MTJtnhjIOTQxIFcw6mhzZJ0T3t/MKqhenpErGlkuJ5LUimehWhuRV13dLLdJW8m9Wa6mGC0G5BxS 666CSMpVZwbIVZc6ys05JMelyDUSK7c01mpyhSbLrVF7JLVOy1frOfKqlVr7em187hU25ZFW6Ysb FoY9cbmh9GBx2NLxH6m65Z3WqLpUvZ174o9bNDoOLqoJHwlDvndAvm9Avm1AnyI8+nzrb/oHYqSQ vzm+j6MGtdeoT7a+Fpp694BNvmNAn2Lt4wn9VatVVFitmk901e4Qk7TpIkmbIVK0mSJemy1/y9Qa Ts4r1O/5a+o3/O3k9ZA3nrwe8rpUfQ3k+l44NfmbxD7Rj+uTuX4+1/tR14XUlULpZ7HnC/nbvtYb 2BuvL8OO5dY72DtK/8p6Sv9apOkN4lL9GzFY/9b6VD/G066sfR+118s3Klg2fcrpf8jf/qemclEg uohsEQejxEAxGmZan4pZkAcLrG/EQuukWASL4T4ogCXCI5Za+8X9sAyWwwp4kPKrYDWsgYegCNbC OngYiuE9cZV4H1rYPw2WGKgJ0CBXjNZugElwI9wEfjFRqxR9UOzXbxYZ+q3yt2VhjiiSvwWvPyCS 9QfFBfYXrP32UngR9ouB9s+gGg5ADXwOtfAnOAh1cAj+LAbGxFmfxhy29sf8VXhiGtn/Dpqs/UaM yDYG8n2ZGGiM4HuO9alxD8yFe2GR9Y2xGPCNgW8MfGMsBXxjvC5GG9vgHTglRjsGiT6OwXC7GOjw wXSYB/NhCQTgAcBHjhJ4DF6AF8VVjlf5/g6+hyb4G5yAU4APzRkwE2bBItHHKcRoZzfRR8XuUeLa pfa+pdVPifOI2jKitoxoG0C0XUm0FRJtNxJt04m2cURbJrk3ES9D9ZutR/RbrKVE0E+Im19Qg0// wNqsf0WcNQhdP0oMfituVXH2NbkOscxs6xXTxLCo+sdS/2Lqv4b6R5J7KnU/Sd3vUOoy6l5P3c9S 33bqu1nEUstxajlOLXHUchG1zKWWYdQyjFoGU4t8Z8YX8s0P1DSTWi6lhi1K6W72XheJ1PEH6vgD daRqt1vvU88w6rmdeoZTz43Uc4Xmtz6hrmHaButdSv6O+uzUtxjL8qizK5Y9SG0P6/XWSaz7SP8L vfVbcbF+LNJj46l1ELX6qXUktV5Drf2pMZXaPqPkZ+qNJu8Qv+7ICPNPRhI5sjwtHrQaxSpYDWvg ISiCtbAOHoZi+MhqEXugCj6GvfAJ7INPYT98BtVwAGrhz5YlvoAv4TAcgXr4ytojvoYGOGHVib/T z09CCJrhFLQwuv0313+Af0Ar/BNOY4tlNWoCNDUqfqVPJcJ+bh3Xp/Hts47b91uN9s+gGg5ADXwO tfAnOAh1cAj+DH+xWuzfwjH4KzTCd/A9HIcm+BucgL/DScAW+2mwrD0xCdYeR6bV4rgGsmE85Fjf OG7iezJM5fqtMA1utxodPpgOs7k2j+/5sJD9+6AAlnC8jO8A3w/AGvYfAtrB8SjfJXw/Bk+w/yT8 AtbDU9T/Auc3sr+J/VfZf5393wFt5KCNHLSRgzZy1FmW4xDQRg7ayEEbOQ5T5gjUA23k+NaqcxyD v6KlEb6z9jm+h+Nca6Luv8EJOMkxbedo5vsUx7SROQNmwizayyYeEd3UzKWLR4jdycSwnL1iOPoN R9kcjSPKK/RPxGChcbZZZBGZdURmHZFZR2TWEZl1RGYdkVlHZNYRmXVEZh25vyHSWoi0FiKthUhr IdJaiLQWoqiRiGkmYpqJmGYippn7BblfnX6biNHvgOlE0AzrK6KmjqipI2rqiJo6oqaOqKkjauqI mjqipo6oqSNq6oiaOlqymZZspiWbacU6WrGOlmum1epotTpaq5mWaqal6miVOlqjDq+34PUWvN6C 11vwegtebcSrjXi0GY8249FmvFiHF5vxYh1erMOLdarHHhQOfHklPdlk7v09c+9b+j7m2k+ZhZht lH+PofBTFB5R/l3GUSJHvfFvITV8LqYwT6YwT6YwT6YwT6YwT6YwT6YwT6YwT6YI+T82FsMjYgRz ZX/myv702Wr6bDV9tpo+e4Q+G6LPhuizIfpsiD4bYj5NoM820Gcb6LMN9NkG+iztLcYzbw6nnx6h n35JPz1CP/1Sny4G6DPkO4jEKubRPsyjfZhHezF3pjB3pjB3pjB3pjB3pjB3pjB3pjB3pjB3pjB3 pjB3pjB3ptAXG+iLDfTFBvpiNX0vRJ+rps9V0+camONSmONSmN9SmN9SmNdS6CsNzG0pzG396SsN zG8pxH818V9N/FcT/9XE/xHi/wjxHyL+Q8x/Ccx/CcR/AzFfTcyHiPkG5sAU5r8U5r8U5r8UGe/W CXx9gvXZI9ZqWmAs4/kRxvNFtMRYWuIlrhYT7dfo+1lJVVun9QNiumq9OnIfJFctM+Yj1gqOplN2 P2U/42wmZR+h7IeUzaZsNeV+JoxIP7qFnAfIWU3ObLW+kjHzsqppFtev4PpertdwfTQ1reXqNmq6 ipo+oqY0lf9Pap34hdo2C5fWRfTRpsIcuAfuhXyYB/NhIaxjpo+Xbw2S7wmi9gLq2a3WRqWih/47 8RN9B+1fL/oxa9/IKjGBmbsnq8R++l8YGb7FgmOc+6v4CfP5fGsHJbqzpuwr53TKzxHjmMGmEvO3 inH6NLX6GidisawXlvXCsl5Y1gvLemFZLyzrhWW9sKwXlvWiZDdKzqVkN0rOVSW9lPRS0ktJLyW9 lPRS0ktJLyW9lPRScgAlL6GkfF/WJaqkh5IeSnoo6aGkh5IeSnoo6aGkh5KeSMnhkZLDUXKrGMTe IOXjMrVGOCXfFyTf4wE3wCS4EW4SLtZuLtZuLtZuLtZuLqf8e1q7fP+PfMdNZKVRodroiKjWUq16 bSAMgsEwBC6GoTAM0uASuBQug+HwExgBIyEdfgqjYDRkwOUwBq6ATLgSroKrIQuugWvhOhgL4yAb xsMEuB5yYCI8A8/Cc/A8vACl8CJshF/BJngJNsPLsAV+Da/Aq/Aa/Aa2wuuwDX4Lb0AZvAlvsVoL 8r3DOqjthHKogD9CJec/tA5ou2A3fAR7oMo6qn0Me+ETVhBTeVqZZu2z/5GVRCV8CLtgN3wEe6AK PrYO2PfCJ9aBmHirPqYbnAfdoQckQpJVbzwKTwM+MJ63jhqbrePGy7AFfg2vwJucL+eb1abxR/b3 WQeMz8hfy36zVe84Hy6APpAMKdZxR1/oB/3hQhhgHXBcBKnWQcdAIBYcxIKDdndcyvFlXBttHXVk 8D3JOm7arHpTBzvEgAEOMMEJLnCDB7wQC10gDtBrJkBXQLeJbhPdJrpNdJvoNntCL+gN2G9iv4n9 JvabKdAX+kF/uBAGYNOl1lHzMvipdcAcBaM5lwnXwnVwO/mm853HtTvJdxf44W5YxLXlsAJWQgAe 5fyvyP8y+bdYB81fc/wKnOBcyKp3aoBWZ1frgBMdzvOso85kYuh+9a4rvKPhHQ3vaHhHwzsa3tEo oeEdDe9oeEa9ESseEqArdIPzoDv0gERIAvnOLPnGrD6QDCnQF/pBf7gQBsBF8q1sPGUPhEEwGIbA xTAUhkEaXAKXwmUwHH4CI2AkpMNPYRSMhgy4HMbAFZAJV8JVcDVkwTVwLVwHY2EcZMN4mCDk/0/p 1nJgIsi3fd0Ak+BGuAkmY/fNcAtMgZ+BfGvXClgJAXgACuFBWAWrYQ08BEXA84Z6e9hj8Dg8AU/C L2A9PAXybVvPwnPwPLwApfAibIRfwSZ4CTYDM6C2BX4Nr8Cr8Br8BrYCY63GWKv9Ft6AMnhTvrtM vlMMdkI5VMAf5Tu+YBfsho9gD5w5iky27mCUnsI80IWRP0O+A0y+kYxR+1M7I56dEc/OiGdnxLMz 4tkZ8eyMeHZGPDsjnp0Rz86IZ2fEs2/lGeV12Aa/hTegDN6Et+Bd6zv7e/A+/A62w+/hA/gDBGEH 7IRyqICPhce+Fz4Rnph44YrpJtwx50F36AGJkCTcRrH1nfFfVqPxKPvr2d9gfWM8zZxEG6jRrJRr aDFe4ho2G9hsYLPBKG28bn1tbIM3uFYGcpR7m/zvcO49rr8Pv+N4O2CngZ1q9PuQ44+4tofvKs59 DHvhE9gnPMZn3JtnO4NnO6OGc59bp9RIeRDbeJ4zvqEszyxGI/usrg1W18Zx4JnF4JnF4JnF+Duc hBA0o+2U9bUj1vrO0QXiIB4SrVOOJOgJvaA3nC9cjgugDyTDAOFxXASpMBAu4dylfF8GzLIOZtfw qCs8pk24TR3sEAMGOMAEJ7jADR7wQix0gTiIhwToCt2EyzwPukMPSIQk6Am9oDdgp4mdJnaa2Gmm QF/oB/3hQrjI+s4czDPaELgYhnLMSsG8hP22kXg4+yNgJKTDT9ExCiawfz3wnGtOpFyuVWHeAJPg Z9Yp83bszCPfmaM0z7smz7vmfbAcG1bASgiQfy33pv+rUXs93xuo92l4Bp6Fl6lvC7SN4q9yjjY0 Q5T9h3XKKayvnZr8hQqr0Yk/nS6+4znfVXjUyM4M5ezBuURIAsZjZ2/5c0nZ0yPrquX00ANqjbaz /fxczi9RP0eR663vRYxtrPVz/XqrnNWpS/5si2vfiSG2NOuYbTiMhCtgrPWpbZy1xzYermdVPtn6 gtXFIVYXh1xTrD2uqfCQdcxVBGthHTwMxfBfwLOc61EogcfgcXgCnoRfwHp4CjbA0/AMPAvPwS/h eXgBSuFF2Ai/gk3WMc9g65jQsbTZNoVn4vk8Q4/G/hD2h2yjrAbsD9mu5nutdcS2jmeXW8XFjF8X k3OP60arwXUT3Aw/hxnWEdfdMAfmQj4shIesENpCaAuhLYS2ENpCaAuhLYS2ENpCaAuhLYS2ENpC aAuhLYS2ENpCaAuhLYS2ENpCaAuhLYS2ENpCaAuhLYS2ENpC7mzriHs8TIDrIQcmQi7cYB1Be4g2 HGl9TgtV2VQ7WrvUTw77oH0LurfYbrW22mbCPbDWCuKDoHz+RvsWtG9B+xa0b0F7EO1BtAfRHkR7 EO1BV4G11bUE7ocHYLW1FbuC2BXEriB2BbEriF1B7ApiV1BcSQv4aQE/tn1FC/ix7xQRdJIIOomd X2JJLZbU6pNPn9SnnA4xu3hpmWHyraq0zrDIM34F0XWS6DqJdbVYV4t1tVhXi3W1WFdLy/hpGT8t 46dl/LSMn5bx0zJ+WsZPy/hpGT8t46dl/LSMn5bx0zJ+WsZPy/hpGT8t46dl/LSMn5bx0zJ+WsZP y/hpGT8t46dl/LSMn5bx44FaPFCLB2rxQC0eqMUDtXigFg/U0jJ+cTVe8OEFH22xGy/4aI/dtrHi fNTnoD4n8vPWhyPP04PwQne8cBle6C7f3xn5KfHPaKvdtNVu2mo3bbUbb+TgjRy8kYM3cvBGDt7I wRs+vOHDGz684cMbPrzhwxs+vOHDGz684cMbPrzhwxs+vOHDGz684cMbPrzhwxs+vOHDGz684cMb Przhwxs+vOHDGz684cMbPrzhwxs5eCMHb+TgjRy8kYM3cvBGDt7IwRs+4SAWTqLYg+LHULwYxQko XIHC+0QSPqrAPxX4pgbf1OAH+U7qBK4+gf4K9FegvwL9FeivQX8N+mvQX4P+GvTXYEcNdtRgRw12 1GBHDXbUYEcNdtTQV/zWy2eMdyfFxbYbGOOmgJ9x7m7GuNkwB6gbiw+3j3XLGTNWWnvc91vH3Mtg OayAlRCAB6AQHoRVsBrWAGOjm7HRzdjoZmx0Mza6GRvdjI1uxkY3Y6ObsdHNuOhmXHQzLroZF92M i27GRTfjoptxMdYJLnAz5smR/ZiyPUQfb6CPN9DHG/CbfE4fwNX99N0G+m4DfbeBvttA323A9hC2 h7A9hO0hbA9hewjbQ9gewvYQtoewPYTtIWwPYXsI20PYHsL2ELaHsD2E7SFsD2F7CNtD2B7C9hC2 h7A9hO0hbA9hewjbQ9gewnY5Zk2x/oS3q/DwjvYxSyr6UlyKojKu13P9FK3RSmu00hqt5P2SvCZ5 3fQUF0qH0lNcqB0a+RlQJS3USgu1orIMlWWoLENlGSrLUFmGyjJUlqGyDJVlqCxDZRkqy1BZhsoy VJahsgyVZagsQ2UZKstQWYbKMlSWobIMlf+HuHuPj7uu8z3+60yTtJMJ5VpEQOQiK7qKqOAK3tDK 4rqy67oi6oq7K1BbKLRAgbYWWoOwK5dypyDlstRawFIlFkVouBVbAilJO2mmk9CEpiHJ9JdpkiaT aQp8z3Oy1YN7znmc888554+Xv8zkN7/v9/P+XL8xDXWsrGNlHSvrWFnHyjpW1rGyLjqZJbV8s4Fv NiRmREfwzwYW/EAG7JEBRZZcy5JD9/1k5tDyT2ZYcnf5p1l8t4HvNvDdBr7bwHcbWFXLqlpW1bKq llW1rKplVS2rallVy6paVtWyqpZVtayqZVUtq2pZVcuqWlbVsqqWVbWsqmVVLatqWVXLqlpW1bKq llW1rKplVS2rallVK4/PGc/jv2LFa/v+P6cz7Pp2u34iqmZvI3sb2drIrkPYdIjv3MmeRvY0sqeR PY3saYwqE3P59YqwJ3FleDNxrbi4KRQSd5Z/0u7dscS1oRhN8L97ohPcUUxcJSLm4drQkrgumpS4 3qdvDL2Ju8p/azXsTdwT9labb6vNt9VH4n04Cu/H0TgG57nnfFyA6fghZmAmLsRFmIWLcQlmYw4u xWW4HHNxBa7EVZiH+WHvuD1jdtqVWBh62LIjcUfYlXDSi76TuFS0X4a53r2KlfNwTWhKLMJi/BjX RockrgurE0vcd0voTNyK23A7loan2PdUdSK8Wp3ERFSgElWYhMlIoRpp1GA/TMH+OAAH4iAcjEMw FYfiPTgM78XhoUDDAg0LNCzQsEDDAg0LNCxUnxqaqk/DZ/BZfA6fxxdwOr6IL2Eavowz8Nc4E1/B eew4HxdgOn6IGZiJC3ERZuFiXILZmINLcRkux1xcgStxFeZhfngqmihytlFxMxXfSNwVBsXStWFI nIxGf88LJV4o8cAYD5Qj7A0dp6jjFN1RpHKJyiUdpqjDFHWYog5T1GGKOkyR+iXql6hfon6J+iXq l6hfon6J+iXql6hfon6J+iXql6hfon6J+iXql6hfon6J+iXql6hfon6J+iXqj1F/jPpj1B+j/hj1 x6g/Rv0xXa6oyxV1uaIuV9TlirpcUZcr6nJF6paoW6Juibol6paoW6Juibol6paoW6Juibol6pao W6Juibol6paoW6Juibol6paoW6JuSc5dIbrLubiQpleL7muj/ajdRe3t1N4VzaZxPY3rRXqvOzfQ uovWXYn5Xi8MfT41JPJjkR+L/Fjkx/zwNj/U80M9Pwwmbg7rZUCrDGiVAa0yoFUuvao2/IGPWvio hY/q+aiej+r5qJ6P6vmono/q+aiej+r5qJ6P6vmono/q+aiej+r5qJ6P6vmono/q+aiej+r5qJ6P 6vmono/q+aiej+r5qJ6P6vmono/q+aiLj7r4qIuPuvioi4+6+KiLj7pkSCxDYhkSy5BYhsQyJJYh sQyJZUgsQ2IZEsuQWIbEMiSWIbEMifm4no/r+biej+v5uJ6P6/m4no/r+biFj1v4uIWPW/i4hY9b +LiFj1v4uIWPW/i4hY9b+LiFj1v4uIWPW/i4hY9b+LiFj1v4uIWPW/i4JZrBg9082M2Du/n7BV7c xXM5ntvJcwWeK/BcgecK/J/m/yd4L+a9OHGD927i6SVhFQ/28mAvD/byYC8P9vPgoDhZy4sdvNjB izEvxrwY82LMizEvxrzYzYvdvNjNi9282M2L3bzYzYvdvNjNi9282M2L3bzYzYvdvNjNi9282M2L 3bzYzYvdvNjNi9282M2L3bzYzUsFXirwUoGXCrxU4KUCLxV4qcBLBV4q8FKBlwq8VOClAi8VeKnA SzEvxbwU81LMSzEvxbwU81LMSx281MFLHbzUwUsdvNTBSx281MFLHbzUwUsdvNTBSx281MFLHbzU wUsdvNTBSx281MFLHbzUwUsd0cd4qchLxfFs/E8vDPPCIC8M8kCRB8rnpkHqDlJ3kLqD1B2k7iB1 i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QtUrdI3SJ1i9QZ pM4gdQapM0idQeoMUmeQOoPRh1SGt1SGt2R/rJ+nEjew4kZWjO/e13dhqX5/j759uKnuCByJ9+Eo vB9H4xic557zcQGm44cwQdJ6lNajtB6l9SitR2k9SutRWo/SepTWo7QepfUorUdpPUrrUVqP0no0 +iGte2nda8exHceyIC8L8rIgLwvy4/r/MQPo/j9Evgk+Uf7Jxv862nv5o5c/evmjlz96+aOXP3r5 o5c/evmjlz96+aOXP3r5o5c/evmjlz96+aOXP3r5o5c/evmjlz96+aOXP3opGFMwpmBMwZiCMQVj CsYUjGVDXjbkZUNeNuRlQ1425GVDXjbkZUNeNuRlQ1425GVDXjbkZUNeNuT/D7Ihz0N5HsrzUJ6H 8jyU56E8D+V5KM9DeR7K81Ceh/I8lOehPA/leSjPQ3keyvNQnofyPJTnofx4jx8Y/38hT+GrmK9i 1SZWbbppH9O+rHFM45jGMY1jGsc0jmkc0zimcUzjmMYxjWMaxzSOaRzTOKZxTOOYxjGNYxrHNI5p HNM4pnHZxpiNMRtjNsZsjNkYszFmY8zGmI0xG2M2xmyM2RizMWZjXF2Ohbm4AldCvLExZmMc7a8W j/x5zoi0G8YzvaimFv93OWJ2v8KM6mQq29KyrVK2vSHTDpFpqeisP1WUubrxQlztXH6ttf49DIjs AXeX5OaA7jzsUx+lcJHCw++amgZE94DoHhDdA6J7QHQP/D+qNgOib0D0DYi+AdE3IPoGRN+A6Bv4 vzoVlU8rJUqt/9O5ZThK7nuvxEt7o2/StoG2DfzXz3/9tC2fbHI8UUHfHvr2jNe/JV7f4Yxwp0lp qffuCT107aFrD1176NpD1x669tC1ga4NdG2gawNdG+jaQNcGujbQtYGuDXRtoGsDXRvo2kDXBro2 0LWBrg10baBrA10b6NpA1wa6NtC1QUz1i6l+MdUvpvrFVL+Y6hdT/WKqn+49dO+hew/de+jeQ/ce uvfQvYfuPXTvoXsP3Xvo3kP3Hrr30L2H7j1076F7D9176N5D9x6699C9p7ps51xcgStxFeZhfugZ 13jPvkwoRQcl1kRTE8+bOF8Qly+GRYn1YWVitzljJCxJ7AlNSZUz+RGn1xPD6uQnQ/efflv57Gj/ 5Lei9L7fKexNt4WNPLbccx/HCzLgxZBJrBPpL2G9NTe4vhLaEhuddDNWa3Hdgt5ocqJPpo6YcYsm oVGMhcFkFDqTVZiEw5z+TwxdyZPC7uTH8QmcHIrJ08L29D+HOH1+aExfCDUifYnr7NCWngM1Ib3A daHr1TBDp2uhY6ZvgqxML/H9272n9qXv9nop7vOM5WFP+hHPX41fhd3pX+MJ79V5/ZQrm9JN3mvG JrR6nUWbr9vR6b7+0JnejdHQWXNwKNQcgqlwOqxxOqw5zvszQ2ONmb7GvmquD8M1N4XdNXfiHjwc CtHf7FM1x08lqrZStZ+q/VR9i6o7qJqlaitVd1O1laqt1CxSc4iaQ5QcouQQJYeouIeKI1QcoeII BfspmKNgKwVbKZijYCsFsxTMUjBHwex/UTBHwX4K9lOwn4JZCuYomKNgPwX7KdhKvX7q9VNvhHoj lOun2AjFRig2QqkRSo1Qqp9SQ5QaotQQpYYoNUSpIUoNUWqIUkOUat2nVI5S/ZQaodQIpUYoNRQd k3g0LEisCb+iVL0Y3EuhFVTZmdgWpouzuYm+8IDoPjsxbNLeEz4nzv6QTIZ1ycpwczIdLhbtLcmD w9HJo6ILkh8Il4v8Y5IfDV+k2sOi/wwx97Pk58LVydPDd/f9dlZH8lvhweQ5YWZyRlhb/v0lVv1e TXpel3gR68PrVnyTP7ZZsdsKfZ464InbPXGXXDpNLn3WifBRHns+NPtUOV9eHc+R3uh9Pr3JJ1/2 yR321m1v1Z6QGc+HT4aMTz4fXvapN33qSZ84yCfesF7HeP46VY/n8FHy9CNenxi2+VSnXa6LjhRZ u8c/uU5kvYQNIuYVn94oqjKmyBbXLWGH6NghOnaIjB0i4w2R8YaoeENU7BYVu0XFbhFREhElEVES EW+IhJJIKImEHTy3g+d281q58vdG+9lPpZ0vt96j1v0dW5/ChjBG13Z6dqevCkXPH/L8Ic8fSt/j 9f2h6DlD0USfGrbzS31ieznuTcKPqiVr2PJiaPJuW6JZHSlruC3k6dbsua2e2xqdY9Ul7l4kp7rG o+V3YaHVF/rkICXGKDHmCV2UCJQY3pdXw5QYTmTD455YJ5KaErHoSeHgcH5yKm8civfg2HBZ8jh8 IOxMfpCfT8BHeI/uyc/7/unjv7t8kt2cJPe6qDtM3WG510XhYQoHCge510WFhZQOlFhCiSWUWCL/ uqg9Ru0xao9RO8i/LvnXRfUxqo9RayHlhym2ML1KJXocT4fL0utcX0UjNmIrcnjd9zpc3/CM7eGy mij8oaYiPF5TiSoc7fXxmKlCLQ5L5GAXb47V3BW219yNpbgXy8LjUbWIHBKN23n6E6rP26rP26rP 27z+KZn+tkx/W6a/Lavfjo7gj7Ivi7QfoP2AT1WqUYNq1KAaNcj2YbYPs32Y3QPsHmD3AFsH2Dqg vgyqL4Nqy6DaMqi2DIrvQbVl0F6H7XNArRhUKwbVisEJKSsuFgF38f5zvH8b79+WWMuj9Xg+rE+s 0xVfwvrwsCjYm9jk/YzYyoa5ia3hmUQObWjH69gWrk90uG5Hl2fucO1GD3qjxaKlLpH39U7EIq/f tYBd4bLEAAZ9PYTdYYba1KRyZ1XurAw+W43amNjre2/h7bA28Y5r0IUnIIFy/Zoo2ip8XalOpcKi ZLWv02HWeD2b4ro/DsCBODicJlrPFK1nitYz9dbrku8NVyYP970jcFT07eTRrsfgWDXvOHwg/FPy eK//Ah/0+gR8yNd/iY+EL6mR/6KyrOK1xby2mNcWi/avqZc3JU9xz6fwV+HHyU+7norTwjXJz7h+ Fp8L35MVZya/4OvTw6Uy4+x9vzG7SoZcmfxO+b+oihnhNfX1l+kZoSk9E7PDXlmyV4bcJkP2ipLF omSxKFmcXuz7P8a/4d/xU9wYTU3fhJuxxP13eu8u3O31UtzjOT/z+n7XB8Ks9EN4GMvDdemfhyt1 s2vSj3r9GH6JVeEMWXWGDneNCFwsAhebD67T5a5J/yb8OL0GT7rvKe897b5nfL0W9d5f5/V672/w 3AbvvYJXvdeIjWjyrGZswmb3t7o3i62+l4PqLboXy9oz0tvCMzL3DF30Gtl7puw9I93lPTGYFoPp NyEO073oC8+lxWFaHKZjiMH0LgxgUAUYQtHXpbA2vQdjvn4bYi4t5lSFRTXirkbc1STD2pqJrhVh rioxV5WYWzPJ68mqRwpisCYdnqupwX6+noL9vX8ADsRB3j84ZHX6rE6frTnU897jnsPwXhyOI3Ck e4/y/ffjaOsf4z0VVjVaVHNNaJLhi2uuj6bW8HUNX9fwdc0NuBE3+d7t4UqZv1ilOkOlOkOlOkMV WKxanVHzM89ZZt8PeObDnr/c659jBX4RLouOViUuVSV+Pd6ZXxjv5y+pBD0yfonM/p7MXiNrV8va l/XcERn7rIztkpXNsrFBFq6VhZtl3Zdl1rkyabWMuUnGvCRjemTJnbJksyyoF/0/F/1/J/qfE/3l f6lwioh/LfpX9eoRO/mljrUpsVqXWqMm/M57T+EFfe5F31sXtqieW3Su59Ssfp1rjR7Yb7d9utca 3WuN+rXczl9Sp/rsfKNatM6us+rNdvVmu533qNcZO9+lZmfU7Ix6ss7uV6kFq9SCVXa51y7/oTzz 6F6b0v+i0p4f1uhga3SwTTrYGrnZLzf7dbBN8vMR+dkvPx+Rn4/Iz0d0sE3pa33uJ7gBN4YtqvoW VX2L3OzXzTbpZptU+C0q/Ba5+YhutkZuPiKXVon7VeJ8lZju008y+klG3PbpKRmx2idO14nL5eJy ubhcLhb7xNp2sbZdrG0XW31iq09cbRdX28XVOr0oI6bW6XBrxNQjOtwmnWOL+FguPvrEx3YT5Fpx UI/nTWjrw+8ovUN3aBYLX1TN21XzdvHwClU7qdpE1SYx8VuVextlN6jU7ZTdQNkNYmOn2HhTNd6s Gm9WjTeLkb8UI6OqbE6VzYmVreKkW2VtVFkbVdZGMdOimm5VRbMq52YVsVlFbKb6DqrvoPYOFbBZ BWxWAZtVwGYVsJmyO1S9ZlWvWaVrVtGyqlhOFcupYllVrFEVa1TBsirYVhVsq2q1VbXKqU451Smn OuVUp0bVqVF1alSdtqpKOVUpt68qNapGOdUoqxpt5p0NKku7ytLOSxt4aIPqsk112aaCbFMt2lWL dpWhXWVoVxnaeaqJp5p4qklV2KYCtPNUE081yfx2ntog85tlfLOMb5bxzTK+WcY3y/hG2d4o23Oy PSfbc7K9UbbnZHs7LzbJ8nZZ3i7L22V5uzNxr+m4PFd/MrwVnSzLyuesC2XUUhm1VEa9wM+LZM0e fl3Br3X8Widb8vzaxa+P8+njfPq4jCjJghJfLOKLRTKgxB+LRHxJlC8V5UtF+VK+WCTKS6K8JMqX ivKlonkPvR6n0+OieQ+tHqdVF626RPUeenWJ5D30qaNPHX3q6NMlmveI5j00qqNRHX0eF70l0btU 5O5hcx0bXww3idhRFqz1are9j4RHxea26L0s2+1VN8v6WNbHsgFWNaoDeZY1sqzR7nbbXaPdNdrd brtrtKvddrTbjvrsqM+O+uxmt93stps+u+mzm0a7KJ9l+6KjrDRipa1W6rZSt5V6aVg+ozZZbdhq TVZrstqI1Zqs1mS1Eas10WKIFkNWHaHFkJVHrNxt5W4rd9NiyOojVh+xerfVu63eZPXy+bDbGWGb erk7vMbq16w8bMV2tewpFbdVxS2fD347XnEr3TW87wyV3/dvmE5MnhN9fFy5Tt9p953O8Vfls93e cR0r9n1qyKvY87d4/qBpOGumjSk8xs4UJSJUmEkrUYWjvT4ey8KAZ2wb90yzu9t0kfIeh6PjPeMl 3/kd/YY86/fuePOP5/vxfhOpL1WYhFT4Pau+zpof0HGIjtvouI2O5fP1NvoN2cPv7eEle3jJHl6i 5Z+fuw/HEe86fx/t/uPk4vGuy9z/gPfKZ+4JbC5Eh9rfoD0N2tNOe9q57yc4u+y+z7522dcu+9hl H7vsYZe1B609aO1B6+607k7r7rTeTuvttNYu6wxaY2d0nKc/zfo/sHzDu6pshs6rrFQcr6qp8d8U +ck+X25l/Yzyb/T8sfqweINVn7bq01Z9+n9aecqV5mj3lavM8a7lirHMvf+1Ykwe76K7zQF7nK0r +fWbYfa+3+54zcrfHv+N0Y/b9zZ3/pbXGp0Lttj/s1Ra/a4KUu4MWUot4+ty332TWsuotYw9z3rq DZ72OC82mt22UHAZBZfxZCMVl8mIrIzI8mgj+56VFVk2bmPjNjZu49VGM9gWM9gW89aW/1I5srzc yMuNf6ocR3vGcWEZ259l9zZebhyvHodTvY3qbeM/jRhRRfaEF+26n/Jtdtxvx+Wf4fRTu43abXbZ b4f9VG6jchuV26jcRuU2KrdRuM1K/RRuo24bdduo20bdNlk1ouqO6X6iR4SNhGejhC44ZlLaEyVN I+u9GvSqJzraq4IzTMl8UjCfFHTKUZ1yVKcc3fczwryZZcAcX9Lx8jpdXqcb1elGzesl3S5vRi+Z Kwpm8pLuNqq7jepuo+bukrm7pLON6myj5o6CzpY3exR0mlGdZlR3GY0m6+V77OQ+vbugZ5fnujet WuDBh3nw4fGqMlm3H04erJJ8JMQs6HNXnDw5mqLCOPNEJ1knG030nB2eU/6Za6lsAYvT4z9ByJfv p8TB8unkUPJ++aey7vC57dEhXpWtH2b9MOuHxy3/jlnh3NDyLsuHWT48bnWTazM2oQ3tYB3Lhlk2 zLLh6P1W20jfEfq20rf13Sdza8dW6abtiBW6rdD9p9P4E+M/8eum7QhtW2k78mcn9Favs+M/BRw/ qdO21erdtG1992k9msDykei4ZI2vDg4PmJYKpqWCaalgT0/a05PUGjEx9ZmYyj9d66fTTpNRgQfe 4oHHeOAx58gDnSPLvx1Znnr6TD199vWk6abPdNNnuukz3fSZZvpMM33286RJps8UU7CnJ00UfSaK PhNFn2miL6qym19bebcVS1bcbbU9VnvFaq9Ex/ruG3Trscet9rjVncV9P8P+7x462WR3mrg+nQ7L Qw8Nx2g49icvPeG9Oq+fcn3apLXe9d1ea/U6iz9673X3dLp/e9j6Z16cSrVOqnVSrZNSnZTqtO+O fT+T6qRIJ0U6qdFJjU5qdFKjkxqd1OikRCclOqnQSYVOKnRSoTN6LztfZ+PrbHydjbvYmGHjZjZu ZuNmk2o56jazZ7OpMm+qzLPldZNlOQI3s2UzWzabJPPs2MyOzex4nQ2vs2EzGzazYfP4v6I8Nvn9 6NhoaXReuCc6HxfgsvBgND/cGi3Aj7AQV6MrLI12oBtD7tkTbonGsBdv4e1wy4QPhqYJJ+BD+DD+ Eh/BR3EiPoaT8HF8Ap/EyTgFn8Jf4dM4FafhM/gsPofP4ws4HV/ElzANX8YZ+Gucia/gb/BV/C2+ hrPwd5gRHTrhufDshOfDbye8gBexDi9hfVg7YQNeRgNeCWsnPhBunfggHkKj1xvxGtg68R2EcEvF /uGeigPD0gpTdoUpu8KUXXEo3oPD0BlurYjd04+BcGvlCTgFF4V7KmfhYlyCueHByitA98oloamy KaytdOKpOj6srfoLfDD8tuoEfByf8Poz+E5YWvVdnBtuqboby9Hp9RvYDj6r6gsPVuWxy/eGvS6G WyYlQtOkJCaiApUwKU4yKU6ajBSqkUYN9sMU7I8DcCAOwqfD2kmn4vu+vsB1kesvXFeG304aCU2T PWvyQebj70UHho3RQVD9okMwFYfiL/BBnIAP4cP4Kv4WX8NZ+Dv8Pb6Of8A3cDa+jfPCfSL3PpF7 n8i9Oro8LIvm4gpciaswP6wUzStF80rRvFI0r5z407Bx4g24ETfhZizBLbgVt+F23IE7cRce8LkH 8VBYyev3VbSGjRXteB0d6PT+m649iH2/HwPeeztsrKxEFSYjhffgMHwAx4MOlXQQHSsrP+l6iutp rn+N7+FcfB//jIvCfSLnPpFzn8i5T+RcLXKurmRvJXtF0MpJl5S1iW4NTdFtuB134E7chRX4BVbi ETyKBryCV9GIjXgNTWjGJmxGBi3Iois8oSY8oSY8oSa8HO3GMEZQxCj2hNXqxGp1YrU6sVqdWD2x NzRN7EMeOxHD6WRiAbswgEEMwYll4jDKn3sHIayWb09UqQVVcr9KrlfJ9Sp5XnVWeLnqH12/ie+4 57s4N6yuutDryzEXV+Iq/AjX4XrItyoaVdGoikZVNJJPq6v+w3W562rXp0GHKjpU0aGKDnLtCbn2 hFx7Qq49IddelmsvV+1EjF0+O+x9esi71RM+Gk2MDogqUFn+r5KU/7sJmIzyX++uRrr8JyaxH06N pkan4bywQIwvEOMLxPhcMT5TjM8U4zPF+EwxPjOa5wnzwyxxPkuczxLns8T5rKg2mhJdi5/gOlyP f8O/46e4ATfiqeh90e/RFebz6Hwenc+jd/DoSh5dyaMreXQlj66Myn9Bek9YyKsLeXUhry7k1YUT 7g0tE36G+3A/HsCDeAj/gYexHD/HCvwCK/EIHsVj+CVW4XGsxq/wazyBOvwmtCQ+Fk1JnBRNTXzS 9fM4MyxIfCVclvgqvu71jLA4MTNclLgQF4WLzGxfTX43XG5u+2ry+66Xh4bk3NCcbIoqks3RwcnN pt4Wp/ItUSrZFVYmd5hFuqMPJt907Sn/bSDXndGBEy+PDpg4F1fgSlyFeZiPBfgRFuJqXIMHwiz1 YpZ6MWvipmjKxM3IoAVb0IostiKHNrTjddBTtC8U7QvVmgUVB4QWUT9fjZlVsTNKqS8L1JcF6sus ir3RAZVJiK3KA3EQjsUJYVblh1xPwieiqWrKrMpP+fqisED9WKB+LFA/Fqgfc9WPuerHTPVjZqVY qpwPsVR5T2ipvHf8X9C3VB2J9+EovB8n4aywUqbNl2nzZdrCqjnRlKpLsQiLcSvu9v4Drg9F75NN C6se83Wn+9/Adog5mXOHzLlD5qyUOSur+qPJVQXscv+w74s/GbSwajSaMung0DLpEEzFoXgPDsN7 cTiOgL1OstdJ9jrJXicdjWNwLI7DB/ADzzoP52Oh11fjmtAyeUJoSZ0TLkt9BwvDRalrIG9S8iYl b1LyJiVvUvImdRNuxhLcAvambsPtuAN34i7cjaW4B/fiZ7gPy3A/6JN6EA/hP/AwlkdTqhfgR1iI q3ENaFtN2+ofQ35Xy+9q+V0tv6vts9o+q+2z2j6r7bPaPqvts9o+q+2z2j6r7bHaHqvtsdoeq+2x 2h6r7bHaHtMfjqbsNxkpVJf/i9DJ12RKl2pU/qr8t0cOTVypmqXH/+sClajCJExGCtVIj/8F+7Rq ljYB5EwAORNAzgSQMwHkTAA5E0DOBJAzAeRMADkTQE7lO0jlO8gkkDcJ5E0CeZNA3iSQNwnkTQJ5 k0DeJJA3CeRNAnlVcroqOV2VnB79MBSiGZiJC3ERZuFiXILZmINLcVmYoaLOVlFnq6izVdTZKups 1XSaajpNNZ2mmk5TTaeppinVNKWaplTTlGqaUk1TqmlKNU2ppinVNKXvtuu77fpuu77bru+267vt +m57VP55x0o8gkfxVHSYynuY/lvQfwv6b0H/Lei/Bf23oP8W9N+C/lvQfwv6b0H/Lei/BdV6jmo9 R7WeE/U4y/aiD3nsRIx+FLALAxjEULhbZV+hsq9Q2Veo7CtU9hWq+jxVfZ6qPk9Vn6eqzzPTZ830 WTN91kyfNdNnzfRZM33WTJ8102fN9FkzfdZMnzXTZ830WTN91kyfNdNnzfRZM33WTJ8102fN9Fkz fdZMnzXTZ830WTN91kyfNdNnzfRZM33WTJ8102fN9FkzfdZMnzXTZ830WTN91kyfnfD30dQJX8c/ 4Bv4R9wbMjpRRifK6EQZnSijE2V0ooxOlNGJMjpRRifK6EQZnSijE2V0ooxOlNGJMjpRRifK6EQZ nSijE2V0ooxOlNGJMjpRxlmizlniGWeJZ5wlnnGWeMZZ4hlniTpniTpniTpniTpniboJr0apCY3Y iNeilC6W1sXSulg6cWr536i6fsn1zHCNbnaWbnbWeDf7bogT52GG7vaurpaYFWKd7bM620yd7bM6 20xn8SXJy8Kq5NPhhWR9tF/yed3vNef5Zuf0zdGhulxel0smW53v/7PTVeh0x43/jcm893fqPJdH aV0urculdbm0LpfW5dK6XFqXS+tyaV0urculdbm0STpvks6bpPMm6bxJOm+Szpuk8ybpvEk6b5LO m6TzJum8STo/8e5QmLgU9+Be/Az3YRnuxwNhms45Teec5txV59xV59xVp4umdNGULprSRVO6aEoX TemiKV00pYumdNGULprSRVPmzII5s2DOLJgzC+bMgjmzYM4smDML5syCObNgziyYMwvmzMLEkRBP LGIUJezBGPbiLcgJnXmezjxPZ56uM2d05jnOf1nnv6zzX9b5L+v8l3X+yzol5JwSck4JeaeEnA4+ rWJHKDgp5JwUcjr5dJ18eoU9VdiTjj5NR087NeQq3vE6hEJlhAlIIBmldfq0E0XOiSLnRJFzosjp /GmdP+1kkXOyyFUe4d4jcaz3PuD18VBrnTJyJoNpJoN05cd8XwyaDg5y6siZEKaZENJOHjknj5yT R87JI+fkkXPyyJkcppscppscppscpleqo5XqaKU6WnkZLsfcMMM0McM0Mds0MdsUMc15NmuSyJgk MpX3j/9FpqmVv8Jvxv8q09TKl1ybQp0pI1PJl8692crRaKqJI2PiyJg4MiaOjLNwnbNwnbPwM87C z5hAMs7DzzgP11WdFqWcieucCwrOBQXngoJzQcG5oN2UssK5oOBcUDCtzDGtzKn6pxBXfQ/nhnnO B4Wqi3wtp6ouxiWYjTmeeSnY5ezQ7uxQcHYoODsUTDgpE07KGaLgDFGo+qn7bxj/q4IFU0/KeaLg PFFwnig4TxRMQfNMQSlT0GHOFQWT0DyTUMrZouBsUXC2KDhbFJwtCs4WBRPSHBPSHBPSHBPSnKod nt2NN6HWV6n1pqa7TU13m5pWmJpWmJbmmZbmmJZWmJbmmZZSzvpZZ/2ss37WWT/rrJ911s8662ed 9bPO+lln/ayzftZZP+usn3XWzzrrZ531s876WWf9rKkrY+rKmLoypq6MqStj6sqYujKmroypK2Pq ypi6MqaujKkrY+rKmLoypq6MqStj6spM+rg9fQKfDnWTTsX3PfsHXp+H83GB96a7/hAzMBOXhLwJ LWNCy5jQMpMW+cwS7//CvSvDM5Me8fWjGAnZyVE01QSXmcy2yQeFusmHRKnUN0JX6h9xNs4JZ5ns zkr9k6+vCnFqHhbgj5PeYl//BNdHaRNf2sSXNvGlTXxpE1/axJc28aVNfGkTX9rElzbxpU18aRNf 2sSXNvGlTXxpE1/axJc28aVNfGkTX9rElzbxpU18aRNf2sSXNvGlTXxpE1/6/+PEl/6zie+Q6Obw mQnnRl+b8M/RNyb8S3TVhH+NvjzhB9FnJpwXfStxZnROYkZ0dvKb4YvJc8Lpyd+HFcn68LXk9vCy 2fDgpAqXfDPcmuwN65N90eHJvPPWzlCMjopufufF6LGwKVoXNnn65/b9NdhTPP3Dnv5hT//ChBmh qLd2W8Vpzqnsm+FUq3zWKnOTz4Snk2tR/06cfC6s0eNaky+El5Ivhputfq2VS8nu0GP1U62+xOpJ q99v9RejScmNYXmyyZ6c5JObwg+Sm8NTyYxPbQltuuLr5tTHwh/s7Q/u/LbeudHdd7t7QXLTO++4 +yF3f0UfXeMTV/rEveN/2/FEu12omx+pe38l8TWdfEaYkbg4SiYeNSe/GP41sT4sTWyLTk6M6MgH R1OSJ4afJ5+J0rr0iSz4tZXWO48mk5ucNVvCb3TpCk9/h0UZnXrBvk6d3HcmTbKsJ9nHqrz3d4b+ Cd+KJoanogpUogqTMBkpVCONGuyHKeHpaH+cGtqi01Ab/ht13wFfRbH9f3Zm787m3t0QQggh9I76 VPDxLFji81l+Cog8xUJXUZ4KFgREqlgRkaqAghRBfYoPsdEFC9gF6RAMJQESIGwogQAJd/7fmbuJ CQmkwNP33/v57p2dnXJm9sx3zpndu3cuPQ+8ALwIvAQMB14GRgCvACOBUejDhXI1LZKrDSa3GBww gQBgAQKwgSggCIQAF4gBKgOxQBUgDqgKxAPVgASgOlAbqAPUBeoB9YEGQEOgEdAYaALcJlOMdsA/ gduBO4DBwBBgKPAMMAx4FngOeB54AXgReAkYDoyRm42xwDhgPPAa8DowAZgoN7Nmci5rASQB7eQC 9rJMZiNkMrS8Pa5KJvQsDzo2F1ciEzrWFjqWx4+GM3gORsQxKfjxcA4/Ed7Cc6XF88Lp/KRM4mHE S1ndDIQzTEteZwopTDucY0aFt5hBaZmhcLrpyCTTRXw00vWRC82+QD/gKaA/8DQwABgIDAIGA0OA ocDbcos5E5gFvAO8C7wH/Bt4H/gAmA18CPwHmAN8BMwFPgY+AT4FPgM+BxbIFHMhsAhYDCwBvgCW AsuAL4GvgK+Bb4DlwBo511wLrAPWAxuAjcAmYDOQDGwBfgNS5NxArlxocQD6awXkYisW31WABsD5 QHPgr3KLdRm+R8oUawIwCcdop/UOwmiPhfZYaI+F9lgfIW4u8AnwKTAfWIj4RcBiYAkA2S3Ibv2I 8E/Azwj/AqwEVgEbgI1ys5WMc+nAPuAgcAg4DGQDR4AcmSKigUpADFAZSJCbRXUgEagB1ARayC3i MuAJOVf0Bp4BhgFjgWnADLlazMZ3jpxrN5Ep9gVyi30Rvpvh+1agLcL3yM32/TjfHXgAeBnxkxD/ BvAmMBmYDeTKzVEkU6Iq4xvjKwrjKioRqCm3BO+XycGHgZ7Ao8DjQB8A4z2I8R7EeA9ivAcx3oMY 78FXgVHAaGAMAHmD44DxwGvA68AEYCIwCXgDeBOYDEwB3gKmAmhjcDowA3gbmAnMknNDt8jkUCug NdAGuBVoC9wGtAMGygWhQcBgYAgwFHgGGAY8CzwHPA+8ALwIvAQMB14GRgCvACOBV4FRwGhgDDAO GA+8BrwOTAAmApOAN+QC5wI5NzpKLogOAiG5gEzMFXPB/Hv5eroIvJxHr9MAOZkGAoOAwcAQ4LhM hv+cDP85Gf5zMvznZPjPHvxnD/6zB//Zg//swX/24D978J89+M8e/GcP/rMH/9mD/+zBf/bgP3vw nz34zx78Zw/+swf/2YP/7MF/9uA/e/CfPfjPHvxnD/6zB//Zg//swX/24D978J89+M8e/GcP/rMH /9mD/+zBf/bgP3vwnz31Fi7jW8j5ncyEz5oJnzUTPmsmfNZM+KGT4IdOgt+5Fn7nWvida9ksmaGf j4w8dbSD5cgdmM02YRabzFdRHcyX2zGDjYQPNxk+3GT4cJPhw2XCh8uED6f8p2T4T8nwn5LhM3nw mTz4TB58Jg8+kwefyYOPNBl+0GT4KZPhk0yGDzEZPoQHHyETvoEHPyATfkCmOF8miwv0+zgzYfsr Wz4ZdnYybOtk2MLJsIGTYf96sH892L8e7F8P9q8H+9eD/evB/vVg/3qwfz3Yvx7sXw/2rwf714P9 68H+9WD/erB/PdirmbBXM2GverBRM+2+KPsZhN9Tb02THuxND/ZmZlQcxtPdchJszEmwKdfCplzr DJYZzhBgqMxw4+QOtyoQD9QB6gLDED9T7iCGWeVDzOuw4/giuoIvps58GbXgX1IC+nc+/xqW1DfU hK+kW9HXt8KvD8BiuAa+fSxfR5eg37fBcqgNOycVsWl0PuyFW2EvNOYZdCPK/dpfy74ANX0lZyP9 eF3nXJx7GFbFYopG3A84WqXeS1n8XbrGQ5RU8vt0IU9zjI6rUGtrzIc3Q4ZITHPMljmIvQ6z5WLM lnv1O4r3qX+jRGxNHF2j1xSrIW0jyKD+i2A3XYgUF+FoFSWhhXE4VxttVW99u1v+wvtQS8j/tXk1 7DWGmO9x9BNSY26CTZiFoxQc9SQXRydw9D01IZOSKABYgABsIAoIAiHAAVwgGjW2p6q8A2y8LkBP tGkx7MAvYWd+JVebfSjJ7Av0A54C+gNPAwOAgcAgYDAwBBhKSfDlk+CzJ8FnT4KPngQfPQk+eRL8 7yT43knwt5P0/1+4sG6zUVMKWrGbL8OVVP9m8pWcB+t2H9reB32yCHJ9gVRoLdruUqzxKzUwVlMz 9EwX9MM/eAek6kgdeRf9jrmOvKf8Sr2ViPeTqXwCXcon0mWox8OVbgRLZo55BV1itqRm6K2OVBs5 aqOeFriafaguatqv6tc1uf7/mnzHOyF3Z6Tvhu978d0HGvar3AwbORP28XGtPxvIRi5OlvonFKSO R8p4pIxCSg8psiie0sCisKFoF+ym3qhJXdN+ci3s7kxc9Upg3NW6vHW4guuRC2UqizgQK/Pgw+fB h8+Dj5wHHzkPPnIefOQ8+L55qLO9zFC/eEKJ52OkCF3aeplN1YrU2Qmc1Q3ohbb1gSW+Sh6EdFlo hweNq4q6jyDXCtQbQr3HSq03hHpT1X+zoLRY1BtAiUdQYiZKzEaJUSjtoN+KPIyz9ohV7wvsBEu+ G9AbZ/pQdeSMgsQWch5FzjzkdCFLWPUacuZiVKTRTbQT2AUch2afAHKBPOAk2KE9PJe7ZTPeCWzR mbrybvi+F9+94Pv0hjz95Ew+CHoxgS6HPlyFHv8VNbbU12aNfEvXtk5uwJiLg5dzwteRS0yUbYYB SU0CsXST6AB0BLpQEzERmAVsx/EOIBWAnCILcdn4PgrZ1PsfsyDZcbT5OCQ7H+0+DsnOR7sT0W7F GDbaG0Rb0/lGitFatwQ5vkaOnciRiBw7kSMROS5H6hjIvFtr3hqZC7mPIedOnWud/l+CDqivIzS5 C7674rsvWDGV6oPxssAxQTBjdTBjZfDdEv2POur6JSMVR0wWrkN7hO7WY0O9DS+ePwmtegrz3W7I nYEa90hP69t25NuJfEGUbqNkhjPJVJ26y4P0APAg8CSufntczw6QqwvQF5qpUqdBS3ajp9Mh0x74 l3tRyj7Mk1dTtUCMPBjIBPbLg1ZPoBfwKPAY0Bfoh3Kj/f8E2oSSk1FyMn8SreoLzk/FdUyDFu3E CNKtBQ9noI/2yJ+1L14N8uVCvlzIl+u3Xq0pb0UpW1EKQynnQ8YYlJKDUsIoRb1p3kYJO9T/EUG+ XMiXC/lyIV8u5MuFfLmQL5cupO7Umh4AHgQG0PU0EBgEDAaG0PWosRJq/As4K4AebgfOCqCX24Gz 3kNPf4Ke/gJ6+h309GboaWv+gRyLNv2EGaJxRBrMW0qaDFgTV1BL6GhL82q5yZxG15vTgRl0fSCG Wge24zsT3/uBA3S9dR5wKdCTWlu9gEeBxwAlnw2pjvp6w3y9YfpaqR7cI9P1asQcyP2unyreTxUP uT2kvESvQOyRa6EZPcPfwBfcD99vO3y9/fDttptNw7ugaz3DHmKzEJNlNpXXoNSe4a38KPo5F7nz wA0n5UozIHPgFx4zQzIbKVci5Y0671c4uxoxqxET1Hk9fgL15aJXTsr18DHDZhRZyBtGqvXwJcNI mQRe6hnejVrC8FKzIVkmP47vXNSaB82M5MxDrWF4p9mQONO08R2EFCHER0rKQwuOQOt6wq/NIQOl ZKGUMEqRKCFD122RgdxZyB1GbomcGb4M56l+Co+BDKnI3QC5tyD3UX4CI1ZJnwc9PgmNC8NOkPIk ZElFaQ1Q2haUdtSMkut0q0K4zg7FwFPei5JPQqb/qFlUMpR4DHKk8DAx5DqGulNMF+Gmsp5KEV6F FOmoT/VUMlKko0zVS8ko4wB695TrhavvXyfkLuX66LT6uiBtKdcDbTzL6wA+LWf/g2XOcb+jjafp b32mxH6maDOOosyqkC+BgmYiSquBPDVhM9RCuDbO1cG5+jjXEMeNcK4xzjXBfGCa8aihBs7WxXcj XBPHjMMRfAizGupPRA01UJMqqzbi6yC+HuIbIr4R4lEOroJKrWqu4adQNamyYiEXw9ldZjxiqgEJ VBvyxSLlLpRZG/IxyMeQa5dZF+frAfUR3xBpGiGuMcJN1L+So5QUyKpayMzqkDWRAn4pKncK5Fct ZGYDnGuIc5HcDO2NA6pC9+IhcwLKTURbauDq10RdtVS7cL4OztfF+fo43xBxjXC+Mc43QfvQClyb qig3HrHVgAS5ATKE0TupZk1cy1poc22kqYM0dXG+HlAfaRogTUOkaYw0TTCzqevk6H5NoDjIoXrs GOSIgxwhyOHovq2P44a6B49BhjjIEFJXhbhue6LfzxHpVe9x3e5IjixfakaVKqoTGLUe+u8UvcBo v5jc8uoGcjUjcTr9wNlGVOVc6QhK+wtaXUE9Qe6mVPlsdQWlXKFadG70BVfiR30dK6Qzem5wy6s3 mtWb8qPhPWDSbmCcmmC1NvxEOAusdgPPC+8F+3QHq9UFq7U0A+E9YNRuYKOaYLU2ZlQ4C6x2gxkK 7wUzdQer1QWrtTTjwkfRIxeiR85Dj5xnJuC4uvwLeiQaUjVHrzRGrzQyayO+DtLVRZp6QH0cN0C6 hkjXCOkaI10TaE0UPDcHPlcSV//r8w1VgbUbB0u3IayKy2ErrIC1V0n/t9AiowtdaXSjG4176RXj PnzfD8+9vZzC74QvcpdcBMtjiv6nuvPOkGqFTqX+A2mjjs0/mltwxODJLzW+lHN1SP27XSpCleAl X0hELeGTnk9/x6cZtaLbqTndSXch9h7YclfRv2gk3UKj6AN6jBbRUhx9ic9Y+pE20DjahM80SoF3 Mp3SUeL7Rg2jBq0xahsX0lqjtdGG0oy2xh20y+hgdKJ9RlejK3nGvUZ3yjJ6Go/SYaOvMYmOGm/i k2hMwaeGMRWfmsb7xgdGLeNLY5VRhzVjlxgXsxbsMuMS1pK1NC5l17Ak4zL2D3a9cQW7kd1oXMn+ j7UyrmJtWBvjWtaO3W78nd3J7jauZx1ZR+Mm1pV1Nf6PdWcPGDezHqyH0Yo9xB41WrPerJ/xT9af vWTcxV5mrxo92Gg2wejJJrE3jD5sFvvY6Mc+ZSuM59l3bIMxkW1iacZ7bA/bZ3zKstgBYx47xHKM Bew4yzWWMsnJ+Iozzo1vuOCusYJX4rHGzzyOxxm/8nieaKzm9Xh9YwNvyBsZm3gTfp6RzP/CLzRS +MX8YmMbb84vMbbzFvxSI5W35Fcau/jV/BojnV/LrzX28Ov4dcZefj2/3tjH2/C2Ria/g99tZPEO /H4jm/fkvYww782fYsQH8UHM4kP4ECb4BD6R2XwOn8OC/DP+GQvx+Xw+c/hC/g1z+Uq+kSXwVL6P 1edHuWR/MQNmNLvUjDObsmvNq82rWXuzj/kSu9McYX7OHjYXmEvZBPMXcxV7y1xj7mLTzQxTss8C wUCQ/RxwAg77JRATiGUrA2sDm9nqwG+B7WxTIC2QxlICuwO72dZARmAP2xbYFzjAdgQOBQ6x9MCR QA7LCBwPHGf7ArmBXJYZOGkF2H5LWNHsqBVjxbCwFWtVZdJKsGpzbtWz/sqD1t+sv/Fa1mXWTby2 1dZqzy+2OlvP8kut560XeSfrZesV3tUabY3m91ljrXH8fut163X+gDXRmsIftKZb03lPa6Y1k/ey 3rHe4Y9as61P+WPWPGsJ728ts77mQ61vre/4c9YP1nr+grXR2sTHWclWMn/N2mpt469b6dZePtE6 aOXxyYIE4+8JIeryD0Rj0YIvF1eIq/laca24lm8S/xA38c3iFnEr3yraiXY8Tdwh7uA7xZ3iTr5L dBBd+W5xv+jOM8VD4iHuiUdEf54lBogh/KR4RgwzmXhRvGSaYoR4xbTEaDHJtMWb4k0zVkwRU8wq YqqYZsaJWWKWGS9mi8VmNfGN+MFsKlaLDebFYos4ZP5NZIsTZhuRJ6R5h93YbmzebTe1zzfvsS+y LzY72S3sFmYX+wq7pdnVvsq+2rzXvta+1rzf/j/7FrO73dpubfawb7Xbmv+yb7fbmw/b99j3mL3s ++0e5qP2Y/YT5pP2AHuA2c8ebA82n7KfsZ81+9sv2S+bA+1X7JHmEHu0Pdp8xh5njzOH2RPsyeaz 9nv2v83h9mx7tjnCnmPPMV+xD9mHzZH2EfuIOco+Zh8zR0eB+MwxUWaUaY6LElFBc3yUE1XNnBhV Paq6OTOqRlRtc1ZU3ai65r+Dtwc7mO8HuwW7mR8Huwe7m58E/xV8yPw0+EjwEfPzYK/go+a84OPB x80FwX7BfubC4IDgAHNRcFBwqLk4+FLwQ3NZ8Mvg9+au4Prgb6YX3BrcZR4NHg8lmuFQg9CYQN3Q uNCMwKjQvNDSwNTQqtChwHuOcBICPzkXODcEUpy7nX8FjjmPOI9bUU5vp49Vyenn9LdinQHOAKuq M8h5wYp3hjujrLrOGGeM1cQZ57xmNXUmONOtC5y3nbetS51ZzofWZc5HzmfWtc58Z7F1o/OF84XV ylnmLLNaO18531ttnJ+dNVZ7Z52zzurkbHA2WZ2dZGeb1c3Z4RywHnQOO8esfs4JJ88a5IRdsoa6 zGXWs67pWtZzru261otujBtvjXQT3ARrvJvo1rRec2u7Da2JbmO3sTXVHeoOtaa5w9wXrOnucPdV 6x13rDvemu2+7k6w5rhvuG9Yc93J7mTrY/ctd4b1iTvTfc+aH82io60l0bHR1awfomtE17JWRedE n7DWEAvCfidyrqt8GzWlunSONrlIpsnd1ExmILylxBRhOVl+hE+WHIGj22RH5FmBUIZ/PkPuxX6H f3S0WH51dq/Mxuf3c6KEeg4Dr5Uq70DgiyIxW1FDvKrltBs8L6TbLHMRdjCTdyIXx2lFZcxvTQl1 /iy3S0/+ghJS0dr00mQsw2aj1Al+6Ttlplwhd/lHh4rVvg9IkdvkWnlM3kJR6LvzqV6h8+HSKpNH cO2yUcLvkqP/YbFEzr4j3yEHKLiGp+TeD+ySyShjKw4DsLMa0zUI1dFnl8uVcgP0B7oDv73k+j+Q b8up+B4OJMmLZF/ZB6FC/ZjfeoQyi+UOy29lOjToW/kT5MB1UL1XNFdB2p9L6QqCn0oUrUOj/BgP Zf+Sr5uFtcKPyUbLD6Hvt8jDsPcrIaoFrkJB7XKfvkL78lMXy58p92CMefk9rlZG9fdvhdOUJref LrnI0RNFjr4vWxnYmuv0vqbJjbh+ttxYSs05hcZ2c7q8lNQfyn+rES2/LbNMRfPvVtqhdLbYmfVl yI2WyRd1aN6p41neV4b80BH5meatreq6lXeT72s2fR/9Wnyzy1RCllykWbOMelFCCYfKrlUl5PYZ Vq6pUO65er9RMcc53/5ahvp3R+YymQs9OlzuGpwznm0C/FPXkj/j7Yh8/PN1SshzHj518DmviJTv +t+rIp8z5G9eYn6/d6ElR8BOR04nMPhzvzwIBtuux5TS6mM6frw+XVt+KZfKdWpGP03+vELhV6g6 +P8uaqtGiB+XgrlhcXEuLsiTWyg8BjNPJbqZuiE8x49LQ++tPv2sml+/1ug3kD8K7NPbZ3IV/4n8 iLicf9r8p2phANZTD8S/6p//Xn6H/v/RPyrO3ycKhUcgd3VqQ8oSSvLjvpALUcJ/Tlv/zpLjw7hi ih9lO3mr7C7b+qmnFcv/LFjsHfkf+atcVyiaUWd6jkYiNIpGq9/M0IfQ3Dk0H9bhYlpKl+hVhUvp G9pAl9Fm2kWtKN0w6G6jm9GNnoRH/0/qo3x56qe8eHqKPcx60dPwxzfRYLaFpdEQlsEy6CW2l+2j 4co3pxHsKMuhkSyX5dIo5ZvTaOWb01j45iEaz+vwOjSJd+Kd6Q3ejd9Lk8155jxSXq2kqYHYQCz9 bH1ufU6/WF9YS2mltcX6jX61pCVpjfLpaK3y6WiTuE20oxTl09E2+HR30Xbl01Gq8ukoQ/l0tFf5 dLRP+XR0XPl0FIZP94pB8ObGGpYYLyYZUcqnMyopn86IUT6dUVnMFLOMKsqnM6oqn85oDJ/ukHEh vDlptLW5HTA62rYdNLrYjh1t3GtXtqsY3e2qdjWjh51o1zQetmvbdY1edgO7kfG4fY2dZDwJr+0B oy+8s+FGf3hnrxgDlP9lDFQ+kTFI+UTG4NDA0BhjmPJ0jIlOjJNgLHY+dD40ljtpzgFjhfI1jLXK 1zA2K1/D+E35GsY25WsY25WvYaQpX8PYo3wN44DyNYyDytcwspWvYeQqP8LIU36EcVL5EYxFR0WH mIiuGl2NBaOPRZ9g6p7CRq0xhtYYBo2ZAI9iIr0JnZ5MsxDzDj6C3qUPMEvNhj5ZWp8s6NMSjLov oFVBrVVBaNUPiP+R1lGI1uPDoGUbYFVvpt9gXaVQKsZYGnSuHqXTQYz4Q/jUp8OUQw3oGD4N6Tid pEYUhkZW1hpZS2sk1xrpaI10oJE9KYb1gl46Wi9joZcpFM+2sq1UhW1jO6gaS2WplMDSoK81tb7W 0PqaoPW1qtbXRK2vVZhkkqpwmP8UB61l2GOjqtBdgTAuPlXnUdDjOK3HNaDHnagx7wxtbgJt7obw vdDpJlqna0GnU8gwt5q7iJm7zXSyzAzTo5CZZWZTbfOIeZQqmTlmHtUxT0L7G2ntr6e1v5bW/lpa +2tp7a8F7f8HxYnrxfUUEjeIG8gUN2I8BDAebkFMK9EKMa1FaxKijWhDtrgV46QBxsltyNsOoyVK j5aQWgEhV9yFMRONMdOR6olOojNVEl1EF2okumIUVdajqLIeRQZG0SPI1VM8jjRPiN6IeVI8SUz0 EX1RSz/RDyU/hZEWwkgbiFyDxCDEDxaDkX4Ixp6rx56h1lOQZrh4GfWOEK/g7GgxGjFjxBjkGivG Is14MQExE8VESDJJTEIMxicF1fhEOVPFVOSaJqYhfqaYiXJmiVlIOVvMRsyHYg7yfiQ+Qj/MFZ+h Zz4XCyHnIrEIfbJYLIZU34gVkPZb8QPKXC2gmWK9gE6KjSIZpW0R26iu2C7S0Cc7RQbq2iP2Un2x T2SiJ/cLjxqKLJGFGg+IQ5A5W2Qj5RFxBGePiqOIzxE5kOSYOI7yT4gTKDlX5KLkPJFHVcRJcRK1 h0UYeaWQ6v9V7QDVUmyCPdgEe7AJ9mAT7MEm2INNsAebYA82wR5sQgbY5CXsh9vDiSlOIVNxChmK U8gBpwzCfnBwKMUoZiEOZtlATmhjaBO5oc2hQxSjWIa4YhmqDpZJoyrOTmcnxTm7nF3kOrud3RTv pDvpOJvhZFCCs8fZQzWdvc5+hD3HQ/osJwtpDjgHkOawcxjhbOcIJTpHnaNIk+McQ5oTzgmczXXy KOSEHUkJrnKtqyj+wt50TewDrkWxYDGbqrlRbpCquiE3hJSO61JN8FoVxMS58ZSo2I3iwW6J2Ndw ayJNbbcOxbl13boop55bH+EGbgOkb+g2RBjch3hwH2LecqeilmnudOSa4c5AyTPdWSjzHfc9qqrY kLhiQ4pRbEgxYKyPfTYcgw/XbBgAG05CeDJ4kGsetMCCHyI8hxZgv5CgbWDDLxH+GhzIaQV4kIMH 14MxN4BfuV6/tzUPcs2DVTUPxmseDGoerKZ5MEHzYHXNg4maBx2jklGJXKOD0QH7nkYv7B8zemPf x+iD/QhjBLlgyXbENEtGgSW7Y69YMqRZMkqzZLTmxDiWyTKpsubBWM2DVdhJdpIqaQaM4SY3KRbc ZyMc5EGqzDvwDlSTd9RPsinuq6W5rw7vwrsgvqt+uk3xYC3Ng3X4ffx+qlHAg+nEwYDZZIP78iio WS9Rs168WrXF+Py7+DtG73XiOuKa42xxEzjOBMe1QlixG9fsZml2SxBtRVvEKHbj4nZxO/Z3iPZI qTjO1OwWr9ktqNktEezWjRxxn7gP+/vF/Uj/gHgA+x6iB/aK6WzNdEGf6fqIPojpC6azNMfZ4mnx NPIOEAOQPp/phiIc4bhnxXMIK6azNdNxzXRBMVKMRK5XxSjEKNazNes5PuuNE+MQr7jP1tyXqFmP a9YzxVtgPe6z3nQxHeEZYgYY7W3xNtIrHuSaBxML8SDXPGiDBxchHOG+JeIrhL8Rv2KvuM8G9yUj rFivqma9eM16Qc161TTrJWjWq65ZL1GzniMOi8PIpbgvXnNfgua+RJ/78sBxXHOcYxu2QTzCVsH+ wacpKjgwOBD7wcHBFAoOBTeFgsOCwxDzQvAFitI8xULjQm8Q04wT5+wH18Q4B51DFKv5JUYzSxyY JQfhY85xqgROCWOcK06p7HKXUyWwiaBozSOxmkfiwCCxCCsGqeJWc6shjeKOOLeWWwvxdXzuqIcS FHfEau6I0dxRWXNHLLjjLZQ5zZ2GXDPdmUg/C6wRq1mDEbvkgFp5vWz3Py6lW+ju09n5/39sMkPu UfCPtpfkd6l1Hr3WV96yd6oVLu15f6mPt+TXqfe/+t5npvI/tS+aLFNletEVndLrzV+hk4+XX8Jz u8lW8DzV92l972I5MuBpf1fxdZmCcjJPPZIH9d6Ph6+YjZ5NlR5QsLJXyBONK5Q7Gak2kVr3qIaQ v8KY713/QVuwQJrC9Tp0j47bV9LqgtxbfG1OHpI75GacKXYXoqJb/ip50SM1fnytLrReANl5QTjz dFdZbiu+qnmutpLv4JSaa5acob/z9Gr49wpqfUi+j9APfpp8zVIj+IhclR9frnp2ah1N/f1YrYLJ lEIpXtXrQWqtfJsO7YQ0hRnK79+yXl+9ap1aerryb9C0QuXKozIPOKHWuuTJIunOdF/qf2z7g8d8 GTY55Swy31ZCeanUFDpY+yxKPfPWlDS3Kj7VnFriBm4o8z3Es58rTimviFSFx14Z838il8q5/v2B ODlNLtWxaWp2Lzx7V8h+2ARu3K7th3Rtm2g2U3OS3I7v2X4qT99v+xFYgU960ZVrzWTVKX9tdjnm gh/kamAKYm+Ra+VPOn5dxIrQd7TvKb+kxSTfU+RIz6Hy40IxD8uZspd8Wa3yy94FsVciboEad8Xv OpK651r8Xuhe+SXaknzuRmq+Pqh5DAyWbxf+QP792cIygJcL7o2oeyyllPzLuZKxoht6ydXfY9X9 5mJn+8jlRdJGvlMwu6UpDalAfeuV1mt7S/eTCmF+2+73GvbyIblSX+8c4iXMYS41K1amh3Gw37+7 xMEc+XedciJnz35++/0+dNH7lflWirK99Ly9Ex+vmO25TdueJYx2jOZzzF0lbafw2dpi5/NOjfHj nyg5nspzH73cm3ywnBkiz1gMly/o7yzNAJ8qIPRvOS8S0ufy7TN9vxNXamEFpPtELgBjfu4fLZcf kHo+aL4KA2BOsNhysES+FZwF9v3J54nI/bPoYmV+Jz+Xy/wy49SRH1+EHaQsv7Q6H0ap3FxwlO+7 7FChfL8yYolrRvtB6UfkGRF//BzSjNxZ3qaPlpG6m/c48BRCY+QkzHVP+aUUerYFPbBYDqiAtPfK wfJt2QuhrzGq35Y9ND+8itnobfTzMjlF/gtza5a6B6hbtkjOkdMjNfuzRqL8+pQy0+UGeJWRkfu3 gpBvd8rjEZTdYi5SdrYe7wVPBRWdpfQ8XeD5ast3u37uofATFxcVfWLlj9qK3sXVTzDtL10S3aJi z1/9EVtRT1b1KnT4cGn8qa/OOfN0y7MVtj8wGpSXtRHfp7nTXZBy79nLK9+Sg+TzcqIOr4K+z1BP yvjzUMRePCI/A5aeXT26pGaRJ1nOqow0uRszoZ4fcU13Qw8LbO7IVZcHYHMcKMkCLHddFbC5C+X+ KXJVIYviwV/8o23++PGl/nPGc0mbfFA+IJfIecT00WDZD2zdLWIRyPnyGI5GyifkFbIBeLSFfEo+ dBZ1RezHumclr89JEZ+24HnDGUXPnstNzjoHZSjt3RBhddi3xa6+Pp8q1/w+C/+5G6TZgjGn1zyh w8pTLPBUIpYuzn4HnOZZ1T96g7yjCo9c2FeL/kx5Tr9htPVRtlPkSVf5JKyjdRh9kXPL9H6LXCg7 ypcRGi1/i8RVsK7vzl7ectaYXfg5r//drcDGPXT2T1eW9Kz7udwi1iHs712Y9c7BikVpzyifMW8Z NUp+pNf291W8pkJb9XNSSpk22EJnbbnKsedCklLq8JkO1u1Zr8ufo6tUWi1psGz/yyPl3G2werLP Wc/EnoUc52K8/4H3IyqijbB7UiM5/V925K+LrNT3GVaeMfOjftq55a/3j94q8huIYmWc9m7IGfLo 1Xq1UhTxhCMrOgX3goNn8o/12m516kVW+evV+SvwKy+ZrueO339Llr8mV1bfLkQ3lb/WP3WLr2jG 8t95IvVUg7ovXeDZy8V6vx/8XOrdiP+1DXb/kdP/ZqJQumP/fVnKtpWNISs6q5f4W6lS69JPEPz+ 20F9x6JAs4IlZspPq9aqalJHjLk/YStqu0dYA95TKTyr78T8Cet98uA5LGsH+SvKJf7i6Dz9Kyd1 B31VCWdLK1v9jmpHfs78kF7h3+HH5Nd5pa7rFLkKHb30e5n5sqjfaxWTSv0qq7m6S1MRr11Oke/K RQW/A/NDyiLw1zRXFcjRvJi875a/viL5K/CkkFyj70r8WHCsnwGCvWmV+U5fGX69d5q6S/xtcil5 dutVKzWTay7QR8sx9iLMEDyTfalnlEp0Tdl+r1lC/oo8/7BW/d5S42jkWO/9VfMzs4PflppFnzeC fh2UqzWmUDXYpHv8u0nbI2Na69rD5Ze0lHZE7rAV8tZlN/mUfE9O1e8NKHimR7aSn5Sz5OV/jMWs ZDx9PTJc0l3lyB3FU+IOln4Xp6KbfkbGZ2Z5CPbEIdhHm2Ty70wkMxGn7hlfLu/Ux59CAzbIznKF OpbL5GvyW7Virs+NL1J2Sn58uSRqK3vJYfIW/0iHoIE9dPhdOVP2hh5MgbW2CDOvSjFPfi4/82dt tTofT830Pef+sqeOizyPOBV29Vvqeqi3JBQ8BVRkLUgez/81f7nkfUO+D1/tTf9opa57iub5lboP 1N3XuTJbfqUTRH617z9h4Gvx38pf65+1/Vd+jV28lh35jBW57/xnbRW5T4UrvZ8KrToUvCGhLHNP FVLP79yuwzWpBXzPujrvLlgdu/RsUoP+KtdjhKpPitwqr8B46UGOjMzrvp+K0Rnxqar5x5/4dyoY FfxiWsd/eIZ26Gcr5ADMc/4KpPy77Aq0kg9SFRmZg/PfoTEYuEFeKdtL/5cN8nv5m35aQo3YvZiT dvj+6wXUVM+cF+hUZ17dKFmuGXIm9u8XHC9SvlyRJyvu8AMd6Z90OV2i3xPTSJ8p3PZgeI0MhXP0 TLlEPiI/VXOYHCKfUyGUOqJItZFnwB6pgLw95WNo/2P6wEaop+bN5/RMvRrXMj0c+SX9fP1WkPxN 96x80i+jDD5eiXXvKT1NsTyZ+okAZSdobdLavBzHpj7tnNHeUbkq0VWQntHaUt5j18F/j92zdLPB jKrUXb+drr9+O91w/Xa6EUYHozONMR4yHqLX9HvpXjf6GiNokjHSmEhz1NvpaJF6Ox0tVm+noyXq 7XT0hfGVsYqWsWasOa1kLdil9Kt6Ox2tZUksidapt9PRenYza0UbWW/2JCWz/uxp+o2NYeNpK5vF ZlEqe4/NoTQ2j82nfWwhW0j72RK2lDy2nK2gg+wH9v8oO/+wqK573a/ZM3vPHtj8EIkBRGIIQURC EAkSBIOEEGOsocYYjzXMMAwzBoZhGGYGmRn2/JLRWGustYZaa6yxHkOsscZaa73WY621xuOhxhpr jSEej7HW47XWGmusue/6DiGePs99nnvjs17W891rrz0zwHd93j9481v2V+HfhRPspjAo/I7dEj4Q PmC3hdPCafZ3raJNYne0qdo0dpcnzLEvKGGOUcKcqM3T5mn0lDAnU6pcorZcW65JolS5ZEqVS6VU uTTKkxutXaj9hiZd26g1asbwv5XTZPDUN00WT33TFOt+pjugWchT3zRmnvSmaeFJbxqrmCqO0tjE dDFT8yrPe9N0iOfETzRenvemCfC8N00vz3vTqDzvTRPieW+amPg38XPNMp7xplnFM940b/CMN82b PONNs4lnvGm28Iw3zTs8401zgGe8aX7JM940g9IrUkzzIU93EzQ83U3Q8XQ3QeTpboKep7sJsrRJ ektI5rluQhrPdRNG81w3IZvnugmP8Fw3YYL0W+mMMJEnuglP8kQ3oVL6VPqzUMUT3YQZPNFN+BpP dBMaeKKb0MoT3YQe/vdxgioLsiAEZUnWCyE5UU4UInKKnCpE5XQ5XeiTM+RMISaPk8cJy+WH5Vzh NZ64JnyTJ64JK3nimvC6PFmeLHyb564Ja3jumvAdnrsmfFeukWcIb/DcNeF7PHdN2MBz14Qf8Nw1 4U2euyZslq2yTXiL564JP5LdslvYxtPXhLd5+powwNPXhHfk1+TXhB3ySnml8K78urxa2MnT14Rd PH1NeI+nrwk/5+lrwi/k9+QDwn75oPyBcFQ+LX8onJP/IP9ROC9/JH8qfCL/Sf6rcJWnsgmf8VQ2 4bb8hUEj/J2nsgl3eSqb8A+eyqbVGDINOdoknsemHW3INRRo0w2TDMXasYZSQ6n2IcMThie04w1T DdO0DxuqDbXafEOdoU5bZKg3zNQ+ZphleF5bYvia4QVtqeFlwwLtEwaHwaWdmjA+IU9bxdPdtDN4 upv2OZ7Wpp3F09q0Tp7Wpu3haW3aME9r076WOC+xWfsO/6s97S94Wpv2V4peSdEe5zlt2t8r31AW a6/znDbtPZ7TptPxnDadnue06RJ4Tpsukee06R7gOW26bJ7TphvHc9p043lOm26SskV5R1fEc9p0 ZTynTVfJc9p0T/GcNl0Nz2nTzeA5bbrneE6broHntOm+znPadPOUT5QLuoU8ZU23iKes6V7hKWs6 M09Z0y3mKWu6Np6ypmtPFpJlnSNZSU7WeZLTktN1S3iyms6f/FnyZzo1haVodEEmaC6g6yXD8aWw VKZho/BPy9JwDutYBs5uEaf6o6jn45+eTcApKLMidEkD+uE0pqAf8v/Pw3T6P2DwjplMHTMFHXM+ 7noZ/0ahb76CHRtZM6thFvTQGeihLpBDF/7VMjdbwh5gPfg3hvmYiicH0WEz0GEVlqlJ0iSzLPoL 4bGaVPTcx9BzJ6BSoClgJZqJmkLUJ2kmYV6EXpxJvXgyevEL0AZ05GcoLzRT8wr6cin15VLqy1PQ lwOo92qWsTLNcs1y7PkaOvVYdOrXWblmtea7bKpmHbr2ZOrak6lrT6auXYKu/TbmA+jdJejdv8Z5 cERzhE3T/EbzPqvSHEc3r6ZuLqCbl0GfQE+XqKenUk8XqKenUk9Pp57+NPX0x6mnV1BPz0ZPf5s9 JAwIA2yc8I7wY/awsANdPpe6fC51+fHo8vuh/wu9Pod6fR71+nHo9f8OPYGOPx4dfxD6O/T9HOr7 OdT3H0HfV9ij2iR0/3zq/gXU/Seg+2ewQm2mNpNN0mZps1gdPwkwx0nAJuIkmAAt0E7EXTgPWBE/ D3BXpbYSOk07DVertdXQ6drpWIOzAYqzARX+t9bP0t9az6S/r36W/r56Jv1NdT3OiSCbrgvpljEN TovVLEX3bd069qTuDV0/G637nm4jq9S9qfshe1C3Wfdjlqnbofspy8KJ8jNWytNEWRk/V1gVP1eY ws8VaKqYymaIo8RRbDI/XVgpTpdTTCv+Xvw9Gy+eFk+zFPFD8UOmE8+If2AiTp1zqHwkfoTKefE8 04sfix8zWRwSh9gD4ifiJyyRn0ksiZ9JWHlZvMxGiX8S/8TScDL9mWnEq+J/44nXxP/NRovXxevs QX5W4Yl/E//GMsRb4i1WLX4mfobXdlu8jdfzd/HvmN8R72D+ufg5my7+Q/wHdr4nCWy0pJV0bLok SiLT4ITTMxwWksySJIOUwFKkRCmRaSVFUliGlCQlsWopWUrGGpyC/P/qLo3GvenSA7g3Q8rE+ixp LEuTsqVx2DlHymE8AfVhaK6Uix0ekR7B+jwpD+sflQqwfqI0kT0oFUqFqE+SJjGdVCQVsWTpMakY +z8uPY57S6QS7DZZmow1pVIp7p0iTWEKP3HxrKnSVNQrpEqsnCZNww5VUg0TpRnSM1hZL9UzvfSs 9Cxe8wvS1/G+5kovYf9XJBOe3iSZ8ZRmyYp9bFIbq5HsUgebITklN57okbysVuqW0D2kHsnHxkh+ yY9XG5BUvJegFMI+YSmMHSJSBDtEpShLlJZKS/GUPqkPa2JSDE8BAbCxnABYCQjg26xMWiOtYVM4 B7BMcMAbuNov9bMs6XsS+oD0fen7rEraIG3Ap71J2gT9obSZlfIMWKwHK2CHd6R3oNsl/JRKO6Qd uPddaSd7RvqJ9BPsvEt6D1f3SHtw78+kn6G+V9qHlb+Q9mPlL6WDuPpv0iFWDsI4gvpvpN+wYnDG b7H+mHQMlfel97HyuPQfWDkoDeL1/E46iTUfSB/gFZ6Sfo/XfFo6zR6TPpQ+ZFOlM9IZ3AtGwV3n pfPY+WPpY9z1qfQpdrssXcH6P0t/xvq/SH/DmlvSLXwan0mf4bXdlu6yTM4xbAo4JgnzZP0oVqZP 049mY/Xp+gdZuT5Dn82m6sfpx7PJoJwJrEpfoJ/IntMX6iexafoifREqj+kfZ9X6En0Jdpisn4yV pfpSrJmin4KrZXp4R7DRk+wJfaW+Es+app+G9VX6Klyt1lfjWTxTQMOZiZVyZoKCmaBgJiiYCQpm goKZoGAmKJiJZXFmYmM5M0HBTOwxzkyYg5lYFWcmlsmzalmxPEOegbtATqiAnLAG5AQFObFyTk5s KsgJTkC2yTZWDX7qYCmyU+7EGlAU7gVFoQ6KwsqQHMI+YTmMeUSOoA6iwusBUWH96/LrrExeLa/G XeAqNgVctQ6VN2T81Mn98vcx/1f5X/GsbfI29hwnLVRAWiyBkxYUpAUFaUFBWtA/yX9hT8k35Bt4 yl/lv2IfUBcr4dSF+RfyF/z/vWVg7BmDxqBhmZzA2FgQmB4qG2T2hAH/sRJDgiEBc8WQDE0x4Pw1 pBpSWblhlCENldGG0azKkG5IZ1MMDxgeYNWGMYYHUc80ZLIyQ5Yhiz1mGGsYi3m2IRtPGWcYh6s5 hhxUwHaYg+3wSsB2ULAdFGwHBdtBwXZQsB0UbAcF20HBdlCwHRRsxxI427GnwHYvstSEeQnzmJTw UsJLmM9PmI/5ywkvY74gYSFL5+SHyrKELUxI+FHCdszBf5iD/7AG/Ic1f0/UMCFRSMxiT3MKZBXx 7AZOgUzgFAgFBUK/oXyDjVMWKYvYeOUV5RU2SmlUGtlDilExskcUk2JiuUqT0sS0illpwdyqWLHe ptiwZrGyGGvalDbM7Uo7y1McigNrOhQn1rgUF652KW6WA7LsRn2JsgR18CU0oASgvYrKspWgEmIP K2ElgpVRJYqVS5U+PHG58k1UViqrsDMYFE9Zo6yBfkdZizXrlDfwmvuVfuzzPWU95t9Xvo/1G5QN mP9A+QH23KhsxNU3lTfZBGWTsolN5OTKCkCuW9gk5UfKj1idslV5G/MBZQBr3lHewdV3lXehO5Wf sCJll7ILV99TduPqz5S9rFD5ubIPlV8ov0AFvAsF70L/TTnEHlV+pRzGml8rR1i+8hvlN1h5VDmK pxxX/gOVQeUk9gQNY//Tymnoh8oZrDmr/BFXzynnsM9HynnMP1Y+ZmWg5E+w2wXlApvAWZnlgJUj LDspmrSU5Sb1JeFTAjcvZ0VJryXhs0pambSSPZT0raRvofLtpDVsUtJ3kr7D6jhPowKeZkWcp1k6 52kmcJ6Ggqeh4GmWznmalYLsaoin64mnBSLpODd/Scycj5OJj5PZv+BfMpHxTCLjWUTGaUTGs4mM xxAZP0hknEFknHlffo9I+T0y5feIlN8jUn5PAuX3iJTfI1J+TxLl94iU3yNSfo9I+T0plN8jUn5P CuX3iJTf8xzl9zxP+T2jKb/na5TfM4fye16g/J4Gyu/JAqkngpuTNEnE6JnsCU2WJgsMzUm9AqT+ AqskFn9R85LmX1DnLD5NY9VYQdgejQfq1fjAzQEQ+VQQ+XJWDRZ/DfNvar6J9ZzIp4LI32A1YPEN bAYofDf0p5qfslrNHs0vcZVT+MtE4U8ThdcRhT8DCi9hWqJw7X38rQV/P038/Rz4+3micJ4wpKOE oVGUMDSKEoYeoIShUcToXydGf1J4TVjBpvNkfzZvmNQ5l08S3hXeZROFveDyR4jIHyUinyC8L7wP /uYs/rBwUjiJ+u/B3w9TatE44Q/CRyDyj4WPoTzBqIhS3QqFi8J/ofKp8CmUZ7vlULJRnvDfwjXM eb5RvvAX4QbmPOWoQPhcuIs5zzp6SLgnfMFyKPEoV6vRCpjz3KN8ragVMefpR7mUfpSnTdQmopIC +i8m7i8l7i8j7p+rHavNRp3Tf7H2EdD/49p80H8x0X+JtlBbiHmRtgg6WTuFTYETmIp5hbaCPaZ9 En6gmPzAZG0V/ECx9intU9if+4FicgIvkROYT07gJXIC88kD1IP+17FkcP9GlkbEn0HEP5aIv0K3 B8Q/DcR/mFXrfq07zmqJ++vuy2QSKZMphTKZRlMmUwM5gVnkBGZQPtPz5Acq4Qc+YBJ5AL34B3gA iTyAnjxAMtG/nug/Q7woXgTlXxI/RYVzv0TE/yAR/ywi/jQi/gwi/kzxpngTypm+npheT0yfRkxf T0wvSBKYXk80ryeazyRqryde1xOppxGpZxKd1xOX64nLM4jL68Hi8L1SMYhcIhZPIxavH6bwMqkM 68ulcqznLF5PFB5nbj1xtp7Yeiax9Sxi6zRi69nE1mOIrR8kts4gts4kes6UVkorwZTfkr4FmuT0 XEnEXCWtk9ahzon5CSLmGdJGaSM4krNyubQZrFxFrDyWWLla2ioNgOPfASWPJUp+kfi4Wtot7cZd nJLLiZJfBCXvxb0/ByuPJVauIFauln4lHcYOv5Z+jfWclcuJkscSJVcQJVcTJddJJ0HJVUTJM4iS y4mSq4mSa4iSnyFKfkL6SPoIVzkfx8n4CemqdB0VzscVxMeVxMcvSvekeyBUTsZVRMbVIOMHMedM XENMPEP/sP5RVktkXEdk/DKR8dPEwTOIg18mDq4jDh6rn6qfCuUE/AwRcJ3+Kf1T2JMniqVQlphI WWIplCKWQiliIqWIJVCK2BxKERMpRUzUz9XPxdN5lphIWWIplCL2PKWIjaYUsQZKEcuiFLEsShET KUVMpBQxkVLEUihFbPR9KWIplCKWQCliKZQilkUpYiKliKVQiph4X4qYSCliKZQiJlKK2GhKEcui FDGRUsRSKEUs674UMZFSxFIoRayBUsREyg8T78sPEyk/LInyw1IoP0yk/LCG+/LDRMoPS6H8MJHy w1IoP0yk/DCR8sNSKD9MpPyw5yg/7HnKDxtN+WFfo/ywOZQf9gLlhzVQflgW5YeJlB/2POWHzaH8 sIb78sNEyg/LovwwER5mNKuEY3mUzSB/UitPkCfAGxTIBWD9SfIkViEXyY/BbxTLxaiXyCXDvqVc LpWnsGfIvZTL5XIFlHuYOnmaPA37cA9TK9fLz0Jnys9jt9ny17BmjjyHPSG/ACdTLTfIc+EQXpZf xlXuZ2pko2zE6zHLZtwVT2LkDqcODqcVz+IOJ1nulF3Yp0vuwl0e2cOelrvlblR65SDeBfc5leRt xlJyYzk5nCp5lbwKyn3OM+RzquTvyugS5HPKyeFUy2/Kb6LylvwWns7dTh25nZflt+UB3MU9T7X8 Y/nHWPOuvBP6HpxPonxe/k/of8HzJJLneZY8T618U76JnbnnqZQ/lz/Hu+OeJ5E8z4vkeWaQ56ki t1NObqeS3E65IQkOpwoOZxSrIYdTRw7naXI4z8DhjIELetCQgZWZcDgV5G3Gkp+phZ+ZgKcUws8k ws+UQcsNldBqeJhE8jCJ8DAvQLl7SST3kkju5Vm4l3nDjoV7lQXwIQvJsSxKWIRKc0Izm57QmtAK tSfYoY4EB9SZ4IS6E9xQnkU3irLoRlEW3QOURfcAZdGNoiy6UeR8tORtvp44NjGXPZk4K/HrbHqi JdHH5lFSnY7cjg4OZxJcBPcwk8jDTFRa4GEeVl5VWkHq3Lc8TI5lEhxLB+ZOpRPOwat4UeFe5RHF r/hR6VWCcCncnzxK/mQS+ZOJ8CcrUPkmXMpEcikTlNeV17Ge+5NJyneVdbj6BvzJBPiT72E37k8e JX8SdyaPkDMpVn6o/BD6lvIWlDuTMnImc5W34Uwmw5lsR/3Hyg5WQs5kMjmTKeRMyuBM3kNlt/JT 9piyR9mDlT9Xfo469yePK/vhT4qVA8oBXD0MZ1JCnqSMPMlc5ZjyPq4eV06gzp3JFOUD5QOs5J6k TPmDchb1P8KTTIEn+Qi7nYczySFnUqIMKUN4LvcnpeRPHlf+UwHjUTpgEeWRFipXlKuo8KTAXOWa ch1znheYT3mBuZQXWER5gbmUF/gQ5ZHmKP9Q/gHl2YFFyhcKCJASBPMA5iBAyhF8iLJJcyhNcBxl k+ZQpmA+ZQoWUTZpYVJyUgrqPF8wP2l00mhUeMpgAaUMPpSUkZSFqzxrsIiyBvMpa7CAsgbzknKT cnGVJw7mU+JgLiUO5iW1JrWyh8mJPQonFiYnhp+HpGVJy+DQlsN9PUruawr5rrnwXd/FfF1SPysh 9zUlaX3Sesx5cmE+JReOo+TCIkouLKDkwnxKLtQxzdgb2SHAr6JdwT5mzLQQw4RhxbBjuDCWjHzV OAfwVcVYirECYzXGOowNGJsxtmHswNiNsQ/jIMYRjOMYJzHOYJxnQugYDWa6SEMIDWKcxvwKxnWM Wxh3GWsSMGSMZIx0jCyM8fHX0JT/f/laFN+rqXR48HsqMKbTNdZUhzEr/nrpns3x99jUgDEfY1G8 PvxVCJ2joXHuxNiD+YWRWnxcxrg2PD+NcXN4fic+wmx4SBgKRhpGBkZOfG04j9azJjPG4vjn1OQY +czjawtpHWtyY/gwQhix4fewMv68cMnwe12D0Y+xcfj6luHr5cOjCjV8H5v4+9mPcWjkvcTf8x6M /RiHMI5inMA4hXEWYwjj0vDXq/d9/XL9DYzbw1/PDt93+77r9xgz6zASMFIxxmBkf/WVf//MuRgF /89fhXDtV98r/t7MxcPf6//fkfU/B/18r4g/h36usuLr6Ln3jzKMyq++juwR31cIz0S9BqN++OcP 18yzv/pqnouxQDeqcah9Vu+gaWkHI5VIFeiKjjTo6o4M6LqOHOiGjjzo5o7C3kF+V3CRaVtHSdDc eKm9ofd049X2+b3nTDs6ykmrRua7O2p7z/GrwcWNN9oX9V4w7euY2XshPh/W2+3m3sumgx1zSOdB j9D8CM2PdyyEnuwwQc90WKHnO+y9l/ldQQd0Meb32h2910wXO1zQKx1LoNc71N5rvB50G3Xt7t6b plsdS6F3O1YEfcaEdl/vnSahYzXpOtINULmpDprcsRma3rENmtWxAzq+Y3fvHX5XMNSU37FP3WBM bQ+p+GQ7DqrMOKY9pkpcgzFjdvtKVWkq7TgCreg4riq8ElwZrw9rbvsaNc1Y0N6vZjRN7zg5onUd Z9QMXg+uGdbi9o1qTtOsjvOkF6ENNJ/fcQW6qOM61NxxC7q44+6IOpxCsL/J7ZSDG41l7VvUvCaf M1nNo90KhyshZ/qXyivBLcbK9gG1pCnmzCId/+Wc14MDxpr2nWp500pnvlrO58GdxhpnEeb17XvU qqY1zlLSipF5v3M6dKOzDrrFOQs64GyA7nTOp/kitYrfG9xjnN2+X601zm0/pM5s2uM0j+h+pzm4 v+mQc7E607ig/ag6x9jYfoJeg4PUPTI/6vThlVjaT6nzmk44QyN6yhlT5xlb28+qC1892BMijZGu hB7pWQM93tMPPdmzEXqmZwv0fM+AupDf1ed79WLPzr6Q0dk+pJqM3vZLqvXVKz17oNd79pPy+a2e Q6qVX+2LGQPtV1Xp1bs9R1WpVWi/2rcyrsZI+w3V3ir3nCA9BU2meTLN03vOQrN6hqDjey5B83uu qnZ+V98a6G3Ml7ffU12tRT03oKU9t6EVPajwel+/cZVDpy5pne7jWudL6NtoXOtIUNXWWb5Urq0x mo+BNviyofN9udBFvgKo2VcMXewrU1V+V9+WVoevsm/AuN54QV3a6vbVqEuNmxyp6gqu4TzjVscY dXWrz1cPDflmq6t5pW9nvD6s2x3Z6jrjLkeuuqE15ps7oit9C/C7g3rfnmHd6yhQN7eu8TWSWkbm /b5W6EafE7rF54UO+ALQnb4IdI9ved/+1v2+VUGz8YCjWN3Wesi3tu8Q7bZjuHLUtx56giuv9B01 HnaUqbtbT/k2kW79cs7rfSeMxxyV6r7Ws77t6j4+7zvVOuTb1XfWOOioUQ+2XsInD/XtHZlf9R2A 3vAdht72HYPe8w2qB9t0vtPQBN859SC/t2/IeNpRrx4xnnPMVo+3pfou/JOO8V1WjxsvOOaqJ42X HQvUM23ZvmukN0fmub476hnjNUejer6twM9GtNgvqeeNNx0W9WLTWedK0jXQIZpfcvZDrzo3Qm84 t0BvOweg95w71Yv8ruAhs865J3jUeMfRql4xMYdTvW5OcO6HppKOIc12HlKv86vBEybJ4VVvmSTn Ua58bs51nggmmxRHQL1rLnCeIj37T/Ni5xC0zHkJWum8Cq1x3lDv8ruCp0xpjkhQMGU4lgdlc73z NnS28x50bqcOuqAzISibchyrgsnmRlJLZ2rwrCnPsTaYbm7tHEOaTZobTDfldRZg7uwshno7y6CB zkpex/ohc6SzBpXlnfXBS6ZCx/pglnlV52zo2s65wSxTiWOTepJr8Kp5feeC4A1TuWMr1m/qbMQO 5Z0WrqgMxevDWuXYHhxvqnXswmvb2tkK3U66q9OJT4bXb5v3dnpxetLcNNOxN5hvPtAZII2M6OHO 5dBjnaugg51roac710PPdW6CXujcGrxnvty5PaTDPgeCRaaczl3QWsdh6BzHMbzOa517oTe5UmXI NM8xGCw13+k88D+V10OwrZ2Hg/nNUuexUKppoeN0sKJZ6RwMVvB5aIxpYScqJpPjHL2vuF74ct6c 1nkZmtF5DZrTeROa13kHWuhi0BKXhPfO771tsjouBKeb7I7LwbrmcpfyT1rlSgvWmVyOa8FZpiWO m8GG5lrnGq6ujBGd6coJNphUx53g/OY5rjzoPNKFrkKoyVUSyuZMEspttrrKwSdgg1BBs91V1Xu5 2eWqhS5xzYyf4KFifg6GyppV1xw1p3mpa56aw0+iUGXzCtdCfiq5TFCcNaGa5tUuq1revM5lx/mC 35dQffMGl0u9yH9uQ7ObN7uWqHebt7lU6A7X0vjPWGgu//6GFjTvdq0I5ptmulZD8TmEGpv3udbx z8S1ARp/pwddm6FHXNuCDXTiXGor8ys4fXjnv9pW6U9T7W01/gxovT9nuD/f4F2u73bbbH+eutm4 118I5X3mXttcfwnvOf5yKDpJTNe2wF+F7tHor1XP0E/+UPNx146Qpfmka3eotfmMa1/I2XzedTDk bb7oOtJ7rvmK63jvhebrrpOhANacwZpbrvOhSPNd18XQcovguhJaZZFd10NrLcmuW73XjLNdd9Va S3qXEFpvyeqSQ5uMC7qS1TmW8V3poa3Ggq6s0HZjcdd4NceS35UfPGop6ioK7bKUdpWG9sZ5w1LR VRE6YJneNb13kBNF6LClrqsudMwyq2sW/y50NXx5slsauuaTLoLOx2sbtCzqModOW8xdi0PnLIu7 HKELFkeXO3TZ4u7yha5ZfF2h0M040zYJXTFQXJyjiFIsoa6VYFfiRkusaw10ZVc/KI7/bNxpMndB LWu6toSZpb9rICxZNnbtDCuWLXylUde1p/emZaBrfzgtTm6mDV2HegctO7uO4necGNWyp+tE7+Wm rK5TvXcs+7vO4umLu4bwORzqugQ92nVVzbOc6LoBBhvouo3Xc6rrHvSsWxdaZbrlTsD+Q+7UcIbl kntMaJB/AuEcy1V3dvxnO5xnueHOxT633QVqueWeuzhc2KJzl4VL4oTZkuCuDJe3pLprwlX89yJc 2zLGXQ9KB6uHZ8a1Jds9O07g4Tn36TzShfQUE6m1Jdc9t/dyS4F7Qe+1lmJ3Y+9NTtRhe0uZ2zI8 d5Eu4b9fYXX4kwQPh5eSruCvKry6pdLdGl4dn5Oua6lxO9W0lnq3FzwMKg5vaJntDsQZOLz5Pt0G UnWreS1z3RHoAq6cWsM74trS6F4eJ9Xw7haLe5Va0tLqXgtFHRWne32cWkM1X2l4H/+tDx8kPRLX Fq97E1gURBo+3hJwbwV5gkvDJ1si7u3qnJbl7l1Qp3svmPOE+wDYkn9fzsS1ZZX7cPi8Odd9DL/d vDMnt6x1D+L0zHWfxny9+1z4oinHfYGfCO7L4Sstm9zXgjdatrpvhq+3bHffCd9q2eVh4bstez1S RBju7dS9TQs9SkRuOeBJQzde4smIJMc7YcthT04kveWYJy+S1TLYWR8Z33LaUxjJjzOAudVTgrOA TpmWc7xvx8/olgue8khRy2VPVaS05Ro/bVtuempx6qFrRSrMg56ZkYqWO85TkenmtZ45wSwr88yL ZA2fy1s9C4PJVslj4izhsaoXrYrHzs90j0u9a03zLAmmWzM8Kp57zrOUn18e9EBrjmc16nmedcH0 5hLPhi9PCmuhZ3Okzlri2YbXBpYIp1nLPTtCg/zdRWZZqzy74502eMpa69mHfWZ6DuIUwJkbabDO ceyKzOfnVGSRdZ7nSMRsXeg5HllsNXlORhz8c4u4aR+f1eo5EwlZ7Z7z8Djo4ZFYnHa4hhrj+iXV OLyRlVzjlcga0n7+GiIbSbdYXZ6LQcG6xHMlKFtVTiOcTEKN1qWe6/E5zjso7sJZEBngXTcyYF3h uRXnisjOYcW7CM21rvbcxXlBc3pfA9Z1XiE43rrBK4MowBWRPdbN3uQ4ReBVjWik37zVmx4ssm7z ZkF3eMfHT3zsA43st+725sdP+cgh6z5vUbDUetBbCkUdlSPeivgpHzl6n57g51TkFGk/6Vnrce90 nN04wSND1pPeOpzUOMcjl6xnvLOCs6znvQ3Qi975OMXmeBcF59NnfpX0xvAnc8VrDlZYr3sXB+us t7yOYIP1rtetXrQJXl/kdpvFPzOW0Nbqn7N0TpvTPw/q9S9UV7cF/CbV2hbxW1WpbbnfHkvFGheu rvIviY1pW+tXcXW9f2ksu22Tf0Ust22rfzXc0Cb/OnVF23b/hliBca1/s6q27fJvixW37fXviJW1 HfDvjlXixNynbm477D8YXd52zH8kVtM26D8eq4+7A+Mx/0l1X9tp/5nY7LZzvl2xuW0X/OdjC9ou +y/Cx132Xxnh8Gv+67HGtpv+W5jf8d+N7rKzgBCz2KWAHGu1K4HkmNOeFkiPee0ZgaxYwJ4TGB+L xB1o66xAPjxX3OmQp7DnBYpiy+Muz16IisteEiiF58JZH1vVuiVQEVvVVhCYHltrLw/UxdbbqwKz Yq2tRXylcVWgQV1irw3Mj22K+6xXDwYWfeln4x7TPpN85azWS9zxBcwjTx8ILIaSV7LPCTjgmOIe 5x485kH7PP/1cFXr9IAb+y8M+GJb7aZACD4Ln0Bsu90aiA2zyhq7PbBS3Wx3BdaoZ+xLAv2xXXY1 sDG2N+4H7UsDW2IH7CsCA7HDnHNix+yrAzvhqeGsY4Okp+3rAntwasBB47yAxs5xDZKnjl3gT4ld jqt9Q2A/3tFmeC6XfVvgkLqE+9/YNfuOwNHh+U3SO5yXlrHhTxLudZk0rHhVyxT77sCJZUp8Tppm 3xc4pa6zHwychXuFh12WYT8SGIo71mU592le69HAJXxixwNXoSe5co8ZWhBX+5nAjbivXFZoPx+4 re62Xwzcg6KOypVeXdxjLiu5T8s5xS2rIq2Nq/16bwKcI/zjspn2W72p8Ilwkcvm2O/2jlFPtgu9 2VC5N1c9057cWxBr5N+XZfNIFxpX9RbHrrWn95ap+9qzeivV4+3je2uwMr+3Xl1ok72hyD3yDnQe Ue+CZ7Ele2NRnS3duzKaYJK8a8JptixvPz87vBujqbbxXDHfEh1jy/cORLOhO0e0yLsnmmsr9e6P FtgqcJcc93S26d5D0WJbnfdotMw2y3siWmlr8J6K1tiyeP8kvW2b7z0bvs67ZbSedLY54h0KptsW eS9F59rM3qvRBaZy743gkG2x93a00ebw3otaSFt5n4w6h70VNOq1ubt10UDcZ9l83QnRiC3UnRpd bot1j4musq3szo6uta3pzoX2dxdE1/OeGd1EutW2sbs4uh1aFhRsW7oro7tsA9010V3xM8W2s7s+ ute2p3t29IBtf/fc6GHboe4F0WO2o92N4SrqorLtRLdFtdpOdbdGB21nu53R07ahbm/0nMneHQjW 2S51R4LTbVe7l6u74ycU1+gFk4rTEPPuVRFfnNxaUrvXRi/bbnSvj14zse5N0Zu2291bo3ds97q3 R+7Zirp3RXP/D3vfAxXVde67z2FmmBicICFKCaGEGEIIsYZYyuVSYi1anH8SS6zXUDNlzsycOXNm mP8MXkvUDC5KvRS9xlqfMT6vz8cjlmtdXmupMdZrrJfyLKXWcl0+FqVeaw2L8gylXmvN+77vnMER SbXr3rvWW6td3/p9Z7PPPvvsP9/3+/bZnjOKmsZjbywQZzWeiDMxvfF0XCfObeyNp4k5jf3NHWJ+ dGc8I7k2sbDxQjxLXNB4KZ4rLmocic8XyxuvxovExY1j8YXissaJeKlobrwZrxBXxlh8ibg6potX i2tjaXGrKMQyQEuxrHiGqv2x3ObLYjQ2P14rro8VvbFJ3BRbGF8jtsZK4zaxPVYRd4rbY0visrgr Vh0Pintj1ngM5zfeLB6wxeJx8WCsNt4m5sSA88XDMVu8Q5k78VjMGd8hnojJG9rF07FgfLfYG4uB 7o81x/eJF+DSTvFSrG1Tpq06Bk9Y4khsB+irsd3xbnEsti9+RJyIdYK+2Vge73GzWPfGIbcudqRZ 506L9cRPujNiJ+Nn3FmxM82yOzfWF+9zz48NxAfcRbHB+KB7oa9/Y4W7NDb0Rrm7InY5PgQlr0HJ JbHx+GXlLu7q2GT8mtsau7Wh313bxMfHbTqxsHnSvaZJH5+0VTQZXs9z25oy47fczqbsFt4tN+W1 6N1BcX2L3lbbBNHZHWsqboG1XFPJ66vczU1lLZnueFNlS7a7ramqJc/d0WRsKXCVNNVsHEfdUqw8 9bt3NK1qKXHvbqprKcPVS0slrlJaqnAXpcWoeBztYGxRdyru9o4T6l4B7Qy01Lj3NdW/UYjxvWUV PoO31KE1ttQru0PEDzfcndGdUD+txNzdTeLr510FTb7Xz6u7N7Sv4j7i87eIrutN4Raf8tTv7mla 1xLGud6wkvFsHjfO/V/GuN9yk4znbnK/ZxruI55jOl7L69hD/MN8GnuYT+fnsNn8Y/xc9gifzT/O 5vD5/FPsUb6Qf5Y9xr/Fv8XmpVSnLGdZ2mXaL7BsbVAbYjnaH2h/wHINIOyThjyDheUZagx1zGp4 zdDCXjVsNbzHNhnOGkbZdwxjhkl2AVrzMtPQ/35gYI+wh9gcVsseZqtYPVvBBPZ1Vsf+jrWzOOtg P2Wb2c/YL1gv+yU3i/2cS+Nms4+4R7jHOI7Db5z0+N4kN49bw7m4HM7NbeaKuFZuO1fN7eTe4l7h /on7MfdqyrdTvs1FNWFNhGvUbNBs4po0rZqvc+s1WzVbuQ2ab2q+xW3UvK35By6u6dYc4r6mOar5 HrdF857mPa5D877mh9xW+h5zu2ZA81Pum5ohzTD3Lc0Vza+53ZrfaH7D7dX8VvM77r/jW3Tcfu2j 2ke5/6n9qfY216nT6uZz53XP6J7hJnTP6hZwv9V9RlfO/R6/8OA+0n1eV8VrdMt0Fl6nW6Gr4w26 r+gEPkfn1AX5PF1E18w/r/uarp3/jK5Dt5v/rO5t3QHeiF9O8Ct13bof8V/UndOd4wO6ft0gH9Rd 0l3i/1Y3rBvm1+t+pbvGfxXfx+I36j7UTfCbdZO623xrKkudzW9NzUh9jH87dV7qU/w/pBakfpo/ lPq5VJk/mRpK3caPpr6Z+mZKWuo3U3enzE59J7U75VH8f1VT5qV+N/VYSk5qT+oPUnLxfaCUgtSf pQ6mLEq9mHolpSz116m/S1mqL9AfTqnVf/jQkym/MPze8HsNfi8ns1bQaSwXvzZeckiFHlDMCuT6 6huyWFW9/ELVQtknh+V11cPyBnlzlVzTIR+Vj8unqnrks/I5+bx8UR6Wr5hnmfPlLeaovG2pcako 75T3yPvlLvmQOX9pFViVBmx8nGz8t4zjPuI+YjxYdDpLgXNP0JuojH+Hf4dx/Lf5b8O5Q/x3WAr/ Lv8u09KbqDr+x/yPmZ6+BHuI/yl/ns2id1DT6O3T2fwv+F8wA713+gj/G/434B34ZmlGCpfCTf2v wdoUHZtLX45lpcxNmcs+kZKVksWy6U3Rx1MKUwrZE/RVWG5KRUoFy6NvwJ5MWZzyOZZPX8XMp3c2 nob2p3EZNHKomec0W+857en19HsueC55RjxXPWOeCc9NmXkmZJ2cJmfIWYRceb5c5BmTF8qlcoW8 RK6WrXKtvEa2yU5ZloNyTG6W43Kb3CHvkHfL+widcrd8RO6RT8pn5D55QB5MFu8qeUi+LF+Tx6dk Ur7l5b36JDF4M73Z3jzILbhL6rwFULbYW+Itk28lxFvprfIaQaPUeOvlca8IZX3eem/Yu867wbvZ uwXqLPBu8+707vHuh/5zD8kqa+A363NoTLJAUlgOiIYVsGeYlhWDpLJPgehZOchDrAJkFqsEeZhV saX0drkJWAe/u3yE/Q1bw9LZWpAM4B2BPcpEkEwWYmH64nIdfWv5Or1R/gbLBj7ayh5n3wR5gv03 kFz2P9gB9kn2DsiTrBskn30P5Cn2fZD57F2Qp9k/s9PQvl6QQvrfsJ9lg+xfWRH7PyDF7Jcgz7Nf gSxg19mH0PYb7N/ZC+w2yIscz6WyRdws4L5yen/8r4H70lkFvT9eyeVyT7KXuKe4p9jn6XvPKmDD Gvqicw1bxn2Zs7EvcPVcPTPRu+Rm+rrTwsmczKxcA9fAVnARLspquK9ym9hK4M7NbDWw59fY33Bf 57awV7kOroN9mb7uXAtMeoy9xvVwPczOneR+wATuDPdD5uT+hfsXJnI/4vqYm+zXAyxQyGR9kb6I NdDbeX79C/oSFqA38kL6cn05C+sr9ZUsQl8SRen9u0a9Tf8V1qS36+3sb2Fur7BJsv1S/GUJ6Qig B3AScAbQp2JAxSBgiH1J6pFOSmekPmlAGpSGpMvSNWlcmgR9y8N79CAGT6Yn25PnKfAUe0o8ZZ5K T5XH6KnxrPLUeeo9osfnCXvWeTZ4Nnu2eLZ5dnr2ePaDdHkOeY56jntOec56znnOey56hj1XPKOe 654bnttyq6yRZ8np8lw5R86XC+UF8iK5XF4Mskw2yyvl1SBrZUGWZL8cldfLm0Da5e3yLvwfRLX1 WjcEwS8b1tLvKyz9T7NvC8gjZOXpZOVzyMofJSvPJCt/jKx8Lll5Fll5Nln542TlOWTluWTlnyQr zyMrzycrf4qsfD5Z+dNk5QVk5c+QlT/L+kCKyNafI1svJltfQLb+KbL1hWTrL5Ctv0i2/mmwdZ6V kn1/huz7r7gnuFywe7TsCrLsz5JlV9L3ES+RNS8ma/4cWfMSsubPgzV/FXzgde518AH8SuILZM3V ZM1G7u+5vwd/QJs20/cRFrJmK1lzDdcHdrySO8edY1/Uv6J/hdXq1+jXsFf0br0bv9dO35DeBvOU BmP/MOMCa8HuSgBlgEpAlZpnBNQAVgHqME8zR1oUKPUM/HFQmcHgeak8UCEtDizxDN0NzJOWBao9 lwHXghcRkjlg9Yz/cWAZaWWgVlodWOOZvAP8W1obsHluBWwyHxyWhIBT1v9xUBlD8IokBWQ5MyBL /kCQEA3E5GxAXtBH6YLgqFwcvC6tDzRLmwJxueQO6O+y4A2pNdAmV94HVcHbsjGkkdoDHYTtgR3S rsBuuUYBprFv8qo7oL7uDeyT6wL78Eg4EOiU6+8PLCcdDHRLhwNHZPFuSMcCPYl6kyGdCJyUfXcg nQ6ceRD410Z3Sb2BPqk/MDAjLgQGEX4huhchXQoMPRBGApelq4Fr92AsMI7wS6F2aSIw+SDw+6MH pJuBWwgPC/IEXVCP8EejB/HY4It0eWzBek9a0ODJCGZOh3999LAnK5h9P/g3RY9RHbnBPML8YIGn KFh8FxYGS+5BabDsLlQEKx8YS4JVnuqg8R5YgzWe2uCqe7AmWHcXsN8PADkcmuVxBkWPHPTNCDgn rwulyxtCc6lcMBh+IMSC6zzNwQ33AOvbDNgSyvHEg5sfBPK2UL6nLbhlCh3BbVPA8zsBe0KFlN4f WiB3hRZ5dgR3UnunQT4UKqf07uCe+0E+GlosHw8tu6uOfcH9d6Ez2HUP8NpTIbOnO3hIPhtaScdz odUztedjcSR41NMTPH4PTgZPec4Ez96DvuC5ZMjnQ2sT3J7MxQmunOK4iyFhioOGQ1Iyj0zZSfK8 JuYlMUZXQv6psR0NRZPbRFzSCpwCvu9vVzjAv13xX/KrXcFsihtg7/69gAPREwl79h+EI9wHz8vX Q+vlG6FN8u1Qq1cTasf44p0V2o752DdvemiXd25oL/KrNyd0AHnSmx866C0MHcYY4F0QOobcTn0G e/cuCp1I8LO3PHTauzjUi/32Lgv141h4zaELyJ1YJ2Fl6JJ3dWjEuzZ01SuExrxSaMLrD930RsMM x5diEI4ljKF3PcRJNZ55N0H8UcfZ2wr1tId1WAed2x5O8+4KZ2DcmYq1SXM0VSdCjSmJWIBtwtjo 3RvOorYdCOcm5pnKI/fD3FNchphHfTsYno953sMQw8sVYLzG8b0LZiUuY7yieAz3ScRiPBLAfqhv 02Is3QvgPRZoRmCMTcTVBLwnAh2IqRiJMVONjcmx8q4YqcbJBLynIQ7CHFPsg3jo7Q30IMhuMc6d UDDFWQBvf7iIjhfCC72XwqWUD/zhHQlXeK+Gl3jHwtXeibCV8tGHMZag34IfoT95b4ZrfSy8BrnI pwvbyC8SfqDyItkW1IM850sDblJ9hOYLeAuvT3DgPb41za+m+CXRfqgDedOXEXbinPuywvLU9Vge /M2XGw765odj2G5fUbjZtzAcJw7H/kAffKXhNl9FuIOuux//qO3yLVF5POHjm5PKqG2mvk7j46n+ IA8n8HH3+hg+9VWrR2vwEPZpCtN5MpkrkR8THJnMiVCW6sEyeA7GwFcbMvsPR0/7j0V7Ebi2wfmm dc2JaD/lAWf5BiIG/+nohcT6xd8bveSLh08Sj8G6w98fHaE1BXCarzt8zdcc7kmsCfwXoleJ0zD+ 47oBue5SdAxjtH8kOuG/Gr3pOxm+5R9rZP6JRp3/ZmNagDVmBHSNWYG0xlxak6l8Sdfi2kxdN9Ga J7FGwbrUOvBcIKNxPvIltmtqbZdYh03c4WBCYg2jrj2wLlyPBbIai3C9E8htXJi4nspDf+hvGC/y E+hbYH5jKeXhujEBdZ14F6avBdW1311Qx3X6um4KuBZLYPq6LrFGm2FtFihScN+1Ga69ktdfuOZK rLuS1ljYVroWy6hjco9vgf/51oR33ONXtvDuxBrL5wzv88nhTuSiRDlfMNyNdu2LhY+QPSV4AMug z4H90bEtfMbXEe6j9I7wgG93eBCR7G++feEh5AhfZ/gy2eeR8Pg96xiAryc8SQB7RJAfIm+difB0 7IvoEz6IPuEbjGT6hiLZU/6HHHQ5kkdccy1S4BuPFPsmIyUYexLA/uIzFvkf9Nl3K1LWwEcqqW7g jwZ9pIr6qZZvMESMDZmRmobsyKqGvEgdclFDQaS+oTgiNpREfA1lkTDGP4qByE+wJmiojKxrqIps QD5uMEY20zMLxMKGmsiWhlWRbQ11kZ04Xg31kT0NYmQ/Pic0hCOHcJwa1kWOYvmGDZHjDZsjpxq2 RM7iGhD5P8HNDdsi5xp2Rs4ToD6MM2jbDXsiF3HcG/ZHhhu6IlfQzhoORUaJw2AeG45GrtO545Eb VMepyG3k8oazUU3DueishvPR9IaL0bkNw9GchivR/IbRaGHD9egCHN+GG9FFxGPY/9vRcjz6NdHF aA/+WdFl/vSo2T83utKfE109ZT+wBsf1hz8/utZfGBX8C6IS5auc618U9fvLo1GaP/AT/+Loev+y 6Ca/Odo6ZauJ54BEjIK0f2W0Hcv4V0e3Yx7jGWfYbOhg7C//gvJn9C8oo+z6nX8HECaZ7Mh25DkK HMWOEkeZo7JW46hyGB01oFc56oRJRRx5CEe9QxRuKeLwOcKOdY4Njs2OLY5tjp2OPY79ji7Hodp2 x1HH8doTjlOOs45zDoMq2wjnHRcdmaoMO644Rh3XHTcct50a5yxnunOuM8eZ7yx0LnAucpY7FzuX OfiEQAmzc6VztXOtQ6+IU3BKTj+Ui1ILsUVYEs/h/eAOuM8/uwtse/l/yj6oBXxjBcgc2gfNoH3Q R2kf9DHaB53LRCaxeUwGyabd0MdpN/QJ2g39JO2G5tFu6JO0G/oU7YbOp93Qp2k39BnaDS2k3dBn aTe0iHZDn6Pd0GLwuT62gJ0DeYF2Q0toN/RF2g39NO2GlrJfsV+zz7APQMppT/SvaU/0s7Qn+hLt iS6mPdHP0Z7o57lcLpdV0Z7oUtoTXUZ7ol+gPdFq2hNdTnuiRtoTNdGeqJn7Kvc6s3IbuY3sZdoT XUl7ol+kPdFXaDd0FXj6d9mXuO9x32NraE/0VdoT/TLtib6madN8ndnolwbrNcc032MC+PUZ5tRc 1fyaieC/kzCWHIux5ju2aoce2y/YL9lH7FftYyAT9psw8DohTcgQsoRcEqcgC0EhJjSDxIU2oUPY IewW9gmdQjfJfKFIWCiUChUkS0hXC1bQtcIawYaCdsM/B3bzvGo3GXR/tBge5ugZsB60FQ2MfwlY D9qKjmwlFSxlKdgQ7pk/BNaxBmwI7eNhso802iefDf3ygCWhNaSDLWwFe0I7yAArOAD2hBaQyb4D 8hhZwFyygHkw/6fBbnE//BMw5/8KFoaz/jjNeg7tgT8BM3+N5dIc53HpMMdP0uzm07w+RTM6n3uN s7GnaUafgRn1s0IuCjNaRLvcz3FbYBaLaRafp1lcQHvan+K+yx1jCxmnL9VXJM1HkWaOvWi6COuE DfaF9tKECAX2ClWWTBdhs73ablVE2GKvtdcK2yBnmgg7hT32NSA2ECeKsJ+Osj2YEKHLHrtXhENU Q8zerEpcEeGovc3eJhwH3XGvCKfsO+y7p2QfllWlU5Xu6eLudh+xH7H3JMQ5bj+pypnp4u6x9yXu 5T5pHwDZBznTxLHIPmkfBMH7DaGIhYIBjpfpChLH2L2128+Iy6iGM4mRtV9TxH3GPm4fd3eCnrxX 3H3Qv1tTYhX4KdErMsNInRXOCQYhc0rOC9kkF++MREKEYSFPKEgIzfgVoXiajAKuCyUkZSA31Pzb Dg3oyqkeWe3NjllC1b3iSBeMjrlCjbAKxZEj1CniyBd8kFMv1DsKhfqkeqbEscB+TRCnxCeEE6KM vn0IZgTs21FOtlvtWOxYhjbmMONIOFaifThWQ2ot9bbYITgkapFEfVVqQksZoFnqcw+6h8gaLtPo X6ORHnX4wXcWwviV2iscUXunYz2MssGxCdrX6mgHW7Y5toO9xxy7BN6xF2y5o77VcUAog/u2g53E oexBx2HHMfstxwnHaUcvtBjtv8PRT720wYydtccdF6CE1XHJMQJ1oddSj6ik4is4u3F7reMqtH8M +jwB+W1QrhS8rs1xE1ILHWudzF7h1DnTnBnOLGeucz75cq0iziLnQvRXZ6mzAmSJsxq8VVY81ml1 1tLd4E7ONfa404Y+6YSaoaTsDDpjzmZn3L7D2ab6H3pgp7PDKYOtGcjesuHsDsEolDl3C9nOfc5O Z7dQ5zwC8wuz5Wh39jhPOs/AyBULVdCmHcI5Z59zAEoPggwJJc4eskDsJc0VlgMBi8FRcl4GXBOq wIc7nJOQH3becvHOIZfeBfd2ZbqyXXmuAlcxjLXkKkF7d5W5Kl1VLqOrBm0cRpbm3LXKUQjWVuaq c8quehDR5RMqUeBc2FXiWgc9MAqr4MwGoc61Ge0UdL1ri2uba6drj3O+a7/9mqtLEF2HwB592DfX UddxuGc9WGgY++cetx9xT4oCMMNJ9y2YnyHoTxXYS4fES3pggU7JAExxxrnDNSpl2rPsPfW9rhop W8pDvwabgdGSCqRiqcTZKZVJlWChyByTwGY4Op3uHnePUsLeIfZLVVAX8h1ZMJVUWAYsGOoakIz2 HVKNvVtaZT8j8FCuB9ozLtVB6oirTqq3n3SUu0rEckmUfFKYWFBlMmmdm5jVVeYecA9IG6TNwHOX Fa6Ttkjb6G5wJ2mn/Zq0B9kM9Li0R9ovdUmHxLkSMLqrTmEu4i69+5p0XNoi1EmnsCWuUzBPaDt1 rrOuc2g/ijjaod1nXOeRk1wXYY6HhRqYnStgV8XAB8WuURjr/a7rQqXrhuu23SpqROAd+2UxXZxb 31vfK+bADO4Huxm3x8R8sVBcIC4Sy8XFQr1zCMfdfkQoE5eJZvu4uFJc7bwsrgXvaQOCkQQf3H8I 4uMVcTF4sAE4qx7O+MWouF7IFjeJrWK7uN3eLOjFXeJe8YB9QDwoHhaPCQbxBNRqEE+LvfZBqHlI 7Ic2GaAtF8RL4oh4VRwTJ6CNfVC33j4OJW+6mVtnb3OnAdtkgC9ZwW6y4JpisJUydy7Y76h7vr1b LHSNukYd7a5h+5BzwF3kXuieD+PAu0vdFe4lzj53tdvqrnWvcdvcTne1YISj7Jx0B90xKN0strvO uePuNiHs7nDvcO927xPb3Z0OgVZTz//lCfPP6AlTZH56q2Eu/m8ytk7GfYVnmbb9IF0gh0COghy3 HV8DYjtlO/Xa4GuDtrMg52znKO88yEUQzBsGuQIC160eWz1mGwW5bsNnWN5gNayAe6TTEw2jJxqe nmVSaM2roWcZLT3F6GjNm0pPMXp6inmInlwepieXNFrzGmjN+witedPpmWUOPa08yrh0Id1HfaL3 Dm2LGGczw7Ecjis1c6oP2JY9CIxGOB4EHP4YHFNgrFNQfeIBcRrQOwP6FRjDcLzwYDBugOMlFSMq ripYPqQcjTsBeyA9Bpi4F8YuON68P4xHAcehXqZCB0i7G9S3aVieMQ1ZfwJyAfNnQNEM9SIWTkPp g8EK4768ArDkY1CtwHpBwXLrA6IWsGYG2BRYYd6WOx8MVpjb5bKKoIqYAutV5WgZhuMAoBkQvxdW sIHlbfeHdUKto0PFDsDuadg3AzqnoftPwBFAzww4CTgzA/qmYeDBYLwCx0Eb+ceMgHPGUcB1tdzl B8Q1wPgMGFTrvA3HyQeDSQPHW3dg5O9gqky6epwLyIFz+jv3SoYpX72/4f4wFQIW3H29MXMasmcA XrsIjnlwLFePi2duz8fBWAAongElgLIZUHk3TMuS+DuZbxN8qfKYyWyb4hfTStvd/JGwk+R5Vcd7 aoxWJ43t2rvbNMUpyRyQ8GHVtzBmJGx+RdY0m55UzpsEgATwKxyB8cW0XsnHPpk2AVoVfrXhfAFP mrYDdikxwLRX5febir2bYEwS/GyCmGY6rPTXdEwdB6gT+RLrJGC9MJ8m4EUTjJ0J2mDCeq+q46uO J15LcTIRw0aSxhnqMTOlDjxnhnhhTlPbNX2eps3RVExJzFOrEhvNGUrbzFlJ199U+kJ/H1ZjH/xt zlXzDibh2AyYHpf7Z8CFpPiaFGOnMJaEafF1Kl7+R+Jkru3uWFhkuxMDk+LdFGcBzEvUI8Qts1X1 MeAPM8QkM8QgM8Qfs1PNBx/G+EF+u0zxJzPEGXNQ4SJzTPUL1Q8SvIi2hfUgzxE/JXykVeEtvH6K A6f71jS/SvDLlG+1qu2Pq3Pedud6Kg/+ZobYZN6htNsMMcmMMWhI5STsA8Qgc7d63f04aDqPz1Qm 0eYZ+HjqnP4OPpbr7seneXfjHp5M5sqSJI5M4kMqm6eWKVPGADl6BdjPiiIFuLbB+cY1zYqFah7Y iqUK0shj6vplBayNzJMqj8GcrkDbiit8ZsGxx/FS1wQrqlUuw/i/Q+U5tD+I0SugvhVQnwXauwLs ZgXUtwLsbAXWCTa2olnlzwRfdqtrs8S6KXiHR6kutQ5qY1zhS2rXdB6exsFTa5gED2M/sS48Bza1 oiPp+ja1P6XKeNGaC/q2YoeaV5GE6hkwfS1omwHquE5f102hOQnT13WJNdp/ZG12xHb3+uuk7c66 K3mNZVOv7Ukak+m+Bf5n7rPd41fmAdvUGsuMfj2kcNEUX11W7Np8TbWnRD6WmVTtD4/AKxbV7yzg YxaDgmR/s2QqHGHJVuzTUjDDOgZgKVZRooB4EOsvU4+Vd3wQfcICsc5Sk+R/UM6ySvE3C8RoSz1A VGJPAsRHXco4YZ8tPkBYrRv6YVmn9lMtb4FnOstmwBbANhtxkWUnAJ7hLPsBXUr8QxBPwprAcghw VOFjy3HFTjEWWk4BzgLOqeN1HnBReU6wXFHGyTKqlLdA7LDcANxW1oDI/wlutkIMsM5SgPVRnAHb tqYr426FNag1R7Eza74yjjiP1kL13AK1jkUKl1thjWiF9aEVuQfWY1ZYh1lhXWWF9ZRVUMbXKqk8 Bv23+tVjVLEHK6yFrLAGskKMsLbfsR/kblwPWGEtZIW1kHWvmq9yrhXWA9aDSv3oJ1YYIyusAawn kmw18RyQiFGQtp5Wylh7lTx8G2P2qdnv/+VtjD+nvTJNkeY0/osq38v+kbHUPEABoBhQAigDVCYd qwBGQA1gFaAOUA8QAT5AGLAOsAGwGbAFsA2wE7AHsB/QpeIQ4CjgOOAU4CzgHOA84CJgGHBFvefo xxyvA26owPK3GdNrlHz9LEC62rZR9Qh90M8F5ADylfypYyFggdJW/aI7fdaXAxYDlgHMSj36lcr9 9KsBawGCmi8B/ICoUq9+PWAToBXQDtgO2AXYCzgAOKgeDycdE+WPAU6ox73qdSeSzp8G9AL6ARcA lwAjd444PvqrgLE/4ZgYiwllHP9U0Bwko0YB1k/zNayWvToNN5X/dj5xTFyfqPchHSBNnW/Ifyjj zvGhLEAu+0dTtclqqjWtMdlMToJsCppipmZT3NRm6jDtMO027TN1mrpNR0w9ppOmM6Y+0wDIoGnI dNl0zTRumjTdMvNmvdlgzjRnE/LMBfR3MUiJuQxQaa4yG8015lWmDnOdqdNcbxbNPkLYvM68wbzZ vMW8zbzTvMe839xlPgR/HzUfN58ynzWfM583XzQPm6+YR83XzTfMty0ayyxLumWuJceSbym0LLAs spRbFluWWcx4HvJXWlZb1loEi2TxW6KW9ZZNhFZLu2X7jNhl2Ws5YJItB1U5DDJT+hjICctpSy+k +1W5YLlEGAG5CjJmmbDctDKrjpBmzYCY8IkZf3GBqb+4oKdfXJhFv7iQRr+4YKBfXEinX1zIoF9c yKRfXJhLv7gwj35r4ROGPMML7HHDi4Yq9rzBbhDZSwbZEGBLDWFDEzMZmg2vs5cNcUML+6Jhq+H7 7BXDu4YTbIPhrOEDtol+feHA/8ct47gMzk/vq/Tg/yafX6ICmCW/UkWVCmNSGgFek79KTWO5OjVd r0JUAaybD6ybD6ybD6ybv1ktu0Utj3nbkv7eqR73qNifdM8u9e9D7DljL0i/8YLxknEE5CrpEeMY yITxpomZdKY0RYy9pgxTlinXNB9yiyA/17TQVGocMVWYloBPklcaJ8AvrSYbzNUj9EsbjH5jg6ff 2EgxlBhKmMaw1LCMaQ3LDRaWSr+3kWZ4zVAP8+A2eNgThqAhxPIM6wxfZfmGTYY3WIHhuOE4KzS8 Z3iPPWsYNYyyov/i2rnbr2o+D3oNWAd3+2FKz6L0C5R+gdIvaqpBL9KGKb+e8r9J6S2gS7TfoXQ1 pZVrX6B0DV37KdALKH+Rxkf14LUlVH+d5kXU2lfx3SftOkhnapag1kZAH6Yyb+N9/0DpP7xLbdhE +R5Kv0jpFym9SGmtqteRDlAZqPMPv9A8B3pY7dFzdPZVahX1VPNX1C83tVzEdMogpfV0ltFV/4ty vHStiXIeofRLdG0j1fYIteQl0loqU0plnKAXUnohpUs05ZQvUbqUaqB80i/S2RI6+xnNX6PWeqgl 5VQS0y+mXKcyyjhsodqOU204F5/SdFK+ostIr6QyAtV5lOqE0eBfxjvyz2ttoFu04N18lNIvkR7U BkE3YxmOJ/0mlad28gx1ipNKvqm1gz5Adc7BHO7nmOY+pLNbqfxSKv8NSmdSbR+SHqbyNzU/gnxe 8z7olZrzeBdMc7+hHKfm56ArsAybRM0ZSf876XdRp6RQyeVUzytYnvsl1dBJ6W/T2S9Q+Y+ofBGl r5A+RfqfqPwHmgYoadb+M6RvoN3yOu17kL6N+Vy9thf0iAYsgc/GMuwD7UbQv0XNXVFzQKeUUD3Z pHPoWgfpraTnaT6is1+B9I9R85cofZx0P+k3NXU4R7oPSB8l3UW6lfQY6tQsuNciZQapZIsOf0Ol ntIvkZ6t6i7SraTx2nlU8jSdPUQ5g5TTTDl7lXnHNOijpLtIt5IeI43ll1PJ9XQVU7T2W2gVlH6T Wn6A0j2kD6g5XaRbSY+RroK+nNS2khWJqOnuPyf9IV27VdVHSXeRbiWNNWyl0fgGlknZSfob1OYP SQ9TPcPYZu4DbR/oCdIfaN8i7Sf9GmmyBO0o1DCP5usGlRwmfU3VG8kGTqFtUM5tquE21XCbarhN VjFCZ0coZ0TN6QGdQn15UnuabKaPtJ/0a6R/gposYVixMUyDpWFtP6H0B7CmxzZADl+uaugL/0O0 Uj6HcnIoJ4e8OwdrBv0+6R6yzIPQx3WKfVLNHaS3qteiX4TI5ufh/8QN93qLtJ/0a6TfJz1KGuu8 RNdeotHop9r6Kf0mpd9WNY5eL7Xz5VSsbbaiFUuj9AFFa79PM+unecSzH1L6A91ncYQVja1ilAPP tKizKb+fZrafcg6TjxSQziMWeoH4rUVXCPp1yv8VcdEEpbdhBOH+jThttsKHWJKbpXWBfpTYLE56 Ho1GN5UpJl/4GaVfJt2pciDEF47q51NR636Cs6/7Oo6GlrhUY8Mx0R3DtK4Y0ylXybY7yU5KyHr7 6Kpj2sN4raabWoVnJYXPdcicz6EG3zxPPnWe/Ai942lKb6Wz/6b2MUTtcdK171D5d2iciWG0V3F8 UANXo1bm63kdxEc+SuVnU/o0lW9W2aOLeKAVowP5oJPy3yQ9h/TTdJefk/4otRpnM/Ug3RfPLsVZ Bs/FdKaqsc5Pq5y8B9JZZJM/oZw80hd1j+P8Et++Tfb8JeLtI8ii2gGyyX4sqS0k29NjDswd2nAm 8jnXp3gxPCtDRKB5GcARBh7oIRvrIa9U9PvkLz2k36cIglydjdfCeL5HV20kD9pIdoh3iWCrUpbj 2ZTlCqtoYK3CPUE+voSuOqb7HfEDli/D1oIlY84V9HSw8J9hZKGWl6j8s5FK4l32k95K+pTuGUzr /o48dwVGGfLcS3T2uKoVD8V0re45OjtKOaPUfhzhUt1PkOuotW9hNOT+N8XEbGrtHyj/OzTmT1A6 j/oygislvkaD9Z/TGEBfxdUj/wnUMF8biVVw1nZRH/egr6W8QHHw2f/H2rmA6VitjX89az3PMxNj kYYYh8Y4n8c45JRTw4xDQpQk5ZiEJufkQ1IOW6JUckpSSehEkUMSQ7YtSZTKtmPTVg0h2eKdb92/ 593Xlfm+67/b////cl2/937vda/7Wete91rPWs/7zktoUn2n0Z/geSGW5/D8V+S/Imfhf49E3lE8 d6DNw4XqLeRT8I6gkJJ9hfhvxkjVwMPe6P4r+yi3T+jL6icZPpPdyyl/CL2QfKtI6QJa/hnX2oy3 FOmp/7lEIyAm/q+M7xi5v5uS4s18IbLfDLkd/c2jF7+yVvzKTEyhnaz2epO00DSg79fEWystSUOu 5bu9q7eTXr/vu92g14q27aIu2a6b+kNljlOru+yBdXfzk+M8v63z3IJxXOsPkPzUC518AG8n4xRv L+KnIT4zfN/xmNBlXTkluzIXAZNAHF6j1gg4hxz43pforcFDNfg8fjojj6bvi4lzG/o4hFon4Tfw fomY22VJL6bIrtXJ10hWcA8ahrd+tLM7fsLgOVkB4tkovdtIey6FlYTBOfgF3Iw+DXaQNSHac4ql TodNg0PcR0RuF+1C8fMZ3ImfnfjZiZ+vsR+E/SDR6Bw0zdF0jnatIqsL0hLHL+Bm9GnIYl8k2tly lc0R2Ue1x097qat7IPeIZPHjuBl9GiyHpiz5w34Dn8fwdh6ugKvhKl/ugFn4zMJnFj6z8JmFzyyi lCWeTQ2xNDWIwDY8bENeh7xOeuGiuoT2C9+N+iuya9sS/Cyh1jk8iKYx7fw1zt3MLGlDt6Aus1VG 51Ffdptb46cDucoO/yBzltOBWKpoJ3+cvX1pTgHZ8BO8lcb/BXgQrqJuT9iOuuvRn4R7fJelYZr0 K1wp9IeIjb832OBmOtcKRwRyn+pNrHKIwD+xtxLVcCXzuh6t/Yw8OQbnxM8phxidXHLyEKN2iMiQ nzLLXASqyEgF1zsu4kyksSyP5WfIU7l68yjfGIvXRWMMI2XQt8f+GPwVroC57ORXhCe4imjyZVzc +Ip8Ik7GGnl9lDmicZnQgRHswIi7c7Saaj5358rOQWFh6M6tVz6VmXjl08CNslnITmm3xMRvIvcd f6DI5m34DPoVsh/zX2RVxN7tjWVfdAN1O7IvegDLj+S86e+UVdpwfjQ95LzsF6P0XWq9Ikwog74k Hi7DVdjfS55MlLEw6yS25ghyFqwv9FNljPw0cmM69h+SUV8Jg+XY1CcrUsTSzGBkf0IeQml1SkuR LZl4iM6qq2A212rJruBF7oDtJGLmGHeQ6ayN27lr5Mr+xCxlRzqbe9Ay9ocT0DzOriYPP1vgAfgF /Ao/x+FeOJZ701fcZ9cLg4+QJ8INrK4XuAdNk/2bX5Nd3Fdx+T24Ek6HeVIqJ6/gFPFvj2USbBLe 6RidyDghmg1xroTToXh4G8tx1FonGkfRdBFN0Ies6M1edyzsCHPYGY5g/9mOMyk7WL8K+bORa2Fp psta6qNxlF58j+fKcb4HV8Lp0HkLqsuZNPyQnNkZlHS1CuNtKewPOZ/6yfT9YeT34nwProTTKZV+ PSyx8jeLnFAufAH2FP/U8uOU+HBGMKskDqYlu74JcS6GOfAeSC7Jzi0sxLjfjWU7WRuDysFOJ58O PnJ8Af3BOHPgPXAHrCv5Rmkumlw0M2Sva96UGer9F3vp8vAmOJa9ZSrnoCbsXWuxK55NRo0lY2fL PlC3w/O7yA9zel1L275F/6348TvS/iOi8cvEuRjmwHugzK+q0ir/BjnDhq9FOS8zQh/HW2G4lB3C ZOZRMvuHh8j/RZR+FedimAPvgTuwcfH0K8hVgo/kuaKj2Gyg1gbkZCJwgSgdDlYyF8pLaUROrCfk xOp/L5pgs7TEfw/5NLJPnvjYTwh+YBQiyun1Uzm9umhIVuz1J9M2yViFvIGWb6A0WkVbwMJBsqOS 8QpKh12dvEz0QQUy+Vv4cHwtlZVnE2vpXGxmYv86M+4n5lFhVtTGrMALkDfKCuzyytUKtjIuufjk 9GqexvMwvNVEfk/Ov+6EK6U5WG4SJm6WDE9UnLaexzPPTBKi1f7PnG6mM0NPMYPWMTsaQk7HZjUe XsOb8h93tTbh531pm89zKp8TsRsLuYcO5Cw8UmTnIQ8eYF7nwQPM1jx4gNa+6+QnueJ6onRZ9gBm IavTTujTto1yRvZfhqOEhicnZnf4hNzvmMVzkddh/yJ1n2SmTxdNOFhWg/AB9B9hfxT2gEvDC8KE XnKnw+YVyZyEMsglYX28XcZ+Hm0uJHcHv7g8p/LrBinkj8ha2hb8KKPvF2fuTIjOm+TDqmCX5Ino /WPxM7U8sVzJGacJ8zpL7hEJ2YzdF4xUM5HDQkERV3qRe9YGORG77JU1IVNKE7K5syyV2eTWqw/g DtalD6DcQzvwHKkm+iPoj6A/jf44+q/Q98bbt1wlOnlN4M54AG6Q6wZHpUchz2PNO5y4l3GPmy/2 +mM5X7tV7h4i/CttlnWpiZy1wyLM+jxm9xahi+Qe1pm6tES4l9LC7IsKy87HrYdXmAuLWTGkdCKc Hl89pNYh1o0P5dztbBagX0D7Wa/CSU5+jza39cs4viT0U4n/W/T0a0ZnDDZ3xC1FU55z0CfSR/9a OSMbniqb6NT2Jae2XazJjxCHsox7bc5lL5AtpQK3FoWJ1PqVHcKbch4PhvjuZOHPZo0dTt3h1J2F vEKupW/kiv0Ylxc59Q+gR9M44R5gRvhonpRTuV+Tdt6F/RmuSKuCqcgT5GxuHkSObIbhoRG8W/ZL bt8os3KDf73cF2jhSfI8Ok23JhOy6Htds8n1q5f4CUfB8UJ/qb+alVNmxM0iB+OCcbRK4tkdm+jz js2sZoGUmpFyFws8/BQj/hto4Sty7jaHkU/Lad3UQ86S07p5g74UlZYEzCD/Dr+00yyh/ZPNacdJ xmWCf0o+5QlfZk/YV07rrnfSnjJyZjcz8TkyTolhEXiHnNODDfBOOUeY36TvYUki0IEz+HfUulfO 6aYE8hZKz9Oef9DCd9D/zGcZqRKZsBpXbwHvob9DYaP43lLuqqWptUdO7vpzObmbacSnNM8Pj9LC vrADozODcewoo+ay11GvRlOWdi7gFDMXtoxkTihzmWtzOenMlVOVK3UnkaAqO+qtWD4G1wWPsx6K bGHHiHjoiIeOeMjCMo+zXk3R+DXRHEKzwHcj7lFXV4JPcF6+jfPybZzCmnC+e0HOSi4TnL0ejOVX XLEk+8/aeKstdf1M5EcjonlUvDluRp8Gy3Fnd5EJPqN3Q3x3KjSL8NkE/1HvWsBH5Ozp2k8v8FkT nzXpaR49zZNY+XeI5zAz2A8fkyzCw1sRiU8/5Gzi0DLsRKyEt3J+Pyznd9eLTvLsy/+M63ZiBn2N h3N46yR3K2mVW3mEC/3Kjn38KU4/jhWV87I7X0vpDFgWTQt/qpNzfGlbbTSst345xuIn+LPQ7BYG e4V+bfio1A3qcJUS+GwPm8LleJsexQoPp2E1IvwwHCYrXsJOiUBiZ+J5kXPfAzylHyZyQshdr6+U BlWJ8G4sM5EHipywU7wldpadSRDjPNiEfkW50ZhRzmRcFiEn46E5Nm/I8wFzr8TfT2EU3iI3Kshd zJyQ3pnVyMWQJ2JzBNamVhpMZjRLSt1gmYx4sBx9fSxfY5RniKx/QtMkbATnSb5hWVpG0+XJ46yB wn34XIVcmTYnE8NHRO8sL9Lai8xQPqnPf115yuR/grxaPsuGGfmvIVeH0+VT8njp63AZ9uORI5aC c9FHddcgr8HbKvgtmm+Rv8TG6XXXfHkiWhs+DsfAlvBLOFHoaaE6jyYDKqEZhPwsfBVeG5flU4ND 1D2HZi5sS62nkJMpPQovoeEquhua08iR/+Zc/QL8itJ/ws14M9i0hz3QH4vL0oYVaFajyULOp1YN 5BNwG1wHf8CyE/JF5BA5BkvB72I1ZGdIe7BXv4jGRJEpC1NE49Fr7w74KfpvkDfBfdhE0esaa+08 NIjGQmTdEi6BS6NRQM6ACj4LX43J7nRrFH/ReG/Cc5T+Bc/zo94hXx9FHpsYNhWivqA5SqtOIH8W 70tr+pXo6o6n7gTRKOLjTcIyI9aZXiyg5Qto7QLaJpyL5hz8AU0FoYrksjAFHueKVWAqrAdPcq0o A59G/jtMibVx7I58HSM7NcpJ0es1yLVicvr+ArkperJCJwhDMi0cK/Q34OGKRCAcJnKwm7F+NYpM /kL5tBH7P0W5gbenacOv2PyTWHWVWenmVCnyXzgnGuUrZ2XG0dMxcWqY6ng9bAknUjoRbxNF4+Ip +nboM6CKM1XuC8jPximWnYn2oXjkUxmFJVDktqI3T1F6nloNaWGU4efpEfH3DkcjQk9fjPIZeQA2 a4nS/mj1kFj5B4hYNH+TkcsSmW3Yb4u1kqdSyGPwMxp5sdAwi017MvAicZtLKaPplUP/g8TQu0yb Q6KXQo8SiVJM6PIqkqWPxMr7E4zysG+cqdRdgh+x/xSf+yl9HRJPdYZen4KL4V/yr3O8Qh8LoXkb uRxyKqPWBXkvLf+e0tIiuxVjhdO0onQkXEDpEiJAtpt6yNFMT5GI6erooxnxCVyI54F4GIjng/Eo iRytbHuY19uZrScZBVYVzyfyzfATrYR74T/y60skkXdHayCWM7GsGK2BXOUz9Mw+fzJzZyfyr/lZ rp3RfWQZq80XEiu/GXI79Hn4+RWZlVBfA2vCtGjOYrMTvh9fnRo6cqfwdmGzNprRkBVAzyNKLbA5 AKN1g7zV3BdcVN2ZwjD3vdfgCBitFdXg83A0+lHIbeAQMvBh9K/H7wWSz1PiskQgunf0xp41RPeL 7imMZkj8S8G58FO4CbKee28zXvnIG+El6u6LxguZSHqnkQfBzkTpAnIRSjcjt4c9YhekheiP4XMO XA1XxedvdC3J/J1k/gVmRA+YhX4bcmPsH8Ub9x1vB1ePkRvcGT1WclMay81kC7J3gdX4IPIq9D2R o3WV0Q9XklHF4GOsMOxPwvJ4i1akHrR2Xf4i+YwJD/mxP9FfRy8XXmId7sZKshr2wfIS63ASfYnu U8nxdTWV3JaVoTma5kSvOavKBfRFiMPmOGXtNVi2j1M8rKB0dZyp3HeGEsNU2inrUiqle+A66nbh GeN5nuGX5Ulj2fBdZ5kU/3aNfDulMd/JucKz5eryLUfvU6Feyee/Ozh78oTK+7sv38zZyomMT1t0 ZlhYZjqf4OwVWX+EfNb/krMqn3nJ/lz10lVkXOSJhKnh3y9X91+WPYbIOs//WbJRaM76ryp5vuQs 1TdCbzC1soXBSp5phLCOP0HmJh5W+G7fa3rj4bKUht2p1Q024PsJF2GinyIjbh6RiJntYiOynix/ 4aKHCk2OOYI3Z6l2Cb20qBaa/UL/R6HrhXCZeVJ6gZ9MeaqgcyM/lPYUBlPwcBEegTPhO0ae59QQ 6k1GTvepcq7XF9EUD3rRTvkWWZJo1H6R1TdCZy/yLrEPmuMnlVrpRr6/V8XMl9E3y2jbKnmmTa13 YFM01cQ+2EKt4/GWSGlPNEvMeFlt0LeIU75H5Me9LZMo0bb3RPaO0h6jPWFwXn71BllrLRpvC6Xy DeT63nd8Y1a+1dZFz3SsLU9d9Cb9lKy6epq0XL8i81pk/YR+wnGilk+3tdh7c2E3oXkAm2c133XU cxzrmhmObyPXMq/hx8neOSypq9tS9ynk6/B2TrLU+ytXv6Svk7msJSt66lK0s5jkv+ZTfh06TWtd VOayripzWey9zrCrUP0iNAYP2XjroUvLmqk/xafIF/QxuWsgr8KyEx5i1L0B+QT8yJMIr6UNp7yK zrKOJ0843broNJc9+ZT5inde7gU6XdZVPZlP7eWXZX/wjkp7hF5rXVI0er3cuby/yz0XloV1hM6b ozqGPAcW945geURmOvI33ni5m+DzU2+54zzva7kfSUvUSTz8Ii3Rl5WSb6H7Z4RhMvLfkIvw7fTC yDeifxON8+O/FDqffi+YCX8Umu/hamGQhP6yUPvwSTTVsLlbGB7CsgbsRGkacj/knlieQIPenylM KI9cldIP4Xk0XMX8GXkg8mTYBc0UOE7o0VrdgtJPkI/SnhCbuXAlpTuQ30b+Cd4K70RPj8wV6kbe 9sDH4P3wCywbINMv8xtXfAh5O+05CE+heRlvA6jVGMvd6Csgr0FeTEzWI4+FL8Lq1Hopwd19wjLR 6Ijs/wjzozESOUhCcxm5VTRGaJ6ORkpkczfsB3Pw1icaL2olRKOGTEzC09GoYb8anqA0TZhQHs2H tK0ulrPgkCg+XP1mWrg1iolo3D1R5ChixNlfBptzRaLt/UwpkdSb8EDWBfNgLvZL4X54C6TXfpRp i2nnROwr44GYB5Y2kD+6Crl3DfbHsXkDuSWWUY61gVaY+IbUTSxBOw02WXh4HyajL0OvqxGZ3dg/ SylzxD9ArUpci9iaedG8I4aHqEts/ZmwKn7exSYd/8RTt6buWvTMsiDK1cFcK5qJ5aPcw89fkLHU M6j1AzbPwChDiJ4ZEWUy161ArNYIvZ/RLORaUR42hM1gV+ruQ66Phwx4Ev4T/RNcqz/ybfihXwFX DxphORs/85GJvGZ98JfDMbAHNtEVP4dRhmyk9AHIuJjSXPFBSOQT0PjnuOJ49NGaxhz0o9nNzA2K oikOWRkMWWHwpqOVilVFn8Geuv4o+DpcgT5aG5HNp2h2Ih/h6uSVYe7os9Qi64JoNkU92oxNIewX oYnGfQv6bjAF0mbDmhlOx2fUKrLC/xoyp3xyw6Pl4SRqPYL9JWRmoj8BfomeMTXEP+iNnjXKZ9Xy yQfNqu4Pgh9gf56cmUz+ROvVSshaFDCPzGNoopUzj7rRmDLuhpEKySVzF2SumTmQ7E3YK0wkKwLu XwHZHhLtBPoeUupjb1ijTBN4q1xdKTmD+C/F5NOiXjAT/ig038PVwiAJ/WWh9uGTaKphc7cwPIRl DdiJ0jTkfsg9sTyBBr0/U5hQHrkqpR/C82i4ivkz8kDkybALmilwnNCjtboFpZ8gH6U9ITZz4UpK dyC/jfwTvBXeiZ4emSvUjbztgY/B++EXWDZApl/mN674EPJ22nMQnkLzMt4GUKsxlrvRV0Beg7yY mKxHHgtfhNWpW4a6+di0Qn6a0hzkPugTIH0JT8O6lM6CQ+DN1NrKdcvSwqjl9NdfBptTl157P1NK j/Qm6jL6wTyYi/1SuB/eAqMWRiMe9WsirIwH+h5YfDKOugo5cA32x7F5A7klltFYt4HUSqQ0sQTt NNhk4eF9mEzps8hkpn8Am0p4JjKG9pt3KU3HD5HRrdGvRU/2BlEODMZblOFRrv4FPTZ6BpofKH0G MjqaOJgRcCHeonFsCJvBrpTuQ65PrQx4Ev4T/RP47I98G35oecBVgkZYzsbPfGRipZlZ/nI4BvbA Jrri5zAa042UPgCJpCnNFR+ERC8BjX+OK45HH60GZK8fzQtyPiiKpjhkThnG0eBNR3Oc+ajPYE9d fxR8Ha5AH60qyOZTNDuRj3B1MsGQ4fostciTIMr5qEebsSmE/SI00chuQd8NpkDabFhtwun4jFrF uPtfQ2aBz+h7tDycRK1HsL+EzNzxJ8Av0TOmhvgHvdEzu30yQbMS+oPgB9iQ1X60kuQhRyPFaBri H5Ih5i5Izps5kNxL2Ev+M9YB63lArobEMIEehZT62BvWB9NEqL7WXyl5KrLXlVaKnmOY2U6Tzbl7 kDxtMMt4ktCe0iXyt7EmVb6fZubzLEWLRv8D/WzRyxcslPy1hWh6C4P9Qr8O+vPUzaH0e2E4AnkQ zMZbXmTJdXvGn2ZUUvKMQs6GS9A8Hn/iUYe/rZOnKB14fnKJ5yHJPBtZhX651NX70Ayi9DlkjYc8 OAauoO9JQj2ZCHSXJyQ6l6cWDZAbmPelrtiofJ5XXBd/fuKo/iY2QQZ+ulErkyckTUXjXecvcvqS 8Wcjq3gGsornIY6xp/PlOVWX/L2y9iL3lLOt3iey1xa5F6WZyJuRv8RyAnIiclNKP6bWKTTFI29o vovJSb8WNsWplQ77UXowIqUpyJcofQEPldC/gr4Rcg1KQ+T7kKdFbRDZ+ypqA6XjRI51y7/gMqEK mndUacfDyEtENkU5y+cLTQt4Fs0l5PlY/lUY7Bf6HnoNV1GaKPTOI+fBdOwVNrNhDTiV0jG0YR5y P+QVXPEHbMYj76J0KH4K4X8bXB5vubRkCJr1aDbBmZCemmxKLZrJsY38L+zieUtMngSm4nl4vA2i /0bGyLQQqm+ouwbOwRtPPPRxNN3Fxq8Sk++qtaS0dew1x5jq5PTFsKknGn0majOel0kbwnJoNovs zUHfLfa25KfY+9spPSilru8yOkl47oa+FD6fov1l8i+5dk6htb/QtsNSK8ihLyfQLyXrJkotrxHX Go+chp/02GU+Qbgs8YQzhW43JTyKpiw2J5CLC83NtKoBo5bLtcbheRAtPCoMfWJbLcqQ/B6SdWKj i4tGfn/HrZDMMr+Y9CUshf0JkYN22CSh6RXlIdEuy1WSiExxiZj3BL3uGZNns0Np4QrkQrE7JMdi 8rTzOtiZq+cSjbbI/cTSO0+tdOQLWObiYQ7yLPQHicYe9FXQnKN0LprDeJuLpiWWp4VuxWG8ojyk /Z3oy99ow1EyIcrkedJrdwo4QpQYdziZkTqPfQwPdbhWU0rTyZ+j6BsL3fou49I+biM8Tg7sx/O+ KP7xaEjLM+nLUWJVEn0R2BPLofHrXmZeXCb3zpIJkaXErbzILrfPksli0wfOQXMHlilcKwXLvdTK xWYBXE9p5/j8zXB9CWnzWvr4F/Rl4Ye0Z3BkSX+HR70WS5dFPLUmo8J4VJeR1URDIuMNxvNzrANb iN62+LXETwYjVTJaqaiVR61tWMbI9nQs15KZySKHaaoombaREZf2L4pmdHyOiLfejFEleC8t/DG+ 4pXmXiNX2ROfs/Nd6VvRXBZvbrV8jlZlUCtaV8XzVJ4S56kB5NUAuafnd3Xy7WTdKWxYB0w0j2ZR t7P+M5m/kdGUPm6N1kYsJ6HvTuTnCd26tJG1QlaVaERWwERKU+l1G/p7BM6Gl/GcyXi1gmmwQ9xG VrmJ8XGUle0ZWTNdPmxkNr1GVlzmk9zL5Opl8vkyYyHyReI2OX4XK41Ger2AnjaP7mKsOXmMziZh AlmUwF3GfI/lAMg9Tp2RPHR74G9ZA8+yBsoK0512NiVL08nhfWQ1a5GzXIal2L+JfiiW2cgd0S+n 5QeRV6FvFzsAc5h9Z2VPLleJzc//jvHqJrOVMb2FfqVF97XYx3xeX0JaS8un0JdULLvF2PNQt6wq 73ymxEfWyVdWi2el+J035cvf6cSfNApVIfSFRK+UaGJ3ybesY73km/Ax/h4kVgi5HnI95PryPe1Y A/kuvdPnoF+JfI98f0y+me/kHch5yD+KLH/F4+p+IL9yg76BfBvQ+XmD32b5hd+32SSUvyNQSv7O PZYsf80RS5a/B4m9Ew6VX7lJeFR+5UbkK5tFjk0Jn5JfuUk4I/7D48KE08hfi/+E75F/Q45susL6 WPaFA+R3b6RtV45GbQ6fx34ZclTrFG0+j74S+mLChFb0rg48TX+nUroWJqC/Ecs2XOtH9LvxmYGm KZGJNJcovQv7mVxxN1G6BCdx9dZY1qSuWKYjpyNnhLvQX0SuiZ9IX4WW3I5cHflO/BwSJiYg80s+ iYmU3oVmBt42yG/g4OFGPNRDrodcX/5e3tl/hlwSlqBWW9qcQZv7McqL6ekvlNK28FU098Ad8Dyl 1zvWTXgT+S18bkGehc278Bn0a5H3I5+TFsqvcLjWSh7W53N5cyUfmbjJJ+mxelf+Ie25wljIJ+9O c1ZKr2yWSEaa2CSYCqmFh3pXtmNJ3Sv0+spi5OP4/Bj5IHIepWTUla/QnMSPfANHqULe9MRTyvR/ eMRQlXzfiIEPqIlD+44art5R7uR3W7c2qcqdLPLzVQmVpEJVVlVUxVUd1VA1Ua1UB3WHutv56Koe UY+q/up+9aAarabF7YuoBFVOVVLXqbqqkfPSWnVUPVUfd9VuaoKa4laOISpHjVHT+T8GozpWJbo1 o7JKVunqRtVMtXGr853qHqXVbeq/1GNqoHpAPaTGqhmqpDLtu3TJVh263XpLqurXvVvHVDUfL9fz m6E3uLW5ivNYTzVXN6ssdYvqpe5VRtVQ3dVENVUNUkPVCDVOzaTONSpVVVVyp7tJZarOqqb6E/pS qpiLQwWVoqo5v/VVY9VCtVXZ6lZ1l+rr2l1L9VCT1OPqPjVMjVQPq1nxFlyrCqs0VUZVdx4aqJaq nWqvuqjeqp8KVG11u5qsnlCD1XA1So2X3zLtnzGyv7kd9oGD4HA4Bk7s33foKPMEnAMXwOVwDVzf v+/IgWYb3AX3wgPwMDzav/+wHHMCnhf6GhaD5WEt2HTA0Pvv89vBTrDbgOEPDvN7wj5wABwCc+AY OGHQiL79/SlwFnwOLoUr4Vq4xTnu6++Ce+EBeHjo8NHD/KPwBPwRnoUXYUwY+EMf7D80KASLwVKw vCscEVSCNWA6bASbwzYw+0Hx0xl2h73gvXAQHApHPDhiwPBgHJwIp+aIfiacA5+Di+AyuAKuGenG KFgLP4Db4C64Fx4cef/wQcE38Dv4PcyD5+GlkcP654QKFoLJsDysBjNGjkyvFzaHmbAT7A57wwGO GeFQOApOgFPhLDjPsX64CC6Hq+BauAlud2wQ7oH74ZfwCDwOT40c3W9keAZegJeFCRomQjtydM7I hGSYAlNhFVgLZoxykUxoDFvATNgBdoG3Q9mNa7f2JP8Hr8bN8zKq7P+V5PHDof9nBm7FCNwqmqAS /7+983kXyZ5b9QqyyB+kcetcYX5z+f9F8tzq/b+z+B+mZkS08yrveNoj9wfZJf5hXvuHWe5/sNgf ZiotNbx6v6P04Pc6+29p3J2qpCr1H0rXI2l3f0r7j14rqkr/0WtlVeU/ePXcnfTf89/HxHN38H/P on+I9dxuY5S7689Ty9VatV0dUMfVec/3kr1KXgMv0+vuDfBGeVO9ed5yb6233TvgHffOa1+X1530 eD1TL9Ar9Qd6tz6sT+lLppBJMTVMU9PB9DJDzHgz0ywwK90clGslRjlrOhd436/A+1kF3s/+3Xu/ QHnopvmXKsH73ftCDa5+n7Ts6vr2wtX+k3td/b6Eutp/ieQC76sUsM8u8L53gfcF+lPi8NXvS1Yr 8L5Lgffjrm5/2aVXl5fbdPX7yrUKvK/zu/du/lVOL1A+hffarQ/Fox5W7RK9Vot67rucK+nWqipx 7b746+H46/H465n/zbrGO/HXTfHX3Pjr/qtbUdNe3cuaH1z9vu6Uq+3rfnP1+3p7rn6f8V6B9+uv fl+/e4H3txd4n1Pg/YgC75/7XZY5odH8Au8/uNq+UYFR+h/lewu831fg/f6rR7HJXkfrItPfe1YN 8hax2vZz/5SbqfOUFxQLruVeUVyFSe1tblK23W632m1OE3o/eT85uzPeGeV5Z72zSnu/eL8oY1vb 1sq3N9ub3X1T8kGbtiZbrqeL6xJOI39BZKU9poirWce9L+lOIyPUIpWrjqpLXrJrQ6JrVXJSV6WT spO6ObZPus2xg2t9Mbcmp7rTQro78zS33yuji7k2/YPXXOtOWrqEe/8Dr7n2oNLu3ZeOufaw4y7X V8nQFJVmj7q2bnWlf+M1137nXre598d4zf2d5fG45d/jlifilifjlv9qb0fa24n23kJ7/1XSmZJb Keny+xK7mxbuoYV7aeG/SvZRsp+SA5RolaDdPzfNCmv55nYxXcxFtYSLqklql5Tlor7VblWha9M2 FynjLOTTyOiu76aWq9+X8VKMlOdd8i65Ucv38l20Au32PfgN8BviN0Gn6BSVqNN0mrpGV9PVVCGT 7UazcNAv6KeSggHBAFUkGBQMUjYYHAxWRYMRwQhVLBgVjFLXBmOCMaq4TbWp6jqbZtNcnyrZSqqE rWKrqJK2mnVnPlvD1lClbC1bS5W2dWwdlWLTbTq/y11flbUNbUNVzt5ob1TlbRPbRN1gm9lmKtXe ZG9SFWxL29KNjuRbRfKtks2yWaqyvdverarY/ra/qmoH2oGqmr3P3qeq26F2qKphh9vhbqHIsTmq lh1lR6nadowdo+rYcXacqmsn2okq3U62k1U9O9VOVRl2mp2m6tsZdoZqYGfZWaqhnW1nq0Z2rp2r brTP2GdUY/usfVY1sc/b51VT+4J9QTWzC+1Cl5+L7WJ1k33Rvqha2JfsS6qlfdm+rFrZV+wrqrV9 zb6m2tjX7evqZvuGfUNl2tV2tWpr37JvqXb2HfuOyrJr7VqVbd+z76n2dr1drzrYD+wHqqPdbDer Toz3LYx3Z5cr29WtLldyVRe7y2VLV7vbZVc3u8dl1212r8uu7nafy6oedr/LqtvtAZdVd9iDbo70 tF+6OXKnPezmSC97xB5Rd/Gb2L3taXta3W1/tj+rPvacPafusb/YX5T8zvcUNz+muEwq6hVVk7wU r5yazP+MOtXr5fVWj3tDvWFqOv8b6kzvIW+U+pM305upnvLmey+oOd7P3s/qae+Cd0E94/3m/abm ySKjntWhDtVzOkknqef1tfpaNV+X1CXVC7qMLqMW6Iq6olqoq+vqapFO113UYj1Kj1Zb9Fg9Vm11 +4jx6iP9X3qi2qan6qlqu56mp6kdep6ep3L18/p5tVMv14fULlPErT+XTQPTQMVMG5Op8k17097T ZrFZ7Bl/lP+S5wf9g/5eRjAwGOjVD+4L7vMaBPcH93sNg5HBSK9RMDoY7d0YjA3Geo2Dz8PpXpNC txXq650uNK2w58WSiiW11Q8n3ZW0RL9ZZECRIfpckUlFZulLVttEk2gr2AqmqK1oK5pitrKtbK61 VW1VU9xWt9XNdbamrWmSbW1b25SwdW1dU9LWs/XM9baBbWBK2Ua2kSltG9vGJsU2tU1NGdvcNjdl bQvbwpSzrWwrU962sW3MDTbTZppUm22zTQXbx/YxafKfU5uKdpAdZCrZwXawqWyH2WGmin3QPmiq 2ofsQ6aaHW1Hm+p2rB1ratiH7cOmpp1kJ5la9lH7qKltH7ePmzp2up1u6tqZdqZJt0/aJ009+5R9 ymTYp+3Tpr6dZ+eZBvY5+5xpaOfb+aaRXWAXmBvtIrvINLZL7BLTxC61S01Tu8wuM83scrvcNLev 2lfNTXaFXWFa2JV2pWlpV9lVppVdY9eY1vZt+7ZpY9+175qb7Tq7zmTa9+37pq3dYDeYdnaj3Wiy 7Ba7xWTbj+xHpr392H5sOtgddofpaHfa/2bvO+CqOLq3p+zeuXcbCCiIaLB3vVixx957N2oURQUL RFHsBXvUaGxRLCD23sXYe+8dUbH3ir2A/7PH1WBivuTL++Z9vxLmx5zZcvfueWbmOc/M7t3dy2sY +439vKZx0DjIaxmHjcO8tnHUOMrrGMeN47yucdI4yesZp43TvL5x1jjLGxhxRhxvaMQb8byRkWAk 8MbGA+MBb2I8Nh7zpkaikcibGc+MZ/wb44Xxkje3xlKm8imEXJsTmrNMW9AWsDqQBhIqxUqxhNmS bEmE20vbS0Pv+fewMbTcf9j4/3M2/qX1eWPry2WqLRpki/+njf3Txv5NbYzKwaDnXWkmVohXkpoQ H1KclCPVSD3SDMYLwaDfe4Me+J6MJ5Ekhiwiq8gGsoMcICfIeXKV3CWJoOwJtVHN0ZNwRzdHmKMX 2u6O3mh7OPqgDXf0AxsGpf5owxwD0HZ3DETbwzEIbbhjMNjusN8QtGGOoWi7O4ah7eEYjjbcMRJs D9jve7RhjlFouztGo+3hGIM23DEWbDjsNw5tmONHtN0d49H2cExAG+7oSxhsjYC8u2ME5D0cP0Ae /i8gMgk97+aYbCHzk4XMFAuZqRYykRYy0yxEpluIzLAQibIQibYQmWUhEmMhMttCZK6FyDwLkfkW IgssRBZaiCy2EFliIbLUQmSZhchyC5GJ4H83x0xEZA4isuhfRGSlhcgqC5HVFiJrLETWWojEWois t9rKzxYyGyxkNlrIbLKQ2Wwhs8VCZKuFyHYLkR0WIjstRHZZiOy2ENlrIbLPQmS/hcgBC5GDFiIr EJF12FK2ISJ7/kVEDluIHLEQOWohcsxC5LiFyEkLkVMWIqctRM5YiJy1EImzEDlvIRJvtZULFjIX LWQuWcgkWMhctpC5YiFyzULkuoXIDQuRmxYityxEDiEiJxCRc9hSrv6LiNyxELlrIXLPQuS+hcgD C5FHFiKPLUSeWIgkWog8tRB5biHywkLkpYXIKwuR1xYiby1E3lmIJFmIJFtt5f0HZBTyARmFfkBG YR+QUbiFzG1E5CEi8gwReWO2FPM9jeZ542xaE5KTnmBRvAavzdvx9jyYd+TdeHceznvxfnwEH8m/ 56P4aD4Gxi5X+TV+nd/gN/ktfpvf4Xf5PX6fP+AP+SP+mD/hifwpf8af60XM9yjRY/QYfMFM89e5 vDqvThivxWsRztvyQCLxDjyI2HhX3pXYeRgPIw7eg/cAJdCT9yQq78v7Eo3354OJzqfxacSdb+CH iYdeWC+MswzeRJEySF9JvlJGKZOUWcoiZZWySdlNz+CMnuPsOiVeKeYmcuN8UCdzD/hkdmsPnxR7 5EmxDZDknWBvInlI5rPAckg5iGp9r4eUWkojeUpeUlrJ23z2Hezxy/cykoW4SG6SuyRLNklIdskh KZIqaZIuGZKL5CqZ810S+DYATsH8DJNKSaWJJpWVyhIDthUhXnweX8CX8OV8F9/N9/C9fB/fzw/w g/wQP/wlxM3ZMj6Xz4Ujzjd/18wX88WA9zIOPArI7YTvu8rvfTr6XNhrMWzdwDfyTXwz38K38m18 O9/Bd36pjvHo8/g8OPoCvsC8I5MvgaMv58DOcIaH4eimH+bR8xGPLx71C34gZlctzMzP/cnWhZ8z WwN8Tu7C1pDBZAgZSoaR4WQEGQn9ehQZjW8XHUvGkR+hl08gE8kkMpn8RKaQqdDnp5HpZAaZSaJI NJkFDDCbzCFzyTwynywgC4EPFpMlZClZRpaTFWQlsMNqsoasJetILFlPfgau2Eg2kc1kC9lKtpHt wBw7yS6ym+whe8k+sh945CA5RA6TI+QoOUaOA6ucJKfIaXKGnCXnSBxwTDy5QC6SSySBXCZXgHGu kevkBrlJbpHb5A7wzz1ynzwgD8kj8pg8ATZ6Sp6R5+QFeUlekdfkDXlL3pEkkkzeQ4OmrC6rx+qz Bqwha8QasyasKWvGvmHNWQvWkn3LWrHWLIC1YW1ZIGvH2rMOLIgFs46sE+vMurAQFsq+Y9HsHItj 51k8u8AuskssgV1mV9hVdo1dZzfYTXaL3WZ32F12j93nCnvAHnKVPWKP2ROWyJ6yZ+w5e8Feslfs NXvD3rJ3LIkls/dAQebd9pxLXOY2LridO3hdXo/X5w14c96Ct+KteWf+HR/Ch/JhfDifwKfy6XwF X8lX8zV8Pf+ZH+FH+TF+nJ/gJ/kpfpqf4Wf5OR7Hz/N4foFf5Jd4Ar/Mr0glpJLme1ulU9Jp6Yx0 VjonxUnnpXjpgnRRuiQlSJelK9JV6Zp0Xboh3ZRuSbelO9Jd6Z50X3ogPZQeSY+lJ1Ki9FR6Jj2X XkgvpVfSa+mN9FZ6JyVJydJ7WZfdRFlRTpQXFURFUUlUFlVEVVFNVBc1RE1RS9QWdURdUU/UFw1E Q9FINBZNRFPRTHwjmosWoqX4VrQSrUWAaAMpEFJ7SEEiWHQUnURn0UWEiFDxnegquokw0V30EOGi p+glekPqK/qJ/mKAGCgGiQgxWAwRQ8UwMVyMECPF92KUGC3GiB/EWDFO/CjGiwliopgkJoufxBQx VUSKaWK6mCFmiigRLWaJGDFbzBGLxRKxVCwTy8UKsVKsEqvFGrFWrDPf/Sp+FhvERrFJbBZbxFax TWwXO8ROsUvsFnvEXrFP7BcHxEFxSBwWR8RRcUwcFyfESXFKnBZnxFlxTsSJ8yJeXBAXxSWRIC6L K+KquCauixviprglbos74q64J+6LB+KheCQeiyciUbwSr8Ub8Va8E0kiWby3EzsVc8U8MV8sEAvF IvFUPBPPxQvxUump9FJ6K32Uvko/pb8yQBmoDFIilMHKEGWoMkzto/ZV+6n91QHqQHWQGqEOVoeo w9Th6gh1pPq9OkodrY5Rf1DHquPUSHWaOl2doc5Uo9RodZYao85W56hz1XnqfHWBulBdpC5Wl6rL 1OXqCnWlukpdra5R16pb1W3qdnWHulPdpe5W96gH1IPqYfWIelQ9ph5XT6gn1VPqafWMek69ol5T b6i31DvqPfWR+kR9qj5Tn6sv1JfqK/W1+kZ9q75Tk9X3GtGoxjSuSZqs2bRr2nXthnZTu6Xd1u5o d7V72n3tgfZQe6Q91p5oidpT7Zn2XHuhvdReaa+1N9pb7Z2WpCVr73WiU53pXJd0WbfpQrfrDl3R VV3Tdd3QXXRXPZXuprvrHnpqPY3uqXvpaXVvPZ3uo6fXM+hf6b56Rj2TnlnPomfVs+nT9On6DH2m HqVH67P0GH22Pkefq8/T5+sL8OozzsjizOgAFsWAQXG+cxavBvH9NK8J8f0sb8a/IXG8Jf+WxGMM vchDeSi5BBFvEEng4/l4co1P4VPIdYzsNzBu3cS4dQvj1m2MW3f4Oh5L7mKEuC8Vk4pTgvOmTFZk hTplV9mV+uHMaAHbFdtNels4RSH6EGdJnyrDlWmMKXOVrcxT2a+8YgVwrjQAZ0nnQbRPJA5QB5kg 5tcCBRQJEWALsDN8hTqUMGM/lpZgybxG40rSEB91LyyfVfdBHqfuhzxePfRp37NQ2k7soCW8SAZQ ALk+XD1S48z1ajzkB9WLkB9WEyA/qj4wP2mkNo9opDGPaHiaR8RjJeFRP16jccDSbkOBfK+hfrbF Bbe44pZUn23xwi1pcYs3bmHEAbXmhLrzZ+bbkkqwEoSxSqwS4awqq0okVpvVJrIyQZlAbEqsEkuE 8lh5DMdj8gJ2/G+KsZ9H2P+34+t/JsKaMfTPxs2/M2a6ibainegg+kAEMiNnRYiZNTCa1YXI9APG ySYQI83o+CE2Bv7JqNj3D+Lhb6PhVIiDv0TAlNHl/7Ro+CnaQVycAvE7ZVQsC+rD1B4flIepO+qA 8nht6Y63oDqaguKYiZojChTHG2i1jaClfmu2y4+xk3X+PG5qrloqzU1z1zy01FoazVPz0tJq3lo6 zUdLr2XQvtJ8tYxaJi2zlkXLqmXTsms5tJxari9G26FfjreGw1AM9U9F3SW/jbuGi+FqpPpN9N2r 7lP3Yww+9MUofBbicJwar15UEz7GYyON4Ykx+cHvRuWk38Zlw8tIa3j/pej8WWzWkv4D0bkWZTQ1 DGW9aQ7iQevQBiQzXinNQVvSQJKbtqftSUEaRINIIdqRdiaFaQjtTfxpXzqJVKCRdAZpSdfSoySA dWVhpB/rwfqRgWwAG0RGsMFsOBnFRrIxZBwby8aTSXjNcyqbzIDtcYw/k2vcjURxD+5B5vE0PBeZ z/Pw/GQT9+MVyDaM+Kcw4p/G0dsZKUY6Su7KqeRU1Et+Ib+gaeVX8ivqLb+R39B0NoCL+thG2sbQ 9Laxtgk0k22SbQrNbou0zaC5bVG2RTS/bYltDS1hW2fbQyvY9tmO0Ya2M7YztKUtzhZPv7VdtCXQ ANAGSTTQ9h60QYQoIkrQ9aKUKEO32HPac9Ht9jz2/HSn3c/uR/fai9iL0H32YvZidL95/YwesH9t /5oetJezl6OH7JXslehhe1V7VXrEXsNegx61N7A3oMfsje2N6XF7M3szesL+rb0NPWkPsgfRcw4Y 9tM4JUBpQ88rgUoHekEJVsLoZaWH0oPegzg7jd6HOLuVPoc4+4omq0z9hgm1hdqbtdaitKtsgD5G j2Q7P9zfAqPRZXjFpQVtZ61Zl2INJcWJzdIe2UDTFILtcyGZ+TJQBXPRmkubraXNsHQRknmXTW6a G1pNPpoPwp0/9YdjVqaVIbhUp9WJRKfQKXiXzT7SWvaW08k+cno5g/yV7CtnlDPJmeUsclY5m5xd ziHnlHPJueU8cl45n5xfdsp+cgG5ID1JT9HT9Aw9S8/ROHqextML9CK9RBPoZXqFXqXX6HV6g96k t+hteofepffofYlLEn/BX/JX/DV/w9/ydzyJJ/P3/8o6CVyRGM40SPhrhVR4NcsLEic+kCRALjt4 moeY96Xlh2QHVIuDTiwJSSGlIamkAqlINFIdkkEaQ3IhTUkz0IctIbmRtpDcSQdIHqQbCSOpSS/S m3iSAZDSQu9kxJu6UFeSDvqoN0lPM9AMJAPe0/AV9Nc6xBf6azOSEa/qZsKempl2op1IFrzLISvt TnuQbLQf7Qd9eiQdSXLSUXQ0yUXH0XEkD/TgSJIXevBako9uo9tJfrqH7iV+9BA9RArifFMh7HlF UFNXw1mnljjr1ArnwrxTzIXlxbupSrDmgFh65sf8QDkWYUXM34ixCrClGqsGyrEeqwfKsTFrTGTQ P4HEBsqnIyjHEcr3xK6MVsYRVZmnzCeuykJlCXFTzihnSRolTrlAvJQE5Rpo6r5qf5IRosgQksWM ECQnRIhZJLfJ5yQ/8PkZ4gcsfpEUBiZPIEWAy6+RosDnN4g/jLFukWLA6XdIceD1e6QEcPsDqKtf +5IPfanKgsGXDJ/5UowVgy2mR5zVgTGNhB7J6JENdF4zItAvO6i474gD/VLQLx39ckO/PJRlygrw aJWyjqRDH33Rx0zKLeUOyabcUx6BX6an+dBTP/S0CHrqD3FwLowT5sNoowx6XRG9rgzx6QWpDtEp CUYoH66+mr9ybIse5Td9NJ+0R4pbPua39skBvXccnfxpHaOL6ApY8vi0H/SAL2BQkgFuiISEdSsj HjbEQyAedsTDAbq3BVEQFRVrW0NsdKWp0pQYMDLvT1xg9DUe6nyiMo34wBhsHcmirFe2kiIwEntE SitPlFckEDTEcNIZ1MI40hvUwRISAbF/LZkEsT6OzMA6X491/jNE8CtkA9b8Rqz5TVjzm7Hmt2DN b8Wa3waR/RHZDtH9CdkBET6J7IR4biNHQON4kTOgazKSS6BlcpGboEpU8hDURSryBGK8N4wAgAlh hPQdIeYIkpQzZxlIXfNuG1Jf7aNVJEfgM+np1D+9Hz7t8m/a+1N7IAFYq05s83VStAfnL+2BNCCl P61jpBJeu/f4tB8jXJmuzIHv3Kbsgzb+WjV7DqzFUf6HM8mI5+C0zvLjuRYHNvsL7A6fTI1cSJAL KXIhRy6UkAtl5EIbcqFALrQjFzqQCxXkQhW5UEMuNJALXZALXZEL3ZAL3ZELPZALUyMXeiIXmr9t 3gEeaKwK30C+/sNrQYwq1A3OMhPNRQvQ4rQcrUbrwdkF0GAaSnuAfoqgI+gPdCJ8azSdR5fQVXQ9 3UJ30QP0GGBzAXC4TR/SZ/QNBCAb05gb82IZWBaWCzAuQnOB9zkAi7xom0EENm0LWgxtS1oc7be0 BNpWtCTa1rQU2gBaGm0bWgZtW/o12kBaFm07WgFtEK2EthNEddOG0NpoI2VP00rrZC+0sXJa0xpv 7appZXe7ZlrbHLuOdrPdQLvF7oI2ye6KNtmeCu17u5tpQUG5oy3jQvF7gmlOYCMX0BoMlvJA3gwU h6lfgJPAS2iJ4KMf5K1oAchb04KQB1DQMuBbYcjb0iKQB9KikLej5cz7T2h5yDvSipB3As3CwKsq kIfSqpB/R6tB3pXWgDyS1oR8Oq0F+TTZgzDwNzXksbI5+/LWDhUDnkKrBj8lyDfbQfOAjzbzjiq7 gDzZbof8vd1BGPgGCsxehuSEvtUcYn4niPV9yRAymkwk08kcsoSsIZvILnKInCIXyHVyH/jFuqYI LckL2noWaEtOWoSWhNZUhdaiDQCNVuBVJ7oI0IoEhBajbUGXoG1Jl6L9li5D24ouRxsA7G7aNnQl 2tZ0Fdq2dDXaQLoGbTt7etOCjxlMC15+hXaz3RftFntGtEn2TGiT7ZnRvrdnMS14nBVtGToT6y8K ay4aa24W1lwM1txsrLM5WGdzsRbnYc3Nx5pbgDW30KwPuwcinhoRT4OIeyLiXoh4WkTcGxFPh4j7 IOKUSC4E7yznyBUEezp1MX8mYj5NuBbe15+DFEAdgLNhNA22NU9sI17md5tHoWk/lTqYLcnkXuCT ydhWMDev0lFXYChCU8O4iiITMeQXM656kZG0IW1Mm9ImtBHtoDSBCNjsw9w06876sxFsEo/kC/kq 452RZCQb74FlZygzlSglWpmlxCizlTnAuNuVHcpOZZeyW9mj7FX2GS8NZnBDMmTDZgjDrrxW3ihv lXdKkpKsvFeB9tQf1fHqBHWiOkmdrP6kTlGnquvUWHW9+rO6Qd2oblI3q1vU8+oF9ZJ6Wb2qXldv qrfVu+p99aH6WE3UhGbXHJqiqZqm6ZqhuWi5tTxaXi2fll9zan5aAa2gVkgrrBXRimr+WjGtuFZC K6mV0kprZbSvtbJaOa28VkGraGiGbhiGm+FueBivjNfGGyOd4WOY10Gz4ciT4GhTBtVVHWJaMOsE yiEMRpUa6wejSh3vmzVwDOmCI0NXnP9NxVfylcTNtty2grjbYm2xJLXtpe0laEYYLxFPc7wE2uqS coPkNEdNoKRGgH4ori4F5VAeRvxxpAaM+uNJTdQPtVA/1Eb9UAf1Q13UD/VQP9RH/dAA9UND1A+N UD80Rv3QRE0G5dBUcwW1EIBqoR+qhYFGalALg8HPDaTZn6nRv1aDf0s9fawhBdEkiKYDcXRDHNMh jlnQ87zoeRH0vC563gB1UuMPo08Z3zYI5WrEnFsuRzKkbP+/bsW/3x4/tB04QipsKQRbCscatmF9 GlifLlifrlifqbA+3bA+3bE+PbA+U2N9psH69MT69ML6TIv16Q315knSWWevykaKszdA81o91uzz 2E4JtlOK7ZRhO+XWZzXZJcVnvUCVfGKBjz0dmQN7AbZkGVuywJZs/zCSpk/oC/rWUgOpWBqWjmVm OXlVuY0cKLeXg+Rucnc53MhoZDayGtmNnEZuI6+R3/AzChlFDH+juFHSKG18bZQzKhhVjJZGW6Od 0cHobIQY3xndjXCjlzHAGGQMNUYY3xtjjLHGeGOiMdmYYkQa042ZRrQRY8wx5hkLjEXGEmOZsdJY baw1Yo2fjY3GFmO7sdPYbew19hsHjcPGUeO4cdI4bZw14ox4I8F4YDw2Eo1nxot/funxz32f/7Zf eriC5m8nuxtvIeaX+VP3tUNPpMG2CynuQrabd+l8usfnf3Gfzqc7fOAYrBRrmWKmw1xTHRjo03wB fUZegkYvzPxhj/Kwrjaryxqxpqw5awtcFQqs18+8rvalZF5LS5ngKJ8n/98m88pbymRep/tiKv+r VMm8ivdZqv3bZF7RS5nAl99JEA8+S+Dz56nplxLEj88SoPR5aonpl+W2v0rtIQX/Tgr9UlKTP08Q tT5PaX+VMn2eLP8+nC8e4Z/5kd+ZH6HkEsTPkhDrq4DKboDPYvn4BBbzaSzfk3FkMox+YsgCsgzG PxvINrIHRkAnyDnAz4nXm/93c/+/lNf+K/kXZ0E+zJFoYCab4x5S1hwLQKxLg6MH8zoLpTlhHM0g 2k+C8mT6E5SnUPMN4jNh5MXoWvrIfAotfQLjlUR8D8dz+gLKL+lrjJlvofyOJkP5PTPfgsKYBG1O ZjYoC2Y+uVVlMP5mOr5TxJXBGJu5MQ8op2ZpoOxpviME4mo6KPuwjFDOxGDkxrKYbx+BGJsTyrlY LijnZrmhnIflIeZbVfJCOR8z3wY0jU2D8nQ2Hcoz2Awoz+SV8UmyVQnn1WR381l1Mvgre8sVzacr ypUJl6vIrc1nhctBUA4230wMsTocyj3Np1bJQ+WhUB4mbyPmW5a3Q3mHHZjZzmAUyezZHB0JdXRy gNJzdNYXEqov0mHUqy/Wt0N5h74byntAqVIjA+gMDmryPY7wgJVdmEvGD7+zxpphJMD6dfAvGoSi BqGoQWiKX7FS1CAUNQhFDUJRg1D87QlFDUJRg1DUIBQ1CEUNQlGDUNQgH86QoRKhqEQoKhGKSoSi EqGoRCgqEYpKhKISoahEKCoRikqEohKhqEQoKhGKSoSiEqGoRCgqEYpKhKISoahEKCoRikqEohKh qEQoKhGKSoSiEqGoRCgqEYpKhKISoahEKCoRikqEohKhqEQoKhGKSoSiEqGoRCgqEYpKhKISoahE KCoRikqEohKhqEQoKhGKSoSiEqGoRCgqEYpKhKISoahEKCoRikqEohKhqEQoKhGKSoSiEqGoRCgq EYpKhKISoahEKCoRikqEohKhqEQoKhGKSoSiEqGoRD4+o+TTE0vSdQPrgWtJuo7OiHTtbY5cw6oM e6lTwaIj0jWBVQ0YpX6q02GTcxucecvE2dqm5LZRiUYUZVSKru+s68yTYo1PTIaBPnhJqSSpTQJI NxICJBpIwuDfvMRU2pkxxcEkj+xidm3/p3lH3ilHvb679/35O+U3HouOSJPLGSG5OSPYm2jOKANy 2E5GlSw5ItXx0i/a3E/42ql/OlMqwTmF+uV25rTxhpLqnql8SGivrkHtO4T55miT09evWLGivjWD 2nQN6RbSLsy3fEjX0Hx+GZw+H3ZO/fmWkK6tw4JCuvhldH5lbufuXr9srxcSEuZbtntYh5CuQWG9 nBk89WJFnX5+TmdRJ/w189QLOP0KFPSzFv8LZxRBM6WExXxTVQTQCqxXWASlZCHbvD30ZonEWuly RP3Us6XzbszCMVm/fZU8qcbs2OQZMb6l+9aNmRYztlWBjsfLte31cEmP/Q3OJ96bPsxnbNSQdqt3 d+wdkPlM+pKXXOj425N3bc3bLjKyQ7apx4rn2aqtbZJte6VbSmn/yXkW5ii24H7VweWuDXHZGNmp YeslEX1ntcobXuPO1DVtS0TW8fGzZ/GIWnjrx9xeN0tNaePRqokcGJW+aL3hL+c/msj2pDu5tWHF 1SMHbi1+v8HEWsuS5vfuHFZrudehyY4cGUnjca2Cim6s7iZKNnr/zds57RT7vBODGjV+tK5EyzSD wqXzL7YsGzgpecXhAWfme3dtXvLApsf22Zmcq21D96/2DXcfmsA4NPzZgxY4B811DooBNNNTaVCk c9BPA12/ORb6KKjrzMx1+3usqvnD+4Ozuv7n6y/iD9o4N+tw0m1125inP3kVfrCeZjkXnupp81YF omaqB0vLP44Yu7/4zYyJjxtPyLM2uvK+gEfvzh4qUaLZwiINgpKzdC6z/9CiS3Lfi35jSkW5hgZv THar7RW07d2x8tdSNfOtfTegz/JFafflLpo175bAWW7fZ3VpM/tlA5/XGfefSf203pIu5QuIpAjP Vzfad9Lrvtj8pN7ezbd2Od/5+jlGpJ+U07vm6fRs7pOBl/mab56tvLiv8cPAqnvrNVi3hudwez/u zGP72P7rf9q9uGie672vLwi/1iOaHAsus/1Eke8vl3VbUDg4XXB84SunfKTrCypK+5oV9O9S00cP iFViRp883aBMpcM+DeeFxrsVHz6he9T8E9HACq2cEbzGB1ZQ8i1OdaHO++YzDm77yCnp/1tkAP3e vwD8AQMUADLwKwCLhT+SQS9kUDiIzZ01rO/n7kxlLtjdlcatu3UI6tI+DL7G1WmYK4W7qBfYtnNI l7YfT0z5vRPL7Mz44cS8U25vG+hbP6h9Fziqb53yZf+QFWJ79TvTYnXFYgsKLfE7/zpr4arh295+ NXNvxe8eHa90+9TonR1r1At4NpXtrHmuaqf8WUoHbj2SOVatEjug+8WKmxeNNerszpo7MfqWnvmr 42WzvAmYejRtxbkTqn019fDq/Jl2VsvbNyQudYYSo4u5Fru4OeezdiXy0gLvk7NXmbe2Ex0+/e2G VW0GRLxuHj1oyNAfViSunzj7qP+8OkM9sw+vddH5gpR6tud1qUFbhj3oVGx+vkIv1uRbrvQL+LFn u+lTuunDlifueur7c223MW0O5okrUDHtw43VJpeoU9/rSLu6vRYtHb6vUemoiDojusgrC2/vk2Vz vXalptY6lLt/wS5DKtuOzzxWbRjrMozM2TY8ob7FCm+cg1463U1SyCppTsVmh4Amy4Lz/zuowsU8 R3fztZOyk4NxpjdXGFIayeNQ+iM9SOg3y5+c31Ursm6FfLMrtHnsVM3NLpIE3WhYiq6DHNNn8bL+ 1bIlHtlUKyymSfawXN1XD0taXGNiT1LzzoF7XheCdhsxfZ+y8nsODD/0qv6hHVGbG4U8blNhYQXy cPK+yNM+69WotPrEs+czLM3Z79GDed2WjL1U7IdSU4I3+Xc+MWJ55qSEO2eCHD+O2Jx8hWws9PRl 39eubvnkezknTyjXMcd3sf5jLwt9f4sOhzcPLNux3YKNsRt/KHQgkbv27f38xOVyCX2Sr1xZkvwi 4bS+OvTM+Gu11/nH9M17qlR8ITWgKIsaFJx55IvmbcauaLax2NlWoxsO8S74vMSU6Agt5ttRq/PE zpp7cPF533VbnWmH+nrouTbVe1b2ckvntfE5goZvD736dP7iIwPLde1hAMcEA8fUszimtUvPmqiQ eMp+JAPP/Bd79UfCKeh0AuMUBMJxFnMWMBcLmovOsL/l1Kzt/He2/yHXxMQrY47u2F512uFFxQst zdy0Y3ynLRkzxU7cd3fZ1j2ns+0okGrUpvMt8rwt0ihD6tzLxuoXPWZ3yVFjQJoyZZeM+XplpRF6 3KCJS3+yHWtcoUfzu0/eGVcHhM0ueDDsxqNrrWf157EV358u7XZ6xYGW+rE+ibHu+rtWwTmGdh8d u3TT0Nuea8ZteZ5mXUCLB6kSij/M+M2o5QO77ax4bdLI8FbTbi0N3150TEGP/O7xAfuXeS+sPaX9 0lO+xZzfXR7TvtLVPT7P9DphZfPflrMEZ+xYdcX4XauK7S03t3Nzr2qLx579YXDpnkrlc3NWDcm8 82pin3Yrq4Vtzla2+vTWHq1qOfdFPD2mhvZ92LBm+Al7wx6DLK555Rz0HLFP72L2WOiEtm0pOuzT jF//0LfuqwbVp9zwPBs8uJCcL9vtL1OTyRPpM0tezjQDv9zNK5g7fCWVcpZwFosuGl14WMEOYWGh xfPnb9O1U77OH+swX5uQzvlDOwaZa/OHdg1p271NWLf85etDQ8sHq5xVPn4l6JCSzuJO/4/LTjYs j3XA8PDwLx0wsGuKI4X9qgMh23zdOKR++5m+gwtR46Zn9ZJL750bNOCh3issvPZPlb2ektRB/eMD xsUktZ81/XqOnG8anp2aXGdrS8fqn+c9iHg6JUNI0zfPn1zRTo6yl07j6Xt829qKle3ZWjV2VJ/4 2H5oQ80uj69WcctReFTGrgnfrlse5JZl4sM7hRzx/buEjFfqHchVo+qiAnmG3Z51qEW2TZtKXv5m 1WB1Q2Gf2kMqVn6/ceKspmLh5Is9NzceMHd+rUOJS6dHlr16sHmW0hcGFKpc68XRfX1m3Fu3f3ob j/rLl0Y+Orv1aPSsxZMO9M49PM+2vXHvOvHzW/2XPjnePK2ny7aXBwbOc7V7XxyX+daKWTVK312R KltPY3uen+d03Du2JLDNDGCboR/ZpmrfB8g28n+PbRoEdQ7sFta6c2hKtiniLOZXxOlXuHABlDd+ uFjAaS46B837W84tuzPrh0CZoUv5oNAOgV19K9Sv6Fuxfq3ifs4K/nkL+xcqmrd8uUr+H3fk7hl+ x4n6gV17BLUJ/EOCurvhf8aafOJm5boWF7ulm4+89Zmnct+yTI7zmpFXRMUl7ZtL2Se8f277e69a zeLfT2vrjM7ftO22NP/044a1idiVSU2/Td5ktBZJ9T/Y4fNgR+tnYy6mg4vKik19Yj9uf+hVK7tj SsXt/3Ktok5uhefq1cOFLjb7W5//de9b91t7hsdX7yX+FO/1XtJo8zXT4dXDzv3s/rtKql/yPHV/ tTrn49X0Ro4fYqdqhXcXP+L0+ZX0++0Cy1lW/14LnkiUS4q4wRXSfNXa2/tR6F79BKm+SazOt2Jf N3EpT+dcwGqY2j3ZT85RcdGkCX9dXVzzTTe6mq/NXJn608R5o/gha8uHAj2fpNofhwTIW881XItc QCEKpLqiD3r2YZoPVL9n7GD84/2w7vxjO5SyJ/+Fn/30nSarvdv698x5tcba0fnYBYrKnpLiguRE qpQ9MJNKsJWgHBilMJYCKrOqiZNH7OK9826devsvmlQ11qtrOGp9vqw4iW/62vjgOM2fbw+GeK2o /S58gVvkp++nNlGGvMfNshquy3Usje7mzzKPeqcc1B/C3Gu/fE6KxTezEyLO26zsZpzkPVzYqPE5 bbnho5jY/p9BQQ9jXk+eMDeT06fz4sUyHxPerIc1Lsu1o5tD6l1VJFWPdLkdVX0s2ZCpKfJN/NgH JZ1GtzjtLz+XHSu3U87/uSyltW9REu9KXbkVTyfY1f/f0Pdn+puPf1nWn/U8F1Wy5tdnYXlpy3OL t1zb82XLuxNrP4XJ/bb5eOKalsue/XPsa9Mkzm5SSOY65WCbaiRZs2mH7UE1Dz8lyZl5PQYHP05E LaAEsrhn+h9gUF0teNtVPqIqfRF6MTUwnS9o6WRgYmIOKp0sgdwB6HxhFJyEyps75nm/159w8iqU OHHOwy74wK/VIrt0jHYL+QedaH5rZ3zT03CSxraJKQ/kA1p2HfK+WM/6433pvu7jK66uyyxIq1BP e7Ft+/vWnWffrfortIQ7UklT/7zDzTAW6bKtuSm5XiG37368t39+8/GG+/U+TOZTvh6YxxEml+F+ 9uaBshj92m2qLFvCorNkkv831Ni8u8qi6mtZXsIeeyjmRpu5TulJvldylpw1Zf/m5uRVPXhj1z99 XiFfvJa/RFKC0bxLzX7aSjEZrt339FsEAjb93CrVm/NOdbbwj9MC11v5vjSVFZsdm1q16EwC2xvW DW3G239MiW5xbIlonZK3QV7H40z+HOcHWS/q1fqyIeVNE6MGMERUsOfQIdH9EmDjhA6AijKC+lQM SKUn1sJREq5BhImFR46LIZihlCGJwZnBEbVrhtGvw1JATfEVNDxUE7BbsG9hIjsjX0+Ba+/74pC9 9pysuv93BAa3yry1nLh9cRj3vZ5t1tIXf69ZfnL7xkBF6XyOzLps5kVKbm9ztuTWKO1wu9zyuZd/ H3uX2cHXdS8LYl3nT7p05tzdvgMP92udrXlzcp3R1fadp5OPmF2UUNxfds961mbp4nmKHTe2bBEK 6fky51Cq1ywNtTkJXfzWx4VTKzx2n1/bbOW/ISninsHLl5ayjzs/3bJs/Cms2JPSkMzGMu3TLCZn /Wq3jl3/mW6m/vS6d4u5ZPJm1jyeM3PvaCTWeHwUnyOoaMEk076G7eg0ox1PHY4F2+5d2XnvRZp5 7xelaXPObCgPCbS6VuSySfmbYRPLemAhtZqJkdGgsX0Ae2UofUXEGPeCxlsGIvD41mA0ZGdmBa9e BqUCaGRyMhvyIA+rA12D4HEb8hkgy4oaKCM0shgC09j3fi/2Ru+J97ZyzArY0Ln/r4b/xK0GKUha eAzDDEIWaDVoMPgyZDIkMxQx5INH5tMYShgUGEIYKhkKgLx0oHgikJXBULlQrUEFZ/VaUlmQn16U WJBRqYBWvLE0MTIo7H+2I1KSwUpkllSH77nPUzfMmeyw6BWfcTjLO4titz9/Nq6b+f6BweO6rq+v vzBXf70a8/NrydwG7rzNt9bpM+exFLxivvZNvFP3QMtU86Xn7Vpiw/kqT96QvLH/r3H3vDubFRZt d3u9s27+2/UH7I692u9y/6Ljnh8vRSS7vD9OZnQ9H2/M012/rmexc++JP37/k9dOOnzWUD20eEvC 9oks30/ylq3zqFjHNKvh1LqJJmZqx56l8CzoYzqZK1+7ri7M9Mhl4ZpNTkpTZ56v8isoW7xO+6jS 86ri67EL+he+D/c3ZNIWKHP5NcVNJmmKcHV/zZMW5QeLZ/uZsxzzSVv1YumtpRHKtZ0GF+VFFjYx yRs0MUkj4ojNsImJByjEQfckil4joXQw2KFJdEGsgQRySuRGzAIxAu2Ey7Aa8gOrWgtDAyNgRWtk aWwahZEQmf6r8N3fltgbqxdv0OEq9XX9gzc/0MosUBK5P/2wF4fu/R0npZfdVGQ9zvMmrU3lvxPT eecPe08sVCib9mjPw8l9Qg6P1LQWLZvYndgj8fOM1sYAqfYf1RNfBR91eLFbN7b/nMuklLywBFUn 7uNtTA2O75RmVh81qgp4l9Px5JeZ+Ndj3ZOSZENmXXkqLLTw2tx13/+HWzG7v7z6LuJzmp1junfc 9n17b7bqPgnfcWLi6qTCLPvlwhyHzmufKb03s6uyoqB5rdusQ5ubO/3crbSbgxWNVvx7ddy+pIzp wLpVRcGxOzKO1702tM2Ypd7weQvbhueXdwjqNF3K2b/+fuGmF81JK7Yxlhnc4nMI3hTN+vn7FrMU 1mBF0e50tzyBrNxI4aC8LbwMAHYqKkUNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMDMgMCBvYmoNClsg MFsgNTA3XSAgM1sgMjI2IDU3OV0gIDE4WyA1MzNdICAyNFsgNjE1XSAgMjhbIDQ4OF0gIDM4WyA0 NTkgNjMxXSAgNDRbIDYyM10gIDQ3WyAyNTJdICA2OFsgODU1IDY0Nl0gIDg3WyA1MTddICA5MFsg NTQzXSAgOTRbIDQ1OV0gIDExNlsgODkwXSAgMjU4WyA0NzldICAyNzFbIDUyNSA0MjNdICAyODJb IDUyNV0gIDI4NlsgNDk4XSAgMjk2WyAzMDVdICAzMzZbIDQ3MV0gIDM0NlsgNTI1XSAgMzQ5WyAy MzBdICAzNjRbIDQ1NV0gIDM2N1sgMjMwXSAgMzczWyA3OTkgNTI1XSAgMzgxWyA1MjddICAzOTNb IDUyNV0gIDM5NlsgMzQ5XSAgNDAwWyAzOTFdICA0MTBbIDMzNV0gIDQzN1sgNTI1XSAgNDQ4WyA0 NTIgNzE1XSAgNDU0WyA0MzMgNDUzXSAgODQ1WyA0NjNdICA4NTNbIDI1MF0gIDg2MlsgNDE4IDQx OF0gIDg3NlsgMzg2XSAgODk0WyAzMDMgMzAzXSAgOTIwWyA2ODJdICAxMDA1WyA1MDcgNTA3IDUw NyA1MDddICAxMDEwWyA1MDddIF0gDQplbmRvYmoNCjEwNCAwIG9iag0KWyAyMjYgMCAwIDAgMCAw IDY4MiAwIDMwMyAzMDMgMCAwIDI1MCAwIDAgMzg2IDAgNTA3IDUwNyA1MDcgNTA3IDAgNTA3IDAg MCAwIDAgMCAwIDAgMCA0NjMgMCA1NzkgMCA1MzMgNjE1IDQ4OCA0NTkgNjMxIDYyMyAyNTIgMCAw IDAgMCA2NDYgMCA1MTcgMCA1NDMgNDU5IDAgMCAwIDg5MCAwIDAgMCAwIDAgMCAwIDAgMCA0Nzkg NTI1IDQyMyA1MjUgNDk4IDMwNSA0NzEgNTI1IDIzMCAwIDQ1NSAyMzAgNzk5IDUyNSA1MjcgNTI1 IDAgMzQ5IDM5MSAzMzUgNTI1IDQ1MiA3MTUgNDMzIDQ1M10gDQplbmRvYmoNCjEwNSAwIG9iag0K PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMzQ+Pg0Kc3RyZWFtDQp4nF2QTWrEMAyF9z6F ltPF4MRdtItgaKcUsugPTXsAx1ZSQ2MbxVnk9pU9wxQqsOGh94knyVP/1AefQb5TtANmmHxwhGvc yCKMOPsg2gact/mi6m8Xk4RkeNjXjEsfpii6DuQHN9dMOxweXBzxRsg3ckg+zHD4Og2shy2lH1ww ZGiE1uBw4kEvJr2aBUFW7Ng77vu8H5n5c3zuCUFV3Z7D2OhwTcYimTCj6BouDd0zlxYY3L++OlPj ZL8NFff9HbtVo5Qu6rGtqr2t7MVVppRlrxHtRsTp6kVqrBLIB7weLcVUqPJ+AYpQcd8NCmVuZHN0 cmVhbQ0KZW5kb2JqDQoxMDYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNDA0 ODUvTGVuZ3RoMSAxNzYzMDg+Pg0Kc3RyZWFtDQp4nOydCWAURb7/f1Xdcx+ZCbkTMj0ZMkoGCOSA EGIyOQEjciRgogQSIBKQIxBAVJC4imA8UJ+ygK54rIonk0Mcgi6ssK4il4p4rEIEvBdBnwdypN+v egKSt8mSkZ2Xv3/qU9S37u5fV1fXVCWZBggAhKOIUJ1XNHyoEKULA7o6DTMXDc3LL7jjl7uHA9n1 KAB9beiokUU3jXtuLZC3pwA8HzW0aGzO/pzy0UAX1wJEr7q8qLhgZsI0NbaPwKPGXlFcNKx3iPk2 gPgWAFPZyKLEJEvS4tUA5DiWl4/KvaL49E2ZuXj8KkwPHJc3omTU/dN/BEh2A1gfmDyzovqZgZcf BbJ0EbZ5bfKCedJjMe9/A2R1NYC6+NrqqTN33FC6BsgyrK+eNbWiphoiQIfHK8HjWabOuOHaveqH ZwFZuw1A93DVlJkLvz719naAvL1A3OuqKium7J9TfAyPvYidvwozgpNNKZhuwnSvqpnzFuZEUiyj eDzH8hmzJ1esefPhX4A8Uw4Q1TSzYmF18CyjCet/gPWlWRUzKwtvdCwEsi0EQN+renbNPDkBVqI9 aay8em5ldfy+EZuB3O0BMPwFWN+rIte4P54VPzEo40dttBYYjx+6JIGFbz7/5qYT609PtYDWiEmd Up+BoSaz9UrItcCJ9SdutMDZkjbE61iOqRRigSoZFCyQCOOw5Hk8L0MQlpN7QQVa1RpVMh4g2hcK b8O1NFiroga1SBliCyTIW2BhrmIBUjwiVwI32KU41buto0myJpM0uIHIsoxHd6o2sSsFUd1mEh0M Z0IPfR8mwO8E9bOwKlDHFmug4Le0o8/C0v+0Ld0B3Qkzu9uGriDWyKe62wYOh8PhcDic/yvIOrm5 u23oKqro34+tHA6H050QkJu16C3A500Oh8PhcDgcDofD4XA4nN8/plINIfCcuust5nec7WiX8uN4 frfw/9gczlnI+av8hqqc80AI700Oh8PhcDgXBwIIhKESBEJxDRSh+qdhCxzXyqAFrdwKOtDJp0EP elQDGFCNYEQ1gQnVrGgQmFEtEIRqRT0FwWBF7QHBqCHQAzUU9SSEQQhqOISiRqCegEgIx3gURGI8 GqJQYxTtCdGosRAj/wI2RSXoiWoHG2ocSKgO1OPQC+yo8RCH6kT9GS4BB+ql0Au1NzhRExR1wSXy T9AHLkXtq2g/SEBNBBdqf+iLOgD1R0iCfqjJkIiaAv3lHyBV0YEwAHUQJKOmQYr83zBY0XRIRR2i aAYMRL0MBqFmQhpqFgyWvwc3pKNmwxDUHMhAzUX9DvLgMtR8yEQtgCz5GAwFN+owyEYdDjmolyta CLmoV0Ae6ggokI/ClYqOhKGoo2AY6mgYLn8LYxQtgstRi6FQPgJjYQTqOEWvgitRS2Ck/E8ohVGo V6MegWtgNMbHQxFqGRSjTlB0IoyVv4FyGIdaAVehTkL9GiZDKeoUuBq1Eq5BvRbGy1/BVEWroAx1 GkyQv4TpUI7x6xSdARWoM2ES5s+CyaizFa2GKfIXMAcqUefCVNQaRedBlfw5buunoS6A6ajXo34G C+E61BtgJuqNMAv1JkUXwWzUxVCNejPMkQ/DEkVroQb1FpiH+geYLx+CW2EB6m2KLoXr5YNwOyxE XQY3oC6HG1HvgJvkT6EOFqHeCYsx5y7UT+FuuBn1HliCugJuQb0XtQXugz+g3g+3ov4X3CYfgAcU fRCWoq6EZah/hOVYugr1AKyGO1DXQJ28Hx6CO1EfhrtQ/6ToI3AP6lpYgfoo3Iv6GOon8Djch/oE 3I/6Z/gv1CfhAfljeAoelP8BT8NK1HXwR9RnFH0WVqE+B6tRn4eHUF9Q9EV4GHU9/AnVA4+g1qN+ BA2wFrURHkVtgsflD+EleEL+ADYo+jL8GdULT6JuhKdQmxXdBOtQX4Fn5PfhVXgW9S+KbobnULfA 86h/hRdQX4MXUbfCenkfbAMP6t+gXn4PXlf079CA+gY0ynvhTWhC3Q4vob4FG1B3wMuoO8GLugs2 ou5WdA80o74Nr6C+A6/K78K7qO/AXvgL6nuwGXUfbJHfhvcV/QBeQ/0QtqJ+BNtQ/6Hox/A31E/g ddT98Hd5DxxQtAXelHfDp7Ad9SC8hXpI0cOwA/Uz2In6OexC/QL2yLvgS0W/grdRv4Z35J3wDbyL +k9Fj8Be1G9hn7wDjsL7qMcU/Q4+QP0ePkT9b/gI9QdFf4SP5bfgJ/gE9WfYj3ocdTv8AgdQT0AL 6kn4FPWUoqfhkPwmtMJhVBk+Q+VzeuDn9O9+53P6N12e07/qZE7/6l/m9C87mdO/+Jc5/fMuzOmH z87pc9vN6Yc6mdMPKXP6oX+Z0w8qc/rBc+b0g8qcflCZ0w+eM6d/+i9zeosyp7coc3rL73BO/7Cb 5vS9fE7nc/rvbk7/va/Tf79zemfrdD6n8zm94zn9jf8P5nTAGRdM4w1hWhCAil3/UY624+z2v4/2 43h+t+C/+eZcALTrVTWBs+KigxjCutsEDofD4XA4nEBjjNCxX3z7sRfSdZzdfh0ayL0VX/FyLgA/ 9lad/BiB8xugxojuNoHD4XA4HA4n0Jii9LitEVRdb2HoOPtC91Zdt4DvrTgXgND1qnxv9Z+DmqK6 2wQOh8PhcDicQBMUa8CNkOrC91bt16F+HM/vFnzFy7kA/Nhb6QNnxUUHDYrtbhM4HA6Hw+FwAo1F MrK9lR/fYTJ1nN3+TwX931t13YJO/iiRw+kKfG/VLVCL1N0mcDgcDofD4QQaa5wJN0L/8b1VIP8X B7634lwAfvy5aie/ouX8Bqg1rrtN4HA4HA6Hwwk0PZxm3Fup/fgOU1DH2e3Xof7vrbpuAV/xci4A P/ZWxsBZcdFBezi72wQOh8PhcDicQBOaYMGNkD97K2vH2e13PP6/b6LrLfiKl3MB+LG36uRXtJzf gBCa0N0mcDgcDofD4QSaiP7BuK3R+vF3dj06zja3S/n/vomut+ArXs4F4MdXATv5FS3nNyBE9O9u EzgcDofD4XACTfTAEPbfwvvxrf3wjrPbr0P9/05U11vwFS/nAvDjz1U7+RUt5zcgRA/sbhM4HA6H w+FwAk3P9DDcW+kufG9laZfy/w1rXW9hOW8NDqdT/NhbdfIrWs5vQOyZ3t0mcDgcDofD4QQayR0B OjD48X6I6I6z2/+M3//3TXS9RbDfx+ZwzuLHVwFDAmfFRYcoubvbBA6Hw+FwOJxAY8+JZHsrP94P 0cneqv2Ox/+9Vdct4HsrzgXgx94qNHBWXHSI9pzuNoHD4XA4HA4n0MRfHgN6MPjxfghbx9nt16H+ v8uv6xbwFS/nAvDjNSsRgbPiokMVf3l3m8DhcDgcDocTaBKKJdwImf14P4Sj4+z2X8Myd1zp39B1 Czr5wheH0xX8eM1KJ7+i5fwGVAnF3W0Ch8PhcDgcTqDpN94BJjBbut4ivuPsqHYp/9/l13ULos5f hcPpDD9es9IzcFZcdKj7je9uEzgcDofD4XACTdIUJ5jB4sd3mHp3nB3TLuX/26u7bkHM+atwOJ3h x95KCpgRFx/qpCndbQKHw+FwOBxOoBk4ozcEgdWPt0337Tg7tl3K//dNdN2C2PNX4XA6w4/XrMQF zoqLDs3AGd1tAofD4XA4HE6gSZ/XByzQw4/3QyR2nC21S/n/PwN1/X3X0nlrcDid4sdrVjr581fO b0CTPq+7TeBwOBwOh8MJNLm3J+FGKMyPN6IN6ji7/To0zG9Duv6GCr7i5VwAfrxmxRU4Ky46tLm3 d7cJHA6Hw+FwOIGmcGUahEK4H29Eu6zj7IR2qUi/Den6GyoSzl+Fw+kMS9er9g+UDRchusKV3W0C h8PhcDgcTqApeioTwiHSjzei5Xec3a9dyv/3TXTdgn7nr8LhdIYfr1lJDZwVFx36oqe62wQOh8Ph cDicQDPemw9REGXveovCjrOT26U6+Q+G/w1Sl2smn78Kh9MZfnwVcEjgrLjoMI73drcJHA6Hw+Fw OIFmyhuFEAMxvbreoqjj7LR2KT/2am108l8Sn/dMHI5f+PHaFnfAjLj4ME15o7tN4HA4HA6Hw/k/ QGjzMUCU9AxMYYzMBRFGAfuCikUpj4MRMAXmqt1SDylOloHtoNrlyId87pSn5ZGWyrajtYOo4Ww2 oRSA/u8K6EVV123v33H20HapsV0/3hmWdb1qvb/H/o/3qjt3bHG2Oyvzsowh6YPTBqWmJCcN6J/Y r28fV0LvSy9xxvdyxNklW2zPmOioyIjwsNCQHsFWS5DZZDTodVqNWiUKlECffEdBueRxlntEp2PY sL4s7ajAjIpzMso9EmYVtK/jkcqValL7mm6see3/qun21XSfrUksUgZk9O0j5Tskz848h+QlV48u wfjdeY5SyXNEiY9Q4vcqcRPG7XZsIOVHVOVJHlIu5XsKFlTV5Zfn4eHqDfpcR26lvm8fqNcbMGrA mCfcUV1PwjOJEqHh+en1FLQmNMoT5cjL90Q68pgFHiE+v2KKZ9Tokvy8aLu9tG8fD8md7JjkAUeO J8ilVIFc5TQeda5Ho5xGmsauBu6U6vtsqbvLa4FJ5S7jFMeUivElHqGilJ3D6sLz5nnCbzwc8WsS Dx6cW7Ls3NJooS4/YprEknV1yyTPo6NLzi21My0txWNgWxpfUF5XgKe+CzuxsEjCs9GlpSUeshRP KbErYVflu75KRz7LKZ8ueXSOHEdV3fRyvDVRdR4Yc4O9ISrKvVFugah8qa64xGH3ZEU7SivyYupD oG7MDY2RbimyfUnfPvUWq69j681BbRGj6dxI5dkyJaZUZ7HCMWd7ljCLHMNxQHikyRJaUuLAa0pj UpkGdZPTsBpSSrCVZwrekWkeXW55nSWd5bP2HlW8xSHV/Qg4AhxH/tk+p6ItRx1v+RFYlI2Ts0MN y8/EPS6XJyGBDRFNLt5TtDFTSaf27bPASx2OaouEAXYfjMK+rShNT8Tut9vZDb7T64ZJmPDUji7x pSWYFN0A7kRXqYeWs5ItZ0pCx7KS2jMlZ5uXO3AkNymPdKhH6zz7L8gS1iO/Kt1Dwv5NcaWvvLDI UTj66hIpv668rW8Li9ulfOVpZ8vaYp4euSVCNG2L0WhBKcVBOf5sZZYoMXrEePynVgb1FK9Gi6NS ySFSgcdSPsynpXq7vYuNvPIx1koJfm3WZqYn3dU+PaRdup15xjoBDRadtLD46ro6fbsyHGq+Ew5v C3DEQ3GJXcr1wFh8MuPxn1feksZ8abTHjV2Wyyrg+PNltSXbVYxui5cibHT27VOAE11dXYFDKqgr r6vwyrWTHJLFUbeRvkZfq6vOLz8zcLxy853RnoK7SrGvqkg6PhQUcuodZPnoejdZXnR1yUYLgLS8 uKSBEppbnlNa3wvLSjZKOLkruZTlskyWkFgCCgleZAPVKvWjN7oBapVSUclQ0pO9BJQ87Zk8ApO9 1JdnOZNHMU/05bmVPAabY3KLS84dPcojWdoXYCMUC5c2OiNse14RekMLeir0bnD1tG0ULhF6Ngyx ub2CozE4NCkou68g4TkTFZVQZ6Nfj34zehEmCrGYb0Fdgr4W/Xr0m9HvQY9rBVRWKqGfjX4t+hZW IvQUYhokmyX7EiES20biNQQJ4XAUvYxeABtqIvqR6CeiX4F+LXq1Uo/lzEa/BP1m9MeUErcQ3nB/ Mtoe3nCnEjROn5GkJCt8yfFlSrLxqlJfOGK0L8wb7quW7qs2IMWX3S/HF17SxxcGxyfVslBvStqS HSaE4UWGoeHVqIRugyBCwAaPCqHgQU8FdVuOWwhu7OVMWrtZEIEIVCC4OLDJWwTSYLImZeupTI9C MNjot/SIr4QeaTRbk9ZmX04Pwnr0m9EL9CC6T+mnsIS2sD5HzUK/Fv1m9LvRH0Wvpi3oDqDbT/dD EP0EEtFnoZ+Ifi36zeiPotfQT1At9GM2PynK4lnoKf0Y1UL/gZf1D9Qg+hHGPqIfoWnvNgwanLRR ibgS2yK2+LZIeHRbJDgsyUvfafilN44oJ95pHFGbhDjIhGQhriF+gM0rRDRkTLN56aFGyWV7NLs/ 3Qse9GxBuRfPvBck9KPQl6OvRq/G2D6M7YNa9PeifxS9Bz2OMlQLeoluR78D/T7oj96NfhR6Ld3T gKfx0t0NzhxbdhjdRf8O4djjO+kbSriDvq6Eb9G/KeGbGMZiuJ2+3hBrg2wDlgO2sWBowTARy1X0 r429gm1ytpVuxr6zoSaiz0I/Ev1E9CvQq+lmGtcwxRaMB9kE27WANRvgKyV8Ch7Xgnu6ze3MxQEo MXGmX4YxlLXSWid1O1euxiQT5z33Y4yJ87a7MMbEeeMtGGPinLEAY0ycU6ZjjInz6okYY+IcWYwx FC995OVel9gGjbyOSNlB9Hrspeuxl67HXroeRHo9c/CLyGx7qCEhAXtsjdvVO8FW20xqXyG1Y0jt 46S2ktTeTGpvIbUZpHYCqXWR2hhSG0tq3aR2E0nDrqgl7qZ2ycHuCFK7ndS+QGprSK2T1MaT2l6k ViKD3F5qbxierAT5StCYzR46DC/LxNkniNqxR+045u04J2xG3Y1eVlJurCTF+SpHxrIwrjEhy5fu l540O3sY3YoNt+Jt2AoH0It4g7biMNqKB9mKBwhCzUI/Ef0W9EfRy+jVWDsODV+haBBqIvos9BPR L0F/FL1aMecoegqz20xcrxiW2Gb0SJaiW9HFobNTu7unJcbisgwTVsSQoFgyMlaOpYMgjL02MNiq tXqJacPPpuM/m0CXraP30BXQE2/EvW3hioZfetq8ZFWDc5MtO5T8EWJFHHVkMDhJPIZpUKOkUyFG y8IUiKHPYZjUEDMOmwU1OPvYmomZtdpg+yXmsO2rGC/F6Jcxm2zvS16RNNjew5znNtj2xtxhezPR q8WcV5xegkGzpFTdGJNme2G7UvUWLFjTYLuZBRtsi2OG2q6LUQoqfQUTajDlDrKNcV5tG4bHy4uZ ZHPX4DE32LJiJtgyfLVSWZsNtv5ogssXTUBje8coJ3XEKgccO8hLqtx9NCs1JZqRmoGaJE0fjV1j 0/TURGtCtMFai9asNWr1Wq1WrRW1VAvaEK/c4naxnWiI2sICtchUVOIWypRtWtmkR7QULgdPD6GQ FhblkELPlslQOEny/FTk8BI9rlZUjhziCS6EwuIcT5qr0KuRx3gGuQo9mlHXlNQTck8p5nrocvyU Li7xEpllLY1m+4KNQIh16d3RLLx06d2lpRARtiArIis40zq4IK8DKW9T169EtIv39KwsLCrxPNuz 1JPEInLP0kLPf7GNw0byPTmWn7eRfMeC0pKNQib5Pn8Myxcy80pLC71knFIPJPId1sMR851ST4sf zKweSNpYX701vnrx2B7r9WIB1tPpIF6pF6/TKfVEwurV1/TKz6vv1UupEy5BjVKnJlw6t872eKwT H6/UCauF7Uqd7WG1rI4nU6kSE4NVYmOUKiQKYpQqMSRKqTLu1yqJbVXuOFvlDuVMAvm1Toyvjqnl TB1TC9ZxdZXKHJeLNA4pnTyebbrKHfmV6Ms9dy6oivDUTpKk+smlbbsxZ/mkyVUsrKj0lDoq8zyT HXlS/ZDxHRSPZ8VDHHn1MD6/uKR+vLsyr2GIe0i+oyKvtHHoqJRB7c51x9lzpYzq4GCj2MFS2LmG DuqgeBArHsrONYidaxA711D3UOVcoIzxUSX1WsgpxTW+EjZSgx7Ha3m0vTQnzFKdqQzeIfaIm6Ob cbWyDgy45THi9tmEnhX1ze6bzYrwmWJFZrazbiuKuHmIPbqZrGsrsmC21ZEDrnnza+ZDRP60PN+/ GgSz5s1nHe5TV01nYFk+bpLzauYBFHoSigo9WbiarddoMLecXZIn/UyewZCPa3tfZj/MTGeZgnC2 IsvLYHk6XVvFf73/89vCXPYU1NJNjcQdS+ZBTangiS0spjgVFLdtYZpxLcU+HmpK8QJriIvUnDlG m9kuF/jSwK75jJ83vy3W1hfz2kJfS2xSc6ZLzsI6y3W2x+bhAUHVDJHoo1RPQ6TohAgA+Qv0X7Kw dZr8JStnIf0aJzpvmwdYBy+QafACbIbXyDFstR43Ak3AlkB58DAsggdgGX6sXY05d8AYdCrMf4BE yk2QCI/hB9tjsBPrXgU3QzOEkQj5K1gCS4V3sdVSMEEcZMMomA13kyvk+TAeDoi3wiC4AmZBNamV S+R75PvlP8OTsFF4Qz4NBoiCyeh2yt+qPpA/hr7Y4kFYDQfI/bqXwI1nqcWaf4K5sEYoE4k8VT6B FtjherRBhBGwk2yhLjx6JXxBIsgiIReP8oTskbdhrRgogypYA80klQyldtV4eYS8E8LwHAvxqKuh ATag88Kr8BExqo7Jf5aPQST0geF4PU2wi2wRWk/f0pqFPabCXuoNg7FkNvwF/g57iIP8lc5WGVVJ KrfqRnkvhMAAGIvWPo0tPyc/05vRLRFeFwvkHDBjv9zHehv+Bp+SKJJIRpJxtDedTR8R5oIWzzgA 3RSYhv29Co++H4fRBmqku4UnxOfEk+qerS2yGe+IEx6CP8FfiQmvVCI15A9kHzlEc+lE+hA9KDwg PiO+o6nAq54AM+FueA5+JsEkjYwm15AqsogsI/eR1WQn2UO+pNm0mF5HjwpVwhzhVTEHXZFYI96q ul11p/rL1pLWba1vt/4sJ8m3w2gcD7eg9Q/CI3hlG2E3fIjuABwkKmIgZnQSsZOx5CZ0N5O7yeNk HXmGNOFZ9pCD5Cv8SPqRnKT4SUvVNBoXP2wJ5KBzcYX5AH2Y7ka3h/6T/iKEC3GCS0gVMoRSYTZa tUy4F91LwqdilLhblLGfk1QrVWtV61TPqV5THVMbNX/Az/gdp544nXB6fyu0Lm9d2drQ2iR/CqF4 D/HTAzdcGWh9BbrpeL9X4ohbD+8SI/ZdFEkgmeQK7JmJZDqZQxZiT95G1pAnFdtfJK9gL71PjqLN Jhqj2NyPptIcOhLdBFpJ5+Bi7H7aRPfRE4JGMAhBQqiQIAwVyoRKYZ5wg7BS8Ag7hE+Eg8JPwil0 sqgXbWKc6BRd4lBxojhffET8QvxCNV71luoztV49U3272qv+Dlc1mZpRmtGaMs0KzQbNXm05js6t 8BK8fO7PiEmLcIuQL7wE99BkMRK3MLtwPE+EKcIIiiOVriPL6WLSRHupFqqH0CHkSjgmOrGvX6dr 6U90iDCCFJIimE4H+I6mDhGfxSBD3ApHxFfw2nbhkReqjeRmelRthAZcIw3Gc/5N6C+6hLfgI+EA 0YiPwT9EPQknR+jTwigcBa+KmaoSsAsPw4vCHLIYXqL5APqT2rtwHF9JnsV5oZgkkeOCjMvgK3EU DRIOwa1wHf0AjuBzvBz+SKaIU+EeSCaL4At4Cp+K3qpZ6gR1KHmTThPraA/SBFR8Bq9uMOlFBFUI 3EbKhDXqo/RDmA+7RT3sF55H63fTF4UR4jHVGFKFT8BiuB3myLfADaoS8R0yFQQyDuLFFpzdFglJ oh3DJTirjMc5bQM+3c04D2QLIzAnAkfOFTguxuIMsQbdKpwnRBxB0/AZvwpnsV3QpC6mXpiqMhOc dQDEt1rHwNXyU7Bangqz5PuhL84Hy+RFeMR18BmsgHVkaetNUI1byQ/x2b5CVUB3qwrkvrSOfkiL 6Mr29xd7O55EwNfoXsREpmoT1InvQxFkyXfJ7+HovhRn2NUwCResh/Eqv8UzDBO2QHLrlbReLhCq 8XoPwGj5adlG9FAlz4CR8Ao8qVFBhcaF99hD3sHrvQkq6Rh5nlDZOg37YQX2ght7az7OP3fgaliZ 8FTsd0kaALvVbo1HwZUznJKELafcKjgJkriF/c7Hg9auwE8ZFehgcb2a/aCpgYLKS9e7DdoMtV6X Lmao0wlJPHz6MGSd/jwruj5GKXViKQW13vCWoEtXpYkZkIb1hAxKJULIW3q94Rb7Y6tw5Xul5Yey jBGWI5bDeIjDlm8hK2uE5fTnuPJtVOHChFgyLBmlpQP69xCsyVZBSE0O/WLQgZQndpMZgo7kt246 9XPrAzt3MlsnCI30esVWA8zfiB+Rxxvj4lNUXvm4O87ZO8Wg1mMn4d5JpVIbvtVptYJAQaPN0Afp anVUhysFd6gpKEW3nwhiBiVukzWFRBrnPB3BTHRljDidYTntKss4nQFZGcyo0xkoxBo8eDDzA/oT l6sHM09IVvTepJ19Pxmws7/QSMKPHWv9yqdsO7IKn8ogtNMihLuN2gSDKWcsVbSesv7dCFr5J7fB aKRjtWaTlY6lXvnbJhbBS/nWfSmLGYNZsSrIKOiAUK3OYAatjuoNaouFjjVYTCZUr3xiA6tlsIBX /ryJlWDkeFNQkBI51cRqQSIuNXYqgh2/ZYtlz54t1uDwwS6XckEuiPbddLdNIxkM6rFqRQVFRUVV imq98vduB4tRo1JDbTRi3MxUZ2SqV1TDLDCZlAbH3TYWc6qIUdIHpwQpojIKQMwG0GoJ1bMLZ0dT IspBNtFxEIybu3FuEygnAuVEcOawQNi1/JD4A5qelZGVkeG7mDLf1ZyzWot2LwEapA2h0VpxgfF2 4xvYlcbhxuFBQm8x3tTHXCJcIy4wLTQvM2kNVKUdbBpoHkkLhTyNWzvClGPWr6KrhZWaldp1wtMa dTANMpv7q2iISkW1RpOpv0qLUa1xTNAY4iaUarU6vcFgMpnNFnafyoNrg2lwM10HJjKgQSVpvWSA O8yow4fCkDNWjz2FKrmNSwzE0IwXbCYGrEW9GAQRvNSfmlg9FmHDBGNSULWFWLx03MuSqlxVqxLw EVzXaB1SGuGKxMcLH7CI0y5XhuVIVKTlCKaizkkeLoOIrKwMZUifcVGWI0eWqfq5li3etqxfBAsG 9MeFtQEX1rG4sH4VjPJJHKX7gMr70tLSSnFDbcSyS7FsI5jk4/VmPctVFtcmee8G+2BzH/tgkxej gwabkwYp0Zf6Ym7fwb6bUjp3ThnMKSNluIF2uZJxNgoLHziI2K0OK67ErKvwY+Ga/mGRqfiBrtrU Om59a4mq+eT39w0b9ZBw6kSB+NbJVLHlpMRmgQL5S+EAPl1W6Ek2uxfpqWiKN6WY8kyq1JDUmKto sX5MSFHMVDpFVambHFIes8W2V/Vej08iP+vxWcjR8G8iP+vZYpNtYTabKyojLCOqMKradq9N04/2 MvULS6eppkKabyoIGR5zlX6caarpM/UXYSfID2YLCRXMBksQRMcYNFbQh8YIhgjfoMwZyyIvsxsV kcxu3/cvK7cv3hp0pgJGfmhiFYLYY3QJKw6Kt1j2WInF6raWW2utos1tMNCxNjd7aK3B7GG2YiO3 lT3NVrXZjBqhlLEjGNiTYTVbLGqW9j061jOPCIu4y9nZrPOCtez0OJlgKtjMzhvcS2NhKY2FlWzW 7NYc0Mga0abJ0ozUCJpYZoUmgs0rmlh2Po3yFGqM7MiaKOURj4xNGeWbNBXK5rhcI45g5PQ5e52y OTj8MMQpNeMwe1aP4NOK3somUxxsZYSNB3uq2hHndKamBA9MTgoLxw8AEhKWnDQwNcXpiFMLaZXb lrw3f/reW8tXJjaelp6fv+DJdTctfOz2R+46+cRaItSNzqbmEwU0eMf2v77+0Y5tbO5dikPkdTET R8d+94jEHsQiEoeYIubi8vhacZ6o1lm1Oq3O1MOqM4GgJYYYtYaoQa+79F4t0cZJPUgPGmdVOsqq dJ1V6TprPLuvW9yW5IEpx9gPnCTYAy34ecr6/MzE67ayuwQi6ztQs35UZmF2k4DdyrCgoLPTmVaZ y64MHrotwmX56ddOc2WwTjxsKfthLn7cZmUdseKnz+DByqcQWN5cZlae1LK5pCzZmhw6EHstXMO6 SqMOtS59PHNa1jUTMnNyhkwIiRWdj80Zlv70JUOzyuee3os2zyR7aBWuAA1g24hLqSK3WafeIUF/ fKTmG696mtlRdgQSj+AncQq7G6Eh7N7MfLBq2oMPTqt6kO6a9sAD0zCOvSyfItvF2fQaXF/EuoNI KtAoFfu1UqTYeCMbGIfLLJ9D4gg8lJBqDxXFGrL9vvtYu2ZcGa0j72K7iFeB0qP42fYN3rBj9SqS aMELxhbEnmon61qDybck/sW2Nqro87dRRZ9Yq6r4tQ2Bztp89ut5oLWZFPzaRtuFNlr4uVl7ThtL F9pY4GizxdeG/UG5z12H+8kAODrLHycs7tzhnifwrn8A3BXccccdd93irg2Iq+WOu/8H3RqxSdzF HXfccccdd9xxxx133HHHHXfcccfd79kBQDr9C/i+mQ4wXVEWJ6BXUixOwQxfw5lvsE+AHW1x8Zw6 7G8wT7TF1WAmCW1xDUw6W0cL/ZX/4p7FdVBH0triJvosee3sN65TxRltcQIq8bG2OAXN//D2NeBR XdXa65wz52TCnASaIlDKzxRjGiikIVBKIx9SjIgIaZrGMTPNl+Y/kxCSyeTMT2aGZCbmInIDxYhY ERG5MdJcRMyNGDFSihQBa6WkRVoQC0X+REoppZQic9+9z5kwra3f9/jd52Oed+/37L322muvtfY+ 53SS1HTK4BI9aDpicFOcjEyq6YLBFUqQBYMn0PQhGTONMTUZPJG+IJsNniR8RV7CfiPfJGEuVdnC uQw+QunlXOHtezlP4O0vcW7m/CTniYYPda77UOe6D3Wu+1DnpjgZ3Yc6132oc92HOtd9qHPdhzrX fcj4sDj7Ldy2y5yrce3JnN/mfASzLUHXeTd4SsI4zkfGyX+K69H5qLj2e/jYDM7v5TK6zvFxMhPj eCqXn8P5FM4XcT6N80LGzXH2m+PmUuPa1dhaniUrZcEj7Cd0rVRATqpEvYQaqB7QqJlcvOXzuHKD s7IU7TVcIgM9j1IdPlbKR1s1xmvUxK8qUVdC2ouyApKPgtdgLJOt4TKlgMb1VUBmGWo3LUVbA1X9 S7Z8VDL7Q3Myi6rJA87mySYbt67JGG2lh6BhOjxhpXRoqqFy9Dagn1mj0eQ4XUtg2z9aVTDEcrhd PkjXY0YrPQYNVVwj653GbWlARtbweXN5jxMtzLImmoq2PL4uN++p4X56AqUH8hWG1VbY+gjNRuzs GOnBNfNfM2oP9zvzrNPwcxW3VeNtDSgreLuLz9fM48D0WtHi5jYxyXJjTKVxXco1ufjsyyCl8T42 qozr0Ixo1RnrrB+yQh8Rs8MdJ+viHq6AxeV8Dt0fPm4388jHr0G/ZrLlmM3DPVLBM/GjnmAj6jhL h/xk1CzLygy7P153/f/D2u9orxiKvZvvg1gsY7n6cSuIzf6Pdn02LkZsJfpaND5fbBcw/fpaK9Di 4ytv4Dvrn2VC6YeiXsmj02CU+qp07sGVi5dWbq13KJt1PUyyDhL/LIcynrVmZU6fbi1wVlqXNNQ3 aM2uSuvnG9yuBnepVtNQn2F9tK7Oml9T7dSarPmVTZVub2VFxqPumtI6a02TtdSquUsrKpeVupda G6o+WUusMVsfmV9Z7akrdWfbKt1N6LY+lDE905q+pKbc3dDUUKVN5lJLCoZUFbAix13qq6mvtj5W VVVTXmmdZs1vKKupt+bWlDsb6kqbplrzSjV3TXlNqfWJUk99BVRbpz8yO8ve4LEuK222epoqrZoT Nlc11GtWrcFaUdPkqkNHaX2F1eWuQWM5eipRlzZZXZXuZTWaVllhLWvGsEprHeasZyrQwXS4eavL 3VDhKdessMPnhCFxM6CuqS+v81TAX9aYEQ31dc3W9JrJ1splZdAdJ13/T2fn4hVs9e7KJrZK5tU7 E7DhQ7o+y1eUXoNZtMplLATuGsxa0eCrr2sorfiwE0r1pVe6rVhRA6ZC6dFcHs1aUellboaMs7LO 9WEPZeB8bOD7jp289chwdnI2C0nIqlpcX+CncKz/CeSZvlPYjqiQNkg/k34tPQf8UtolbYvTVcpP qtj1Ka678kNzVX5IG9dnmmCabvqy6Yum/4XyEUiXYiewPabfCZzCDuGHeBxjO5/dLdz8xGY69GdD it5Pn/T/cpaIPQXdRUI0qv9VoyXic5PER0xpRPNel3fh2qondOxfFP/oc9Hbj+Yvzs/MNP68JnsS U1FdEW5AWx4e+jpIEFeL3yVJ3CBuAP+e+D3wjeJG8O+Lm8B/IF4Bf1u8Af6+BAukFCmFJOluaQH4 F6Uvgy+WWsBbpVYSpbB0Dfxd6Rb436Xb4FH2mw8mYk+FJs2kgXtMzeABUwA8aPomeKfpW+DrTOvA v236Nvh6OYsEeYY8kyT5Iflh8NnyZ8HnKDkkKF9QMK+yWFkCnqs8AV7AfrxZsSlfBS9UCsHtypPg RYoG7lE84F7FB+5X/o1EZYXydfCVyjfAVyV0kZDwo4QfkZTQnfBz8J3mR0k0zzeHSDIvN2N15lbz RvDvmy+Dv2W+Bv5uImZJtCf6SEr0W/A0ahlmSSLJkmxJB59smQE+0/Jj8K2Wn4LvsDwPvteyD/wF y+/AX7T8nkTLSxY8U1suWv6G9suWd8CvWa6Dv2d5D/yGBZ63vG+5Cf4BgiepgvobPKHtU38LfkC9 Cv6Oeo1E9d2kESQk3ZV0D0lJY5MK2S/7GjEX6T7ued3nurcNP2ON+VhRgRl+MxeaMcrsMBeDl5rL UVaZXSi95maUAXiD+SGCss3chpavmb8G3m5eAf518zfAV5n/HXwtfMW8dNXwiQhvPAA+1fIg1pJp yeTr/Sv4JcslvpYXUO5X92NFv8W62CpGoRydNBprGZM0Bvweti5jPcNovTBAcqm7tIys5c3uOppb 7a5cSrnOyjI3FdeVavXY/cNI+Ep+jpVGYmdF4QMTWQyG9xjuG+K7ib3LJMVdC3gfSB66FrDzoGlx wUIrjTIkRLwZDDe4hN4RdNfSSnc9OXlZz0uNlwF2Q6IwL1fyci0v1/Oyh5cv8fL0sqXLltJ1Xt5m paDwMpmXo3g5gWjoze2jpWj8QnesFthfhIDtMntTg73DsHqVvx3CWkqhu+GXT2FFo/FOxH5j7F4a R+PZn3vg/+edjxv3cW0i1m/6UD0c+j+pnoyn4CKch3U49ULUTh20jjZSF22jPhqgfXhne4VO0Bm6 RNfolmASVGGskC7MEnKExUKBUCS4hU5hg7BF6BF6hV3CXuGQcASa8YYprMDseBtNyYSNqMc7YSlq K+n1fWf0vTCpXa9n3dbrhw/r9SMZep2t54Xwxet6vfCkXn9pr14/biUT+9X5x3tIYX9a7qkQKUgg ofSMPn/5JmYNCRXsb84loN6kt1f063Vlhl5Xj+JyppqMmvk1tppa4+pYzaVaqh2pX9Uerb1Ye3tp in61NLx03dKtSwf08XUter2sVq/rc7iUuWFCQ1bDwobiBq1hVcPmhp28Ncm10bXDtc91zHWpkRpH NqY3zmnMa6xo9Dd26Na62d+nYHWxrs1dpddN8/Ra69Nrz0Vdzlds1FU82wTfGhKGu7iHauiEoCBu WcI8oVhwCW3Ci6IozhTdYkhcJa4DNoldYq94QLyIrZMsWYFFkkvySgekI7hHjDUVmtymlaYtpm1y lrxZOiAfUqxKreJSupUTUnKCkjASI/BJmJ9QmFCcUJHQk3DGnG3eZt5vPmy+mTguMStxXmJV4rrE 68NmDuu1LLbUWzos6y2bLT2WM2qKmqPa1HXq0SRKGpaUmTQ/yZW0IakrqTfplaTryebkrGQtuTO5 P/lQ8rHk08NNwycNnzp8EbI9Nfo0PRw9TnOix4W3o08L7wMfRJ8WBSAxelwcBgxHv0Ajo07sD4nL O+kRIDvah3FOsqPfARQBO3Et0fDoeLoLYNoTMKYvboyTjylC2070mtB7nIbfvkF3AanoMXF7HgGy dbuwo7kM9I3ACKZ3PDCB63dSFvpywBcAC4HF0JyP+iuobagLUTswrghIgpYcQ0sOtPRBSx/XkgMs RPtiaMtHzUazkcxOFaOexqjjGPU0Rh3HqOMY1YdRfRjFRhzHiOMYwbxwGSdCbFUjMA9b2XiMnBAN xs2VY1iaQ0/gugB1IWTsgEhfYp6kz3BPPs1n3UmL2UkDybsAcahdoJ9DVuI+tnH/HydZnBYtEWcB i4HHowNiQXQA+2F4dCLGTMQTUhfinIM45yDOOeLY6FbxfiokGa3H0XocrSzyuxH53SSh9YWhK5OQ FX1THBd9TUyNHhQ7om/SMCEj+qbwIDAdmIHeEcBowApMAtKAByCZKEyNvipMgzY5+iqyywmtTmh1 iqMwH3wKnewvEmEuGgnZ1ZBdDe0LoHkBNC+A5T2wxgkbnbDRCT2rxaToJjEF/O5onzgG9VjU96Ie D1ijC7CyMnFydAGJ0PsyZnsZJzzLYmTq/5U9CpNmkobUN2JSNBytz2P807DxHDxwDnaeg53nIPk8 vHAOXjgn3gNMBKxAGjAZeCB67h/0Ds0+FIdXPxQHxcipm8inm/FeIBEx2YRYbKL7jJ3C44ycm4ic m4g5jsPK47ByopAJTAdm8DwY+Ig3j8Obx2H5RBHjxZHRXHgiF16t5V4dj3oCzgUr+j4dzYN3nhY/ g7b7aUBMh9xktE+J5uJ+G7N0BPwOa43sf/oTYvpRKz4c01HgHx/XZh5Xln+98H4vNPZCYy/s74XX X4NULzzeC6leeLwXzwSw6388r1KgyYf5+6DNh0j0QKMPNvgw+jis78Ho47BnEzQchwaWWT3Q4INt PmjwwTYfoteDzMe+oqR/yKaPy6RJH8kmNuoURp3CqFMYxaJ4CtKnIH0K0i8jYn/AiFMYcQpR+gNG neK+O4hRBzHqIEYdxKiDmOsgRh7EyIMYeRAjDuIUiO17tuctnzguNiZNH4dZDuK5ZXhUQUYq9GzU Rz1Ab3QQJ9fOaAkvfXhq2wmPz6Uc8dHoBfELNE1cGB0UvwT+ZdTsFFsS7RZzcZI9Dv5VtDlotFiH ehlk6sF9NI2SxWy0MA0L+cgLGNmFkS9j5AXxMfQ9jmuchdBwQbQDlcAy2PIpjBwQ50JiHtcwIH6B axmAlgFo8UHLAJ//Mdiha1kNDQNiMeSqgDpwZksD0AjeHL2Ap86PWTdm8mEmH2YZxCyrxQWwbyHq L0Mr0+gALwKKIfMUUAZeCVQB1YATbbWol6H2oPYCfqAZ+hVxCXyRy1e6SyyFP524XgbfiHy+pbBq mOGhQd1D6F8CfxcAzKdPIZ+c3CsXyGx4IebLQXjhAvfl4+DwH+408d7W597F/hYArp7kM4+mRGPE BV0/wGxaqvfCVxcQu9Fk4bGLRYDNuwT1Y/CJPtcg/DHI4wUP47l++O3lOFmW42QZxMkyCO+uHvLs PEjd8W7cWnk2DBrZ0MW1OngMS7Dubqy7W/ShrRl3y+FD9vCMhFRM02LwJTwTVhv31l08n9jqSuBF rAhvGrEnoGej3bCt24g8y7EBcR4kda2D0NjF80q3pQuR74YtqxH1brECqERbFbetRKxBzSK/lEd/ NTzRLTYBHsAL+IHm6GpKg3euwDtXhryjW9EFKy4YXuoyPDTAszyX7wndz08CLP/+N2R0z/jEEvSX cqu6xHLwCtSVaK9CXQ2wnKxBXQssBW9A7QLcQBPgB1h+mg2vDvCZF0PjkqEI74LGAUrgdsV2nm7X LiMjB5HFC/neZ/nsiGU2O0HYzsFbG06UuDwaMLy8C7EbNLKAxW+GkVclxjnQhezjcUHux6L9GEbp WTeAqI5mtvF9zva1akSy28jVrrg9strQzbKqy4jeBbxZlfIzQj+vGrGS4Yj2y1zmKbSUAKU8v5k8 36dsvWI9z/cBfqJogI9bMEgjMBo7DGDnzx0N7ER7mdvJPLZ0aE5dUyO0a8bZNCx2NkHToGHHoKFh EKOZDYNcUsSYQb5HE40ZB+PsHYg7+QaZnVjrk3F7W0OELEPjnhqy8o6F/AQ3Tk3MhPMJ8YWOafys KGW+jzsz6gzdzB6RtzJvSnwGppmdOOY4G/X1xDzfYHifSbxs9O76aC9ftYlH3Rl3Qg2L7Wnue5YX 3O84Y3WPGauB5AhIzoDkDOrBeIdxFt4ZMZqP0KN0DntGH8l84DMyLGHIY/HWx2xLHIp+zJ93oh3z 5SBW8JFeeOkp42oZ914ddkAj35U8Nszbsfgbd9eGIXtiHo1ZHutlM4lD600YuuPdOXlKcPKU8Dt+ In9T+D+9JYj0EP9vT0Qj8REoldg3v5PxkehBfEw0Ax8ZUg/hmfhhfBLoEcrG+80cfIbRl/Cx0Ffw UclODrzzFeEznH6Od6gRtA+fFOEBYRrdLTwoPEij8D4/g0YLbwtv0z3Cu8J7NFZ4X3ifxgsfCB/Q BJH90ZSJoizKdJ+YIA6jSaIqJlGaOFwcTuniaHE0TRbvEe+hKeK94jh6QJwo3ofMTRVTKVNME9No ujhZnExZ4gPiAzRDzBAzaKY4U4TtYrb4KD0s5ogL6HPiQnEhzRcXiXn0efEJ3IsXiTaxkBaLDuT/ Y2KFWEVfFZ2IikOsFV30pNgkNuHp0yv6qVxcIa6gKnGluJKqxQ6xg5wkKBVKD/uWm07STCLXRmAL Ce4TqLcC28FPo+4DdgF7DOwHXjRwhKjRifoYcBI4gzHnUV8ErgDXgVuQEQEzkAyMBMYCViANmIox l1FnAbN5n+C+xvsF903Uc4EcYBGQB9hIaELYG4uAMiJPN7AN6CXB0496N7BPKHVtcWe7TU0trj3u /Kpid4XrotvFccvtbTS7N4NvayxqUnld1qQ2XnKHgJWure55ru1An3tedaZ7XuNLTQUuxb3Atcu9 YEjmmLsQbfPQNk/XX722sctd3NjjLnbtd+fz/hdRn0R9Z95QHC92XUENNIoYlwzZ68At92Zcb260 uru5Xaw+5t6GOXbj+vBQfd19lOOW+wTHRfdp4HxjmvtE41Rgtvs0cB7jTzfmNSkcOe6bMR5be1Vx 0wSGxkDTFI4VTbPgt/zGDvcGtobGHbBzC+zb2USNA01zmC9iPmi81OQAStjaDR9DHvoZrO6bMf/F AH8tZj6M+Y3reuWOPtcRrP9MnN/2uAt53PbDhmPV64faP9of50f4xMWA+BbH+botPvafIONtHIl1 J7vXAOvA17F4gG/g7TGM1ePD4hQPHjOzHjfY1GvU/Ub8+mHrvo/GrzELcWLxmosYzTVixbCjqZ3D Cp/noWZAe9OqJoXBkFnLEd/O4rsImIp82WLkNWIM3Xp+2/Qa7SfQnhLLe147eX0T12NQr0GdEmtv rEd+hJEbDPFcu8ORQ6nIn0yODvjzmLu2sRO+ewbg19XrGzchp+7EaiXfL0UsBk3zY+A5EQPLjdcN /gZwNj73YvsQ+471XWqqwrUXdR3gbrzqvtx4o8nfeNuo9Tj0wv+H+Lru7JPLwDWW9/DnQvgtl/Vz bHTP5HuS5YFoxPgAYrIX+8CoXXuaWnj+85zk+yCWs4WYj9WTmI16O+rY2RCfs0YOsnxEjFws53hO GXtfu8F0AFewx6+4z2u3sd+PAdf1a48J68i7c63nh2cSR1yuxNbFc8Gsx51fm9k19MeuxaYUBsR0 licda+dnQlNLY4cng63FMxP2YZ96slGfZOti54d7EocYd37BdtxdLPybU+LfmZr5t6WJ/DvNZP5t 5gj+PeZI/g3mvfy7y/v4t5af5t8YpvHv+zKg5TfiWyLuJ9JEaSKJ0n3SfSRJ90uTySQ9ID1ACdI0 aRq0Pyg9SInSdGk6DZNmSDPIIj0kzSJVikj/RsnS16V/p7ul1dLTNEb6pvRNulf6lvRtGid9R/oO TZS+K32XrNL3pO/RfdL3pR/QJOmH0n/QZ6QfST+mdOlZ6Vl6QPpP6T9pqvQT6Sc0Tfqp9FPKkH4m /YwelP5L+i/KlH4u/ZymS7+QfkFZ0i+lX9IM6VfSr2im9Gvp1/SQ9Jz0HM2Snpeep4elF6QXaLZ0 UHqZHpEGpVdpvvRH6TX6gnRcOk4LpT9Jp+hL0pvSm5Qr/UX6Cz0mnZPOUZ50QfobPS69Jb1DNjld nkpPynPkHCqRF8gLqEZeKC+iWnmxvJiWyblyLtXLeXIeNcj5cj655AK5gBplm2wjt1woF1KT7JAd pMlFchF55GK5mLxyiVxCPrlMLiO/XCFXULNcJTspINfKdbRcrpddFJbdskZfk72yn1bIATlE35Bb 5BbqkMNymFbLbXIbrZHb5XZ6Wl4hr6C18kp5JX1TXiWvok65Q+6gb8lr5DW0Tl4rr6Vvy51yJ62X 18nr6Dvyenk9PSPjQ9+VN8gbaIO8Ud5I35M3yZtoo7xZ3kzfl7fIW2iT3CV30Q/kbrmbNstb5a30 Q7lH7qEt8jZ5G/2HvF3eTl3yDnkH/UjulXupW+6T++jH8k75V7RV/rX8HG2Xn5d/Qz+TX5B/S33y Qfl39Av59/IfaJf8svwy/VoelAdpt/yq/Co9J/9R/iPtkV+TX6Pn5ePycdor/0n+E/1G/rP8Z9on n5JP0Qvym/KbtF/+i/wX+q18Tj5HB+QL8gU6KP9V/isdkv8m/41+J78lv0Uvym/Lb9Pv5Xfkd+gl +V35XfqD/J78Hh2W35ffp5flD+QP6Ij8dzlKg4qgSHRUkZUEek1JVCx0QklSkujPynBlOL2h3KXc RaeUu5W76bTyKeVT9KYyWhlNZ5R7lHvpL8p4ZRKdV1KVVLqspClp9JaSrqTTFWWKMoXeVqYqU+mq kqFk0DtKppJJ15QsZRa9q8xWZtNNJVv5LH2gzFU+T39XipQiQVKKlWLBpJQoJYKslCllgoKnxmoh QalRagSLslSpE1TFrTQJyZZES6IwwvIzS79wl4rHX+Ee1aSahLGqoirCvapZNQvj1GHqMGG8in/C BDVZTRYmqiPUEYJVTVFThPvUkepIYZI6Sh0lfFodo44RUtWx6ljhM+o4dZyQpk5QrcL96iQ1VZii pqlpwjQ1XU0XMtQp6hThQXWqOlXIVDPUDGG6mqnOEbLUueo84XPqfDVPmK/mq/nC42qBWiDkqzbV JjyhFqqFQoHqUB3CV9QitUiwqcVqsfBVtUQtEQrVMrVMsKsVaoXgUKtUp/CkWqvWCsVqnVonPKXW q/VCCQnibLHlzvNzJZ5HK8tIqMZzdCWeiSvrwbeg1oAAEDawAugw0ElUlY76GWAT0IUxePau7AF2 ADuBAWAvcAB4CXgFeB14AzgLXMKY7aivAjd4n1Ddx/uFajy3V97GHCZgGDACGIV2PMdXjQMmEdVW AXWAm4RaP+oWoJ3updm0gPLwZsR+esdPbdRB62kz3lX7aDcdoCN0gs7SFbopmIRkYYwwSZgpLBDy SHLsfHKSY+DJdMfeJ3FyO1Y5Tjo2Os6AhR1vODodZ8G8jkOONsdhsDrHiw6/4whYmWOnw+l4CazQ 0e8odhwCy3VscRQ4toLlOLocixx4W3FkO9Y4FjjWgWU61jrmONaDpTk2OaY6OsHGOUKOSY41YCmO KscYRx2YGXqTHfVgoxz5DpOjEEx1FNhvOhxgomOu/Yojh0T7Dcc8+1nHArDLjin2E45MsDOOqfYj jiywveg94BgH1u+YY9/tmEAm+0nHIkjkQcJmPwYdJpSL0JqHVpv9oqMI0qvsJ+1r7Vi/c4f9DfsK 587/sXuizH/eiPhPGuk/05PIf55mNP9pmHtIQFTa8GasIl5TicqQR2XIozLkURnyqAx5VIY8KnvD AHKp7JIB5FL5StSwsgz5U478KUf+lCN/ykcByJ1y5E45crc8A0D+l2cD84AFwGIgHyiMay8GKoBa wAV4gRDQRlSNd8pqvE9W432yGu+R1Wdoqj3dngHMBLKrk+0L7Ivto+zj7JPsh+wV9nn2Wnu+vdDu snvtxfYQyjb7SnzW2NfZN9g3o6Xbvg2fXns/+G77vupF1XnVNsbYT5HB/1iheE18l0TxPcTCxGOh 8Fgk8FioiMUjiMhnhyJyFyLyOI1RnkBcxvG4jFccioMmIi7byGrZjuh8xvKB5e90vyWKGE35/ziT QPNI47HOIPM/jxPOC3OhVhgoDBeuKOwo7Cx8por9dIpZfEd8B+S6eJ0EOVvOJlHJV/JJQu7ZyaQ8 iQyULT+x/IQUy23LbUr4l8YIKZfvRj+pwm7CmeOErc5kYCQwlsQwcs1pBdIA5Kwzy7ieDcwFcozr RQbyDBkbUDQEwamRGDGRiHNRjAzjNTnLwEeA74/DLrSNAsbpYG1IUTEySR/PkW4gw5CfCWClkXnA giH5Ozbh7HfWAzj3nQGug9nMxxjzkhP3AecKLidGFhttHf8CcP9wPhMH3EOcXdwfYlmYxKdWDIGc PXpbGZt7B7eN28evd34i9P4BVot/sq3y7WndrC30BFq7beub+1u3abme5NZeraB5d2u/ltu8D70O tOzWSlDu06qaD7Ue0uo0f+th3tKvuZsPtx7V/M1HW09oJc0nIMPkT2Ps7tbzWgv4Za7tmlaAWc5r C8FvQvI0JAuaz4fJttW/Kaxo7Z7ksMpbUrRVzZdbu7W1zdfCY7T1zYdRbvQ4UW7xBMITbPubb4ZT ta3ey+Ep2sYAhTO17ZCZoPX5qsKztF0o52h7eMt+/6XwfO3FgBJeqB0JqGg5hnKMbX8gBaM2BsaE c7WTgQnhWbYzgdRwgXYmMCXsQHsKJC8GMsMl2hWMrQJPAb8YmBWusx0LzAm7teuB+WFCuRD2w29h v3YrkNva7xEDBa37POaAo/U0eAnWuD6wna0irtwe6OMcpSePt7DVbUT7LqzrH0qPLbAn7PAUBfZj vVWBF8NbUB5pPWS7HjgWnuApC5yEnk8otT2BM+GtvGSSKLUtvNyOsame5EBVuEVzBOpgrTNwMbzd U4/2Ps0fGla62zMy4A6TZ2zAj9IcaIFMIHA9/KInHLgVPuLRILnL1h4UW88vLQm0Q8bKPaCPSgvk htuNlqmBVeFVniyUaz2zA2tRzg2sD6/35HCd8eWiwEZ4b1FgCy8ZX+G/inzb7tsTPqbt0raGT3o6 guaw6ukMJodLPM9glj6saFf4DM+3Xr6uPYjF1nCKbqGWG7iCrGPt+z2bgiNbT9iuB8eGL3qyglb4 cFXz7vAV2zH4/7qnK5gWvmU7EpwK7/Uw7tnBuO1I8+6IqN0KZiE/WeyOeXYGZ0fMnoHArEiyZy8s 7/UcQJ53873T73kpODcy0jMQzEHvK8FFrf2I1JmI6Hk9mIexbwRt4fmes8EirKjPtopx5Ooxbb+n E3wR/LkP8rvCY5auZ9xzKVgGe64GndhT24P1iOmtoAjbbEEtMtYzkvMbgRcjVng+N5JmuxUMhM94 bjf3R6Z6TcFwJMs7DFHoBl8Rme0dwXR6RwU7wqk61/YEO5EJbOxc77jgMxir80mM29YHN7X2etOD XaWHvRnBntbzLB8iad6ZbEXebGjYBqvKwOcFdwzxBcGdOBmYr1KxInDkHrh3MePefM4LsaIT3mLo yfFWQA+PSyRHcwQHIou8tcEOtLu4td7g3vAEbyg4AGu3Bw+AtzWPC6/yrgy+1HrIMzv4Sush78rA i5y/zjl2h3eNp7N0N86E9kied13wjYjNuyF4NlLk3Qz9Zdp2W1/E6e3GSTKBnWCRZC5Zz2aJaNqR 4KVIDvb1eZxaRwKZkRyPGZac9s7kscgx+NXwGO82T3KkzNvr85dOwi5AtttuBbZHApqb5QN8fiPs 8PYbfr4Ky3frnO1B3f98n07w7mPz2vYEUrDqQ8Hb4SPewyET1n4UMpsR06ulKz02/8jwfO+h5XVh xXtiuTtcBe7nvIXzO+1HQyFESgtklq7UHKERyJxjoVHInJLQNqzoWLAnnOo74tvT1u071nytbdvS EnYX8J1c3t7W670c6m7rZ2ds226PNdTd2u87s3wV4si57To7e30Xl69t2+e7snx9eL7vuq+97RC8 19J2mJ38bUdxuqptJzw54KcxdmN4j+9W8+m282if1XbZ24+T/xratyAHtgUH2q75xeVbwxu9R+Ht zX4z2g0O+2eFNy4taRGR1UcCfZGzvostZsy7sSUZmZ/TMhInRhk7x7wjWsZiXXsYt60PjcMuxlzs /AxNQjaeQObs9p7GvanX0xlKbz3qPR3KQFafD82E5y+HssPt3muhea3bvDdDC+Cl3FB2JA1+W4yc 3B7Kx6myEJKp7K4RCdtWhQp5S3FkLiQrIit8FKpFJp8OuSIdPiXkjXSykyryjE/1l7Ue8qWEQmHV WxxqY3cobzos7/QpkU2+MaGVkCwJDoRv+SYEKNKFGdcgUv7QutbTvtTQBtzp1oc2Y08tDLUhK7aF uiM9Wju7q+IelBou8U3B2aX6Mj1nkckmbWNkBzL5BE6hrVpJZCfjkQHMvhjeWNt8PrLXNyvUGzng KQtti7wEb/RHXoGeWZHXcXL2R97AiYGTUNvD7PS1tFjbx2K91G71d7Sktaf5O1umtk/1P9OS1Z7l 39Qyu322v6tlbvtcf4/mb8v272jJac/x72xZ1L7IP9CS155n2x+6HE71722xtdv8BwIX24uwrzfh CQH3a6ylsKUIfAvb7/5kxK7f/1JL2dccmsO3PbKI5U/kBuLrjCxi8QXf21LfXqbtadFwPuxvCbQ7 /a+0hGHV67Cq3v8GrNL8Z1tGxs4Q2/aWFeFb7I7QHsDYseF2nKi422KuDuRVJ/ge5BU4y6vwHsh0 htv1/PEe5ZzfH30Xcbfa4l3ZkhxeFeOBPW37vP0s97zFLc+w04BxbTt4KvRsar3mv9TS1R72WBnX trZ0hWd5F7f0xPITY4e45m7pbF/hNXlvtndoW3x7Ik7/1eUT2jv9acEd7c/4b7TsQA5sxwkz0n8b Tz59vq24D6ay2LVvYrFr72K7Q19F5Kz3cnP/19ayncu9p++Ok+HUZlPLTuTMLax0o29CsCdyVtsY 6o9c8s1BLC5pC/EEleqbj0y4ivNnVkT04WkwcgN7J8RyPrSbl/sgkxs6FLntmx861GZi8igLUA7z rAgdLh0B+WxE51joKCux+8b4HAFqG2G7EjrRepPlEtr5XKxsG6X1aRdxepT4WobKKm1h2zi91HZ5 OtsmIfNPR7p8daHzbem8zODlTL5fnNx+53+T9zVQUaVXgt97FPXDn2VBkEYkRYk0oWmasFABJMih Xoy8qiLEhaqCGNomxBBiCG2QvwWkCzCua1xiiOkYp5exHWN6jHEY4hLGGNp2WMLxGELbrkuMQduw HGM8xGEYDzGw9973XvGqGttOZiZnz5nznXu/W/fd7373u9/97ve9RxVPijTokUGPe9rm991sam5b xPyMkdnU0c68BU3dDcWAO5oSX4pruNWu9W4lbEHcaW066Na/4oLItOJIwT+tDffaw7wOsKTUu72p t2FnVV7TUVjRsKbaTS8tNh1v6vV6Gu429b60CJ683hnv1rfHgD/BG6+0NpW2x4OGufbEzl1N22Cl tzaeAjtbcb46FxB7KxuO/5c3vNWYh73VTb0g42qsxJkFOyvAkknovVY6lYG2FNme+qYT7ekwUjid ehubTruOQu/Af+lAU3G71dvmWmhre0Vo6nadfsW1twp2ycSms+15Xu/eiPZC74GmwfZt3sNN2vb0 V440DbcXg/dG2ku9fYArvMcaKtp3QpY42r5r3zxkSG/n3abRNq+3n/aIRdeVlvku1hwBp/dFyBIT sK6j9rZ6TzXHtkx0aWGna+0KwxN4l+lLeEfQ31gJV/vxPN8Vg3RXPNGJe6uQxh2zK8W1ADK1yH8l qmEE6GrMbF3pDTdaFrsY0sAneu8lvAdpNuNpf6/Q1tZlhbXDvNWNRuhrfu8U2oNrpCuv6TTYUNic hPzmVB9/G/GLiS5F2lvbeLhl/CUL3i94t+41g/xscwbIVDQ+gD1rHscC+xTQXTuJhgyMGhoGm+97 J5qzgd7VnO862LWb+LuQ37WH6GaS2dostB3o6mgW2892nm0W2geJHgZabB/p6m4uaR8FnAR79Dzt pyOwy7R1HWyYhD33JtF5RF8kupfo2r1R7VdgT5+B3HhSTTdeBx8mNbswkhv7weajzTvatV3Hid5G 9AmQn4QcW7W3puu062D7ZFdicw3QZ5HfNdhc16TtOv0eepjkR5oj2m/AvGe4JrtGIf5vdF1p2OW6 0jWpom8QfQtprwVszu26C1Ga7o0muhRpzMkK3XUPzydwhrS0h70yBftaG5wBGtrDuuYax/FOEM4w tzp3uQabX+tagHV0q+sxnAduovzeTpgjf5rOCXs7O49DnFzEM8/eTtrRLnbzzfzezm490l1XiI5w LTRp4VST0X63O6q5tf1e567mzvY5yIq32hdemWne3/6409rT2NPW421p22fsLGxp3GfsKYCV5YVo hIwEMYN3kXOYsTsrmq7AahIl3BLScaH7jRZjx6Xucy3RrXu6z7fEdYx1X2ixdFztviTdI7cktxZ3 j+GdZvdVvIvsvtaS1nENTgXSHS7d28p3tao7Vvlele5SWzI7pvzvVaW70ZbcjunuqZaCjpnu6Zat Hfe7Z1ocHQ+777ds73jU/bDF0/EIWpGelsqOpc6Ylup9mu5H2G/3EvWbjv32aOS7abx3Tsd7554Q tKTHSJakr1jSEy2NQsqQeKfcE4f3yD1x0rjwzh000/015iVsC3E+ijtIjwV3kJ5k5PSk4RrsiW6p 3VvTkylrO0521u8L6clt8e6L9rZJTyekJwYtB5pGerY2lMI5Z6jl8L64Hof8LILu+lv69ll6trcc 25fc45GfOZDf5KcKdP/eMrBva0+t/NRCej4g0dLzCmjVta2lf1+a92LLqX2ZXSdaavfl9lS2nNlX 0FON/62CfnXIVL865OlXhxp9od7DgumXhnH0S8ME+qVhor5R38Ze0O/T/zdmpV8R2uhXhCWhHwlN Z6Wh90Lvsx30y8cX6XeOn4M+Mlgi+zhjTGCfZbGsir3CMuk9TqWsl32DlbF+9tfMzU5BKWdn2DlW wX7MhtmLbJS9w15i0+w37GX2f9l91sQW2DJr53guhX2NO8gdYue4o9w77O+5X3F32T9pajVfZn/Q nNR8jy1rLmje5II0VzRvcwbNrOa33FrNQnAQ96HgxOBN3EbtQe0FbpN2RPsm59G+pX2Lq9COaX/B fUb7v3Va7vM6g24d9y3dBl08d1KXoNvHnTLsM+zngw3/1XCEDzd823CMX2f4K8MZfr3hh4Zx/jnD 24Yp/pOGXxkW+E8Z/hASxX8R/9LEd4VGhK7hu0NNoev4/aG/Dp3lD4XVh73GHw3753Ce/8fw9eHr +bfDN4Rv5K+Fp4Sn8L8Mfz78eXq7dSmrpSel8fh7LdtRgOMAJwBOs1jbcdsJ22nbWdugbdg2AtSo 7Ypt0nbDdst213bPNgf1gu2xwAt6IUKIEmIFs5CEv/2juWV6m97GeL2oF+k3kiY+lU9ljM/msxnH 5/K5jOe38FtYEF/I25iGvs+l5Z28k+n4Mr6M6Xk3X8EM/Iv8iyycr+I/xyLo+1xG/sv8l9lafi+/ F3Q28a0skr7PtQ78nchitL/Q/gKf97Mb7BaNzIS/iLRVsypbta3WVm9rtLXZvLYDtsO2PtsxW7/t lO2MbcA2ZLtou2wbt03Yrttu2u7YZqF+YJu3LQpM0AphgkmIEeKFRCFFSBesQp5QKGwDnkkoFkqF CmGnsEvYLewRmgU4zNsWVwrJYJkTFqiYfOWxXA4KvcLRT/DCcQAmnBBOw7WzQA0Kw8KIcE8YFa7A p0nhhnBLuIu/r9P9DXgz2i/O8X8oZLJ6iNpc1gIxX0hxbof4PsecEOE/ZsUQ3++wT9Gb1ErIR5/W bdRtYtt1z+qeZWW653TPMZfueV0ac+vSdemsXGfVWVmFLleXyz6jy9PlsR26T+q2sc/qPqPbwV7U VeoqYb1w7DisJPSyBV+RBjHDbGcBBgGGAUZYnm3aNmO7b3toe2RbEjS2R0KIYBSihTjBYnsoJAtp QqaQKxQIWwUH4O0AHqFSqBZqhXoojUKb4BUOCIeFPsDHhH7hFPDOAG9AGBLabFO2q8JF21UoY0Bf A3zVds523nbBdgl/i6h/Wb+Xfm0a4uetFiiZ7OdQsti7UKyw6n/DPsZmoWTrSnQlLEdXpitjubpq XTXbzLiw+XD6bzgsBd8BVxoBEMU41xzUsQBmoBcAHgdllOpddwkiXPcIkI5yzZXGuhbos9n1uDTJ zRM/1a0vzXBHEB+vI0+RU9opdLY7yqcb+dgWAXUpNOpW6Hx3LAFexxr7Ua4pILjNdF1phzT2h7UC IvQnyuPBvkugdoGNWAfqW80mtW1qeFLbQMCx7nAnkV9q3Km+sSt2oS14Hf2j+FVcBaqgTzVgOwVw LAootqHPsB3qrIM+Fd8ofavnEHXIYywIcWf4+bFErvG6Iq/UeK3Bne3zraIb61bZBqQ73flU73cL Pr8rtdI3fsb5VGrFRvQXjgnHcMgtvqe9MjalPuIuKX3V7Sp9zb3Dz071WAJtFQP8oNSxKttwPIr/ AmOhSkWrY1Yvj0HxH/IUHSfdVX59KHXEE8avjDciYPzKZ4wfpJV20JdLK/ECa5/MG+6a0nPuutJH 7nOlS+7zT/TLanXrB7z+NLk/pZ8q2b+Kn2MD5uv96taVz64wadxPqn1+CfC1yyT56Wm1b97FVWr1 ONSxj/V5d4Mvb1xwt5ZecncSrdRKTlbW55h7v+/aVfch6hfjXsnX19xHSqfcr/p8pl+JDaqn3a/5 xojyM+6TpfdB5qH7Dd86l9uUadwXykLcl0iPEpNQlxndY6ijLNp91RevSi3nurJk93RZnPsa+TDF M+RK91x0WT2XXXmecczrrkLPBPG2ea67ij03Sa4UciLmy8A5Bh+6YkB/IB/Wf1m/ZzvFfcVKH745 3+m5g2Pw+fppsVcVsLYDYyowXwXmJdlHaJNrl2dWySGu3Z4Hrj2eeVezZ9HnK6XPwHysxM1q+1MA v8ziniI/I6S5Z8oy3ffV+1RZrvthWYH7UdlW95KfLmWfBShzeDRl2z0hRHs8RtpzFVD0VHqiqa72 xJXVeixl9Z5kGv8ToKzRk4agxF1ZmyeTaq8nV72Xlh3wFJQd9mxV7z1lfR4H1cdAB/iR5le9tydJ cVB2yuPB8dIYz3gqywY81dRuyFOr9lfZRU992WVPY9m4p61swuMtu+45UHbTc7jsjqevbNZzrOyB p79s3nOqbNFz5j25cLW9T9lT1Hn4SXVgfAXqU/i4j1Wp4m21vN+6in4lJyrnA2WdKGter4ollMNY jJf35/yV2pUozbdS++Bp43xCrvWLZXWtrJuIgHUUuP+pcimNR1X79v2AnORXP8nekgB/BvTn2ysD 99XAuk6V79S1MidKvk6V/P2Vhq+0KuvN1VHOcB24usu1roPlYS7mGSDoLTch+M7hij5FN9p3tDzG t4axH/X5WFl/ytlYbk/5G/YJ1/HyeN+6Rz6sO1x/an2uE+WJq569Zb2u0+UpfuswIEcpuch1tjzd 70yE1zAnDpZbS/XleaUR5YWu4fJtRKeWF5cmlZeW5pdXuEbKd9JnuF4qlO+i63DNdaW8mfggQ7Ws g2hz+W6SGS3fg3fx+q/r/ztjoR+l/1z1u9DfMfyPrEl/2ecrwUFsmZ6jvEjPUV7Sjmjf4vroCcqr 9ATlBD1BmaQnKLfpCcq7hn0hUXwhPRe5Qc9F/g89F/klPRe5Tc9FfovPRYJi8blIUDI+Fwn6CD4X CUrH5yJBH4U72pPsjZWnB1aebbPmWwWraC2xuqw7rKnWKmuNtc7aALgVaN7aad1vPWQ9Yn3Vqrdm WF+DKyetb1gjqJwDOG81A74A5ZJ1zHrVes0akem1TlmnrTPW+9YoKA+tj6xLH9NYY6mYrUnQC5YM 0oifYgmyQTbDiq8I5fTl+P3JgHvbVpiRdrYP7mrPQsmh+9xc9gs2CXey16B8nPsZN87yNROat1kB Pq+ClhzzsErVeM3MIluQAf1JI8+Qx66MvFU15kMwYhzvORjnG1DOg1SV9QLZiE/+1tEvEhlETxLw kqHwcC+N/283FYqGpbEXWDD7KMuA++ssls0MYJPAwtlWKBFsG5Q1TIRiZA4oa1kx+xRY+mm2nUVB zHlYNP2XzVjWCGU964ASxzqhbGBXoMTD2N9mH+YiuAiWQN8O7VgZa9HVoIyiq3lzRdeKpoqm8w8X zRTdzxrfMlJ0v+hh0aOipaJroqbooRgiGrM8ojHvrhgtxuXXihbgJec7rIl59/Iei2liZla/mIvY qrWyfIdYIG7N6s+vzRu1MtFRNJPf9kK1uL3oatFV0VM0TVqNoN9XxHrQQ2VLad7jrHGxEbUoxcqk kjUrVkLLtnyHPQZ1AX1APPxCdX4t0NME02K1WAvtNTCea9gLlb6ih2CfEe0GK6a2HM2vhVaHRW/R jJgG0sfE/qJr+Q6ErFnQ81A8JZ4pmrImFk2JA+JQ0XTePdTggyUrIwB5MQQ0h4gXSftlcTzLkzcq GmHUCNCbDBPiddSr9EIaFQAbEMSbUN8HrQBin9iIBT0h3hFnt4yIuZvBRjET5B6I82Dhop0p2sQQ uxb79+sbwB5mN4nR4H0YLVgJlALIoZYgRXb9KTBtP+5nvx/Yj2eNZ/XbT9hP28/aB33jVcFqfOTZ h1cs9xsF8O0jOMsSoA3Yh8/+a3n3xGR7fH4b4ESIyjbSOlV0zZ6SNWtPt1vz6+15RTP2Qvs2e3HW eNF9ilNmLy1asleA1E77rvw+0WvfTXO4aN9jb0ZP2jvs3RA7mRC5MIf2g/ZeiA6P/ahY4Kx3Njrb nF7nAedhZ5/zmLM/q8BZILYVzThP0WxCD84zzgEE+0HnKTFXaoHXnEMvVFLs+LwpeU7sy5vEGV+Z U1EDsdUH624WYB5jy3nReZl0jzsn8uvz5rLqKVaPifXYAn2Td8+amFUAxeN4w3FOoakUOM5D7KRB fQHgEoyfZfVh2XJ2y1nHmOOq45pjyjFtTXTMgH8KHPcdDx2PtoxuGXUsiV7xTlb/x+scfL7Dqdmc 7AxxGh01zmhnHPVQb010WmB1XnQmQ6xDH860j/P5BfY9tJ6gZ2emM9feC76r+Hhd3hVngXOr0yEu OrcXLTk9OEvOSjETR5I3BzM4ar9in7TfED0wKliB9lsAd+037DAy8dhmr89fx+xz9gX7Yxx9/uG8 x4rfi+47eKkWMx16R4QjyhGLq0jhbe4H3YsOM4IjKb3DkerIKHpk1fqA1ra925ENfRau5AXfvGgg tyHQunfkAwgOMb0DY8dR4nBRDMk0RdENSGA7HFX2PY4ae6GjztHgaHV0OvYr0Q0Z1QGyh6SV6TgC 2bUNAWdTyh0O3vGq4zXHybzRohmI/odZfS9OYLZ1Xod5uO686ax21jrviFsxH4KND2HuU+2F+cfE ZMjOj2FMTCzI6peyMc6Pc1Y85rTgzIsF0Huy84Fz3rkophWzYm1xWLFJLHih0n6wOKY4vjhR9BSn FKcXW4vziguLt2UVFBcXlxZXFKcUPczvg9kyYs6FnA3ZqXhn8S70Cdpd3CxlSoxgmNXR4t3Fe2gv /Px/oBNUDaunZ+b4P+VZWiPjAKLS9kBphtIBZSeUbigH066k9UI5CiUFynEoB6GcgHIaCvLOQhmE MgylFMoIlNG0UfzvlvoX9Tvpv3h+gn0S/FoECzuIOeF0oGX/GbwXCn7+LItkXNhs2EOyiP7WlTPI uLw8qIehLgzKyDmb85hgUAakhwFG5M+jAFdk/iTADZk/IvNGAtop9C25VviTMlxR0aMq+q4MV+T6 huqaAvfk66MqXYNyrYB6PEqt2BiobzWb1Lap4UltAwHHOif3uaAau2LXiHz9VoC9gRDY/4gKBlWg 2HZXbndF7lPxzaSKr8zhiGqMjwP8qNSTKnmlhmu5vMq36muKDVDn6uU6QmXDYEDfg/J8KrXa9lGp zo1apf1wjt8Yc2MBzABJ/nb6jSXQ1kA/BNaBfQbOhRrUMauMQfHf3RUduanv09dq4w+0IbC+pZoH pX+FF1jLMrkZANkAnQD738cv/7/Uin+V+knz9ZTaN+6n1IE+Vvz0tNpvfQXWk6vYr+jPz/GtnVwB QJRpUSWniuXcEpWMS9JPcS/n69wdAFUqn6ljA+e/JsdvHebWATQAtKr8rsTKIYAjOb616FuTr8q2 vJbjn2uGc3y5LvccwEmJ3nwYoA/gGEB/DuX1zadk3hmAAblvzIkLq8yhMoZAPvS1OVkam7oP5frm IWkMfjnwabEWmG/fL1+tlpdGJZs2X1zhb74MMA4wofLVk/KQMtbV9qcAfu4bsp8RzgNcyPHbp3Iv AYwBXA3QdXcFcq8BTMn0tDQ3PlD0zMj1fYCHAI/k8T8BcpckUOJus0auQ3L89tLNRoDoHL88vTlO ri2yH5NVY1cAfLU5TRovjnFzJkCu3K7A31+btwI4ALYDeAAqAaoBagHqARoB2gC8HyA+1HvK++Xl DxpvSq2srSftPU+q1blRvdYDa2XOn1TfeAI8rf+n5d7V/Be4flbb/59Wq3LRqvWfMj9qvU/YM1ft f7V6UtW/yu9uZZ5wDVyX1sHmmwB3AA7IMCuB77yqtFd0Yyw/yFlZw6M5/udjZf0pZ2O5PeZv3Cc2 z6/YQGsvWlp/an2bF3NWP3vLevNYjv86DMhRSi7K0+b4n4kmpXWcF7YyvjyTKi5kubyYgDiR/Z2X uOJL37yp1wDKxOc8xu890VsW2H+ce02uF/8LPwvjIvDFJikjAKMAVwAmAW4A3AK4C3BP/jwHsADw WPr8HC+DXpJ5LgIgSgWxKhkzQBJAKkCG3D4bIF/mC38GiAAlKnAB7JDtqAKokfoiqHsfaGAFKc0p HSndKQdTep9pTTn6TAOWlF5VOa5QzxxJOZFy+plD8vUTAGefKUkZTBl8NhEx1jI1LH0CyRMkh21H Uk6njKaMgsQVVcF3MJje+01ferOIht4p8iF6d0g0vTvkGXprSBy9L2QDfcfXTN/xfZ7eEfJRejtI Jr0XJIveC2KlN4Jk0xtBcuhdIFv+4v1xnImTvjU7zJ5j7FmIpWcXAuCxDIVSnQxxkwyxlRyhAoir ZIirZLMMvAxJcp26ootkYe6TsyUgfuEK4DXL2FPhuWd7nz0aUI6/h/P+/FUKvk2QvsnN6M0x0jtj gumb3CH0Te5wemdMDL0nJo7eELOB3g1jpnfAWOjtL0n0xpdkesvLR+j9Lin/bno5dpYNrvwNaEMf c26a2jCEZdP0Bs+mmU33Nz3cdJ8+P8KaYGnDUJImKUSWGkoyIh9LUjTykixQjFLZNIVF0ZgUBxp9 +ggvSZoUPRs8pCEEZE5hO+RLPW8YwieHPPpYy/fzP4G0/ib/jyye/1/8DNuobdI2MRtmTyaE/jh0 hH2C3lgTA2CS3wWT4GuvgfYnof0pfpgF8xdAVyy1iQOJaMKyP9anMQ4B3/qEGN9mxLJZvkoihpli JmMm18db6iwN6+PXJ65PWV8MJWZ9esyt9VaAvPWF67eRjlfxG7j89/jvQd8/4H8AnB/yP2Q8P8AP sCD+R/yPwLJ/AGuCYUxjTE+jCQHLfsJCQ38K9hlhxR3gxujZ3Xa2FiK5k7EPuySw7F+h1WA5tDof gLM8ZE6LwzJkvmu5aE63XMb6mWrLQILeMv7hZMsE0srn2BTLdZSxbLfcRJ7FY7mDfPMtyyzJRFhu WiotD7BGWQRLtWWe2oCspdayaKnfyBSgtukbCxFQJ4Fnoxag1AdgmwJgG/S/MVG2cd5yeGOKRG+0 WnI35kF/l6mvPtITJts1JNv0QGXPddJdu7HCcmxjemzKxnhL/8ZtllMbi5XxP+MAOxo3hlnaNppo XF4Yr0If2BhD84jvBGP0Bi3OUGH4LOMNLxp2Mq2h2lDN9IZdhi8wg+GLhi+yUMNXDF9hYYY9hq+y cEOjoYmt+cAxzHFn6J1kYawRzi0sAbJhwnkZLgBckgGyWsJVgGsAUxJs2AX1jFSrIeH+Ch0/tQLw mbNEE+00Z5uz4ydiouPjEgbWAbWuZF1J/DyUixuigFpcV2KmzwmOmOgP74qPW3ceSknCkFkwVyUc gCvj8eMoA1KLMdHrzkOL8zFxMdEx0QkXEw4DdzYm2izE3zG71tXET5h3+IB0mg8hxA/ELyKYhXXZ ZiFhwgfZK0WyMf6BZKO5BNq1JvQjnTCUcMqclOCAq3GSfWibbFc29C6CZhEtAu2yPaAb7Zk37wc7 L4MV42h3/IQ0fpCrSegzV5lroDdoGz8LmoBOOAafGsz4XpUw/us85Gj+2/y3mYH/Dv8dFmIoN5RD BFQaKiECPmf4HERAraGORRheNrzMIumtZ1Gh86HzbF3oQugCi6H3mj3zJ+U4fKNZCUAdZTkL/cak gr7LkCdnPgvJtdI3Dji2VSWXwXbh23l8chxko+9CRPOQj6h/6i2eesP36eop0hlFuoYiXUuRrqNI N1Ckh1Ckh0KkN7Jw0oRjYDSGYBrDJrLnqGz3Gep7I/G8ZDXHRlS8q7Ldarlhsppj9TIP/3vWv8b3 6PWYJ45aS5oYaeJIE0+agkiTnnTgm5aD32sD9RJK+iOe6Aue3vmF3pDmIZHG2Cz7ot7H49kOeRbV crtkX2yTeX/OLD1t3p9k91E2pLJb4g2zk6rYk3h18iyqeUfkWVR4/1Zz+EFm4V8zy6v5gmPn2RU6 FcTifx+P2u4DZ5QIJTaqJMoVtQNwFXzaQbwawhItwlUxqg5KVVQDfUZalEsnFDFqvwyiSqMeikig 6FM0qfXUUY1XWqn/GukzjsXwkuElGHO9AaLMsNeAEfCB9yY2QDMo/2UzshLgFHNGnoBSSPi0rz7h K6cjz/roQSiATQOmw6Z6LCrJEdMAgfJZ0nSW6hUNZ32aJD2NkWESx+QBuGyqNl2OHI4cRmy6jFFu +Lyh5s8doekBwDxzmuZMC6bHkXykPjIiMgow1rGR5sgkolMjMwDzkdmR+cAzRwqRItAlkS4qVSAZ G1kDJVsu2Ebv01gX2UA4NrIVZFCbXtbUKeupMi3ANeToqTWCQFd20AirDA1/wv7Bw/n/OmVXaR0m 4f/P5zK4bHYJPr/qx03m0igLe/248Vwi5fLdftwoLpZ1wmeXHzeEM9LvLAv8uIzTslL4nKLi8myB ztlRPt7K2J6+wk38Cf51kPgb/hRktu/z34eT9Rn+DLQ8x58D3wzxQ0wHvnmT6fnL4CED/3N+AvLP JP82C+ff4d9ha/gb/A1m5Kf4KbaWn+anQee7/LuQc4ZDhyHn/ARO5R+CU/lPITbwbP8Nwl8n/J33 0N9Q0UdUdJ+K/pZMw9g5Mwfj5ZT3lD5LvBguHj7N+fGMHPZ+04+n5yLg05gfDz3MwUyreOwRW4JP /X68OfA6B3uRmjfLHtBupOZNsxn4VO3Hk35nWuLHm6DYyvPjjfntBRJvhI2q5vpZukfDeWWUkznK yZiNd9OO5+dVQ+17vHpExf8m0VUqulLl+a+rPP+NFVqW+Zaq7bdUOiX6S36zJtE4Fgt9qxPvI6XR JK9Ig/3SPSjiAcAhLBhOeyE+rl++CVtiLFzDnOEsXBseBmAKjwmPB4x1InxOCU+HEhNuBZwXXgj8 bVBMwC8OLwUJLLvlOpHaqUs8yJmgrTZ8D+hohhplwuSreQAd4RV0TWqNUEElPXwn4J3hu1Tnhg96 PxPBldII98C4mSkEwKgCuP8wgd9MFgCIEFOazEe5/gA4JddnZHoAIBMgF6BA+mw8ypwh3Wun15YA nll7f+3DtY+g3F+7ZNKEdGMxhaxdwtq4be20ybh2xmQ0RZuMIP0QiynEZDFZSM4oFamVotGUjBoB kz5TGupCTSt6TJmgV7N2OlQEOi40NWR3yHFTHODukN3/ZieeD7qb3aFsEUbfJWah6QBWgDy5RigE 2CbXxfI1lCuVoQL82RGaBOM4GJoRmh2aHypAEUNLQg6GdGABWqRaAKkMKEmhrtAd9BkK1CUgi9d3 SEVutaKxTq0PdcmaFD3ZoUkgmYS6QppDekN6Q6tCa6DuCOn9M+9P/qzIXQNr0wj52QiRaYQINULk GiFyjRC5RohcI0SuMVOWcwDAadDoAYBTkhHyprEWoF6+1ggAUWsskAE+Z3Qwp258TVLEUcCpa7Kh 5EPJXjO9RtSNY1lTskagOn9N0hoXyLjW7Fjjos9Y6tbUrKmh6y6pyK38NWaDFOlDXaRpRU82fBIB 8oGu0u/RDejurKkCPK4b+ItHLr6Pd1F1AsD7He1S/R/vKuUpOwbKczR7mIPHlrOVnBzUre0FekaL czujO0jYg3zdBcZpOoJvQmZ+oMVdbDHoGuOCb2rhLlkTi3xDWtAs43RxGgdw7mj3Q4xUBjNsu4w7 3AxikID8z4m0C8ws1SONOKgbOUHdf5xCGcSaDuTwF0hyETH0AVjzeeI/QKzbvXQC+M3LsJsHbUfM pS7X4klBew+x7jThBOKUEu4ljPbf1OJ3L+e05Yh1EyTZgzuUdhrwUS3eyWXo9MTfTTKI+wmzYLw/ ZXgV5MuJQ88RggeJg22Z5g7REcS/SfKvESYNcl/XCaO3F6nVIo6ILeIogL6GV5fyCWcSprvfJZi3 5UjUvPQr0m/Q/JR6PA+e+YFOAPw64T4tzDT/JuEHhKeQH7Qe6aAR4kwQ/XPCKcR5TvMWYIFwkYSR zy0RPYGYu0f0m4QbCedKMqQnjPRsQf7y7/nfA8ccDKPTHNbAeTk4VQO7uuZ3SGt+SvwmxMGf0bwB 9BLSXCvioGK6+l3iOIP/AY5tJpLkCH+ZNFwinR7C4cRpJT1/TTIhhCMR60TS9i5hSf+JoBM4dsL/ IwiiPeid4AH0DHL47cHjQN/VbAT8P5HDpWrwHPoC4iAr0UkorzXJGv4W8FvI5/dpNgD92SCwh/tn TRbQP6FW30Qc/FWidxE+TvjvEGsrSc9jxNpp6rEO+Rot8e+R5HaiY6gvM9HdJLlZk0wW4kr5PeKg ScQa4vAvE90ZdAPfgk6SlSQzTvgMYraec2EUETYQ1nOwEpcf8D+i/8ySjmuWw/ugm0Hr0XK8z+Gm efTDEuKg9bAuOT4daf41onuCtmE8EP2A8K+Rw79OeAI53AbiP0IMWQV/wbSIdNAuwil0dUITi+OV 9CDNnyb6C4SnSHKc6NcJewg/x0G25IvJnucI55K1GqLxnWIwIs05xETfljhoA/SOMlsIe4g/R23n ifNrxMtzmgzwqiO4DvA5XPtBX6IZ2UvW7iL6m0SfQAwydRTzIKm5iph/nVqlECcWrwbNkkyDzBmk SB5EL5FkGHG6EAd/lehskj9C2EUaRoiuxau6dSRzhPBHSMM3SdsSZaplsi0MMbtNOt8im1uluCI/ f0Hzn4DWUYxFBr8IMh+jVjnSGAlvQ7x8B0/4/GuU56OXf0/ZG/O/GWluA119Ha/yHqLfIXqA8EGS 3y3zUX6eOOmEBcKmpR3K3R1cxT1lkuSTSEMStbpHuIlklgh/grB07/gWYXxbA6wjfKIIM/1FwIdJ z4Ol8zh2krlJe0o90sHUC8ijZDfmZ7iXhnmHlUC7G2LNh4neS7iVJGs03wXJz+AuwLn4HKT57eCl H/GdhH9E+C554zbguxRX4TxkIZ6j1bSd8KsUdXbNb3G/17wLnL9CzUFm0u8hehYxN0+cC8TpJrwd sSaW+EnEOU/454S/hDg4mWS+TXQU0eeIbiadl4jjIPlXCdcjZosafKo5RvhriLkYovsRg1VI3yZ8 kThxpK2XLNHLGpBDmvl0olMJXyE8RPw+wrsJdxK/ktoyuXekyU52k/AbhOdkGcRHCR8iXId4eSfR 1YTzUE9QJmmm+eJOUl8TNNJr5IetkrZl2sEhxvE882P0xvI5HBfhB4iBj5lkEDGcQ5Bznq5eICwQ v5fwNGKNg2S2EzYTDiM8S/Kvk8wd0jlGreYJxxBuI5mDJF9PMo81kKu5DM0vgP6n4FqilwCbg40Y +Rg/XDDSXFRwPODQ4DCkNXiOvK3FZyk3gvFMck8bRt4TAT+POw5br3kBMO13bAvRBtzdln9DMiZN J8knEUb+vyAG2kE4inA2nXPSCX+ITkQvEbYQvgythjC2gcZ3cqyjPdQTHIQewzMku01nrX7Ct6WT GNrMJwVTBggeQ4ynOz4Jz6tcpTaV8Dxi4lxCSe4S8S8Rf54488SZJ86l4GrEeNbl5hGDDZJML8mP EV/SNkZ6ekkGe/eQTKqkn2R6ie4lzb3IYYs0ljHCi3TSXpSsRf/wW2gsWzT/ghhbAUYNqdRXr6Sf 7DlJuFSm8WopSsJuQjmW7HmdbHsdRwR0KuV8Ggv2BWeGeqKPoz2QwyB+2Kdx9ukvL/cY/hKWMSth tNbA/pbwXsxjyz+Ett+nvBoJ2RQ0LNHuQLiXOIuIuVSJxvM8nGbP41WkuVQJSyd2apVK9wK9dHrv xXMvYMy0ScjnPSQzTzorSaYS71mC6QlZcBTqAVxLubQCW5HkPPVyiehjhC9Rj8cIz5POSrJwjq42 SZhaNdHVX1JfvyT7b5PkbUknnsC5SslO8s+ixJGv4hl+jFqNIR+u5hOdTyMNw/X+x9PIkXonPak4 42yOWjF6BraVMFv+GeCo5UnA8cSJIk788h/g/D+CHGiP+Dxinp6z8Xqyip56whiRk050qrR70lV6 Xsn3EZ6Qdmq62iaNSNpbif4hYvA4rOVlG2LoC+lYxKAN+20k/DLhOsSQr36GM4KWw7yEEE27P1rO V5PMEOFemZZsxoxxiPAM4UnC/YRvU481RN9kdJeBOyb7Gkf3rboqyjbkQ8qETMoq9K2e55Gz/AA5 kBlwNcXo8Fsrk+R5hqsGshNlJG0MeT6WZoeimjJDL84dvwXXLKzNXszV0v2yfFcrrRT01XHyniD7 8CieV4kOJ7yF8F3y9j2iD0onEMIelIfzxv9j78ujqji29et0nepzhAYHUBFRESdUxIOiAiqiICKO QTRGiUFAFEVARCSGKKCgUdQ4xKhBRBzidY5z4qyJszhEnMc4xBHHGIcIv6qv2nO99+bed98fv3fX W+slK19/Z9fuXdW79t6nqrs5Ea099NmcQ/R73YYlkOAtHkNvqc9t8L4EGp4DvxRIXoP/BbgXOvWB yyHxALcDtgPehPwe+HbgZGCJQBqG1gPAdGAP9PIYOn6QhAKXABcCS9FaDIyHJBwjD8eMh4sIMXQF 7wHeQ8QGv2oZ+eJ7rQm8Wl2PQHG96xGrf2Dd1QHWNgAD9DvMc5DvQtMP8qPAA8CFcoUJzcr4Zu8A tAV2AvpgnTAeXAViBUVqASvoqxfxLRwKzU0C33YpQ80smwTMAw4FegI3AcWqlenyFKCouqT0IfiP wLHCGta65O1LtHJeepbxb/O3F8W3c+kj1ZbjQ4E8wlcAjyBua4LLuwEvgOMwQqkj3omI0znGQ5+B /4D4fwC+D/K74EXARUBRqQh2f8SI8QsPlD0Q9okjenkCToyRQFyLkV9j6S8mPiNvb5r8xMjFdzeX 4B6IGgB8BNwBTAaK1R0R+nxUWD+w15APB6YDA4GZ+P4tAO7h3wJ9zN4cDwg03hCo+gpUgEYCHAn5 CoGmqQIN0FcgMUPHVMOM+y3Qv4/W3sBVAink7Do4LBiLITkEy5fA24EzYEVIAsDHQD8FWIq+NKAr Wp9C80PwckBpuT/00UptIXmDVk9IbkFyF3wluB30ywPTgArwEa4iH5gAySxgPKz1AmLkxligvGpH 4BFIcoGRQHdgODACiGs0DsNI5Nha4+q2ANFqluPfgNZE8N3o1wU8FIiR019gzQeScQJtMEflMF/m GCDkNA/2p8FOY8iDIR+Lc5fBzhlgDiTwP8NcKI9xrhNal8JCZ7RuhAXImTd4AXhf4G2gBXJESFl/ EYcceRwq44DpiMyB4h6R4Vu1vIhPEfnsgEDjDYGqr0AFaMS9QeNIyFcINE0VaIC+AgmP8LmI8LmI 7bkiYqUFwU01pGXBjfelNcGV3tBZJZBCn2EVTWHfWAzJIfR7CbwdOANWhCQAfAz0U4ClGKEGdEXr U2h+CF4OKC33hz5aqS0kb9DqCcktSO6CrwS3g355YBpQAaJ6KPnABEhmAeNhrRcQIzfGAuVVOwKP QJILjAS6A8OBEUBco3EYRiLH1hpXtwWIVrMc/wa0JoLvRr8u4KFAjJyiyhl9IBknZxOzdglYjDki Ag1yNlcItAGWw4ybY4A4l+bBwjT01RhyIvXBg6EzFn0tQ79ngDmQYL4Y5k7BfWyTE1qXwlpntG6E BciZNzjudbO+wNtAC+SIq7L+Yi9c1ruMx3lZV3yrriztxvEGcIRA6iLQAFQI0Bfy3sD9Agn0DZAY oUOnQS71R6G1EbAPMAPyx+CwoAwF3sS5CeALwRWgGZIC8LbgfsBxkOQAvwR+CjQCpc3VQMgN2eBv 0VoVkqeQPAcvBoc1xQRsAzQAR0OnB7AVJJ2BLWGtIbAWJM2B8nptgIMgCQZagI5AT6ArsAU0vwYu gLWLQFy1kUHnPFq3gF9Dqz34UuBEtD4Bl/O1SyCT84I5MjYDtoNmESwcAFaGvA7kOEv5GTgMGAj8 AbgDOmk4KxeSMPC64BfQKuXzwU+IlQ+PqwjElcBVQF8g1kVEyp8J5FEUgXgTkrngv0HHveyFuO+K deNmxOpLrB7xNo5RBWLFTvHeD1sBySSsEm9Dgl0wjQBPQOsyoDOs7Qdux5OsWJy1tHSM2FlAkoS9 7TVY8Ad6C4kJezSDG1DuC/pC0x69yDdMTonxm7CnY3L97yT3a9gXBwlkbQQaVeA6yF/iOdFGeT+2 NESs2AUq2WJU9Li8b4m+hgADZL+wcA6td+R+ED4MF0hX4VpOQ3ON2BNRuWf0hh9QAXjGidYbGPlG zEIJRtgPEshVjJ/7hLeygwKNXYF5YhesTEaPS2DfG/0WQl9D7xpspkoL4i4u/xLajZ31bly1wErA 7cAMYCrQostPw88CZ0OyHDwDfosHluDOA54tUrzxZdTvbJdOwK6/EP0WYnbEufv1kSdhtygtnBa7 A2C4QO5J2YuQHNX1T6OanYZNGdVJ0CwEL8QVCbkZPrkmNI1t5f4FFmKAC4AHZTTq8V+I2IjALMsZ TMK1w+eIpY2YlzTMeAXwKbDwo9xdQt9P3pOBBSdcdTIicAg8n4yzgmW0yKjQc6Qc5zniLBX3GViu aFXPwHKUsGN8APsX0ONUjCpXYDnEnvmpQBPuS6hbdQtjMCMcTdg1qwMEZwTy5fDbYWkTfeXLXTPu 89wTaJwg4wcj3I1rCRBvfjN5DyTRcInLa0BnLq7FCTwCc/oaV3oJkkJI5qCvm5CEwYdjgUOBzsCu aN0MzeV4XnAGlo2wAJ+wY4j8DFnNMDZkOq2DUY3AU9TJwMV4ruoKXownrW7gb4CpaA0DmiBZDhyh 1uBYG89na0NSH7wSLHwJSZBAch94XeqAX4K1WPlsF2jBk98lQAdYeA75VeBs/bmzWGMU4ymzq0Dm CJuz9ZWb0Nmur8eCxF0IrG/ddAwS3sYaw1W3I7Aznt0PQY9GWLNgbBPQbzzQLCTGrpBvxgg9IF8O y8+lN2DZH9gIiHWaUhWt84GtcNZkyAPYI/GNA/lOcWdJwVqIYP2j9IW8BXpsiF6SIYmH98rAM6B5 AWgnrkKRT8YpruWknF+8U9EYdrDKpU2hvx2+2g/eHa0h4C7gWK/ymRI2n4F/Jr0Kyw0wHifJ5RN5 jPwUerwJrIQrXQ+ddPASWChBvxfkWwGQ3IX+evCr8rrk831WJsapR90UMR6xW6e+gtMJsOwBzZfQ mQXeF30tln5WxZtEAWgdg9bumLujaLWDhWuSQ/4Kdyfugw+QMS84HQY0Qb5XImbhMfhF8DnA2zLm WZYYv+BsBXCGjGdx34/egY4LfLsdvedD4qi/C5GOrOFowG6L2wTX37KIFtGox6TQTIXfstHaC72s geQEELsVJQg4AvF/H7mDPRSNkHONq8jEuZngj8AfSY5zKXq8i5E8B36JfQGi3YTxq6ECTYhPdhDj WS3Q/B1av4K8DRA7JpokfQI7GIkJ3lCHwNvYIxjSZSVB7/UxkihpGRZyMf5cWR/UNPgnDXEyBdVJ 8DDVh1uYBx1fJip2tngyxWtOidjHCR1yQ3A+73i7ABgMxN0qxROtlxAb1+GTrcKOslCvb+I50TN1 tLCvV8KaqGBCPpeJN3x+Q1+/oIasA47FdY3G+A/DP/aQo94yAmwCydfQKYRPjgs0OgtkryG5Aokt 0AeS6sBRMkrZM84fQnIH+ASaXcWdMR6HARhPGvoNQC0NQO8cTfh2YGno/Q50ugrkOoI7w7eTgduF Pq8VaThXYAywiUBaiJy9AzzO8F3DZHYjnoHbBRrrQucKuK1AdQlDtAg0bUGEVMW198YYimB/FJPj xKiYzDLRezBaN8PmK/BX8CeqolGBH1ZDfhhX4SL1cb1/MJmzaXirQYzwBOzMAu8Lr1YXaPTBaPug 9TTOKpDfa/L7Qh9tAGY/DVzIO6GvP2S1lPZ1T4oex4P7weYfmLWH0GksejRNh51L6DcFkXMGNsej r53o/QoQeWfMAzbEbLaC/lFwdxlFkkPnsrQDnAlNeIxlgSPauVcdMftC0hIS5KC6BnwkbMaA2wD3 ofUjnNUHPm8O/AXXtQD54gJJQ+BlYCfUgQBwA7g9LCMHlcHAt7CwW9qRmQXuirNegM/FWcHyu0Cg KRvWUOdN8XI8skpDcwYkD8BRjbm3RSu+EUz4VmI7YbmQNUA8N8C3VS/MVwNEbwNEewPk3Uxxnwo9 4ltSDQfvCO6Evoow8l3AB7BfgNHul1zaAe5GX4Oh6YOMmwyM1+M/ALMj8nqcsGDTT/ByMwU3ewMV 9ItVRDlPZBPeqWNYiZkWw0JPxKoz+Aq9Pgg06JHP0WYk9PFen3GQHtsCVSZjLADZIXgXyDuhl2aC q6jeahQ8HI1oPyieONDL7DTHZPhkpNGfc1vjchHhxslcE6tNwwHBeUZMFvfZgBECDQMwI23EWcaR wks8Yn3E/T2j2AskC4mhWPRiRD03yu8XVPu33fXnKZkcy4OX15+k4Nl0GZ50lI0HxgN74t7RffBc 8VRC6Je9KDsNyUzxbS7sKCME0irgk4HbIfEFLxZocAMehaQvWsOArpDMBtfAS4CpwOWQHwdfDJwH tADrA4NguZyUvD0vvt1wdWng12EhFq3thITvYoT+AGAp5FfBr4lWRY6hWHBjc/ATaPUAOsHya8jN eELdANwdvUSAx0PzOaz5yRHCWlfobIYE104uSU1I7KA/GTav4d1dkxyzvHYhUcKA2/Fc+zYs7EPr ejkL4jm4YQDwS0gG6z4R1lxhuaN8qo5zu8BaCbAdbK4FLwbaST9D3w2SDNiZgHPPSg/I2UTreuzI HKCfDvlLyPfgqpOkt6UdtFJgd0g6Sy5nQfeYsHNRRKPhpEA+44K/gr4LWj+CfjhGFYJeQsCllxpD JxSjvS+vCNc4B3Iv9FKprK5AtPrpPQp5Y1jeKpDNEGh8I1o5ryvqAyTOciQy5sXbCEp9YAsZ/+AW vKVQA9Zq4L2F6wJpFbQ2BnctmyF8jr0thTwfuFx6RiIkGUA/2Qp0Ac4GrofmEXjAX8atHA+wBBgF vArNSjJyIInH2M4C78u7N7DzoYxq6OwHnsC5F3BdocABwEe4xlvQ2QLL0yG/BhwiMxo8GnHSEpqp 0hqQwv+v4JPjcpzAwTirFNwMnoy+zmBmb4uzzN6Cm5CnajgwAHPXW7SaUKPUBngT/gHmsSauawxG 1QtREQNNVC1V2jdC/liO/G0qMkvgXjlmmem4X0RxVyoXNnORxfkiTng9rIu4rYtqVldUHllhgL6o Rdmw44f6gBpFbkASrGef0Ckn65hAGivrG+SlwIvAk7AZVNqIIwH3hGYaRrtQ5hR8+Ax3L32BeMKu zMX1/iavGu+WRBpv8vGkGrsLjmjfg/1IJO5O78HTvcaE6O8I2JB8wwrCBiYPjCKu0Z8mx5PwwcmD hpEBQwZFJZOh8QNTEkiasNs7LMiV1OTfHGXi//FHyhFbUpE4EDvxicvMRPzVmkbKk0rEkdjzz+JN U9FCrMwg/hpD5wpRCRV2u4aHuIrfYkG7UW9jpAKpHB09PIlkAHOAucA5wHzg8pj4uMFkfWxcwkCy FbgzLiEuhfwIPBw3MjGenACe4YoDySXgL/GJ0fHkDrBk+KCYOPIc+DqZNxsIEPfCidGKFEzcnBKj U/9G8ldmILhnLd990dH2PTS/h3bvoQko7di8h5qOFUld4kG8SRsSRLqScBJBYkg8SSHp+IWA2SSP LCGqeC2BTJJjNlSSR1W+v2Ywi990Fr+wXVc/zibiLz8NNt0J/gLGZiPGa7Ap0o+X5LFCTXl0WM/P 48eqwfLoNETacdrN++L2nU7on2/qVyHeJ8IbRPhVE4WPupt4k8Hkh0//w79HxYaKiDK4Kd402NiX uBA/0oGEkjDSj0SRoSSZjCFZ3HNfkrmkgCwn68hmspPsJ0XkDLlCbpIH5Dn5g391aKbNhJpWmVab tuC4xrQVx7Wm73FcZ/qBH1dztg3H1abtOK4x7cBxrWknjutMu4jCj7v5pzVcew+Oq017cVxj2ofj WtOPOK4z/cS115j2809rufYBHFebDuK4xnQIx7WmwziuMx3h2mtNR/mndVz7GI6rTUU4rjEdx3Gt 6QSO60wnufa6v/OI+GXyNJLxb3nkFK58leln3TOndc8U6545o3vmLO9nlemc7p/zul8u6H65qPvl ku6Ry7pHrugeuap75JrukevwyC+6R27oHrmpe+SW7pHbukd+hUfu6B65q3vknu6R+7pHHugeefhf eGQOySfLyJp/6pES3SOPdI881j3yRPfIU90jz+CR57pHftMj5oXumd91z7zUPfMKEfNa988b3T9/ 6H55q/ulVPdImfQILzTwiNkgPWJWpEfMVHjEbJQeMTPpEbMqPWI2SY+YzdIj5nL/DY/8SI6S0+QS 98g98pS8NigGG7ON9IjZVnrErEmPmO2kR8z20iPm8sIj5grSI+aK0iPmStIjZgfpEbOj9Ii5svCI uYr0iLmq9IjZSUaMuZr0jNlZesZcXUSM2UX6x1xD909N3T+1dL/UE1dqdtX9Ulv3i5vulzq6X+pK v/y3PfLA6pH6ukca6B5x1z3SUPdII90jjeERD90jTXSPeOoeaap7xKJ7xAseaaZ7pLnuEW/dIy10 j7TUPdIKHvHRPeKre8RP90hrPWLa6J5pi4jx1z3TTvdMgO6Z9tIz4rc1xbjxDTSTfxNoJEG8PMa/ DVxIfWLh/goi3Ulf7Wde6QPNHxhnaqd1NksrBgvjsjM6m6Wd5awj9M7pbJZ2HkzoXdDZLPy+Sl3i SXz4fHQlfUgkr+opZCyZpF209nTJ2tNla09XrD1dtfZ0zdrTdWtPv7zrSbvPWSdzIJc90Nks7SFY Ry4r0dm/GtEN64huWkd0yzqi29YR/Wod0R3riO5aR3TPOqJH1hE9to7oiXVET60j4rlv8DR48gWM s+LM14N1lDr4LuYrNztvrAJSiPi1KPVvZouvfmgnoii/g4VYWWcrC7WyLmAMv4HnxNeKdXHmU5z1 DGc8h/Zv0HwhokV5ys8Q0TKbVPtHX5H5fF2zhmwlp3j+vOSZoxmqGFwNjQzeBn9DiEG872y03ctt zQPbZ2U/vmPKMc7mghVZ2XErO2FlJ8HEqlRTTgmu3OA4B20/W7VOW1kxGOXesyeOyhmcIUYyVRGj +Ao6Z9/TqaKIMc1RfiKUa85RzlktnbeyC1Z20couWdllK7tiZVet7BqYia+bnYgrnz1P0pK0Ufja QFnA+zuEXhcoB7jWAoWvFJR8/vkwpPnKQS7NV65bbf2i+8KkTFO+5PFSoCzjmsuVVcRGWaOsIeWV dcp3pIKyQdlIKimblR/4ip9iZezIo0b8iotY91XQf1FxEW9YqazkNjdyfarsUHbwtSKPPGU2/lJc /F6eiEP+rSP+H+l85cvrrDJfmU9qKHlKHqnJbewitfCX3+3wl98B+OU7qk5UcxSxW6AU3VMbaiPu Q1EN9rgGvavWoCLyDWottbYYoSGCrKT3aC3qThtTT9qMtqRZdALNppPoZDqNTqez6Vd0Hs2nhXQZ /QtdSVfTtfQ7uol+T3fQPfQnepgW0ZO0mJ6nl+l1eovbekAf0sf0KXNnHqwta8fas0AWxIJZZxbK urMw1of1YwNYFBvMhrFENpKNZp+xsSyDZbEJLIdNYpNZLpvGvmQz2Ww2h81l81key2cFbAlbzlax dWwj28J+YNvYLraPHWBH2HF2kp1m59hFdpXdYHfYA/aYPWcv2RtWplLVpNqq5dWKqoNaVXVWa/Lr dlVrq25qXbW+6q42Uj1UT9WiNldbqD5qa7Wd2l4NVCPUSHWQOtJ2ve1G282aoqmajWavVdKqaM5a La2OVl9z1xppHpqX1kLz1dpoAVpHrbPWTeuphWt9tQgtUovRxK9WfEvNVCw5atFafB4a0AZE4V5u zOehCW3C64MX9SKMtqAtiEozaSYx0fF0PDFz72eTcnQinUhs6Bf0C2JLp9KpROOzMZ3Y0Vl8Bu35 rHxFyvOZmUcq0AV0AalIF9FFpBJdSpcSBz5TfyGOfLZWksp8xlaTKnzW1pKqfOa+I0589jaRanwG vyfOfBZ3kOp8JvcQFz6bP5Ea9BA9RGrSY/QYqcVn9iRx5bNbTGrzGT5P3PgsXyZ1+Exf59XsFr1F 6tG79C6pT+/T+6QBn/mHxJ0+oo9IQ/qEPiGNeBS4k8Y8EjyIB2vD2pAmzJ/5E08WwAJIU9aBdSAW Hh1BxItHSDBpxkJYCGnOIyWUePNo6U5a8IgJIy151PQhrXjk9CM+PHoGEF8eQVHEj8WyWNKaDeU7 mjYsgSWQtiyZJRN/lspSSTs2ho0hATy6xpL2PMIySAceZVkkkEfaBBLEoy2HdOQRN4kE86ibTDrx yMslITz6ppHOPAK/JKE8CmeSLjwSZ5OuPBrnkG48IueS7jwq55MePDLzSE8enfnkAx6hBSSMR+kS 0otH6nISzqN1FenNI3Yd6cOjdiP5kG1mm0lfEb3kIx6/u0h/HsP7SASP4wPkYx7LR8gAHs/HySc8 pk+SSPYz+5kMZGfZWRLF4/siieYxfpXE8Di/QQaxX9mvJJbdZ/fJYPaIPSJD2DP2jMSx39nvZCiP /zdkGCtjZSSe5wElw3kumEgCzwdbkshzojxJ4nlRkYzgueFAknl+VCUj1WpqNZKi1lBrkFE8V9xI Ks+UumQMz5b65DOeMe4knWdNI/K5Kv6ibSzPHk8yjmeQhWSozdRmJFP1Vr1JFs8mHzJe9VP9yATV X/Un2WqAGkBy1A5qBzKRZ1gEmcSzLJJ8ocaoMWSymqwmkym239l+R3JtN9huIFNtN9luItN49ilk Os9AlXzJs9CGzOCZaE9m8mysRGbxjKxCZvOsdCZfaTW1mmSO5qa5ka95htYnc3mWupN5PFMbkfk8 Wz3IN5pFs5A8zVvzJgs0H82H5PPsbUMW8gwOIAVakBZEFmkhWggp1LpqXclintE9yRKe1eFkKc/s vmQZz+4I8i3P8EiynGd5DPmLFs9zfQXP9gdkJK1NG1IL9abP6BQ6g35Nv6EL6WL6Ld1At9BtdBcq 5lF6gp6m5+hFeo3eoL/yevmANaTPWEPWmE5hXVlPFs76sggWyWLYEBbPklgKS2PprJAtYyvYGrae x9L3rDHbyfay/ewwK6Kn+fEMu8Aus+vsFrvHSthT9oK9ZqWqoqqqjWpHf2Vd1crUTa2uxqstWThn A9QodTC7brtVM2pmTdMqaI6ak+aiuWp1NU+tudZKa6210wK1TloXrYcWpvXR+mkDtCgtVkvg15qM mkZQ0wyoZgqqGUU1M6JqMdQrFZXKhEplRqUqh0plg0pli4qkoSLZoSLZoyKVR0WqgIpUERWpEiqS AyqSIypSZVSkKqhIVVGRnFCRqqEiOaMiVUctckEtqoFaVBO1qBbqjCvqTG3UGTfUmTqoM3VRZ+qh ztRHnWmAOuOOOtMQdaYR6kxj1BkP1JkmqACeqABNUQEsqABeqADNUAGaowJ4owK0QAVohQrggwrg iwrghwrQGhWgDSpAW1QAf1SAdqgAAagA7VEBOqACBKICBKECdEQFCEYF6IQKEIIK0BkVIBQVoAsq QFdUgG6oAN1RAXqgAvTkuV+LfIBcDkMW90IWhyNzeyNz+yBzP0Tm9kW2foRs7Yds7Y9sjUC2foxs HYBs/QTZGolsHYhsjUJuRiM3Y5Cbg5CbscjNwcjNIcjNOOTmUOTmMORmPHJzOHIzAbmZiNxMQm6O QG4mv5ebTWnzf5mbR+hx+jM9y3PzKnKTx5Cem43+7dzcyhqxHWwP+4kdYsfoz/xYzM7ruXmXPWRP 2G/sFXurGlSmlrPmZm2em8OQm7WRm7E8N7f8aW4201pqfpq/1kEL1kK17v+Xm/+Xm/+Lc9NgEP9H ahcygBTwb9GNZCc5iN3tbfIY90mwbyaN+D6K79/obzyWs+jvHCfQVxwn0Tccp6mTiMLaqmkc26lj OLZX0zkG/omFF7DwEhZew8IfsPAFLHwKC5/BwuewwPd/6lihATbOyjKsLNPKsqxsvJVNsLJsMOyo tWeCa8/fSXi1uUYIe8tKicLrAt8n8tqgEpXXBxti5nkdi797DcUdpPrEG1Yq2B7l2czPpPfeMR4X Yrd/jH96xndvl6FnT8fx3Odt8kjvYYcodhQEewMDP/Oq2BPiGYUZO95f+W50lbgHohTInSMpti1v a/8PTy7EmMSzKTfiwb0boN8vOIK97FHrvv+m+PVDsFtWdvsdU0cL7X+5N8YTGzyR0/CkibtKeUyr Gwcbhxjj9Cd3BqlFSFXxdxaOkJKqAyxZVfup5RrlhOT8bmcwKQVZVbtwUSfFYPCytZRTWWN7qjgz Yhmo2jRWDUZDVivFYCzoZfnA4vGexKWwZoYLaYN/e5AoMpIkkngyiKTw//zFv5ba7xkzOnpmq7mX Vhb9OMcy5v6aGm1dPCt/Ma0gq5KXJcsYacmiXQuoYlAUG8+VFS/1LItYcGT3u7Nr8KEkeTW2NFRp b6Otg1tgYtKnyXGDh6S4ukc3dPXy9W3l2i0uOjlxZGJsimtgYnKSp1dNi4tUrvy3LYnJA1PiEhO8 altqiXbq4PTX9rDExBTX9qNShiQmx6V8aqlZ1c7SyuLTjP/T3MvSrF9VO69m/GMLLuT/9LN8Cl9x I6qD0ruXl4OlovhgdrD5cODIIXEJg1N4NxUs9kJocjCFDYoZnpgQ825gNv9sYHUsteXAnN9vjxnk 2itucAK36tozsL0ly+BmsbNOoMHACM0ylCdcbqNkGQxky6efn/l4Q0ff5d6rvC68qtei8+jdb2rl H+g44tHJ4Dunc/cN6xoW9Xyesq/buc7xTev6D9pVVGeLbciWcaMud9yxYrp9z5/qNX5a8KtdnVon 29d9HTXveLWOS2eF1pp3bENTt32hTdITz1eu2TrXt4Lv5R0Nn8e2bmJoVlbaIGTZpnjDxLw3P6yP Hpf1KqIgc0L2tHVPt85efNxnWc/sqg0mdr9seUHaPt//qm3mzpyH8b7fenq/2Oi51ubzqBlpsXlz R9rlrH364zPX73tUmhp9xON8s47VSraFzmnds5dTUewHn65YPfFgH/+FWT0nJbDvWuz5rO6OsNi2 87ofbTy2ecKETurJ/BOhOUpCDlmye+LVXor4VeDFma8tmb9bHLg7a9QzahYb1cxDlzETpZbMQiE1 GDPnWzK/zqjQ/0TSo7jk/DofjHVc321a2ZFFyf/z8ZZVnuwhU9q0mVTxpP+L6AdXAyzlxRgdDIYy I7NQfrDUEAJ7YxWj49EaRakkqf/aJxd+7D7/gyDPxUHRjy22orm80cjTKOe91KEiIj5buWZsaP2n Rdu7pxT2bZDSaNSGnLcru85OI93uHr7vdCnuJ/vC9GdK4P7DE4++7HV078IdfRIfRwf9JYiUzDk4 v9hlq+3Canazz16oubrh548eLhu5avoV32lt5w7d7jP81KS1dd5evXsmrtyMSTtKr5Nt3s9+T39V oZInu99wzqwOw9xHbPGZfs1kd+jjIcd2ZLQfFrt825Zt07wPP6UV0sf8dupah6uflV6/vqr0xdVi uw1JZ2be6LHZpzC9yem2F71to1opCzOH1vniRUT09HX9tvmejcztPcG5+W+t5xZkaYWfTNngsWXR 0iMrL7hu3mWplu3qaNdoe9jz9tcGWG7MdI+buCfpl2ffrizK6JCcas9rzBheY6L0GjPQsP4b1MLK 7+cR43XmP5jVvOB48ULTjJeZFs299ILTwvrRkjn+/8vY7BA4PHSN3Xr0DHunTv+J+n9Ze5aOSHE6 cjGv6esn0dUyFk8rO5g0XlvUqdHr1/3WFXUrv6P1hdrHWPHn6e02zUut53epoIfrreSfA0fcLot3 fLVwwvp6E3c4bvp4Z6svPH9amR05IjuzwffN6avVZ2YpJZt7V1SOjM9+sSc7emC1Ase8BQvzgqNb navY5sMDIa69qvx+tG/pi93OhzcHx9vd8WNFy1xuTHp8ecXepPH9Tz592m7r+SULFpOEFZnHSvyM q3eHzvRwuHa3fWq5DEP8YNeNXuv8h50KMI8vTrJMtfy6M/dE05LTOe2c+y3dPST7zhfpM2howkeB riF5k0oPddxyp6vRYBtVVPjAZVa9tye+s9//cnNd58/epJ+J6H5y8F299ry0ZP7257Xnr1l8Pvn0 ES3qk8uLUxZ+Yj+3/fL+DoH1MX01yous54lsykDdqFHH6GSpkvHnaR8kFGoZ21paW3wLWhW0yGk+ JCUlya9p0+jkeM/h7+bQMzpxeNOkYXFC2jQpOTFmVHTKyKaBvXjgeXKRJeTdCA0GYxuLn8Xn3WeL kuOhGxw9evSfGRyU/J6llL9LKFSfyMgG59ItnSt1at+qzYBRG28WkpYVQ9Z59P1mbvrDxZUWzS1x 2vD1i+HTzlmcXVbXjm4fPOvsWmf3Ll+3/DwgPPJo1Pa7f8R9+8m4nyYuy9HS//LLR59fnFQ8Oo0t q3s45mX3D7YEuU9z9gg3uyf/VMuprcdx0iDR4eTSgU/PRPntIN1Z03mDP78VHdiutbZzimnM9bSA XVfTiia6FlZbtD3y8cJVYRGpjm+rp7Gz0aOGZb6dGLx69Udhuz7btbbakpnrn9p6jLVUuOjVZeeE fuN+/6ZS2t0rYyNX2u33qvkieb7/4OM+JT5FvtVHXmx93vvq+FN5x65PueJcGmP+ZO0Lz63N6qXG 1XtWPLVFnX0X6wXx6rOAV59sWX0qDLWd12M3qbey4sWOtfqOGVz49zXoP7PWaWnx9Wpp8bJ4e7cS pceXf/wPrHXC44YPGpkycHjSv7vWudQq4c3agx1CRzgdLArx77X79UrHHzyabavUI+zg+If+zc93 9prpvnlGzLVaPSf8sLfLyXHs5aNRO6ccWF68Ji4pNq1B7J3NWx5lf3+sZMXbSktsP3Jr2PR4wPk+ xuqpm4bHDA8Nv3j5yZVdC8cfyLg6rqvSavZvu/PNfWoO6XTs/O7UiKafb65n3Nin/1CX6LKM9DYl xcZ63XxHp5g+3htxLqeVx6hD9vdq+pZLTy1dEJ8w5toD/+lf54+w/6RRD6eoyGb5p8Z3b+wWMaTj lCtNJ1Touf7VJuep8SX1vnF4eaTC2Wz751mpI1vu/2pM4dFI9QFbl9N8y8vZ/Se0n9A3e3bCuloe IUcT8wKvDb0zrv60YbLeZBncuUfq/lnFMf/vWO1UUMvpO4vKBrGEIe8VysQ73dt9/b33yi4507fn 3VvVun3g/hOWatYTHBWjVtOG9CKj+C4kkLT/25XQPyyj/qRAze5W0Wtves9tFactGmgy2OcmdZz6 aGT4jnblWJOyrR/0ynZ56Dtjy+I+tldyN7eufvLNqm8Pbfnug9rVE81xY4fRQrfgh/Ebh6e7bQ3+ ecKzqeV3mia33HN/7N2kjzsunHnqaNHlabuv72p0LP3BoTXNiid+fyT6x5YnnWrvSr3Sev6G6iPz a086t3FjpfDc53l7B4XOd6+fFzm5fOsDDoPSQrYdXz3er8e6qL5XLHfv+ta48cXTC76Zrxxq58Zk RKvGOU/nK4FNPwue9EOZcn7Qq9ArF2jKrA0sQTu64JL7wPSQJ1XzKtb2UVwm/r+tYTs6zWjHU4dj wbZ7V3bee5Fm3vtFadqcMxvKQwKtrhW5bFL+BiygVgELqEmw5hHrIgNw84hj4JpHGAUBqIyyMDA3 MgUWTYaGpqAyyhjCNQRxDRo306N5pG6gCuHK5TlnFmSkFim4BLsquAb7WVmYuhjrGhuYOuuaOjm7 GaoaKEP8JIPqJ91gkKcUglOLyjKTUwkWbx9YdDdNOyDVmK66US1ps7D3OYNdB4Qs/jSmmrAfMduk kvGNneUA+/Qv2z9WyyXpuN30XhJosv1yztso6y3NC91tBTn0TLNdnx2y6WFKY1opkfna6626zjub 8uglVwpmeoe3CFxYr/ujU/bZK80tz8/PY0taXhRyyPrYefsdDzdECOQ8XXr98KFS871fWh82vtC4 If3x07qPTYuvXWdeNF+05bftr9UPtxmdWMCU8vnZfym1Qo7gLlGmT83qZZ5NhcvfrzWqOHY9R8xf KXV6kq+b/n/l9a1vlhXsZT5964YR61HtCQ7b5l3VacvZflrYqLb3WN06cX2jP2m7ZTe4hv5Y+0s3 vTldc3LLpaiFysjNKUSB8GL6t+/vez4+y3wcmeH3fUZX1d3ZeigtJawlBiUtpZLiguREqrSUYCaV YC+sUdp/bAewlVa89uXxE232LTVdcpuVtUU+7NP7mcuOc/Tqbz5rX3i1raZc/u5r8U17ax7/nPmJ y9VjrcjuTJ1PdulJIZ/e1asLTrJ8c+5mu1/H9wR35Wp1UQeO+ft5DVmabphu45nDcLl7VUXi0a0d jnPtzO5ELFGfbXVrL1usyLJN/D4H+2y6PyXN/JH29upnGY0NRrdPGXLu+a2U4ebz63Kx0nPNPiWG 32H72dY1LhDdZfJTo0/eK4l1YefXRveXvBM5rkdY98tlc2auPOBRE9pkH89g4TyH7Yz9Df39/sWc tn93xX05/sb8UEriAt8rtgVnojcINx68sthQam/KtWmXquy1ot2COW3OMv+0j2Q40xmcaNjEMhtY Yk1nYmQ0aGwfwC4bSkcSMdS1oPEYqHaCRhsnsyEP8jga0F4Ej9uQzwBZVhRYasA1shgCk/qJy9ud H5pu6zp/7MOOrg9HFj6o3+hlkIakhccwwiBsgU6DFoMvQyZDMkMRQz54KC6NoYRBAVgd5gNFCsBk IlAkE8jKW6jWoIIzpZZUFuSnFyUWZFQqoJVMLE2MDL2+Kb/6Hc+3ClSXPTvNO22B5+/njlP3G3C/ +hTjOvNVtHt3XuWHixNErzTt4DObZpl+sJ33l4vD8pw5awtkUiMn3r20seb5nJ0maxh/HVzr89FS 6N+CnbduSEwKUtTSik/MT814m5w5/WP4Xsavl28qv9jTdPXID+3//zKCb/XZfjtmuq3z2pzlqw99 UBSpvce198i6wy9q13gWLJi87KWh9C7RJcfDZrRd8brWO6WhN0eBJ/Um1/4aaa7KWuegWcoRl/Ol MxfcZy4ItGb8eWi51s8pPrfX8Sn1Jf0O63olUml04LfShNofkzjiReZdZlVZFaPhd2Ld2jQO/Yup U1en7ew+vvHyrYzqrxu6ukMXNjHJGzQxSSNiic2wiYkHKMRB9+SIXkWiVNzs0OS4INZAAjktciMG fhmBdsJlWA35weMPxkaGhuZGZgbGURhJUTRr4kndpRNqXn8orTgsti/3zOnnP9HKJ1ASOSOYfUJY fV+ho1mEXNz6E+mX5/DvYXVnTnz+Y0HAXkbfP3qGvNyMpjMfXip9HfEiYvOcppDVZVEWkwL3vL96 rmDx7dnlhbcePq3Y/HtmycIeufhNE2+9XMq2z7XYcY9pmZOJjbSg5cvw5x9U99gxzuZjmqSsbHb0 ovL7pX5HQvuf1dh4fl7Q9fXiAlHms7M+9Tho6d4Mvd59YEIpR+6ZoxuUlzwqE//49Dz7shLdnJpo hotTjx8Ke/t0abpu+/JLQsE6fX9sI8qTg21ltmuK1v0WLrvG+nTNh3iraw/NJyhcPMF0ue3BVqPm 5BMv/93XcBBt/sL3OHZ3zEKPMyevrbYwtC6wCHM2WnNxic4vawYGAOPxgOkNCmVuZHN0cmVhbQ0K ZW5kb2JqDQoxMDcgMCBvYmoNClsgMFsgNzUwXSAgMTM1WyAzNTBdICAxNzdbIDU1Nl0gXSANCmVu ZG9iag0KMTA4IDAgb2JqDQo8PC9UeXBlL1hSZWYvU2l6ZSAxMDgvV1sgMSA0IDJdIC9Sb290IDEg MCBSL0luZm8gMjMgMCBSL0lEWzxDM0NFM0JEM0U3Qzk4NTREQjYxRTMzMUExRkIwN0UzNT48QzND RTNCRDNFN0M5ODU0REI2MUUzMzFBMUZCMDdFMzU+XSAvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAyNjg+Pg0Kc3RyZWFtDQp4nDXSyTJDQRTG8e6bhMwkIYK4CDHP8xQxD/Eidp5ApaI8gnewtLRh w0pRZWdtY21lHX2/P2fRv+pTfU6dqj7GuGg2rTszxgRcwouwd8L7EKG6CF+IyLmIvotYDUjGDZBM VOAJPkWyAa8i9SDS9yL7JnKPIv/lJnANfXMIR3AMLfD35MQVFLz/mwcWQhCBMHRDK5xCDKKQhw5I QBxykIIktEEaspCBduiEAnTBLPRADYrQC1MwCT70wRAMQD+UYBDKMAwTMAojMA5jMAPTcABzcAYL MA+7UIUlWIR1WIFlWINV2IQN2IYKbMEO7MOe+/DijxbFvwmwdW2kbTyLq29xXQ7wSrfG/AKdQSvt DQplbmRzdHJlYW0NCmVuZG9iag0KeHJlZg0KMCAxMDkNCjAwMDAwMDAwMjQgNjU1MzUgZg0KMDAw MDAwMDAxNyAwMDAwMCBuDQowMDAwMDAwMTI1IDAwMDAwIG4NCjAwMDAwMDAyMDEgMDAwMDAgbg0K MDAwMDAwMDQzMSAwMDAwMCBuDQowMDAwMDAwNzI2IDAwMDAwIG4NCjAwMDAwMDA4OTUgMDAwMDAg bg0KMDAwMDAwMTEzNSAwMDAwMCBuDQowMDAwMDAxMzg0IDAwMDAwIG4NCjAwMDAwMDIyNTUgMDAw MDAgbg0KMDAwMDAwMjM3OCAwMDAwMCBuDQowMDAwMDAyNDA4IDAwMDAwIG4NCjAwMDAwMDI1NjAg MDAwMDAgbg0KMDAwMDAwMjYzNCAwMDAwMCBuDQowMDAwMDAyODc3IDAwMDAwIG4NCjAwMDAwMDMw MTAgMDAwMDAgbg0KMDAwMDAwMzA0MCAwMDAwMCBuDQowMDAwMDAzMjAxIDAwMDAwIG4NCjAwMDAw MDMyNzUgMDAwMDAgbg0KMDAwMDAwMzUxNiAwMDAwMCBuDQowMDAwMDAzNzY3IDAwMDAwIG4NCjAw MDAwMDQ4MTIgMDAwMDAgbg0KMDAwMDAwNTA1MyAwMDAwMCBuDQowMDAwMDA1ODYxIDAwMDAwIG4N CjAwMDAwMDAwMjUgNjU1MzUgZg0KMDAwMDAwMDAyNiA2NTUzNSBmDQowMDAwMDAwMDI3IDY1NTM1 IGYNCjAwMDAwMDAwMjggNjU1MzUgZg0KMDAwMDAwMDAyOSA2NTUzNSBmDQowMDAwMDAwMDMwIDY1 NTM1IGYNCjAwMDAwMDAwMzEgNjU1MzUgZg0KMDAwMDAwMDAzMiA2NTUzNSBmDQowMDAwMDAwMDMz IDY1NTM1IGYNCjAwMDAwMDAwMzQgNjU1MzUgZg0KMDAwMDAwMDAzNSA2NTUzNSBmDQowMDAwMDAw MDM2IDY1NTM1IGYNCjAwMDAwMDAwMzcgNjU1MzUgZg0KMDAwMDAwMDAzOCA2NTUzNSBmDQowMDAw MDAwMDM5IDY1NTM1IGYNCjAwMDAwMDAwNDAgNjU1MzUgZg0KMDAwMDAwMDA0MSA2NTUzNSBmDQow MDAwMDAwMDQyIDY1NTM1IGYNCjAwMDAwMDAwNDMgNjU1MzUgZg0KMDAwMDAwMDA0NCA2NTUzNSBm DQowMDAwMDAwMDQ1IDY1NTM1IGYNCjAwMDAwMDAwNDYgNjU1MzUgZg0KMDAwMDAwMDA0NyA2NTUz NSBmDQowMDAwMDAwMDQ4IDY1NTM1IGYNCjAwMDAwMDAwNDkgNjU1MzUgZg0KMDAwMDAwMDA1MCA2 NTUzNSBmDQowMDAwMDAwMDUxIDY1NTM1IGYNCjAwMDAwMDAwNTIgNjU1MzUgZg0KMDAwMDAwMDA1 MyA2NTUzNSBmDQowMDAwMDAwMDU0IDY1NTM1IGYNCjAwMDAwMDAwNTUgNjU1MzUgZg0KMDAwMDAw MDA1NiA2NTUzNSBmDQowMDAwMDAwMDU3IDY1NTM1IGYNCjAwMDAwMDAwNTggNjU1MzUgZg0KMDAw MDAwMDA1OSA2NTUzNSBmDQowMDAwMDAwMDYwIDY1NTM1IGYNCjAwMDAwMDAwNjEgNjU1MzUgZg0K MDAwMDAwMDA2MiA2NTUzNSBmDQowMDAwMDAwMDYzIDY1NTM1IGYNCjAwMDAwMDAwNjQgNjU1MzUg Zg0KMDAwMDAwMDA2NSA2NTUzNSBmDQowMDAwMDAwMDY2IDY1NTM1IGYNCjAwMDAwMDAwNjcgNjU1 MzUgZg0KMDAwMDAwMDA2OCA2NTUzNSBmDQowMDAwMDAwMDY5IDY1NTM1IGYNCjAwMDAwMDAwNzAg NjU1MzUgZg0KMDAwMDAwMDA3MSA2NTUzNSBmDQowMDAwMDAwMDcyIDY1NTM1IGYNCjAwMDAwMDAw NzMgNjU1MzUgZg0KMDAwMDAwMDA3NCA2NTUzNSBmDQowMDAwMDAwMDc1IDY1NTM1IGYNCjAwMDAw MDAwNzYgNjU1MzUgZg0KMDAwMDAwMDA3NyA2NTUzNSBmDQowMDAwMDAwMDc4IDY1NTM1IGYNCjAw MDAwMDAwNzkgNjU1MzUgZg0KMDAwMDAwMDA4MCA2NTUzNSBmDQowMDAwMDAwMDgxIDY1NTM1IGYN CjAwMDAwMDAwODIgNjU1MzUgZg0KMDAwMDAwMDA4MyA2NTUzNSBmDQowMDAwMDAwMDg0IDY1NTM1 IGYNCjAwMDAwMDAwODUgNjU1MzUgZg0KMDAwMDAwMDA4NiA2NTUzNSBmDQowMDAwMDAwMDg3IDY1 NTM1IGYNCjAwMDAwMDAwODggNjU1MzUgZg0KMDAwMDAwMDA4OSA2NTUzNSBmDQowMDAwMDAwMDkw IDY1NTM1IGYNCjAwMDAwMDAwOTEgNjU1MzUgZg0KMDAwMDAwMDA5MiA2NTUzNSBmDQowMDAwMDAw MDkzIDY1NTM1IGYNCjAwMDAwMDAwOTQgNjU1MzUgZg0KMDAwMDAwMDA5NSA2NTUzNSBmDQowMDAw MDAwMDk2IDY1NTM1IGYNCjAwMDAwMDAwOTcgNjU1MzUgZg0KMDAwMDAwMDA5OCA2NTUzNSBmDQow MDAwMDAwMDk5IDY1NTM1IGYNCjAwMDAwMDAxMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDA3NDEzIDAwMDAwIG4NCjAwMDAwMDc4MjggMDAwMDAgbg0KMDAwMDA5ODI1NSAwMDAw MCBuDQowMDAwMDk4NzU1IDAwMDAwIG4NCjAwMDAwOTkwNTUgMDAwMDAgbg0KMDAwMDA5OTM2NSAw MDAwMCBuDQowMDAwMTM5OTQzIDAwMDAwIG4NCjAwMDAxMzk5OTggMDAwMDAgbg0KdHJhaWxlcg0K PDwvU2l6ZSAxMDkvUm9vdCAxIDAgUi9JbmZvIDIzIDAgUi9JRFs8QzNDRTNCRDNFN0M5ODU0REI2 MUUzMzFBMUZCMDdFMzU+PEMzQ0UzQkQzRTdDOTg1NERCNjFFMzMxQTFGQjA3RTM1Pl0gPj4NCnN0 YXJ0eHJlZg0KMTQwNDY5DQolJUVPRg0KeHJlZg0KMCAwDQp0cmFpbGVyDQo8PC9TaXplIDEwOS9S b290IDEgMCBSL0luZm8gMjMgMCBSL0lEWzxDM0NFM0JEM0U3Qzk4NTREQjYxRTMzMUExRkIwN0Uz NT48QzNDRTNCRDNFN0M5ODU0REI2MUUzMzFBMUZCMDdFMzU+XSAvUHJldiAxNDA0NjkvWFJlZlN0 bSAxMzk5OTg+Pg0Kc3RhcnR4cmVmDQoxNDI4MDkNCiUlRU9G --_002_9B57C850BB53634CACEC56EF4853FF653B1A3F4DTK5EX14MBXW601w_-- From bingxuere@gmail.com Thu Jul 28 19:56:50 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88FD621F886A for ; Thu, 28 Jul 2011 19:56:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nMSPKz1HxHH for ; Thu, 28 Jul 2011 19:56:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8444F21F885C for ; Thu, 28 Jul 2011 19:56:49 -0700 (PDT) Received: by iye7 with SMTP id 7so4252341iye.31 for ; Thu, 28 Jul 2011 19:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cx+NF9GrlF5yHe/Dcxso+k4WXJP8ugBYeu2vasx9PlM=; b=sK9N2GC8ZkXo3mb41NloC5wpmSkbGKK6Rj3dmJlhxQvYzpAqrcEWKn5mYYXqxGDrCn I3zhSt2FoxxVDtdZ29MjG8AgcpQc6aMRxCMvi1kzoEjNIYB7ichIQI0VcZUkVbUXTuQV cIop9/GgnX7/ULv1tIKIEJYypuHnLt2xLO0Jk= Received: by 10.231.34.4 with SMTP id j4mr494174ibd.156.1311908209088; Thu, 28 Jul 2011 19:56:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Thu, 28 Jul 2011 19:56:29 -0700 (PDT) In-Reply-To: <201107290210325157354@csnet1.cs.tsinghua.edu.cn> References: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> <201107290210325157354@csnet1.cs.tsinghua.edu.cn> From: Qiong Date: Fri, 29 Jul 2011 10:56:29 +0800 Message-ID: To: Peng Wu Content-Type: multipart/alternative; boundary=0022154012fac7d94804a92c6ec5 Cc: softwires Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 02:56:50 -0000 --0022154012fac7d94804a92c6ec5 Content-Type: text/plain; charset=UTF-8 Hi Peng, Satoru, Thanks for your comments and suggestions. Actually, I think there are two kinds of routing issues around here, and we should take appropriate planning for our stateless 4v6 routing system. The first one is what Peng has mentioned above, that de-aggregated IPv4 IGP addresses blocks together with embedded non-continuous port set would have impact on IPv6 routing system. This situation has no relationship with shared-mode or exclusive-mode, and I personally think we can reduce this impact with careful IPv4 address planning. Here are two possible ways: -- Guarantee that one shared-IPv4 address would only be allocated within the same BNG (say, BRAS, etc). Thus, non-continous port info will no longer be needed to shown up in IPv6 IGP and all the packets with the same shared-IPv4 address will be destined to the same BNG. -- Select the same IPv6 stateless prefix with native IPv6 prefix in a certain area. For example, if 2001:c68:1122::/48 is the prefix for one MAN, we can also use it for stateless IPv6 prefix , followed by shared IPv4 address/port set. In this way, de-aggregated IPv6 routings can be further aggregated in the upper level (say, backbone network). However, in this way, this IPv6 prefix is relatively long and it would be difficult to ensure the whole stateless IPv6 prefix (including IPv4 address/port set) to be less than /64 (easier for SLLAC). The second one is to deal with the co-existence scenario for shared-mode and exclusive-mode (or other differentiated situation). As suggested by Satoru and Remi, it can either be accomplished by IPv4 routing in stateless GW, or by mapping rule specification. Anyway, it still have to do some kind of lookup, no matter whether it is a routing table or other kinds of database. But I also agree that the performance would not be a big problem to handle these additional prefix-based rules. Best wishes Qiong Sun 2011/7/29 Peng Wu > Hi Satoru, > > >> However, if we introduce multiple domains with multiple IPv4 prefix > pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry > number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, > Nm would not be a small number anymore. So maybe some more optimization work > will still be needed to make it more "stateless" ? > > > >What do you mean 'the entry number of IPv4 routing table'? > >Do you presume that your IGP routing has almost 300K routes as same number > of current internet full routes? > > If I get Qiong correctly, she means that, suppose the IPv4 IGP addresses > blocks are quite de-aggregated already. If the ISP upgrade the network to > IPv6, and support IPv4 using stateless 4v6 with the same IPv4 address > distribution, then the IPv4 IGP kind of introduce the IPv4 IGP routing table > into IPv6. > > If this situation does exists, then it's an interesting operation problem. > > --0022154012fac7d94804a92c6ec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Peng,=C2=A0Satoru,

Thanks for your comments and sugge= stions. Actually, I think there are two kinds of routing issues around here= , and we should take appropriate planning for our stateless 4v6 routing sys= tem.

The first one is what Peng has mentioned above, that=C2= =A0de-aggregated=C2=A0<= span class=3D"Apple-style-span" style=3D"border-collapse: collapse; font-fa= mily: arial, sans-serif; font-size: 13px; ">IPv4 IGP addresses blocks toget= her =C2=A0 with embedded non-continuous port set would have impact on IPv6 = routing system. This situation has no relationship with shared-mode or excl= usive-mode, and I personally think we can reduce this impact with careful I= Pv4 address planning.=C2=A0

Here are two possible ways:
-- Guarantee that one sha= red-IPv4 address would only be allocated within the same BNG (say, BRAS, et= c). Thus, non-continous port info will no longer be needed to shown up in I= Pv6 IGP and all the packets with the same shared-IPv4 address will be desti= ned to the same BNG.
-- Select the same IPv6 s= tateless prefix with native IPv6 prefix in a certain area. For example, if = 2001:c68:1122::/48 is the prefix for one MAN, we can also use it for statel= ess IPv6 prefix , followed by shared IPv4 address/port set. In this way, de-aggregated=C2=A0IPv6 routings can be further = aggregated in the upper= level (say, backbone network). However, in this way, this IPv6 prefix is r= elatively long and it would be difficult to ensure the whole stateless IPv6= prefix (including IPv4 address/port set) to be less than /64 (easier for S= LLAC).

The second one is to de= al with the co-existence scenario for shared-mode and exclusive-mode (or ot= her differentiated situation). As suggested by=C2=A0Satoru an= d Remi, it can either be accomplished by IPv4 routing in stateless GW, or b= y mapping rule specification. Anyway, it still have to do some kind of =C2= =A0lookup, no matter whether it is a routing table or other kinds of databa= se. But I also agree that the performance would not be a big problem to han= dle these additional prefix-based rules.

Best wishes

Qiong Sun =C2=A0
=C2=A0=C2=A0

=C2=A0=C2=A0=

2011/7/29 Peng Wu <weapon@csnet1.cs= .tsinghua.edu.cn>
Hi Satoru,

>> However, if we introduce multiple domains with multiple IPv4 prefi= x pools ( the number of each domain is N1, N2, N3,... Nm) , then the entry = number of IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, = Nm would not be a small number anymore. So maybe some more optimization wor= k will still be needed to make it more "stateless" ?
>
>What do you mean 'the entry number of IPv4 routing table'= ?
>Do you presume that your IGP routing has almost 300K = routes as same number of current internet full routes?

If I get Qiong correctly, she means that, suppose the IPv4 IGP addres= ses blocks are quite de-aggregated already. If the ISP upgrade the network = to IPv6, and support IPv4 using stateless 4v6 with the same IPv4 address di= stribution, then the IPv4 IGP kind of introduce the IPv4 IGP routing table = into IPv6.

If this situation does exists, then it's an interesting operation probl= em.


--0022154012fac7d94804a92c6ec5-- From bingxuere@gmail.com Thu Jul 28 20:26:18 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A61621F8876 for ; Thu, 28 Jul 2011 20:26:18 -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.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUjmQNwHrIP2 for ; Thu, 28 Jul 2011 20:26:17 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CADB21F885C for ; Thu, 28 Jul 2011 20:26:17 -0700 (PDT) Received: by iye7 with SMTP id 7so4280008iye.31 for ; Thu, 28 Jul 2011 20:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BAgeUZSbmid0hfbl7cSX/lAZ/FTB2PV5gZ/HIec/fMY=; b=tzv/lN7UNwFBW8kK12ktaEjfMxbTaHGKSGkBBNc1T3zwugkEKPLXn8a9xCOTT+Gl5l cDcxBWiYjuy70PowyxsJd1G8u5wDZrQ3h8q4YLIXSjWkAnfP5rN56Ds9H69DfNU1KCLu hMeWisU+V8Vml6jvjBXEIs0AeyyWWQ9mbcuas= Received: by 10.231.6.157 with SMTP id 29mr502115ibz.131.1311909977135; Thu, 28 Jul 2011 20:26:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Thu, 28 Jul 2011 20:25:57 -0700 (PDT) In-Reply-To: References: <6DB746CD-CC26-4606-9175-36D4E320C3F2@gmail.com> From: Qiong Date: Fri, 29 Jul 2011 11:25:57 +0800 Message-ID: To: Tina TSOU Content-Type: multipart/alternative; boundary=00151773df422a1c8704a92cd8c7 Cc: "softwires@ietf.org" Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 03:26:18 -0000 --00151773df422a1c8704a92cd8c7 Content-Type: text/plain; charset=UTF-8 Hi, Tina, Agree. >From the perspective of routing issues discussed these days, I think stateful ones would store customer (lightweight AFTR) /session (DS-Lite/NAT44/NAT64) information, while stateless ones would just store *location-based information* just as traditional routing system. Actually, since stateless ones have combined some kind of user info into these locators (e.g. shared-IPv4 address, port multiplex ratio, etc), it would have some impact on routing system. That's why these configurations in stateless solutions would be a little more complicated than stateful ones. Maybe this is also a tradeoff between different solutions. Best regards Qiong Sun On Thu, Jul 28, 2011 at 7:10 PM, Tina TSOU wrote: > Matsushima-san, > In this draft, we may need to refer or define the definition of > - Stateful operation > - Stateless operation > - Dynamic port allocation > - Static port allocation > > Hope in this way, the discussion could be easier. > > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Satoru Matsushima > Sent: Thursday, July 28, 2011 5:56 AM > To: Qiong > Cc: softwires@ietf.org > Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain > > Hi Qiong, > > On 2011/07/28, at 4:31, Qiong wrote: > > > Hi, Satoru, > > > > Thanks a lot for your suggestion and I understand it can work. But in my > understanding, it still lies some differences with the so-called "totally > stateless solution". > > I don't mean that 'totally stateless solution' isn't a part of routing > system. > > > Suppose there is only one domain, when an IPv4 downstream packet arrives > at stateless gateway, it would firstly forward to the virtual tunnel > interface (take 4V6 Mapped Tunnel for example) with only one default route. > Then after encapsulated with a uniform IPv6 prefix and IPv4 prefix, etc, it > will lookup IPv6 routing table and forward to 4v6 CE. Here, actually there > is no need to do routing lookup for IPv4 address expect one default route. > > You already did routing when you found default route. > > > > However, if we introduce multiple domains with multiple IPv4 prefix pools > ( the number of each domain is N1, N2, N3,... Nm) , then the entry number of > IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, Nm would > not be a small number anymore. So maybe some more optimization work will > still be needed to make it more "stateless" ? > > What do you mean 'the entry number of IPv4 routing table'? > Do you presume that your IGP routing has almost 300K routes as same number > of current internet full routes? > > Best regards, > --satoru > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00151773df422a1c8704a92cd8c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Tina,

Agree.

From the persp= ective of routing issues discussed these days, I think stateful ones would = store customer (lightweight AFTR) /session (DS-Lite/NAT44/NAT64) informatio= n, while stateless ones would just store *location-based information* just = as traditional routing system.

Actually, since stateless ones have combined some kind = of user info into these locators (e.g. shared-IPv4 address, port multiplex = ratio, etc), it would have some impact on routing system. That's why th= ese configurations in stateless solutions would be a little more complicate= d than stateful ones. Maybe this is also a tradeoff between different solut= ions.

Best regards

Qiong Sun


On Thu, Jul 28, 2011 at 7:= 10 PM, Tina TSOU <Tina.Tsou.Zouting@huawei.com> wrote:
Matsushima-san,
In this draft, we may need to refer or define the definition of
- Stateful operation
- Stateless operation
- Dynamic port allocation
- Static port allocation

Hope in this way, the discussion could be easier.


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

-----Original Message-----
From: softwires-bounces@ietf.= org [mailto:softwires-bou= nces@ietf.org] On Behalf Of Satoru Matsushima
Sent: Thursday, July 28, 2011 5:56 AM
To: Qiong
Cc: softwires@ietf.org
Subject: Re: [Softwires] [softwire]comments on stateless 4v6 domain

Hi Qiong,

On 2011/07/28, at 4:31, Qiong wrote:

> Hi, Satoru,
>
> Thanks a lot for your suggestion and I understand it can work. But in = my understanding, it still lies some differences with the so-called "t= otally stateless solution".

I don't mean that 'totally stateless solution' isn't a part= of routing system.

> Suppose there is only one domain, when an IPv4 downstream packet arriv= es at stateless gateway, it would firstly forward to the virtual tunnel int= erface (take 4V6 Mapped Tunnel for example) with only one default route. Th= en after encapsulated with a uniform IPv6 prefix and IPv4 prefix, etc, it w= ill lookup IPv6 routing table and forward to 4v6 CE. Here, actually there i= s no need to do routing lookup for IPv4 address expect one default route.
You already did routing when you found default route.


> However, if we introduce multiple domains with multiple IPv4 prefix po= ols ( the number of each domain is N1, N2, N3,... Nm) , then the entry numb= er of IPv4 routing table will be N1+N2+N3+..+Nm. In current situation, Nm w= ould not be a small number anymore. So maybe some more optimization work wi= ll still be needed to make it more "stateless" ?

What do you mean 'the entry number of IPv4 routing table'?
Do you presume that your IGP routing has almost 300K routes as same number = of current internet full routes?

Best regards,
--satoru

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

--00151773df422a1c8704a92cd8c7-- From bingxuere@gmail.com Thu Jul 28 21:24:52 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBC021F877F for ; Thu, 28 Jul 2011 21:24:52 -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.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZfPrxJAGweG for ; Thu, 28 Jul 2011 21:24:50 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3A21F8770 for ; Thu, 28 Jul 2011 21:24:49 -0700 (PDT) Received: by iye7 with SMTP id 7so4336615iye.31 for ; Thu, 28 Jul 2011 21:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QbvKeKjqslBt9fw+pkT65hJF6OXzvq24OvWjg4eNAPY=; b=o1AsUBWbb68+AbCqw0e3CgkifAtV8vlwTFomJ1So9dCNj7jcboDk5foTBbai6aQ4kN djUpJFkUASfyVxi0STWFOgrQTqEO3basvjupMeogVoFrjuhnyoZornRst8DRyiWULYHd N/x6iONyYHEWkrDpoXpdWOQ4vW4fWKcPE9JC4= Received: by 10.42.155.74 with SMTP id t10mr511763icw.527.1311913489118; Thu, 28 Jul 2011 21:24:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Thu, 28 Jul 2011 21:24:29 -0700 (PDT) In-Reply-To: <99815557-036E-469D-AACB-473403B59393@laposte.net> References: <741D71AA-24D1-4EA7-9409-45175D603213@free.fr> <99815557-036E-469D-AACB-473403B59393@laposte.net> From: Qiong Date: Fri, 29 Jul 2011 12:24:29 +0800 Message-ID: To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Content-Type: multipart/alternative; boundary=90e6ba6e8dbc7eb68104a92da950 Cc: Softwires-wg Subject: Re: [Softwires] Support of multiple IPv4 prefixes in a network with 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 Jul 2011 04:24:52 -0000 --90e6ba6e8dbc7eb68104a92da950 Content-Type: text/plain; charset=UTF-8 Hi Remi, Thank you very much for your comments and your reference. It is exactly what I want. Please see my comments inline. 1. > A possible approach, to progressively reduce the number of used IPv4 > prefixes, consists in proposing two different tariffs: > - one for length L of IPv6 prefixes, and full IPv4 address per customer, > - the other, slightly lower, for length L+K of IPv6 prefixes, and shared > IPv4 address per customer. > > Thus the number of full-address customers can be expected to decrease, and > the longest IPv4 prefixes can be expected to progressively be reclaimed. > > [Qiong]: I'm not quite clear of the reason why "the longest IPv4 prefixes can be expected to progressively be reclaimed". The situation here is that these IPv4 prefixes (indicated as D1, D2, D3 in your draft) are disjoint prefixes with different lengths. Maybe we can firstly choose a shorter prefix (say D1 in your example). But after we have run out of this address pool, we have to choose another one from the remaining pools, and it is rather difficult to re-allocate existing IPv4 address pool unless this full IPv4 address customers do not exist anymore. Would you please explain it a bit more ? Thanks. > 2. > With a dihcotomic search for a prefix match in BR's and CE', the > performance impact of having a large number of rules can remain quite > limited, both in CE's and in BR's. > (Scalability of the BR function is in any case ensured by the fact that > BR's are, with respect to individual-customer states, completely stateless > (and also, of course, with respect to transport-connection states). > [Qiong]: Agree. The performance impact would not be a big problem for BR's. But we should still take our plan carefully with the region it covers. > > 3. > By configuring appropriately as many mapping rules as there are IPv4 > prefixes, all IPv4 prefixes can be used without any impact on IPv6 routing > (no "IPv4 entropy" exported to IPv6). > [Qiong]: As I have mentioned in another thread, indeed, special configuration should be applied to avoid potential non-continuous IPv4 prefix impacting on IPv6 routing. Best regards Qiong Sun > This is illustrated in sec 3.2 of > tools.ietf.org/html/draft-despres-softwire-sam-01 (not too easy to read, > sorry for that, but the subject had some intrinsic sophistication and was > new). > (Incidentally this 4rd founding draft wasn't included Ole's 4rd-history > slide yesterday, but is IMHO worth looking at for anyone interested in the > genesis of 4rd.) > > Hope it helps. > > Regards, > RD > > > > I agree that this mapping specification can be applied to all stateless > solutions, separated from specific solution. Thanks for your suggestion. > > > > Best wishes > > > > Qiong Sun > > > > > > > --90e6ba6e8dbc7eb68104a92da950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Remi,

Thank you very much for your comments=C2=A0and = your reference. It is exactly what I want. Please see my comments inline.= =C2=A0


1.
A possible approach, to progressively reduce the number of used IPv4 prefix= es, consists in proposing two different tariffs:
- one for length L of IPv6 prefixes, and full IPv4 address per customer, - the other, slightly lower, for length L+K of IPv6 prefixes, and shared IP= v4 address per customer.

Thus the number of full-address customers can be expected to decrease, and = the longest IPv4 prefixes can be expected to progressively be reclaimed.
[Qiong]: I'm not quite clear of the reason why &q= uot;the longest IPv4 prefixes can be expected to progressively be reclaimed= ". The situation here is that these IPv4 prefixes (indicated as D1, D2= , D3 in your draft) are disjoint prefixes with different lengths. Maybe we = can firstly choose a shorter prefix (say D1 in your example). But after we = have run out of this address pool, we have to choose another one from the r= emaining pools, and it is rather difficult to re-allocate existing IPv4 add= ress pool unless this full IPv4 address customers do not exist anymore. Wou= ld you please explain it a bit more ? Thanks.
=C2=A0
2.
With a dihcotomic search for a prefix match in BR's and CE', the pe= rformance impact of having a large number of rules can remain quite limited= , both in CE's and in BR's.
(Scalability of the BR function is in any case ensured by the fact that BR&= #39;s are, with respect to individual-customer states, completely stateless= (and also, of course, with respect to transport-connection states).
[Qiong]: Agree. The performance impact would not be a big= problem for BR's. But we should still take our plan carefully with the= region it covers.=C2=A0
=C2=A0

3.
By configuring appropriately as many mapping rules as there are IPv4 prefix= es, all IPv4 prefixes can be used without any impact on IPv6 routing (no &q= uot;IPv4 entropy" exported to IPv6).
[Qiong]: As = I have mentioned in another thread, indeed, special configuration should be= applied to avoid potential non-continuous IPv4 prefix impacting on IPv6 ro= uting.

Best regards

Qiong Sun


This is illustrated in sec 3.2 of tools.ietf.org/html/draft-des= pres-softwire-sam-01 (not too easy to read, sorry for that, but the sub= ject had some intrinsic sophistication and was new).
(Incidentally this 4rd founding draft wasn't included Ole's 4rd-his= tory slide yesterday, but is IMHO worth looking at for anyone interested in= the genesis of 4rd.)

Hope it helps.

Regards,
RD


> I agree that this mapping specification can be applied to all stateles= s solutions, separated from specific solution. Thanks for your suggestion.<= br> >
> Best wishes
>
> Qiong Sun
>
>



--90e6ba6e8dbc7eb68104a92da950-- From bingxuere@gmail.com Thu Jul 28 22:19:52 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B850D21F8B8C for ; Thu, 28 Jul 2011 22:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYUaFXBRDHc8 for ; Thu, 28 Jul 2011 22:19: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 C582C21F8B8B for ; Thu, 28 Jul 2011 22:19:51 -0700 (PDT) Received: by yxp4 with SMTP id 4so2571078yxp.31 for ; Thu, 28 Jul 2011 22:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZxHWbxrfFhEffRX3ytNzfL28L9Ui7n6lR/mcTWyiL30=; b=ks57/jP56NXRgyvwQl9CnUGjwGGnALMx3Powz8muZ05AarnLjdjO9ucS5SPyu/m9zL Ss+zQRoLa6OszxA2F3H7oGKxwzIsb96XdK0Xxg77hufiWGAxhZq50Jhruf2m/wKA8sxX IlvAZVkXQUrrnz5fXCvCNpm9t2slF8GoBTM6A= Received: by 10.42.159.199 with SMTP id m7mr655844icx.326.1311916790144; Thu, 28 Jul 2011 22:19:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Thu, 28 Jul 2011 22:19:30 -0700 (PDT) In-Reply-To: <71F7C208-9C83-448A-A2B1-C323C1537A6A@laposte.net> References: <71F7C208-9C83-448A-A2B1-C323C1537A6A@laposte.net> From: Qiong Date: Fri, 29 Jul 2011 13:19:30 +0800 Message-ID: To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Content-Type: multipart/alternative; boundary=90e6ba6e8a0c40603304a92e6e27 Cc: Softwires-wg Subject: Re: [Softwires] The Framing discussion of yesterday X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 05:19:52 -0000 --90e6ba6e8a0c40603304a92e6e27 Content-Type: text/plain; charset=UTF-8 Hi, Remi, Dave, I'm not sure whether I get the point in Dave'd slide. Please correct me if anything is wrong. In my understanding, the major problem in this failure mode would happen on the downstream path, rather than the upstream one. A node which is attached to an IPv6 network can determine whether to use shared-address system or not. However, when the downstream IPv4 packet arrived at the network-side GW, it can not tell whether the packet should be translated into shared-mode or exclusive-mode. So it can not work unless network-side GW have know these IPv4 addresses in advance for either mode. Moreover, I think this issue would have distinct impact on stateless solutions and stateful ones. For stateful ones, the states in AFTR have already shown the binding information between IPv4 address/port set and IPv6 address explicitly. While for stateless ones, these address mapping rules are determined implicitly in algorithm. As a result, in order to reflect prefix mapping information (discussed in multiple prefix threads), some more rules would be needed to be introduced accordingly . Of course, the number of rules would be significantly less than the number of states . Best regards Qiong Sun > 2. > Unless I misinterpreted, you asked about the failure mode of a host that > isn't part of a shared IPv4 address system and is attached to such a system. > > Assuming that, in the context of the discussion, this implicitly referred > to a "static" shared-address system, I don't see which problem there would > be: > - If a node is attached to an IPv6 network and ignores the static > shared-address system of this network, it won't be able to receive/accept > parameters of this-system mapping rule(s). > - It will therefore ignore that it could have used an exclusive port set of > a global IPv4 address. > - It will do nothing with its assigned address-and-port-set. > > Is this OK, or did you have in mind something more complicated which you > could detail? > > > Kind regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --90e6ba6e8a0c40603304a92e6e27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Remi, Dave,

I'm not sure whether I get the point= in Dave'd slide. Please correct me if anything is wrong.
In my understanding, the major problem in this failure mode wou= ld happen on the downstream path, rather than the upstream one. =C2=A0A nod= e which is attached to an IPv6 network can determine whether to use shared-= address system or not. However, when the downstream IPv4 packet arrived at = the network-side GW, it can not tell whether the packet should be translate= d into shared-mode or exclusive-mode. So it can not work unless network-sid= e GW have know these IPv4 addresses in advance for either mode.=C2=A0

Moreover, I think this issue would have distinct impact= on stateless solutions and stateful ones. For stateful ones, the states in= AFTR have already shown the binding=C2=A0information=C2=A0between IPv4 add= ress/port set and IPv6 address explicitly. While for stateless ones, these = address mapping rules are determined implicitly in algorithm. As a result, = in order=C2=A0to reflect prefix mapping information (discussed in multiple = prefix threads),=C2=A0some more rules would be needed to be introduced acco= rdingly . Of course, the number of rules would be=C2=A0significantly=C2=A0l= ess than the number of states=C2=A0.

Best regards

Qiong Sun



2.
Unless I misinterpreted, you asked about the failure mode of a host that is= n't part of a shared IPv4 address system and is attached to such a syst= em.

Assuming that, in the context of the discussion, this implicitly referred t= o a "static" shared-address system, I don't see which problem= there would be:
- If a node is attached to an IPv6 network and ignores the static shared-ad= dress system of this network, it won't be able to receive/accept parame= ters of this-system mapping rule(s).
- It will therefore ignore that it could have used an exclusive port set of= a global IPv4 address.
- It will do nothing with its assigned address-and-port-set.

Is this OK, or did you have in mind something more complicated which you co= uld detail?


Kind regards,
RD
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--90e6ba6e8a0c40603304a92e6e27-- From despres.remi@laposte.net Fri Jul 29 00:42:49 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773AD21F8B20 for ; Fri, 29 Jul 2011 00:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68FXVkR9Qwbd for ; Fri, 29 Jul 2011 00:42:48 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE9721F8B15 for ; Fri, 29 Jul 2011 00:42:47 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id D5A22700009D; Fri, 29 Jul 2011 09:42:46 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2321.sfr.fr (SMTP Server) with ESMTP id 2B3F97000098; Fri, 29 Jul 2011 09:42:44 +0200 (CEST) X-SFR-UUID: 20110729074244177.2B3F97000098@msfrf2321.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7-758198914 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 29 Jul 2011 09:42:44 +0200 Message-Id: <0BD07F42-9845-472D-9221-AD0879B62DA4@laposte.net> References: <71F7C208-9C83-448A-A2B1-C323C1537A6A@laposte.net> To: Qiong X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] The Framing discussion of yesterday X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 07:42:49 -0000 --Apple-Mail-7-758198914 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 29 juil. 2011 =E0 07:19, Qiong a =E9crit : > Hi, Remi, Dave, >=20 > I'm not sure whether I get the point in Dave'd slide. Please correct = me if anything is wrong. >=20 > In my understanding, the major problem in this failure mode would = happen on the downstream path, rather than the upstream one. A node = which is attached to an IPv6 network can determine whether to use = shared-address system or not. However, when the downstream IPv4 packet = arrived at the network-side GW, it can not tell whether the packet = should be translated into shared-mode or exclusive-mode. So it can not = work unless network-side GW have know these IPv4 addresses in advance = for either mode.=20 In the downstream direction from the Internet, the stateless BR (no per = customer state) maps the destination transport-address to an IPv6 = destination address. Because this IPv6 destination address has an IID that no host recognizes = (as discussed recently on the mailing list), the packet will be = discarded. A Destination-Unreachable ICMPv6 message is then returned to = the BR anycast address. The BR statelessly converts it into an IPv4 ICMP = error message returned to the IPv4 source. If the path is direct from a CE of a 4V6 domain to another CE of the = same domain, the ICMPv6 error message is returned to the source CE. This = CE does the conversion to the right IPv4 ICMP message for the CE NAT44. Does this answer your concern?=20 > Moreover, I think this issue would have distinct impact on stateless = solutions and stateful ones. For stateful ones, the states in AFTR have = already shown the binding information between IPv4 address/port set and = IPv6 address explicitly. While for stateless ones, these address mapping = rules are determined implicitly in algorithm. As a result, in order to = reflect prefix mapping information (discussed in multiple prefix = threads), some more rules would be needed to be introduced accordingly . > Of course, the number of rules would be significantly less than the = number of states . Yes, that's the point. The difference is between BR/AFTR's that have states _per customer = prefix_ or just as many mapping rules as independent IPv4 prefixes.=20 In addition, if several BR/AFTR's instances have to share their load for = scalability, their per-customer states have to be identical. If = per-customer states are dynamically updated this becomes complex. Last but not least, if there is one mapping rule per independent IPv4 = prefix, direct CE-to-CE paths are possible (each CE knows all mapping = rules). If BR/AFTR's have per-customer states, CE's don't know them. = Direct CE-to-CE paths are impossible. Hope it helps. Kind regards, RD ... >=20 > If a node is attached to an IPv6 network and ignores the static = shared-address system of this network, it won't be able to = receive/accept parameters of this-system mapping rule(s). > - It will therefore ignore that it could have used an exclusive port = set of a global IPv4 address. > - It will do nothing with its assigned address-and-port-set. --Apple-Mail-7-758198914 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi, Remi, = Dave,

I'm not sure whether I get the point in Dave'd = slide. Please correct me if anything is = wrong.

In my understanding, the major problem = in this failure mode would happen on the downstream path, rather than = the upstream one.  A node which is attached to an IPv6 network can = determine whether to use shared-address system or not. However, when the = downstream IPv4 packet arrived at the network-side GW, it can not tell = whether the packet should be translated into shared-mode or = exclusive-mode. So it can not work unless network-side GW have know = these IPv4 addresses in advance for either = mode. 

In the downstream = direction from the Internet, the stateless BR (no per customer state) = maps the destination transport-address to an IPv6 destination = address.
Because this IPv6 destination address has an IID that = no host recognizes (as discussed recently on the mailing list), the = packet will be discarded. A Destination-Unreachable ICMPv6 message is = then returned to the BR anycast address. The BR statelessly converts it = into an IPv4 ICMP error message returned to the IPv4 = source.
If the path is direct from a CE of a 4V6 domain to = another CE of the same domain, the ICMPv6 error message is returned to = the source CE. This CE does the conversion to the right IPv4 ICMP = message for the  CE NAT44.
Does this answer your = concern? 

Moreover, I think this issue would have distinct impact on = stateless solutions and stateful ones. For stateful ones, the states in = AFTR have already shown the binding information between IPv4 = address/port set and IPv6 address explicitly. While for stateless ones, = these address mapping rules are determined implicitly in algorithm. As a = result, in order to reflect prefix mapping information (discussed = in multiple prefix threads), some more rules would be needed to be = introduced accordingly .

Of course, the number of rules would = be significantly less than the number of = states .

Yes, that's the = point.
The difference is between BR/AFTR's that have states = _per customer prefix_ or just as many mapping rules as independent IPv4 = prefixes. 

In addition, if several = BR/AFTR's instances have to share their load for scalability, their = per-customer states have to be identical. If per-customer states are = dynamically updated this becomes complex.

Last = but not least, if there is one mapping rule per independent IPv4 prefix, = direct CE-to-CE paths are possible (each CE knows all mapping rules). =  If BR/AFTR's have per-customer states, CE's don't know them. = Direct CE-to-CE paths are impossible.

Hope it = helps.

Kind = regards,
RD

...


If a node is attached to an IPv6 network = and ignores the static shared-address system of this network, it won't = be able to receive/accept parameters of this-system mapping rule(s).
- It will therefore ignore that it could have used an exclusive port set = of a global IPv4 address.
- It will do nothing with its assigned = address-and-port-set.

<= /body>= --Apple-Mail-7-758198914-- From despres.remi@laposte.net Fri Jul 29 02:41:49 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8265821F8B02 for ; Fri, 29 Jul 2011 02:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW0pVnihIia5 for ; Fri, 29 Jul 2011 02:41:49 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id BDEFC21F8747 for ; Fri, 29 Jul 2011 02:41:48 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2212.sfr.fr (SMTP Server) with ESMTP id 6BD21700008A; Fri, 29 Jul 2011 11:41:47 +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 B84E9700008C; Fri, 29 Jul 2011 11:41:46 +0200 (CEST) X-SFR-UUID: 20110729094146755.B84E9700008C@msfrf2212.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 29 Jul 2011 11:41:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: Softwires-wg X-Mailer: Apple Mail (2.1084) Cc: Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 09:41:49 -0000 Dear all, Dave rightly expresses in the Softwire meeting the need to = separate/clarify discussion about: - Stateless vs stateful =96 Static vs dynamic port sets The need to clarify is IMHO even larger than that. I therefore worked out a way to present the range of solutions to be = compared, with the following taken in consideration: - The stateless/stateful IPv4 across IPv6 comparison isn't limited to = IPv4 shared addresses (applies also to exclusive IPv4 customer = addresses). - If there is, in BR/AFBR's, no Customer state (i.e. no states referring = to individual IPv6 prefixes), there can't be per-transport-connection = state either. - CE-CE direct paths are possible only if IPv4/IPv6 mappings of = BR/AFBR's don't depend on Customer state. The proposed document structure is as follows, with pros and cons for = each section: a) Stateful per transport connection (and also stateful per customer = IPv6 prefix) e.g. DS-lite with CGN b) Stateful per customer IPv6 prefix (but Stateless per transport = connection)=20 e.g. draft-cui-softwire-host-4over6-06 c) Stateless per customer IPv6 prefix (and also stateless per transport = connection) - Hub-an-spoke =20 TBD - Direct CE-CE paths (mesh) . Encapsulation based=20 e.g. draft-murakami-softwire-4rd-00 alias . Translation based =20 e.g. draft-murakami-softwire-4v6-translation-00 Thoughts? Regards, RD Le 28 juil. 2011 =E0 21:45, Dave Thaler a =E9crit : > Attaching here since they don't seem to be posted yet. >=20 > -Dave >=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On >> Behalf Of Satoru Matsushima >> Sent: Thursday, July 28, 2011 1:29 PM >> To: softwires@ietf.org list >> Subject: [Softwires] Yesterday's slides >>=20 >> Hi, >>=20 >> Could someone tell me where is Dave Thaler's slides? >>=20 >> Best regards, >> --satoru >> _______________________________________________ >> 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 denghui02@gmail.com Fri Jul 29 04:19:16 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C32521F8B46 for ; Fri, 29 Jul 2011 04:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtixncWhm3sF for ; Fri, 29 Jul 2011 04:19:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC5A821F8B11 for ; Fri, 29 Jul 2011 04:19:14 -0700 (PDT) Received: by wwe5 with SMTP id 5so2284412wwe.13 for ; Fri, 29 Jul 2011 04:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nXktqkxm/W1WNuVyf1kLCIEv5+j+E1l7P/XsTBo6yNo=; b=qfNyHj0IEWwhXtcNFqrTex9LRjVDWb9ld1E4pks8P9aO83AiQYLlmkrluzHcn364OG rm+07n77PUnklHaVIXITPvGRQ8VZQNiqy6ci/Bzwezx1veKVtPSNgNH7vs5rEWL/zrHJ m/rBJ81Dn7uxAZRv9hNS2EHLBE/U5ypYbIqOo= MIME-Version: 1.0 Received: by 10.227.55.81 with SMTP id t17mr1582509wbg.100.1311938340059; Fri, 29 Jul 2011 04:19:00 -0700 (PDT) Received: by 10.216.73.17 with HTTP; Fri, 29 Jul 2011 04:18:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 07:18:59 -0400 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf300258f2b9fc4304a93372db Cc: softwires@ietf.org, wdec@cisco.com, Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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, 29 Jul 2011 11:19:16 -0000 --20cf300258f2b9fc4304a93372db Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron. Inline please, 2011/7/28 Cameron Byrne > On Thu, Jul 28, 2011 at 10:48 AM, Hui Deng wrote: > > Hi Cameron, > > > > You may need spend time to review it later, it's different from 6RD and > > DS-Lite, > > > > I just now read it in more detail. My first piece of feedback is that > it is too long :) I assume future revisions will be more tight. I > would also say that the translation part be put into a separate draft > that goes to BEHAVE. > > I believe the mapped mode has some similar challenges in mobile as > DS-lite. It is an IP in IP tunnel. It is really a non-starter in > 3GPP networks as the draft amply notes. I believe it is best to state > that clearly for the 3GPP case, and move on without elaboration. > > The translation mode looks like NAT464, and i like it NAT464 + DNS64 > since it solves a real problem, as noted here > http://www.ietf.org/mail-archive/web/behave/current/msg09480.html > > ==>I think your observation is correct. > Is the reference to RFC6053 right? > > "The operation of the 4V6 CE and > gateway are very similar, if not identical, to that of stateless > NAT64 as specified in RFC 6053." > > So is this right? > > CPE/UE (NAT46) --->ipv6 only network--> NAT64 (stateless port restricted) > > And the port-set is delivered via some encoding in the IPv6 address > assigned to the UE? This is clever. I remain concerned about being > able to engineer stateless port allocations that sufficiently meet > everyone's needs with a limited free public IPv4 pool vs. dynamic > allocation. I do not have much experience with stateless LSN, i am > not sure anyone has much experience at scale with port restricted > stateless? I believe there are ways of going beyond 65k ports per > IPv4 address in stateful, what about in stateless? I think this will > be a requirement as the IPv4 pool keeps getting stretched thin. > > ==>the scenario is right, for port assignment, 2000 ports assignment per user would be fine? the algorithm allow dynamic port assignment. > Right now, i feel like it would be easier for the IETF to just define > NAT464 in general and stateless translation 4V6 is a flavor of NAT464. > > I understand the allure of stateless. But, IMHO the address > multiplexing of stateful is very useful and many large SPs already run > this way, and that operational experience is very important. The IPv6 > transition space is becoming very crowded, i personally would like to > see more work to make IPv6 a true replacement for IPv4 instead of yet > another transition mechanism that meets some set for checkboxs. > > ==> stateless 464 is good in his own environment, it may not be able to compatible with NAT64 or others, stateful 464 has advantage which could work with others, will see. -Hui > This architecture is complicated. > > CB > --20cf300258f2b9fc4304a93372db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Cameron.
=A0
Inline please,

2011/7/28 Cameron Byrne <cb.list6@gmail.com>
On Thu, Jul 28, 2011 at 10:48 AM, Hui Deng <denghui02@gmail.com> wrote:
> Hi = Cameron,
>
> You may need spend time to review it later, it'= ;s different from 6RD and
> DS-Lite,
>

I just now read it in more detail. =A0My= first piece of feedback is that
it is too long :) =A0I assume future re= visions will be more tight. =A0I
would also say that the translation par= t be put into a separate draft
that goes to BEHAVE.

I believe the mapped mode has some similar chal= lenges in mobile as
DS-lite. =A0It is an IP in IP tunnel. =A0It is reall= y a non-starter in
3GPP networks as the draft amply notes. =A0I believe = it is best to state
that clearly for the 3GPP case, and move on without elaboration.

The= translation mode looks like NAT464, and i like it NAT464 + DNS64
since = it solves a real problem, as noted here
http://www.= ietf.org/mail-archive/web/behave/current/msg09480.html

=3D=3D>I think your observation is correct.
=A0
Is the reference to RFC6053 righ= t?

"The operation of the 4V6 CE and
=A0 gateway are very sim= ilar, if not identical, to that of stateless
=A0 NAT64 as specified in RFC 6053."

So is this right?

C= PE/UE (NAT46) --->ipv6 only network--> NAT64 (stateless port restrict= ed)

And the port-set is delivered via some encoding in the IPv6 addr= ess
assigned to the UE? =A0This is clever. =A0I remain concerned about beingable to engineer stateless port allocations that sufficiently meet
ever= yone's needs with a limited free public IPv4 pool vs. dynamic
alloca= tion. =A0I do not have much experience with stateless LSN, i am
not sure anyone has much experience at scale with port restricted
statel= ess? =A0I believe there are ways of going beyond 65k ports per
IPv4 addr= ess in stateful, what about in stateless? =A0I think this will
be a requ= irement as the IPv4 pool keeps getting stretched thin.

=3D=3D>the scenario is right,=A0 for port assignment,
2000 ports assignment per user would be fine? the algorithm allow dyna= mic
port assignment.
=A0
Right now, i feel like it would = be easier for the IETF to just define
NAT464 in general and stateless tr= anslation 4V6 is a flavor of NAT464.

I understand the allure of stateless. =A0But, IMHO the address
multi= plexing of stateful is very useful and many large SPs already run
this w= ay, and that operational experience is very important. =A0The IPv6
trans= ition space is becoming very crowded, i personally would like to
see more work to make IPv6 a true replacement for IPv4 instead of yet
an= other transition mechanism that meets some set for checkboxs.

=3D=3D> stateless 464 is good in his own environment, it may not be= able to compatible with NAT64 or others, stateful 464 has advantage which = could work with others, will see.
=A0
-Hui
=A0
This architecture is complicated= .

CB

--20cf300258f2b9fc4304a93372db-- From despres.remi@laposte.net Fri Jul 29 05:08:06 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFAB21F87FA for ; Fri, 29 Jul 2011 05:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq4QNhxjpSca for ; Fri, 29 Jul 2011 05:08:06 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E28421F8770 for ; Fri, 29 Jul 2011 05:08:06 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 5024F700008B; Fri, 29 Jul 2011 14:08:05 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id BF8147000086; Fri, 29 Jul 2011 14:08:04 +0200 (CEST) X-SFR-UUID: 20110729120804784.BF8147000086@msfrf2109.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: <4E2FFFDB.3000301@piuha.net> Date: Fri, 29 Jul 2011 14:08:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2FFFDB.3000301@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] review of draft-operators-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: Fri, 29 Jul 2011 12:08:06 -0000 Le 27 juil. 2011 =E0 14:08, Jari Arkko a =E9crit : > R=E9mi, >>> I want to eacho Satoru's comment that this draft wasn't intended to >>> compare stateless and stateful transition mechanisms. This draft = only >>> describes the motivations. >>> =20 >=20 > And I don't want a full blown comparison either, but if the argument = is that we need to do this because is better/cheaper/more efficient than = something else, I think we do need to explain the main differences to = that something else (positive and negative). Fair enough. Actually I sometimes confused what was in version -O2 and what was in = version -00, more detailed on several points. =20 Kind regards, RD From satoru.matsushima@gmail.com Fri Jul 29 06:48:40 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC88B21F8BF9 for ; Fri, 29 Jul 2011 06:48: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzRe2iJLY9kq for ; Fri, 29 Jul 2011 06:48:40 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25EF421F8BE8 for ; Fri, 29 Jul 2011 06:48:40 -0700 (PDT) Received: by qwc23 with SMTP id 23so2434889qwc.31 for ; Fri, 29 Jul 2011 06:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xj/pnUN/r+DflXQ17+uRoV+cUL9W8sEWmqUHn4+ayWs=; b=QRPHcnTkG86WpsdCFx1qv9wkSqw/1AoId+Z+Czpa9GyBL/QlGt68KGcxkNyRrAKhh5 0kSDt5X7TmQIIq5mL9biRihAwwDZNcpB6mSmPFil4GbKQl6pn16HQkSP46Y+ppKVVUlS GIdR5SywugHfCLeHkfbdjbdSrwVJhiVTXIDRI= Received: by 10.229.64.93 with SMTP id d29mr959156qci.259.1311947319433; Fri, 29 Jul 2011 06:48:39 -0700 (PDT) Received: from dhcp-53a8.meeting.ietf.org (dhcp-53a8.meeting.ietf.org [130.129.83.168]) by mx.google.com with ESMTPS id o4sm1376545qct.37.2011.07.29.06.48.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 06:48:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: Date: Fri, 29 Jul 2011 09:48:35 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1244.3) Cc: softwires@ietf.org, wdec@cisco.com, Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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, 29 Jul 2011 13:48:40 -0000 Cameron, On 2011/07/28, at 17:42, Cameron Byrne wrote: > The translation mode looks like NAT464, and i like it NAT464 + DNS64 > since it solves a real problem, as noted here > http://www.ietf.org/mail-archive/web/behave/current/msg09480.html > I don't understand why is DNS64 needed with NAT464. Could you elaborate it? > Is the reference to RFC6053 right? > > "The operation of the 4V6 CE and > gateway are very similar, if not identical, to that of stateless > NAT64 as specified in RFC 6053." > > So is this right? I think that it should be RFC6052. > Right now, i feel like it would be easier for the IETF to just define > NAT464 in general and stateless translation 4V6 is a flavor of NAT464. > > I understand the allure of stateless. But, IMHO the address > multiplexing of stateful is very useful and many large SPs already run > this way, and that operational experience is very important. The IPv6 > transition space is becoming very crowded, i personally would like to > see more work to make IPv6 a true replacement for IPv4 instead of yet > another transition mechanism that meets some set for checkboxs. Stateless is not exclusive with stateful one, and also NAT64. I agree with Hui. cheers, --satoru From xing@cernet.edu.cn Fri Jul 29 06:58:56 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E4C21F8C19 for ; Fri, 29 Jul 2011 06:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.752 X-Spam-Level: X-Spam-Status: No, score=-99.752 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tAeuxRhfnfP for ; Fri, 29 Jul 2011 06:58:55 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 10A1021F8C18 for ; Fri, 29 Jul 2011 06:58:54 -0700 (PDT) Received: from [127.0.0.1]([130.129.16.217]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm184e32fa43; Fri, 29 Jul 2011 21:58:51 +0800 Message-ID: <4E32BC95.8010708@cernet.edu.cn> Date: Fri, 29 Jul 2011 21:58:45 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Hui Deng References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020704030001080603030901" X-AIMC-AUTH: xing X-AIMC-MAILFROM: xing@cernet.edu.cn X-AIMC-Msg-ID: cV5anm0B Cc: softwires@ietf.org, wdec@cisco.com, Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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, 29 Jul 2011 13:58:56 -0000 This is a multi-part message in MIME format. --------------020704030001080603030901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit ? 2011/7/29 19:18, Hui Deng ??: > Hi Cameron. > > Right now, i feel like it would be easier for the IETF to just define > NAT464 in general and stateless translation 4V6 is a flavor of NAT464. > > I understand the allure of stateless. But, IMHO the address > multiplexing of stateful is very useful and many large SPs already run > this way, and that operational experience is very important. The IPv6 > transition space is becoming very crowded, i personally would like to > see more work to make IPv6 a true replacement for IPv4 instead of yet > another transition mechanism that meets some set for checkboxs. > > ==> stateless 464 is good in his own environment, it may not be able > to compatible with NAT64 or others, stateful 464 has advantage which > could work with others, will see. FYI, the dIVI (https://datatracker.ietf.org/doc/draft-xli-behave-divi/https://datatracker.ietf.org/doc/draft-xli-behave-divi/) and dIVI-PD (https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd/) models are fully compatiple with stateless NAT64, i.e. RFC6052 and RFC6145. Regards, xing > -Hui > > This architecture is complicated. > > CB > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --------------020704030001080603030901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 于 2011/7/29 19:18, Hui Deng 写道:
Hi Cameron.

Right now, i feel like it would be easier for the IETF to just define
NAT464 in general and stateless translation 4V6 is a flavor of NAT464.

I understand the allure of stateless.  But, IMHO the address
multiplexing of stateful is very useful and many large SPs already run
this way, and that operational experience is very important.  The IPv6
transition space is becoming very crowded, i personally would like to
see more work to make IPv6 a true replacement for IPv4 instead of yet
another transition mechanism that meets some set for checkboxs.

==> stateless 464 is good in his own environment, it may not be able to compatible with NAT64 or others, stateful 464 has advantage which could work with others, will see.
 

FYI, the dIVI (https://datatracker.ietf.org/doc/draft-xli-behave-divi/https://datatracker.ietf.org/doc/draft-xli-behave-divi/)
and dIVI-PD (https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd/) models are fully compatiple with stateless NAT64, i.e. RFC6052 and RFC6145.

Regards,

xing


-Hui
 
This architecture is complicated.

CB


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

--------------020704030001080603030901-- From despres.remi@laposte.net Fri Jul 29 07:15:36 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648F921F861E for ; Fri, 29 Jul 2011 07:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNh6BFFLo2Nh for ; Fri, 29 Jul 2011 07:15:36 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id DA9D621F85CE for ; Fri, 29 Jul 2011 07:15:35 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 12EF1700008D; Fri, 29 Jul 2011 16:15:35 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id BF9E1700008A; Fri, 29 Jul 2011 16:15:34 +0200 (CEST) X-SFR-UUID: 20110729141534784.BF9E1700008A@msfrf2309.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, 29 Jul 2011 16:15:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Satoru Matsushima X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org, wdec@cisco.com, Paco Cortes Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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, 29 Jul 2011 14:15:36 -0000 Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit : > Cameron, ... > Stateless is not exclusive with stateful one, and also NAT64. > I agree with Hui. +1 RD From cb.list6@gmail.com Fri Jul 29 07:27:56 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AEF21F8BEA for ; Fri, 29 Jul 2011 07:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.237 X-Spam-Level: X-Spam-Status: No, score=-3.237 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-RZ7O7FF4K1 for ; Fri, 29 Jul 2011 07:27:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13F9921F8BD7 for ; Fri, 29 Jul 2011 07:27:55 -0700 (PDT) Received: by wwe5 with SMTP id 5so2411362wwe.13 for ; Fri, 29 Jul 2011 07:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+3MW4WJ4d45nOU3JXoZLatwWQSkM1/E217srUuBTWwc=; b=Aur8f4sC+/e4NJknu/nnR704f1w/RqCu20ncamxE15EJRwzvoxgzawbY7Eg9d2bgov N3tFukPVYMUu5TSErqn0JjeKLE3pAcr4xlpGb76C4pl7i1YBeQ2Hl4/TImdwNBr6EuAw 8J0hue6/l2hZWHLaYJfnlyB/6oYsbwwnT1D5U= MIME-Version: 1.0 Received: by 10.227.23.197 with SMTP id s5mr1835500wbb.72.1311949675126; Fri, 29 Jul 2011 07:27:55 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Fri, 29 Jul 2011 07:27:54 -0700 (PDT) Received: by 10.216.177.213 with HTTP; Fri, 29 Jul 2011 07:27:54 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Jul 2011 07:27:54 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=002215b02f7e595ed204a9361644 Cc: softwires@ietf.org, Paco Cortes , wdec@cisco.com Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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, 29 Jul 2011 14:27:56 -0000 --002215b02f7e595ed204a9361644 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" wrot= e: > > > Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit : > > > Cameron, > ... > > Stateless is not exclusive with stateful one, and also NAT64. > > I agree with Hui. > > +1 > RD > Ok. I do think the draft would benefit from narrowing some of the options. It seemed to me that statelessness was a key feature, but I may have misread. Either way, I think it is helpful if the true cost and benefits of statelessness is explored. It sounds like there may be a seperate thread on this. I am skeptical about stateless operation scaling. I don't even have 2000 ports per user (growth to 2015 ...), and I don't want to get into a positio= n where I have to tactically move ipv4 addresses around to meet demand. > > --002215b02f7e595ed204a9361644 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 29, 2011 7:15 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
>
> Le 29 juil. 2011 =E0 15:48, Satoru Matsushima a =E9crit :
>
> > Cameron,
> ...
> > Stateless is not exclusive with stateful one, and also NAT64.
> > I agree with Hui.
>
> +1
> RD
>

Ok. I do think the draft would benefit from narrowing some of the option= s. It seemed to me that statelessness was a key feature, but I may have mis= read.

Either way, I think it is helpful if the true cost and benefits of state= lessness is explored. It sounds like there may be a seperate thread on this= .

I am skeptical about stateless operation scaling. I don't even have = 2000 ports per user (growth to 2015 ...), and I don't want to get into = a position where I have to tactically move ipv4 addresses around to meet de= mand.
>
>

--002215b02f7e595ed204a9361644-- From satoru.matsushima@gmail.com Fri Jul 29 08:14:40 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9875521F8C88 for ; Fri, 29 Jul 2011 08:14: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njuG6BISSpvn for ; Fri, 29 Jul 2011 08:14:40 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0E41521F8C83 for ; Fri, 29 Jul 2011 08:14:39 -0700 (PDT) Received: by qyk29 with SMTP id 29so2401587qyk.10 for ; Fri, 29 Jul 2011 08:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QeAIjK5MPAHMeAUIK2VFXcAtHbd0mujKwwLzqo2x3AQ=; b=qR5tnvkjvzuDYRFObMj4kNZj6807KD2yPRFYgOsmS18FbbgbOW9ybpwBOKMSMFaprv lcrba+xKBUGX4PIMsvg/RAle1d2sS0ySbmKBlPlHr+AYH0lVPlpf/s/znq4UBksSOut8 DIJAEU/bwm+jqnDY4BVfm94u2oOpr5RfZRtEg= Received: by 10.229.74.144 with SMTP id u16mr1076684qcj.208.1311952471439; Fri, 29 Jul 2011 08:14:31 -0700 (PDT) Received: from dhcp-53a8.meeting.ietf.org (dhcp-53a8.meeting.ietf.org [130.129.83.168]) by mx.google.com with ESMTPS id m7sm1432997qct.17.2011.07.29.08.14.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 08:14:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Fri, 29 Jul 2011 11:14:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DAE2467-20FC-403C-8D1F-EA096176D374@gmail.com> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1244.3) Cc: softwires@ietf.org, Paco Cortes , wdec@cisco.com Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-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, 29 Jul 2011 15:14:40 -0000 Cameron, On 2011/07/29, at 10:27, Cameron Byrne wrote: > I am skeptical about stateless operation scaling. I don't even have = 2000 ports per user (growth to 2015 ...), and I don't want to get into a = position where I have to tactically move ipv4 addresses around to meet = demand.=20 That's a trade-off. Many people require to make clear the trade-off = among stateless and steteful that the softwire wg is now going to do. = Fundamentally, to support much port demand, applications should utilize = IPv6. Otherwise, restricted port sets should be utilize as much as = possible. There are some techniques could be helpful to do it, multiple = mapping rule is for example. cheers, --satoru From phdgang@gmail.com Fri Jul 29 08:18:44 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B7E21F8C6A for ; Fri, 29 Jul 2011 08:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dExVywrGMzeh for ; Fri, 29 Jul 2011 08:18:44 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0247A21F8C29 for ; Fri, 29 Jul 2011 08:18:43 -0700 (PDT) Received: by vws12 with SMTP id 12so3482510vws.31 for ; Fri, 29 Jul 2011 08:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XuwdkF8PVN71caSu0imLLNwA0E4AVvjiXPCkSChQeoQ=; b=Kedh0GU9dmaf8SXl2ihNi0dcZhEiFBVEo+G6MIexUPaNpf1GFyb3NgR7Obm+mEI6eF yV/4jNmKbwLFI+084+K//t6Gwsrea4uKXdICH49xdKlnhAq39i8CWtJrWBlllLJWsUEn l86fVoo1pjUfQFGpTGAGhpPcb/f0vhBjZCUn4= MIME-Version: 1.0 Received: by 10.52.74.166 with SMTP id u6mr1501880vdv.252.1311952723536; Fri, 29 Jul 2011 08:18:43 -0700 (PDT) Received: by 10.52.156.229 with HTTP; Fri, 29 Jul 2011 08:18:43 -0700 (PDT) In-Reply-To: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 29 Jul 2011 23:18:43 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:18:44 -0000 Before making such comparison (of course it should be as fair as possible), I think we need to state what solution space we are targeting and what category mode we should take care. If I understand correctly, I would paraphrase as following categories. a) Stateful+Dynamic port sets: e.g. DS-Lite b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 c) Stateless + Static port set: e.g. 4rd, 4via6 translation d) Stateless + Dynamic port set: ??(Any candidate solution?) Gang 2011/7/29, R=E9mi Despr=E9s : > Dear all, > > Dave rightly expresses in the Softwire meeting the need to separate/clari= fy > discussion about: > - Stateless vs stateful > =96 Static vs dynamic port sets > > The need to clarify is IMHO even larger than that. > > I therefore worked out a way to present the range of solutions to be > compared, with the following taken in consideration: > - The stateless/stateful IPv4 across IPv6 comparison isn't limited to IPv= 4 > shared addresses (applies also to exclusive IPv4 customer addresses). > - If there is, in BR/AFBR's, no Customer state (i.e. no states referring = to > individual IPv6 prefixes), there can't be per-transport-connection state > either. > - CE-CE direct paths are possible only if IPv4/IPv6 mappings of BR/AFBR's > don't depend on Customer state. > > The proposed document structure is as follows, with pros and cons for eac= h > section: > a) Stateful per transport connection (and also stateful per customer IPv6 > prefix) > e.g. DS-lite with CGN > b) Stateful per customer IPv6 prefix (but Stateless per transport > connection) > e.g. draft-cui-softwire-host-4over6-06 > c) Stateless per customer IPv6 prefix (and also stateless per transport > connection) > - Hub-an-spoke > TBD > - Direct CE-CE paths (mesh) > . Encapsulation based > e.g. draft-murakami-softwire-4rd-00 alias > . Translation based > e.g. draft-murakami-softwire-4v6-translation-00 > > Thoughts? > > Regards, > RD > > > > Le 28 juil. 2011 =E0 21:45, Dave Thaler a =E9crit : > >> Attaching here since they don't seem to be posted yet. >> >> -Dave >> >>> -----Original Message----- >>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >>> Behalf Of Satoru Matsushima >>> Sent: Thursday, July 28, 2011 1:29 PM >>> To: softwires@ietf.org list >>> Subject: [Softwires] Yesterday's slides >>> >>> Hi, >>> >>> Could someone tell me where is Dave Thaler's slides? >>> >>> Best regards, >>> --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 > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Fri Jul 29 08:58:25 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07EB21F8681 for ; Fri, 29 Jul 2011 08:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TwFBSdybM+W for ; Fri, 29 Jul 2011 08:58:24 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 943B021F866A for ; Fri, 29 Jul 2011 08:58:24 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 5EF2C7000090; Fri, 29 Jul 2011 17:58:23 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id D9BCD7000084; Fri, 29 Jul 2011 17:58:20 +0200 (CEST) X-SFR-UUID: 20110729155820891.D9BCD7000084@msfrf2217.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 29 Jul 2011 17:58:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 15:58:25 -0000 Le 29 juil. 2011 =E0 17:18, GangChen a =E9crit : > Before making such comparison (of course it should be as fair as = possible), > I think we need to state what solution space we are targeting and what > category mode we should take care. > If I understand correctly, I would paraphrase as following categories. >=20 > a) Stateful+Dynamic port sets: e.g. DS-Lite > b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 > c) Stateless + Static port set: e.g. 4rd, 4via6 translation OK so far, assuming that "stateful/stateless" implicitly means = "Stateful/stateless concerning individual customers". Note however that this isn't what stateful means _in general_, in = particular in NAT discussions.=20 The statefulness/statelessness we talk about should be expressed one way = or another ("per customer" is a proposal to do that).=20 > d) Stateless + Dynamic port set: ??(Any candidate solution?) NOK for this one: if BR/AFTR's are stateless (i.e. have no per customer = state) they can't manage dynamic port sets. That's the point below, now preceded by an *. The possible solution I mentioned is one where: - like with 4rd and 4via6 Translation, BR/AFTR's are stateless per = customer (and therefore also stateless per transport connection) - unlike with 4rd and 4via6, CE-CE paths within the ISP network always = via at least one BR (the hub and spoke topology)=20 This hasn't been described yet, AFAIK, but can be simple variations of = 4rd (i.e. 4via6 Encapsulation) and of 4via6 Translation. Is that clearer? Regards, RD >=20 > Gang >=20 >=20 > 2011/7/29, R=E9mi Despr=E9s : >> Dear all, >>=20 >> Dave rightly expresses in the Softwire meeting the need to = separate/clarify >> discussion about: >> - Stateless vs stateful >> =96 Static vs dynamic port sets >>=20 >> The need to clarify is IMHO even larger than that. >>=20 >> I therefore worked out a way to present the range of solutions to be >> compared, with the following taken in consideration: >> - The stateless/stateful IPv4 across IPv6 comparison isn't limited to = IPv4 >> shared addresses (applies also to exclusive IPv4 customer addresses). * >> - If there is, in BR/AFBR's, no Customer state (i.e. no states = referring to >> individual IPv6 prefixes), there can't be per-transport-connection = state >> either. >> - CE-CE direct paths are possible only if IPv4/IPv6 mappings of = BR/AFBR's >> don't depend on Customer state. >>=20 >> The proposed document structure is as follows, with pros and cons for = each >> section: >> a) Stateful per transport connection (and also stateful per customer = IPv6 >> prefix) >> e.g. DS-lite with CGN >> b) Stateful per customer IPv6 prefix (but Stateless per transport >> connection) >> e.g. draft-cui-softwire-host-4over6-06 >> c) Stateless per customer IPv6 prefix (and also stateless per = transport >> connection) >> - Hub-an-spoke >> TBD >> - Direct CE-CE paths (mesh) >> . Encapsulation based >> e.g. draft-murakami-softwire-4rd-00 alias >> . Translation based >> e.g. draft-murakami-softwire-4v6-translation-00 >>=20 >> Thoughts? >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> Le 28 juil. 2011 =E0 21:45, Dave Thaler a =E9crit : >>=20 >>> Attaching here since they don't seem to be posted yet. >>>=20 >>> -Dave >>>=20 >>>> -----Original Message----- >>>> From: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] On >>>> Behalf Of Satoru Matsushima >>>> Sent: Thursday, July 28, 2011 1:29 PM >>>> To: softwires@ietf.org list >>>> Subject: [Softwires] Yesterday's slides >>>>=20 >>>> Hi, >>>>=20 >>>> Could someone tell me where is Dave Thaler's slides? >>>>=20 >>>> Best regards, >>>> --satoru >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 From bingxuere@gmail.com Fri Jul 29 19:01:43 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B3621F8B3F for ; Fri, 29 Jul 2011 19:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6NU26swkC7B for ; Fri, 29 Jul 2011 19:01:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81B7521F8B3E for ; Fri, 29 Jul 2011 19:01:38 -0700 (PDT) Received: by iye7 with SMTP id 7so5558171iye.31 for ; Fri, 29 Jul 2011 19:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BNlX0GFtlGTzZRoQbLHCf4AOQm2gVI5p3/ECy6vwPX0=; b=dlEagndFyjQ8nAgx/9IJhvlEbpY7Gi6O3O8UEUWloijzEswwbNscEiqTZvtbF7QAIB Ok+ikeVlXXHqPycBe7J2JeExoWwVbnNA7jaoHmqV57n2DAsHQ3x585wvIv7OU9p5htyl poQjwgm35G9iNz2BYzPaIMO1Mprhf4sqTDJ1g= Received: by 10.231.6.157 with SMTP id 29mr1335018ibz.131.1311991298092; Fri, 29 Jul 2011 19:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.218.199 with HTTP; Fri, 29 Jul 2011 19:01:18 -0700 (PDT) In-Reply-To: <0BD07F42-9845-472D-9221-AD0879B62DA4@laposte.net> References: <71F7C208-9C83-448A-A2B1-C323C1537A6A@laposte.net> <0BD07F42-9845-472D-9221-AD0879B62DA4@laposte.net> From: Qiong Date: Sat, 30 Jul 2011 10:01:18 +0800 Message-ID: To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= Content-Type: multipart/alternative; boundary=00151773df4245705c04a93fc7c7 Cc: Softwires-wg Subject: Re: [Softwires] The Framing discussion of yesterday X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 02:01:43 -0000 --00151773df4245705c04a93fc7c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Remi, Thanks. I think your solution would work, but it still get ICMP Unreachable message rather than normal communication packet. Ok, I will keep silent and let's wait for Dave's answer :) On Fri, Jul 29, 2011 at 3:42 PM, R=C3=A9mi Despr=C3=A9s wrote: > > Le 29 juil. 2011 =C3=A0 07:19, Qiong a =C3=A9crit : > > Hi, Remi, Dave, > > I'm not sure whether I get the point in Dave'd slide. Please correct me i= f > anything is wrong. > > In my understanding, the major problem in this failure mode would happen = on > the downstream path, rather than the upstream one. A node which is attac= hed > to an IPv6 network can determine whether to use shared-address system or > not. However, when the downstream IPv4 packet arrived at the network-side > GW, it can not tell whether the packet should be translated into shared-m= ode > or exclusive-mode. So it can not work unless network-side GW have know th= ese > IPv4 addresses in advance for either mode. > > > In the downstream direction from the Internet, the stateless BR (no per > customer state) maps the destination transport-address to an IPv6 > destination address. > Because this IPv6 destination address has an IID that no host recognizes > (as discussed recently on the mailing list), the packet will be discarded= . A > Destination-Unreachable ICMPv6 message is then returned to the BR anycast > address. The BR statelessly converts it into an IPv4 ICMP error message > returned to the IPv4 source. > If the path is direct from a CE of a 4V6 domain to another CE of the same > domain, the ICMPv6 error message is returned to the source CE. This CE do= es > the conversion to the right IPv4 ICMP message for the CE NAT44. > Does this answer your concern? > > Moreover, I think this issue would have distinct impact on stateless > solutions and stateful ones. For stateful ones, the states in AFTR have > already shown the binding information between IPv4 address/port set and I= Pv6 > address explicitly. While for stateless ones, these address mapping rules > are determined implicitly in algorithm. As a result, in order to reflect > prefix mapping information (discussed in multiple prefix threads), some m= ore > rules would be needed to be introduced accordingly . > > > Of course, the number of rules would be significantly less than the numbe= r > of states . > > > Yes, that's the point. > The difference is between BR/AFTR's that have states _per customer prefix= _ > or just as many mapping rules as independent IPv4 prefixes. > > In addition, if several BR/AFTR's instances have to share their load for > scalability, their per-customer states have to be identical. If per-custo= mer > states are dynamically updated this becomes complex. > > Last but not least, if there is one mapping rule per independent IPv4 > prefix, direct CE-to-CE paths are possible (each CE knows all mapping > rules). If BR/AFTR's have per-customer states, CE's don't know them. Dir= ect > CE-to-CE paths are impossible. > > Hope it helps. > > Kind regards, > RD > > ... > > >> If a node is attached to an IPv6 network and ignores the static >> shared-address system of this network, it won't be able to receive/accep= t >> parameters of this-system mapping rule(s). >> - It will therefore ignore that it could have used an exclusive port set >> of a global IPv4 address. >> - It will do nothing with its assigned address-and-port-set. >> > > --00151773df4245705c04a93fc7c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Remi,

Thanks. I think your solution would work, but i= t still get ICMP=C2=A0Unreachable message rather than normal communication = packet.

Ok, I will keep silent and let's wait = for Dave's answer :) =C2=A0=C2=A0

On Fri, Jul 29, 2011 at 3:42 PM, R=C3= =A9mi Despr=C3=A9s <despres.remi@laposte.net> wrote:

Le 29 juil. 2011 =C3=A0 0= 7:19, Qiong a =C3=A9crit :

Hi, Remi, Dave,

I'm not sure whether I get the = point in Dave'd slide. Please correct me if anything is wrong.

In my understanding, the major problem in this failure = mode would happen on the downstream path, rather than the upstream one. =C2= =A0A node which is attached to an IPv6 network can determine whether to use= shared-address system or not. However, when the downstream IPv4 packet arr= ived at the network-side GW, it can not tell whether the packet should be t= ranslated into shared-mode or exclusive-mode. So it can not work unless net= work-side GW have know these IPv4 addresses in advance for either mode.=C2= =A0

In the downstream direction from the= Internet, the stateless BR (no per customer state) maps the=C2=A0destinati= on=C2=A0transport-address to an IPv6 destination address.
Because= this IPv6 destination address has an IID that no host recognizes (as discu= ssed recently on the mailing list), the packet will be discarded. A Destina= tion-Unreachable ICMPv6 message is then returned to the BR anycast address.= The BR statelessly converts it into an IPv4 ICMP error message returned to= the IPv4 source.
If the path is direct from a CE of a 4V6 domain to another CE of the s= ame domain, the ICMPv6 error message is returned to the source CE. This CE = does the conversion to the right IPv4 ICMP message for the =C2=A0CE NAT44.<= /div>
Does this answer your concern?=C2=A0

Moreover, I think this issue would have distinct impact on stateless s= olutions and stateful ones. For stateful ones, the states in AFTR have alre= ady shown the binding=C2=A0information=C2=A0between IPv4 address/port set a= nd IPv6 address explicitly. While for stateless ones, these address mapping= rules are determined implicitly in algorithm. As a result, in order=C2=A0t= o reflect prefix mapping information (discussed in multiple prefix threads)= ,=C2=A0some more rules would be needed to be introduced accordingly .

Of course, the number of ru= les would be=C2=A0significantly=C2=A0less than the number of states=C2=A0.<= /div>

Yes, that's the point.
The difference is between BR/AFTR's that have states _per custome= r prefix_ or just as many mapping rules as independent IPv4 prefixes.=C2=A0=

In addition, if several BR/AFTR's instances have to= share their load for scalability, their per-customer states have to be ide= ntical. If per-customer states are dynamically updated this becomes complex= .

Last but not least, if there is one mapping rule per in= dependent IPv4 prefix, direct CE-to-CE paths are possible (each CE knows al= l mapping rules). =C2=A0If BR/AFTR's have per-customer states, CE's= don't know them. Direct CE-to-CE paths are impossible.

Hope it helps.

Kind regards,
RD

...


If a node is attached to an IPv6 network and ignores the static shared-= address system of this network, it won't be able to receive/accept para= meters of this-system mapping rule(s).
- It will therefore ignore that it could have used an exclusive port set of= a global IPv4 address.
- It will do nothing with its assigned address-and-port-set.


--00151773df4245705c04a93fc7c7-- From weapon@csnet1.cs.tsinghua.edu.cn Sat Jul 30 06:27:07 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B221F21F8841 for ; Sat, 30 Jul 2011 06:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.852 X-Spam-Level: * X-Spam-Status: No, score=1.852 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U41H7T3BcsRL for ; Sat, 30 Jul 2011 06:27:07 -0700 (PDT) Received: from mail.catc.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 84DC821F87D9 for ; Sat, 30 Jul 2011 06:26:45 -0700 (PDT) Received: from PengWu-laptop (unknown [209.226.201.250]) by mail.catc.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id D62022A20011; Sat, 30 Jul 2011 21:26:39 +0800 (CST) Date: Sat, 30 Jul 2011 21:26:38 +0800 From: "Peng Wu" To: "GangChen" , "=?gb2312?B?UultaSBEZXNwculz?=" References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , Message-ID: <201107302126309348102@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:27:07 -0000 Hi Gang, >Before making such comparison (of course it should be as fair as possible), >I think we need to state what solution space we are targeting and what >category mode we should take care. >If I understand correctly, I would paraphrase as following categories. > >a) Stateful+Dynamic port sets: e.g. DS-Lite >b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 >c) Stateless + Static port set: e.g. 4rd, 4via6 translation >d) Stateless + Dynamic port set: ??(Any candidate solution?) I would say that the last one makes no sense From satoru.matsushima@gmail.com Sat Jul 30 06:39:02 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41A221F8ABB for ; Sat, 30 Jul 2011 06:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBVV4Fwmx+-r for ; Sat, 30 Jul 2011 06:39:02 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4847021F8ABC for ; Sat, 30 Jul 2011 06:39:02 -0700 (PDT) Received: by gwb20 with SMTP id 20so3685509gwb.31 for ; Sat, 30 Jul 2011 06:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=c203tNb6FQ7qW69VSGtUcy9PINBc+8MTGAKnrEdao3c=; b=uKmFuJ0g6UmgfVvR4JREhRfiPvFPZHIykBI8Xx//q2kgO7V3VMM8hWMf9Xtg+YwDPa WsCTQAyKDwA4xLAmRQZQ9j3mj0iAQnCYh57ibfuiYR4Mxedi1hf0s0c1UlQdsCYI2clC wysokxmOWFCiQfDDUrKnQwwL8+aUABWHrRMAc= Received: by 10.236.185.100 with SMTP id t64mr1409389yhm.523.1312033142532; Sat, 30 Jul 2011 06:39:02 -0700 (PDT) Received: from 162.10.242.10.in-addr.arpa (mb50736d0.tmodns.net [208.54.7.181]) by mx.google.com with ESMTPS id o47sm2103038yhn.30.2011.07.30.06.39.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 06:39:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <201107302126309348102@csnet1.cs.tsinghua.edu.cn> Date: Sat, 30 Jul 2011 08:38:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <51E2768B-3B23-4904-BF9C-866BB705509B@gmail.com> References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com>, <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>, , <201107302126309348102@csnet1.cs.tsinghua.edu.cn> To: "Peng Wu" X-Mailer: Apple Mail (2.1244.3) Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:39:02 -0000 On 2011/07/30, at 8:26, Peng Wu wrote: >>=20 >> a) Stateful+Dynamic port sets: e.g. DS-Lite >> b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 >> c) Stateless + Static port set: e.g. 4rd, 4via6 translation >> d) Stateless + Dynamic port set: ??(Any candidate solution?) >=20 > I would say that the last one makes no sense Agree. It is a problem space only on that logical frame. I think that the analysis work doesn't need to insist necessity of = unfeasible area solution. cheers, --satoru= From satoru.matsushima@gmail.com Sat Jul 30 06:57:36 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9807021F84F5 for ; Sat, 30 Jul 2011 06:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBQsZT1CiD9S for ; Sat, 30 Jul 2011 06:57:31 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C288321F850B for ; Sat, 30 Jul 2011 06:57:12 -0700 (PDT) Received: by gyd5 with SMTP id 5so3546102gyd.31 for ; Sat, 30 Jul 2011 06:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=qbfWRoNEfTe2w/w1GY2ag/N2sW++ZBxHdRmCLOI2SSo=; b=d+wWh271aXb4Af+QSFHIvcBVvu0dcnEqut+51foIhC3z+X75WqauHdg+K590Kw7aku wdz9PG5mq7CNgZjrz3m0MsSVucRTq1zSsuS9KEG5EKidL7LQhnLx5ToDxTFlpQDCxbpU /cSiZKvoykTGp+stI73GWFIy1QPNFbhG5y9kc= Received: by 10.101.54.2 with SMTP id g2mr2068288ank.51.1312034233152; Sat, 30 Jul 2011 06:57:13 -0700 (PDT) Received: from 162.10.242.10.in-addr.arpa (mb50736d0.tmodns.net [208.54.7.181]) by mx.google.com with ESMTPS id j30sm160969ann.48.2011.07.30.06.57.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 06:57:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Satoru Matsushima In-Reply-To: Date: Sat, 30 Jul 2011 08:57:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2E10EAEB-6671-42F6-A371-BA75C88B2556@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B1A3F4D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: GangChen X-Mailer: Apple Mail (2.1244.3) Cc: Softwires-wg , Softwire Chairs Subject: Re: [Softwires] Clarification of the stateles/stateful discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 13:57:36 -0000 One clarification. On 2011/07/29, at 10:18, GangChen wrote: > Before making such comparison (of course it should be as fair as = possible), > I think we need to state what solution space we are targeting and what > category mode we should take care. > If I understand correctly, I would paraphrase as following categories. >=20 > a) Stateful+Dynamic port sets: e.g. DS-Lite > b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06 > c) Stateless + Static port set: e.g. 4rd, 4via6 translation > d) Stateless + Dynamic port set: ??(Any candidate solution?) AFAIK, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address = sharing. Is that correct? cheers, --satoru= From weapon@csnet1.cs.tsinghua.edu.cn Sat Jul 30 07:16:15 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D77A21F8AFF for ; Sat, 30 Jul 2011 07:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.702 X-Spam-Level: * X-Spam-Status: No, score=1.702 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcNps37AHrB0 for ; Sat, 30 Jul 2011 07:16:15 -0700 (PDT) Received: from mail.catc.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 998A221F8AF9 for ; Sat, 30 Jul 2011 07:15:49 -0700 (PDT) Received: from PengWu-laptop (unknown [209.226.201.250]) by mail.catc.edu.cn (EMOS V1.5 (Postfix)) with ESMTPA id 4955124787D7; Sat, 30 Jul 2011 22:15:47 +0800 (CST) Date: Sat, 30 Jul 2011 22:15:46 +0800 From: "Peng Wu" To: "Lee, Yiu" , "softwires@ietf.org" Message-ID: <201107302215444330623@csnet1.cs.tsinghua.edu.cn> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] DS-lite Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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 Jul 2011 14:16:15 -0000 Hi all, I think definitely we should define the first case, isn't reduce redundant delivery the original spirit of multicast? Deliver multicast over an IPv6 multicast disabled network doesn't seem quite persuading, except the legacy case. So if we need to choose one, then I prefer the first one. Or can we make the second case a special case in one unified draft? >Hi WG, > >In today meeting, we presented two drafts on to enable multicast in DS-lite. I think they target different use cases: > >The use case of http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04 is to deliver multicast over DS-lite in an IPv6 multicast enabled network. > >The use case of http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemulticast-00 is to deliver multicast over DS-lite in an IPv6 multicast disabled network. > >I think both drafts target different use cases. My question to the WG is: Should we work on both use cases? If not, which use case the WG should work on first? >