From jacni@jacni.com Wed May 2 18:03:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5130D21F84B2 for ; Wed, 2 May 2012 18:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUvp-5UWSxfO for ; Wed, 2 May 2012 18:03:29 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id D0F4421F84A7 for ; Wed, 2 May 2012 18:03:29 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 25336380049 for ; Wed, 2 May 2012 21:03:28 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 5C7573400DF for ; Thu, 3 May 2012 09:03:26 +0800 (CST) Received: from [10.140.20.21] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJBrYwlc2aFPt3ThAA--.4969S2; Thu, 03 May 2012 09:03:25 +0800 (CST) Message-ID: <4FA1D95C.6090906@jacni.com> Date: Thu, 03 May 2012 09:03:24 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090303030300020004010904" X-CM-TRANSID: +AWowJBrYwlc2aFPt3ThAA--.4969S2 X-Coremail-Antispam: 1UD129KBjvdXoWruryDAF4DWr4DtFy8ZF4xJFb_yoW3trc_ur WDtw10qr1DAr4jgrWxJr1ktrnxKr45WryUKFyDAr4DZr1Uur1Dtrs5Kry7Wr1UGry5Jr1U Gr1fGrnrKa45KjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ-t7k0a2IF6FyUM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_ Wr0E3s1lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcV AKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI 7VAKI48JMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43 ZEXa7IU0_Ma5UUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQECEko7lQ2zUwAKsT Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 03 May 2012 01:03:31 -0000 This is a multi-part message in MIME format. --------------090303030300020004010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Re-, On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: > Well, even the WG decided to go with MAP, we would still need to coin toss > between MAP-T and MAP-E, wouldn't we? May I share your concern. Cheers, Jacni > On 4/26/12 10:50 AM, "Jan Zorz @ go6.si" wrote: > >> On 4/26/12 11:50 AM, Mark Townsley wrote: >>> Perhaps we would have been better off with the coin toss. >> +1 >> >> bingo. >> >> Cheers, Jan >> >> P.S: I'll not waste more bits on this topic as it's apparently a waste >> of bandwidth :) >> >> P.P.S: Should we deprecate RFC6346? >> _______________________________________________ >> 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 --------------090303030300020004010904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Re-,

On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: 
Well, even the WG decided to go with MAP, we would still need to coin toss
between MAP-T and MAP-E, wouldn't we?
May I share your concern.


Cheers,
Jacni

On 4/26/12 10:50 AM, "Jan Zorz @ go6.si" <jan@go6.si> wrote:


On 4/26/12 11:50 AM, Mark Townsley wrote:

Perhaps we would have been better off with the coin toss.

+1

bingo.

Cheers, Jan

P.S: I'll not waste more bits on this topic as it's apparently a waste
of bandwidth :)

P.P.S: Should we deprecate RFC6346?
_______________________________________________
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
--------------090303030300020004010904-- From yiu_lee@cable.comcast.com Wed May 2 19:18:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3204821F84D5 for ; Wed, 2 May 2012 19:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.844 X-Spam-Level: X-Spam-Status: No, score=-99.844 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzzGO07UTW9u for ; Wed, 2 May 2012 19:18:18 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9826221F84BF for ; Wed, 2 May 2012 19:18:18 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.11258182; Wed, 02 May 2012 22:10:41 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.02.0283.003; Wed, 2 May 2012 22:18:14 -0400 From: "Lee, Yiu" To: Jacni Qin Thread-Topic: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Thread-Index: AQHNKNL92ORHiKu0hEKkTEVAnswsCA== Date: Thu, 3 May 2012 02:18:13 +0000 Message-ID: In-Reply-To: <4FA1D95C.6090906@jacni.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [24.40.55.73] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3418841892_968767" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 03 May 2012 02:18:20 -0000 --B_3418841892_968767 Content-type: multipart/alternative; boundary="B_3418841892_960824" --B_3418841892_960824 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. From: Jacni Qin Date: Wednesday, May 2, 2012 9:03 PM To: "Yiu L. LEE" Cc: "Jan Zorz @ go6.si" , "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Re-, On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: > Well, even the WG decided to go with MAP, we would still need to coin toss > between MAP-T and MAP-E, wouldn't we? May I share your concern. Cheers, Jacni > On 4/26/12 10:50 AM, "Jan Zorz @ go6.si" > wrote: > >> On 4/26/12 11:50 AM, Mark Townsley wrote: >>> Perhaps we would have been better off with the coin toss. >> +1 >> >> bingo. >> >> Cheers, Jan >> >> P.S: I'll not waste more bits on this topic as it's apparently a waste >> of bandwidth :) >> >> P.P.S: Should we deprecate RFC6346? >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires --B_3418841892_960824 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
My concern is MAP isn't a si= ngle solution. Operators still need to make a choice between E and T because= they are not compatible.

Fr= om: Jacni Qin <jacni@jacni.com>
Date: Wednesday, May 2, 201= 2 9:03 PM
To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>Cc: "Jan Zorz @ go6.si" <jan@go6.si>, "softwires@ietf.org" <softwires@i= etf.org>
Subject: Re: [Soft= wires] Result from the consensus call on Map vs 4rd-U and official way forwa= rd

Re-,

On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: 
Well, even the WG decided to go with MAP, we would still nee=
d to coin toss
between MAP-T and MAP-E, wouldn't we?
May I share your concern.


Cheers,
Jacni

On 4/26/12 10:50 AM, "Jan Zorz @ go6.si" <jan@go6.si> w=
rote:


On 4/26/12 11:50 AM, Mark Townsl=
ey wrote:

Perhaps we would have been bette=
r off with the coin toss.

+1

bingo.

Cheers, Jan

P.S: I'll not waste more bits on this topic as it's apparently a waste
of bandwidth :)

P.P.S: Should we deprecate RFC6346?
_______________________________________________
Softwires mailing list
Softwi=
res@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires<=
/a>


_______________________________________________
Softwires mailing list
Softwi=
res@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires<=
/a>
 --B_3418841892_960824-- --B_3418841892_968767 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSzfl3z gw+rm21hfY8QyUFh6ZxRCjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA1MDMwMjE4MTJaMA0GCSqGSIb3DQEBAQUABIIBABc+uhJPe1GIhtnV07UFNvFw QMbOrQfv0HNSjckhA4Nm8g92peaaGFUa5NcPzU01Gc33M7fT5GFf3s449F+tYn78rGqQGVV5 2gzCxkUQd9ITNVb7y+2MoBvc8fRaXbenHxFjIn2KyYSzB6CcWbTM2bQ8cciJAUYWGpArSSc6 vBtCydQT5vFY9sY4aw0hImm5L34ME5/h+2sE7jmJZjLI9uT4pA20b5WiGI3vbxGwYuNalGiK ezINSho9+7ppkSpsB4QkClfGJvsrtSlc8Y7z3kyJ73p8l3r4m28DoeiyLh0XCp7gOCPeolCN hgKNwp5e5fHaiqqyGwuIvwh5G8yHHp0= --B_3418841892_968767-- From jacni@jacni.com Wed May 2 22:53:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888E121F8607 for ; Wed, 2 May 2012 22:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMJTbf7485hO for ; Wed, 2 May 2012 22:53:27 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 9133921F8603 for ; Wed, 2 May 2012 22:53:12 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id A27EF380058 for ; Thu, 3 May 2012 01:53:11 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 2429C34006D for ; Thu, 3 May 2012 13:53:10 +0800 (CST) Received: from [10.140.20.21] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJCrgQdEHaJPO+PhAA--.5599S2; Thu, 03 May 2012 13:53:09 +0800 (CST) Message-ID: <4FA21D44.400@jacni.com> Date: Thu, 03 May 2012 13:53:08 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------070105080803010809070507" X-CM-TRANSID: +AWowJCrgQdEHaJPO+PhAA--.5599S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw48Kw1UAry5Zr15WFy5twb_yoW8Gw48pF 4rJ34DGw17JF1rA395Cr1UC3yjv3WrJrW5Gw15tF18JryUJFW8tw1vkw45AFWUJr4rXr4D JrWUur1UJan8Xw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWDJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07jfKsbUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQECEko7lQ2zUwAPsW Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 03 May 2012 05:53:29 -0000 This is a multi-part message in MIME format. --------------070105080803010809070507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Re-, On 5/3/2012 Thursday 10:18 AM, Lee, Yiu wrote: > My concern is MAP isn't a single solution. Operators still need to > make a choice between E and T because they are not compatible. Fully agree, and IMHO, there have been lots of compromise in the design of MAP algorithm to accommodate both E and T. Cheers, Jacni > > From: Jacni Qin > > Date: Wednesday, May 2, 2012 9:03 PM > To: "Yiu L. LEE" > > Cc: "Jan Zorz @ go6.si" >, > "softwires@ietf.org " > > Subject: Re: [Softwires] Result from the consensus call on Map vs > 4rd-U and official way forward > > Re-, > > On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: >> Well, even the WG decided to go with MAP, we would still need to coin toss >> between MAP-T and MAP-E, wouldn't we? > May I share your concern. > > > Cheers, > Jacni > >> On 4/26/12 10:50 AM, "Jan Zorz @ go6.si" wrote: >> >>> On 4/26/12 11:50 AM, Mark Townsley wrote: >>>> Perhaps we would have been better off with the coin toss. >>> +1 >>> >>> bingo. >>> >>> Cheers, Jan >>> >>> P.S: I'll not waste more bits on this topic as it's apparently a waste >>> of bandwidth :) >>> >>> P.P.S: Should we deprecate RFC6346? >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires --------------070105080803010809070507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Re-,

On 5/3/2012 Thursday 10:18 AM, Lee, Yiu wrote:
My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible.

Fully agree, and IMHO, there have been lots of compromise in the design of MAP algorithm to accommodate both E and T.


Cheers,
Jacni


From: Jacni Qin <jacni@jacni.com>
Date: Wednesday, May 2, 2012 9:03 PM
To: "Yiu L. LEE" <yiu_lee@cable.comcast.com>
Cc: "Jan Zorz @ go6.si" <jan@go6.si>, "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward

Re-,

On 4/30/2012 Monday 4:03 AM, Lee, Yiu wrote: 
Well, even the WG decided to go with MAP, we would still need to coin toss
between MAP-T and MAP-E, wouldn't we?
May I share your concern.


Cheers,
Jacni

On 4/26/12 10:50 AM, "Jan Zorz @ go6.si" <jan@go6.si> wrote:


On 4/26/12 11:50 AM, Mark Townsley wrote:

Perhaps we would have been better off with the coin toss.

+1

bingo.

Cheers, Jan

P.S: I'll not waste more bits on this topic as it's apparently a waste
of bandwidth :)

P.P.S: Should we deprecate RFC6346?
_______________________________________________
Softwires mailing list
Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
Softwires mailing list
Softwires@ietf.orghttps://www.ietf.org/mailman/listinfo/softwires
--------------070105080803010809070507-- From ichiroumakino@gmail.com Wed May 2 23:58:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC55321F85F8 for ; Wed, 2 May 2012 23:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6t5TsPXrrze for ; Wed, 2 May 2012 23:58:40 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 24FA621F85A2 for ; Wed, 2 May 2012 23:58:39 -0700 (PDT) Received: by werb10 with SMTP id b10so1122221wer.31 for ; Wed, 02 May 2012 23:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kK70Gkk0bpcXuavt6amHpnBwT3n6v4zlfj3APL8yaiE=; b=d+xHXfUohBBZHumVwFTzmaYEtpC5wLcJYPwq4+k7ICz/WeOT2z4c3TFaPfD62aaIYz o2+txlpkgkSgEjbThd6aH6iGPhEflIh8nAlvCQD0ayeMebmA5OqUVJes3GO/ZDP9DdkL 4+NgQfG9BulKl/545SO124S+tK0Y+DnYSmc1C6z9dJJywmvINPKfPFNfz5SKT4ahWaaQ XbGEeSvmjmLCxBnTBOkBST0Y9clPECOekQ1ul/QcvH0meOnBbZqboSWtKgeQaDwExMQb 0N+Y7qljBkLZfR2kMR8gY/DMaKAnXNwV8Fa4x0OzZnG/JoYa1MJPQWobpI+Uvscd9rlv ubkA== Received: by 10.216.150.166 with SMTP id z38mr669059wej.78.1336028319303; Wed, 02 May 2012 23:58:39 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-95.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fn2sm585408wib.0.2012.05.02.23.58.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 23:58:38 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4FA21D44.400@jacni.com> Date: Thu, 3 May 2012 08:58:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> References: <4FA21D44.400@jacni.com> To: Jacni Qin X-Mailer: Apple Mail (2.1257) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 03 May 2012 06:58:40 -0000 Jacni, >> My concern is MAP isn't a single solution. Operators still need to = make a choice between E and T because they are not compatible. would it alleviate your concerns if the documents had MUSTs for both? = i.e. increasing the probability that an implementation supported both, = and making this purely into an operational choice? > Fully agree, and IMHO, there have been lots of compromise in the = design of MAP algorithm to accommodate both E and T. examples? cheers, Ole From jacni@jacni.com Thu May 3 00:17:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A8921F861A for ; Thu, 3 May 2012 00:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWCLhuAUZDEk for ; Thu, 3 May 2012 00:17:41 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 41D0921F8618 for ; Thu, 3 May 2012 00:17:40 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id B0D943800AE for ; Thu, 3 May 2012 03:17:39 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 3902134011D for ; Thu, 3 May 2012 15:17:38 +0800 (CST) Received: from [10.140.20.21] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJC7mQYPMaJPfgDiAA--.7486S2; Thu, 03 May 2012 15:17:37 +0800 (CST) Message-ID: <4FA2310F.6020900@jacni.com> Date: Thu, 03 May 2012 15:17:35 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: =?UTF-8?B?T2xlIFRyw7hhbg==?= References: <4FA21D44.400@jacni.com> <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> In-Reply-To: <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: +AWowJC7mQYPMaJPfgDiAA--.7486S2 X-Coremail-Antispam: 1UD129KBjvdXoWruFy8trWDKry3XF15Cr18Grg_yoWfXFg_Cr s5WF15Ja4UXFZ3Jay3Gryj9FnIyFWFgr1rXry0qFZrta48ZrW3Gan0kryIyry7Ja9rAr93 G3Z3Gr4jg342vjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJ-M7k0a2IF6w4kM7kC6x804xWl1xkIjI8I6I8E6xAIw20EY4v20xvaj40_ Wr0E3s1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I 8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28I cxkI7VAKI48JMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnU UI43ZEXa7IUnPfH5UUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQECEko7lQ2zUwAWsP Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 03 May 2012 07:17:41 -0000 Ole, On Thursday, May 03, 2012 2:58:35 PM, Ole Trøan wrote: > Jacni, > >>> My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. > > would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice? > I'd rather prefer you pick one only. >> Fully agree, and IMHO, there have been lots of compromise in the design of MAP algorithm to accommodate both E and T. > > examples? > Section 5.4, the BR address, And the 6 about the design of IID, I'm not a fan of the statement like "The encoding of the full IPv4 address into the interface identifier, both for the source and destination IPv6 addresses have been shown to be useful for troubleshooting. " ... Cheers, Jacni > cheers, > Ole > > > From ichiroumakino@gmail.com Thu May 3 01:38:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F73121F8601 for ; Thu, 3 May 2012 01:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUj1cV8WkScg for ; Thu, 3 May 2012 01:38:16 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 90ECB21F8603 for ; Thu, 3 May 2012 01:38:11 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so123573wgb.1 for ; Thu, 03 May 2012 01:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VBwEi8eWo7WPlJ0TjYyomZ4/tabn/4B5cX2nOqFaSyk=; b=JEvsfjkieRXZPLyTBVDpN6Xlz4S74vjPtA0DMOMR1mrT0Tl/3In4UV3cbJYB0KIYIm jynI3fDceQKW9PlnuJLBXTcmNS3Y2k+/st7yOJJ3rrbjInYLy4Dw1Hxh6V0WoIi8qY8s D1jQfDnffkEdVbJnFpZ+N4OV9WJ/pPfgorJyKIdM1TYv8QcOWcMFQPV51Qe517vAla40 9WNGmcCJ6aYgSzrZzcWuXBXbD9Ym4wfnGqZhs/XZRN736BihkBLeB6Zz6LmA0XWLVyQj 8d3wWpyfD9MlEntVkeWC9tGa+BAbyGoa/bT72R0AH0c0U6OMj6+6osXK7LXrv1+/ogCu sQrA== Received: by 10.216.195.10 with SMTP id o10mr923922wen.11.1336034291009; Thu, 03 May 2012 01:38:11 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-95.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id du4sm1274881wib.10.2012.05.03.01.38.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 01:38:10 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <4FA2310F.6020900@jacni.com> Date: Thu, 3 May 2012 10:38:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FA21D44.400@jacni.com> <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> <4FA2310F.6020900@jacni.com> To: Jacni Qin X-Mailer: Apple Mail (2.1257) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 03 May 2012 08:38:17 -0000 Jacni, >>>> My concern is MAP isn't a single solution. Operators still need to = make a choice between E and T because they are not compatible. >>=20 >> would it alleviate your concerns if the documents had MUSTs for both? = i.e. increasing the probability that an implementation supported both, = and making this purely into an operational choice? >>=20 > I'd rather prefer you pick one only. wouldn't we all. I think you're flogging a dead horse. let us accept = that the requirements for translation and the requirements for = encapsulation are mutually exclusive. cheers, Ole From despres.remi@laposte.net Thu May 3 02:09:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F74821F8617 for ; Thu, 3 May 2012 02:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9MDC35ywCwU for ; Thu, 3 May 2012 02:09:48 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 374D921F8601 for ; Thu, 3 May 2012 02:09:46 -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 356179401B8; Thu, 3 May 2012 11:09:36 +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, 3 May 2012 11:09:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02A2EFBA-42B1-4EA9-AE3B-7136F3407C3E@laposte.net> References: <4FA21D44.400@jacni.com> <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> <4FA2310F.6020900@jacni.com> To: Softwires WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 03 May 2012 09:09:49 -0000 2012-05-03 =E0 10:38, Ole Tr=F8an: ... > let us accept that the requirements for translation and the = requirements for encapsulation are mutually exclusive. Agreed: each of E or T doesn't cover by itself all expressed = requirements for a stateless 4via6 solution.=20 The question that remains, however, is whether 4rd does cover, or not, = all these requirements in a unified solution.=20 This question will better be answered when the WG drafts on both MAP and = 4rd are available and stabilized. Looking forward to it, RD From internet-drafts@ietf.org Thu May 3 17:42:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7D321F8620; Thu, 3 May 2012 17:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoYJuSlCp+AB; Thu, 3 May 2012 17:42:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7636D21F862F; Thu, 3 May 2012 17:42:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504004210.22773.70578.idtracker@ietfa.amsl.com> Date: Thu, 03 May 2012 17:42:10 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-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, 04 May 2012 00:42:11 -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 : Multicast Extensions to DS-Lite Technique in Broadband D= eployments Author(s) : Jacni Qin Mohamed Boucadair Christian Jacquenet Yiu L. Lee Qian Wang Filename : draft-ietf-softwire-dslite-multicast-02.txt Pages : 20 Date : 2012-05-03 This document specifies a solution for the delivery of multicast service offerings to DS-Lite serviced customers. The proposed solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic over an IPv6 multicast-enabled network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-multicast-02= .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-multicast-02.= txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ From jacni@jacni.com Thu May 3 19:03:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE2C21F85FB for ; Thu, 3 May 2012 19:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuhG0c-r+AoT for ; Thu, 3 May 2012 19:03:20 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id C315521F85D1 for ; Thu, 3 May 2012 19:03:20 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 6D5133800B6 for ; Thu, 3 May 2012 22:03:18 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id D0ABC3400F8 for ; Fri, 4 May 2012 10:03:16 +0800 (CST) Received: from [10.140.20.30] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJD7L43iOKNPqSjjAA--.6852S2; Fri, 04 May 2012 10:03:16 +0800 (CST) Message-ID: <4FA338E1.7060301@jacni.com> Date: Fri, 04 May 2012 10:03:13 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <4FA21D44.400@jacni.com> <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> <4FA2310F.6020900@jacni.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040701080806030408080107" X-CM-TRANSID: +AWowJD7L43iOKNPqSjjAA--.6852S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Kw48WryfGw47Cry3JF47Arb_yoW8JFy3pF 48Gw1fJFn3Gw4Ikr95Zws8A34UCw4fW3y5Jw1rK3yxC3s3KFy0qw1Ut3WjkF98Xr1kJFWY qw4qyF1fG3sYvFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07j6wZcUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQECEko7lQ2zUwAts0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 04 May 2012 02:03:21 -0000 This is a multi-part message in MIME format. --------------040701080806030408080107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Ole, On 5/3/2012 Thursday 4:38 PM, Ole Tran wrote: > Jacni, > >>>>> My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. >>> would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice? >>> >> I'd rather prefer you pick one only. > wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive. We put the requirements on the table and some discussions, but sorry, I can't remember what exactly the consensus/conclusion is, and I'm confused about where we are. I see, maybe I'm wrong, the technical requirements are drawn more from the two incompatible solutions after, but not from the conversion/analysis of the statements in "motivation", then we got the mutually exclusive ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ... Anyway, if generally we have a single target or design goal, IMHO, it's really a bad idea to keep parallel two, no matter we call them requirements/solutions, whatever. Cheers, Jacni > cheers, > Ole > > > --------------040701080806030408080107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ole,

On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote: 
Jacni,


My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible.

would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice?


I'd rather prefer you pick one only.

wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive.
We put the requirements on the table and some discussions, but sorry, I can't remember what exactly the consensus/conclusion is, and I'm confused about where we are.

I see, maybe I'm wrong, the technical requirements are drawn more from the two incompatible solutions after, but not from the conversion/analysis of the statements in "motivation", then we got the mutually exclusive ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ...

Anyway, if generally we have a single target or design goal, IMHO, it's really a bad idea to keep parallel two, no matter we call them requirements/solutions, whatever.


Cheers,
Jacni
cheers,
Ole
--------------040701080806030408080107-- From leaf.y.yeh@huawei.com Fri May 4 03:11:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E149F21F85BD for ; Fri, 4 May 2012 03:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCLMEGED4XQA for ; Fri, 4 May 2012 03:11:52 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4B021F85B7 for ; Fri, 4 May 2012 03:11:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFN03515; Fri, 04 May 2012 06:11:51 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 03:08:41 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 03:08:38 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.168]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 4 May 2012 18:08:33 +0800 From: Leaf yeh To: Jacni Qin , =?utf-8?B?T2xlIFRyw7hhbg==?= Thread-Topic: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward Thread-Index: AQHNKZpKETfQE+arR0OKrlBe93IxvJa5Wwrw Date: Fri, 4 May 2012 10:08:32 +0000 Message-ID: References: <4FA21D44.400@jacni.com> <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> <4FA2310F.6020900@jacni.com> <4FA338E1.7060301@jacni.com> In-Reply-To: <4FA338E1.7060301@jacni.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.39.132] Content-Type: multipart/alternative; boundary="_000_E1CE3E6E6D4E1C438B0ADC9FFFA345EA262DB9A6SZXEML510MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 04 May 2012 10:11:53 -0000 --_000_E1CE3E6E6D4E1C438B0ADC9FFFA345EA262DB9A6SZXEML510MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFjbmkgLSBBbnl3YXksIGlmIGdlbmVyYWxseSB3ZSBoYXZlIGEgc2luZ2xlIHRhcmdldCBvciBk ZXNpZ24gZ29hbCzigKYNCg0KVGhlcmUgYXJlIG1hbnkgZGVzaWduIGdvYWxzIGhlcmUuIFdoYXQg T2xlIHNhaWQgaW4gdGhpcyBlbWFpbCBpcyB0aGUgc29sdXRpb24gb2YgRW5jYXBzdWxhdGlvbiAm IFRyYW5zbGF0aW9uIHdpbGwgbWVldCB0aGUgZGlmZmVyZW50IG9uZXMsIHdoaWNoIHNvdW5kcyBt dXR1YWxseSBleGNsdXNpdmUuIFdpbGwgeW91IGdvIGZvciB0aGUgZnVydGhlciBjbGFyaWZpY2F0 aW9uIG9yIGRpc2N1c3Npb24gb24gaXQgaGVyZT8NCg0KSSB3b3VsZCBiZSBvcGVuIHRvIGFjY2Vw dCB0aGVzZSAyIHNvbHV0aW9ucywgd2hpY2ggc2hhcmUgcGFydCBvZiB0aGUgc2FtZSBhZGRyZXNz IGZvcm1hdC4gQW5kIGxldCB0aGUgb3BlcmF0b3IgZ2V0IHRoZSByaWdodCB0byBwaWNrIG9uZSBo ZSBiZWxpZXZlIGl0IGlzIGZlYXNpYmxlICYgc3VpdGFibGUsIG9yIGV2ZW4gbm90IHBpY2sgYW55 IG9mIHRoZXNlIHNvbHV0aW9uLg0KDQoNCkJlc3QgUmVnYXJkcywNCkxlYWYNCg0KDQoNCkZyb206 IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBKYWNuaSBRaW4NClNlbnQ6IEZyaWRheSwgTWF5IDA0LCAyMDEy IDEwOjAzIEFNDQpUbzogT2xlIFRyw7hhbg0KQ2M6IHNvZnR3aXJlc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtTb2Z0d2lyZXNdIFJlc3VsdCBmcm9tIHRoZSBjb25zZW5zdXMgY2FsbCBvbiBNYXAg dnMgNHJkLVUgYW5kIG9mZmljaWFsIHdheSBmb3J3YXJkDQoNCk9sZSwNCg0KT24gNS8zLzIwMTIg VGh1cnNkYXkgNDozOCBQTSwgT2xlIFRyw7hhbiB3cm90ZToNCg0KSmFjbmksDQoNCg0KDQpNeSBj b25jZXJuIGlzIE1BUCBpc24ndCBhIHNpbmdsZSBzb2x1dGlvbi4gT3BlcmF0b3JzIHN0aWxsIG5l ZWQgdG8gbWFrZSBhIGNob2ljZSBiZXR3ZWVuIEUgYW5kIFQgYmVjYXVzZSB0aGV5IGFyZSBub3Qg Y29tcGF0aWJsZS4NCg0KDQoNCndvdWxkIGl0IGFsbGV2aWF0ZSB5b3VyIGNvbmNlcm5zIGlmIHRo ZSBkb2N1bWVudHMgaGFkIE1VU1RzIGZvciBib3RoPyBpLmUuIGluY3JlYXNpbmcgdGhlIHByb2Jh YmlsaXR5IHRoYXQgYW4gaW1wbGVtZW50YXRpb24gc3VwcG9ydGVkIGJvdGgsIGFuZCBtYWtpbmcg dGhpcyBwdXJlbHkgaW50byBhbiBvcGVyYXRpb25hbCBjaG9pY2U/DQoNCg0KDQpJJ2QgcmF0aGVy IHByZWZlciB5b3UgcGljayBvbmUgb25seS4NCg0KDQoNCndvdWxkbid0IHdlIGFsbC4gSSB0aGlu ayB5b3UncmUgZmxvZ2dpbmcgYSBkZWFkIGhvcnNlLiBsZXQgdXMgYWNjZXB0IHRoYXQgdGhlIHJl cXVpcmVtZW50cyBmb3IgdHJhbnNsYXRpb24gYW5kIHRoZSByZXF1aXJlbWVudHMgZm9yIGVuY2Fw c3VsYXRpb24gYXJlIG11dHVhbGx5IGV4Y2x1c2l2ZS4NCldlIHB1dCB0aGUgcmVxdWlyZW1lbnRz IG9uIHRoZSB0YWJsZSBhbmQgc29tZSBkaXNjdXNzaW9ucywgYnV0IHNvcnJ5LCBJIGNhbid0IHJl bWVtYmVyIHdoYXQgZXhhY3RseSB0aGUgY29uc2Vuc3VzL2NvbmNsdXNpb24gaXMsIGFuZCBJJ20g Y29uZnVzZWQgYWJvdXQgd2hlcmUgd2UgYXJlLg0KDQpJIHNlZSwgbWF5YmUgSSdtIHdyb25nLCB0 aGUgdGVjaG5pY2FsIHJlcXVpcmVtZW50cyBhcmUgZHJhd24gbW9yZSBmcm9tIHRoZSB0d28gaW5j b21wYXRpYmxlIHNvbHV0aW9ucyBhZnRlciwgYnV0IG5vdCBmcm9tIHRoZSBjb252ZXJzaW9uL2Fu YWx5c2lzIG9mIHRoZSBzdGF0ZW1lbnRzIGluICJtb3RpdmF0aW9uIiwgdGhlbiB3ZSBnb3QgdGhl IG11dHVhbGx5IGV4Y2x1c2l2ZSBvbmVzIHlvdSBtZW50aW9uZWQgYWJvdmUuIEhvdyBjYW4gd2Ug ZmlndXJlIG91dCB0aGUgd2F5IHRvIG1vdmUgZm9yd2FyZD8gSnVzdCBieSBzb21lIE1VU1RzL01B WXMgLi4uDQoNCkFueXdheSwgaWYgZ2VuZXJhbGx5IHdlIGhhdmUgYSBzaW5nbGUgdGFyZ2V0IG9y IGRlc2lnbiBnb2FsLCBJTUhPLCBpdCdzIHJlYWxseSBhIGJhZCBpZGVhIHRvIGtlZXAgcGFyYWxs ZWwgdHdvLCBubyBtYXR0ZXIgd2UgY2FsbCB0aGVtIHJlcXVpcmVtZW50cy9zb2x1dGlvbnMsIHdo YXRldmVyLg0KDQoNCkNoZWVycywNCkphY25pDQoNCg0KDQoNCmNoZWVycywNCg0KT2xlDQoNCg0K DQoNCg0KDQo= --_000_E1CE3E6E6D4E1C438B0ADC9FFFA345EA262DB9A6SZXEML510MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWN juaWh+e7hum7kTsNCglwYW5vc2UtMToyIDEgNiAwIDQgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5Y2O5paH57uG6buRIjsNCglwYW5vc2Ut MToyIDEgNiAwIDQgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkJvb2sg QW50aXF1YSI7DQoJcGFub3NlLTE6MiA0IDYgMiA1IDMgNSAzIDMgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5KYWNuaSAtIDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+QW55d2F5LCBpZiBnZW5lcmFsbHkgd2UgaGF2ZSBhIHNpbmdsZSB0YXJnZXQgb3IgZGVz aWduIGdvYWwsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj7igKY8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIG1hbnkgZGVzaWduIGdvYWxzIGhlcmUu IFdoYXQgT2xlIHNhaWQgaW4gdGhpcyBlbWFpbCBpcyB0aGUgc29sdXRpb24gb2YgRW5jYXBzdWxh dGlvbiAmYW1wOyBUcmFuc2xhdGlvbiB3aWxsIG1lZXQgdGhlIGRpZmZlcmVudCBvbmVzLCB3aGlj aA0KIHNvdW5kcyBtdXR1YWxseSBleGNsdXNpdmUuIFdpbGwgeW91IGdvIGZvciB0aGUgZnVydGhl ciBjbGFyaWZpY2F0aW9uIG9yIGRpc2N1c3Npb24gb24gaXQgaGVyZT8NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGJlIG9wZW4gdG8gYWNjZXB0IHRoZXNlIDIg c29sdXRpb25zLCB3aGljaCBzaGFyZSBwYXJ0IG9mIHRoZSBzYW1lIGFkZHJlc3MgZm9ybWF0LiBB bmQgbGV0IHRoZSBvcGVyYXRvciBnZXQgdGhlIHJpZ2h0IHRvIHBpY2sgb25lIGhlIGJlbGlldmUN CiBpdCBpcyBmZWFzaWJsZSAmYW1wOyBzdWl0YWJsZSwgb3IgZXZlbiBub3QgcGljayBhbnkgb2Yg dGhlc2Ugc29sdXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0Jvb2sgQW50aXF1YSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3Qg UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Qm9vayBBbnRpcXVhJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxlYWY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h bGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrljY7mlofnu4bpu5EiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFwaCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBzb2Z0d2lyZXMtYm91bmNl c0BpZXRmLm9yZw0KIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJl aGFsZiBPZiA8L2I+SmFjbmkgUWluPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDA0LCAy MDEyIDEwOjAzIEFNPGJyPg0KPGI+VG86PC9iPiBPbGUgVHLDuGFuPGJyPg0KPGI+Q2M6PC9iPiBz b2Z0d2lyZXNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTb2Z0d2lyZXNdIFJl c3VsdCBmcm9tIHRoZSBjb25zZW5zdXMgY2FsbCBvbiBNYXAgdnMgNHJkLVUgYW5kIG9mZmljaWFs IHdheSBmb3J3YXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T2xl LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KT24gNS8zLzIwMTIgVGh1cnNk YXkgNDozOCBQTSwgT2xlIFRyw7hhbiB3cm90ZTogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+SmFjbmksPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+TXkgY29uY2VybiBpcyBNQVAgaXNuJ3QgYSBzaW5n bGUgc29sdXRpb24uIE9wZXJhdG9ycyBzdGlsbCBuZWVkIHRvIG1ha2UgYSBjaG9pY2UgYmV0d2Vl biBFIGFuZCBUIGJlY2F1c2UgdGhleSBhcmUgbm90IGNvbXBhdGlibGUuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPndvdWxkIGl0IGFsbGV2aWF0ZSB5b3VyIGNvbmNlcm5zIGlmIHRoZSBkb2N1bWVudHMg aGFkIE1VU1RzIGZvciBib3RoPyBpLmUuIGluY3JlYXNpbmcgdGhlIHByb2JhYmlsaXR5IHRoYXQg YW4gaW1wbGVtZW50YXRpb24gc3VwcG9ydGVkIGJvdGgsIGFuZCBtYWtpbmcgdGhpcyBwdXJlbHkg aW50byBhbiBvcGVyYXRpb25hbCBjaG9pY2U/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkknZCByYXRoZXIgcHJlZmVyIHlvdSBw aWNrIG9uZSBvbmx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOLVVTIj53b3VsZG4ndCB3ZSBhbGwuIEkgdGhpbmsgeW91J3JlIGZsb2dn aW5nIGEgZGVhZCBob3JzZS4gbGV0IHVzIGFjY2VwdCB0aGF0IHRoZSByZXF1aXJlbWVudHMgZm9y IHRyYW5zbGF0aW9uIGFuZCB0aGUgcmVxdWlyZW1lbnRzIGZvciBlbmNhcHN1bGF0aW9uIGFyZSBt dXR1YWxseSBleGNsdXNpdmUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2UgcHV0IHRoZSByZXF1aXJlbWVudHMgb24gdGhl IHRhYmxlIGFuZCBzb21lIGRpc2N1c3Npb25zLCBidXQgc29ycnksIEkgY2FuJ3QgcmVtZW1iZXIg d2hhdCBleGFjdGx5IHRoZSBjb25zZW5zdXMvY29uY2x1c2lvbiBpcywgYW5kIEknbSBjb25mdXNl ZCBhYm91dCB3aGVyZSB3ZSBhcmUuPGJyPg0KPGJyPg0KSSBzZWUsIG1heWJlIEknbSB3cm9uZywg dGhlIHRlY2huaWNhbCByZXF1aXJlbWVudHMgYXJlIGRyYXduIG1vcmUgZnJvbSB0aGUgdHdvIGlu Y29tcGF0aWJsZSBzb2x1dGlvbnMgYWZ0ZXIsIGJ1dCBub3QgZnJvbSB0aGUgY29udmVyc2lvbi9h bmFseXNpcyBvZiB0aGUgc3RhdGVtZW50cyBpbiAmcXVvdDttb3RpdmF0aW9uJnF1b3Q7LCB0aGVu IHdlIGdvdCB0aGUgbXV0dWFsbHkgZXhjbHVzaXZlIG9uZXMgeW91IG1lbnRpb25lZCBhYm92ZS4g SG93IGNhbiB3ZSBmaWd1cmUNCiBvdXQgdGhlIHdheSB0byBtb3ZlIGZvcndhcmQ/IEp1c3QgYnkg c29tZSBNVVNUcy9NQVlzIC4uLjxicj4NCjxicj4NCkFueXdheSwgaWYgZ2VuZXJhbGx5IHdlIGhh dmUgYSBzaW5nbGUgdGFyZ2V0IG9yIGRlc2lnbiBnb2FsLCBJTUhPLCBpdCdzIHJlYWxseSBhIGJh ZCBpZGVhIHRvIGtlZXAgcGFyYWxsZWwgdHdvLCBubyBtYXR0ZXIgd2UgY2FsbCB0aGVtIHJlcXVp cmVtZW50cy9zb2x1dGlvbnMsIHdoYXRldmVyLg0KPGJyPg0KPGJyPg0KPGJyPg0KQ2hlZXJzLDxi cj4NCkphY25pPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5jaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIj5PbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_E1CE3E6E6D4E1C438B0ADC9FFFA345EA262DB9A6SZXEML510MBSchi_-- From despres.remi@laposte.net Fri May 4 05:56:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A389221F85C0 for ; Fri, 4 May 2012 05:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXH1B1Na+xDh for ; Fri, 4 May 2012 05:56:05 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5F721F8587 for ; Fri, 4 May 2012 05:56:03 -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 DFD909400F3; Fri, 4 May 2012 14:55:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-99--800814717 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 4 May 2012 14:55:54 +0200 Message-Id: References: <4FA21D44.400@jacni.com> <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> <4FA2310F.6020900@jacni.com> <4FA338E1.7060301@jacni.com> To: Leaf yeh X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 04 May 2012 12:56:12 -0000 --Apple-Mail-99--800814717 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-05-04 =E0 12:08, Leaf yeh a =E9crit : > Jacni - Anyway, if generally we have a single target or design goal,=85 > =20 > There are many design goals here. What Ole said in this email is the = solution of Encapsulation & Translation will meet the different ones, = which sounds mutually exclusive. Will you go for the further = clarification or discussion on it here? > =20 > I would be open to accept these 2 solutions, which share part of the = same address format. And let the operator get the right to pick one he = believe it is feasible & suitable, or even not pick any of these = solution. Would you agree, though, that if a solution is confirmed to cover design = goals of both Encapsulation and Translation, it would better meet the WG = objective objective to have a single standard?=20 (Operators would be relieved from having to make a choice.) Regards, RD > Best Regards, > Leaf > =20 > =20 > =20 > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Jacni Qin > Sent: Friday, May 04, 2012 10:03 AM > To: Ole Tr=F8an > Cc: softwires@ietf.org > Subject: Re: [Softwires] Result from the consensus call on Map vs = 4rd-U and official way forward > =20 > Ole, >=20 > On 5/3/2012 Thursday 4:38 PM, Ole Tr=F8an wrote: > Jacni, > =20 > My concern is MAP isn't a single solution. Operators still need to = make a choice between E and T because they are not compatible. > =20 > would it alleviate your concerns if the documents had MUSTs for both? = i.e. increasing the probability that an implementation supported both, = and making this purely into an operational choice? > =20 > I'd rather prefer you pick one only. > =20 > wouldn't we all. I think you're flogging a dead horse. let us accept = that the requirements for translation and the requirements for = encapsulation are mutually exclusive. > We put the requirements on the table and some discussions, but sorry, = I can't remember what exactly the consensus/conclusion is, and I'm = confused about where we are. >=20 > I see, maybe I'm wrong, the technical requirements are drawn more from = the two incompatible solutions after, but not from the = conversion/analysis of the statements in "motivation", then we got the = mutually exclusive ones you mentioned above. How can we figure out the = way to move forward? Just by some MUSTs/MAYs ... >=20 > Anyway, if generally we have a single target or design goal, IMHO, = it's really a bad idea to keep parallel two, no matter we call them = requirements/solutions, whatever. >=20 >=20 > Cheers, > Jacni >=20 > =20 > cheers, > Ole > =20 > =20 > =20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-99--800814717 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Jacni - Anyway, if generally we have a single target or design = goal,=E2=80=A6
There are many design goals here. What = Ole said in this email is the solution of Encapsulation & = Translation will meet the different ones, which sounds mutually = exclusive. Will you go for the further clarification or discussion on it = here?
 
I = would be open to accept these 2 solutions, which share part of the same = address format. And let the operator get the right to pick one he = believe it is feasible & suitable, or even not pick any of these = solution.

Would= you agree, though, that if a solution is confirmed to cover design = goals of both Encapsulation and Translation, it would better meet the WG = objective objective to have a single = standard? 
(Operators would be relieved from having to = make a = choice.)

Regards,
RD



Leaf
 
 softwires-bounces@ietf.org [mailto:softwires-bounces@iet= f.org] On Behalf = Of Jacni = Qin
Sent: Friday, May 04, 2012 10:03 = AM
To: Ole = Tr=C3=B8an
Cc:  Re: [Softwires] Result from = the consensus call on Map vs 4rd-U and official way = forward
Jacni,
 
My concern is MAP isn't a single solution. Operators =
still need to make a choice between E and T because they are not =
compatible.
 
would it alleviate your concerns if =
the documents had MUSTs for both? i.e. increasing the probability that =
an implementation supported both, and making this purely into an =
operational choice?
 
I'd rather prefer you pick one =
only.
 
wouldn't we all. I think you're flogging a dead horse. =
let us accept that the requirements for translation and the requirements =
for encapsulation are mutually exclusive.
 
cheers,
Ole
 
 
 
_______________________= ________________________
Softwires mailing list
Softwires@ietf.org
Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 04 May 2012 16:18:23 -0000 --_000_51C6E1D4EC1B4D9D8DBD1021D720FA53mimectl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Remi - Would you agree, though, that if a solution is confirmed to cover de= sign goals of both Encapsulation and Translation, it would better meet the = WG objective objective to have a single standard? (Operators would be reli= eved from having to make a choice.) That sounds great if the solution (eg. 4rd-U) is confirmedly feasible and e= xtensively accepted by the group. Right? Best Regards, Leaf ________________________________ From: R=E9mi Despr=E9s [despres.remi@laposte.net] Sent: Friday, May 04, 2012 20:55 To: Leaf yeh Cc: Jacni Qin; Ole Tr=F8an; softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and= official way forward Le 2012-05-04 =E0 12:08, Leaf yeh a =E9crit : Jacni - Anyway, if generally we have a single target or design goal,=85 There are many design goals here. What Ole said in this email is the soluti= on of Encapsulation & Translation will meet the different ones, which sound= s mutually exclusive. Will you go for the further clarification or discussi= on on it here? I would be open to accept these 2 solutions, which share part of the same a= ddress format. And let the operator get the right to pick one he believe it= is feasible & suitable, or even not pick any of these solution. Would you agree, though, that if a solution is confirmed to cover design go= als of both Encapsulation and Translation, it would better meet the WG obje= ctive objective to have a single standard? (Operators would be relieved from having to make a choice.) Regards, RD Best Regards, Leaf From: softwires-bounces@ietf.org [mailto= :softwires-bounces@ietf.org] On Behalf Of Jacni Qin Sent: Friday, May 04, 2012 10:03 AM To: Ole Tr=F8an Cc: softwires@ietf.org Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and= official way forward Ole, On 5/3/2012 Thursday 4:38 PM, Ole Tr=F8an wrote: Jacni, My concern is MAP isn't a single solution. Operators still need to make a c= hoice between E and T because they are not compatible. would it alleviate your concerns if the documents had MUSTs for both? i.e. = increasing the probability that an implementation supported both, and makin= g this purely into an operational choice? I'd rather prefer you pick one only. wouldn't we all. I think you're flogging a dead horse. let us accept that t= he requirements for translation and the requirements for encapsulation are = mutually exclusive. We put the requirements on the table and some discussions, but sorry, I can= 't remember what exactly the consensus/conclusion is, and I'm confused abou= t where we are. I see, maybe I'm wrong, the technical requirements are drawn more from the = two incompatible solutions after, but not from the conversion/analysis of t= he statements in "motivation", then we got the mutually exclusive ones you = mentioned above. How can we figure out the way to move forward? Just by som= e MUSTs/MAYs ... Anyway, if generally we have a single target or design goal, IMHO, it's rea= lly a bad idea to keep parallel two, no matter we call them requirements/so= lutions, whatever. Cheers, Jacni cheers, Ole _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_51C6E1D4EC1B4D9D8DBD1021D720FA53mimectl_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2C2E30FFC44F624FA8B3EF282FE0D1BE@huawei.com> Content-Transfer-Encoding: quoted-printable

Remi - Would you agree, though, that if a solution is confirmed to cover= design goals of both Encapsulation and Translation, it would better meet t= he WG objective objective to have a single standard?  (Operators would= be relieved from having to make a choice.)

 

That sounds great if the solution (eg. 4rd-U) is confirmedly feasib= le and extensively accepted by the group. Right?

 

 

Best Regards,

Leaf

 

 

From: R=E9mi Despr=E9s [despres.remi@lapos= te.net]
Sent: Friday, May 04, 2012 20:55
To: Leaf yeh
Cc: Jacni Qin; Ole Tr=F8an; softwires@ietf.org
Subject: Re: [Softwires] Result from the consensus call on Map vs 4r= d-U and official way forward


Le 2012-05-04 =E0 12:08, Leaf yeh a =E9crit :

Jacni - Anyway, if generally we have a single targe= t or design goal,=85
 
There are many design goals here. What Ole = said in this email is the solution of Encapsulation & Translation will = meet the different ones, which sounds mutually exclusive. Will you go for the further clarification or discussion on it h= ere?
 
I would be open to accept these 2 solutions= , which share part of the same address format. And let the operator get the= right to pick one he believe it is feasible & suitable, or even not pick any of these solution.

Would you agree, though, that if a solution is confirmed to cover design go= als of both Encapsulation and Translation, it would better meet the WG obje= ctive objective to have a single standard? 
(Operators would be relieved from having to make a choice.)

Regards,
RD



Best Regards,
Leaf
 
 
 
 
Ole,<= span lang=3D"EN-US">

On 5/3/2012 Thursday 4:38 PM, Ole Tr=F8an wrote:
Jacni,
 
My concern is MAP isn't a single so=
lution. Operators still need to make a choice between E and T because they =
are not compatible.
 
would it alleviate your concerns if=
 the documents had MUSTs for both? i.e. increasing the probability that an =
implementation supported both, and making this purely into an operational c=
hoice?
 
I'd rather prefer you pick one only=
.
 
wouldn't we all. I think you're flo=
gging a dead horse. let us accept that the requirements for translation and=
 the requirements for encapsulation are mutually exclusive.
We put the requirements on the table and some discussi= ons, but sorry, I can't remember what exactly the consensus/conclusion is, = and I'm confused about where we are.

I see, maybe I'm wrong, the technical requirements are drawn more from the = two incompatible solutions after, but not from the conversion/analysis of t= he statements in "motivation", then we got the mutually exclusive= ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ...

Anyway, if generally we have a single target or design goal, IMHO, it's rea= lly a bad idea to keep parallel two, no matter we call them requirements/so= lutions, whatever.


Cheers,
Jacni

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

--_000_51C6E1D4EC1B4D9D8DBD1021D720FA53mimectl_-- From Tina.Tsou.Zouting@huawei.com Fri May 4 09:55:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B86B21F8638 for ; Fri, 4 May 2012 09:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2fbjtGOT-fA for ; Fri, 4 May 2012 09:55:48 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A565121F8637 for ; Fri, 4 May 2012 09:55:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFV28815; Fri, 04 May 2012 12:55:46 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 09:53:47 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 09:53:44 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.48]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Sat, 5 May 2012 00:53:40 +0800 From: Tina TSOU To: "wdec.ietf@gmail.com" Thread-Topic: WT-146 and draft-tsou-softwire-bfd-ds-lite-02 Thread-Index: AQHNKgsswgjcTJqB80Gt5GOxG5B/cpa52Jmw Date: Fri, 4 May 2012 16:53:40 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.51] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A80C9B702Dszxeml526mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Org Softwires@Ietf. \(softwires@ietf.org\)" Subject: [Softwires] WT-146 and draft-tsou-softwire-bfd-ds-lite-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, 04 May 2012 16:55:49 -0000 --_000_C0E0A32284495243BDE0AC8A066631A80C9B702Dszxeml526mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In WT-146, why is there only BFD, no PING? Sent from my iPad --_000_C0E0A32284495243BDE0AC8A066631A80C9B702Dszxeml526mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In WT-146, why is there only BFD, no PING?

Sent from my iPad

--_000_C0E0A32284495243BDE0AC8A066631A80C9B702Dszxeml526mbschi_-- From despres.remi@laposte.net Fri May 4 09:59:01 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064BA21F85BD for ; Fri, 4 May 2012 09:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb20E0fqP2IG for ; Fri, 4 May 2012 09:59:00 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A4521F8483 for ; Fri, 4 May 2012 09:58:57 -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 8F0A69401A6; Fri, 4 May 2012 18:58:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-101--786242050 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <51C6E1D4-EC1B-4D9D-8DBD-1021D720FA53@mimectl> Date: Fri, 4 May 2012 18:58:46 +0200 Message-Id: References: <4FA21D44.400@jacni.com> <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> <4FA2310F.6020900@jacni.com> <4FA338E1.7060301@jacni.com> <51C6E1D4-EC1B-4D9D-8DBD-1021D720FA53@mimectl> To: Leaf yeh X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 04 May 2012 16:59:01 -0000 --Apple-Mail-101--786242050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 2012-05-04 18:16, Leaf yeh: > Remi - Would you agree, though, that if a solution is confirmed to = cover design goals of both Encapsulation and Translation, it would = better meet the WG objective objective to have a single standard? = (Operators would be relieved from having to make a choice.) > =20 > That sounds great if the solution (eg. 4rd-U) is confirmedly feasible Yes, feasibility is clearly a decisive criterion. (Not forgetting that feasibility of MAP-T+E, with all what there is in = the specification without having be tested before, has also to be = confirmed.) > and extensively accepted by the group. Right? That's the purpose of this question: will standard unicity be confirmed = by the WG an important criterion? If you agree, we can resume this discussion when all specifications are = available. Kind regards, RD > =20 > =20 > Best Regards, > Leaf > =20 > =20 > From: R=E9mi Despr=E9s [despres.remi@laposte.net] > Sent: Friday, May 04, 2012 20:55 > To: Leaf yeh > Cc: Jacni Qin; Ole Tr=F8an; softwires@ietf.org > Subject: Re: [Softwires] Result from the consensus call on Map vs = 4rd-U and official way forward >=20 >=20 > Le 2012-05-04 =E0 12:08, Leaf yeh a =E9crit : >=20 >> Jacni - Anyway, if generally we have a single target or design goal,=85= >> =20 >> There are many design goals here. What Ole said in this email is the = solution of Encapsulation & Translation will meet the different ones, = which sounds mutually exclusive. Will you go for the further = clarification or discussion on it here? >> =20 >> I would be open to accept these 2 solutions, which share part of the = same address format. And let the operator get the right to pick one he = believe it is feasible & suitable, or even not pick any of these = solution. >=20 > Would you agree, though, that if a solution is confirmed to cover = design goals of both Encapsulation and Translation, it would better meet = the WG objective objective to have a single standard?=20 > (Operators would be relieved from having to make a choice.) >=20 > Regards, > RD >=20 >=20 >=20 >> Best Regards, >> Leaf >> =20 >> =20 >> =20 >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Jacni Qin >> Sent: Friday, May 04, 2012 10:03 AM >> To: Ole Tr=F8an >> Cc: softwires@ietf.org >> Subject: Re: [Softwires] Result from the consensus call on Map vs = 4rd-U and official way forward >> =20 >> Ole, >>=20 >> On 5/3/2012 Thursday 4:38 PM, Ole Tr=F8an wrote: >> Jacni, >> =20 >> My concern is MAP isn't a single solution. Operators still need to = make a choice between E and T because they are not compatible. >> =20 >> would it alleviate your concerns if the documents had MUSTs for both? = i.e. increasing the probability that an implementation supported both, = and making this purely into an operational choice? >> =20 >> I'd rather prefer you pick one only. >> =20 >> wouldn't we all. I think you're flogging a dead horse. let us accept = that the requirements for translation and the requirements for = encapsulation are mutually exclusive. >> We put the requirements on the table and some discussions, but sorry, = I can't remember what exactly the consensus/conclusion is, and I'm = confused about where we are. >>=20 >> I see, maybe I'm wrong, the technical requirements are drawn more = from the two incompatible solutions after, but not from the = conversion/analysis of the statements in "motivation", then we got the = mutually exclusive ones you mentioned above. How can we figure out the = way to move forward? Just by some MUSTs/MAYs ... >>=20 >> Anyway, if generally we have a single target or design goal, IMHO, = it's really a bad idea to keep parallel two, no matter we call them = requirements/solutions, whatever. >>=20 >>=20 >> Cheers, >> Jacni >>=20 >> =20 >> cheers, >> Ole >> =20 >> =20 >> =20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-101--786242050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
 

That sounds great if the = solution (eg. 4rd-U) is confirmedly = feasible

Yes, = feasibility is clearly  a decisive criterion.
(Not = forgetting that feasibility of MAP-T+E, with all what there is in the = specification without having be tested before, has also to be = confirmed.)

Best = Regards,

From: R=C3=A9mi Despr=C3=A9s = [despres.remi@laposte.net]
Sent: Friday, May 04, 2012 = 20:55
To: Leaf= yeh
Cc: Jacni= Qin; Ole Tr=C3=B8an; softwires@ietf.org
Subject: Re: [Softwires] = Result from the consensus call on Map vs 4rd-U and official way = forward


Le 2012-05-04 = =C3=A0 12:08, Leaf yeh a =C3=A9crit :

Jacni - Anyway, if generally we have a single target or design = goal,=E2=80=A6
 
There are = many design goals here. What Ole said in this email is the solution of = Encapsulation & Translation will meet the different ones, which = sounds mutually exclusive. Will you go for the further clarification or = discussion on it here?
 
I would = be open to accept these 2 solutions, which share part of the same = address format. And let the operator get the right to pick one he = believe it is feasible & suitable, or even not pick any of these = solution.

Would= you agree, though, that if a solution is confirmed to cover design = goals of both Encapsulation and Translation, it would better meet the WG = objective objective to have a single = standard? 
(Operators would be relieved from having to = make a = choice.)

Regards,
RD



Best = Regards,
Leaf
 
 
 
Jacni,
 
My concern is MAP isn't a =
single solution. Operators still need to make a choice between E and T =
because they are not =
compatible.
 
would it alleviate your concerns if the documents had =
MUSTs for both? i.e. increasing the probability that an implementation =
supported both, and making this purely into an operational =
choice?
 
I'd rather prefer you pick one =
only.
 
wouldn't we all. I think you're flogging a dead horse. =
let us accept that the requirements for translation and the requirements =
for encapsulation are mutually exclusive.
 
cheers,
Ole
 
 
 
__________________________________= _____________
Softwires mailing list
Softwires@ietf.org

= --Apple-Mail-101--786242050-- From jacni@jacni.com Fri May 4 19:58:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09F321E8029 for ; Fri, 4 May 2012 19:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqLPTTNZwuan for ; Fri, 4 May 2012 19:58:56 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 2D28E21F846D for ; Fri, 4 May 2012 19:58:55 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id DDC72380077 for ; Fri, 4 May 2012 22:58:53 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 51E933400F8 for ; Sat, 5 May 2012 10:58:52 +0800 (CST) Received: from [192.168.1.104] (unknown [58.209.56.106]) by app (Coremail) with SMTP id +AWowJDbuQZrl6RPIPPkAA--.12700S2; Sat, 05 May 2012 10:58:51 +0800 (CST) Message-ID: <4FA49769.4000707@jacni.com> Date: Sat, 05 May 2012 10:58:49 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Leaf yeh References: <4FA21D44.400@jacni.com> <742494B0-B894-4EC2-A935-A8FD7619CE85@employees.org> <4FA2310F.6020900@jacni.com> <4FA338E1.7060301@jacni.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090906050901060603060203" X-CM-TRANSID: +AWowJDbuQZrl6RPIPPkAA--.12700S2 X-Coremail-Antispam: 1UD129KBjvJXoWxuryUKw4kGw43Gr43ZrW8JFb_yoW5WF1kpF 48Gw13AFZ7C3W0yry8Zw1rA3ykAw4S9rZ8Jrs5K3yxA3s8CFy0qw1vq347CFZ8Wr4kJFWY qw4qyry5Gwn5AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU2Cb7Iv0xC_Kw4lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8I cIk0rVWrJVCq3wAqx4xG67k08I80eVW5JVWrJwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4 AK048IF2xKxVWUJVW8JwAqx4xG6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AG zxvEb7x7McIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07j62NNUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQECEko7lQ2zUwBTsK Cc: "softwires@ietf.org" Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 05 May 2012 02:58:57 -0000 This is a multi-part message in MIME format. --------------090906050901060603060203 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I'll be open to accept N solutions, in case of necessity. Of course, operators get the right to pick one, e.g. from DS-Lite, "stateless" like MAPs/4rd .., etc., but it'll be our fault to let them try to pick one from different variables of the "stateless", if there's no sufficient reason. Back to the motivation document, I failed to see the "mutually exclusive" requirements were stated. Have we left it all behind or chosen to miss it, since the mission to prove "stateless" approaches are needed is complete? Ok, let's wait for the output of the design team, while may I again suggest that you consider seriously the mutually exclusive requirements from E & T before moving forward? Cheers, Jacni On 5/4/2012 Friday 6:08 PM, Leaf yeh wrote: > > Jacni - Anyway, if generally we have a single target or design goal,… > > There are many design goals here. What Ole said in this email is the > solution of Encapsulation & Translation will meet the different ones, > which sounds mutually exclusive. Will you go for the further > clarification or discussion on it here? > > I would be open to accept these 2 solutions, which share part of the > same address format. And let the operator get the right to pick one he > believe it is feasible & suitable, or even not pick any of these solution. > > Best Regards, > > Leaf > > *From:*softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > *On Behalf Of *Jacni Qin > *Sent:* Friday, May 04, 2012 10:03 AM > *To:* Ole Trøan > *Cc:* softwires@ietf.org > *Subject:* Re: [Softwires] Result from the consensus call on Map vs > 4rd-U and official way forward > > Ole, > > On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote: > > Jacni, > > > My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible. > > > > would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice? > > > > I'd rather prefer you pick one only. > > > wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive. > > We put the requirements on the table and some discussions, but sorry, > I can't remember what exactly the consensus/conclusion is, and I'm > confused about where we are. > > I see, maybe I'm wrong, the technical requirements are drawn more from > the two incompatible solutions after, but not from the > conversion/analysis of the statements in "motivation", then we got the > mutually exclusive ones you mentioned above. How can we figure out the > way to move forward? Just by some MUSTs/MAYs ... > > Anyway, if generally we have a single target or design goal, IMHO, > it's really a bad idea to keep parallel two, no matter we call them > requirements/solutions, whatever. > > > Cheers, > Jacni > > > cheers, > Ole > > > --------------090906050901060603060203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I'll be open to accept N solutions, in case of necessity.
Of course, operators get the right to pick one, e.g. from DS-Lite, "stateless" like MAPs/4rd .., etc., but it'll be our fault to let them try to pick one from different variables of the "stateless", if there's no sufficient reason.

Back to the motivation document, I failed to see the "mutually exclusive" requirements were stated. Have we left it all behind or chosen to miss it, since the mission to prove "stateless" approaches are needed is complete?

Ok, let's wait for the output of the design team, while may I again suggest that you consider seriously the mutually exclusive requirements from E & T before moving forward?


Cheers,
Jacni

On 5/4/2012 Friday 6:08 PM, Leaf yeh wrote:

Jacni - Anyway, if generally we have a single target or design goal,…

 

There are many design goals here. What Ole said in this email is the solution of Encapsulation & Translation will meet the different ones, which sounds mutually exclusive. Will you go for the further clarification or discussion on it here?

 

I would be open to accept these 2 solutions, which share part of the same address format. And let the operator get the right to pick one he believe it is feasible & suitable, or even not pick any of these solution.

 

 

Best Regards,

Leaf

 

 

 

From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Jacni Qin
Sent: Friday, May 04, 2012 10:03 AM
To: Ole Trøan
Cc: softwires@ietf.org
Subject: Re: [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward

 

Ole,

On 5/3/2012 Thursday 4:38 PM, Ole Trøan wrote: 

Jacni,
 
My concern is MAP isn't a single solution. Operators still need to make a choice between E and T because they are not compatible.
 
would it alleviate your concerns if the documents had MUSTs for both? i.e. increasing the probability that an implementation supported both, and making this purely into an operational choice?
 
I'd rather prefer you pick one only.
 
wouldn't we all. I think you're flogging a dead horse. let us accept that the requirements for translation and the requirements for encapsulation are mutually exclusive.

We put the requirements on the table and some discussions, but sorry, I can't remember what exactly the consensus/conclusion is, and I'm confused about where we are.

I see, maybe I'm wrong, the technical requirements are drawn more from the two incompatible solutions after, but not from the conversion/analysis of the statements in "motivation", then we got the mutually exclusive ones you mentioned above. How can we figure out the way to move forward? Just by some MUSTs/MAYs ...

Anyway, if generally we have a single target or design goal, IMHO, it's really a bad idea to keep parallel two, no matter we call them requirements/solutions, whatever.


Cheers,
Jacni

 
cheers,
Ole
 
 
 
--------------090906050901060603060203-- From Tina.Tsou.Zouting@huawei.com Mon May 7 15:25:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC8121F86B7 for ; Mon, 7 May 2012 15:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29StceBtpgUg for ; Mon, 7 May 2012 15:25:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE5F21F85F2 for ; Mon, 7 May 2012 15:25:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFX32307; Mon, 07 May 2012 18:25:01 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 15:23:30 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 15:23:32 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.48]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 8 May 2012 06:23:27 +0800 From: Tina TSOU To: Wojciech Dec Thread-Topic: WT-146 and draft-tsou-softwire-bfd-ds-lite-02 Thread-Index: AQHNKgsswgjcTJqB80Gt5GOxG5B/cpa98cSAgAD6MXw= Date: Mon, 7 May 2012 22:23:27 +0000 Message-ID: <46C38899-627F-457F-9ABA-92C71A7789CC@huawei.com> References: <774B240D54DAB844B37EE80C2DD8E8BC1D052665@szxeml522-mbx.china.huawei.com> <20120426083807.GA90464@elstar.local> <774B240D54DAB844B37EE80C2DD8E8BC1D05284C@szxeml522-mbx.china.huawei.com> <27D4C696-625B-4845-81E6-11B76C62BB05@huawei.com> <774B240D54DAB844B37EE80C2DD8E8BC1D0805E9@szxeml522-mbs.china.huawei.com> <4E9C1C5B-C571-4BF3-8F7D-7B66E86EAEF5@huawei.com> <774B240D54DAB844B37EE80C2DD8E8BC1D080635@szxeml522-mbs.china.huawei.com> <464B1F67-68AD-454A-96B8-AF2A2CB21884@huawei.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_46C38899627F457F9ABA92C71A7789CChuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] WT-146 and draft-tsou-softwire-bfd-ds-lite-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 22:25:02 -0000 --_000_46C38899627F457F9ABA92C71A7789CChuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank u for ur reply, Woj. Then I think draft-tsou-softwire-bfd-ds-lite-02 is in line with WT-146. Other comments are welcome. Sent from my iPad On May 7, 2012, at 8:28 AM, "Wojciech Dec" > wrote: Hello, PING was there, as a SHOULD option. -Woj. On 4 May 2012 17:32, Tina TSOU > wrote: In WT-146, why is there only BFD, no PING? Sent from my iPad --_000_46C38899627F457F9ABA92C71A7789CChuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank u for ur reply, Woj.
Then I think draft-tsou-softwire-bfd-ds-lite-02 is in line with&n= bsp;WT-146.
Other comments are welcome.

Sent from my iPad

On May 7, 2012, at 8:28 AM, "Wojciech Dec" <wdec.ietf@gmail.com> wrote:

Hello,

PING was there, as a SHOULD option.

-Woj.

On 4 May 2012 17:32, Tina TSOU <Tina= .Tsou.Zouting@huawei.com> wrote:
In WT-146, why is there only BFD, no PING?

Sent from my iPad

--_000_46C38899627F457F9ABA92C71A7789CChuaweicom_-- From Tina.Tsou.Zouting@huawei.com Mon May 7 23:56:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6A221F85D6 for ; Mon, 7 May 2012 23:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjbVbe8PPy9x for ; Mon, 7 May 2012 23:56:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 82E7E21F85E7 for ; Mon, 7 May 2012 23:56:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFX59213; Tue, 08 May 2012 02:56:27 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 23:54:03 -0700 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 May 2012 23:54:05 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.48]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Tue, 8 May 2012 14:53:54 +0800 From: Tina TSOU To: Tina TSOU Thread-Topic: [Softwires] WT-146 and draft-tsou-softwire-bfd-ds-lite-02 Thread-Index: AQHNLOdVdNa5UNZt1ECDyYlCLVoAjg== Date: Tue, 8 May 2012 06:53:53 +0000 Message-ID: References: <774B240D54DAB844B37EE80C2DD8E8BC1D052665@szxeml522-mbx.china.huawei.com> <20120426083807.GA90464@elstar.local> <774B240D54DAB844B37EE80C2DD8E8BC1D05284C@szxeml522-mbx.china.huawei.com> <27D4C696-625B-4845-81E6-11B76C62BB05@huawei.com> <774B240D54DAB844B37EE80C2DD8E8BC1D0805E9@szxeml522-mbs.china.huawei.com> <4E9C1C5B-C571-4BF3-8F7D-7B66E86EAEF5@huawei.com> <774B240D54DAB844B37EE80C2DD8E8BC1D080635@szxeml522-mbs.china.huawei.com> <464B1F67-68AD-454A-96B8-AF2A2CB21884@huawei.com>, , <46C38899-627F-457F-9ABA-92C71A7789CC@huawei.com> In-Reply-To: <46C38899-627F-457F-9ABA-92C71A7789CC@huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D15E1C263F78408E9A3449A0028372A7huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] WT-146 and draft-tsou-softwire-bfd-ds-lite-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 06:56:28 -0000 --_000_D15E1C263F78408E9A3449A0028372A7huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition, http://tools.ietf.org/html/draft-tsou-softwire-bfd-ds-lite-02 = analyses the applicability of some of the keep-alive mechanisms and try to = suggest one for DS-Lite scenario. BFD is a good solution for keep-alive and to trigger failover when a fault = is detected. Compared to PING and other solutions, BFD is simple and suitab= le for implementation by logic (FPGA, ASIC, etc), while usually PING is han= dled by CPU, which may cause a performance problem if there are too many PI= NG packets. BFD can provide more functionalities besides keep-alive, e.g. d= elay, jitter and throughput test, etc. BBF WT-146 also mandate BFD support for IP sessions. Though as Woj said, PI= NG is a SHOULD option. Sent from my iPad On May 7, 2012, at 3:35 PM, "Tina TSOU" > wrote: Thank u for ur reply, Woj. Then I think draft-tsou-softwire-bfd-ds-lite-02 is in line with WT-146. Other comments are welcome. Sent from my iPad On May 7, 2012, at 8:28 AM, "Wojciech Dec" > wrote: Hello, PING was there, as a SHOULD option. -Woj. On 4 May 2012 17:32, Tina TSOU > wrote: In WT-146, why is there only BFD, no PING? Sent from my iPad --_000_D15E1C263F78408E9A3449A0028372A7huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In addition, http://tools= .ietf.org/html/draft-tsou-softwire-bfd-ds-lite-02 analyses the applicability of some of the keep-alive mechanisms and try to suggest = one for DS-Lite scenario.

BFD is a good solution for keep-alive and to trigger f= ailover when a fault is detected. Compared to PING and other solutions, BFD= is simple and suitable for implementation by logic (FPGA, ASIC, etc), while usually PING is handl= ed by CPU, which may cause a performance problem if there are too many PING packets. BFD can provide more functionalities besides keep-a= live, e.g. delay, jitter and throughput test, etc.

BBF WT-146 also mandate BFD support for IP sessions. T= hough as Woj said, PING is a SHOULD option.


Sent from my iPad

On May 7, 2012, at 3:35 PM, "Tina TSOU" <Tina.Tsou.Zouting@huawei.com> wrote:

Thank u for ur reply, Woj.
Then I think draft-tsou-softwire-bfd-ds-lite-02 is in line with&n= bsp;WT-146.
Other comments are welcome.

Sent from my iPad

On May 7, 2012, at 8:28 AM, "Wojciech Dec" <wdec.ietf@gmail.com> wrote:

Hello,

PING was there, as a SHOULD option.

-Woj.

On 4 May 2012 17:32, Tina TSOU <Tina= .Tsou.Zouting@huawei.com> wrote:
In WT-146, why is there only BFD, no PING?

Sent from my iPad

--_000_D15E1C263F78408E9A3449A0028372A7huaweicom_-- From iesg-secretary@ietf.org Tue May 15 10:21:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F10021F88CC; Tue, 15 May 2012 10:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HystFFWBp1jy; Tue, 15 May 2012 10:21:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F35A21F8912; Tue, 15 May 2012 10:21:35 -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: 4.02 Message-ID: <20120515172135.26599.28969.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 10:21:35 -0700 Cc: softwire mailing list , softwire chair , RFC Editor Subject: [Softwires] Protocol Action: 'Gateway Initiated Dual-Stack Lite Deployment' to Proposed Standard (draft-ietf-softwire-gateway-init-ds-lite-08.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, 15 May 2012 17:21:40 -0000 The IESG has approved the following document: - 'Gateway Initiated Dual-Stack Lite Deployment' (draft-ietf-softwire-gateway-init-ds-lite-08.txt) as Proposed Standard This document is the product of the Softwires Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-softwire-gateway-init-ds-lite/ Technical Summary This document specifies a Gateway-Initiated Dual-Stack lite (GI-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. Working Group Summary This document was discussed in depth and well-reviewed. The overall WG consensus is strong to publish this document. As discussed during the first IESG review of IPR disclosure datatracker.ietf.org/ipr/1630, the patent to which the disclosure refers is available, at present, only in Chinese. In response to the IESG discussion, the WG was asked to reconsider and comment on its decision to progress this document. There was no response to the request for discussion. Therefore, the document will be returned to the IETF for review in its current state. Document Quality As far as we know, there are no existing implementations now, but some vendors have plans to implement and release the related product. Personnel Yong Cui is the Document Shepherd. Ralph Droms is the Responsible AD. From internet-drafts@ietf.org Mon May 21 16:40:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F20421F8562; Mon, 21 May 2012 16:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOLfPixkY6nI; Mon, 21 May 2012 16:40:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04D321F853B; Mon, 21 May 2012 16:40:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2012 16:40:47 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 23:40:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : IPv4 Residual Deployment via IPv6 - a unified Stateless = Solution (4rd) Author(s) : Remi Despres Reinaldo Penno Yiu Lee Gang Chen Sheng Jiang Filename : draft-ietf-softwire-4rd-00.txt Pages : 40 Date : 2012-05-16 The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of [RFC6145]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ From fibrib@gmail.com Mon May 21 18:54:46 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2BA21F854A for ; Mon, 21 May 2012 18:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BhdvKlwecwb for ; Mon, 21 May 2012 18:54:45 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DADF021F84B6 for ; Mon, 21 May 2012 18:54:44 -0700 (PDT) Received: by qadz3 with SMTP id z3so2046190qad.10 for ; Mon, 21 May 2012 18:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v6Zs9iGTdd/4W6q/LKKGSmHfK9n15pxMfJkazu4USFY=; b=SzeyDjcq2c3YdCBTAI8qBlDS/eDIHNgfZSCsLmoraNApJzRTny5rt1Wq4Gcd1CCiER c/VsrId6I0uDh1HWgeML3XmTvk7sW5PTYPxo9djDU5GB+hZoscvPMufIA4CaN5Dfm7ml qhAuTDuO3IkbDC5K+ZvdincJ+A8Tlb/gpjAp/39yhSPCfV0t5JJORW0Htc1xRAMEiZ6m +y2g6FZOK39uhxb7qnnj8IqDqE/2ygwjhV+Bthb3Afx6kWepu3b+1NJyQRo3es3Hl7mn 42kgt/PfqeyZF6YiJj98/GZbYOs7Gu/xCEPRH0+Hyh6BZ2DB28clP1DHmJw9QVuoI9vq ftsQ== MIME-Version: 1.0 Received: by 10.224.33.8 with SMTP id f8mr41992062qad.11.1337651684366; Mon, 21 May 2012 18:54:44 -0700 (PDT) Received: by 10.229.238.201 with HTTP; Mon, 21 May 2012 18:54:44 -0700 (PDT) In-Reply-To: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> Date: Tue, 22 May 2012 01:54:44 +0000 Message-ID: From: Maoke To: softwires@ietf.org Content-Type: multipart/alternative; boundary=20cf302074587ad9b604c0964d9b Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 01:54:46 -0000 --20cf302074587ad9b604c0964d9b Content-Type: text/plain; charset=ISO-8859-1 hi Remi and other authors, thanks a lot for updating the draft. semantics review will follow and here i only make an incomprehensive but quick response. please don't hesitate to point out if i misunderstand. i assume that the purpose of 4rd (this 4rd = 4rd-U in the past, conceptually) is still unchanged as it is titled: making a unified solution of encapsulation and translation for ipv4 residual deployment in an ipv6 domain. then i would like to clarify that ... 1. the new draft remains ipv4 header checksum not end-to-end transparent for ICMP and UDP with zero checksum. even though the CNP in address could protect the integrity of addresses, the integrity protection provided by full encapsulation for port number and payload length is still lost. (=> can 4rd be called as a unified solution unifying encapsulation?) 2. end-to-end transparency for TTL=1 and TTL=255 is now protected but other values are not. i doubt this is enough, because neither RFC4271 nor RFC5082 is limited to the case only 1 or 255 is applied for the TTL security mechanism. in practice, eBGP sessions across 1 hop, 2 hops, or several hops are possible and the BGP speaker may not be very next to the CE nor to the BR. we noticed that full encapsulation protect any case of TTL. (=> can 4rd be called as a unified solution unifying encapsulation?) but it is good that the first bit of IPv6 Hop Limit is now not misused. (btw, a minor point of confusion, if TTL_1 = 1, i suppose the IPv6-to-IPv4 translator should make TTL=0 in the resulted packet; if TTL_255 = 1, it must result in TTL=254, right? as the virtual link has been a hop.) 3. TTL=1 and TTL=255 are treated differently may also confuse traceroute. e.g.: A - B - CE --(IPv6 domain)-- BR - C when one do tranceroute at A to C, it will result in: 1 xxx ms xxx ms xxx ms B 2 xxx ms xxx ms xxx ms CE 3 xxx ms xxx ms xxx ms BR 4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain) 5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) . . . N xxx ms xxx ms xxx ms BR (woops, again, is it a routing loop?) N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) don't you think it is strange? the above behavior is neither encapsulation nor translation, then can we call it as a "unification"? thanks a lot for your attention, - maoke 2012/5/21 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Softwires Working Group of > the IETF. > > Title : IPv4 Residual Deployment via IPv6 - a unified > Stateless Solution (4rd) > Author(s) : Remi Despres > Reinaldo Penno > Yiu Lee > Gang Chen > Sheng Jiang > Filename : draft-ietf-softwire-4rd-00.txt > Pages : 40 > Date : 2012-05-16 > > The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment > possible via IPv6 networks without maintaining for this per-customer > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of > 6rd). To cope with the IPv4 address shortage, customers can be > assigned IPv4 addresses with restricted port sets. In some > scenarios, 4rd-capable customer nodes can exchange packets of their > IPv4-only applications via stateful NAT64s that are upgraded to > support 4rd tunnels (in addition to their IP/ICMP translation of > [RFC6145]). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf302074587ad9b604c0964d9b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Remi and other authors,=A0

thanks a lo= t for updating the draft. semantics review will follow and here i only make= an incomprehensive but quick response. please don't hesitate to point = out if i misunderstand.=A0

i assume that the purpose of 4rd (this 4rd =3D 4rd-U in= the past, conceptually) is still unchanged as it is titled: making a unifi= ed solution of encapsulation and translation for ipv4 residual deployment i= n an ipv6 domain. then i would like to clarify that ...=A0

1. the new draft remains ipv4 header checksum not end-t= o-end transparent for ICMP and UDP with zero checksum. even though the CNP = in address could protect the integrity of addresses, the integrity protecti= on provided by full encapsulation for port number and payload length is sti= ll lost. (=3D> can 4rd be called as a unified solution unifying encapsul= ation?)

2. end-to-end transparency for TTL=3D1 and TTL=3D255 is= now protected but other values are not. i doubt this is enough, because ne= ither RFC4271 nor RFC5082 is limited to the case only 1 or 255 is applied f= or the TTL security mechanism. in practice, eBGP sessions across 1 hop, 2 h= ops, or several hops are possible and the BGP speaker may not be very next = to the CE nor to the BR. we noticed that full encapsulation protect any cas= e of TTL. (=3D> can 4rd be called as a unified solution unifying encapsu= lation?)

but it is good that the first bit of IPv6 Hop Limit is = now not misused.=A0

(btw, a minor point of confusi= on, if TTL_1 =3D 1, i suppose the IPv6-to-IPv4 translator should make TTL= =3D0 in the resulted packet; if TTL_255 =3D 1, it must result in TTL=3D254,= right? as the virtual link has been a hop.)

3. TTL=3D1 and TTL=3D255 are treated differently may al= so confuse traceroute. e.g.:=A0

=A0 =A0 A - B - CE= --(IPv6 domain)-- BR - C

=A0 =A0when one do tranc= eroute at A to C, it will result in:=A0
=A0 =A01 =A0xxx ms xxx ms xxx ms B
=A0 =A02 =A0xxx ms xxx ms= xxx ms CE
=A0 =A03 =A0xxx ms xxx ms xxx ms BR
=A0 =A04= =A0xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain)
=A0 =A05 = =A0xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain)
=A0 =A0.
=A0 =A0.
=A0 =A0.
=A0 =A0N =A0x= xx ms xxx ms xxx ms BR (woops, again, is it a routing loop?)
=A0 = =A0N+1=A0 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted)
<= br>
=A0 =A0don't you think it is strange? the above behavior = is neither encapsulation nor translation, then can we call it as a "un= ification"?

thanks a lot for your attention,=A0
- maoke= =A0

2012/5/21 <internet-drafts= @ietf.org>

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.<= br>
=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv4 Residual Deployment via IP= v6 - a unified Stateless Solution (4rd)
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Remi Despres
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Reinaldo Penno
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yiu Lee
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gang Chen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sheng Jiang
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-4rd-00.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 40
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-16

=A0 The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment =A0 possible via IPv6 networks without maintaining for this per-customer =A0 states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of =A0 6rd). =A0To cope with the IPv4 address shortage, customers can be
=A0 assigned IPv4 addresses with restricted port sets. =A0In some
=A0 scenarios, 4rd-capable customer nodes can exchange packets of their =A0 IPv4-only applications via stateful NAT64s that are upgraded to
=A0 support 4rd tunnels (in addition to their IP/ICMP translation of
=A0 [RFC6145]).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwi= re-4rd-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire= -4rd-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/<= br>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf302074587ad9b604c0964d9b-- From despres.remi@laposte.net Tue May 22 00:58:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68321F8555 for ; Tue, 22 May 2012 00:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=1.229, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62qgEDERB2Y4 for ; Tue, 22 May 2012 00:58:44 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id A37AB21F8552 for ; Tue, 22 May 2012 00:58:44 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id 06FBD7000223 for ; Tue, 22 May 2012 09:58:43 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2304.sfr.fr (SMTP Server) with ESMTP id D7B3E70000F8 for ; Tue, 22 May 2012 09:58:42 +0200 (CEST) X-SFR-UUID: 20120522075842883.D7B3E70000F8@msfrf2304.sfr.fr Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> Date: Tue, 22 May 2012 09:58:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71202D37-FAB5-4F9A-85B8-C63E5638A162@laposte.net> References: <9DB3908B-7024-4463-BF67-AA2D3CCBBCA5@juniper.net> To: "softwires@ietf.org WG" X-Mailer: Apple Mail (2.1084) Subject: [Softwires] 4rd-00 now available X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 22 May 2012 07:58:45 -0000 Hello, all, The solution that, with Reinaldo Penno, Yiu Lee, Gang Chen, and Sheng = Jiang, we submit to the WG, as proposed standard for stateless IPv4 via = IPv6, is now available. The acronym is now just 4rd as other proposals using it have all expired = (4rd-E and 4rd T). As done for 6rd [RFC5969], the complete specification is in a single = document, including DHCPv6 formats. Ref: www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt=20 Since IETF 83, one significant point of substance has evolved: instead = of being systematic, including an IPv6 fragment header is now avoided = when possible without sacrificing IPv4 transparency.=20 For this, TTL preservation across 4rd tunnels is now limited to TTL =3D = 1 or 255, values that may be used to test router adjacency. We believe this evolution is important because: - As discussed in Paris, some IPv6 networks may treat IPv6 packets more = efficiently if they have no fragment headers, at least in TCP and UDP. - The added complexity to better deal with this is very limited. Any questions, and remarks on the draft are most welcome. We look forward to knowing the review-team composition when available. Regards, RD =20 From despres.remi@laposte.net Tue May 22 08:11:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56A421F8528 for ; Tue, 22 May 2012 08:11:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3nO8ePYTvn5 for ; Tue, 22 May 2012 08:11:29 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id CD8DF21F8531 for ; Tue, 22 May 2012 08:11:27 -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 B40FC9401A4; Tue, 22 May 2012 17:11:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 22 May 2012 17:11:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:11:30 -0000 Hi Maoke, Thank you for this quick reaction. 2012-05-22 03:54, Maoke : > hi Remi and other authors,=20 >=20 > thanks a lot for updating the draft. semantics review will follow and = here i only make an incomprehensive but quick response. please don't = hesitate to point out if i misunderstand.=20 >=20 > i assume that the purpose of 4rd (this 4rd =3D 4rd-U in the past, = conceptually) is still unchanged as it is titled: making a unified = solution of encapsulation and translation for ipv4 residual deployment = in an ipv6 domain. then i would like to clarify that ...=20 Yes, the goal remains a single standard, one that combines useful = features of MAP-T and MAP-E proposals.=20 A complementary explanation in section 7 (Relationship with previous = work) can be added to clarify it.=20 Besides, if 4rd is retained by the WG for standard track, the word = "unified" in the title can be deleted. (It is only a reference to the = historical process that led to the specification, the subject of section = 7) =20 > 1. the new draft remains ipv4 header checksum not end-to-end = transparent for ICMP and UDP with zero checksum.=20 (*) Assuming that links of 4rd domains have reliable link-layer = corruption detections, and that their routers never forward packets that = have been corrupted in memory (two acceptable assumptions AFAIK), IPv4 = packets forwarded at domain exit have their checksums completely = unchanged, unless required for decreased TTL and/or ECN. > even though the CNP in address could protect the integrity of = addresses, the integrity protection provided by full encapsulation for = port number and payload length is still lost. RFC6145 says "when the translator is configured to forward the packet = without a UDP checksum, the fragmented IPv4 UDP packets will be = translated". Reason why this is acceptable is AFAIK an assumption = similar to (*) above.=20 > (=3D> can 4rd be called as a unified solution unifying encapsulation?) >=20 > 2. end-to-end transparency for TTL=3D1 and TTL=3D255 is now protected = but other values are not. i doubt this is enough, because neither = RFC4271 nor RFC5082 is limited to the case only 1 or 255 is applied for = the TTL security mechanism. in practice, eBGP sessions across 1 hop, 2 = hops, or several hops are possible and the BGP speaker may not be very = next to the CE nor to the BR. we noticed that full encapsulation protect = any case of TTL. Yes encapsulation maintains *all* TTLs, but: - When MAP-T was proposed as a possible unique standards, this was = considered negligible. - 4rd does much more in this respect than MAP-T. > (=3D> can 4rd be called as a unified solution unifying encapsulation?) >=20 > but it is good that the first bit of IPv6 Hop Limit is now not = misused.=20 >=20 > (btw, a minor point of confusion, if TTL_1 =3D 1, i suppose the = IPv6-to-IPv4 translator should make TTL=3D0 in the resulted packet; if = TTL_255 =3D 1, it must result in TTL=3D254, right? as the virtual link = has been a hop.) In my understanding of MAP-E, TTL decrease isn't more part of the tunnel = behavior than in 4rd. Routers remain responsible for their usual TTL processing, which is = appropriate AFAIK. > 3. TTL=3D1 and TTL=3D255 are treated differently may also confuse = traceroute. e.g.:=20 >=20 > A - B - CE --(IPv6 domain)-- BR - C >=20 > when one do tranceroute at A to C, it will result in:=20 > 1 xxx ms xxx ms xxx ms B > 2 xxx ms xxx ms xxx ms CE > 3 xxx ms xxx ms xxx ms BR > 4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain) > 5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) > . > . > . > N xxx ms xxx ms xxx ms BR (woops, again, is it a routing loop?) > N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) >=20 > don't you think it is strange? the above behavior is neither = encapsulation nor translation, In the traced route above, IPv4 addresses of intra-domain nodes are all = the same (the domain entry IPv4 address, if it exists, or = 192.70.192.254 as per R-22). This provides a way to detect that a v4/v6 tunnel has been used, with an = indication of the number traversed nodes, IMHO a useful feature. Regards, RD > then can we call it as a "unification"? >=20 > thanks a lot for your attention,=20 > - maoke=20 >=20 > 2012/5/21 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Softwires Working Group of = the IETF. >=20 > Title : IPv4 Residual Deployment via IPv6 - a unified = Stateless Solution (4rd) > Author(s) : Remi Despres > Reinaldo Penno > Yiu Lee > Gang Chen > Sheng Jiang > Filename : draft-ietf-softwire-4rd-00.txt > Pages : 40 > Date : 2012-05-16 >=20 > The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment > possible via IPv6 networks without maintaining for this per-customer > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of > 6rd). To cope with the IPv4 address shortage, customers can be > assigned IPv4 addresses with restricted port sets. In some > scenarios, 4rd-capable customer nodes can exchange packets of their > IPv4-only applications via stateful NAT64s that are upgraded to > support 4rd tunnels (in addition to their IP/ICMP translation of > [RFC6145]). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 From fibrib@gmail.com Tue May 22 09:29:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DDC21F860D for ; Tue, 22 May 2012 09:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sePmfjAOq6xM for ; Tue, 22 May 2012 09:29:11 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 882F621F8606 for ; Tue, 22 May 2012 09:29:11 -0700 (PDT) Received: by qadz3 with SMTP id z3so2567841qad.10 for ; Tue, 22 May 2012 09:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IykJzsg/97Y7rCyvCReQSuhAlnrpj44vioxNkEAMyOY=; b=MTcuCzd2wJkDo43EDDnEMn9ragoi8WvegE5nyOgBBHXe5zPS4XlUJWk9EH2z2fMnl2 ftH6cDXSQVvXCTbwppkylJhXZOZwFuOdDsZXAawzZagyW55JcpWuBAzXlMU4SueUx595 Eq9WqUtUHaR4QPxCIFyDAVhMWU7JcbdQTWq4pZ12cztHMY1vuwsMGWBfM2UsNWC0Iosg NNLxlwfY8UeJvLuBqkkZnNbK5T3FdbT+lkJeWoGJWD+1/1t6gzQ7W49kCc5xOMdxHzpS pIVQ6qfayGhz6rGu524Bk5wZfjyAwATk8LtVM7rhHpF06ihkqvtsBbUrE1ohG4V5bC9p hp0A== MIME-Version: 1.0 Received: by 10.229.137.75 with SMTP id v11mr12742632qct.26.1337704150798; Tue, 22 May 2012 09:29:10 -0700 (PDT) Received: by 10.229.238.201 with HTTP; Tue, 22 May 2012 09:29:10 -0700 (PDT) In-Reply-To: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 01:29:10 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00235452ecd0b9134804c0a284f9 Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 16:29:13 -0000 --00235452ecd0b9134804c0a284f9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, thanks a lot for your clarification. only some quick reaction with my personal observations: 1. it is not the time to compare 4rd with MAP-T or with MAP-E separately, but with the MAP-suite. i never think MAP-T is intended to be the *unique* standard in the scope of residual deployment. (maybe it "was" but we'd better discuss things based on current understanding) 2. doing much more !=3D doing better correct. a) the "useful feature" of showing number of traverse nodes has been offered by MAP-suite through translation mode. is it really an add-on to the encapsulation? i don't think so. sometimes provider would like to open the tunnel details to the users sometimes they do like to hide the secret. 4rd traceroute behavior forces operator doing the latter. i don't know if everyone like it. i don't anyway. b) the TTL security mechanism is still a problem. c) i said that traceroute behavior is strange, it doesn't mean there are several IPv6 responders. it means there are BR showed twice. and one think 3 hops can reach the BR but 4 hops cannot reach the host C soon next to the BR. this is the strange thing! 3. regarding the link layer assumption, either MAP-T or MAP-E doesn't need such an assumption. (new assumption is new limitation on usability scope to my understanding). and i have pointed out it is not a correct understanding to think things would be reliable as long as link layer is reliable. for detailed investigation on these above observations, i promise i will update the commetary draft to reflect them. but not very quick as i got my hands hurt by the mouse and keyboard recently. :P anyway i am happy that you make the design not touching the first bit of Hop Limit now. thanks! regards, maoke 2012/5/23 R=E9mi Despr=E9s > Hi Maoke, > > Thank you for this quick reaction. > > > 2012-05-22 03:54, Maoke : > > > hi Remi and other authors, > > > > thanks a lot for updating the draft. semantics review will follow and > here i only make an incomprehensive but quick response. please don't > hesitate to point out if i misunderstand. > > > > i assume that the purpose of 4rd (this 4rd =3D 4rd-U in the past, > conceptually) is still unchanged as it is titled: making a unified soluti= on > of encapsulation and translation for ipv4 residual deployment in an ipv6 > domain. then i would like to clarify that ... > > Yes, the goal remains a single standard, one that combines useful feature= s > of MAP-T and MAP-E proposals. > A complementary explanation in section 7 (Relationship with previous work= ) > can be added to clarify it. > > Besides, if 4rd is retained by the WG for standard track, the word > "unified" in the title can be deleted. (It is only a reference to the > historical process that led to the specification, the subject of section = 7) > > > > 1. the new draft remains ipv4 header checksum not end-to-end transparen= t > for ICMP and UDP with zero checksum. > > (*) Assuming that links of 4rd domains have reliable link-layer corruptio= n > detections, and that their routers never forward packets that have been > corrupted in memory (two acceptable assumptions AFAIK), IPv4 packets > forwarded at domain exit have their checksums completely unchanged, unles= s > required for decreased TTL and/or ECN. > > > even though the CNP in address could protect the integrity of addresses= , > the integrity protection provided by full encapsulation for port number a= nd > payload length is still lost. > > RFC6145 says "when the translator is configured to forward the packet > without a UDP checksum, the fragmented IPv4 UDP packets will be > translated". Reason why this is acceptable is AFAIK an assumption similar > to (*) above. > > > > (=3D> can 4rd be called as a unified solution unifying encapsulation?) > > > > 2. end-to-end transparency for TTL=3D1 and TTL=3D255 is now protected b= ut > other values are not. i doubt this is enough, because neither RFC4271 nor > RFC5082 is limited to the case only 1 or 255 is applied for the TTL > security mechanism. in practice, eBGP sessions across 1 hop, 2 hops, or > several hops are possible and the BGP speaker may not be very next to the > CE nor to the BR. we noticed that full encapsulation protect any case of > TTL. > > > Yes encapsulation maintains *all* TTLs, but: > - When MAP-T was proposed as a possible unique standards, this was > considered negligible. > - 4rd does much more in this respect than MAP-T. > > > > (=3D> can 4rd be called as a unified solution unifying encapsulation?) > > > > but it is good that the first bit of IPv6 Hop Limit is now not misused. > > > > (btw, a minor point of confusion, if TTL_1 =3D 1, i suppose the > IPv6-to-IPv4 translator should make TTL=3D0 in the resulted packet; if > TTL_255 =3D 1, it must result in TTL=3D254, right? as the virtual link ha= s been > a hop.) > > In my understanding of MAP-E, TTL decrease isn't more part of the tunnel > behavior than in 4rd. > Routers remain responsible for their usual TTL processing, which is > appropriate AFAIK. > > > > 3. TTL=3D1 and TTL=3D255 are treated differently may also confuse > traceroute. e.g.: > > > > A - B - CE --(IPv6 domain)-- BR - C > > > > when one do tranceroute at A to C, it will result in: > > 1 xxx ms xxx ms xxx ms B > > 2 xxx ms xxx ms xxx ms CE > > 3 xxx ms xxx ms xxx ms BR > > 4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain) > > > > > 5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) > > . > > . > > . > > N xxx ms xxx ms xxx ms BR (woops, again, is it a routing loop?) > > N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) > > > > don't you think it is strange? the above behavior is neither > encapsulation nor translation, > > > In the traced route above, IPv4 addresses of intra-domain nodes are all > the same (the domain entry IPv4 address, if it exists, or 192.70.192.254 > as per R-22). > This provides a way to detect that a v4/v6 tunnel has been used, with an > indication of the number traversed nodes, IMHO a useful feature. > > Regards, > RD > > > > > > then can we call it as a "unification"? > > > > thanks a lot for your attention, > > - maoke > > > > 2012/5/21 > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Softwires Working Group of > the IETF. > > > > Title : IPv4 Residual Deployment via IPv6 - a unified > Stateless Solution (4rd) > > Author(s) : Remi Despres > > Reinaldo Penno > > Yiu Lee > > Gang Chen > > Sheng Jiang > > Filename : draft-ietf-softwire-4rd-00.txt > > Pages : 40 > > Date : 2012-05-16 > > > > The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment > > possible via IPv6 networks without maintaining for this per-customer > > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of > > 6rd). To cope with the IPv4 address shortage, customers can be > > assigned IPv4 addresses with restricted port sets. In some > > scenarios, 4rd-capable customer nodes can exchange packets of their > > IPv4-only applications via stateful NAT64s that are upgraded to > > support 4rd tunnels (in addition to their IP/ICMP translation of > > [RFC6145]). > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > > > > The IETF datatracker page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > > > --00235452ecd0b9134804c0a284f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,
=A0
thanks a lot for your=A0clarificat= ion.
=A0
only some quick=A0reaction=A0with my personal= =A0observations:
=A0
1. it is not the time to compare = 4rd with MAP-T or with MAP-E separately, but=A0with the MAP-suite.=A0i neve= r=A0think MAP-T is=A0intended to=A0be the=A0*unique*=A0standard in the scop= e of residual deployment. (maybe it "was" but we'd better dis= cuss things based on current understanding)
=A0
2. doing much more !=3D doing better correct. a) the=A0&= quot;useful feature" of showing number of traverse nodes=A0has been=A0= offered by MAP-suite through translation mode.=A0is it really an add-on to = the encapsulation? i don't think so. sometimes provider would like to o= pen the tunnel details to the users sometimes they do like to hide the secr= et. 4rd traceroute behavior=A0forces operator doing the latter. i don't= know if everyone like it. i don't anyway.=A0b) the TTL security mechan= ism is still a problem. c) i said that traceroute behavior is strange, it d= oesn't mean there are several IPv6 responders. it means there are BR sh= owed twice. and=A0one think 3 hops can reach the BR but 4 hops cannot reach= the host C soon next to the BR. this is the strange thing!
=A0
3. regarding the link layer assumption,=A0either MAP-T o= r MAP-E=A0doesn't need such an assumption. (new assumption is new limit= ation on usability scope=A0to my understanding).=A0and i have pointed out i= t is not a correct understanding to think things would be reliable as long = as link layer is reliable.
=A0
for detailed investigation on these above observations, = i promise i will update the commetary draft to reflect them. but not=A0very= quick as=A0i got my hands hurt=A0by the mouse and keyboard recently.=A0:P= =A0anyway i am happy that you make the design not touching the first bit of= Hop Limit now. thanks!
=A0
regards,
maoke
2012/5/23 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Hi Maoke,

Thank you for this quick reaction.


2012-05-22 03:54, Maoke :

> hi Remi and other authors,
>
> thanks a lot for updating the draft. semantics review will follow and = here i only make an incomprehensive but quick response. please don't he= sitate to point out if i misunderstand.
>
> i assume that the purpose of 4rd (this 4rd =3D 4rd-U in the past, conc= eptually) is still unchanged as it is titled: making a unified solution of = encapsulation and translation for ipv4 residual deployment in an ipv6 domai= n. then i would like to clarify that ...

Yes, the goal remains a single standard, one that combines useful fea= tures of MAP-T and MAP-E proposals.
A complementary explanation in section 7 (Relationship with previous work) = can be added to clarify it.

Besides, if 4rd is retained by the WG for standard track, the word "un= ified" in the title can be deleted. (It is only a reference to the his= torical process that led to the specification, the subject of section 7)


> 1. the new draft remains ipv4 header checksum not end-to-end transpare= nt for ICMP and UDP with zero checksum.

(*) Assuming that links of 4rd domains have reliable link-layer corru= ption detections, and that their routers never forward packets that have be= en corrupted in memory (two acceptable assumptions AFAIK), IPv4 packets for= warded at domain exit have their checksums completely unchanged, unless req= uired for decreased TTL and/or ECN.

> even though the CNP in address could protect the integrity of addresse= s, the integrity protection provided by full encapsulation for port number = and payload length is still lost.

RFC6145 says "when the translator is configured to forward the p= acket without a UDP checksum, the fragmented IPv4 UDP packets will be trans= lated". Reason why this is acceptable is AFAIK an assumption similar t= o (*) above.


> (=3D> can 4rd be called as a unified solution unifying encapsulatio= n?)
>
> 2. end-to-end transparency for TTL=3D1 and TTL=3D255 is now protected = but other values are not. i doubt this is enough, because neither RFC4271 n= or RFC5082 is limited to the case only 1 or 255 is applied for the TTL secu= rity mechanism. in practice, eBGP sessions across 1 hop, 2 hops, or several= hops are possible and the BGP speaker may not be very next to the CE nor t= o the BR. we noticed that full encapsulation protect any case of TTL.


Yes encapsulation maintains *all* TTLs, but:
- When MAP-T was proposed as a possible unique standards, this was consider= ed negligible.
- 4rd does much more in this respect than MAP-T.


> (=3D> can 4rd be called as a unified solution unifying encapsulatio= n?)
>
> but it is good that the first bit of IPv6 Hop Limit is now not misused= .
>
> (btw, a minor point of confusion, if TTL_1 =3D 1, i suppose the IPv6-t= o-IPv4 translator should make TTL=3D0 in the resulted packet; if TTL_255 = =3D 1, it must result in TTL=3D254, right? as the virtual link has been a h= op.)

In my understanding of MAP-E, TTL decrease isn't more part of the= tunnel behavior than in 4rd.
Routers remain responsible for their usual TTL processing, which is appropr= iate AFAIK.


> 3. TTL=3D1 and TTL=3D255 are treated differently may also confuse trac= eroute. e.g.:
>
> =A0 =A0 A - B - CE --(IPv6 domain)-- BR - C
>
> =A0 =A0when one do tranceroute at A to C, it will result in:
> =A0 =A01 =A0xxx ms xxx ms xxx ms B
> =A0 =A02 =A0xxx ms xxx ms xxx ms CE
> =A0 =A03 =A0xxx ms xxx ms xxx ms BR
> =A0 =A04 =A0xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain)



> =A0 =A05 =A0xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) > =A0 =A0.
> =A0 =A0.
> =A0 =A0.
> =A0 =A0N =A0xxx ms xxx ms xxx ms BR (woops, again, is it a routing loo= p?)
> =A0 =A0N+1 =A0xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) >
> =A0 =A0don't you think it is strange? the above behavior is neithe= r encapsulation nor translation,


In the traced route above, IPv4 addresses of intra-domain nodes are a= ll the same (the domain entry IPv4 address, if it exists, =A0or 192.70.192.= 254 as per R-22).
This provides a way to detect that a v4/v6 tunnel has been used, with an in= dication of the number traversed nodes, IMHO a useful feature.

Regards,
RD




> then can we call it as a "unification"?
>
> thanks a lot for your attention,
> - maoke
>
> 2012/5/21 <internet-dra= fts@ietf.org>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the Softwires Working Group of the I= ETF.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv4 Residual Deployment vi= a IPv6 - a unified Stateless Solution (4rd)
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Remi Despres
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Reinaldo Penno
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yiu Lee
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gang Chen
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sheng Jiang
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-4rd-00.tx= t
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 40
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-16
>
> =A0 The 4rd automatic tunneling mechanism makes IPv4 Residual Deployme= nt
> =A0 possible via IPv6 networks without maintaining for this per-custom= er
> =A0 states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment = of
> =A0 6rd). =A0To cope with the IPv4 address shortage, customers can be<= br> > =A0 assigned IPv4 addresses with restricted port sets. =A0In some
> =A0 scenarios, 4rd-capable customer nodes can exchange packets of thei= r
> =A0 IPv4-only applications via stateful NAT64s that are upgraded to > =A0 support 4rd tunnels (in addition to their IP/ICMP translation of > =A0 [RFC6145]).
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-s= oftwire-4rd-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sof= twire-4rd-00.txt
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/=
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>


--00235452ecd0b9134804c0a284f9-- From simon.perreault@viagenie.ca Tue May 22 10:28:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3084A21F8681 for ; Tue, 22 May 2012 10:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TolqusKR+9zN for ; Tue, 22 May 2012 10:28:11 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id A3BF821F867D for ; Tue, 22 May 2012 10:28:11 -0700 (PDT) Received: from [IPv6:2607:fa48:94:201:c0ac:7b22:4916:b8c6] (unknown [IPv6:2607:fa48:94:201:c0ac:7b22:4916:b8c6]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 349F940032 for ; Tue, 22 May 2012 13:28:11 -0400 (EDT) Message-ID: <4FBBCCA9.2050603@viagenie.ca> Date: Tue, 22 May 2012 13:28:09 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 17:28:12 -0000 On 2012-05-22 12:29, Maoke wrote: > 1. it is not the time to compare 4rd with MAP-T or with MAP-E > separately, but with the MAP-suite. i never think MAP-T is intended > to be the *unique* standard in the scope of residual deployment. (maybe > it "was" but we'd better discuss things based on current understanding) My understanding: 4rd is a compromise. What you gain: only one protocol to consider. What you lose: some edge cases are not supported. So any argument to the effect that "MAP-E|T does X and 4rd doesn't" is empty. This is expected, it's a compromise. The argument should be: "I need 4rd to do X because ..." Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From phdgang@gmail.com Tue May 22 23:19:02 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BE121F855D for ; Tue, 22 May 2012 23:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHBPrLpAokfn for ; Tue, 22 May 2012 23:19:01 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8BD21F84DF for ; Tue, 22 May 2012 23:19:00 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so3407195wib.13 for ; Tue, 22 May 2012 23:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oQf6hu29movO4mZzYqFN9403Ol7lqRveDcK65qKJyn4=; b=Zd8LAJvPUVksgrJhMHF8yz1ieKQ+q/DRAlyXJkcpOWs47CAuKp4HWOMyobHXQCXZjf GbaHZ9VBFOzTrgeYGKIvfCPP5kUWCabPD1s6RhDF51xbyGvLn97pjVX4jdSEqpugrjdh tTwabQxxiwVHy2QUEH12OktCVuDVkAoDgWDYAeLGuORMhbD9uIugiS9hzAoRO+JQq/pZ 4EkVxL3aYVWyZtx5Bk+tdXxv7dQWNpcPOLeieWP6Xt4jt8Nxx15cy74H0Q66YIYwKoNR E5lP/BUGSq7plnZja8+uEjbB/SJ8CQferKq9NpW4BzRJ3Rs5mfkFCfWEkKP8wrNHNaix NXHw== MIME-Version: 1.0 Received: by 10.180.78.161 with SMTP id c1mr42935541wix.1.1337753940186; Tue, 22 May 2012 23:19:00 -0700 (PDT) Received: by 10.180.106.38 with HTTP; Tue, 22 May 2012 23:19:00 -0700 (PDT) In-Reply-To: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 14:19:00 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 06:19:02 -0000 > 2. doing much more !=3D doing better correct. a) the "useful feature" of > showing number of traverse nodes has been offered by MAP-suite through > translation mode. is it really an add-on to the encapsulation? i don't > think so. sometimes provider would like to open the tunnel details to the > users sometimes they do like to hide the secret. 4rd traceroute > behavior forces operator doing the latter. i don't know if everyone like > it. i don't anyway. I guess translation mode may not help you to reveal the secret either. RFC6145 says " Note that the IPv6 addresses in the IPv6 header may not be IPv4- translatable addresses and there will be no corresponding IPv4 addresses representing this IPv6 address. In this case, the translator can do stateful translation. A mechanism by which the translator can instead do stateless translation of this address is left for future work." Stateful translator seems to me a shared IPv4 address might be used for several traversed nodes. b) the TTL security mechanism is still a problem. Please kindly to identify the issue. Gang > c) i > said that traceroute behavior is strange, it doesn't mean there are sever= al > IPv6 responders. it means there are BR showed twice. and one think 3 hops > can reach the BR but 4 hops cannot reach the host C soon next to the BR. > this is the strange thing! > > 3. regarding the link layer assumption, either MAP-T or MAP-E doesn't nee= d > such an assumption. (new assumption is new limitation on usability scope = to > my understanding). and i have pointed out it is not a correct understandi= ng > to think things would be reliable as long as link layer is reliable. > > for detailed investigation on these above observations, i promise i will > update the commetary draft to reflect them. but not very quick as i got m= y > hands hurt by the mouse and keyboard recently. :P anyway i am happy that > you make the design not touching the first bit of Hop Limit now. thanks! > > regards, > maoke > 2012/5/23 R=E9mi Despr=E9s > >> Hi Maoke, >> >> Thank you for this quick reaction. >> >> >> 2012-05-22 03:54, Maoke : >> >> > hi Remi and other authors, >> > >> > thanks a lot for updating the draft. semantics review will follow and >> here i only make an incomprehensive but quick response. please don't >> hesitate to point out if i misunderstand. >> > >> > i assume that the purpose of 4rd (this 4rd =3D 4rd-U in the past, >> conceptually) is still unchanged as it is titled: making a unified >> solution >> of encapsulation and translation for ipv4 residual deployment in an ipv6 >> domain. then i would like to clarify that ... >> >> Yes, the goal remains a single standard, one that combines useful >> features >> of MAP-T and MAP-E proposals. >> A complementary explanation in section 7 (Relationship with previous >> work) >> can be added to clarify it. >> >> Besides, if 4rd is retained by the WG for standard track, the word >> "unified" in the title can be deleted. (It is only a reference to the >> historical process that led to the specification, the subject of section >> 7) >> >> >> > 1. the new draft remains ipv4 header checksum not end-to-end >> > transparent >> for ICMP and UDP with zero checksum. >> >> (*) Assuming that links of 4rd domains have reliable link-layer >> corruption >> detections, and that their routers never forward packets that have been >> corrupted in memory (two acceptable assumptions AFAIK), IPv4 packets >> forwarded at domain exit have their checksums completely unchanged, >> unless >> required for decreased TTL and/or ECN. >> >> > even though the CNP in address could protect the integrity of >> > addresses, >> the integrity protection provided by full encapsulation for port number >> and >> payload length is still lost. >> >> RFC6145 says "when the translator is configured to forward the packet >> without a UDP checksum, the fragmented IPv4 UDP packets will be >> translated". Reason why this is acceptable is AFAIK an assumption simila= r >> to (*) above. >> >> >> > (=3D> can 4rd be called as a unified solution unifying encapsulation?) >> > >> > 2. end-to-end transparency for TTL=3D1 and TTL=3D255 is now protected = but >> other values are not. i doubt this is enough, because neither RFC4271 no= r >> RFC5082 is limited to the case only 1 or 255 is applied for the TTL >> security mechanism. in practice, eBGP sessions across 1 hop, 2 hops, or >> several hops are possible and the BGP speaker may not be very next to th= e >> CE nor to the BR. we noticed that full encapsulation protect any case of >> TTL. >> >> >> Yes encapsulation maintains *all* TTLs, but: >> - When MAP-T was proposed as a possible unique standards, this was >> considered negligible. >> - 4rd does much more in this respect than MAP-T. >> >> >> > (=3D> can 4rd be called as a unified solution unifying encapsulation?) >> > >> > but it is good that the first bit of IPv6 Hop Limit is now not misused= . >> > >> > (btw, a minor point of confusion, if TTL_1 =3D 1, i suppose the >> IPv6-to-IPv4 translator should make TTL=3D0 in the resulted packet; if >> TTL_255 =3D 1, it must result in TTL=3D254, right? as the virtual link h= as >> been >> a hop.) >> >> In my understanding of MAP-E, TTL decrease isn't more part of the tunnel >> behavior than in 4rd. >> Routers remain responsible for their usual TTL processing, which is >> appropriate AFAIK. >> >> >> > 3. TTL=3D1 and TTL=3D255 are treated differently may also confuse >> traceroute. e.g.: >> > >> > A - B - CE --(IPv6 domain)-- BR - C >> > >> > when one do tranceroute at A to C, it will result in: >> > 1 xxx ms xxx ms xxx ms B >> > 2 xxx ms xxx ms xxx ms CE >> > 3 xxx ms xxx ms xxx ms BR >> > 4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain) >> >> >> >> > 5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) >> > . >> > . >> > . >> > N xxx ms xxx ms xxx ms BR (woops, again, is it a routing loop?) >> > N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) >> > >> > don't you think it is strange? the above behavior is neither >> encapsulation nor translation, >> >> >> In the traced route above, IPv4 addresses of intra-domain nodes are all >> the same (the domain entry IPv4 address, if it exists, or 192.70.192.25= 4 >> as per R-22). >> This provides a way to detect that a v4/v6 tunnel has been used, with an >> indication of the number traversed nodes, IMHO a useful feature. >> >> Regards, >> RD >> >> >> >> >> > then can we call it as a "unification"? >> > >> > thanks a lot for your attention, >> > - maoke >> > >> > 2012/5/21 >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Softwires Working Group of >> the IETF. >> > >> > Title : IPv4 Residual Deployment via IPv6 - a unified >> Stateless Solution (4rd) >> > Author(s) : Remi Despres >> > Reinaldo Penno >> > Yiu Lee >> > Gang Chen >> > Sheng Jiang >> > Filename : draft-ietf-softwire-4rd-00.txt >> > Pages : 40 >> > Date : 2012-05-16 >> > >> > The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment >> > possible via IPv6 networks without maintaining for this per-customer >> > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of >> > 6rd). To cope with the IPv4 address shortage, customers can be >> > assigned IPv4 addresses with restricted port sets. In some >> > scenarios, 4rd-capable customer nodes can exchange packets of their >> > IPv4-only applications via stateful NAT64s that are upgraded to >> > support 4rd tunnels (in addition to their IP/ICMP translation of >> > [RFC6145]). >> > >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > This Internet-Draft can be retrieved at: >> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt >> > >> > The IETF datatracker page for this Internet-Draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ >> > >> > _______________________________________________ >> > Softwires mailing list >> > Softwires@ietf.org >> > https://www.ietf.org/mailman/listinfo/softwires >> > >> >> > From fibrib@gmail.com Wed May 23 01:49:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC5A21F868A for ; Wed, 23 May 2012 01:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46S+rH5gkrpa for ; Wed, 23 May 2012 01:49:09 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3A21F8648 for ; Wed, 23 May 2012 01:49:08 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so3502996wib.13 for ; Wed, 23 May 2012 01:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nRzgDyUX4Fgrv7aRpt8OkNYc2kimsQznPXG1a9Tk+lg=; b=w0LRaeveLBh/7vebykq0AedGo5FGNPdP4i7MPgNIX6D3FXoexi6gNW+JRoyAnbvlOc sEJcVsU43PU/0tl5rbRNvtbZqdvYYPRNF/UvGsrxC/d/WrqzvgShC0i135fLMTXp3axT dU7nc6MBpXGMP+FtVpQEwotZnmNcMxZ7lNQOyO+pfcT3WUDow5Gvri4CTNK+iDYFAjUf OYeQK4pWhJbMpIFiBAojV2sWNYclZHF2yXyZryAqTgwf/YQZ2ygCvLTF72mw4tB5qQ7O 2+QwKZfIVMLWizKi8VLnJXyfoAbIhnYUG/1VLwQVIgjAp83IHTA4ZebIaMXVVh+hCl22 3LBA== MIME-Version: 1.0 Received: by 10.180.80.97 with SMTP id q1mr44140987wix.13.1337762946990; Wed, 23 May 2012 01:49:06 -0700 (PDT) Received: by 10.216.17.20 with HTTP; Wed, 23 May 2012 01:49:06 -0700 (PDT) In-Reply-To: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 08:49:06 +0000 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=f46d0442835c3fc16204c0b035bd Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 08:49:11 -0000 --f46d0442835c3fc16204c0b035bd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/5/23 GangChen > > 2. doing much more !=3D doing better correct. a) the "useful feature" o= f > > showing number of traverse nodes has been offered by MAP-suite through > > translation mode. is it really an add-on to the encapsulation? i don't > > think so. sometimes provider would like to open the tunnel details to t= he > > users sometimes they do like to hide the secret. 4rd traceroute > > behavior forces operator doing the latter. i don't know if everyone lik= e > > it. i don't anyway. > > I guess translation mode may not help you to reveal the secret either. > open (some) details !=3D reveal (all) secrets. it is "i don't care if you get to know" or "i am happy to let you know", rather than "i have to let you know". we were talking about that 4rd disables operator's right of protecting their secret rather than the right of revealing it. revealing the secret, we have a lot of ways, not necessarily through user's traceroute. but you hinted me to find that 4rd's traceroute behavior is really a little worse than RFC6145. see the detailed example of path below: A - B - CE - D(v6) - F(v6) - G(v6) - BR - I - J from A to J: TTL =3D 1 =3D> B responds; 2 =3D> CE responds; 3 =3D> BR responds (as TTL_1 set at CE); 4 =3D> F(woops!! D is skipped) responds 5 =3D> G responds 6 =3D> BR responds again 7 =3D> I responds 8 =3D> J responds well, it would be not so bad if all the community of Internet engineers like such a cute joke. > RFC6145 says > " Note that the IPv6 addresses in the IPv6 header may not be IPv4- > translatable addresses and there will be no corresponding IPv4 > addresses representing this IPv6 address. In this case, the > translator can do stateful translation. A mechanism by which the > translator can instead do stateless translation of this address is > left for future work." > > Stateful translator seems to me a shared IPv4 address might be used > for several traversed nodes. > > b) the TTL security mechanism is still a problem. > > Please kindly to identify the issue. > eBGP multihop applies non-1 non-255 values for the hop-limited security of the sessions. both Cisco and Juniper has this well-known functionality. iptables can be set with ttl module to restrict only packets with ttl higher than or less than or equal to a certain value (surely not possible to be 1 or 255) can be accepted or forwarded. of course, 255 is the most important value and normative to RFC5082 but it is not the only value in practical use. - maoke > > > > Gang > > > > > c) i > > said that traceroute behavior is strange, it doesn't mean there are > several > > IPv6 responders. it means there are BR showed twice. and one think 3 ho= ps > > can reach the BR but 4 hops cannot reach the host C soon next to the BR= . > > this is the strange thing! > > > > 3. regarding the link layer assumption, either MAP-T or MAP-E doesn't > need > > such an assumption. (new assumption is new limitation on usability scop= e > to > > my understanding). and i have pointed out it is not a correct > understanding > > to think things would be reliable as long as link layer is reliable. > > > > for detailed investigation on these above observations, i promise i wil= l > > update the commetary draft to reflect them. but not very quick as i got > my > > hands hurt by the mouse and keyboard recently. :P anyway i am happy tha= t > > you make the design not touching the first bit of Hop Limit now. thanks= ! > > > > regards, > > maoke > > 2012/5/23 R=E9mi Despr=E9s > > > >> Hi Maoke, > >> > >> Thank you for this quick reaction. > >> > >> > >> 2012-05-22 03:54, Maoke : > >> > >> > hi Remi and other authors, > >> > > >> > thanks a lot for updating the draft. semantics review will follow an= d > >> here i only make an incomprehensive but quick response. please don't > >> hesitate to point out if i misunderstand. > >> > > >> > i assume that the purpose of 4rd (this 4rd =3D 4rd-U in the past, > >> conceptually) is still unchanged as it is titled: making a unified > >> solution > >> of encapsulation and translation for ipv4 residual deployment in an ip= v6 > >> domain. then i would like to clarify that ... > >> > >> Yes, the goal remains a single standard, one that combines useful > >> features > >> of MAP-T and MAP-E proposals. > >> A complementary explanation in section 7 (Relationship with previous > >> work) > >> can be added to clarify it. > >> > >> Besides, if 4rd is retained by the WG for standard track, the word > >> "unified" in the title can be deleted. (It is only a reference to the > >> historical process that led to the specification, the subject of secti= on > >> 7) > >> > >> > >> > 1. the new draft remains ipv4 header checksum not end-to-end > >> > transparent > >> for ICMP and UDP with zero checksum. > >> > >> (*) Assuming that links of 4rd domains have reliable link-layer > >> corruption > >> detections, and that their routers never forward packets that have bee= n > >> corrupted in memory (two acceptable assumptions AFAIK), IPv4 packets > >> forwarded at domain exit have their checksums completely unchanged, > >> unless > >> required for decreased TTL and/or ECN. > >> > >> > even though the CNP in address could protect the integrity of > >> > addresses, > >> the integrity protection provided by full encapsulation for port numbe= r > >> and > >> payload length is still lost. > >> > >> RFC6145 says "when the translator is configured to forward the packet > >> without a UDP checksum, the fragmented IPv4 UDP packets will be > >> translated". Reason why this is acceptable is AFAIK an assumption > similar > >> to (*) above. > >> > >> > >> > (=3D> can 4rd be called as a unified solution unifying encapsulation= ?) > >> > > >> > 2. end-to-end transparency for TTL=3D1 and TTL=3D255 is now protecte= d but > >> other values are not. i doubt this is enough, because neither RFC4271 > nor > >> RFC5082 is limited to the case only 1 or 255 is applied for the TTL > >> security mechanism. in practice, eBGP sessions across 1 hop, 2 hops, o= r > >> several hops are possible and the BGP speaker may not be very next to > the > >> CE nor to the BR. we noticed that full encapsulation protect any case = of > >> TTL. > >> > >> > >> Yes encapsulation maintains *all* TTLs, but: > >> - When MAP-T was proposed as a possible unique standards, this was > >> considered negligible. > >> - 4rd does much more in this respect than MAP-T. > >> > >> > >> > (=3D> can 4rd be called as a unified solution unifying encapsulation= ?) > >> > > >> > but it is good that the first bit of IPv6 Hop Limit is now not > misused. > >> > > >> > (btw, a minor point of confusion, if TTL_1 =3D 1, i suppose the > >> IPv6-to-IPv4 translator should make TTL=3D0 in the resulted packet; if > >> TTL_255 =3D 1, it must result in TTL=3D254, right? as the virtual link= has > >> been > >> a hop.) > >> > >> In my understanding of MAP-E, TTL decrease isn't more part of the tunn= el > >> behavior than in 4rd. > >> Routers remain responsible for their usual TTL processing, which is > >> appropriate AFAIK. > >> > >> > >> > 3. TTL=3D1 and TTL=3D255 are treated differently may also confuse > >> traceroute. e.g.: > >> > > >> > A - B - CE --(IPv6 domain)-- BR - C > >> > > >> > when one do tranceroute at A to C, it will result in: > >> > 1 xxx ms xxx ms xxx ms B > >> > 2 xxx ms xxx ms xxx ms CE > >> > 3 xxx ms xxx ms xxx ms BR > >> > 4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain) > >> > >> > >> > >> > 5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) > >> > . > >> > . > >> > . > >> > N xxx ms xxx ms xxx ms BR (woops, again, is it a routing loop?) > >> > N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) > >> > > >> > don't you think it is strange? the above behavior is neither > >> encapsulation nor translation, > >> > >> > >> In the traced route above, IPv4 addresses of intra-domain nodes are al= l > >> the same (the domain entry IPv4 address, if it exists, or > 192.70.192.254 > >> as per R-22). > >> This provides a way to detect that a v4/v6 tunnel has been used, with = an > >> indication of the number traversed nodes, IMHO a useful feature. > >> > >> Regards, > >> RD > >> > >> > >> > >> > >> > then can we call it as a "unification"? > >> > > >> > thanks a lot for your attention, > >> > - maoke > >> > > >> > 2012/5/21 > >> > > >> > A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. This draft is a work item of the Softwires Working Group = of > >> the IETF. > >> > > >> > Title : IPv4 Residual Deployment via IPv6 - a unifi= ed > >> Stateless Solution (4rd) > >> > Author(s) : Remi Despres > >> > Reinaldo Penno > >> > Yiu Lee > >> > Gang Chen > >> > Sheng Jiang > >> > Filename : draft-ietf-softwire-4rd-00.txt > >> > Pages : 40 > >> > Date : 2012-05-16 > >> > > >> > The 4rd automatic tunneling mechanism makes IPv4 Residual Deployme= nt > >> > possible via IPv6 networks without maintaining for this per-custom= er > >> > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment = of > >> > 6rd). To cope with the IPv4 address shortage, customers can be > >> > assigned IPv4 addresses with restricted port sets. In some > >> > scenarios, 4rd-capable customer nodes can exchange packets of thei= r > >> > IPv4-only applications via stateful NAT64s that are upgraded to > >> > support 4rd tunnels (in addition to their IP/ICMP translation of > >> > [RFC6145]). > >> > > >> > > >> > A URL for this Internet-Draft is: > >> > http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > This Internet-Draft can be retrieved at: > >> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > >> > > >> > The IETF datatracker page for this Internet-Draft is: > >> > https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ > >> > > >> > _______________________________________________ > >> > Softwires mailing list > >> > Softwires@ietf.org > >> > https://www.ietf.org/mailman/listinfo/softwires > >> > > >> > >> > > > --f46d0442835c3fc16204c0b035bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/5/23 GangChen <phdgang@gmail.com&g= t;
> 2. doing much more !=3D doing better correct. a) the= "useful feature" of
> showing number of traverse nodes has been offered by MAP-suite through=
> translation mode. is it really an add-on to the encapsulation? i don&#= 39;t
> think so. sometimes provider would like to open the tunnel details to = the
> users sometimes they do like to hide the secret. 4rd traceroute
> behavior forces operator doing the latter. i don't know if everyon= e like
> it. i don't anyway.

I guess translation mode may not help you to reveal the secret either= .

open (some) details !=3D reveal (all)= secrets.=A0
it is "i don't care if you get to know"= ; or "i am happy to let you know", rather than "i have to le= t you know".=A0

we were talking about that 4rd disables operator's = right of protecting their secret rather than the right of revealing it. rev= ealing the secret, we have a lot of ways, not necessarily through user'= s traceroute.=A0

but you hinted me to find that 4rd's traceroute beh= avior is really a little worse than RFC6145. see the detailed example of pa= th below:=A0
=A0 =A0 =A0 =A0 =A0 =A0=A0
=A0 =A0A - B - = CE - D(v6) - F(v6) - G(v6) - BR - I - J

from A to J:=A0
TTL =3D 1 =3D> B responds;= =A0
=A0 =A0 =A0 2 =3D> CE responds;
=A0 =A0 =A0 3 = =3D> BR responds (as TTL_1 set at CE);=A0
=A0 =A0 =A0 4 =3D>= ; F(woops!! D is skipped) responds=A0
=A0 =A0 =A0 5 =3D> G responds=A0
=A0 =A0 =A0 6 =3D> BR= responds again=A0
=A0 =A0 =A0 7 =3D> I responds=A0
= =A0 =A0 =A0 8 =3D> J responds

well, it would be= not so bad if all the community of Internet engineers like such a cute jok= e.=A0


RFC6145 says
" =A0Note that the IPv6 addresses in the IPv6 header may not be IPv4-<= br> =A0 translatable addresses and there will be no corresponding IPv4
=A0 addresses representing this IPv6 address. =A0In this case, the
=A0 translator can do stateful translation. =A0A mechanism by which the =A0 translator can instead do stateless translation of this address is
=A0 left for future work."

Stateful translator seems to me a shared IPv4 address might be used
for several traversed nodes.

b) the TTL security mechanism is still a problem.

Please kindly to identify the issue.

<= div>eBGP multihop applies non-1 non-255 values for the hop-limited security= of the sessions. both Cisco and Juniper has this well-known functionality.= iptables can be set with ttl module to restrict only packets with ttl high= er than or less than or equal to a certain value (surely not possible to be= 1 or 255) can be accepted or forwarded. of course, 255 is the most importa= nt value and normative to RFC5082 but it is not the only value in practical= use.

- maoke=A0
=A0



Gang



> c) i
> said that traceroute behavior is strange, it doesn't mean there ar= e several
> IPv6 responders. it means there are BR showed twice. and one think 3 h= ops
> can reach the BR but 4 hops cannot reach the host C soon next to the B= R.
> this is the strange thing!
>
> 3. regarding the link layer assumption, either MAP-T or MAP-E doesn= 9;t need
> such an assumption. (new assumption is new limitation on usability sco= pe to
> my understanding). and i have pointed out it is not a correct understa= nding
> to think things would be reliable as long as link layer is reliable. >
> for detailed investigation on these above observations, i promise i wi= ll
> update the commetary draft to reflect them. but not very quick as i go= t my
> hands hurt by the mouse and keyboard recently. :P anyway i am happy th= at
> you make the design not touching the first bit of Hop Limit now. thank= s!
>
> regards,
> maoke
> 2012/5/23 R=E9mi Despr=E9s <despres.remi@laposte.net>
>
>> Hi Maoke,
>>
>> Thank you for this quick reaction.
>>
>>
>> 2012-05-22 03:54, Maoke :
>>
>> > hi Remi and other authors,
>> >
>> > thanks a lot for updating the draft. semantics review will fo= llow and
>> here i only make an incomprehensive but quick response. please don= 't
>> hesitate to point out if i misunderstand.
>> >
>> > i assume that the purpose of 4rd (this 4rd =3D 4rd-U in the p= ast,
>> conceptually) is still unchanged as it is titled: making a unified=
>> solution
>> of encapsulation and translation for ipv4 residual deployment in a= n ipv6
>> domain. then i would like to clarify that ...
>>
>> Yes, the goal remains a single standard, one that combines useful<= br> >> features
>> of MAP-T and MAP-E proposals.
>> A complementary explanation in section 7 (Relationship with previo= us
>> work)
>> can be added to clarify it.
>>
>> Besides, if 4rd is retained by the WG for standard track, the word=
>> "unified" in the title can be deleted. (It is only a ref= erence to the
>> historical process that led to the specification, the subject of s= ection
>> 7)
>>
>>
>> > 1. the new draft remains ipv4 header checksum not end-to-end<= br> >> > transparent
>> for ICMP and UDP with zero checksum.
>>
>> (*) Assuming that links of 4rd domains have reliable link-layer >> corruption
>> detections, and that their routers never forward packets that have= been
>> corrupted in memory (two acceptable assumptions AFAIK), IPv4 packe= ts
>> forwarded at domain exit have their checksums completely unchanged= ,
>> unless
>> required for decreased TTL and/or ECN.
>>
>> > even though the CNP in address could protect the integrity of=
>> > addresses,
>> the integrity protection provided by full encapsulation for port n= umber
>> and
>> payload length is still lost.
>>
>> RFC6145 says "when the translator is configured to forward th= e packet
>> without a UDP checksum, the fragmented IPv4 UDP packets will be >> translated". Reason why this is acceptable is AFAIK an assump= tion similar
>> to (*) above.
>>
>>
>> > (=3D> can 4rd be called as a unified solution unifying enc= apsulation?)
>> >
>> > 2. end-to-end transparency for TTL=3D1 and TTL=3D255 is now p= rotected but
>> other values are not. i doubt this is enough, because neither RFC4= 271 nor
>> RFC5082 is limited to the case only 1 or 255 is applied for the TT= L
>> security mechanism. in practice, eBGP sessions across 1 hop, 2 hop= s, or
>> several hops are possible and the BGP speaker may not be very next= to the
>> CE nor to the BR. we noticed that full encapsulation protect any c= ase of
>> TTL.
>>
>>
>> Yes encapsulation maintains *all* TTLs, but:
>> - When MAP-T was proposed as a possible unique standards, this was=
>> considered negligible.
>> - 4rd does much more in this respect than MAP-T.
>>
>>
>> > (=3D> can 4rd be called as a unified solution unifying enc= apsulation?)
>> >
>> > but it is good that the first bit of IPv6 Hop Limit is now no= t misused.
>> >
>> > (btw, a minor point of confusion, if TTL_1 =3D 1, i suppose t= he
>> IPv6-to-IPv4 translator should make TTL=3D0 in the resulted packet= ; if
>> TTL_255 =3D 1, it must result in TTL=3D254, right? as the virtual = link has
>> been
>> a hop.)
>>
>> In my understanding of MAP-E, TTL decrease isn't more part of = the tunnel
>> behavior than in 4rd.
>> Routers remain responsible for their usual TTL processing, which i= s
>> appropriate AFAIK.
>>
>>
>> > 3. TTL=3D1 and TTL=3D255 are treated differently may also con= fuse
>> traceroute. e.g.:
>> >
>> > =A0 =A0 A - B - CE --(IPv6 domain)-- BR - C
>> >
>> > =A0 =A0when one do tranceroute at A to C, it will result in:<= br> >> > =A0 =A01 =A0xxx ms xxx ms xxx ms B
>> > =A0 =A02 =A0xxx ms xxx ms xxx ms CE
>> > =A0 =A03 =A0xxx ms xxx ms xxx ms BR
>> > =A0 =A04 =A0xxx ms xxx ms xxx ms (Somewhere in the IPv6 domai= n)
>>
>>
>>
>> > =A0 =A05 =A0xxx ms xxx ms xxx ms (Somewhere else in the IPv6 = domain)
>> > =A0 =A0.
>> > =A0 =A0.
>> > =A0 =A0.
>> > =A0 =A0N =A0xxx ms xxx ms xxx ms BR (woops, again, is it a ro= uting loop?)
>> > =A0 =A0N+1 =A0xxx ms xxx ms xxx ms C (IPv6-domain hops are co= unted)
>> >
>> > =A0 =A0don't you think it is strange? the above behavior = is neither
>> encapsulation nor translation,
>>
>>
>> In the traced route above, IPv4 addresses of intra-domain nodes ar= e all
>> the same (the domain entry IPv4 address, if it exists, =A0or 192.7= 0.192.254
>> as per R-22).
>> This provides a way to detect that a v4/v6 tunnel has been used, w= ith an
>> indication of the number traversed nodes, IMHO a useful feature. >>
>> Regards,
>> RD
>>
>>
>>
>>
>> > then can we call it as a "unification"?
>> >
>> > thanks a lot for your attention,
>> > - maoke
>> >
>> > 2012/5/21 <int= ernet-drafts@ietf.org>
>> >
>> > A New Internet-Draft is available from the on-line Internet-D= rafts
>> directories. This draft is a work item of the Softwires Working Gr= oup of
>> the IETF.
>> >
>> > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv4 Residual Depl= oyment via IPv6 - a unified
>> Stateless Solution (4rd)
>> > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Remi Despres
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Reinaldo P= enno
>> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yiu Lee >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gang Chen<= br> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sheng Jian= g
>> > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-= 4rd-00.txt
>> > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 40
>> > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-16
>> >
>> > =A0 The 4rd automatic tunneling mechanism makes IPv4 Residual= Deployment
>> > =A0 possible via IPv6 networks without maintaining for this p= er-customer
>> > =A0 states in 4rd-capable nodes (reverse of the IPv6 Rapid De= ployment of
>> > =A0 6rd). =A0To cope with the IPv4 address shortage, customer= s can be
>> > =A0 assigned IPv4 addresses with restricted port sets. =A0In = some
>> > =A0 scenarios, 4rd-capable customer nodes can exchange packet= s of their
>> > =A0 IPv4-only applications via stateful NAT64s that are upgra= ded to
>> > =A0 support 4rd tunnels (in addition to their IP/ICMP transla= tion of
>> > =A0 [RFC6145]).
>> >
>> >
>> > A URL for this Internet-Draft is:
>> > http://www.ietf.org/internet-drafts/dra= ft-ietf-softwire-4rd-00.txt
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > This Internet-Draft can be retrieved at:
>> > ftp://ftp.ietf.org/internet-drafts/draft= -ietf-softwire-4rd-00.txt
>> >
>> > The IETF datatracker page for this Internet-Draft is:
>> > https://datatracker.ietf.org/doc/draft-ietf-soft= wire-4rd/
>> >
>> > _______________________________________________
>> > Softwires mailing list
>> > Softwires@ietf.org<= br> >> > https://www.ietf.org/mailman/listinfo/softwires
>> >
>>
>>
>

--f46d0442835c3fc16204c0b035bd-- From fibrib@gmail.com Wed May 23 02:24:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA93E21F85FF for ; Wed, 23 May 2012 02:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWSxL8duGdIk for ; Wed, 23 May 2012 02:24:22 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 159E821F84E1 for ; Wed, 23 May 2012 02:24:21 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so3584300wib.13 for ; Wed, 23 May 2012 02:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y52JMfxlWk5Nsn5V2RM0oUOa6eWAsO0xehAdugfdxLw=; b=EQmTzHo8e9A0teKJhXgGjOk5eLj9XnwI9IXbRBMfZaGy4Gyyt91lCjWnEb+ZZNkFwU MUe8yVGoo8xhsZIX/PScVj0t5wGVJ9phHLHqi6gp6oVoGrue7DHu3Eud3EOoDfBUq51N oOC53Tbb8YHPoNYCchUqbKfOaqp+4jGmoaV/tQ2JH/DIZ3/7TKUQYZ0IxrPGVMjJlQ84 yc+QeuhuyLo7Ch3RDkMRNtYQel6c5+3TZa7yEpJ8HT/FW001n/lgjIkno7mAteAWVDUc SfRvr218P81CmMqob0s0+XWb+8ksUL5iXUuUHK9CmdVywLlaViXaWcSjMqDetd5RvGnC ULJQ== MIME-Version: 1.0 Received: by 10.180.102.36 with SMTP id fl4mr36902610wib.2.1337765061160; Wed, 23 May 2012 02:24:21 -0700 (PDT) Received: by 10.216.17.20 with HTTP; Wed, 23 May 2012 02:24:21 -0700 (PDT) In-Reply-To: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 18:24:21 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=f46d044481c7436e1304c0b0b32e Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 09:24:22 -0000 --f46d044481c7436e1304c0b0b32e Content-Type: text/plain; charset=ISO-8859-1 2012/5/23 Maoke > > eBGP multihop applies non-1 non-255 values for the hop-limited security of > the sessions. both Cisco and Juniper has this well-known functionality. > iptables can be set with ttl module to restrict only packets with ttl > higher than or less than or equal to a certain value (surely not possible > to be 1 or 255) can be accepted or forwarded. of > typo... *not possible to be 1 or 255* => not necessarily to be 1 or 255.. > course, 255 is the most important value and normative to RFC5082 but it is > not the only value in practical use. > > - maoke > > --f46d044481c7436e1304c0b0b32e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/5/23 Maoke <fibrib@gmail.com>= ;

eBGP multihop applies non-1 non-255 val= ues for the hop-limited security of the sessions. both Cisco and Juniper ha= s this well-known functionality. iptables can be set with ttl module to res= trict only packets with ttl higher than or less than or equal to a certain = value (surely not possible to be 1 or 255) can be accepted or forwarded. of=

typo... *not possible to be 1 or 255= * =3D> not necessarily to be 1 or 255.. =A0
=A0
course, 255 is the most important value an= d normative to RFC5082 but it is not the only value in practical use.
=

- maoke=A0
=A0
--f46d044481c7436e1304c0b0b32e-- From phdgang@gmail.com Wed May 23 04:24:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948CF21F85D4 for ; Wed, 23 May 2012 04:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSosmY-Z1bz5 for ; Wed, 23 May 2012 04:24:21 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9279521F8548 for ; Wed, 23 May 2012 04:24:20 -0700 (PDT) Received: by wibhn6 with SMTP id hn6so3673296wib.13 for ; Wed, 23 May 2012 04:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fkT/LYWPBI0T1L8IMTMZk3wYPIcRdh7ONVNHLONLv4s=; b=cDna8nkLwBvBDrRfLk8S7quT1FavXQ6KvOC6NB7mGd+dYS9Bjv2uaYkavMMDS5pRMW 36k7NtdHdiGuMMtDknCMqhDhziaZzZ5Xzog6Q/su+sCh3bUid1YCRNMrxTOxxhagLHH7 yLS6skGSR4HfgySL7kmN+R+G/oe/Z9xihqjoT8Nslodg1iN1zIoqcPxvvENg4rWsH3jq PKp16JPGS7nXF7zuXKmbHXMuVMpVQYBPVepZkSh/TdGIyJ3JAcnTB5fmrIdRs6tDEKtZ uxnH9K6+9x9CKPrL0E+ESXaiIck/Hq1T35qw2nSrIKtWovQRjj5d2zYmb59yLw9Z68Ev U/rg== MIME-Version: 1.0 Received: by 10.180.74.193 with SMTP id w1mr45221966wiv.4.1337772259465; Wed, 23 May 2012 04:24:19 -0700 (PDT) Received: by 10.180.106.38 with HTTP; Wed, 23 May 2012 04:24:19 -0700 (PDT) In-Reply-To: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 19:24:19 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 11:24:22 -0000 2012/5/23, Maoke : > 2012/5/23 GangChen > >> > 2. doing much more !=3D doing better correct. a) the "useful feature" = of >> > showing number of traverse nodes has been offered by MAP-suite through >> > translation mode. is it really an add-on to the encapsulation? i don't >> > think so. sometimes provider would like to open the tunnel details to >> > the >> > users sometimes they do like to hide the secret. 4rd traceroute >> > behavior forces operator doing the latter. i don't know if everyone li= ke >> > it. i don't anyway. >> >> I guess translation mode may not help you to reveal the secret either. >> > > open (some) details !=3D reveal (all) secrets. > it is "i don't care if you get to know" or "i am happy to let you know", > rather than "i have to let you know". > > we were talking about that 4rd disables operator's right of protecting > their secret rather than the right of revealing it. revealing the secret, > we have a lot of ways, not necessarily through user's traceroute. That is little bit misleading. I'd rather to understand 4rd provides the tunnel solution with revealing capability. Operators who want to protect their secrets could simply disable traceroute on the node. > but you hinted me to find that 4rd's traceroute behavior is really a litt= le > worse than RFC6145. see the detailed example of path below: > > A - B - CE - D(v6) - F(v6) - G(v6) - BR - I - J > > from A to J: > TTL =3D 1 =3D> B responds; > 2 =3D> CE responds; > 3 =3D> BR responds (as TTL_1 set at CE); > 4 =3D> F(woops!! D is skipped) responds > 5 =3D> G responds > 6 =3D> BR responds again > 7 =3D> I responds > 8 =3D> J responds > well, it would be not so bad if all the community of Internet engineers > like such a cute joke. I don't see the harm when a solution provides a determinated way to debug. >> RFC6145 says >> " Note that the IPv6 addresses in the IPv6 header may not be IPv4- >> translatable addresses and there will be no corresponding IPv4 >> addresses representing this IPv6 address. In this case, the >> translator can do stateful translation. A mechanism by which the >> translator can instead do stateless translation of this address is >> left for future work." >> >> Stateful translator seems to me a shared IPv4 address might be used >> for several traversed nodes. >> >> b) the TTL security mechanism is still a problem. >> >> Please kindly to identify the issue. >> > > eBGP multihop applies non-1 non-255 values for the hop-limited security o= f > the sessions. both Cisco and Juniper has this well-known functionality. > iptables can be set with ttl module to restrict only packets with ttl > higher than or less than or equal to a certain value (surely not possible > to be 1 or 255) can be accepted or forwarded. of course, 255 is the most > important value and normative to RFC5082 but it is not the only value in > practical use. The design is following normative behavior. When you are concerning about numerous implementation variants, the best answer is PLEASE BE consistent with normative recommendation. Gang > - maoke > > >> >> >> >> Gang >> >> >> >> > c) i >> > said that traceroute behavior is strange, it doesn't mean there are >> several >> > IPv6 responders. it means there are BR showed twice. and one think 3 >> > hops >> > can reach the BR but 4 hops cannot reach the host C soon next to the B= R. >> > this is the strange thing! >> > >> > 3. regarding the link layer assumption, either MAP-T or MAP-E doesn't >> need >> > such an assumption. (new assumption is new limitation on usability sco= pe >> to >> > my understanding). and i have pointed out it is not a correct >> understanding >> > to think things would be reliable as long as link layer is reliable. >> > >> > for detailed investigation on these above observations, i promise i wi= ll >> > update the commetary draft to reflect them. but not very quick as i go= t >> my >> > hands hurt by the mouse and keyboard recently. :P anyway i am happy th= at >> > you make the design not touching the first bit of Hop Limit now. thank= s! >> > >> > regards, >> > maoke >> > 2012/5/23 R=E9mi Despr=E9s >> > >> >> Hi Maoke, >> >> >> >> Thank you for this quick reaction. >> >> >> >> >> >> 2012-05-22 03:54, Maoke : >> >> >> >> > hi Remi and other authors, >> >> > >> >> > thanks a lot for updating the draft. semantics review will follow a= nd >> >> here i only make an incomprehensive but quick response. please don't >> >> hesitate to point out if i misunderstand. >> >> > >> >> > i assume that the purpose of 4rd (this 4rd =3D 4rd-U in the past, >> >> conceptually) is still unchanged as it is titled: making a unified >> >> solution >> >> of encapsulation and translation for ipv4 residual deployment in an >> >> ipv6 >> >> domain. then i would like to clarify that ... >> >> >> >> Yes, the goal remains a single standard, one that combines useful >> >> features >> >> of MAP-T and MAP-E proposals. >> >> A complementary explanation in section 7 (Relationship with previous >> >> work) >> >> can be added to clarify it. >> >> >> >> Besides, if 4rd is retained by the WG for standard track, the word >> >> "unified" in the title can be deleted. (It is only a reference to the >> >> historical process that led to the specification, the subject of >> >> section >> >> 7) >> >> >> >> >> >> > 1. the new draft remains ipv4 header checksum not end-to-end >> >> > transparent >> >> for ICMP and UDP with zero checksum. >> >> >> >> (*) Assuming that links of 4rd domains have reliable link-layer >> >> corruption >> >> detections, and that their routers never forward packets that have be= en >> >> corrupted in memory (two acceptable assumptions AFAIK), IPv4 packets >> >> forwarded at domain exit have their checksums completely unchanged, >> >> unless >> >> required for decreased TTL and/or ECN. >> >> >> >> > even though the CNP in address could protect the integrity of >> >> > addresses, >> >> the integrity protection provided by full encapsulation for port numb= er >> >> and >> >> payload length is still lost. >> >> >> >> RFC6145 says "when the translator is configured to forward the packet >> >> without a UDP checksum, the fragmented IPv4 UDP packets will be >> >> translated". Reason why this is acceptable is AFAIK an assumption >> similar >> >> to (*) above. >> >> >> >> >> >> > (=3D> can 4rd be called as a unified solution unifying encapsulatio= n?) >> >> > >> >> > 2. end-to-end transparency for TTL=3D1 and TTL=3D255 is now protect= ed but >> >> other values are not. i doubt this is enough, because neither RFC4271 >> nor >> >> RFC5082 is limited to the case only 1 or 255 is applied for the TTL >> >> security mechanism. in practice, eBGP sessions across 1 hop, 2 hops, = or >> >> several hops are possible and the BGP speaker may not be very next to >> the >> >> CE nor to the BR. we noticed that full encapsulation protect any case >> >> of >> >> TTL. >> >> >> >> >> >> Yes encapsulation maintains *all* TTLs, but: >> >> - When MAP-T was proposed as a possible unique standards, this was >> >> considered negligible. >> >> - 4rd does much more in this respect than MAP-T. >> >> >> >> >> >> > (=3D> can 4rd be called as a unified solution unifying encapsulatio= n?) >> >> > >> >> > but it is good that the first bit of IPv6 Hop Limit is now not >> misused. >> >> > >> >> > (btw, a minor point of confusion, if TTL_1 =3D 1, i suppose the >> >> IPv6-to-IPv4 translator should make TTL=3D0 in the resulted packet; i= f >> >> TTL_255 =3D 1, it must result in TTL=3D254, right? as the virtual lin= k has >> >> been >> >> a hop.) >> >> >> >> In my understanding of MAP-E, TTL decrease isn't more part of the >> >> tunnel >> >> behavior than in 4rd. >> >> Routers remain responsible for their usual TTL processing, which is >> >> appropriate AFAIK. >> >> >> >> >> >> > 3. TTL=3D1 and TTL=3D255 are treated differently may also confuse >> >> traceroute. e.g.: >> >> > >> >> > A - B - CE --(IPv6 domain)-- BR - C >> >> > >> >> > when one do tranceroute at A to C, it will result in: >> >> > 1 xxx ms xxx ms xxx ms B >> >> > 2 xxx ms xxx ms xxx ms CE >> >> > 3 xxx ms xxx ms xxx ms BR >> >> > 4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain) >> >> >> >> >> >> >> >> > 5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) >> >> > . >> >> > . >> >> > . >> >> > N xxx ms xxx ms xxx ms BR (woops, again, is it a routing loop?) >> >> > N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) >> >> > >> >> > don't you think it is strange? the above behavior is neither >> >> encapsulation nor translation, >> >> >> >> >> >> In the traced route above, IPv4 addresses of intra-domain nodes are a= ll >> >> the same (the domain entry IPv4 address, if it exists, or >> 192.70.192.254 >> >> as per R-22). >> >> This provides a way to detect that a v4/v6 tunnel has been used, with >> >> an >> >> indication of the number traversed nodes, IMHO a useful feature. >> >> >> >> Regards, >> >> RD >> >> >> >> >> >> >> >> >> >> > then can we call it as a "unification"? >> >> > >> >> > thanks a lot for your attention, >> >> > - maoke >> >> > >> >> > 2012/5/21 >> >> > >> >> > A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. This draft is a work item of the Softwires Working Group >> >> of >> >> the IETF. >> >> > >> >> > Title : IPv4 Residual Deployment via IPv6 - a >> >> > unified >> >> Stateless Solution (4rd) >> >> > Author(s) : Remi Despres >> >> > Reinaldo Penno >> >> > Yiu Lee >> >> > Gang Chen >> >> > Sheng Jiang >> >> > Filename : draft-ietf-softwire-4rd-00.txt >> >> > Pages : 40 >> >> > Date : 2012-05-16 >> >> > >> >> > The 4rd automatic tunneling mechanism makes IPv4 Residual >> >> > Deployment >> >> > possible via IPv6 networks without maintaining for this >> >> > per-customer >> >> > states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment >> >> > of >> >> > 6rd). To cope with the IPv4 address shortage, customers can be >> >> > assigned IPv4 addresses with restricted port sets. In some >> >> > scenarios, 4rd-capable customer nodes can exchange packets of the= ir >> >> > IPv4-only applications via stateful NAT64s that are upgraded to >> >> > support 4rd tunnels (in addition to their IP/ICMP translation of >> >> > [RFC6145]). >> >> > >> >> > >> >> > A URL for this Internet-Draft is: >> >> > http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt >> >> > >> >> > Internet-Drafts are also available by anonymous FTP at: >> >> > ftp://ftp.ietf.org/internet-drafts/ >> >> > >> >> > This Internet-Draft can be retrieved at: >> >> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt >> >> > >> >> > The IETF datatracker page for this Internet-Draft is: >> >> > https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ >> >> > >> >> > _______________________________________________ >> >> > Softwires mailing list >> >> > Softwires@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/softwires >> >> > >> >> >> >> >> > >> > From despres.remi@laposte.net Wed May 23 05:25:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE9721F86AD for ; Wed, 23 May 2012 05:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxQCUJv8SM87 for ; Wed, 23 May 2012 05:25:46 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 35FE321F85F2 for ; Wed, 23 May 2012 05:25:44 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id A6CD29400F9; Wed, 23 May 2012 14:25:37 +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: Wed, 23 May 2012 14:25:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120521234047.23326.15971.idtracker@ietfa.amsl.com> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 12:25:47 -0000 Maoke, Thanks for the thorough analysis of how 4rd deals with the various TTL = value. 2012-05-23 10:49, Maoke: > 2012/5/23 GangChen > > 2. doing much more !=3D doing better correct. a) the "useful = feature" of > > showing number of traverse nodes has been offered by MAP-suite = through > > translation mode. is it really an add-on to the encapsulation? i = don't > > think so. sometimes provider would like to open the tunnel details = to the > > users sometimes they do like to hide the secret. 4rd traceroute > > behavior forces operator doing the latter. i don't know if everyone = like > > it. i don't anyway. >=20 > I guess translation mode may not help you to reveal the secret either. >=20 > open (some) details !=3D reveal (all) secrets.=20 > it is "i don't care if you get to know" or "i am happy to let you = know", rather than "i have to let you know".=20 >=20 > we were talking about that 4rd disables operator's right of protecting = their secret rather than the right of revealing it. revealing the = secret, we have a lot of ways, not necessarily through user's = traceroute.=20 >=20 > but you hinted me to find that 4rd's traceroute behavior is really a = little worse than RFC6145. For TTL =3D 255 and TTL =3D 1, isn't 4rd now BETTER than RFC6145?=20 (Thanks for your previous remarks that contributed to improve support of = these values.)=20 Regarding other values, more comments below. > see the detailed example of path below:=20 > =20 > A - B - CE - D(v6) - F(v6) - G(v6) - BR - I - J >=20 > from A to J:=20 > TTL =3D 1 =3D> B responds;=20 > 2 =3D> CE responds; > 3 =3D> BR responds (as TTL_1 set at CE);=20 > 4 =3D> F(woops!! D is skipped) responds=20 > 5 =3D> G responds=20 > 6 =3D> BR responds again=20 > 7 =3D> I responds=20 > 8 =3D> J responds This interesting example suggests IMHO to simplify R-22 to avoid = permitting multiple behaviors. R-22 would just say "192.70.192.254 MUST = be used as source address" instead of "If the CE or BR has a global IPv4 = address, this address MUST be used as source of this packet. Otherwise, = 192.70.192.254 SHOULD be used as this source". With this, we have: =20 TTL =3D 1 =3D> B responds=20 2 =3D> CE responds 3 =3D> BR responds =20 4 =3D> F responds in v6=20 CE responds to A, SRC=3D192.70.192.254 5 =3D> G responds in v6 CE responds to A, SRC=3D192.70.192.254 6 =3D> BR responds 7 =3D> I responds=20 8 =3D> J responds Thus, where a 4rd tunnel is traversed, trace route gets: - two responses of the tunnel exit node - between these two, as many responses with SRC=3D192.70.192.254 as = there are intermediate IPv6 routers This is a feature I see no reason to avoid or regret. > well, it would be not so bad if all the community of Internet = engineers like such a cute joke. For at least SOME Internet engineers, this as a feature, not as a joke = ;-) .=20 > RFC6145 says > " Note that the IPv6 addresses in the IPv6 header may not be IPv4- > translatable addresses and there will be no corresponding IPv4 > addresses representing this IPv6 address. In this case, the > translator can do stateful translation. A mechanism by which the > translator can instead do stateless translation of this address is > left for future work." >=20 > Stateful translator seems to me a shared IPv4 address might be used > for several traversed nodes. >=20 > b) the TTL security mechanism is still a problem. >=20 > Please kindly to identify the issue. >=20 > eBGP multihop applies non-1 non-255 values for the hop-limited = security of the sessions. both Cisco and Juniper has this well-known = functionality. iptables can be set with ttl module to restrict only = packets with ttl higher than or less than or equal to a certain value = (surely not possible to be 1 or 255) can be accepted or forwarded. AFAIK, this functionality does work across a 4rd domain.=20 Any real case where this would be a problem? RD > of course, 255 is the most important value and normative to RFC5082 = but it is not the only value in practical use. >=20 > - maoke=20 > =20 >=20 >=20 >=20 > Gang >=20 >=20 >=20 > > c) i > > said that traceroute behavior is strange, it doesn't mean there are = several > > IPv6 responders. it means there are BR showed twice. and one think 3 = hops > > can reach the BR but 4 hops cannot reach the host C soon next to the = BR. > > this is the strange thing! > > > > 3. regarding the link layer assumption, either MAP-T or MAP-E = doesn't need > > such an assumption. (new assumption is new limitation on usability = scope to > > my understanding). and i have pointed out it is not a correct = understanding > > to think things would be reliable as long as link layer is reliable. > > > > for detailed investigation on these above observations, i promise i = will > > update the commetary draft to reflect them. but not very quick as i = got my > > hands hurt by the mouse and keyboard recently. :P anyway i am happy = that > > you make the design not touching the first bit of Hop Limit now. = thanks! > > > > regards, > > maoke > > 2012/5/23 R=E9mi Despr=E9s > > > >> Hi Maoke, > >> > >> Thank you for this quick reaction. > >> > >> > >> 2012-05-22 03:54, Maoke : > >> > >> > hi Remi and other authors, > >> > > >> > thanks a lot for updating the draft. semantics review will follow = and > >> here i only make an incomprehensive but quick response. please = don't > >> hesitate to point out if i misunderstand. > >> > > >> > i assume that the purpose of 4rd (this 4rd =3D 4rd-U in the past, > >> conceptually) is still unchanged as it is titled: making a unified > >> solution > >> of encapsulation and translation for ipv4 residual deployment in an = ipv6 > >> domain. then i would like to clarify that ... > >> > >> Yes, the goal remains a single standard, one that combines useful > >> features > >> of MAP-T and MAP-E proposals. > >> A complementary explanation in section 7 (Relationship with = previous > >> work) > >> can be added to clarify it. > >> > >> Besides, if 4rd is retained by the WG for standard track, the word > >> "unified" in the title can be deleted. (It is only a reference to = the > >> historical process that led to the specification, the subject of = section > >> 7) > >> > >> > >> > 1. the new draft remains ipv4 header checksum not end-to-end > >> > transparent > >> for ICMP and UDP with zero checksum. > >> > >> (*) Assuming that links of 4rd domains have reliable link-layer > >> corruption > >> detections, and that their routers never forward packets that have = been > >> corrupted in memory (two acceptable assumptions AFAIK), IPv4 = packets > >> forwarded at domain exit have their checksums completely unchanged, > >> unless > >> required for decreased TTL and/or ECN. > >> > >> > even though the CNP in address could protect the integrity of > >> > addresses, > >> the integrity protection provided by full encapsulation for port = number > >> and > >> payload length is still lost. > >> > >> RFC6145 says "when the translator is configured to forward the = packet > >> without a UDP checksum, the fragmented IPv4 UDP packets will be > >> translated". Reason why this is acceptable is AFAIK an assumption = similar > >> to (*) above. > >> > >> > >> > (=3D> can 4rd be called as a unified solution unifying = encapsulation?) > >> > > >> > 2. end-to-end transparency for TTL=3D1 and TTL=3D255 is now = protected but > >> other values are not. i doubt this is enough, because neither = RFC4271 nor > >> RFC5082 is limited to the case only 1 or 255 is applied for the TTL > >> security mechanism. in practice, eBGP sessions across 1 hop, 2 = hops, or > >> several hops are possible and the BGP speaker may not be very next = to the > >> CE nor to the BR. we noticed that full encapsulation protect any = case of > >> TTL. > >> > >> > >> Yes encapsulation maintains *all* TTLs, but: > >> - When MAP-T was proposed as a possible unique standards, this was > >> considered negligible. > >> - 4rd does much more in this respect than MAP-T. > >> > >> > >> > (=3D> can 4rd be called as a unified solution unifying = encapsulation?) > >> > > >> > but it is good that the first bit of IPv6 Hop Limit is now not = misused. > >> > > >> > (btw, a minor point of confusion, if TTL_1 =3D 1, i suppose the > >> IPv6-to-IPv4 translator should make TTL=3D0 in the resulted packet; = if > >> TTL_255 =3D 1, it must result in TTL=3D254, right? as the virtual = link has > >> been > >> a hop.) > >> > >> In my understanding of MAP-E, TTL decrease isn't more part of the = tunnel > >> behavior than in 4rd. > >> Routers remain responsible for their usual TTL processing, which is > >> appropriate AFAIK. > >> > >> > >> > 3. TTL=3D1 and TTL=3D255 are treated differently may also confuse > >> traceroute. e.g.: > >> > > >> > A - B - CE --(IPv6 domain)-- BR - C > >> > > >> > when one do tranceroute at A to C, it will result in: > >> > 1 xxx ms xxx ms xxx ms B > >> > 2 xxx ms xxx ms xxx ms CE > >> > 3 xxx ms xxx ms xxx ms BR > >> > 4 xxx ms xxx ms xxx ms (Somewhere in the IPv6 domain) > >> > >> > >> > >> > 5 xxx ms xxx ms xxx ms (Somewhere else in the IPv6 domain) > >> > . > >> > . > >> > . > >> > N xxx ms xxx ms xxx ms BR (woops, again, is it a routing = loop?) > >> > N+1 xxx ms xxx ms xxx ms C (IPv6-domain hops are counted) > >> > > >> > don't you think it is strange? the above behavior is neither > >> encapsulation nor translation, > >> > >> > >> In the traced route above, IPv4 addresses of intra-domain nodes are = all > >> the same (the domain entry IPv4 address, if it exists, or = 192.70.192.254 > >> as per R-22). > >> This provides a way to detect that a v4/v6 tunnel has been used, = with an > >> indication of the number traversed nodes, IMHO a useful feature. > >> > >> Regards, > >> RD > >> > >> > >> > >> > >> > then can we call it as a "unification"? > >> > > >> > thanks a lot for your attention, > >> > - maoke > >> > > >> > 2012/5/21 > >> > > >> > A New Internet-Draft is available from the on-line = Internet-Drafts > >> directories. This draft is a work item of the Softwires Working = Group of > >> the IETF. > >> > > >> > Title : IPv4 Residual Deployment via IPv6 - a = unified > >> Stateless Solution (4rd) > >> > Author(s) : Remi Despres > >> > Reinaldo Penno > >> > Yiu Lee > >> > Gang Chen > >> > Sheng Jiang > >> > Filename : draft-ietf-softwire-4rd-00.txt > >> > Pages : 40 > >> > Date : 2012-05-16 > >> > > >> > The 4rd automatic tunneling mechanism makes IPv4 Residual = Deployment > >> > possible via IPv6 networks without maintaining for this = per-customer > >> > states in 4rd-capable nodes (reverse of the IPv6 Rapid = Deployment of > >> > 6rd). To cope with the IPv4 address shortage, customers can be > >> > assigned IPv4 addresses with restricted port sets. In some > >> > scenarios, 4rd-capable customer nodes can exchange packets of = their > >> > IPv4-only applications via stateful NAT64s that are upgraded to > >> > support 4rd tunnels (in addition to their IP/ICMP translation = of > >> > [RFC6145]). > >> > > >> > > >> > A URL for this Internet-Draft is: > >> > = http://www.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > >> > > >> > Internet-Drafts are also available by anonymous FTP at: > >> > ftp://ftp.ietf.org/internet-drafts/ > >> > > >> > This Internet-Draft can be retrieved at: > >> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-4rd-00.txt > >> > > >> > The IETF datatracker page for this Internet-Draft is: > >> > https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/ > >> > > >> > _______________________________________________ > >> > Softwires mailing list > >> > Softwires@ietf.org > >> > https://www.ietf.org/mailman/listinfo/softwires > >> > > >> > >> > > >=20 From pengwu.thu@gmail.com Thu May 24 02:42:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDFD21F85EF for ; Thu, 24 May 2012 02:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zyhK559TM+s for ; Thu, 24 May 2012 02:42:54 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53AB121F85E7 for ; Thu, 24 May 2012 02:42:54 -0700 (PDT) Received: by dacx6 with SMTP id x6so11247349dac.31 for ; Thu, 24 May 2012 02:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=h9cbwSKBEOtwwu/DthyJnqFE46pWb4KAP0ZEJLGHqaU=; b=SlNn8XTzkjXbuqdqgSHyLE4fbao6TNbZrh8+sEwzZJpZapFHpelJ3yECcJjfo7GKuk oKm6m/s+pePP2mfzGJsp3qd4qduo5+5+E+ct4085EMoRduA9oxbZwtETs0iYgYIb9+gJ TVkUzmscyN6EucGiWmvQuHCBEs3jLkU8MB+bif/lJc2hxCsGEuH1Ba2hJ6Kt8qCFAD4X E2FbTqE46HNyQTZ7KGA5egYeX8sdRnSowmveFj6A/xU/IBybumTG0oW5BYOJGWo7GPhg WXyhYBzF0QLoDEMk6QfBrpgAGgFemZ3zyzqYnu8VQs4LfnfHp1I6YlNleluWvS7Hk0GX MsLg== MIME-Version: 1.0 Received: by 10.68.237.166 with SMTP id vd6mr19463374pbc.139.1337852573993; Thu, 24 May 2012 02:42:53 -0700 (PDT) Received: by 10.68.55.74 with HTTP; Thu, 24 May 2012 02:42:53 -0700 (PDT) In-Reply-To: <20120519141238.4345.1501.idtracker@ietfa.amsl.com> References: <20120519141238.4345.1501.idtracker@ietfa.amsl.com> Date: Thu, 24 May 2012 17:42:53 +0800 Message-ID: From: Peng Wu To: Softwires WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Softwires] Fwd: New Version Notification for draft-cui-softwire-b4-translated-ds-lite-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 09:42:55 -0000 Hi all, We have pubished a new version of the lightweight 4over6 draft. The draft describes a per-subscriber IPv4-over-IPv6 Hub & Spoke mechanism with port-set provisioning support. The -06 version merges with draft-penno-softwire-sdnat-02 and makes the draft compatible with both use cases. Among different provisoning protocols, the authors choose DHCP as the mandated method, based on the comments from IETF83 Softwire meeting. In this version, various issues are settled and the preciseness of the mechanism description is improved . The draft is available at http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-06 Please feel free to provide your comments:) Cheers~ ---------- Forwarded message ---------- A new version of I-D, draft-cui-softwire-b4-translated-ds-lite-06.txt has been successfully posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-cui-softwire-b4-translated-ds-lite Revision: =A0 =A0 =A0 =A006 Title: =A0 =A0 =A0 =A0 =A0 Lightweight 4over6: An Extension to the DS-Lite = Architecture Creation date: =A0 2012-05-19 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 16 Abstract: =A0 This document specifies an extension to DS-Lite called Lightweight =A0 4over6. =A0This mechanism moves the translation function from the =A0 tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the =A0 mapping scale on the concentrator to a per-subscriber level. =A0To =A0 delegate the NAPT function to the initiators, port-restricted IPv4 =A0 addresses are allocated to the initiators. The IETF Secretariat From cuiyong@tsinghua.edu.cn Sun May 27 07:28:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD2421F854B for ; Sun, 27 May 2012 07:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.496 X-Spam-Level: * X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxyPhnE0fDOL for ; Sun, 27 May 2012 07:28:49 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id D9C8421F8543 for ; Sun, 27 May 2012 07:28:45 -0700 (PDT) Received: from [124.126.164.51] (helo=[192.168.0.106]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1SYeSU-000097-7c; Sun, 27 May 2012 22:28:38 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 27 May 2012 22:28:40 +0800 From: Yong Cui To: Message-ID: Thread-Topic: WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 14:28:50 -0000 Hi folks, This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio n/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 June 10 at 12pm EDT. Yong & Alain From cuiyong@tsinghua.edu.cn Sun May 27 07:30:46 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA07121F8546 for ; Sun, 27 May 2012 07:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.403 X-Spam-Level: * X-Spam-Status: No, score=1.403 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SL03ybbG8rQ for ; Sun, 27 May 2012 07:30:46 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1CABB21F8543 for ; Sun, 27 May 2012 07:30:46 -0700 (PDT) Received: from [124.126.164.51] (helo=[192.168.0.106]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1SYeUW-0000HX-1j; Sun, 27 May 2012 22:30:45 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 27 May 2012 22:30:51 +0800 From: Yong Cui To: Message-ID: Thread-Topic: WG last call on draft-ietf-softwire-public-4over6-01 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 14:30:46 -0000 Hi folks, This is a wg last call on draft-ietf-softwire-public-4over6-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 June 10 at 12pm EDT. Yong & Alain From cuiyong@tsinghua.edu.cn Sun May 27 07:32:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703F321F8546 for ; Sun, 27 May 2012 07:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.357 X-Spam-Level: * X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_40=-0.185, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmKW4MeH0J0j for ; Sun, 27 May 2012 07:32:24 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBFE21F8543 for ; Sun, 27 May 2012 07:32:22 -0700 (PDT) Received: from [124.126.164.51] (helo=[192.168.0.106]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1SYeW4-0000Lq-Hn; Sun, 27 May 2012 22:32:20 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 27 May 2012 22:32:28 +0800 From: Yong Cui To: Message-ID: Thread-Topic: WG last call on draft-ietf-softwire-dslite-deployment-03 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-dslite-deployment-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 27 May 2012 14:32:24 -0000 Hi folks, This is a wg last call on draft-ietf-softwire-dslite-deployment-03. http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 June 10 at 12pm EDT. Yong & Alain From cuiyong@tsinghua.edu.cn Sun May 27 07:34:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DF121F8466 for ; Sun, 27 May 2012 07:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.341 X-Spam-Level: * X-Spam-Status: No, score=1.341 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_40=-0.185, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAY8EOYvgeD2 for ; Sun, 27 May 2012 07:34:49 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBBD21F8463 for ; Sun, 27 May 2012 07:34:49 -0700 (PDT) Received: from [124.126.164.51] (helo=[192.168.0.106]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1SYeYP-0006mz-JI; Sun, 27 May 2012 22:34:46 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 27 May 2012 22:34:52 +0800 From: Yong Cui To: Message-ID: Thread-Topic: WG last call on draft-ietf-softwire-dslite-multicast-02 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 14:34:50 -0000 Hi folks, This is a wg last call on draft-ietf-softwire-dslite-multicast-02. http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on June 10 at 12pm EDT. Yong & Alain From cuiyong@tsinghua.edu.cn Sun May 27 07:43:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BAB21F854B for ; Sun, 27 May 2012 07:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.056 X-Spam-Level: * X-Spam-Status: No, score=1.056 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_20=-0.74, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8+ozDUzUnkB for ; Sun, 27 May 2012 07:43:18 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEFF21F84E6 for ; Sun, 27 May 2012 07:43:17 -0700 (PDT) Received: from [124.126.164.51] (helo=[192.168.0.106]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1SYegb-0007A3-O3; Sun, 27 May 2012 22:43:13 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 27 May 2012 22:43:21 +0800 From: Yong Cui To: Softwires WG Message-ID: Thread-Topic: Call for adoption of Softwire Mesh Management Information Base (MIB) Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Yong Cui Subject: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2012 14:43:19 -0000 Hi folks, As we discussed on Softwire Mesh Management Information Base (MIB) in Paris meeting, the chairs would like to ask for WG adoption on the mailing list. Please review this document and send your comments (especially your opinion on the adoption with your reasons) to the mailing list by two weeks, i.e. June 10. FYI: http://datatracker.ietf.org/doc/draft-cui-softwire-mesh-mib/ Yong & Alain From jiangsheng@huawei.com Sun May 27 18:23:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF43221F8564 for ; Sun, 27 May 2012 18:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCb91bf47Of9 for ; Sun, 27 May 2012 18:23:54 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 17D2821F854E for ; Sun, 27 May 2012 18:23:54 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGO85890; Sun, 27 May 2012 21:23:53 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 18:21:51 -0700 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 18:21:50 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.40]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Mon, 28 May 2012 09:21:47 +0800 From: Sheng Jiang To: Yong Cui , Softwires WG Thread-Topic: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) Thread-Index: AQHNPBcTtUo/jywqBkCMVZPj+zTxJ5beaCNQ Date: Mon, 28 May 2012 01:21:46 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921EE69DB3@szxeml545-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 01:23:54 -0000 Support adopt this draft as WG draft. Sheng Jiang > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Yong Cui > Sent: Sunday, May 27, 2012 10:43 PM > To: Softwires WG > Cc: Yong Cui > Subject: [Softwires] Call for adoption of Softwire Mesh Management > Information Base (MIB) >=20 > Hi folks, >=20 > As we discussed on Softwire Mesh Management Information Base (MIB) > in Paris meeting, the chairs would like to ask for WG adoption on the > mailing list. Please review this document and send your comments > (especially your opinion on the adoption with your reasons) to the > mailing list by two weeks, i.e. June 10. >=20 > FYI: > http://datatracker.ietf.org/doc/draft-cui-softwire-mesh-mib/ >=20 >=20 > Yong & Alain >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jiangsheng@huawei.com Sun May 27 18:34:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2238A21F846A for ; Sun, 27 May 2012 18:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipx8iYBFwhch for ; Sun, 27 May 2012 18:34:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DB91121F8462 for ; Sun, 27 May 2012 18:34:48 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGH85320; Sun, 27 May 2012 21:34:48 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 18:32:58 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 18:32:57 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.40]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Mon, 28 May 2012 09:32:50 +0800 From: Sheng Jiang To: Yong Cui , "softwires@ietf.org" Thread-Topic: WG last call on draft-ietf-softwire-dslite-deployment-03 Thread-Index: AQHNPBWM7k7k8UX3IkqTKXzvSSJDipbea1yw Date: Mon, 28 May 2012 01:32:49 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921EE69DC6@szxeml545-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-deployment-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 28 May 2012 01:34:50 -0000 The document looks mature enough for being advanced. Sheng Jiang > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Yong Cui > Sent: Sunday, May 27, 2012 10:32 PM > To: softwires@ietf.org > Cc: Yong Cui > Subject: [Softwires] WG last call on draft-ietf-softwire-dslite- > deployment-03 >=20 > Hi folks, >=20 > This is a wg last call on draft-ietf-softwire-dslite-deployment-03. > http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment/ >=20 > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. >=20 > This wg last call will end on 2012 June 10 at 12pm EDT. >=20 >=20 > Yong & Alain >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From jiangsheng@huawei.com Sun May 27 18:35:07 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F6A21F848E for ; Sun, 27 May 2012 18:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5U2t0VNIhml for ; Sun, 27 May 2012 18:35:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 43B7B21F8455 for ; Sun, 27 May 2012 18:35:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGH85364; Sun, 27 May 2012 21:35:07 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 18:32:38 -0700 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 18:32:38 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.40]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Mon, 28 May 2012 09:32:34 +0800 From: Sheng Jiang To: Yong Cui , "softwires@ietf.org" Thread-Topic: WG last call on draft-ietf-softwire-public-4over6-01 Thread-Index: AQHNPBVSL6hqNob4rkO6K53ThmzIfJbeay6A Date: Mon, 28 May 2012 01:32:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921EE69DBF@szxeml545-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 01:35:07 -0000 The document looks mature for being advanced. Sheng Jiang > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Yong Cui > Sent: Sunday, May 27, 2012 10:31 PM > To: softwires@ietf.org > Cc: Yong Cui > Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6- > 01 >=20 > Hi folks, >=20 > This is a wg last call on draft-ietf-softwire-public-4over6-01. > http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >=20 > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. >=20 > This wg last call will end on 2012 June 10 at 12pm EDT. >=20 >=20 > Yong & Alain >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Tina.Tsou.Zouting@huawei.com Sun May 27 18:41:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A6C21F8568 for ; Sun, 27 May 2012 18:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnnDGW0jnN9F for ; Sun, 27 May 2012 18:41:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB63E21F853D for ; Sun, 27 May 2012 18:41:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGH85781; Sun, 27 May 2012 21:41:34 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 18:40:06 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Sun, 27 May 2012 18:40:03 -0700 From: Tina TSOU To: Yong Cui Thread-Topic: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) Thread-Index: AQHNPBcV+Vl9N3oEIUer1X/1dFql7JbebWyz Date: Mon, 28 May 2012 01:40:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 01:41:35 -0000 Support the adoption. Tina On May 27, 2012, at 7:43 AM, "Yong Cui" wrote: > Hi folks, >=20 > As we discussed on Softwire Mesh Management Information Base (MIB) > in Paris meeting, the chairs would like to ask for WG adoption on the > mailing list. Please review this document and send your comments > (especially your opinion on the adoption with your reasons) to the > mailing list by two weeks, i.e. June 10. >=20 > FYI: > http://datatracker.ietf.org/doc/draft-cui-softwire-mesh-mib/ >=20 >=20 > Yong & Alain >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Tina.Tsou.Zouting@huawei.com Sun May 27 18:44:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386A721F846C for ; Sun, 27 May 2012 18:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCkEty3YZvgp for ; Sun, 27 May 2012 18:44:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 84FEC21F8467 for ; Sun, 27 May 2012 18:44:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGH85942; Sun, 27 May 2012 21:44:56 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 18:42:25 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Sun, 27 May 2012 18:42:24 -0700 From: Tina TSOU To: Yong Cui Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Thread-Index: AQHNPHMhv8w2xFqESky/PWHwL6IcMA== Date: Mon, 28 May 2012 01:42:24 +0000 Message-ID: <3048164C-912F-412D-BB22-217E2E87EBD2@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 01:44:57 -0000 Support it move to the next step. Tina On May 27, 2012, at 7:30 AM, "Yong Cui" wrote: > Hi folks, >=20 > This is a wg last call on draft-ietf-softwire-public-4over6-01. > http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >=20 > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. >=20 > This wg last call will end on 2012 June 10 at 12pm EDT. >=20 >=20 > Yong & Alain >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From leo.liubing@huawei.com Sun May 27 19:59:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51E521F853D for ; Sun, 27 May 2012 19:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bABp6vlD6DVP for ; Sun, 27 May 2012 19:59:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4885F21F84E6 for ; Sun, 27 May 2012 19:59:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGO91281; Sun, 27 May 2012 22:59:00 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 19:56:55 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 27 May 2012 19:56:54 -0700 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Mon, 28 May 2012 10:56:40 +0800 From: "Liubing (Leo)" To: Sheng Jiang , Yong Cui , Softwires WG Thread-Topic: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) Thread-Index: AQHNPHHX3gE++zz0n0aG8+PZkvkbrZbegfIQ Date: Mon, 28 May 2012 02:56:40 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45292C9812@szxeml509-mbx> References: <5D36713D8A4E7348A7E10DF7437A4B921EE69DB3@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921EE69DB3@szxeml545-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 02:59:01 -0000 +1 for support > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Sheng Jiang > Sent: Monday, May 28, 2012 9:22 AM > To: Yong Cui; Softwires WG > Subject: Re: [Softwires] Call for adoption of Softwire Mesh Management > Information Base (MIB) >=20 > Support adopt this draft as WG draft. >=20 > Sheng Jiang >=20 > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > > Behalf Of Yong Cui > > Sent: Sunday, May 27, 2012 10:43 PM > > To: Softwires WG > > Cc: Yong Cui > > Subject: [Softwires] Call for adoption of Softwire Mesh Management > > Information Base (MIB) > > > > Hi folks, > > > > As we discussed on Softwire Mesh Management Information Base (MIB) > > in Paris meeting, the chairs would like to ask for WG adoption on the > > mailing list. Please review this document and send your comments > > (especially your opinion on the adoption with your reasons) to the > > mailing list by two weeks, i.e. June 10. > > > > FYI: > > http://datatracker.ietf.org/doc/draft-cui-softwire-mesh-mib/ > > > > > > Yong & Alain > > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From repenno@cisco.com Sun May 27 22:52:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F7C21F85B4 for ; Sun, 27 May 2012 22:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjZ5Usg5S2Yk for ; Sun, 27 May 2012 22:52:37 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6F51721F85B1 for ; Sun, 27 May 2012 22:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=1413; q=dns/txt; s=iport; t=1338184357; x=1339393957; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=SqNQnBr0MtmMLR5TF0K+QF6nVNYFGepyUrFK3+w2pB8=; b=JQq8cF6w3QUJ88M+9gJQIlFNp9l4RskfkD2hBi5jetZV7N3n42YPUON+ hUDV31gVYlfLkd4mq9vo14XHaouzMm3yXTnCDHhq2GSlvNYWR6zedQeIg dslvyZrm9Qqd68XFYDQLmCJZrp6ULR7GMEcxmSaKrUkGNTV5IniheUojm 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAFALARw0+rRDoJ/2dsb2JhbABFDoMPsgqBB4IXAQEBBAEBAQ8BJwIBMRcHCBEEAQEoLh8JCAYBEiKHaAyYPJ8SiwOFPwOIP4xYgQ+EQIg9gWWCJ1k X-IronPort-AV: E=Sophos;i="4.75,669,1330905600"; d="scan'208";a="46641358" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 28 May 2012 05:52:35 +0000 Received: from [10.21.125.62] (sjc-vpn6-1342.cisco.com [10.21.125.62]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4S5qWDI023008; Mon, 28 May 2012 05:52:34 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sun, 27 May 2012 22:52:30 -0700 From: Reinaldo Penno To: Sheng Jiang , Yong Cui , "softwires@ietf.org" Message-ID: Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921EE69DBF@szxeml545-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 05:52:38 -0000 -1 In which significant way this document is different from http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-06 ? We can insert one paragraph in the above draft and allow public IPs since NAT is optional. The two documents even use DHCPv4ov6 as provisioning. On 5/27/12 6:32 PM, "Sheng Jiang" wrote: >The document looks mature for being advanced. > >Sheng Jiang > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >> Behalf Of Yong Cui >> Sent: Sunday, May 27, 2012 10:31 PM >> To: softwires@ietf.org >> Cc: Yong Cui >> Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6- >> 01 >> >> Hi folks, >> >> This is a wg last call on draft-ietf-softwire-public-4over6-01. >> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >> >> As usual, please send editorial comments to the authors and >> substantive comments to the mailing list. >> >> This wg last call will end on 2012 June 10 at 12pm EDT. >> >> >> Yong & Alain >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From simon.perreault@viagenie.ca Mon May 28 07:11:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4016E21F85BE for ; Mon, 28 May 2012 07:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whb5wc-ptpJa for ; Mon, 28 May 2012 07:11:16 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 94D7321F85BB for ; Mon, 28 May 2012 07:11:16 -0700 (PDT) Received: from [192.168.0.100] (modemcable010.192-131-66.mc.videotron.ca [66.131.192.10]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 174B940031; Mon, 28 May 2012 10:11:15 -0400 (EDT) Message-ID: <4FC38782.8020207@viagenie.ca> Date: Mon, 28 May 2012 10:11:14 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yong Cui References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 14:11:17 -0000 On 2012-05-27 10:34, Yong Cui wrote: > This is a wg last call on draft-ietf-softwire-dslite-multicast-02. Section 6.1 introduces IGMP/MLD translation, but I fear it is very underspecified. Our own effort at specifying IGMP/MLD translation is in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite multicast would be better served by referencing our draft instead. So I would suggest replacing section 6.1 by a reference to the draft above, which we hope to have adopted in the PIM WG shortly. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From xmw@cernet.edu.cn Mon May 28 17:49:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD90D21F877A for ; Mon, 28 May 2012 17:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.755 X-Spam-Level: X-Spam-Status: No, score=-95.755 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S15vdkcHeWSe for ; Mon, 28 May 2012 17:49:40 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5994F21F8777 for ; Mon, 28 May 2012 17:49:38 -0700 (PDT) Received: from win7-PC (unknown [101.5.202.75]) by centos (Coremail) with SMTP id AQAAf3DbOQcgHMRPuAELAA--.43497S2; Tue, 29 May 2012 08:45:20 +0800 (CST) Date: Tue, 29 May 2012 08:49:33 +0800 From: "Mingwei Xu" To: "Yong Cui" , "Softwires WG" References: Message-ID: <201205282232590217640@cernet.edu.cn> X-mailer: Foxmail 6, 15, 201, 26 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: AQAAf3DbOQcgHMRPuAELAA--.43497S2 X-Coremail-Antispam: 1UD129KBjvdXoW7XFyxGrW3Gr48Gr13tw1UJrb_yoWfAFX_Ka 4UJ3W8Jr4UAw4UKr4xArsrtr9xAF4jgryUXFyDJrsrXr1xAr4DJrn3JrW2gr1xXryUJr17 Jryxtry8C3y7WjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbsxYjsxI4VW7JwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWx JwA2z4x0Y4vEx4A2jsIE14v26r4j6F4UM28EF7xvwVC2z280aVCY1x0267AKxVW8JVW8Jr 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0 cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8Jw ACjcxG0xvY0x0EwIxGrwACjcxG0xvY0x0EwIxGrVCF72vEw4AK0wACY4xI67k04243AVAK zVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AKxV WUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI 7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Gr0_Xr1lIxAIcVC0I7IYx2IY6xkF7I0E14v26r 4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWUCVW8JwCI42IY6I8E87Iv67AKxVW8JVWxJwCI 42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0x ZFpf9x0zRbtxhUUUUU= X-CM-SenderInfo: x0pzquphuqv3oohg3hdfq/ Cc: Yong Cui Subject: Re: [Softwires] Call for adoption of Softwire Mesh ManagementInformation Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 00:49:40 -0000 U3VwcG9ydCB0aGUgYWRvcHRpb24uDQoNCk1pbmd3ZWkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tCQkJ CSANCk1pbmd3ZWkgWHUNCjIwMTItMDUtMjgNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kt6K8/sjLo7pZb25nIEN1aQ0Kt6LL zcjVxtqjujIwMTItMDUtMjcgMjI6Mzk6MTANCsrVvP7Iy6O6U29mdHdpcmVzIFdHDQqzrcvNo7pZ b25nIEN1aQ0K1vfM4qO6W1NvZnR3aXJlc10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgU29mdHdpcmUg TWVzaCBNYW5hZ2VtZW50SW5mb3JtYXRpb24gQmFzZSAoTUlCKQ0KDQpIaSBmb2xrcywNCg0KQXMg d2UgZGlzY3Vzc2VkIG9uIFNvZnR3aXJlIE1lc2ggTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNl IChNSUIpDQppbiBQYXJpcyBtZWV0aW5nLCB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gYXNrIGZv ciBXRyBhZG9wdGlvbiBvbiB0aGUNCm1haWxpbmcgbGlzdC4gUGxlYXNlIHJldmlldyB0aGlzIGRv Y3VtZW50IGFuZCBzZW5kIHlvdXIgY29tbWVudHMNCihlc3BlY2lhbGx5IHlvdXIgb3BpbmlvbiBv biB0aGUgYWRvcHRpb24gd2l0aCB5b3VyIHJlYXNvbnMpIHRvIHRoZQ0KbWFpbGluZyBsaXN0IGJ5 IHR3byB3ZWVrcywgaS5lLiBKdW5lIDEwLg0KDQpGWUk6DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWN1aS1zb2Z0d2lyZS1tZXNoLW1pYi8NCg0KDQpZb25nICYgQWxhaW4N Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29m dHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KLg0K From xmw@cernet.edu.cn Mon May 28 17:49:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD30C21F8778 for ; Mon, 28 May 2012 17:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.755 X-Spam-Level: X-Spam-Status: No, score=-95.755 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoWxzqotaQWD for ; Mon, 28 May 2012 17:49:40 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 598EC21F8776 for ; Mon, 28 May 2012 17:49:38 -0700 (PDT) Received: from win7-PC (unknown [101.5.202.75]) by centos (Coremail) with SMTP id AQAAf3DbOQcgHMRPuAELAA--.43497S4; Tue, 29 May 2012 08:45:23 +0800 (CST) Date: Tue, 29 May 2012 08:49:36 +0800 From: "Mingwei Xu" To: "Yong Cui" , "softwires@ietf.org" References: Message-ID: <201205282235330711523@cernet.edu.cn> X-mailer: Foxmail 6, 15, 201, 26 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: AQAAf3DbOQcgHMRPuAELAA--.43497S4 X-Coremail-Antispam: 1UD129KBjvdXoW7JF4rJr48tF47Jr1DZr1kXwb_yoW3Zrg_uF yUJF18Jr1UJrWUKw4fJrnxtrnIqr4UXw4UAryDJFsrXr17Ar4DJwn7JrW7Wr1UWryUG3sr GryxXr15C3yUujkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbg8YjsxI4VW7JwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l82xGYIkIc2x26280x7 IE14v26r15M28IrcIa0xkI8VCY1x0267AKxVWUCVW8JwA2ocxC64kIII0Yj41l84ACjcxK 6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7 xvwVC2z280aVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E 0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67 AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48I cxkI7VAKI48JM4x0Y48IcxkI7VAKI48G6xCjnVAKz4kxM4xvF2IEb7IF0Fy264kE64k0F2 4lFcxC0VAYjxAxZF0Ex2IqxwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18 MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4 1lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1l IxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4 A2jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7x R_Fks3UUUUU== X-CM-SenderInfo: x0pzquphuqv3oohg3hdfq/ Cc: Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 00:49:40 -0000 c3VwcG9ydC4NCg0KTWluZ3dlaQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0JCQkJIA0KTWluZ3dlaSBY dQ0KMjAxMi0wNS0yOA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQq3orz+yMujullvbmcgQ3VpDQq3osvNyNXG2qO6MjAxMi0w NS0yNyAyMjo0MDozNQ0KytW8/sjLo7pzb2Z0d2lyZXNAaWV0Zi5vcmcNCrOty82jullvbmcgQ3Vp DQrW98zio7pbU29mdHdpcmVzXSBXRyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1w dWJsaWMtNG92ZXI2LTAxDQoNCkhpIGZvbGtzLA0KDQpUaGlzIGlzIGEgd2cgbGFzdCBjYWxsIG9u IGRyYWZ0LWlldGYtc29mdHdpcmUtcHVibGljLTRvdmVyNi0wMS4NCmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1wdWJsaWMtNG92ZXI2Lw0KDQpBcyB1 c3VhbCwgcGxlYXNlIHNlbmQgZWRpdG9yaWFsIGNvbW1lbnRzIHRvIHRoZSBhdXRob3JzIGFuZA0K c3Vic3RhbnRpdmUgY29tbWVudHMgdG8gdGhlIG1haWxpbmcgbGlzdC4NCg0KVGhpcyB3ZyBsYXN0 IGNhbGwgd2lsbCBlbmQgb24gMjAxMiBKdW5lIDEwIGF0IDEycG0gRURULg0KDQoNCllvbmcgJiBB bGFpbg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCi4NCg== From xmw@cernet.edu.cn Mon May 28 17:56:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65721F8745 for ; Mon, 28 May 2012 17:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.755 X-Spam-Level: X-Spam-Status: No, score=-95.755 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwFhxInCWqcw for ; Mon, 28 May 2012 17:56:19 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id E69E121F8748 for ; Mon, 28 May 2012 17:56:13 -0700 (PDT) Received: from win7-PC (unknown [101.5.202.75]) by centos (Coremail) with SMTP id AQAAf3DbOQcgHMRPuAELAA--.43497S3; Tue, 29 May 2012 08:45:23 +0800 (CST) Date: Tue, 29 May 2012 08:49:36 +0800 From: "Mingwei Xu" To: "Yong Cui" , "softwires@ietf.org" References: Message-ID: <201205282234146343056@cernet.edu.cn> X-mailer: Foxmail 6, 15, 201, 26 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-CM-TRANSID: AQAAf3DbOQcgHMRPuAELAA--.43497S3 X-Coremail-Antispam: 1UD129KBjvdXoW7XFyxGrW3Gr1DGFW8AF1DWrg_yoWfJFg_uF W8JF18KF1jyw4UKrWxJrnrtwnIqr4UXw4UZryDArsrZr17Ar4DtwnrJrW2gr1UWryrG347 Jr1FqryYk3yUWjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbg8YjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l82xGYIkIc2x26280x7 IE14v26r18M28IrcIa0xkI8VCY1x0267AKxVWUXVWUCwA2ocxC64kIII0Yj41l84ACjcxK 6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7 xvwVC2z280aVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E 0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67 AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48I cxkI7VAKI48JM4x0Y48IcxkI7VAKI48G6xCjnVAKz4kxM4xvF2IEb7IF0Fy264kE64k0F2 4lFcxC0VAYjxAxZF0Ex2IqxwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18 MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr4 1lIxAIcVC0I7IYx2IY67AKxVW8JVW5JwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1l IxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r4j6F4UMIIF0xvEx4 A2jsIEc7CjxVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7I U8dR63UUUUU== X-CM-SenderInfo: x0pzquphuqv3oohg3hdfq/ Cc: Yong Cui Subject: Re: [Softwires] WG last call ondraft-ietf-softwire-stateless-4v6-motivation-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 00:56:20 -0000 U3VwcG9ydCB0aGUgYWRvcHRpb24uDQoNCk1pbmd3ZWkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tCQkJ CSANCk1pbmd3ZWkgWHUNCjIwMTItMDUtMjgNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0Kt6K8/sjLo7pZb25nIEN1aQ0Kt6LL zcjVxtqjujIwMTItMDUtMjcgMjI6MzU6MzUNCsrVvP7Iy6O6c29mdHdpcmVzQGlldGYub3JnDQqz rcvNo7pZb25nIEN1aQ0K1vfM4qO6W1NvZnR3aXJlc10gV0cgbGFzdCBjYWxsIG9uZHJhZnQtaWV0 Zi1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2LW1vdGl2YXRpb24tMDENCg0KSGkgZm9sa3MsDQoNClRo aXMgaXMgYSB3ZyBsYXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1zdGF0ZWxlc3MtNHY2 LW1vdGl2YXRpb24tMDEuDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtc29mdHdpcmUtc3RhdGVsZXNzLTR2Ni1tb3RpdmF0aW8NCm4vDQoNCkFzIHVzdWFsLCBwbGVh c2Ugc2VuZCBlZGl0b3JpYWwgY29tbWVudHMgdG8gdGhlIGF1dGhvcnMgYW5kDQpzdWJzdGFudGl2 ZSBjb21tZW50cyB0byB0aGUgbWFpbGluZyBsaXN0Lg0KDQpUaGlzIHdnIGxhc3QgY2FsbCB3aWxs IGVuZCBvbiAyMDEyIEp1bmUgMTAgYXQgMTJwbSBFRFQuDQoNCg0KWW9uZyAmIEFsYWluDQoNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdp cmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KLg0K From eleven.fuyu@huawei.com Mon May 28 20:49:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4AF21F8715 for ; Mon, 28 May 2012 20:49: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKPa+04qRcvk for ; Mon, 28 May 2012 20:49:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 28F7721F8714 for ; Mon, 28 May 2012 20:49:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGP84606; Mon, 28 May 2012 23:49:55 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 May 2012 20:47:55 -0700 Received: from SZXEML434-HUB.china.huawei.com (10.72.61.62) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 May 2012 20:47:54 -0700 Received: from SZXEML512-MBX.china.huawei.com ([169.254.5.169]) by szxeml434-hub.china.huawei.com ([10.72.61.62]) with mapi id 14.01.0323.003; Tue, 29 May 2012 11:47:50 +0800 From: "Fuyu (Eleven)" To: Yong Cui Thread-Topic: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) Thread-Index: AQHNPBcUFKHmqfiYkE+s9TrQM6Gea5bgIk7w Date: Tue, 29 May 2012 03:47:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.119] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG Subject: Re: [Softwires] Call for adoption of Softwire Mesh Management Information Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 03:49:57 -0000 Support the adoption for WG item Cheers=20 Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Yong Cui Sent: Sunday, May 27, 2012 10:43 PM To: Softwires WG Cc: Yong Cui Subject: [Softwires] Call for adoption of Softwire Mesh Management Informat= ion Base (MIB) Hi folks, As we discussed on Softwire Mesh Management Information Base (MIB) in Paris meeting, the chairs would like to ask for WG adoption on the mailing list. Please review this document and send your comments (especially your opinion on the adoption with your reasons) to the mailing list by two weeks, i.e. June 10. FYI: http://datatracker.ietf.org/doc/draft-cui-softwire-mesh-mib/ Yong & Alain _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From cuiyong@tsinghua.edu.cn Tue May 29 23:54:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04321F86E4 for ; Tue, 29 May 2012 23:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.496 X-Spam-Level: * X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgNmIeQbCycG for ; Tue, 29 May 2012 23:54:21 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A10321F86F2 for ; Tue, 29 May 2012 23:54:21 -0700 (PDT) Received: from [115.171.173.74] (helo=[192.168.1.121]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1SZcnS-0008J5-6z for softwires@ietf.org; Wed, 30 May 2012 14:54:18 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 30 May 2012 14:53:58 +0800 From: Yong Cui To: Softwires WG Message-ID: Thread-Topic: Call for adoption of DS-Lite Management Information Base (MIB) Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Softwires] Call for adoption of DS-Lite Management Information Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 06:54:22 -0000 Hi folks, As we discussed on DS-Lite Management Information Base (MIB) in Paris meeting, the chairs would like to ask for WG adoption on mailing list. Please review this document and send your comments (especially your opinion on the adoption with your reasons) to the mailing list by two weeks, i.e. June 13. FYI: http://datatracker.ietf.org/doc/draft-fu-softwire-dslite-mib/ Yong & Alain From ichiroumakino@gmail.com Wed May 30 06:55:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD8B21F8643 for ; Wed, 30 May 2012 06:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWTVBk-32GsL for ; Wed, 30 May 2012 06:55:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 910ED21F8627 for ; Wed, 30 May 2012 06:55:53 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1649548eaa.31 for ; Wed, 30 May 2012 06:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XsgCwwZhfcGeSoECnPAPae8cs7KAFUfWap63hxg17tg=; b=AFOT+6WPY3+lYWy/grqn7x651yIjcy79h9f2iL0/xTfKH/DwPqiEITaWo8fKI1H3SA PcYIdPu4j/1Q2Y9J0+ahW4HwEQ/lx42jdrevy+cVgfsljCFfz0eupX4AqwR8pD5f+cf8 KMZ/2IAV8Ae3hJTNSFsu7zDc+KaShxS5IZ6NuR0FScBv9LcArAEzBxxqINz+lG+iu2E6 wdlyneNYAFG1kKEEhulDwpArmNrsiVlfWoXEkAmHhA4UfQn7dYX7IaJq68tM+4hG/koJ gDSC/wAB9aK6XMU3c7AGPDAmbCsuTuaKJSaepN8i8hQ0C3gSxG0D61TeM2dN7CH7b7GO YyNA== Received: by 10.14.96.70 with SMTP id q46mr6102644eef.231.1338386152637; Wed, 30 May 2012 06:55:52 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-91.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id p41sm32883641eef.5.2012.05.30.06.55.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 May 2012 06:55:51 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 30 May 2012 15:55:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Yong Cui X-Mailer: Apple Mail (2.1278) Cc: softwires@ietf.org Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 13:55:54 -0000 public 4over6 is exactly the same as MAP in hub and spoke mode with one = mapping rule per subscriber. and if Reinaldo is correct, also the same as b4-translated-ds-lite. we have 4 mechanisms doing almost the exact same thing (4rd, MAP, = 4over6, B4-translated). I would suggest that we do not progress this document now, but pass it = through the same review process that 4rd/MAP is going through. unless we = can reach consensus on pruning prior to that. cheers, Ole > This is a wg last call on draft-ietf-softwire-public-4over6-01. > http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >=20 > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. >=20 > This wg last call will end on 2012 June 10 at 12pm EDT. >=20 >=20 > Yong & Alain >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Tina.Tsou.Zouting@huawei.com Wed May 30 08:35:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDE311E8083 for ; Wed, 30 May 2012 08:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zv1IhNg4x6x for ; Wed, 30 May 2012 08:35:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3011E8080 for ; Wed, 30 May 2012 08:35:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGK21345; Wed, 30 May 2012 11:35:40 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 May 2012 08:33:12 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 30 May 2012 08:33:07 -0700 From: Tina TSOU To: Yong Cui Thread-Topic: [Softwires] Call for adoption of DS-Lite Management Information Base (MIB) Thread-Index: AQHNPjEW1ldzBQrYvUm73ZTSyPLxWZbidqOS Date: Wed, 30 May 2012 15:33:06 +0000 Message-ID: <35F88A91-E324-4A6D-891D-ABA8B5DDFA6D@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG Subject: Re: [Softwires] Call for adoption of DS-Lite Management Information Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 15:35:41 -0000 Support. Tina On May 29, 2012, at 11:54 PM, "Yong Cui" wrote: > Hi folks, >=20 > As we discussed on DS-Lite Management Information Base (MIB) > in Paris meeting, the chairs would like to ask for WG adoption on > mailing list. Please review this document and send your comments > (especially your opinion on the adoption with your reasons) to the > mailing list by two weeks, i.e. June 13. >=20 > FYI: > http://datatracker.ietf.org/doc/draft-fu-softwire-dslite-mib/ >=20 >=20 > Yong & Alain >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From bingxuere@gmail.com Wed May 30 18:24:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C762911E80FA for ; Wed, 30 May 2012 18:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4y1D0bHkG+d for ; Wed, 30 May 2012 18:24:18 -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 E513011E80D2 for ; Wed, 30 May 2012 18:24:17 -0700 (PDT) Received: by yenq13 with SMTP id q13so454686yen.31 for ; Wed, 30 May 2012 18:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ypoVhopKeduGBft+mYCJGNqlvSytpebO6llsAQpd9uk=; b=zI9hu0QFLfvNxV8ighNIhS5uFeHy0nK25rhksuZ9J+mynVdjgeRqZs8GTQAlNnbNzh D/tzjdNH2lQO8SLDUch81ljK3TJ739uGzvpDootLdmsfz+RinPAW95WuK7p7nnRo6Cm/ ncHQX4UDGEeELhDw5IXW/nf5OSrvZIWCGzf7B5E7/QDrmaBItYh4rIaZ6BxQ7jIAphMd xNLWYBoefmSRfNjChq7vAQHPBTsnZZfbhXSx1g5Ocf0046WXoaD+PoCiq2X8ysYydfoi LFQGwH6T8Sje92rql9avL6QnOOTc2dE9kqZAwUpMLuGR2bNy9hnEVxBCo7QyO1KxXmzS 7fqA== Received: by 10.50.181.225 with SMTP id dz1mr12298033igc.2.1338427457349; Wed, 30 May 2012 18:24:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 30 May 2012 18:23:37 -0700 (PDT) In-Reply-To: References: <5D36713D8A4E7348A7E10DF7437A4B921EE69DBF@szxeml545-mbx.china.huawei.com> From: Qiong Date: Thu, 31 May 2012 09:23:37 +0800 Message-ID: To: Reinaldo Penno Content-Type: multipart/alternative; boundary=14dae934098127283f04c14aed7f Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 01:24:18 -0000 --14dae934098127283f04c14aed7f Content-Type: text/plain; charset=UTF-8 Hi Reinaldo, In my understanding, public 4over6 is mainly designed for host-orientied server behind the CPE. So the senario of public 4over6 is different from lightweight 4over6. It is better to be described seperately. I support it to be advanced. Thanks. Best wishes Qiong On Mon, May 28, 2012 at 1:52 PM, Reinaldo Penno wrote: > -1 > > In which significant way this document is different from > http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-06 ? > > We can insert one paragraph in the above draft and allow public IPs since > NAT is optional. The two documents even use DHCPv4ov6 as provisioning. > > > > On 5/27/12 6:32 PM, "Sheng Jiang" wrote: > > >The document looks mature for being advanced. > > > >Sheng Jiang > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > >> Behalf Of Yong Cui > >> Sent: Sunday, May 27, 2012 10:31 PM > >> To: softwires@ietf.org > >> Cc: Yong Cui > >> Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6- > >> 01 > >> > >> Hi folks, > >> > >> This is a wg last call on draft-ietf-softwire-public-4over6-01. > >> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ > >> > >> As usual, please send editorial comments to the authors and > >> substantive comments to the mailing list. > >> > >> This wg last call will end on 2012 June 10 at 12pm EDT. > >> > >> > >> Yong & Alain > >> > >> > >> > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --14dae934098127283f04c14aed7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Reinaldo,

In my understanding, public 4over6 is mainly designed f= or host-orientied server behind the CPE. So the senario of public 4over6 is= different from lightweight 4over6. It is better to be described seperately= .

I support it to be advanced. Thanks.

Best wishes
Qiong
On Mon, May 28, 2012 at 1:52 PM, Reinaldo Penno= <repenno@cisco.com> wrote:
-1

In which significant way this document is different from
http://tools.ietf.org/html/draft-cui-softwire-b4-= translated-ds-lite-06 ?

We can insert one paragraph in the above draft and allow public IPs since NAT is optional. The two documents even use DHCPv4ov6 as provisioning.



On 5/27/12 6:32 PM, "Sheng Jiang" <jiangsheng@huawei.com> wrote:

>The document looks mature for being advanced.
>
>Sheng Jiang
>
>> -----Original Message-----
>> From: softwires-boun= ces@ietf.org [mailto:soft= wires-bounces@ietf.org] On
>> Behalf Of Yong Cui
>> Sent: Sunday, May 27, 2012 10:31 PM
>> To: softwires@ietf.org >> Cc: Yong Cui
>> Subject: [Softwires] WG last call on draft-ietf-softwire-public-4o= ver6-
>> 01
>>
>> Hi folks,
>>
>> This is a wg last call on draft-ietf-softwire-public-4over6-01. >> http://datatracker.ietf.org/doc/draft-ietf-s= oftwire-public-4over6/
>>
>> As usual, please send editorial comments to the authors and
>> substantive comments to the mailing list.
>>
>> This wg last call will end on 2012 June 10 at 12pm EDT.
>>
>>
>> Yong & Alain
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


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

--14dae934098127283f04c14aed7f-- From bingxuere@gmail.com Wed May 30 18:28:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F26911E80FA for ; Wed, 30 May 2012 18:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh5PvzmSx4yd for ; Wed, 30 May 2012 18:28:21 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED2111E80D2 for ; Wed, 30 May 2012 18:28:20 -0700 (PDT) Received: by yhq56 with SMTP id 56so325917yhq.31 for ; Wed, 30 May 2012 18:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UcqylV9KzPCwSn8uzDfi8wtGLMIjy9LZl1Hj6JtCrJU=; b=EskDEYyeUgnwhLNcr1bC9jHhUJP0ulWD5dUcmnQGPPdbTc+59F1bI577MwFLm3HLM3 gIxCL6UMw1plUhnp0FzfbRyjsrUU2DI1lEkCw4Z05LwJQzIa3/5N58RCAQsQ7UtJP6YH WgOqvEDddtTxNh1q7xyHmkoeFplKbkvt+3k1GeFeGBJh4lbxRK+glmqwhuP9uowfCIow CZ6ACK1irROyEhSIQI3upX2A0/Gf5WxYOZzlgzsCWZhJv92I6T/M6wZwum4OkQQo9MG4 +Q5hFgQIjxFe/ZVhDHxqCnpvylYsDc4Jx96gREoOMKUTruOm/A2z2uq1Lxv+2MAdkvup uP8g== Received: by 10.50.169.65 with SMTP id ac1mr12566186igc.54.1338427700403; Wed, 30 May 2012 18:28:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 30 May 2012 18:27:40 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Thu, 31 May 2012 09:27:40 +0800 Message-ID: To: Yong Cui Content-Type: multipart/alternative; boundary=e89a8f3bac1fa3dd5a04c14afb4f Cc: Softwires WG Subject: Re: [Softwires] Call for adoption of DS-Lite Management Information Base (MIB) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 01:28:21 -0000 --e89a8f3bac1fa3dd5a04c14afb4f Content-Type: text/plain; charset=UTF-8 +1 support. I think it is mature enough. Best wishes Qiong On Wed, May 30, 2012 at 2:53 PM, Yong Cui wrote: > Hi folks, > > As we discussed on DS-Lite Management Information Base (MIB) > in Paris meeting, the chairs would like to ask for WG adoption on > mailing list. Please review this document and send your comments > (especially your opinion on the adoption with your reasons) to the > mailing list by two weeks, i.e. June 13. > > FYI: > http://datatracker.ietf.org/doc/draft-fu-softwire-dslite-mib/ > > > Yong & Alain > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --e89a8f3bac1fa3dd5a04c14afb4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 support. I think it is mature enough.

Best wishes
Qiong
On Wed, May 30, 2012 at 2:53 PM, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:
Hi folks,

As we discussed on DS-Lite Management Information Base (MIB)
in Paris meeting, the chairs would like to ask for WG adoption on
mailing list. Please review this document and send your comments
(especially your opinion on the adoption with your reasons) to the
mailing list by two weeks, i.e. June 13.

FYI:
http://datatracker.ietf.org/doc/draft-fu-softwire-dslite-m= ib/


Yong & Alain




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

--e89a8f3bac1fa3dd5a04c14afb4f-- From bingxuere@gmail.com Wed May 30 19:08:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B761D11E80D2 for ; Wed, 30 May 2012 19:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K43LXGSskGSk for ; Wed, 30 May 2012 19:08:06 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3119711E80FA for ; Wed, 30 May 2012 19:08:06 -0700 (PDT) Received: by yhq56 with SMTP id 56so346244yhq.31 for ; Wed, 30 May 2012 19:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=K+o9rQyzbcCd65/MznvAZMGiCq5ffp7glQYoLRcp1Ic=; b=b1fVBCa5hNSf88KzeQoyUX+b41xh19VPWZqD42VtSq6zkDcpEYYaj4WMZfqnpVQqHj qtyMq07dZzTrBAoX5QQW1IWA7QoK+16V8DSOwp1PCXdZw6f1oEoXwWastIV4BvDX466a x3or5mTYgVkQqctz2tG+NdC+v4pDaqDTceaRX/rsytYRtMCEp+wYaj9OAKF9MLtQB/09 pC6cR9Be+xI504VzuozXwpIwwcObq3ftzgJdP1pxzMq8eUqFBm+1/71bPgsOW9lk8vXS KMBofq54W2OD4wIghj1+AIRWGpp2lyDoyhIg6LSdJpSBJFjumWX61vXmb9jMmzr6mKge MhGg== Received: by 10.42.145.7 with SMTP id d7mr25262icv.45.1338430085629; Wed, 30 May 2012 19:08:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 30 May 2012 19:07:25 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Thu, 31 May 2012 10:07:25 +0800 Message-ID: To: Yong Cui Content-Type: multipart/alternative; boundary=90e6ba6136b8cf87a604c14b89dc Cc: softwires@ietf.org Subject: Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 02:08:06 -0000 --90e6ba6136b8cf87a604c14b89dc Content-Type: text/plain; charset=UTF-8 +1 support. On Sun, May 27, 2012 at 10:28 PM, Yong Cui wrote: > Hi folks, > > This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01. > http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio > n/ > > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. > > This wg last call will end on 2012 June 10 at 12pm EDT. > > > Yong & Alain > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --90e6ba6136b8cf87a604c14b89dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 support.

On Sun, May 27, 2012 at 10:28= PM, Yong Cui <cuiyong@tsinghua.edu.cn> wrote:
Hi folks,

This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01.<= br> http://datatracker.ietf.org/doc/draft-i= etf-softwire-stateless-4v6-motivatio
n/

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

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


Yong & Alain



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

--90e6ba6136b8cf87a604c14b89dc-- From repenno@cisco.com Wed May 30 19:10:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0569A11E8136 for ; Wed, 30 May 2012 19:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.9 X-Spam-Level: X-Spam-Status: No, score=-9.9 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYBL0K68TznD for ; Wed, 30 May 2012 19:10:45 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D1AD411E8135 for ; Wed, 30 May 2012 19:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=9955; q=dns/txt; s=iport; t=1338430244; x=1339639844; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=hzXHZmE1Hi9WZ0VAEyzzscb7oqqEUl0d9suTFbgzo7A=; b=QmdOwSmyyUfrF4yYQ0xlWfIGn+2LygWyG4kuMstwIWTtyp9okfbI1R/l W2QCm4DXXM2k2SofuRgybCommyzG6FwxKX+sRZGDN4yA7DvPqw6bYa/rt X+HKWTj66eVKtfxBRx4/lUCu9JKbUBShF1Tn2gFivR0mUsv1F0qbtlOOL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0GAAXSxk+rRDoI/2dsb2JhbABEgkVYoECHRQGHaoEJgQeCFwEBAQMBAQEBDwEqMQsFBwcIEQMBAQEBJygGHwkIBg4FIodbAwYEDJkxlhwNiU6KJ2GFRgOIQIxYgQ+EQIUpgxWBZoMA X-IronPort-AV: E=Sophos;i="4.75,688,1330905600"; d="scan'208,217";a="46970742" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 31 May 2012 02:10:43 +0000 Received: from [10.21.124.164] (sjc-vpn6-1188.cisco.com [10.21.124.164]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4V2AVod004251; Thu, 31 May 2012 02:10:33 GMT User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 30 May 2012 19:10:29 -0700 From: Reinaldo Penno To: Qiong Message-ID: Thread-Topic: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3421249838_29381909" Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 02:10:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3421249838_29381909 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit If we continue like this somebody will write a draft called draft-ietf-100.64.0.2-00 which tells how we can give this specific address to a CPE. Everything that is in this draft is possible to be done already in at least 3 different ways. Please point what can not be done today with MAP/4rd-U/DS-Lite/L46 that this draft provides. L46/MAP/4rd-U all can give a single, public IP to the CPE. Nobody says you have to give a port range. From: Qiong Date: Thu, 31 May 2012 09:23:37 +0800 To: Reinaldo Penno Cc: Sheng Jiang , Yong Cui , "softwires@ietf.org" Subject: Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 > Hi Reinaldo, > > In my understanding, public 4over6 is mainly designed for host-orientied > server behind the CPE. So the senario of public 4over6 is different from > lightweight 4over6. It is better to be described seperately. > > I support it to be advanced. Thanks. > > Best wishes > Qiong > > On Mon, May 28, 2012 at 1:52 PM, Reinaldo Penno wrote: >> -1 >> >> In which significant way this document is different from >> http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-06 ? >> >> We can insert one paragraph in the above draft and allow public IPs since >> NAT is optional. The two documents even use DHCPv4ov6 as provisioning. >> >> >> >> On 5/27/12 6:32 PM, "Sheng Jiang" wrote: >> >>> >The document looks mature for being advanced. >>> > >>> >Sheng Jiang >>> > >>>> >> -----Original Message----- >>>> >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >>>> >> Behalf Of Yong Cui >>>> >> Sent: Sunday, May 27, 2012 10:31 PM >>>> >> To: softwires@ietf.org >>>> >> Cc: Yong Cui >>>> >> Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6- >>>> >> 01 >>>> >> >>>> >> Hi folks, >>>> >> >>>> >> This is a wg last call on draft-ietf-softwire-public-4over6-01. >>>> >> http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ >>>> >> >>>> >> As usual, please send editorial comments to the authors and >>>> >> substantive comments to the mailing list. >>>> >> >>>> >> This wg last call will end on 2012 June 10 at 12pm EDT. >>>> >> >>>> >> >>>> >> Yong & Alain >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> Softwires mailing list >>>> >> Softwires@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/softwires >>> >_______________________________________________ >>> >Softwires mailing list >>> >Softwires@ietf.org >>> >https://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > --B_3421249838_29381909 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable 
If we continue like this=
 somebody will write a draft called draft-ietf-100.64.0.2-00 which tells how=
 we can give this specific address to a CPE.

Everything that is in this= draft is possible to be done already in at least 3 different ways. Ple= ase point what can not be done today with MAP/4rd-U/DS-Lite/L46 that this dr= aft provides. L46/MAP/4rd-U all can give a single, public I= P to the CPE. Nobody says you have to give a port range.


From: Qiong <bingxuere@gmail.com>
Date: Thu, 31 May 2012 09:23:37 +0800
To: Reinaldo Penno <= repenno@cisco.com>
Cc: Shen= g Jiang <jiangsheng@huawei.com= >, Yong Cui <cuiyong@tsinghua= .edu.cn>, "softwires@ietf.org= " <softwires@ietf.org>
Subject: Re: [Softwires] WG last call on = draft-ietf-softwire-public-4over6-01

Hi Reinaldo,

In my understanding, pub= lic 4over6 is mainly designed for host-orientied server behind the CPE. So t= he senario of public 4over6 is different from lightweight 4over6. It is bett= er to be described seperately.

I support it to be advanced. Thanks.
Best wishes
Qiong

On Mon, May 28, 2= 012 at 1:52 PM, Reinaldo Penno <repenno@cisco.com> wrote:
-1

In which significant way this document is different from
http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-06= ?

We can insert one paragraph in the above draft and allow public IPs since NAT is optional. The two documents even use DHCPv4ov6 as provisioning.
<= div class=3D"HOEnZb">



On 5/27/12 6:32 PM, "Sheng Jiang" <jiangsheng@huawei.com> wrote:

>The document looks mature for being advanced.
>
>Sheng Jiang
>
>> -----Original Message-----
>> From: softwires-bounce= s@ietf.org [mailto:softwires= -bounces@ietf.org] On
>> Behalf Of Yong Cui
>> Sent: Sunday, May 27, 2012 10:31 PM
>> To: softwires@ietf.org
= >> Cc: Yong Cui
>> Subject: [Softwires] WG last call on draft-ietf-softwire-public-4o= ver6-
>> 01
>>
>> Hi folks,
>>
>> This is a wg last call on draft-ietf-softwire-public-4over6-01. >> http://datatracker.ietf.org/doc/draft-ietf-softwi= re-public-4over6/
>>
>> As usual, please send editorial comments to the authors and
>> substantive comments to the mailing list.
>>
>> This wg last call will end on 2012 June 10 at 12pm EDT.
>>
>>
>> Yong & Alain
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires


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

--B_3421249838_29381909--