From internet-drafts@ietf.org Tue Jul 2 09:15:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59D621F9E5A; Tue, 2 Jul 2013 09:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 QX-pZDpOJ0kO; Tue, 2 Jul 2013 09:15:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5912921F99C3; Tue, 2 Jul 2013 09:15:49 -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.51.p2 Message-ID: <20130702161549.30611.29338.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 09:15:49 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-t-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:15:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port using Translation (MAP-T) Author(s) : Xing Li Congxiao Bao Wojciech Dec Ole Troan Satoru Matsushima Tetsuya Murakami Filename : draft-ietf-softwire-map-t-02.txt Pages : 32 Date : 2013-07-02 Abstract: This document specifies the "Mapping of Address and Port" double stateless NAT64 translation based solution (MAP-T) for providing shared or uniquely addressed IPv4 device connectivity to and across an IPv6 domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-t There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-t-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-t-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sarikaya2012@gmail.com Tue Jul 2 09:53:35 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B333B11E80AD for ; Tue, 2 Jul 2013 09:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 mRZNQOLIKPqx for ; Tue, 2 Jul 2013 09:53:35 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0A21F9E3B for ; Tue, 2 Jul 2013 09:53:34 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so3620957lba.30 for ; Tue, 02 Jul 2013 09:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=pmnomg5m4hdRNt4su1Xv4S7vFn1Gy4QG+IqJj2M5O8U=; b=fMboVCdSBDSTvUsOAKjKgSnb6A3pesbsipVWrGg/HMoGQxMGIug6ofnIWJ3Oic+pME lH14W16jt2pzdZ9tBjE4tW0/XshuTdKdRXuASnJ8eLH5UQgwWv0xmSshj6pg6H7+YyZ/ pFkwVx+/DUoqRoPYtUknMMGfspxrDjTkDi+coFxklDA6NLxZEVbAqUKiqg2Y6MsrbyrE nHnxPZkJIKK3crzDZK3kD3fBxPb8bc2hMME1uBYFkKtHFf2jjQ2M4gRBXJbRwDd40FFb GohjP4adCkPW9Vsan6+JQrLPT2MdGKR8NvliXN7Jt6dgBU2EOKhMldhz7egverQ0Qu2U yyEw== MIME-Version: 1.0 X-Received: by 10.152.21.131 with SMTP id v3mr14943681lae.50.1372784013437; Tue, 02 Jul 2013 09:53:33 -0700 (PDT) Received: by 10.114.176.37 with HTTP; Tue, 2 Jul 2013 09:53:33 -0700 (PDT) In-Reply-To: <20130702165209.7407.12113.idtracker@ietfa.amsl.com> References: <20130702165209.7407.12113.idtracker@ietfa.amsl.com> Date: Tue, 2 Jul 2013 11:53:33 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: multipart/alternative; boundary=089e0158b6947970fd04e08a2fb0 Subject: [Softwires] New Version Notification for draft-sarikaya-softwire-map-multicast-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 16:53:35 -0000 --089e0158b6947970fd04e08a2fb0 Content-Type: text/plain; charset=ISO-8859-1 A new version of I-D, draft-sarikaya-softwire-map-multicast-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-softwire-map-multicast Revision: 00 Title: Multicast Support for Mapping of Address and Port Protocol Creation date: 2013-07-02 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-softwire-map-multicast-00.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-softwire-map-multicast Htmlized: http://tools.ietf.org/html/draft-sarikaya-softwire-map-multicast-00 Abstract: This memo specifies MAP-E's multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In the encapsulation solution for encapsulation variant of Mapping of Address and Port (MAP), MAP-E, IGMP Proxy at the MAP-E Customer Edge router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGMP messages to establish multicast state at MAP-E Border Relay so that MAP-E Border Relay can tunnel IPv4 multicast data to IPv4 hosts connected to MAP-E Customer Edge device. In the Translation Multicast solution for the translation variant of MAP, MAP-T and 4rd, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. MAP-T/4rd Border Relay does the reverse translation and joins IPv4 multicast group for MAP-T/4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. The IETF Secretariat --089e0158b6947970fd04e08a2fb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A new version of I-D, draft-sarikaya-softwire-map-multicast-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-sarikaya-softwire-map-multicast
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Multicast Support for Mapping of Address and Por= t Protocol
Creation date: =A0 2013-07-02
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 20
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www= .ietf.org/internet-drafts/draft-sarikaya-softwire-map-multicast-00.txt<= br> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf= .org/doc/draft-sarikaya-softwire-map-multicast
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/= draft-sarikaya-softwire-map-multicast-00


Abstract:
=A0 =A0This memo specifies MAP-E's multicast component so that IPv4 hos= ts
=A0 =A0can receive multicast data from IPv4 servers over an IPv6 network. =A0 =A0In the encapsulation solution for encapsulation variant of Mapping o= f
=A0 =A0Address and Port (MAP), MAP-E, IGMP Proxy at the MAP-E Customer Edge=
=A0 =A0router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGM= P
=A0 =A0messages to establish multicast state at MAP-E Border Relay so that<= br> =A0 =A0MAP-E Border Relay can tunnel IPv4 multicast data to IPv4 hosts
=A0 =A0connected to MAP-E Customer Edge device. =A0In the Translation
=A0 =A0Multicast solution for the translation variant of MAP, MAP-T and 4rd= ,
=A0 =A0IGMP messages are translated into MLD messages at the CE router whic= h
=A0 =A0is IGMP/MLD Proxy and sent to the network in IPv6. =A0MAP-T/4rd Bord= er
=A0 =A0Relay does the reverse translation and joins IPv4 multicast group fo= r
=A0 =A0MAP-T/4rd hosts. =A0Border Relay as multicast router receives IPv4 =A0 =A0multicast data and translates the packet into IPv6 multicast data an= d
=A0 =A0sends downstream on the multicast tree. =A0Member CEs receive multic= ast
=A0 =A0data, translate it back to IPv4 and transmit to the hosts.




The IETF Secretariat


--089e0158b6947970fd04e08a2fb0-- From wdec.ietf@gmail.com Mon Jul 8 03:18:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B9C21F95DC for ; Mon, 8 Jul 2013 03:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vSy0OLAUdrAY for ; Mon, 8 Jul 2013 03:18:36 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C5C0E21F8793 for ; Mon, 8 Jul 2013 03:18:31 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id s1so2199186qcw.1 for ; Mon, 08 Jul 2013 03:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ivEHjBTrVbehQetmCOvbfzwIkCWzbwByA4SeSMkjvcE=; b=j3lCQSf5IhFvSnVbT6BCqVpjIGMSQdnJYbngxrISnJpCZ2B0YjXbKetVV9yw4cJRUM 2AURSx0f/w+pGwphTzAdIdaHZoazMmciBzZDdNZltnpoLLZABQs7/DqCOvcScKbA8+Gp pINuNyB8pDz8ptcTn09WrCzNknRggAE6OhfMOtqSF5gS+U9VWgp1SWl+7AuO3gY09YOu fm05gqutBooPbpQ6YgaHJfYci2bvEif2kTRhhfNV93MzswEAuP3udxBeciyA/G8acVy4 73iAigduc5iMMKfOwxIzuQ8hybXtCnztvREPgptRlGkgZoSDwT6j0TtliIs1p1ZLSbSl hxAA== MIME-Version: 1.0 X-Received: by 10.224.73.193 with SMTP id r1mr10657877qaj.57.1373278711282; Mon, 08 Jul 2013 03:18:31 -0700 (PDT) Received: by 10.49.134.2 with HTTP; Mon, 8 Jul 2013 03:18:31 -0700 (PDT) Date: Mon, 8 Jul 2013 12:18:31 +0200 Message-ID: From: Wojciech Dec To: Softwires-wg Content-Type: multipart/alternative; boundary=001a11c3e0e4c3831d04e0fd5dac Cc: Congxiao Bao Subject: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 10:18:37 -0000 --001a11c3e0e4c3831d04e0fd5dac Content-Type: text/plain; charset=ISO-8859-1 Hi All, I've begun preparing the next ste of changes to the DHCP MAP option draft, and would like to highlight the main changes. - Naming: The name of the option will be changed, tentatively, to OPTION_S46_*. This it in line with the recognition that there is wider applicability of the options. Furthermore the "Mapping" term will be removed from the text, except when describing their use with MAP algorithm. - Default Mapping Rule: The DMR option will be removed, to allow the re-use of the existing AFTR option, if desired and when applicable. - Flags: The flags field will be removed from the options. To accomplish this, what was previously known as the BMR/FMR option, which was using the flag to make the difference, will now be recast as two separate "Basic Rule" and a "Forwarding Rule" Options. - Some of the generic DHCP requirements about known or unknown processing appear to actually conflict with DHCP practice and will be changed, eg an unknown sub-option should not lead to the entire option being discarded. - A new sub-section intended only for clients using the MAP algorithm will be introduced, and will describe how the options apply to MAP provisioning. - Various other editorial changes to bring the text into shape. If you have any initial comments, reactions to the above, please let us know. Regards, W. Dec --001a11c3e0e4c3831d04e0fd5dac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

I've begun preparing the next ste of changes to the DHCP MAP option = draft, and would like to highlight the main changes.

- Naming:= The name of the option will be changed, tentatively, to OPTION_S46_*. This= it in line with the recognition that there is wider applicability of the o= ptions. Furthermore the "Mapping" term will be removed from the t= ext, except when describing their use with MAP algorithm.
- Default Mapping Rule: The DMR option will be removed, to allow the = re-use of the existing AFTR option, if desired and when applicable.
- Flags: The flags field will be removed from the options. To accomplish = this, what was previously known as the BMR/FMR option, which was using the = flag to make the difference, will now be recast as two separate "Basic= Rule" and a "Forwarding Rule" Options.
- Some of the generic DHCP requirements about known or unknown p= rocessing appear to actually conflict with DHCP practice and will be change= d, eg an unknown sub-option should not lead to the entire option being disc= arded.
- A new sub-section intended only for clients using the MAP algo= rithm will be introduced, and will describe how the options apply to MAP pr= ovisioning.
- Various other editorial changes to bring the text in= to shape.

If you have any initial comments, reactions to the above, please = let us know.

Regards,
W. Dec
--001a11c3e0e4c3831d04e0fd5dac-- From robmgl@cisco.com Mon Jul 8 06:21:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB5121F9C37 for ; Mon, 8 Jul 2013 06:21:32 -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 Ex1AJO0iViUm for ; Mon, 8 Jul 2013 06:21:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6D21F9A64 for ; Mon, 8 Jul 2013 06:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2488; q=dns/txt; s=iport; t=1373289686; x=1374499286; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/cb4/LHotyF0pn8E0ONzK1kTJc3z7ICgtWXgWMRzp8s=; b=mKYhox8EYTqIcBHRPP6poZyPIKG2ehtn6Jk1P7x48l0j5JRbYOEY2Dqj b8OQ65loh0VYHE8Y8iQuiG6IKqt7QRJmwumF2jIJLVswL7MZ7loS4o8qk cRv8Yx6KNM/lWMg6oqw+pvaVhbdcPRcHLVCH7aj4tT15wALRQN1V51rlJ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAJ+82lGtJV2a/2dsb2JhbABagwkyRwaDCL1ZF3gWdIIjAQEBBCMRQwIMBgEIEQQBAQMCBh0DAgQwFAEICQEEDgUIARKHdAcFpz6QcoEmjhQxDYJOM2kDlACEfJAfgxGCKA X-IronPort-AV: E=Sophos;i="4.87,1020,1363132800"; d="scan'208";a="232086282" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 08 Jul 2013 13:21:26 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r68DLPqG019023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jul 2013 13:21:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.9]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 08:21:25 -0500 From: "Roberta Maglione (robmgl)" To: "softwires@ietf.org" Thread-Topic: New Version Notification for draft-maglione-softwire-map-t-scenarios-02.txt Thread-Index: Ac573ggw66TOtV3LQWCiVHHYlJrQxw== Date: Mon, 8 Jul 2013 13:21:24 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D24EDB5@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.8.112] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Wojciech Dec \(wdec\)" , Edwin Mallette Subject: Re: [Softwires] New Version Notification for draft-maglione-softwire-map-t-scenarios-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: Mon, 08 Jul 2013 13:21:34 -0000 SGVsbG8sDQpXZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1tYWdsaW9uZS1zb2Z0 d2lyZS1tYXAtdC1zY2VuYXJpb3MuDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t YWdsaW9uZS1zb2Z0d2lyZS1tYXAtdC1zY2VuYXJpb3MtMDINCllvdXIgY29tbWVudHMgYXJlIHdl bGNvbWUuDQpUaGFua3MNCkJlc3QgUmVnYXJkcw0KUm9iZXJ0YQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI3LCAyMDEzIDI6NTUg UE0NClRvOiBXb2pjaWVjaCBEZWMgKHdkZWMpOyBSb2JlcnRhIE1hZ2xpb25lIChyb2JtZ2wpOyBF ZHdpbiBNYWxsZXR0ZTsgVmljdG9yIEt1YXJzaW5naA0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1tYWdsaW9uZS1zb2Z0d2lyZS1tYXAtdC1zY2VuYXJpb3MtMDIu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1hZ2xpb25lLXNvZnR3aXJlLW1h cC10LXNjZW5hcmlvcy0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg Um9iZXJ0YSBNYWdsaW9uZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZp bGVuYW1lOgkgZHJhZnQtbWFnbGlvbmUtc29mdHdpcmUtbWFwLXQtc2NlbmFyaW9zDQpSZXZpc2lv bjoJIDAyDQpUaXRsZToJCSBVc2UgY2FzZXMgZm9yIE1BUC1UDQpDcmVhdGlvbiBkYXRlOgkgMjAx My0wNi0yNw0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDExDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LW1hZ2xpb25lLXNvZnR3aXJlLW1hcC10LXNjZW5hcmlvcy0wMi50eHQNClN0YXR1czog ICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYWdsaW9uZS1z b2Z0d2lyZS1tYXAtdC1zY2VuYXJpb3MNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWFnbGlvbmUtc29mdHdpcmUtbWFwLXQtc2NlbmFyaW9zLTAyDQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1h Z2xpb25lLXNvZnR3aXJlLW1hcC10LXNjZW5hcmlvcy0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoZSBT b2Z0d2lyZSB3b3JraW5nIGdyb3VwIGlzIGN1cnJlbnRseSBkaXNjdXNzaW5nIGJvdGggZW5jYXBz dWxhdGlvbg0KICAgYW5kIHRyYW5zbGF0aW9uIGJhc2VkIHN0YXRlbGVzcyBJUHY0L0lQdjYgc29s dXRpb25zIGluIG9yZGVyIHRvIGJlDQogICBhYmxlIHRvIHByb3ZpZGUgSVB2NCBjb25uZWN0aXZp dHkgdG8gY3VzdG9tZXJzIGluIGFuIElQdjYtT25seQ0KICAgZW52aXJvbm1lbnQuDQoNCiAgIFRo ZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gZGVzY3JpYmUgc29tZSBvcGVyYXRpb25h bCB1c2UNCiAgIGNhc2VzIHRoYXQgd291bGQgYmVuZWZpdCBmcm9tIGEgdHJhbnNsYXRpb24gYmFz ZWQgYXBwcm9hY2ggYW5kDQogICBoaWdobGlnaHRzIHRoZSBvcGVyYXRpb25hbCBiZW5lZml0cyB0 aGF0IGEgdHJhbnNsYXRpb24gYmFzZWQgc29sdXRpb24NCiAgIHdvdWxkIGFsbG93Lg0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From cuiyong@gmail.com Tue Jul 9 03:54:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A39B21F940D for ; Tue, 9 Jul 2013 03:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ZiVslryyRYHk for ; Tue, 9 Jul 2013 03:54:37 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22E21F8F4F for ; Tue, 9 Jul 2013 03:54:36 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so4316388vbe.33 for ; Tue, 09 Jul 2013 03:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=fdQ0366v7+YGKX20txPLR4fvm5Wk86HX4XHT4WsdYBU=; b=jd48Rnym23LPptawV8dEOTpBb2b1e+9i2bFxdjWMv46upDJzR69S2IBA3TAG2lB72/ 5t0gkHzamcPqhnSZ2m+pF1vJ3ry74hEKF1PN7O7gg9HiGar0dfdUFYB9JUrH2XmLu/XT +XlwMzU5QWH5tMI9e+fa/Ji1r98jDfJ5/u452rYJAXqPfL/BE5k0kQMKlAiAvVcjozHJ /sy1l2hIipK15CPbYMsAzVvEs4QEWMl3kwZjNYJu48MhDL0KeaBY5585oGsHrzPdRuEx CbckXuap/2Jx9/AgmbzR9v5i077Gga5Y2JYUWEmhCLWWEW/cgbYFGAZWDx7MLJfaugax zIlw== MIME-Version: 1.0 X-Received: by 10.58.41.105 with SMTP id e9mr16126036vel.14.1373367276433; Tue, 09 Jul 2013 03:54:36 -0700 (PDT) Sender: cuiyong@gmail.com Received: by 10.52.170.148 with HTTP; Tue, 9 Jul 2013 03:54:36 -0700 (PDT) Date: Tue, 9 Jul 2013 18:54:36 +0800 X-Google-Sender-Auth: 09wLCHjni9azwQbucOMIakh8mDk Message-ID: From: Yong Cui To: Softwires WG Content-Type: multipart/alternative; boundary=001a11c3a66aa8771404e111fc13 Cc: Yong Cui Subject: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 09 Jul 2013 10:57:14 -0000 --001a11c3a66aa8771404e111fc13 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, We will have our Softwires session on Tuesday morning in the coming IETF meeting in Berlin. If you would like to have a time slot, please reply this email and send your request to Suresh and me in the following format by July 12 (Friday): (name, title, link to IETF datatracker, minutes requested). Thanks, Yong & Suresh --001a11c3a66aa8771404e111fc13 Content-Type: text/html; charset=ISO-8859-1

Hi folks,


We will have our Softwires session on Tuesday morning in the coming IETF meeting in Berlin.

If you would like to have a time slot, please reply this email and send your request to Suresh and me in the following format by July 12 (Friday):

(name, title, link to IETF datatracker, minutes requested).


Thanks,

Yong & Suresh

--001a11c3a66aa8771404e111fc13-- From cuiyong@gmail.com Tue Jul 9 03:57:28 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C96321F9AAF for ; Tue, 9 Jul 2013 03:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 GR4js58hTeRH for ; Tue, 9 Jul 2013 03:57:28 -0700 (PDT) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9C21921F9F86 for ; Tue, 9 Jul 2013 03:57:24 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pa12so4417642veb.25 for ; Tue, 09 Jul 2013 03:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=dAQXK4TG4G78f3o8qz1TSDvlMBCE3qDfX4taQzroyLE=; b=GbybBQLZrJDVYoB7qllf1i4wcn4xUkT2W7w4StFByhcYRtmvvjxLHeSPL7OPk79wkP XVFd38rj+EOqSyuUakIbcCEJ7xqxtb4peWjvNsN5j/fngPTQ6MNkJirFttJQjWIwEHjS yHNYOGixOrwR8yY6PrphcXs+kwDf3vp6rurT8AMknaz/2/Cj+7Lav+NE2u55MtwFg3A5 lINvLLss6GqaeZ/zGRrhUAvP339UqUxAUHE8lWxMlYRQQqhBlSMtOqumrZYfT6befaTK isPLddmjYzwz6GxZnl/dMBuWRmSw6jrtf+fgNQZdKYfZfkM2+iUgxpg16ijWyJXGS60g lu7A== MIME-Version: 1.0 X-Received: by 10.58.145.97 with SMTP id st1mr16106457veb.71.1373367443912; Tue, 09 Jul 2013 03:57:23 -0700 (PDT) Sender: cuiyong@gmail.com Received: by 10.52.170.148 with HTTP; Tue, 9 Jul 2013 03:57:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jul 2013 18:57:23 +0800 X-Google-Sender-Auth: wpI9wglohohfK47xGz1JLDoSfoA Message-ID: From: Yong Cui To: Softwires WG Content-Type: multipart/alternative; boundary=047d7b6768b8a3fe1904e11206f5 Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 09 Jul 2013 10:57:28 -0000 --047d7b6768b8a3fe1904e11206f5 Content-Type: text/plain; charset=ISO-8859-1 Hello Chairs, we would like to ask for a 10min slot to present the revised draft-ietf-map-dhcp. One of the changes will be in naming, moving from MAP-Options to S46-options, for Software46. This follows the discussion about the option being reusable in other cases of A+P. Regards, W. Dec 2013/7/9 Yong Cui > Hi folks, > > > We will have our Softwires session on Tuesday morning in the coming IETF > meeting in Berlin. > > If you would like to have a time slot, please reply this email and send > your request to Suresh and me in the following format by July 12 (Friday): > > (name, title, link to IETF datatracker, minutes requested). > > > Thanks, > > Yong & Suresh > --047d7b6768b8a3fe1904e11206f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Chairs,

we would like to ask for a 10min slot to p= resent the revised draft-ietf-map-dhcp. One of the=A0 changes will be in na= ming, moving from MAP-Options to S46-options, for Software46. This follows = the discussion about the option being reusable in other cases of A+P.=A0
Regar= ds,
W. Dec


2013/7/9 Yong Cui <= cuiyong@tsingh= ua.edu.cn>

Hi folks,


We will have our Softwires session on Tuesday morning in the coming IETF= meeting in Berlin.

If you would like to have a time slot, please reply this email and send = your request to Suresh and me in the following format by July 12 (Friday):<= /p>

(name, title, link to IETF datatracker, minutes requested).


Thanks,

Yong & Suresh


--047d7b6768b8a3fe1904e11206f5-- From cuiyong@gmail.com Tue Jul 9 03:58:04 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD91521F9FE4 for ; Tue, 9 Jul 2013 03:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 qoxT0xRAUVgp for ; Tue, 9 Jul 2013 03:58:04 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id A9EA621F9FD2 for ; Tue, 9 Jul 2013 03:57:57 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so4115443vcb.8 for ; Tue, 09 Jul 2013 03:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=jaCcVLBw/3mU2/paI3HS0/V6hfSXCNoDXtVd5a5eTsY=; b=Aw5byiapcZr/+1EyaAaNpbHOIOtaQ57p6N3rk11x/D6R/A9acGGGE4aUQo1gb438Sc FyR4OA0++2xZ4TET0Px1GrC/NNoqE1VDJVdoqscNXRyM3/R2Hr5bVIowiYTzLvmP/sgC Nhz4be5NvYhBbH2e4KaxBLE82L8I4mmsE/p5K6vMKFbK90mvTUp0/krBrNnJb2G+WQHN 4blytpGCc/xk5crwjLtww5xa5KrtbvivnWrG2B/r8qpxs1tZlgMvI5de63TbAnFYfZzQ +MPXdq6h7H8PTpei3Wr9u+aPsYCyPNVE11eZDEQk2DvlV5NeaFay/EQibvPD4dHv0hGT Z/IA== MIME-Version: 1.0 X-Received: by 10.58.49.130 with SMTP id u2mr16208722ven.7.1373367476129; Tue, 09 Jul 2013 03:57:56 -0700 (PDT) Sender: cuiyong@gmail.com Received: by 10.52.170.148 with HTTP; Tue, 9 Jul 2013 03:57:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jul 2013 18:57:56 +0800 X-Google-Sender-Auth: tFuLiDdIDFyGaY7Z3rGtSYaDM30 Message-ID: From: Yong Cui To: Softwires WG Content-Type: multipart/alternative; boundary=089e013cbd3e8f971f04e11208b3 Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 09 Jul 2013 10:58:04 -0000 --089e013cbd3e8f971f04e11208b3 Content-Type: text/plain; charset=ISO-8859-1 Hi Chairs, we would like to ask for a 10min slot to present the MAP-T draft. Overall, aside from a few more editorial nits, we feel that the draft is ready for WGLC after this meeting. Regards, W. Dec 2013/7/9 Yong Cui > Hello Chairs, > > we would like to ask for a 10min slot to present the revised > draft-ietf-map-dhcp. One of the changes will be in naming, moving from > MAP-Options to S46-options, for Software46. This follows the discussion > about the option being reusable in other cases of A+P. > > Regards, > W. Dec > > > 2013/7/9 Yong Cui > >> Hi folks, >> >> >> We will have our Softwires session on Tuesday morning in the coming IETF >> meeting in Berlin. >> >> If you would like to have a time slot, please reply this email and send >> your request to Suresh and me in the following format by July 12 (Friday): >> >> (name, title, link to IETF datatracker, minutes requested). >> >> >> Thanks, >> >> Yong & Suresh >> > > --089e013cbd3e8f971f04e11208b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chairs,

we would like to ask for a 10min slot to= present the MAP-T draft. Overall, aside from a few more editorial nits, we= feel that the draft is ready for WGLC after this meeting.

Regards,
W. Dec


2013/7/9 Yong Cui <cuiyong@tsinghua.edu.cn>
Hello Chairs,

we would li= ke to ask for a 10min slot to present the revised draft-ietf-map-dhcp. One = of the=A0 changes will be in naming, moving from MAP-Options to S46-options= , for Software46. This follows the discussion about the option being reusab= le in other cases of A+P.=A0

Regar= ds,
W. Dec


2013/7/9 Yong Cui <= cuiyong@tsingh= ua.edu.cn>

Hi folks,


We will have our Softwires session on Tuesday morning in the coming IETF= meeting in Berlin.

If you would like to have a time slot, please reply this email and send = your request to Suresh and me in the following format by July 12 (Friday):<= /p>

(name, title, link to IETF datatracker, minutes requested).


Thanks,

Yong & Suresh



--089e013cbd3e8f971f04e11208b3-- From yiu_lee@cable.comcast.com Tue Jul 9 04:14:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC7A21F9EE7 for ; Tue, 9 Jul 2013 04:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTCpmmL9aQuZ for ; Tue, 9 Jul 2013 04:14:27 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id BCF7721F9F9D for ; Tue, 9 Jul 2013 04:14:23 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.57904765; Tue, 09 Jul 2013 07:12:26 -0400 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 9 Jul 2013 07:14:20 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.138]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Tue, 9 Jul 2013 07:14:20 -0400 From: "Lee, Yiu" To: Softwires WG Thread-Topic: [Softwires] Call for agenda in IETF 87 Thread-Index: AQHOfJV1Wf6gKkb3LUSdtL2Jfsd1NA== Date: Tue, 9 Jul 2013 11:14:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.246] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3456198859_2014829" MIME-Version: 1.0 Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 09 Jul 2013 11:14:34 -0000 --B_3456198859_2014829 Content-type: multipart/alternative; boundary="B_3456198858_1990224" --B_3456198858_1990224 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Chairs, We would like to ask for 10 min slot to present the "Lightweight 4over6 Failover" draft. Thanks, Yiu From: Yong Cui Date: Tuesday, July 9, 2013 6:54 AM To: Softwires WG Cc: Yong Cui Subject: [Softwires] Call for agenda in IETF 87 Hi folks, We will have our Softwires session on Tuesday morning in the coming IETF meeting in Berlin. If you would like to have a time slot, please reply this email and send your request to Suresh and me in the following format by July 12 (Friday): (name, title, link to IETF datatracker, minutes requested). Thanks, Yong & Suresh --B_3456198858_1990224 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Chairs,

We would like to ask for 10 min slot to present the "Lightweight 4ov= er6 Failover" draft.

Thanks,
Yiu 

From: Yong Cui <cuiyong@tsinghua.edu.cn>
Date: Tuesday, July 9, 2013 6:54 AM
<= span style=3D"font-weight:bold">To: Softwires WG <softwires@ietf.org>
Cc: Yong Cui <cuiyon= g@tsinghua.edu.cn>
Subject: = [Softwires] Call for agenda in IETF 87

Hi folks,


We will have ou= r Softwires session on Tuesday morning in the coming IETF meeting in Berlin.=

If you would like to have a time slot, please reply this ema= il and send your request to Suresh and me in the following format by July 12= (Friday):

(name, title, link to IETF datatracker, minutes re= quested).


Thanks,

Yong= & Suresh

 --B_3456198858_1990224-- --B_3456198859_2014829 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFNx+ 07BNwjWjEkooPA439nVfKEiaMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDcwOTExMTQxOFowDQYJKoZIhvcNAQEBBQAEggEAIB0WFeHMaojfugHXyGN4 4kRELHeSzya1ZpnGB2fYtt0p/o0f6JnXISDrhyq8pRj953iJs9Z6sim/WSty/HbbDzjk7YeM I6AYYt65jEnPhJrTcc48mKcdOGSJXlf8ulsDarLzqmDEOcABm9uyw2bIlhP664KH/YN6+5wB qPbWZ6NR/Gy2dT1p9YVhs6Xp85/ADxjzZNj5WMlxVa904QilYg2cagz2C31rjWEb0cn1eUtT ahImwPmqI438/Yo3V29pTJsH1CqWvfvrq2PVq+A8hrCHn6wLzDlf6AT2b8xWdAl9r0MBRSEg nX4VYU3OS2G1fF6q0nuk3f7i9J4F93Vp/g== --B_3456198859_2014829-- From robmgl@cisco.com Tue Jul 9 06:59:39 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D857D21F9F9D for ; Tue, 9 Jul 2013 06:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.488 X-Spam-Level: X-Spam-Status: No, score=-9.488 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 OwkMobk1GXPP for ; Tue, 9 Jul 2013 06:59:35 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F1BB721F9B18 for ; Tue, 9 Jul 2013 06:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6224; q=dns/txt; s=iport; t=1373378375; x=1374587975; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jCOyr8fKaXxQnNLtCjz5uEGOEfBN4s3pzCzfXoORnac=; b=GWxGnwbRQ//uM1/XrzBkKLNSVWHz1EuNZoR2RKPToZHMyX8ucBWWMmkz 8+BcDgqXTkim9NQ7C3FLUXQtxfJRvOMkWIQ1unchk5Pmn9v7xNYEmVGyV xRFt9aDvOxj30kTmATsR5TlDsy3XfHZLmiPcbOYub4/jp/vfZxFtM4oW3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEFAMcW3FGtJXG+/2dsb2JhbABaDoI3RDJNuEqIPYEYFnSCIwEBAQQdEFwCAQgRBAEBCx0HMhQJCAIEARIIiAcMuhWOKYERNwGDCWkDmHyQH4JTPoFxNw X-IronPort-AV: E=Sophos;i="4.87,1028,1363132800"; d="scan'208,217";a="232591544" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jul 2013 13:59:34 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r69DxYQ2030827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 13:59:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 08:59:33 -0500 From: "Roberta Maglione (robmgl)" To: Yong Cui , Softwires WG Thread-Topic: [Softwires] Call for agenda in IETF 87 Thread-Index: AQHOfJMV3qB3zCfhfkOTpVkiqDlzzJlcXpyQ Date: Tue, 9 Jul 2013 13:59:32 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D25E44E@xmb-rcd-x01.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.234.68] Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D25E44Exmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 09 Jul 2013 13:59:40 -0000 --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D25E44Exmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Chairs, we would like to ask for a 10min slot to present version -02 of draft-magl= ione-softwire-map-t-scenarios. http://tools.ietf.org/html/draft-maglione-softwire-map-t-scenarios-02 the presenter will be one of the co-authors. Thanks Regards, Roberta From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Yong Cui Sent: Tuesday, July 09, 2013 6:55 AM To: Softwires WG Cc: Yong Cui Subject: [Softwires] Call for agenda in IETF 87 Hi folks, We will have our Softwires session on Tuesday morning in the coming IETF me= eting in Berlin. If you would like to have a time slot, please reply this email and send you= r request to Suresh and me in the following format by July 12 (Friday): (name, title, link to IETF datatracker, minutes requested). Thanks, Yong & Suresh --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D25E44Exmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Chairs,<= /span>

we would like to ask for = a 10min slot to present  version -02 of draft-maglione-softwire-map-t-= scenarios.

http://tools.ietf.= org/html/draft-maglione-softwire-map-t-scenarios-02

the presenter will be one= of the co-authors.

Thanks<= /p>

Regards,

Roberta

 <= /p>

From: softwire= s-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Yong Cui
Sent: Tuesday, July 09, 2013 6:55 AM
To: Softwires WG
Cc: Yong Cui
Subject: [Softwires] Call for agenda in IETF 87

 

Hi folks,

 

We will have our Softwires session on Tuesday morning in the comin= g IETF meeting in Berlin.

If you would like to have a time slot, please reply this email and= send your request to Suresh and me in the following format by July 12 (Fri= day):

(name, title, link to IETF datatracker, minutes requested).

 

Thanks,

Yong & Suresh

--_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D25E44Exmbrcdx01ciscoc_-- From tom.taylor.stds@gmail.com Tue Jul 9 08:06:48 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A482E21F9EC5 for ; Tue, 9 Jul 2013 08:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlPopaZPm9h2 for ; Tue, 9 Jul 2013 08:06:46 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3572521F9EC9 for ; Tue, 9 Jul 2013 08:06:46 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so13045844ieb.30 for ; Tue, 09 Jul 2013 08:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=HFz03lMwoIMkehjDKKTl7zFYaUiffaDhIwh2qqvX3/Q=; b=hR6Ym1FL5dgVYtzGz9qvI0q7DXK7zv6eV/b2F2WXeV0Hx0UN58YVIjCUcK2PwoTuRp 6ptjCCopeGpc73Fh1JOSdUVNFi0x8yRwnRb7Q4HlaICagMTofOTpW53fdtdCeJEFOgID W6XIm2997B+WKF6s6/Jd4DpVLOvaag7z26fmUu+UwqCnmCwEUhjBqOqkx+uEMN1DlN1B VNkO9dpPUFP+icxa6ykOdj47Py8HEucnKr1N47VLupQb9yd46O8sRMhiZL33CHBMgQ8U hJZdPd87uqYxdfAJP3eFBOQn4ldbm/ygbe5WlfW+bwFVw2tK6P9nkVVNfnRZXH3tAkC+ rzKw== X-Received: by 10.50.61.171 with SMTP id q11mr7002136igr.57.1373382398698; Tue, 09 Jul 2013 08:06:38 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id x10sm36155636igl.3.2013.07.09.08.06.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 08:06:38 -0700 (PDT) Message-ID: <51DC26FE.30905@gmail.com> Date: Tue, 09 Jul 2013 11:06:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:06:49 -0000 Section 8.1 of draft-ietf-softwire-map talks about rules for processing incoming packets. The first paragraph says that the CE checks the received port number against the stateful port mapping table, but doesn't say what it does if the port is out of range. I'm interested in whether the BR receives a notification when this happens (i.e., an ICMPv6 error message like the one described in the next paragraph going the other way). This would allow the BR to log the error. Is the failure to specify CE action deliberate or should it be specified? Tom Taylor From simon.perreault@viagenie.ca Tue Jul 9 08:54:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63411E8137 for ; Tue, 9 Jul 2013 08:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.145, 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 5ToJGfVp9U-0 for ; Tue, 9 Jul 2013 08:54:39 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E6C0521F9EF4 for ; Tue, 9 Jul 2013 08:54:33 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c15b:51e7:d305:cc6c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B555E415A1 for ; Tue, 9 Jul 2013 11:54:29 -0400 (EDT) Message-ID: <51DC3235.1020803@viagenie.ca> Date: Tue, 09 Jul 2013 17:54:29 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 09 Jul 2013 15:54:44 -0000 Le 2013-07-09 12:54, Yong Cui a écrit : > If you would like to have a time slot, please reply this email and send > your request to Suresh and me in the following format by July 12 (Friday): > > (name, title, link to IETF datatracker, minutes requested). We would need 10 minutes to present recent changes and future direction for the unified CPE draft. https://datatracker.ietf.org/doc/draft-ietf-softwire-unified-cpe/ Simon From wdec.ietf@gmail.com Tue Jul 9 08:58:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B270411E8140 for ; Tue, 9 Jul 2013 08:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nm6GCJ5yt2be for ; Tue, 9 Jul 2013 08:58:16 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 91A3711E8141 for ; Tue, 9 Jul 2013 08:58:15 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so3109496qeb.16 for ; Tue, 09 Jul 2013 08:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0YMrBuGGP/kMvZNC4ruPkM5Up4tdhv7UvW56ZAsSEUE=; b=pSTcKKb7tOkQgmawIEmWESef4H6Hc3odt+eXoDQCNItFl28w1TrIX4v4DlF5oShsvM NST8Rvd/jdnVpHEXJxRRTko6ZmWYZcmxLba0UyF5uvpPd4tbWmyuxILYcsz6gOI1nWZY G5xOjdcc06fEYT12LBU0p+C7lzQaxcVRV8LEBP1aCwRVZqqyufeO+mq5lhzBCD95FN7J 234WGftdjdzye8tlpR6U9JZ+Yr8MnarGEbfiZuqRQ0qaTFQvfBZI7wUZq9YovAZuenXV 1Oi10BSNINuN46YGPcBKQcGFOTjDyTkSL2mfxkv7pxABYD5VNhvtwsjCD130OdMtrSFw uokQ== MIME-Version: 1.0 X-Received: by 10.229.163.84 with SMTP id z20mr5059592qcx.75.1373385493115; Tue, 09 Jul 2013 08:58:13 -0700 (PDT) Received: by 10.49.134.2 with HTTP; Tue, 9 Jul 2013 08:58:13 -0700 (PDT) In-Reply-To: <51DC26FE.30905@gmail.com> References: <51DC26FE.30905@gmail.com> Date: Tue, 9 Jul 2013 17:58:13 +0200 Message-ID: From: Wojciech Dec To: Tom Taylor Content-Type: multipart/alternative; boundary=14dae9c093de74f8b804e1163a1e Cc: Softwires Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:58:18 -0000 --14dae9c093de74f8b804e1163a1e Content-Type: text/plain; charset=ISO-8859-1 The MAP-T draft actually covers that, with the following text. MAP-E should do the equivalent with ICMPv4. Think the text on this accidentally fell through the cracks during the editorial cleanup. The CE SHOULD check that MAP-T received packets' destination transport-layer destination port number is in the range allowed for by the CE's MAP BMR configuration. The CE SHOULD drop any non conforming packet and respond with an ICMPv6 "Address Unreachable" (Type 1, Code 3). On 9 July 2013 17:06, Tom Taylor wrote: > Section 8.1 of draft-ietf-softwire-map talks about rules for processing > incoming packets. The first paragraph says that the CE checks the received > port number against the stateful port mapping table, but doesn't say what > it does if the port is out of range. > > I'm interested in whether the BR receives a notification when this happens > (i.e., an ICMPv6 error message like the one described in the next paragraph > going the other way). This would allow the BR to log the error. > > Is the failure to specify CE action deliberate or should it be specified? > > Tom Taylor > ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > --14dae9c093de74f8b804e1163a1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The MAP-T draft actually covers that, with the following t= ext. MAP-E should do the equivalent with ICMPv4. Think the text on this=A0 = accidentally fell through the cracks during the editorial cleanup.

<= pre class=3D""> The CE SHOULD check that MAP-T received packets' destination transport-layer destination port number is in the range allowed for by the CE's MAP BMR configuration. The CE SHOULD drop any non conforming packet and respond with an ICMPv6 "Address Unreachable" (Type 1, Code 3).


On 9 July 2013 17:06= , Tom Taylor <tom.taylor.stds@gmail.com> wrote:
Section 8.1 of draft-ietf-softwire-map talks= about rules for processing incoming packets. The first paragraph says that= the CE checks the received port number against the stateful port mapping t= able, but doesn't say what it does if the port is out of range.

I'm interested in whether the BR receives a notification when this happ= ens (i.e., an ICMPv6 error message like the one described in the next parag= raph going the other way). This would allow the BR to log the error.

Is the failure to specify CE action deliberate or should it be specified?

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

--14dae9c093de74f8b804e1163a1e-- From rajiva@cisco.com Tue Jul 9 09:28:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0600021F9E43 for ; Tue, 9 Jul 2013 09:28:30 -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 awiotY2sTRUN for ; Tue, 9 Jul 2013 09:28:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D67A021F9E4B for ; Tue, 9 Jul 2013 09:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2225; q=dns/txt; s=iport; t=1373387304; x=1374596904; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nscDZxKAuRyjVX/LZL8SfgtgVS9IJi8ELJoTK36zrsQ=; b=ZWtG+HGInvmSqL1QJTBCoP8MfNBOsjcSNiKwaIFq+/yu0sq3+SB+Tbjl UWZcqv57nfv3wrhCrOtHuPOfDVQ+CnuqLqhJyoTYM3nfRsWMkuvoocD5u b1qVVK4S7mN0/EhezcwInhi6AviSqSdr/zhRmGQEozZy5A2WLzbQmkZaO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAPo43FGtJV2b/2dsb2JhbABagwkyTcEGgRkWdIIjAQEBBAEBATcNJwsMBAIBCA4DBAEBAQoUCQchBgsUCQgCBAENBQiHdQMPDKx+hF8NiE0EjQCCOjEHBoMDaQOVbI4KhSWDEYIo X-IronPort-AV: E=Sophos;i="4.87,1029,1363132800"; d="scan'208";a="232673533" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 09 Jul 2013 16:28:24 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r69GSOfR002316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 16:28:24 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 11:28:23 -0500 From: "Rajiv Asati (rajiva)" To: Wojciech Dec , Tom Taylor Thread-Topic: [Softwires] Ambiguity in MAP-E receiving rules Thread-Index: AQHOfLX+Z1jN8ar5B02prcwEBIX9n5lc1KGA//+zkhA= Date: Tue, 9 Jul 2013 16:28:23 +0000 Message-ID: References: <51DC26FE.30905@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.38.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:28:30 -0000 IMO, we should not specify this behavior at all, since it could provide a f= antastic recipe for launching an attack against the BR.=20 All the IPv4 packets failing the NAPT44 table check would result in ICMPv6 = traffic to the BR. Sure, BR could do the rate-limiting of the incoming ICMP= v6 packets, but it is consequential and should be avoided. I suggest that the CPE should log this error in this case, and that's it. N= o need to notify the BR. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Wojciech Dec > Sent: Tuesday, July 09, 2013 11:58 AM > To: Tom Taylor > Cc: Softwires > Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules >=20 > The MAP-T draft actually covers that, with the following text. MAP-E shou= ld > do the equivalent with ICMPv4. Think the text on this accidentally fell > through the cracks during the editorial cleanup. >=20 >=20 >=20 > The CE SHOULD check that MAP-T received > packets' destination transport-layer destination port number is in > the range allowed for by the CE's MAP BMR configuration. The CE > SHOULD drop any non conforming packet and respond with an ICMPv6 > "Address Unreachable" (Type 1, Code 3). >=20 >=20 >=20 > On 9 July 2013 17:06, Tom Taylor wrote: >=20 >=20 > Section 8.1 of draft-ietf-softwire-map talks about rules for > processing incoming packets. The first paragraph says that the CE checks = the > received port number against the stateful port mapping table, but doesn't > say what it does if the port is out of range. >=20 > I'm interested in whether the BR receives a notification when this > happens (i.e., an ICMPv6 error message like the one described in the next > paragraph going the other way). This would allow the BR to log the error. >=20 > Is the failure to specify CE action deliberate or should it be > specified? >=20 > Tom Taylor > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > >=20 >=20 From xuxiaohu@huawei.com Wed Jul 10 00:16:48 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F3D21F9B9F for ; Wed, 10 Jul 2013 00:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-3.846, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLYnTLWFfVcQ for ; Wed, 10 Jul 2013 00:16:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB4A21F9E26 for ; Wed, 10 Jul 2013 00:16:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH32711; Wed, 10 Jul 2013 07:16:40 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Jul 2013 08:16:17 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Jul 2013 08:16:34 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Wed, 10 Jul 2013 15:16:27 +0800 From: Xuxiaohu To: Yong Cui , Softwires WG Thread-Topic: [Softwires] Call for agenda in IETF 87 Thread-Index: AQHOfJMdm7XA776B2ECH2JcOfTHX55ldfw6g Date: Wed, 10 Jul 2013 07:16:27 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CD828@NKGEML512-MBS.china.huawei.com> 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.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CD828NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] =?gb2312?b?tPC4tDogIENhbGwgZm9yIGFnZW5kYSBpbiBJRVRG?= =?gb2312?b?IDg3?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 10 Jul 2013 07:16:48 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CD828NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgY28tY2hhaXJzLA0KDQpJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBhIDUtbWluIHRpbWUgc2xv dCBmb3IgcHJlc2VudGluZyB0aGUgZm9sbG93aW5nIHR3byBkcmFmdHM6DQoNCg0KMS4gICAgICAg QkdQIFR1bm5lbCBFbmNhcHN1bGF0aW9uIEF0dHJpYnV0ZSBmb3IgVURQIChodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1zb2Z0d2lyZS1lbmNhcHMtdWRwLTAxKQ0KDQoyLiAgICAg ICBFbmNhcHN1bGF0aW5nIElQIGluIFVEUCAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQteHUtc29mdHdpcmUtaXAtaW4tdWRwLTAyKQ0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0K t6K8/sjLOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIFlvbmcgQ3VpDQq3osvNyrG85DogMjAxM8TqN9TCOcjVIDE4OjU1 DQrK1bz+yMs6IFNvZnR3aXJlcyBXRw0Ks63LzTogWW9uZyBDdWkNCtb3zOI6IFtTb2Z0d2lyZXNd IENhbGwgZm9yIGFnZW5kYSBpbiBJRVRGIDg3DQoNCkhpIGZvbGtzLA0KDQpXZSB3aWxsIGhhdmUg b3VyIFNvZnR3aXJlcyBzZXNzaW9uIG9uIFR1ZXNkYXkgbW9ybmluZyBpbiB0aGUgY29taW5nIElF VEYgbWVldGluZyBpbiBCZXJsaW4uDQpJZiB5b3Ugd291bGQgbGlrZSB0byBoYXZlIGEgdGltZSBz bG90LCBwbGVhc2UgcmVwbHkgdGhpcyBlbWFpbCBhbmQgc2VuZCB5b3VyIHJlcXVlc3QgdG8gU3Vy ZXNoIGFuZCBtZSBpbiB0aGUgZm9sbG93aW5nIGZvcm1hdCBieSBKdWx5IDEyIChGcmlkYXkpOg0K KG5hbWUsIHRpdGxlLCBsaW5rIHRvIElFVEYgZGF0YXRyYWNrZXIsIG1pbnV0ZXMgcmVxdWVzdGVk KS4NCg0KVGhhbmtzLA0KWW9uZyAmIFN1cmVzaA0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CD828NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi co-chai= rs,

 = ;

I would li= ke to request a 5-min time slot for presenting the following two drafts:

 = ;

1.       BG= P Tunnel Encapsulation Attribute for UDP (http://tools.ietf.org/html/draft-xu-softwire-encaps-udp-01)

2.       En= capsulating IP in UDP (http://tools.ietf.org/html/draft-xu-softwire-ip-in-u= dp-02)

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: softwir= es-bounces@ietf.org [mailto:softwires-bounces@ietf.org] =B4=FA= =B1=ED Yong Cui
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C29=C8=D5 18:55
=CA=D5=BC=FE=C8=CB: Softwires WG
=B3=AD=CB=CD: Yong Cui
=D6=F7=CC=E2: [Softwires] Call for agenda in IETF 87

 

Hi folks,

 

We will have our Softwires session on Tuesday= morning in the coming IETF meeting in Berlin.

If you would like to have a time slot, please= reply this email and send your request to Suresh and me in the following f= ormat by July 12 (Friday):

(name, title, link to IETF datatracker, minut= es requested).

 

Thanks,

Yong & Suresh

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CD828NKGEML512MBSchi_-- From ecordeiro@nic.br Wed Jul 10 04:16:45 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7525021F9FD2 for ; Wed, 10 Jul 2013 04:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.599, 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 w58n9wbxDPjf for ; Wed, 10 Jul 2013 04:16:43 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D361A21F9F58 for ; Wed, 10 Jul 2013 04:16:42 -0700 (PDT) Received: from ecordeiro.in.nic.br (5.110.net.registro.br [200.160.5.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 81D2E20801A0 for ; Wed, 10 Jul 2013 08:16:39 -0300 (BRT) Message-ID: <51DD42A9.9040706@nic.br> Date: Wed, 10 Jul 2013 08:16:57 -0300 From: Edwin Cordeiro User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------020107010207030509000603" Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 10 Jul 2013 11:16:45 -0000 This is a multi-part message in MIME format. --------------020107010207030509000603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I'd like to request a slot: Edwin Cordeiro Experience from MAP-T Testing http://tools.ietf.org/html/draft-cordeiro-softwire-experience-mapt-01 10 minutes Thanks, Edwin Cordeiro IPv6 Evangelist NIC.br Em 09/07/13 07:54, Yong Cui escreveu: > > Hi folks, > > > We will have our Softwires session on Tuesday morning in the coming > IETF meeting in Berlin. > > If you would like to have a time slot, please reply this email and > send your request to Suresh and me in the following format by July 12 > (Friday): > > (name, title, link to IETF datatracker, minutes requested). > > > Thanks, > > Yong & Suresh > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --------------020107010207030509000603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I'd like to request a slot:
Edwin Cordeiro
Experience from MAP-T Testing
http://tools.ietf.org/html/draft-cordeiro-softwire-experience-mapt-01
10 minutes

Thanks,
Edwin Cordeiro
IPv6 Evangelist
NIC.br
Em 09/07/13 07:54, Yong Cui escreveu:

Hi folks,


We will have our Softwires session on Tuesday morning in the coming IETF meeting in Berlin.

If you would like to have a time slot, please reply this email and send your request to Suresh and me in the following format by July 12 (Friday):

(name, title, link to IETF datatracker, minutes requested).


Thanks,

Yong & Suresh



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

--------------020107010207030509000603-- From ian.farrer@telekom.de Wed Jul 10 23:28:40 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650F521F9DAA for ; Wed, 10 Jul 2013 23:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep-2+va2446H for ; Wed, 10 Jul 2013 23:28:36 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 24F7021F9DA2 for ; Wed, 10 Jul 2013 23:28:32 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jul 2013 08:28:30 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 11 Jul 2013 08:28:30 +0200 From: To: , , Date: Thu, 11 Jul 2013 08:28:29 +0200 Thread-Topic: [Softwires] Ambiguity in MAP-E receiving rules Thread-Index: Ac59/9u6u/5hLrqAQjWTdGKgzOKkOA== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 06:28:40 -0000 Hi Rajiv, The problem is common for lw4o6 CPEs. It would make sense to have common behaviour across the CPEs. A couple of comments below. Cheers, Ian On 09/07/2013 18:28, "Rajiv Asati (rajiva)" wrote: >IMO, we should not specify this behavior at all, since it could provide a >fantastic recipe for launching an attack against the BR. [ian] Agreed >=20 > >All the IPv4 packets failing the NAPT44 table check would result in >ICMPv6 traffic to the BR. Sure, BR could do the rate-limiting of the >incoming ICMPv6 packets, but it is consequential and should be avoided. > >I suggest that the CPE should log this error in this case, and that's it. >No need to notify the BR. [ian] It may be useful to have the option of sending an ICMP error message for troubleshooting. What about if we have a 'should' requirement for logging the error on the CPE and a 'may' for sending an ICMP error message? > >Cheers, >Rajiv > > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >> Behalf Of Wojciech Dec >> Sent: Tuesday, July 09, 2013 11:58 AM >> To: Tom Taylor >> Cc: Softwires >> Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules >>=20 >> The MAP-T draft actually covers that, with the following text. MAP-E >>should >> do the equivalent with ICMPv4. Think the text on this accidentally fell >> through the cracks during the editorial cleanup. >>=20 >>=20 >>=20 >> The CE SHOULD check that MAP-T received >> packets' destination transport-layer destination port number is in >> the range allowed for by the CE's MAP BMR configuration. The CE >> SHOULD drop any non conforming packet and respond with an ICMPv6 >> "Address Unreachable" (Type 1, Code 3). >>=20 >>=20 >>=20 >> On 9 July 2013 17:06, Tom Taylor wrote: >>=20 >>=20 >> Section 8.1 of draft-ietf-softwire-map talks about rules for >> processing incoming packets. The first paragraph says that the CE >>checks the >> received port number against the stateful port mapping table, but >>doesn't >> say what it does if the port is out of range. >>=20 >> I'm interested in whether the BR receives a notification when this >> happens (i.e., an ICMPv6 error message like the one described in the >>next >> paragraph going the other way). This would allow the BR to log the >>error. >>=20 >> Is the failure to specify CE action deliberate or should it be >> specified? >>=20 >> Tom Taylor >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >>=20 >>=20 > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From ian.farrer@telekom.de Wed Jul 10 23:47:19 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC8121F9CCA for ; Wed, 10 Jul 2013 23:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bVuG4e+460OX for ; Wed, 10 Jul 2013 23:47:14 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4B421F9BB2 for ; Wed, 10 Jul 2013 23:47:12 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jul 2013 08:46:37 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 11 Jul 2013 08:46:37 +0200 From: To: Date: Thu, 11 Jul 2013 08:46:34 +0200 Thread-Topic: Updates to lw4o6 Draft (draft-ietf-softwire-lw4over6) Thread-Index: Ac5+AmOSVJTCMOrERKG4D5Eo/5CvUw== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CE04216A7DF5Aianfarrertelekomde_" MIME-Version: 1.0 Subject: [Softwires] Updates to lw4o6 Draft (draft-ietf-softwire-lw4over6) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 06:47:19 -0000 --_000_CE04216A7DF5Aianfarrertelekomde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I'm currently updating the lw4o6 draft in advance of IETF87. I plan to incl= ude the following changes: - I-D.bfmk-softwire-unified-cpe needs to be changed to I-D.ietf-softwire-un= ified-cpe throughout - Section 7 =96 the reference from I-D.ietf-dhc-dhcpv4-over-ipv6 should be = changed to draft-ietf-dhc-dhcpv4-over-dhcpv6 in line with the DHC recommend= ations - Section 5.2 does not consider what happens if a packet is received by the= lwB4 that isn't addressed to the correct destination v4 address with a val= id l4 port (there's a small discussion about this for MAP-E on the list at = the moment). Propose that the lw4o6 draft is updated in line with the outco= me of this discussions so that MAP-E & lw4o6 CPE behaviour stays aligned. - I-D.bfmk-softwire-unified-cpe is currently included as a normative refere= nce, this will be moved to informative. - Add text to section 5.2 saying that any IPv4 fragments received by the lw= B4 (CPE) after decapsulation are re-assembled before NAT, so that the whole= packet can be translated. This is based on some problems encountered durin= g interop testing. If you have any comments or objections to the above, please let me know. Cheers, Ian --_000_CE04216A7DF5Aianfarrertelekomde_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

I'm currently updating the lw4o6 draft in advance of IETF87. I plan to i= nclude the following changes:

- I-D.bfmk-softwire-= unified-cpe needs to be changed to I-D.ietf-softwire-unified-cpe throughout=

- Section 7 =96 the reference from I-D.ietf-= dhc-dhcpv4-over-ipv6 should be changed to draft-ietf-dhc-dhcpv4-over-d= hcpv6 in line with the DHC recommendations

- Secti= on 5.2 does not consider what happens if a packet is received by the l= wB4 that isn't addressed to the correct destination v4 address with a valid= l4 port (there's a small discussion about this for MAP-E on the list at th= e moment). Propose that the lw4o6 draft is updated in line with the outcome= of this discussions so that MAP-E & lw4o6 CPE behaviour stays aligned.=

- I-D.bfmk-softwire-unified-cpe is currently incl= uded as a normative reference, this will be moved to informative.

- Add text to section 5.2 saying that any IPv4 fragments re= ceived by the lwB4 (CPE) after decapsulation are re-assembled before NAT, s= o that the whole packet can be translated. This is based on some problems e= ncountered during interop testing.

If you ha= ve any comments or objections to the above, please let me know.
<= br>
Cheers,
Ian

--_000_CE04216A7DF5Aianfarrertelekomde_-- From sunqi.csnet.thu@gmail.com Thu Jul 11 00:34:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA84221F9E29 for ; Thu, 11 Jul 2013 00:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 Yk9o6sBewT4Q for ; Thu, 11 Jul 2013 00:34:27 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 53BE521F9E28 for ; Thu, 11 Jul 2013 00:34:27 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa11so7621356pad.33 for ; Thu, 11 Jul 2013 00:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=GdsDAtOnA77zOXyIim8eeiJapDIPalphiJv1Dle5OG8=; b=FPOfgvDu604n5bKM6ER2Fv7yKMbVNsJ8lwb3kDVVEV91IVGm6YsGrggr5pqW0QYC+J oEXqJAf4AMX8ob1XYxbNwqikZfB5hkcaUtsnMZjGl2X0KyKBKMSbMjvZ8jrnAZFMEyKH vSIBQiVuu5aYKiMJyRf8p9ZgvZoYQ5O+ZZZr9kPXGaBPnvBeU0boVF1OGADwOPvv90R6 7aQ6j2UOiN7hswAK2pjoDNNPfRebuV2CaQ/qLYR/71LuBQ9blaOpNTaotrgeSZUX4cqe R5xtBVPXS3RZfptRBxaJ48eReTuj+c704Oj9Ph7+MojpeKZ9Hyum6xna3BFduWykHtdo xoAA== X-Received: by 10.66.150.9 with SMTP id ue9mr33172700pab.88.1373528067006; Thu, 11 Jul 2013 00:34:27 -0700 (PDT) Received: from [192.168.1.107] ([166.111.68.233]) by mx.google.com with ESMTPSA id qg10sm8461461pbb.2.2013.07.11.00.34.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 00:34:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-56-83867696 From: Qi Sun In-Reply-To: Date: Thu, 11 Jul 2013 15:34:18 +0800 Message-Id: References: To: X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Updates to lw4o6 Draft (draft-ietf-softwire-lw4over6) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 07:34:28 -0000 --Apple-Mail-56-83867696 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ian , > - I-D.bfmk-softwire-unified-cpe is currently included as a normative = reference, this will be moved to informative. Does this mean the Unified CPE will be referenced as an informative one?=20= Best Regards, Qi On 2013-7-11, at =E4=B8=8B=E5=8D=882:46, = wrote: > Hi, >=20 > I'm currently updating the lw4o6 draft in advance of IETF87. I plan to = include the following changes: >=20 > - I-D.bfmk-softwire-unified-cpe needs to be changed to = I-D.ietf-softwire-unified-cpe throughout >=20 > - Section 7 =E2=80=93 the reference from I-D.ietf-dhc-dhcpv4-over-ipv6 = should be changed to draft-ietf-dhc-dhcpv4-over-dhcpv6 in line with the = DHC recommendations >=20 > - Section 5.2 does not consider what happens if a packet is received = by the lwB4 that isn't addressed to the correct destination v4 address = with a valid l4 port (there's a small discussion about this for MAP-E on = the list at the moment). Propose that the lw4o6 draft is updated in line = with the outcome of this discussions so that MAP-E & lw4o6 CPE behaviour = stays aligned. >=20 > - I-D.bfmk-softwire-unified-cpe is currently included as a normative = reference, this will be moved to informative. >=20 > - Add text to section 5.2 saying that any IPv4 fragments received by = the lwB4 (CPE) after decapsulation are re-assembled before NAT, so that = the whole packet can be translated. This is based on some problems = encountered during interop testing. >=20 > If you have any comments or objections to the above, please let me = know. >=20 > Cheers, > Ian >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-56-83867696 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Ian = ,

- = I-D.bfmk-softwire-unified-cpe is currently included as a normative = reference, this will be moved to = informative.

Does this mean = the Unified CPE will be referenced as an informative = one? 


Best = Regards,
Qi

On 2013-7-11, at =E4=B8=8B=E5=8D=882:46, <ian.farrer@telekom.de> = <ian.farrer@telekom.de>= wrote:

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

= --Apple-Mail-56-83867696-- From internet-drafts@ietf.org Thu Jul 11 00:38:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8421F9D70; Thu, 11 Jul 2013 00:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 u38UL8A1kUV5; Thu, 11 Jul 2013 00:38:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B659A21F9D62; Thu, 11 Jul 2013 00:38:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130711073833.30444.51376.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 00:38:33 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-4rd-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, 11 Jul 2013 07:38:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : IPv4 Residual Deployment via IPv6 - a Stateless Solution= (4rd) Author(s) : Remi Despres Sheng Jiang Reinaldo Penno Yiu Lee Gang Chen Maoke Chen Filename : draft-ietf-softwire-4rd-06.txt Pages : 38 Date : 2013-07-11 Abstract: The 4rd automatic tunneling mechanism makes IPv4 Residual Deployment possible via IPv6 networks without maintaining for this per-customer states in 4rd-capable nodes (reverse of the IPv6 Rapid Deployment of 6rd). To cope with the IPv4 address shortage, customer sites can be assigned shared public IPv4 addresses with restricted port sets. 4rd can also support the scenarios that customer sites are assigned full public IPv4 addresses or a set of public IPv4 addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-4rd-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-4rd-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jiangsheng@huawei.com Thu Jul 11 00:43:05 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B52721F9D66 for ; Thu, 11 Jul 2013 00:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 IkfXwE0skum9 for ; Thu, 11 Jul 2013 00:43:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DCBFC21F963F for ; Thu, 11 Jul 2013 00:43:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUX35318; Thu, 11 Jul 2013 07:42:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 08:42:23 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Jul 2013 08:42:43 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 11 Jul 2013 15:42:38 +0800 From: Sheng Jiang To: Softwires WG Thread-Topic: New Version Notification for draft-ietf-softwire-4rd-06.txt Thread-Index: AQHOfgmuL8WpHGv/tUG6kiX6XdauzJlfF1ZA Date: Thu, 11 Jul 2013 07:42:38 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACABAE8@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] FW: New Version Notification for draft-ietf-softwire-4rd-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, 11 Jul 2013 07:43:05 -0000 SGksIFNvZnR3aXJlcywNCg0KVGhlIDRyZCBhdXRob3JzIGhhdmUganVzdCB1cGRhdGVkIHRoZSBk cmFmdC4gVGhpcyB1cGRhdGUgaXMgbWFpbmx5IHNvbHZlIHRoZSBpbmNvbXBsZXRlIG1vZGlmaWNh dGlvbiByZWdhcmRpbmcgdG8gTkFUNjQrIGluIGxhc3QgdXBkYXRlLCBpbiB3aGljaCB3ZSBhZGFw dGVkIHRvIDZtYW4gY29uY2x1c2lvbiAtIG5vIElJRC1yYW5nZSByZXNlcnZhdGlvbnMuIFRoaXMg aXNzdWUgd2FzIHJhaXNlZCBieSBSZW1pIChiZWxvdyBlbWFpbCkuIFRoZSBhdXRob3JzIHRoaW5r IGl0IGlzIG5vdyBmdWxsZWQgYWRkcmVzc2VkLg0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvc29mdHdpcmVzL2N1cnJlbnQvbXNnMDU0NDQuaHRtbA0KDQpCZXN0IHJlZ2Fy ZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj5T ZW50OiBUaHVyc2RheSwgSnVseSAxMSwgMjAxMyAzOjM5IFBNDQo+VG86IFJlbWkgRGVzcHJlczsg UmVpbmFsZG8gUGVubm87IEdhbmcgQ2hlbjsgU2hlbmcgSmlhbmc7IFlpdSBMZWU7IE1hb2tlDQo+ Q2hlbg0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1z b2Z0d2lyZS00cmQtMDYudHh0DQo+DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWll dGYtc29mdHdpcmUtNHJkLTA2LnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgUmVtaSBEZXNwcmVzIGFuZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0K PkZpbGVuYW1lOgkgZHJhZnQtaWV0Zi1zb2Z0d2lyZS00cmQNCj5SZXZpc2lvbjoJIDA2DQo+VGl0 bGU6CQkgSVB2NCBSZXNpZHVhbCBEZXBsb3ltZW50IHZpYSBJUHY2IC0gYSBTdGF0ZWxlc3MgU29s dXRpb24gKDRyZCkNCj5DcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0xMQ0KPkdyb3VwOgkJIHNvZnR3 aXJlDQo+TnVtYmVyIG9mIHBhZ2VzOiAzOA0KPlVSTDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXNvZnR3aXJlLTRyZC0wNi50eHQNCj5TdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zb2Z0d2ly ZS00cmQNCj5IdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc29mdHdpcmUtNHJkLTA2DQo+RGlmZjoNCj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLXNvZnR3aXJlLTRyZC0wNg0KPg0KPkFic3RyYWN0Og0KPiAgIFRo ZSA0cmQgYXV0b21hdGljIHR1bm5lbGluZyBtZWNoYW5pc20gbWFrZXMgSVB2NCBSZXNpZHVhbCBE ZXBsb3ltZW50DQo+ICAgcG9zc2libGUgdmlhIElQdjYgbmV0d29ya3Mgd2l0aG91dCBtYWludGFp bmluZyBmb3IgdGhpcyBwZXItY3VzdG9tZXINCj4gICBzdGF0ZXMgaW4gNHJkLWNhcGFibGUgbm9k ZXMgKHJldmVyc2Ugb2YgdGhlIElQdjYgUmFwaWQgRGVwbG95bWVudCBvZg0KPiAgIDZyZCkuICBU byBjb3BlIHdpdGggdGhlIElQdjQgYWRkcmVzcyBzaG9ydGFnZSwgY3VzdG9tZXIgc2l0ZXMgY2Fu IGJlDQo+ICAgYXNzaWduZWQgc2hhcmVkIHB1YmxpYyBJUHY0IGFkZHJlc3NlcyB3aXRoIHJlc3Ry aWN0ZWQgcG9ydCBzZXRzLiA0cmQNCj4gICBjYW4gYWxzbyBzdXBwb3J0IHRoZSBzY2VuYXJpb3Mg dGhhdCBjdXN0b21lciBzaXRlcyBhcmUgYXNzaWduZWQgZnVsbA0KPiAgIHB1YmxpYyBJUHY0IGFk ZHJlc3NlcyBvciBhIHNldCBvZiBwdWJsaWMgSVB2NCBhZGRyZXNzZXMuDQo+DQo+DQo+DQo+DQo+ VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From ian.farrer@telekom.de Thu Jul 11 01:12:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97A621F9B4D for ; Thu, 11 Jul 2013 01:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 DbrFYMDQMU54 for ; Thu, 11 Jul 2013 01:11:49 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF4721F9D6A for ; Thu, 11 Jul 2013 01:11:48 -0700 (PDT) Received: from he113676.emea1.cds.t-internal.com ([10.134.99.29]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 11 Jul 2013 10:11:45 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113676.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 11 Jul 2013 10:11:21 +0200 From: To: Date: Thu, 11 Jul 2013 10:11:20 +0200 Thread-Topic: [Softwires] Updates to lw4o6 Draft (draft-ietf-softwire-lw4over6) Thread-Index: Ac5+Djn7YFR1j1QNTuSCb5F8ki72fA== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CE0434E97E03Cianfarrertelekomde_" MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] Updates to lw4o6 Draft (draft-ietf-softwire-lw4over6) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 08:12:02 -0000 --_000_CE0434E97E03Cianfarrertelekomde_ Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: base64 SGkgUWksDQoNClllcy4gV2l0aGluIHRoZSB0ZXh0IG9mIHRoZSBkcmFmdCwgaXQgaXMgb25seSBy ZWNvbW1lbmRlZCB0aGF0IEktRC5iZm1rLXNvZnR3aXJlLXVuaWZpZWQtY3BlIGlzIGZvbGxvd2Vk IHNvIHRoZXJlJ3Mgbm8gcmVhc29uIGZvciBpdCB0byBiZSBub3JtYXRpdmUuDQoNCkNoZWVycywN Cklhbg0KDQpGcm9tOiBRaSBTdW4gPHN1bnFpLmNzbmV0LnRodUBnbWFpbC5jb208bWFpbHRvOnN1 bnFpLmNzbmV0LnRodUBnbWFpbC5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIDExIEp1bHkgMjAxMyAw OTozNA0KVG86IElhbiBGYXJyZXIgPGlhbi5mYXJyZXJAdGVsZWtvbS5kZTxtYWlsdG86aWFuLmZh cnJlckB0ZWxla29tLmRlPj4NCkNjOiAic29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpzb2Z0d2ly ZXNAaWV0Zi5vcmc+IiA8c29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIFVwZGF0ZXMgdG8gbHc0bzYgRHJhZnQgKGRy YWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYpDQoNCg0KSGkgSWFuICwNCg0KLSBJLUQuYmZtay1z b2Z0d2lyZS11bmlmaWVkLWNwZSBpcyBjdXJyZW50bHkgaW5jbHVkZWQgYXMgYSBub3JtYXRpdmUg cmVmZXJlbmNlLCB0aGlzIHdpbGwgYmUgbW92ZWQgdG8gaW5mb3JtYXRpdmUuDQoNCkRvZXMgdGhp cyBtZWFuIHRoZSBVbmlmaWVkIENQRSB3aWxsIGJlIHJlZmVyZW5jZWQgYXMgYW4gaW5mb3JtYXRp dmUgb25lPw0KDQoNCkJlc3QgUmVnYXJkcywNClFpDQoNCg0KT24gMjAxMy03LTExLCBhdCCkVaTI Mjo0NiwgPGlhbi5mYXJyZXJAdGVsZWtvbS5kZTxtYWlsdG86aWFuLmZhcnJlckB0ZWxla29tLmRl Pj4gPGlhbi5mYXJyZXJAdGVsZWtvbS5kZTxtYWlsdG86aWFuLmZhcnJlckB0ZWxla29tLmRlPj4g d3JvdGU6DQoNCkhpLA0KDQpJJ20gY3VycmVudGx5IHVwZGF0aW5nIHRoZSBsdzRvNiBkcmFmdCBp biBhZHZhbmNlIG9mIElFVEY4Ny4gSSBwbGFuIHRvIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBjaGFu Z2VzOg0KDQotIEktRC5iZm1rLXNvZnR3aXJlLXVuaWZpZWQtY3BlIG5lZWRzIHRvIGJlIGNoYW5n ZWQgdG8gSS1ELmlldGYtc29mdHdpcmUtdW5pZmllZC1jcGUgdGhyb3VnaG91dA0KDQotIFNlY3Rp b24gNyChViB0aGUgcmVmZXJlbmNlIGZyb20gSS1ELmlldGYtZGhjLWRoY3B2NC1vdmVyLWlwdjYg c2hvdWxkIGJlIGNoYW5nZWQgdG8gZHJhZnQtaWV0Zi1kaGMtZGhjcHY0LW92ZXItZGhjcHY2IGlu IGxpbmUgd2l0aCB0aGUgREhDIHJlY29tbWVuZGF0aW9ucw0KDQotIFNlY3Rpb24gNS4yIGRvZXMg bm90IGNvbnNpZGVyIHdoYXQgaGFwcGVucyBpZiBhIHBhY2tldCBpcyByZWNlaXZlZCBieSB0aGUg bHdCNCB0aGF0IGlzbid0IGFkZHJlc3NlZCB0byB0aGUgY29ycmVjdCBkZXN0aW5hdGlvbiB2NCBh ZGRyZXNzIHdpdGggYSB2YWxpZCBsNCBwb3J0ICh0aGVyZSdzIGEgc21hbGwgZGlzY3Vzc2lvbiBh Ym91dCB0aGlzIGZvciBNQVAtRSBvbiB0aGUgbGlzdCBhdCB0aGUgbW9tZW50KS4gUHJvcG9zZSB0 aGF0IHRoZSBsdzRvNiBkcmFmdCBpcyB1cGRhdGVkIGluIGxpbmUgd2l0aCB0aGUgb3V0Y29tZSBv ZiB0aGlzIGRpc2N1c3Npb25zIHNvIHRoYXQgTUFQLUUgJiBsdzRvNiBDUEUgYmVoYXZpb3VyIHN0 YXlzIGFsaWduZWQuDQoNCi0gSS1ELmJmbWstc29mdHdpcmUtdW5pZmllZC1jcGUgaXMgY3VycmVu dGx5IGluY2x1ZGVkIGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwgdGhpcyB3aWxsIGJlIG1vdmVk IHRvIGluZm9ybWF0aXZlLg0KDQotIEFkZCB0ZXh0IHRvIHNlY3Rpb24gNS4yIHNheWluZyB0aGF0 IGFueSBJUHY0IGZyYWdtZW50cyByZWNlaXZlZCBieSB0aGUgbHdCNCAoQ1BFKSBhZnRlciBkZWNh cHN1bGF0aW9uIGFyZSByZS1hc3NlbWJsZWQgYmVmb3JlIE5BVCwgc28gdGhhdCB0aGUgd2hvbGUg cGFja2V0IGNhbiBiZSB0cmFuc2xhdGVkLiBUaGlzIGlzIGJhc2VkIG9uIHNvbWUgcHJvYmxlbXMg ZW5jb3VudGVyZWQgZHVyaW5nIGludGVyb3AgdGVzdGluZy4NCg0KSWYgeW91IGhhdmUgYW55IGNv bW1lbnRzIG9yIG9iamVjdGlvbnMgdG8gdGhlIGFib3ZlLCBwbGVhc2UgbGV0IG1lIGtub3cuDQoN CkNoZWVycywNCklhbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnPG1haWx0 bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlcw0KDQo= --_000_CE0434E97E03Cianfarrertelekomde_ Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi Qi,
Yes. Within the text of the draft, it is only recommended that= I-D.bfmk-softwire-unified-cpe is followed so there's no reason for it to b= e normative.

Cheers,
Ian
=
From: Q= i Sun <sunqi.csnet.thu@gmai= l.com>
Date: Thursday, 1= 1 July 2013 09:34
To: Ian Farre= r <ian.farrer@telekom.de>= ;
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject= : Re: [Softwires] Updates to lw4o6 Draft (draft-ietf-softwire-lw4ov= er6)


Hi Ian ,

- I-D.bfmk-softwire-unified-cpe is c= urrently included as a normative reference, this will be moved to informati= ve.

Does this mean the Unified= CPE will be referenced as an informative one? 


Best Regards,
Qi


On 2013-7-11, at =A4U=A4=C82:46, <= ian.farrer@telekom.de> <= ian.farrer@telekom.de> wrot= e:

<= div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-= break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family= : Calibri, sans-serif; ">
Hi,

I'm current= ly updating the lw4o6 draft in advance of IETF87. I plan to include the fol= lowing changes:

- I-D.bfmk-softwire-unified-cpe ne= eds to be changed to I-D.ietf-softwire-unified-cpe throughout
- Section 7 – the reference from I-D.ietf-dhc-dhcpv4= -over-ipv6 should be changed to draft-ietf-dhc-dhcpv4-over-dhcpv6 in l= ine with the DHC recommendations

- Section 5.2 doe= s not consider what happens if a packet is received by the lwB4 that i= sn't addressed to the correct destination v4 address with a valid l4 port (= there's a small discussion about this for MAP-E on the list at the moment).= Propose that the lw4o6 draft is updated in line with the outcome of this d= iscussions so that MAP-E & lw4o6 CPE behaviour stays aligned.

- I-D.bfmk-softwire-unified-cpe is currently included as a = normative reference, this will be moved to informative.

- Add text to section 5.2 saying that any IPv4 fragments received by = the lwB4 (CPE) after decapsulation are re-assembled before NAT, so that the= whole packet can be translated. This is based on some problems encountered= during interop testing.

If you have any com= ments or objections to the above, please let me know.

<= div>Cheers,
Ian

_______________________________________________
Softwires mailing listSoftwires@ietf.org
https://www.ietf.org/m= ailman/listinfo/softwires

= --_000_CE0434E97E03Cianfarrertelekomde_-- From internet-drafts@ietf.org Thu Jul 11 02:47:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A714921F9F58; Thu, 11 Jul 2013 02:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 BsKz4eXOV9HH; Thu, 11 Jul 2013 02:47:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0521F9F96; Thu, 11 Jul 2013 02:47:19 -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.51.p2 Message-ID: <20130711094719.3379.97600.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 02:47:19 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-t-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:47:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port using Translation (MAP-T) Author(s) : Xing Li Congxiao Bao Wojciech Dec Ole Troan Satoru Matsushima Tetsuya Murakami Filename : draft-ietf-softwire-map-t-03.txt Pages : 32 Date : 2013-07-11 Abstract: This document specifies the "Mapping of Address and Port" double stateless NAT64 translation based solution (MAP-T) for providing shared or uniquely addressed IPv4 device connectivity to and across an IPv6 domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-t There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-t-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-t-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sunqi.csnet.thu@gmail.com Thu Jul 11 05:47:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284F711E815E for ; Thu, 11 Jul 2013 05:47:44 -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.001, 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 cxL0QGnIKQKP for ; Thu, 11 Jul 2013 05:47:43 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 70FCE11E8133 for ; Thu, 11 Jul 2013 05:47:43 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so7842669pbb.19 for ; Thu, 11 Jul 2013 05:47:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TmBT/GkNVrYVSSjPFmD9r5zhWc4F5EfpeRLBBlXg1pY=; b=x97avwTVGofQPocGaWZ6veUVXIm2fIqJU5e8omrRDEsyQyg6UuQfyMJtnuZsky2cS6 mdWfnAPU5bhfVz1D4zwdPK1hBesAWu4mV1LCpgLK3ggh1sZs6jd1jWGtcZ1/air1sXT7 lewknCfMXhmcDSCRYvWBqvWZuHhFWiS5IGCxs6AhKL0GtiiWQk7imGfuliVxg/i3GM1W m3LPZCWilAKkp6ddIxYukYX5yLvYhovQQvXKpG27uCXkJruPaF/hAu/mWN8GlK9UTdLE P0m/jtOHDEhvVHtWiAX+EyZbYx14ke6JtW4HT69DM6q3T89BGS/0Yj75rGRVRkhtfzHz iJdw== X-Received: by 10.68.212.229 with SMTP id nn5mr36585542pbc.44.1373546860732; Thu, 11 Jul 2013 05:47:40 -0700 (PDT) Received: from [192.168.1.107] ([166.111.68.233]) by mx.google.com with ESMTPSA id ry2sm39526316pbc.41.2013.07.11.05.47.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 05:47:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Thu, 11 Jul 2013 20:47:35 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51DC26FE.30905@gmail.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 12:47:44 -0000 Hi Rajiv, IMHO, logging this kind of error on the BR may be useful for = troubleshooting.=20 But in the case that BR uses IPv6 anycast, the ICMPv6 packet replied by = the CE could be sent to any of the BRs. Is it ok for any of the BRs to = log the error, or the error should be logged by the specific BR that = relays the incorrect packet to the CE? Or this is not an issue? Please correct me if I'm wrong. Best Regards, Qi On 2013-7-10, at =E4=B8=8A=E5=8D=8812:28, Rajiv Asati (rajiva) wrote: > IMO, we should not specify this behavior at all, since it could = provide a fantastic recipe for launching an attack against the BR.=20 >=20 > All the IPv4 packets failing the NAPT44 table check would result in = ICMPv6 traffic to the BR. Sure, BR could do the rate-limiting of the = incoming ICMPv6 packets, but it is consequential and should be avoided. >=20 > I suggest that the CPE should log this error in this case, and that's = it. No need to notify the BR. >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On >> Behalf Of Wojciech Dec >> Sent: Tuesday, July 09, 2013 11:58 AM >> To: Tom Taylor >> Cc: Softwires >> Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules >>=20 >> The MAP-T draft actually covers that, with the following text. MAP-E = should >> do the equivalent with ICMPv4. Think the text on this accidentally = fell >> through the cracks during the editorial cleanup. >>=20 >>=20 >>=20 >> The CE SHOULD check that MAP-T received >> packets' destination transport-layer destination port number is in >> the range allowed for by the CE's MAP BMR configuration. The CE >> SHOULD drop any non conforming packet and respond with an ICMPv6 >> "Address Unreachable" (Type 1, Code 3). >>=20 >>=20 >>=20 >> On 9 July 2013 17:06, Tom Taylor wrote: >>=20 >>=20 >> Section 8.1 of draft-ietf-softwire-map talks about rules for >> processing incoming packets. The first paragraph says that the CE = checks the >> received port number against the stateful port mapping table, but = doesn't >> say what it does if the port is out of range. >>=20 >> I'm interested in whether the BR receives a notification when = this >> happens (i.e., an ICMPv6 error message like the one described in the = next >> paragraph going the other way). This would allow the BR to log the = error. >>=20 >> Is the failure to specify CE action deliberate or should it be >> specified? >>=20 >> Tom Taylor >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >>=20 >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sunqi.csnet.thu@gmail.com Thu Jul 11 06:04:35 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A68311E8163 for ; Thu, 11 Jul 2013 06:04:35 -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 xaE5tU+IS6t9 for ; Thu, 11 Jul 2013 06:04:34 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 84A2A11E8151 for ; Thu, 11 Jul 2013 06:04:33 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so7802775pad.2 for ; Thu, 11 Jul 2013 06:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=R4IsBJOz/LwWyNEfK+/JBqwbFxM+R9j1zE1ZEuK0Jws=; b=NBZsg3QLNNrour7P/fKp0XJoLjduxR2O9XxSYtDif6CFRRoPvd300LMFqcl3cBW+r8 QG+fCSIroaOIxWDpafEpEs+bi5zqSzOGmQGIPNE5uogyzLp2Phkf1b3kAt0FqYVe+Nx5 VWZtAdPm5UQbG55Pvbhf/+JehKUygpqIEFrexYhpEOQbWXyNdOYNeeEFFUgD3MJ2HR8x Biz26f3tHaMu5/xSyK3rbCCYU6STPn2H7ih3k+aZUa7MCQXp8RQ3jV9vBSz1zEjhgvp5 PjUxW6g381EBf8092UbSwFG57iJaMJ6r4XiRtrNpkNWTHbKDvoCSrIwUNYbE9dHxNqjh B+ug== X-Received: by 10.66.189.225 with SMTP id gl1mr38457049pac.22.1373547873543; Thu, 11 Jul 2013 06:04:33 -0700 (PDT) Received: from [192.168.1.107] ([166.111.68.233]) by mx.google.com with ESMTPSA id ib9sm39647237pbc.43.2013.07.11.06.04.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 06:04:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Thu, 11 Jul 2013 21:04:25 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2F367E31-6B86-43D1-9C1D-D6E20ABF3214@gmail.com> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:04:35 -0000 Hi Woj, > - Naming: The name of the option will be changed, tentatively, to = OPTION_S46_*. This it in line with the recognition that there is wider = applicability of the options. Would you please elaborate (sorry if I missed some of the = discussions...)?=20 > - Flags: The flags field will be removed from the options. To = accomplish this, what was previously known as the BMR/FMR option, which = was using the flag to make the difference, will now be recast as two = separate "Basic Rule" and a "Forwarding Rule" Options. =46rom my understanding, the 'flags' are referred to those in MAP Rule = Option (rule-flags), right? Or do you mean the flags in MAP Container = Option will also be removed? > - A new sub-section intended only for clients using the MAP algorithm = will be introduced, and will describe how the options apply to MAP = provisioning. I'm not quite sure about the content that you plan to provide. IMHO, the = DHCPv6 client (not a MAP DHCPv6 client) is only able to handle the = DHCPv6 related interactions, rather than MAP related interactions. If = this part is about how the client side uses the MAP options, maybe the = MAP-E or the Unified CPE is a more proper place to go, IMHO. In addition, I notice in the current MAP option draft, the offset in MAP = Port Parameters Option is still 4, which is not consistent with the = draft-ietf-softwire-map-07. Maybe you can update it as well. Best Regards, Qi On 2013-7-8, at =E4=B8=8B=E5=8D=886:18, Wojciech Dec wrote: > Hi All, >=20 > I've begun preparing the next ste of changes to the DHCP MAP option = draft, and would like to highlight the main changes. >=20 > - Naming: The name of the option will be changed, tentatively, to = OPTION_S46_*. This it in line with the recognition that there is wider = applicability of the options. Furthermore the "Mapping" term will be = removed from the text, except when describing their use with MAP = algorithm. > - Default Mapping Rule: The DMR option will be removed, to allow the = re-use of the existing AFTR option, if desired and when applicable. > - Flags: The flags field will be removed from the options. To = accomplish this, what was previously known as the BMR/FMR option, which = was using the flag to make the difference, will now be recast as two = separate "Basic Rule" and a "Forwarding Rule" Options. > - Some of the generic DHCP requirements about known or unknown = processing appear to actually conflict with DHCP practice and will be = changed, eg an unknown sub-option should not lead to the entire option = being discarded. > - A new sub-section intended only for clients using the MAP algorithm = will be introduced, and will describe how the options apply to MAP = provisioning. > - Various other editorial changes to bring the text into shape. >=20 > If you have any initial comments, reactions to the above, please let = us know. >=20 > Regards, > W. Dec > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From rajiva@cisco.com Thu Jul 11 06:15:55 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA9C21F9C69 for ; Thu, 11 Jul 2013 06:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DUlZgjTVcAY for ; Thu, 11 Jul 2013 06:15:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DEE2221F9C96 for ; Thu, 11 Jul 2013 06:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3478; q=dns/txt; s=iport; t=1373548551; x=1374758151; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aQJiKn46exYpkrOVxMxywWGLxZXAqiF3FweggviuaeM=; b=hlP/JRO4k4CXkw/1MUExhwjC8Ik4UPmop/5pePDC7EqLSv6WlKNSH1Yh DaGugz6BFpbSA7YBqMjE3VDRVAOVeR6Q9s3QksS3DmsNeYBzeRwF9BU2+ LZ5GIf8Xy6PkFUxvBU+1Wz16zYf2W4HjjfO3fxztbGypqZwAP2flnzwBa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAJid3lGtJXHA/2dsb2JhbABagwkywh2BBhZ0giMBAQEDAQEBATcNJwsFBwQCAQgRBAEBAR4JByEGCxQJCAIEDgWHfQMJBgypdYRhDYhNBIx4gjYzBwaDA2wDlXGBaYwkhSaDEQ X-IronPort-AV: E=Sophos;i="4.87,1043,1363132800"; d="scan'208";a="233576069" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 11 Jul 2013 13:15:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6BDFioM013845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 13:15:44 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 08:15:44 -0500 From: "Rajiv Asati (rajiva)" To: "ian.farrer@telekom.de" Thread-Topic: [Softwires] Ambiguity in MAP-E receiving rules Thread-Index: AQHOfLX+Z1jN8ar5B02prcwEBIX9n5lc1KGA//+zkhCAAtHpgIAAHfaC Date: Thu, 11 Jul 2013 13:15:43 +0000 Message-ID: <9989163A-5B33-4D6F-9EAB-308298BBAD3C@cisco.com> References: , In-Reply-To: Accept-Language: en-US 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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:15:55 -0000 Hi Ian, We are in agreement.=20 Even with MAY, We should add the cautionary note about ICMP usage. =20 > The problem is common for lw4o6 CPEs. It would make sense to have common > behaviour across the CPEs. I agree. Cheers, Rajiv Sent from my Phone On Jul 11, 2013, at 2:28 AM, "ian.farrer@telekom.de" wrote: > Hi Rajiv, >=20 > The problem is common for lw4o6 CPEs. It would make sense to have common > behaviour across the CPEs. >=20 > A couple of comments below. >=20 > Cheers, > Ian >=20 >=20 >=20 > On 09/07/2013 18:28, "Rajiv Asati (rajiva)" wrote: >=20 >> IMO, we should not specify this behavior at all, since it could provide = a >> fantastic recipe for launching an attack against the BR. >=20 > [ian] Agreed >=20 >>=20 >>=20 >> All the IPv4 packets failing the NAPT44 table check would result in >> ICMPv6 traffic to the BR. Sure, BR could do the rate-limiting of the >> incoming ICMPv6 packets, but it is consequential and should be avoided. >>=20 >> I suggest that the CPE should log this error in this case, and that's it= . >> No need to notify the BR. >=20 > [ian] It may be useful to have the option of sending an ICMP error messag= e > for troubleshooting. What about if we have a 'should' requirement for > logging the error on the CPE and a 'may' for sending an ICMP error messag= e? >=20 >>=20 >> Cheers, >> Rajiv >>=20 >>=20 >>> -----Original Message----- >>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >>> Behalf Of Wojciech Dec >>> Sent: Tuesday, July 09, 2013 11:58 AM >>> To: Tom Taylor >>> Cc: Softwires >>> Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules >>>=20 >>> The MAP-T draft actually covers that, with the following text. MAP-E >>> should >>> do the equivalent with ICMPv4. Think the text on this accidentally fel= l >>> through the cracks during the editorial cleanup. >>>=20 >>>=20 >>>=20 >>> The CE SHOULD check that MAP-T received >>> packets' destination transport-layer destination port number is in >>> the range allowed for by the CE's MAP BMR configuration. The CE >>> SHOULD drop any non conforming packet and respond with an ICMPv6 >>> "Address Unreachable" (Type 1, Code 3). >>>=20 >>>=20 >>>=20 >>> On 9 July 2013 17:06, Tom Taylor wrote: >>>=20 >>>=20 >>> Section 8.1 of draft-ietf-softwire-map talks about rules for >>> processing incoming packets. The first paragraph says that the CE >>> checks the >>> received port number against the stateful port mapping table, but >>> doesn't >>> say what it does if the port is out of range. >>>=20 >>> I'm interested in whether the BR receives a notification when this >>> happens (i.e., an ICMPv6 error message like the one described in the >>> next >>> paragraph going the other way). This would allow the BR to log the >>> error. >>>=20 >>> Is the failure to specify CE action deliberate or should it be >>> specified? >>>=20 >>> Tom Taylor >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From rajiva@cisco.com Thu Jul 11 06:22:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F3F21F9C05 for ; Thu, 11 Jul 2013 06:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2S0mnn+AovZ for ; Thu, 11 Jul 2013 06:22:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 465D811E816E for ; Thu, 11 Jul 2013 06:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3291; q=dns/txt; s=iport; t=1373548961; x=1374758561; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5nkUJTxu2AoysLhKRnZUzS+9TofoQDlZW2Cv8jW4BRg=; b=JD4/eSkzoYH/zrm1R/h0f9eAbyxK1tf9MAeBxPN+SnNubp9EV8NM5ca/ 1wOVukSn2ykqmduQw0/eJ1bucFc9SZkU6OzUu72+gAzGS+fapvLvZ+k4e 60dCz8V1C+FCpZY2hSgTjWP74rUgkIDqSBExfpiToYdigRWti7bK3Av+X g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJid3lGtJXG9/2dsb2JhbABagwkyg1O+SoEGFnSCIwEBAQMBAQEBHgElJwsFBwQCAQgRBAEBAQEDCxgCAwIhBgsUCQgCBA4Fh30DCQYMijabOwGEA4RhDYhNBIEji1WCNjMHBoJNNmwDlXGBaYwkhSaDEQ X-IronPort-AV: E=Sophos;i="4.87,1043,1363132800"; d="scan'208";a="230558182" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jul 2013 13:22:36 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6BDMaPd025490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 13:22:36 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 08:22:35 -0500 From: "Rajiv Asati (rajiva)" To: Qi Sun Thread-Topic: [Softwires] Ambiguity in MAP-E receiving rules Thread-Index: AQHOfLX+Z1jN8ar5B02prcwEBIX9n5lc1KGA//+zkhCAAzvUgP//tfa2 Date: Thu, 11 Jul 2013 13:22:35 +0000 Message-ID: References: <51DC26FE.30905@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:22:47 -0000 Hi Qi, Good Q. Any BR should be enough to be notified, if notification were to be = provided. Cheers, Rajiv Sent from my Phone On Jul 11, 2013, at 8:47 AM, "Qi Sun" wrote: > Hi Rajiv, >=20 > IMHO, logging this kind of error on the BR may be useful for troubleshoot= ing.=20 > But in the case that BR uses IPv6 anycast, the ICMPv6 packet replied by t= he CE could be sent to any of the BRs. Is it ok for any of the BRs to log t= he error, or the error should be logged by the specific BR that relays the = incorrect packet to the CE? >=20 > Or this is not an issue? >=20 > Please correct me if I'm wrong. >=20 > Best Regards, > Qi >=20 > On 2013-7-10, at =1B$B>e8a=1B(B12:28, Rajiv Asati (rajiva) wrote: >=20 >> IMO, we should not specify this behavior at all, since it could provide = a fantastic recipe for launching an attack against the BR.=20 >>=20 >> All the IPv4 packets failing the NAPT44 table check would result in ICMP= v6 traffic to the BR. Sure, BR could do the rate-limiting of the incoming I= CMPv6 packets, but it is consequential and should be avoided. >>=20 >> I suggest that the CPE should log this error in this case, and that's it= . No need to notify the BR. >>=20 >> Cheers, >> Rajiv >>=20 >>=20 >>> -----Original Message----- >>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >>> Behalf Of Wojciech Dec >>> Sent: Tuesday, July 09, 2013 11:58 AM >>> To: Tom Taylor >>> Cc: Softwires >>> Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules >>>=20 >>> The MAP-T draft actually covers that, with the following text. MAP-E sh= ould >>> do the equivalent with ICMPv4. Think the text on this accidentally fel= l >>> through the cracks during the editorial cleanup. >>>=20 >>>=20 >>>=20 >>> The CE SHOULD check that MAP-T received >>> packets' destination transport-layer destination port number is in >>> the range allowed for by the CE's MAP BMR configuration. The CE >>> SHOULD drop any non conforming packet and respond with an ICMPv6 >>> "Address Unreachable" (Type 1, Code 3). >>>=20 >>>=20 >>>=20 >>> On 9 July 2013 17:06, Tom Taylor wrote: >>>=20 >>>=20 >>> Section 8.1 of draft-ietf-softwire-map talks about rules for >>> processing incoming packets. The first paragraph says that the CE check= s the >>> received port number against the stateful port mapping table, but doesn= 't >>> say what it does if the port is out of range. >>>=20 >>> I'm interested in whether the BR receives a notification when this >>> happens (i.e., an ICMPv6 error message like the one described in the ne= xt >>> paragraph going the other way). This would allow the BR to log the erro= r. >>>=20 >>> Is the failure to specify CE action deliberate or should it be >>> specified? >>>=20 >>> Tom Taylor >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From tom.taylor.stds@gmail.com Thu Jul 11 06:38:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824C211E814D for ; Thu, 11 Jul 2013 06:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMjNqJ1jcj2R for ; Thu, 11 Jul 2013 06:38:00 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC2711E8115 for ; Thu, 11 Jul 2013 06:37:59 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so17997512iec.41 for ; Thu, 11 Jul 2013 06:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ioxO1zmiTeLfetKQWvhOl3+L5EMJ3i2wLt07gOqapcU=; b=lxWJ8RtqnOHvKIk6wns5FQiD+MDw31MinGd97Z6Btwlj+TyqWbhKXc41zaHZ8p8obf Sj+Mn9OJ8U2jIJ6UXHucHpakq4eCJqzcwdTHhRvrH7DMNDHFvZAyKlLY2zIUNkxG1WUL lutx2MxCt63HhIjRbgbAUhWg2LmT1Pc65GkOUzREX0lDD6wJZOvhA2HAudsthg06kd2U ibxIUIBP9l9qGkMA5ji8RGrgAGVGRK0ZGxhXTqBNV7dNZsXl7nnt39jQXBRE4DZEuJVK uNBLkveMlKg9/GvDw+Tj23MLUiGPoAL4luq15p2p+ghB7hEJ698RdRKFPRz67JRcDioj XHbQ== X-Received: by 10.50.36.100 with SMTP id p4mr14152018igj.30.1373549879653; Thu, 11 Jul 2013 06:37:59 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id z15sm38627402igp.0.2013.07.11.06.37.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 06:37:59 -0700 (PDT) Message-ID: <51DEB538.20207@gmail.com> Date: Thu, 11 Jul 2013 09:38:00 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ian.farrer@telekom.de References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 13:38:00 -0000 On 11/07/2013 2:28 AM, ian.farrer@telekom.de wrote: > Hi Rajiv, > > The problem is common for lw4o6 CPEs. It would make sense to have common > behaviour across the CPEs. > > A couple of comments below. > > Cheers, > Ian > > > > On 09/07/2013 18:28, "Rajiv Asati (rajiva)" wrote: > >> IMO, we should not specify this behavior at all, since it could provide a >> fantastic recipe for launching an attack against the BR. > > [ian] Agreed > >> >> >> All the IPv4 packets failing the NAPT44 table check would result in >> ICMPv6 traffic to the BR. Sure, BR could do the rate-limiting of the >> incoming ICMPv6 packets, but it is consequential and should be avoided. >> >> I suggest that the CPE should log this error in this case, and that's it. >> No need to notify the BR. > [PTT] Is there any point to having the CPE generate logs? Who would look at them -- the operator or the customer? If logging is useful on the CPE, that should be reflected in our logging drafts, but if not, not. > [ian] It may be useful to have the option of sending an ICMP error message > for troubleshooting. What about if we have a 'should' requirement for > logging the error on the CPE and a 'may' for sending an ICMP error message? > ... From wdec.ietf@gmail.com Thu Jul 11 07:43:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A658711E81AB for ; Thu, 11 Jul 2013 07:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tLMZLT5KSJ-e for ; Thu, 11 Jul 2013 07:43:36 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A501211E81B5 for ; Thu, 11 Jul 2013 07:43:36 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id k14so4341306qcv.34 for ; Thu, 11 Jul 2013 07:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5sAU1lE9LQa+mwpuT1h7hYWWWcB5Z2xpSOjavoY5YaE=; b=QJCQhsHOomBFR20BF4vJiltQwSLAIbLCgxMuVI6+1fMpkmpIzdp2Y5uF76cWiPFhK9 1JUk+HUU+vtXllmfSE3UkV4XL52XYP3SIDgT4tx0H0YIWAbvbvt9ijeCKyvALs9oUq8r O/e1axSHsRS4idonSWxv8TAjdk54PtXmKbbzK44qsU3F3WUyeoD+xi/yj0OKaAjuKwZl t20FmCqdhybd+lzTEmla9nNI2ppKtay7zOE7EU7aQGe83/bqnQIdeSCrgP9H28WrU1f+ 5yPRoOyJsTs7mSOKRVnZiNo06Zkuf0J9hv0qWhO9+3S7KMrTYyG7dpYwJ45Ajq/fUJKj FFfg== MIME-Version: 1.0 X-Received: by 10.49.118.166 with SMTP id kn6mr30425417qeb.39.1373553816092; Thu, 11 Jul 2013 07:43:36 -0700 (PDT) Received: by 10.49.134.2 with HTTP; Thu, 11 Jul 2013 07:43:36 -0700 (PDT) In-Reply-To: <2F367E31-6B86-43D1-9C1D-D6E20ABF3214@gmail.com> References: <2F367E31-6B86-43D1-9C1D-D6E20ABF3214@gmail.com> Date: Thu, 11 Jul 2013 16:43:36 +0200 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=047d7b6780b449e0a804e13d6ba2 Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 14:43:37 -0000 --047d7b6780b449e0a804e13d6ba2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On 11 July 2013 15:04, Qi Sun wrote: > > Hi Woj, > > > - Naming: The name of the option will be changed, tentatively, to > OPTION_S46_*. This it in line with the recognition that there is wider > applicability of the options. > > Would you please elaborate (sorry if I missed some of the discussions...)= ? > Yes, there was a long thread started by Tomek. Given that the option is applicable beyond MAP a *suggestion* was to rename it. I'm personally ok either way. The "Softwire46" option is the currently proposed name. > > > - Flags: The flags field will be removed from the options. To accomplis= h > this, what was previously known as the BMR/FMR option, which was using th= e > flag to make the difference, will now be recast as two separate "Basic > Rule" and a "Forwarding Rule" Options. > > From my understanding, the 'flags' are referred to those in MAP Rule > Option (rule-flags), right? Or do you mean the flags in MAP Container > Option will also be removed? > All flag fields removed. > > > - A new sub-section intended only for clients using the MAP algorithm > will be introduced, and will describe how the options apply to MAP > provisioning. > > I'm not quite sure about the content that you plan to provide. IMHO, the > DHCPv6 client (not a MAP DHCPv6 client) is only able to handle the DHCPv6 > related interactions, rather than MAP related interactions. If this part = is > about how the client side uses the MAP options, maybe the MAP-E or the > Unified CPE is a more proper place to go, IMHO. > Well, the MAP Port Parameters option is clearly only applicable to a client that understands what it means. While having a separate, standalone 1-page draft for this single option is doable, it does become to look like unnecessary bureaucracy. DHCP Options are options after all... > > In addition, I notice in the current MAP option draft, the offset in MAP > Port Parameters Option is still 4, which is not consistent with the > draft-ietf-softwire-map-07. Maybe you can update it as well. > Yes, that will be updated. Thanks, Woj. > > > Best Regards, > Qi > > > On 2013-7-8, at =E4=B8=8B=E5=8D=886:18, Wojciech Dec wrote: > > > Hi All, > > > > I've begun preparing the next ste of changes to the DHCP MAP option > draft, and would like to highlight the main changes. > > > > - Naming: The name of the option will be changed, tentatively, to > OPTION_S46_*. This it in line with the recognition that there is wider > applicability of the options. Furthermore the "Mapping" term will be > removed from the text, except when describing their use with MAP algorith= m. > > - Default Mapping Rule: The DMR option will be removed, to allow the > re-use of the existing AFTR option, if desired and when applicable. > > - Flags: The flags field will be removed from the options. To accomplis= h > this, what was previously known as the BMR/FMR option, which was using th= e > flag to make the difference, will now be recast as two separate "Basic > Rule" and a "Forwarding Rule" Options. > > - Some of the generic DHCP requirements about known or unknown > processing appear to actually conflict with DHCP practice and will be > changed, eg an unknown sub-option should not lead to the entire option > being discarded. > > - A new sub-section intended only for clients using the MAP algorithm > will be introduced, and will describe how the options apply to MAP > provisioning. > > - Various other editorial changes to bring the text into shape. > > > > If you have any initial comments, reactions to the above, please let us > know. > > > > Regards, > > W. Dec > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > --047d7b6780b449e0a804e13d6ba2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


On 11 July 2013 15:04, Qi Sun <sunqi.csnet.thu@gmail.co= m> wrote:

Hi Woj,

> - Naming: The name of the option will be changed, tentatively, to OPTI= ON_S46_*. This it in line with the recognition that there is wider applicab= ility of the options.

Would you please elaborate (sorry if I missed some of the discussions= ...)?

Yes, there was a long thread star= ted by Tomek. Given that the option is applicable beyond MAP a *suggestion*= was to rename it. I'm personally ok either way. The "Softwire46&q= uot; option is the currently proposed name.
=C2=A0

> - Flags: The flags field will be removed from the options. To accompli= sh this, what was previously known as the BMR/FMR option, which was using t= he flag to make the difference, will now be recast as two separate "Ba= sic Rule" and a "Forwarding Rule" Options.

From my understanding, the 'flags' are referred to those in M= AP Rule Option (rule-flags), right? Or do you mean the flags in MAP Contain= er Option will also be removed?

All fla= g fields removed.

> - A new sub-section intended only for clients using the MAP algorithm = will be introduced, and will describe how the options apply to MAP provisio= ning.

I'm not quite sure about the content that you plan to provide. IM= HO, the DHCPv6 client (not a MAP DHCPv6 client) is only able to handle the = DHCPv6 related interactions, rather than MAP related interactions. If this = part is about how the client side uses the MAP options, maybe the MAP-E or = the Unified CPE is a more proper place to go, IMHO.

Well, the MAP Port Parameters option is cl= early only applicable to a client that understands what it means. While hav= ing a separate, standalone 1-page draft for this single option is doable, i= t does become to look like unnecessary bureaucracy. DHCP Options are option= s after all...

In addition, I notice in the current MAP option draft, the offset in MAP Po= rt Parameters Option is still 4, which is not consistent with the draft-iet= f-softwire-map-07. Maybe you can update it as well.

Yes, that will be updated.

Thanks,
Woj.
=C2=A0


Best Regards,
Qi


On 2013-7-8, at =E4=B8=8B=E5=8D=886:18, Wojciech Dec wrote:

> Hi All,
>
> I've begun preparing the next ste of changes to the DHCP MAP optio= n draft, and would like to highlight the main changes.
>
> - Naming: The name of the option will be changed, tentatively, to OPTI= ON_S46_*. This it in line with the recognition that there is wider applicab= ility of the options. Furthermore the "Mapping" term will be remo= ved from the text, except when describing their use with MAP algorithm.
> - Default Mapping Rule: The DMR option will be removed, to allow the r= e-use of the existing AFTR option, if desired and when applicable.
> - Flags: The flags field will be removed from the options. To accompli= sh this, what was previously known as the BMR/FMR option, which was using t= he flag to make the difference, will now be recast as two separate "Ba= sic Rule" and a "Forwarding Rule" Options.
> - Some of the generic DHCP requirements about known or unknown process= ing appear to actually conflict with DHCP practice and will be changed, eg = an unknown sub-option should not lead to the entire option being discarded.=
> - A new sub-section intended only for clients using the MAP algorithm = will be introduced, and will describe how the options apply to MAP provisio= ning.
> - Various other editorial changes to bring the text into shape.
>
> If you have any initial comments, reactions to the above, please let u= s know.
>
> Regards,
> W. Dec
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires


--047d7b6780b449e0a804e13d6ba2-- From tom.taylor.stds@gmail.com Thu Jul 11 10:07:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380E421F9F3D for ; Thu, 11 Jul 2013 10:07:57 -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 qoYGFk5s-Jit for ; Thu, 11 Jul 2013 10:07:56 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3121F9F37 for ; Thu, 11 Jul 2013 10:07:56 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id qd12so18683499ieb.30 for ; Thu, 11 Jul 2013 10:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KtqX2SaAPutZQmy98iQ7Dk3a3PbO+DXaweGVd9Dhl2U=; b=UJc/2tYA1fEwTjAwve8ODZ/e+3lM6AjAGOM/BqfhEwTLPBkGnX33atuTZPZsyx5uSi y5XQJqT6Q3EZ6MB2+VyMQPn1/nQ3cwRH7Cbl+KWaXsMp05sq90OTCRsMaoB7UeVbEYIy 7T++Z7Z70VP0Lqg6YcIkR5r7SkSDX2MkX3W0C0b9xAgLpwkgDwKbVENopcGN4wMjtdZ/ 4SLWXm1EDC+0JVnYolZis9mmPIB2lrQ3HEm+mGWTYTvDMqyM5zmFYpGRjEhm1Ab4dWGu vXF5eaG23DxBBT+vgvh5irXTirDbXOiYrGAUC7dbsYvgf6v8z9Vkv34HWKc7yxC1ClrR VrXw== X-Received: by 10.50.225.66 with SMTP id ri2mr13570581igc.55.1373562476376; Thu, 11 Jul 2013 10:07:56 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id fu2sm13632656igb.3.2013.07.11.10.07.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 10:07:55 -0700 (PDT) Message-ID: <51DEE66C.7010607@gmail.com> Date: Thu, 11 Jul 2013 13:07:56 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 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 WG Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 11 Jul 2013 17:07:57 -0000 Cathy Zhou and Behcet Sarikaya, 6rd multicast, http://datatracker.ietf.org/doc/draft-sarikaya-softwire-6rdmulticast/ 10 minutes On 09/07/2013 6:54 AM, Yong Cui wrote: > Hi folks, > > > We will have our Softwires session on Tuesday morning in the coming IETF > meeting in Berlin. > > If you would like to have a time slot, please reply this email and send > your request to Suresh and me in the following format by July 12 (Friday): > > (name, title, link to IETF datatracker, minutes requested). > > > Thanks, > > Yong & Suresh > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From sunqi.csnet.thu@gmail.com Thu Jul 11 19:48:24 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AAD21F9A5E for ; Thu, 11 Jul 2013 19:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 YYqYTQ7pXsJl for ; Thu, 11 Jul 2013 19:48:23 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EEFED21F8D0D for ; Thu, 11 Jul 2013 19:48:16 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp12so8422381pab.7 for ; Thu, 11 Jul 2013 19:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=ZY1kBjV+gWTIxrslSVRJ+CRWHJ1ovGhi8QTpxdheK+8=; b=mWhiexZqFS8mWhQj7vJYIO24nqLVr3ScUBWavvAZeXYIyuYO3I68B6HGNaAgcCeX9v g+pNqpFMI1amWZ7KU8wWRvtujtgr08TQVIqogERrTLV0W8RWjqyh989zR8Eukk34vD33 i3EErVgaJZ179ADy4+5rUAByHMKaDdScvP9EWaqZHuOcfpM1p+z0wqZHJ02PSs+lhiUh EHjbGzRH1G5NQCXXoX8pQ9jVyZrXx2Y6tCWjwkV0ZHazfqVrvEuDpzE4b2d7CbMUg2Dc wBsruQiMCDud5boOjey74KwXcWyG0l3OPoGMvfKxA/GIcRBjtMA4kWb3Udh+cOPj08rk WKhA== X-Received: by 10.66.122.194 with SMTP id lu2mr40573721pab.125.1373597296681; Thu, 11 Jul 2013 19:48:16 -0700 (PDT) Received: from [192.168.1.107] ([166.111.68.233]) by mx.google.com with ESMTPSA id iq3sm32393839pbb.20.2013.07.11.19.48.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 19:48:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-60-153099841 From: Qi Sun In-Reply-To: Date: Fri, 12 Jul 2013 10:48:10 +0800 Message-Id: References: <2F367E31-6B86-43D1-9C1D-D6E20ABF3214@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 02:48:24 -0000 --Apple-Mail-60-153099841 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Woj, On 2013-7-11, at =E4=B8=8B=E5=8D=8810:43, Wojciech Dec wrote: > Hi, >=20 >=20 > Yes, there was a long thread started by Tomek. Given that the option = is applicable beyond MAP a *suggestion* was to rename it. I'm personally = ok either way. The "Softwire46" option is the currently proposed name. [Qi] At the first glance, I thought it stood for "Stateless46" option... = (sorry for missing the discussion) > =20 >=20 > > - Flags: The flags field will be removed from the options. To = accomplish this, what was previously known as the BMR/FMR option, which = was using the flag to make the difference, will now be recast as two = separate "Basic Rule" and a "Forwarding Rule" Options. >=20 > =46rom my understanding, the 'flags' are referred to those in MAP Rule = Option (rule-flags), right? Or do you mean the flags in MAP Container = Option will also be removed? >=20 > All flag fields removed.=20 [Qi] If so, how could a MAP node finds out it should work as MAP-E or = MAP-T? Or we can take this MAP DHCP draft as "MAP-E DHCP"?=20 >=20 > > - A new sub-section intended only for clients using the MAP = algorithm will be introduced, and will describe how the options apply to = MAP provisioning. >=20 > I'm not quite sure about the content that you plan to provide. IMHO, = the DHCPv6 client (not a MAP DHCPv6 client) is only able to handle the = DHCPv6 related interactions, rather than MAP related interactions. If = this part is about how the client side uses the MAP options, maybe the = MAP-E or the Unified CPE is a more proper place to go, IMHO. >=20 > Well, the MAP Port Parameters option is clearly only applicable to a = client that understands what it means. While having a separate, = standalone 1-page draft for this single option is doable, it does become = to look like unnecessary bureaucracy. DHCP Options are options after = all... [Qi] So this sub-section is about the behaviors of the client after = receiving the MAP Port Parameters Option?=20 Best Regards, Qi >=20 > Thanks, > Woj. > =20 >=20 >=20 > Best Regards, > Qi >=20 >=20 > On 2013-7-8, at =E4=B8=8B=E5=8D=886:18, Wojciech Dec wrote: >=20 > > Hi All, > > > > I've begun preparing the next ste of changes to the DHCP MAP option = draft, and would like to highlight the main changes. > > > > - Naming: The name of the option will be changed, tentatively, to = OPTION_S46_*. This it in line with the recognition that there is wider = applicability of the options. Furthermore the "Mapping" term will be = removed from the text, except when describing their use with MAP = algorithm. > > - Default Mapping Rule: The DMR option will be removed, to allow the = re-use of the existing AFTR option, if desired and when applicable. > > - Flags: The flags field will be removed from the options. To = accomplish this, what was previously known as the BMR/FMR option, which = was using the flag to make the difference, will now be recast as two = separate "Basic Rule" and a "Forwarding Rule" Options. > > - Some of the generic DHCP requirements about known or unknown = processing appear to actually conflict with DHCP practice and will be = changed, eg an unknown sub-option should not lead to the entire option = being discarded. > > - A new sub-section intended only for clients using the MAP = algorithm will be introduced, and will describe how the options apply to = MAP provisioning. > > - Various other editorial changes to bring the text into shape. > > > > If you have any initial comments, reactions to the above, please let = us know. > > > > Regards, > > W. Dec > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail-60-153099841 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Woj,

On 2013-7-11, at =E4=B8=8B=E5=8D=8810:43, Wojciech Dec = wrote:

Hi,


Yes, there was a long thread started by Tomek. Given = that the option is applicable beyond MAP a *suggestion* was to rename = it. I'm personally ok either way. The "Softwire46" option is the = currently proposed = name.

[Qi] = At the first glance, I thought it stood for "Stateless46" option... = (sorry for missing the discussion)

 

> - Flags: The flags field will be removed from the options. To = accomplish this, what was previously known as the BMR/FMR option, which = was using the flag to make the difference, will now be recast as two = separate "Basic Rule" and a "Forwarding Rule" Options.

=46rom my understanding, the 'flags' are referred to those in MAP = Rule Option (rule-flags), right? Or do you mean the flags in MAP = Container Option will also be = removed?

All flag fields removed. =

[Qi] If so, = how could a MAP node finds out it should work as MAP-E or MAP-T? Or we = can take this MAP DHCP draft as "MAP-E DHCP"? 


> - A new sub-section intended only for clients using the MAP = algorithm will be introduced, and will describe how the options apply to = MAP provisioning.

I'm not quite sure about the content that you plan to provide. = IMHO, the DHCPv6 client (not a MAP DHCPv6 client) is only able to handle = the DHCPv6 related interactions, rather than MAP related interactions. = If this part is about how the client side uses the MAP options, maybe = the MAP-E or the Unified CPE is a more proper place to go, IMHO.

Well, the MAP Port Parameters option is = clearly only applicable to a client that understands what it means. = While having a separate, standalone 1-page draft for this single option = is doable, it does become to look like unnecessary bureaucracy. DHCP = Options are options after = all...

[Qi] So = this sub-section is about the behaviors of the client after receiving = the MAP Port Parameters Option? 

Best = Regards,
Qi


Thanks,
Woj.
 


Best Regards,
Qi


On 2013-7-8, at =E4=B8=8B=E5=8D=886:18, Wojciech Dec wrote:

> Hi All,
>
> I've begun preparing the next ste of changes to the DHCP MAP option = draft, and would like to highlight the main changes.
>
> - Naming: The name of the option will be changed, tentatively, to = OPTION_S46_*. This it in line with the recognition that there is wider = applicability of the options. Furthermore the "Mapping" term will be = removed from the text, except when describing their use with MAP = algorithm.
> - Default Mapping Rule: The DMR option will be removed, to allow = the re-use of the existing AFTR option, if desired and when = applicable.
> - Flags: The flags field will be removed from the options. To = accomplish this, what was previously known as the BMR/FMR option, which = was using the flag to make the difference, will now be recast as two = separate "Basic Rule" and a "Forwarding Rule" Options.
> - Some of the generic DHCP requirements about known or unknown = processing appear to actually conflict with DHCP practice and will be = changed, eg an unknown sub-option should not lead to the entire option = being discarded.
> - A new sub-section intended only for clients using the MAP = algorithm will be introduced, and will describe how the options apply to = MAP provisioning.
> - Various other editorial changes to bring the text into shape.
>
> If you have any initial comments, reactions to the above, please = let us know.
>
> Regards,
> W. Dec
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires



= --Apple-Mail-60-153099841-- From sunqi.csnet.thu@gmail.com Sat Jul 13 09:39:20 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4E721F9ED3 for ; Sat, 13 Jul 2013 09:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 FbwPo0UGItSr for ; Sat, 13 Jul 2013 09:39:19 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7970921F9ECE for ; Sat, 13 Jul 2013 09:39:19 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x11so9543564pdj.15 for ; Sat, 13 Jul 2013 09:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; bh=ahEk2zQk3JzbYoWm5i9f22edwtLQLm/oQ2wYDfEQFQ8=; b=ksqmM0ayCaghIc2gpTJzOMBCF30iGXTYvD8rNZVv86yHS3MtQ6Q6T44YJUswdLMF/8 qcTisC18q2vMZF89pTLseMZQOjtr1WPAS9o0tAcqHtXtMghny2sYCXsTEFEN7ZtpQVoO IfAHuRkkqLl4titB4xZEAYCN8gdph2XjOP82qQd8MICUZAkWO9pA3p5nvvmgdoh+rJIr 9CuKdeeK4HzepmyWUvdbwnx/mmYGWJX6apxYjIv2GN1mDLKkMy+YGRAuYVZH8tVr9ti9 +JJRc8++Kp2yU1U1kehiEJw7EuRACVEOrPepvyz7VnMz70gN2Q5XUEK3SLVoK6SzEOBC t2FA== X-Received: by 10.68.211.138 with SMTP id nc10mr46900086pbc.162.1373733559183; Sat, 13 Jul 2013 09:39:19 -0700 (PDT) Received: from [192.168.0.115] ([59.64.255.202]) by mx.google.com with ESMTPSA id s5sm51474134pbo.38.2013.07.13.09.39.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 09:39:18 -0700 (PDT) From: Qi Sun Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-76-289362687 Date: Sun, 14 Jul 2013 00:39:13 +0800 In-Reply-To: <5193CFBB.8030900@gmail.com> To: Softwires References: <5193CFBB.8030900@gmail.com> Message-Id: <117DE5F7-3A58-44CD-8E22-11F6286DBDB3@gmail.com> X-Mailer: Apple Mail (2.1084) Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 16:39:20 -0000 --Apple-Mail-76-289362687 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear wg,=20 I've reviewed the draft and have some comments in addition to Tom's. = May the comments make the draft better.=20 Please correct me if there is any mistake. Best Regards, Qi 1. In Fig 1, there is an element called the Core Router. Does it mean = MAP BR? I think the terms should be consistent.=20 2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR could = be provisioned by the DS-Lite AFTR Name option. But the DMR is still in = use in MAP-T. IMO, this is an issue. But maybe the WG could give some = guidance on handling this.=20 3. Section 4.2.2 This part talks about sub-domain, which is a term that is not defined in = the MAP draft. I think there should be some text about the what a = 'sub-domain' is and how to differentiate 'sub-domain' from a MAP domain. 4. Section 4.2.5, para 3: It is the wg consensus that the non-contiguous port set has nothing to = do with 'better security'. I recommend text about this be removed. 5. Section 4.3, page 14: 'as long as it is up and ready to take over the virtual IPv6 address, quick failover can be achieved.' Does the term 'virtual IPv6 address' stand for anycast IPv6 address, or = something else? 6. Section 4.3, page 14: 'Therefore, when using anycast addresses, it is RECOMMENDED that they be only used as destination address, and never as source addresses. BRs SHOULD be configured to accept traffic sent to the anycast address, but use an unicast address as source.' The packets from the BR to the CE is : Src: BR's unicast addr, Dest: CE's unicast addr But what should be the destination address of the packets from CE to BR = after the CE receives the responses sent from/via the BR? The BR's = unicast addr, or the anycast addr? IMO, there should be some text like = 'The CE SHOULD always use the anycast address of the BR if there is one = when sending packets to the BR.' But there is another issue (maybe = minor): how can the CE determine which is the anycast address? Some Nits: 1. There are some acronyms in the draft, which are better to be expanded = when first used. 2. The para below Fig 2:=20 For model A/B, one CE only need (needs) to correspond to a BR, while in model C one CE have = (has) to correspond with multiple BRs. Figure 3 illustrate (illustrates) a = typical case, where the home network have (has) multiple connections to multiple providers or multiple logical connections to the same provider. 3. Section 4.2, 1st para: However, all CEs within the sub-domain will have the same BMR. in = which the BMR of all CEs is the same. =3D> However, all CEs within the sub-domain will have the same BMR. 4. Section 4.2.3.2, 1st para: Assigning all BMRs in MAP domain to each CE as FMRs, Mesh communications can be achieved among all CEs. =3D> By assigning all BMRs in a MAP domain to each CE as the FMR, = Mesh communications can be achieved among all CEs. 5. Section 4.2.6, para 3: For the ISP who have number of scattered IPv4 address prefixes, in order to reduce the FMRs, according to needs of ports they can divide different class. =3D> have -> has, reduce the FMRs -> reduce the number of FMRs, class = -> classes 6. Section 4.2.7, 3. PMTU and fragmentation, para 2 cannot to -> cannot do 7. Section 4.3, para 2 the path from the CE to an IPv4 peer via the BR should be close to the one that would be taken if the CE had native IPv4 connectivity. =3D> the path from the CE to an IPv4 peer via the BR should be = closer than that would be taken if the CE had native IPv4 connectivity. 8. Section 6.2.2, para 1 When a network evolve (evolves) to a post-IPv6 era. (,) It might be good for ISP to consider implement enforcements rules to help IPv6 migration. =3D> When a network evolves to a post-IPv6 era, it might be good for ISPs to consider to implement enforcement rules to help = IPv6 migration.= --Apple-Mail-76-289362687 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = wg, 

I've reviewed the draft and have some = comments in addition to Tom's.  May the comments make the draft = better. 
Please correct me = if there is any mistake.
Best Regards,
Qi
1. In Fig 1, there is an = element called the Core Router. Does it mean MAP BR? I think the terms = should be consistent. 
2. = Currently, there is no DMR in MAP-E. The IPv6 address of the BR could be = provisioned by the DS-Lite AFTR Name option. But the DMR is still in use = in MAP-T. IMO, this is an issue. But maybe the WG could give some = guidance on handling this. 
This part = talks about sub-domain, which is a term that is not defined in the MAP = draft. I think there should be some text about the what a = 'sub-domain' is and how to differentiate 'sub-domain' from a MAP = domain.
4. Section 4.2.5, para = 3:
It is the wg consensus that = the non-contiguous port set has nothing to do with 'better security'. I = recommend text about this be removed.
5. Section 4.3, page 14:
Does the term 'virtual IPv6 address' = stand for anycast IPv6 address, or something else?
6. Section 4.3, page 14:

The packets from the BR to the CE is = :
Src: BR's unicast addr, Dest: = CE's unicast addr
But what = should be the destination address of the packets from CE to BR after the = CE receives the responses sent from/via the BR? The BR's unicast addr, = or the anycast addr? IMO, there should be some text like 'The CE SHOULD = always use the anycast address of the BR if there is one when sending = packets to the BR.'  But there is another issue (maybe minor): how = can the CE determine which is the anycast address?


Some = Nits:
1. There are some = acronyms in the draft, which are better to be expanded when first = used.
2. The para below Fig = 2: 
   For model A/B, one = CE
   only need (needs) to correspond to a BR, while in = model C one CE have (has) to
   providers = or multiple logical connections to the same provider.
3. Section 4.2, 1st para:
    However, all CEs = within the sub-domain will have the same BMR. in which the BMR of all = CEs is the same.
4. = Section 4.2.3.2, 1st para:
   = communications can be achieved among all CEs.
   =3D>   By = assigning all BMRs in a MAP domain to each CE as the FMR, Mesh
5. = Section 4.2.6, para 3:
   For the ISP who have = number
   of scattered IPv4 address = prefixes, in order to reduce the FMRs,
  =3D> have -> has, = reduce the FMRs -> reduce the number of FMRs, class -> = classes
6. Section 4.2.7, 3. = PMTU and fragmentation, para 2
7. Section 4.3, para 2
8. Section 6.2.2, para 1
   be good for ISP to consider = implement enforcements rules to help IPv6
   be good for ISPs to consider = to implement enforcement rules to help IPv6
To: Qi Sun , Softwires Thread-Topic: [Softwires] Comments on draft-ietf-softwire-map-deployment-01 Thread-Index: AQHOf+eKne6Cc9hXlESpUEoTvself5lk1Hlw Date: Sun, 14 Jul 2013 23:40:24 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAE@xmb-rcd-x01.cisco.com> References: <5193CFBB.8030900@gmail.com> <117DE5F7-3A58-44CD-8E22-11F6286DBDB3@gmail.com> In-Reply-To: <117DE5F7-3A58-44CD-8E22-11F6286DBDB3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.226.34] Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAExmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-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, 14 Jul 2013 23:40:31 -0000 --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAExmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qu, A comment on point 2: >2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR could b= e > provisioned by the DS-Lite AFTR Name option. The DS-Lite ATFR Name option defined in RFC 6334 is used to carry a fully q= ualified domain name of the AFTR not an IPv6 address. There was a proposal and a long discussion on the dhc working group about t= o be able to use the same option to provision either the name or the addre= ss but the wg did not reach consensus on that idea. So in my understanding= you cannot carry an IPv6 address into the DS-Lite AFTR Name option. In addition even if you could, it would sound confusing in my opinion, usin= g a DS-Lite specific option to provision MAP specific parameters. Thanks Regards Roberta From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Qi Sun Sent: Saturday, July 13, 2013 12:39 PM To: Softwires Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-01 Dear wg, I've reviewed the draft and have some comments in addition to Tom's. May t= he comments make the draft better. Please correct me if there is any mistake. Best Regards, Qi 1. In Fig 1, there is an element called the Core Router. Does it mean MAP B= R? I think the terms should be consistent. 2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR could be= provisioned by the DS-Lite AFTR Name option. But the DMR is still in use i= n MAP-T. IMO, this is an issue. But maybe the WG could give some guidance o= n handling this. 3. Section 4.2.2 This part talks about sub-domain, which is a term that is not defined in th= e MAP draft. I think there should be some text about the what a 'sub-domain= ' is and how to differentiate 'sub-domain' from a MAP domain. 4. Section 4.2.5, para 3: It is the wg consensus that the non-contiguous port set has nothing to do w= ith 'better security'. I recommend text about this be removed. 5. Section 4.3, page 14: 'as long as it is up and ready to take over the virtual IPv6 address, quick failover can be achieved.' Does the term 'virtual IPv6 address' stand for anycast IPv6 address, or som= ething else? 6. Section 4.3, page 14: 'Therefore, when using anycast addresses, it is RECOMMENDED that they be only used as destination address, and never as source addresses. BRs SHOULD be configured to accept traffic sent to the anycast address, but use an unicast address as source.' The packets from the BR to the CE is : Src: BR's unicast addr, Dest: CE's unicast addr But what should be the destination address of the packets from CE to BR aft= er the CE receives the responses sent from/via the BR? The BR's unicast add= r, or the anycast addr? IMO, there should be some text like 'The CE SHOULD = always use the anycast address of the BR if there is one when sending packe= ts to the BR.' But there is another issue (maybe minor): how can the CE de= termine which is the anycast address? Some Nits: 1. There are some acronyms in the draft, which are better to be expanded wh= en first used. 2. The para below Fig 2: For model A/B, one CE only need (needs) to correspond to a BR, while in model C one CE have (h= as) to correspond with multiple BRs. Figure 3 illustrate (illustrates) a typic= al case, where the home network have (has) multiple connections to multiple providers or multiple logical connections to the same provider. 3. Section 4.2, 1st para: However, all CEs within the sub-domain will have the same BMR. in which= the BMR of all CEs is the same. =3D> However, all CEs within the sub-domain will have the same BMR. 4. Section 4.2.3.2, 1st para: Assigning all BMRs in MAP domain to each CE as FMRs, Mesh communications can be achieved among all CEs. =3D> By assigning all BMRs in a MAP domain to each CE as the FMR, Mesh communications can be achieved among all CEs. 5. Section 4.2.6, para 3: For the ISP who have number of scattered IPv4 address prefixes, in order to reduce the FMRs, according to needs of ports they can divide different class. =3D> have -> has, reduce the FMRs -> reduce the number of FMRs, class -> = classes 6. Section 4.2.7, 3. PMTU and fragmentation, para 2 cannot to -> cannot do 7. Section 4.3, para 2 the path from the CE to an IPv4 peer via the BR should be close to the one that would be taken if the CE had native IPv4 connectivity. =3D> the path from the CE to an IPv4 peer via the BR should be closer than that would be taken if the CE had native IPv4 connectivity. 8. Section 6.2.2, para 1 When a network evolve (evolves) to a post-IPv6 era. (,) It might be good for ISP to consider implement enforcements rules to help IPv6 migration. =3D> When a network evolves to a post-IPv6 era, it might be good for ISPs to consider to implement enforcement rules to help IPv6 migration. --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAExmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qu,<= /p>

A comment on point 2:

>2. Currently, there = is no DMR in MAP-E. The IPv6 address of the BR could be

> provisioned by the DS-Lite AFTR Name option.

 <= /p>

The DS-Lite ATFR Name opt= ion defined in RFC 6334 is used to carry a fully qualified domain name of t= he AFTR not an IPv6 address.

There was a proposal and = a long discussion on the dhc working group about to be able to use the same= option to provision either  the name or the address but the wg did not reach consensus on that idea.  So in my understanding = you cannot carry an IPv6 address into the DS-Lite AFTR Name option.

In addition even if you c= ould, it would sound confusing in my opinion, using a DS-Lite specific opti= on to provision MAP specific parameters.

    &= nbsp;           &nbs= p;         

Thanks<= /p>

Regards=

Roberta=

 <= /p>

From: softwire= s-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Qi Sun
Sent: Saturday, July 13, 2013 12:39 PM
To: Softwires
Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deploym= ent-01

 

Dear wg, 

 

I've reviewed the draft and have some comments in addition= to Tom's.  May the comments make the draft better. 

Please correct me if there is any mistake.

 

Best Regards,

Qi

 

1. In Fig 1, there is an element called the Core Router. D= oes it mean MAP BR? I think the terms should be consistent. 

2. Currently, there is no DMR in MAP-E. The IPv6 address o= f the BR could be provisioned by the DS-Lite AFTR Name option. But the DMR = is still in use in MAP-T. IMO, this is an issue. But maybe the WG could give some guidance on handling this. <= /p>

3. Section 4.2.2

This part talks about sub-domain, which is a term that is = not defined in the MAP draft. I think there should be some text about the&n= bsp;what a 'sub-domain' is and how to differentiate 'sub-domain' from a MAP domain.

4. Section 4.2.5, para 3:

It is the wg consensus that the non-contiguous port set ha= s nothing to do with 'better security'. I recommend text about this be remo= ved.

5. Section 4.3, page 14:

   'as long as it is up and ready to take o= ver the virtual IPv6 address,

   quick failover can be achieved.'

Does the term 'virtual IPv6 address' stand for anycast IPv= 6 address, or something else?

6. Section 4.3, page 14:

  'Therefore, when using anycast addresses, it i= s RECOMMENDED that they
  be only used as destination address, and never as source addresses.<= br>   BRs SHOULD be configured to accept traffic sent to the anycast<= /o:p>

   address, but use an unicast address as source= .'

 

The packets from the BR to the CE is :

Src: BR's unicast addr, Dest: CE's unicast addr=

But what should be the destination address of the packets = from CE to BR after the CE receives the responses sent from/via the BR? The= BR's unicast addr, or the anycast addr? IMO, there should be some text like 'The CE SHOULD always use the anycast address of the BR = if there is one when sending packets to the BR.'  But there is another= issue (maybe minor): how can the CE determine which is the anycast address= ?

 

 

Some Nits:

1. There are some acronyms in the draft, which are better = to be expanded when first used.

2. The para below Fig 2: 

   For model A/B, one CE

   only need (needs) to correspond to a BR, whil= e in model C one CE have (has) to

   correspond with multiple BRs.  Figure 3 = illustrate (illustrates) a typical case,

   where the home network have (has) multiple co= nnections to multiple

   providers or multiple logical connections to = the same provider.

3. Section 4.2, 1st para:

    However, all CEs within the sub-domain = will have the same BMR. in which the BMR of all CEs is the same.<= /o:p>

    =3D> However, all CEs within th= e sub-domain will have the same BMR.

4. Section 4.2.3.2, 1st para:

   Assigning all BMRs in MAP domain to each CE a= s FMRs, Mesh

   communications can be achieved among all CEs.=

   =3D>   By assigning all BMR= s in a MAP domain to each CE as the FMR, Mesh

   communications can be achieved among all CEs.=

5. Section 4.2.6, para 3:

   For the ISP who have number=

   of scattered IPv4 address prefixes, in order = to reduce the FMRs,

   according to needs of ports they can divide d= ifferent class.

  =3D> have -> has, reduce the FMRs -> = reduce the number of FMRs, class -> classes

6. Section 4.2.7, 3. PMTU and fragmentation, para 2

     cannot to -> cannot do

7. Section 4.3, para 2

  the path from the CE to an IPv4 peer via the B= R should be close
  to the one that would be taken if the CE had native IPv4 connec= tivity.

  =3D>   the path from the CE = to an IPv4 peer via the BR should be closer

  than that would be taken if the CE had native IPv4&= nbsp;connectivity.

8. Section 6.2.2, para 1

When a network evolve (evolves) to a post-IPv6 era. (,) It= might

   be good for ISP to consider implement enforce= ments rules to help IPv6

   migration.

   =3D> When a network evolves to a post= -IPv6 era, it might

   be good for ISPs to consider to implement enf= orcement rules to help IPv6

   migration.

--_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAExmbrcdx01ciscoc_-- From sunqi.csnet.thu@gmail.com Sun Jul 14 18:19:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF87A21F9A38 for ; Sun, 14 Jul 2013 18:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 qO8Z+LmE-lRl for ; Sun, 14 Jul 2013 18:18:59 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 77F6C21F9A37 for ; Sun, 14 Jul 2013 18:18:59 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so10707513pbb.6 for ; Sun, 14 Jul 2013 18:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=3SBtGzKdy7CAmj1mkEFwaWKNoEQlf339L5fXc136s+c=; b=hhjyLdBsUS/AlV51d7SNCsCGgBTynkO/iqd1SM2a0zWXTSOFAr3CoGG/6ydFpvYFbF bAVDGygqADmWH3mIjipk12UzKszJkJaIWRk1hfzN1migGJ+zonkWovlL/qs4ZxcG7uB3 484k2DCS3mMUXv2o+JswWmXu2G2Iu7sHiIfvqk9KDvjhBx0mWrcHtnibz0t3BeHl4aqG x1nFgIcetGLQyMgbue1+j3d+3oBdFyfDwiJnkcV9NIG1ChvsgDG5NZw4rMoHED+YHSUZ DNPmC7aWNBsMerMMM/fPhV/Vzekjqj38UQD2ZWX6RSU07vuRdOJZyh3W7vlRmzRPNoW2 Zz4g== X-Received: by 10.68.203.137 with SMTP id kq9mr51060164pbc.190.1373851138191; Sun, 14 Jul 2013 18:18:58 -0700 (PDT) Received: from [192.168.0.115] ([59.64.255.202]) by mx.google.com with ESMTPSA id p2sm61181069pag.22.2013.07.14.18.18.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 18:18:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-102-406936021 From: Qi Sun In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAE@xmb-rcd-x01.cisco.com> Date: Mon, 15 Jul 2013 09:18:47 +0800 Message-Id: <537F548C-69A1-41EB-B4A2-7BBC80220228@gmail.com> References: <5193CFBB.8030900@gmail.com> <117DE5F7-3A58-44CD-8E22-11F6286DBDB3@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAE@xmb-rcd-x01.cisco.com> To: Roberta Maglione (robmgl) X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-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, 15 Jul 2013 01:19:01 -0000 --Apple-Mail-102-406936021 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Roberta, > The DS-Lite ATFR Name option defined in RFC 6334 is used to carry a = fully qualified domain name of the AFTR not an IPv6 address. > There was a proposal and a long discussion on the dhc working group = about to be able to use the same option to provision either the name or = the address but the wg did not reach consensus on that idea. So in my = understanding you cannot carry an IPv6 address into the DS-Lite AFTR = Name option [Qi] Sorry for not expressing it correctly. My intension was that the = DS-Lite AFTR Name option could be used to tell the CE the BR's IPv6 = info. The option should be used as it is designed. I didn't try to = change that.=20 > it would sound confusing in my opinion, using a DS-Lite specific = option to provision MAP specific parameters. [Qi] In the Unified CPE draft, it using the DS-Lite AFTR Name option to = provision the IPv6 info of BR. The map dhcp draft is going to remove the = DMR option. So I think these drafts should be aligned.=20 Best Regards, Qi Sun On 2013-7-15, at =E4=B8=8A=E5=8D=887:40, Roberta Maglione (robmgl) = wrote: > Hi Qu, > A comment on point 2: > >2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR = could be > > provisioned by the DS-Lite AFTR Name option. > =20 > The DS-Lite ATFR Name option defined in RFC 6334 is used to carry a = fully qualified domain name of the AFTR not an IPv6 address. > There was a proposal and a long discussion on the dhc working group = about to be able to use the same option to provision either the name or = the address but the wg did not reach consensus on that idea. So in my = understanding you cannot carry an IPv6 address into the DS-Lite AFTR = Name option. > In addition even if you could, it would sound confusing in my opinion, = using a DS-Lite specific option to provision MAP specific parameters. > =20 > Thanks > Regards > Roberta > =20 > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Qi Sun > Sent: Saturday, July 13, 2013 12:39 PM > To: Softwires > Subject: Re: [Softwires] Comments on = draft-ietf-softwire-map-deployment-01 > =20 > Dear wg,=20 > =20 > I've reviewed the draft and have some comments in addition to Tom's. = May the comments make the draft better.=20 > Please correct me if there is any mistake. > =20 > Best Regards, > Qi > =20 > 1. In Fig 1, there is an element called the Core Router. Does it mean = MAP BR? I think the terms should be consistent.=20 > 2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR = could be provisioned by the DS-Lite AFTR Name option. But the DMR is = still in use in MAP-T. IMO, this is an issue. But maybe the WG could = give some guidance on handling this.=20 > 3. Section 4.2.2 > This part talks about sub-domain, which is a term that is not defined = in the MAP draft. I think there should be some text about the what a = 'sub-domain' is and how to differentiate 'sub-domain' from a MAP domain. > 4. Section 4.2.5, para 3: > It is the wg consensus that the non-contiguous port set has nothing to = do with 'better security'. I recommend text about this be removed. > 5. Section 4.3, page 14: > 'as long as it is up and ready to take over the virtual IPv6 = address, > quick failover can be achieved.' > Does the term 'virtual IPv6 address' stand for anycast IPv6 address, = or something else? > 6. Section 4.3, page 14: > 'Therefore, when using anycast addresses, it is RECOMMENDED that = they > be only used as destination address, and never as source addresses. > BRs SHOULD be configured to accept traffic sent to the anycast > address, but use an unicast address as source.' > =20 > The packets from the BR to the CE is : > Src: BR's unicast addr, Dest: CE's unicast addr > But what should be the destination address of the packets from CE to = BR after the CE receives the responses sent from/via the BR? The BR's = unicast addr, or the anycast addr? IMO, there should be some text like = 'The CE SHOULD always use the anycast address of the BR if there is one = when sending packets to the BR.' But there is another issue (maybe = minor): how can the CE determine which is the anycast address? > =20 > =20 > Some Nits: > 1. There are some acronyms in the draft, which are better to be = expanded when first used. > 2. The para below Fig 2:=20 > For model A/B, one CE > only need (needs) to correspond to a BR, while in model C one CE = have (has) to > correspond with multiple BRs. Figure 3 illustrate (illustrates) a = typical case, > where the home network have (has) multiple connections to multiple > providers or multiple logical connections to the same provider. > 3. Section 4.2, 1st para: > However, all CEs within the sub-domain will have the same BMR. in = which the BMR of all CEs is the same. > =3D> However, all CEs within the sub-domain will have the same = BMR. > 4. Section 4.2.3.2, 1st para: > Assigning all BMRs in MAP domain to each CE as FMRs, Mesh > communications can be achieved among all CEs. > =3D> By assigning all BMRs in a MAP domain to each CE as the FMR, = Mesh > communications can be achieved among all CEs. > 5. Section 4.2.6, para 3: > For the ISP who have number > of scattered IPv4 address prefixes, in order to reduce the FMRs, > according to needs of ports they can divide different class. > =3D> have -> has, reduce the FMRs -> reduce the number of FMRs, = class -> classes > 6. Section 4.2.7, 3. PMTU and fragmentation, para 2 > cannot to -> cannot do > 7. Section 4.3, para 2 > the path from the CE to an IPv4 peer via the BR should be close > to the one that would be taken if the CE had native IPv4 = connectivity. > =3D> the path from the CE to an IPv4 peer via the BR should be = closer > than that would be taken if the CE had native IPv4 connectivity. > 8. Section 6.2.2, para 1 > When a network evolve (evolves) to a post-IPv6 era. (,) It might > be good for ISP to consider implement enforcements rules to help = IPv6 > migration. > =3D> When a network evolves to a post-IPv6 era, it might > be good for ISPs to consider to implement enforcement rules to help = IPv6 > migration. --Apple-Mail-102-406936021 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear = Roberta,

The = DS-Lite ATFR Name option defined in RFC 6334 is used to carry a fully = qualified domain name of the AFTR not an IPv6 = address.
There = was a proposal and a long discussion on the dhc working group about to = be able to use the same option to provision either  the name or the = address but the wg did not reach consensus on that idea.  So in my = understanding you cannot carry an IPv6 address into the DS-Lite AFTR = Name = option

[Qi] = Sorry for not expressing it correctly. My intension was that the DS-Lite = AFTR Name option could be used to tell the CE the BR's IPv6 info. The = option should be used as it is designed. I didn't try to change = that. 

it = would sound confusing in my opinion, using a DS-Lite specific option to = provision MAP specific = parameters.

[Qi= ] In the Unified CPE draft, it using the  DS-Lite AFTR Name = option to provision the IPv6 info of BR. The map dhcp draft is going to = remove the DMR option. So I think these drafts should be = aligned. 

Best Regards,
Qi = Sun

On 2013-7-15, at =E4=B8=8A=E5=8D=887:40, Roberta Maglione = (robmgl) wrote:

Hi = Qu,
A comment = on point 2:
2. = Currently, there is no DMR in MAP-E. The IPv6 address of the BR could = be
> provisioned by the DS-Lite AFTR Name = option.
The = DS-Lite ATFR Name option defined in RFC 6334 is used to carry a fully = qualified domain name of the AFTR not an IPv6 = address.
There = was a proposal and a long discussion on the dhc working group about to = be able to use the same option to provision either  the name or the = address but the wg did not reach consensus on that idea.  So in my = understanding you cannot carry an IPv6 address into the DS-Lite AFTR = Name option.
In = addition even if you could, it would sound confusing in my opinion, = using a DS-Lite specific option to provision MAP specific = parameters.
From: softwires-bounces@ietf.org [mailto:softwires-bounces@iet= f.org] On Behalf = Of Qi = Sun
Sent: Saturday, July 13, 2013 = 12:39 PM
To: Softwires
Subject:<= span class=3D"Apple-converted-space"> Re: [Softwires] = Comments on = draft-ietf-softwire-map-deployment-01
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: = 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New = Roman', serif; "> 
Dear wg, 
I've reviewed the draft and = have some comments in addition to Tom's.  May the comments make the = draft better. 
Please correct = me if there is any mistake.
Best = Regards,
 
1. In Fig 1, = there is an element called the Core Router. Does it mean MAP BR? I think = the terms should be = consistent. 
2. Currently, = there is no DMR in MAP-E. The IPv6 address of the BR could be = provisioned by the DS-Lite AFTR Name option. But the DMR is still in use = in MAP-T. IMO, this is an issue. But maybe the WG could give some = guidance on handling this. 
3. Section = 4.2.2
This part talks about sub-domain, which is a term = that is not defined in the MAP draft. I think there should be some text = about the what a 'sub-domain' is and how to differentiate = 'sub-domain' from a MAP domain.
4. Section = 4.2.5, para 3:
It is the wg consensus that = the non-contiguous port set has nothing to do with 'better security'. I = recommend text about this be = removed.
5. Section 4.3, page = 14:
   'as long as it is up and ready = to take over the virtual IPv6 = address,
   quick failover = can be achieved.'
Does the term = 'virtual IPv6 address' stand for anycast IPv6 address, or something = else?
6. Section 4.3, page = 14:
  'Therefore, when using anycast = addresses, it is RECOMMENDED that they
  be only used as = destination address, and never as source addresses.
  BRs SHOULD = be configured to accept traffic sent to the = anycast
   address, but use an unicast address = as source.'
The packets from the BR to = the CE is :
Src: BR's unicast addr, Dest: = CE's unicast addr
But what = should be the destination address of the packets from CE to BR after the = CE receives the responses sent from/via the BR? The BR's unicast addr, = or the anycast addr? IMO, there should be some text like 'The CE SHOULD = always use the anycast address of the BR if there is one when sending = packets to the BR.'  But there is another issue (maybe minor): how = can the CE determine which is the anycast = address?
Some = Nits:
1. There are some acronyms in the draft, which are = better to be expanded when first = used.
2. The para below Fig = 2: 
   For model A/B, = one CE
   only need (needs) to correspond to a = BR, while in model C one CE have (has) = to
   correspond with multiple BRs.  = Figure 3 illustrate (illustrates) a typical = case,
   where the home network have (has) = multiple connections to multiple
   = providers or multiple logical connections to the same = provider.
3. Section 4.2, 1st = para:
    However, all CEs within the = sub-domain will have the same BMR. in which the BMR of all CEs is = the same.
   =  =3D> However, all CEs within the sub-domain will have the = same BMR.
4. Section 4.2.3.2, 1st = para:
   Assigning all BMRs in MAP domain to = each CE as FMRs, Mesh
   = communications can be achieved among all = CEs.
   =3D>   By assigning = all BMRs in a MAP domain to each CE as the FMR, = Mesh
   communications can be achieved among = all CEs.
5. Section 4.2.6, para = 3:
   For the ISP who have = number
   of scattered IPv4 address prefixes, = in order to reduce the FMRs,
   = according to needs of ports they can divide different = class.
  =3D> have -> has, reduce the = FMRs -> reduce the number of FMRs, class -> = classes
6. Section 4.2.7, 3. PMTU and fragmentation, para = 2
     cannot to -> cannot = do
7. Section 4.3, para = 2
  the path from the CE to an IPv4 peer = via the BR should be close
  to the one that would be taken if = the CE had native = IPv4 connectivity.
  than = that would be taken if the CE had native = IPv4 connectivity.
8. Section = 6.2.2, para 1
When a network evolve = (evolves) to a post-IPv6 era. (,) It = might
   be good for ISP to consider implement = enforcements rules to help IPv6
   = migration.
   =3D> When = a network evolves to a post-IPv6 era, it = might
   be good for ISPs to consider to = implement enforcement rules to help = IPv6
   = migration.

= --Apple-Mail-102-406936021-- From bingxuere@gmail.com Sun Jul 14 18:21:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11221F862B for ; Sun, 14 Jul 2013 18:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Ms3i-3NTPFo8 for ; Sun, 14 Jul 2013 18:21:36 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 394F421F8475 for ; Sun, 14 Jul 2013 18:21:36 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gf11so8851548vcb.39 for ; Sun, 14 Jul 2013 18:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Inv046Ub/+8PG9BsLGHwLQVXikA4yezV2iOGvE/M7f8=; b=GQR8TP9jl2Lk8qOw6cVucLeV37MYoF/UYfXwp682twpSsRdC52BUeyCi3GGma/iy/F zT7Hc7MmosdY1+MQVaBHIsdwhJaoJ5jsJaBrahAbNeoIvEaZL3Yvu0uYR2elK53ZdRsj bNyp71s4DNPbCnoik840J+H+WnUj9uJmOgqJmUsyy8eSX/cKD3/cL5ateTkUNVDposaU btGXh7fe08U2XqYzOYc/O8FdRYe39uiiEkRvucmUx4UgADLdNHfz6LHozDpGfTW05/WN lZ90d2ppiJHyNJq4hzn5LmD6QJxOAvIi99DJc0IBTBP/nf3JMornRmLWWLpPtAll3vgx AmKA== X-Received: by 10.58.127.202 with SMTP id ni10mr27142701veb.27.1373851295629; Sun, 14 Jul 2013 18:21:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.210.202 with HTTP; Sun, 14 Jul 2013 18:20:55 -0700 (PDT) In-Reply-To: <117DE5F7-3A58-44CD-8E22-11F6286DBDB3@gmail.com> References: <5193CFBB.8030900@gmail.com> <117DE5F7-3A58-44CD-8E22-11F6286DBDB3@gmail.com> From: Qiong Date: Mon, 15 Jul 2013 09:20:55 +0800 Message-ID: To: Qi Sun Content-Type: multipart/alternative; boundary=047d7b5d870f73491004e182aecd Cc: Softwires Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-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, 15 Jul 2013 01:21:37 -0000 --047d7b5d870f73491004e182aecd Content-Type: text/plain; charset=UTF-8 Dear Qi, Thanks for your detailed review. I have incorporated most of your comments into the next version and will be submitted soon. Some comments are inline. On Sun, Jul 14, 2013 at 12:39 AM, Qi Sun wrote: > > 2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR could > be provisioned by the DS-Lite AFTR Name option. But the DMR is still in use > in MAP-T. IMO, this is an issue. But maybe the WG could give some guidance > on handling this. > [Qiong] This is also the question for the WG. I'm wondering what's the reason of this change in MAP-E. Is this the final decision that MAP-E and MAP-T will deal with it differently ? > > 5. Section 4.3, page 14: > 'as long as it is up and ready to take over the virtual IPv6 address, > quick failover can be achieved.' > Does the term 'virtual IPv6 address' stand for anycast IPv6 address, or > something else? > [Qiong] This is the term in VRRP. It is not the anycast address. > 6. Section 4.3, page 14: > 'Therefore, when using anycast addresses, it is RECOMMENDED that they > be only used as destination address, and never as source addresses. > BRs SHOULD be configured to accept traffic sent to the anycast > address, but use an unicast address as source.' > > The packets from the BR to the CE is : > Src: BR's unicast addr, Dest: CE's unicast addr > But what should be the destination address of the packets from CE to BR > after the CE receives the responses sent from/via the BR? The BR's unicast > addr, or the anycast addr? IMO, there should be some text like 'The CE > SHOULD always use the anycast address of the BR if there is one when > sending packets to the BR.' But there is another issue (maybe minor): how > can the CE determine which is the anycast address? > [Qiong] I agree this recommendation has problems as you state. I would like to change the recommendation to increase the MTU so that no fragmentation will occur. Is this ok ? For other comments, I agree with you and I have updated in my text. Thanks! Best wishes Qiong > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --047d7b5d870f73491004e182aecd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Qi,

Thanks for your detailed= review. I have incorporated most of your comments into the next version an= d will be submitted soon.

Some comment= s are inline.


On Sun, Jul 1= 4, 2013 at 12:39 AM, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:

2. Currently, there is no DMR in MAP-E. The IPv6 address of the BR could be= provisioned by the DS-Lite AFTR Name option. But the DMR is still in use i= n MAP-T. IMO, this is an issue. But maybe the WG could give some guidance o= n handling this.=C2=A0
[Qiong] This is also the question for the WG.= I'm wondering what's the reason of this change in MAP-E. Is this t= he final decision that MAP-E and MAP-T will deal with it differently ?=C2= =A0

5. Section 4.3, page 14:
=C2=A0=C2=A0 'as=C2=A0long as it is up a= nd ready to take over the virtual IPv6 address,
=C2=A0=C2=A0 quick failover can be achieved.'
Does the term 'virtual IPv6 addr= ess' stand for anycast IPv6 address, or something else?
[Qiong] This is the term in VRRP. It is not the anycast= address.
=C2=A0
6. Section 4.3, page 14:
=C2=A0=C2=A0= 'Therefore, when using anycast addresses, it is RECOMMENDED that they=C2=A0 be only used as destination address, and never as source addresses= .
=C2=A0 BRs SHOULD be configured to accept traffic sent to the anycast<= br>
=C2=A0=C2=A0 address, but use an uni= cast address as source.'

=
The packets from the BR to the CE is= :
Src: BR's unicast addr, Dest: CE's unicast addr
But what should be the destination address of the packet= s from CE to BR after the CE receives the responses sent from/via the BR? T= he BR's unicast addr, or the anycast addr? IMO, there should be some te= xt like 'The CE SHOULD always use the anycast address of the BR if ther= e is one when sending packets to the BR.' =C2=A0But there is another is= sue (maybe minor): how can the CE determine which is the anycast address?
[Qiong] I agree this recommendation has probl= ems as you state. I would like to change the=C2=A0 recommendation=C2=A0to increase the MTU so that no fragmentation will occur= . Is this ok ?=C2=A0

For other comments, I a= gree with you and I have updated in my text.

Thanks!

Best wishes
Qi= ong=C2=A0
=

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




--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--047d7b5d870f73491004e182aecd-- From bingxuere@gmail.com Sun Jul 14 18:28:24 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E503E21F943C for ; Sun, 14 Jul 2013 18:28:24 -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, HTML_MESSAGE=0.001, 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 YURPzZ0twyKN for ; Sun, 14 Jul 2013 18:28:24 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 63E5921F93F3 for ; Sun, 14 Jul 2013 18:28:24 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id ib11so8985913vcb.17 for ; Sun, 14 Jul 2013 18:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6P3OPpMrMBzv0uFWRNsIWjyyZoiz0Rl6lBEblvper1s=; b=DPyYGzvLTLSsq6ebJTveBFcx7IeBHkM4uQ6WRgmAqK/VGREEU/tO0/WALm2Zdn3B90 rmbUI+Aa3m0rczQQAF7rXulZ1VJwOfmAxE9dEfo+s/RY/h9x+snJHogHpUzyM7qUuZl2 1jcmL6muVQgtHisKr1rDy9ixg9FnVoyhBI9u4i7ocdlTsAepF8+HACR/YXejEGYMXxxr 8nxcHtUF+mAmT33M0oij92ZsopxixVxi98WCLgeGTs5kFuyDaDRmo7V4LxrRHULq8c/c KYJP2k1ayLWswCrCu8yKRl1dC5ZWzXCGbiRxzjkZVq5Fmw4mDPKmaZoD645224wfWNIi 9WiQ== X-Received: by 10.220.173.72 with SMTP id o8mr27452886vcz.75.1373851703809; Sun, 14 Jul 2013 18:28:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.210.202 with HTTP; Sun, 14 Jul 2013 18:27:43 -0700 (PDT) In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAE@xmb-rcd-x01.cisco.com> References: <5193CFBB.8030900@gmail.com> <117DE5F7-3A58-44CD-8E22-11F6286DBDB3@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAE@xmb-rcd-x01.cisco.com> From: Qiong Date: Mon, 15 Jul 2013 09:27:43 +0800 Message-ID: To: "Roberta Maglione (robmgl)" Content-Type: multipart/alternative; boundary=089e0149c390c79d3a04e182c616 Cc: Softwires Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-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, 15 Jul 2013 01:28:25 -0000 --089e0149c390c79d3a04e182c616 Content-Type: text/plain; charset=UTF-8 Hi Roberta, On Mon, Jul 15, 2013 at 7:40 AM, Roberta Maglione (robmgl) wrote: > > In addition even if you could, it would sound confusing in my opinion, > using a DS-Lite specific option to provision MAP specific parameters. > [Qiong] I agree with you. I think using DMR is more clear. Best wishes Qiong --089e0149c390c79d3a04e182c616 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Roberta,


On Mon, Jul 15, 2013 at 7:40 AM, Roberta Maglione (robmgl)= <robmgl@cisco.com> wrote:

In addition even if you c= ould, it would sound confusing in my opinion, using a DS-Lite specific opti= on to provision MAP specific parameters.

=C2=A0
[Qiong] I agree with y= ou. I think using DMR is more clear.

B= est wishes
Qiong=C2=A0
--089e0149c390c79d3a04e182c616-- From internet-drafts@ietf.org Mon Jul 15 03:19:56 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016CF11E80D3; Mon, 15 Jul 2013 03:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 zvf+yA9vXcCu; Mon, 15 Jul 2013 03:19:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BB011E80A2; Mon, 15 Jul 2013 03:19:55 -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.51.p2 Message-ID: <20130715101955.15853.48949.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 03:19:55 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 10:19:56 -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 : Softwire Mesh Multicast Author(s) : Mingwei Xu Yong Cui Jianping Wu Shu Yang Chris Metz Greg Shepherd Filename : draft-ietf-softwire-mesh-multicast-05.txt Pages : 21 Date : 2013-07-15 Abstract: The Internet needs to support IPv4 and IPv6 packets. Both address families and their attendant protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwire Mesh is a solution to E-IP unicast and multicast support across an I-IP backbone. This document describes the mechanisms for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwire mesh. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-mesh-multicast-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From robmgl@cisco.com Mon Jul 15 05:53:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2691A11E80F1 for ; Mon, 15 Jul 2013 05:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.32 X-Spam-Level: X-Spam-Status: No, score=-10.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6P6xBF4rji-9 for ; Mon, 15 Jul 2013 05:53:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0142521F8A67 for ; Mon, 15 Jul 2013 05:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18446; q=dns/txt; s=iport; t=1373892796; x=1375102396; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/TsWO6nXpzr6lJ+e6c96EcZfRo/xGHqTNDBEZKyOuDk=; b=Yud7QBVur45dl3ZLmKWzJPEBYtEBcL8XbrOCdkVJx2KN8SvZKk1LL5Yx VmT35mFyFT3l9MoAIlQjVGahVzj5Atll3vpFPPC2kBDUV22Iy1ahfPZyB JrcTZWGfaFBkkmGNjz2kNgPSyzEetufrPyTPdGgTz7s0oBQsGIlcHSsnA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAA/w41GtJXHB/2dsb2JhbABagkJENE+DBr5MF3kWdIIjAQEBAwEjCkwFCwIBBgIRBAEBCx0DAgICHxEUCQgCBA4FCId2AwkGiQabQIgdDYhejHqCOTEGAYJYM20DlXOOEIUmgxKCKA X-IronPort-AV: E=Sophos;i="4.89,668,1367971200"; d="scan'208,217";a="234721749" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 15 Jul 2013 12:53:10 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6FCrA1n015832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jul 2013 12:53:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 07:53:10 -0500 From: "Roberta Maglione (robmgl)" To: Qi Sun Thread-Topic: [Softwires] Comments on draft-ietf-softwire-map-deployment-01 Thread-Index: AQHOf+eKne6Cc9hXlESpUEoTvself5lk1HlwgAByDICAAG3qYA== Date: Mon, 15 Jul 2013 12:53:09 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D27726E@xmb-rcd-x01.cisco.com> References: <5193CFBB.8030900@gmail.com> <117DE5F7-3A58-44CD-8E22-11F6286DBDB3@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D276EAE@xmb-rcd-x01.cisco.com> <537F548C-69A1-41EB-B4A2-7BBC80220228@gmail.com> In-Reply-To: <537F548C-69A1-41EB-B4A2-7BBC80220228@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.8.120] Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D27726Exmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-deployment-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, 15 Jul 2013 12:53:22 -0000 --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D27726Exmbrcdx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUWksDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9ucy4NCkkgc3RpbGwgdGhpbmsgdGhh dCBoYXZpbmcgYSBETVIgb3B0aW9uIGZvciBNQVAgd291bGQgbW9yZSBjbGVhciwgYnV0IGlmIHRo ZSBXRyBoYXMgZGVjaWRlZCB0byByZS11c2UgdGhlIERTLUxpdGUgQUZUUiBOYW1lIG9wdGlvbiBJ 4oCZbSBvayB3aXRoIHRoYXQgYXMgbG9uZyBhcyBpdCBpcyB1c2VkIGFzIGRlc2lnbmVkLg0KUmVn YXJkcw0KUm9iZXJ0YQ0KDQpGcm9tOiBRaSBTdW4gW21haWx0bzpzdW5xaS5jc25ldC50aHVAZ21h aWwuY29tXQ0KU2VudDogU3VuZGF5LCBKdWx5IDE0LCAyMDEzIDk6MTkgUE0NClRvOiBSb2JlcnRh IE1hZ2xpb25lIChyb2JtZ2wpDQpDYzogU29mdHdpcmVzDQpTdWJqZWN0OiBSZTogW1NvZnR3aXJl c10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtZGVwbG95bWVudC0wMQ0KDQoN CkRlYXIgUm9iZXJ0YSwNCg0KVGhlIERTLUxpdGUgQVRGUiBOYW1lIG9wdGlvbiBkZWZpbmVkIGlu IFJGQyA2MzM0IGlzIHVzZWQgdG8gY2FycnkgYSBmdWxseSBxdWFsaWZpZWQgZG9tYWluIG5hbWUg b2YgdGhlIEFGVFIgbm90IGFuIElQdjYgYWRkcmVzcy4NClRoZXJlIHdhcyBhIHByb3Bvc2FsIGFu ZCBhIGxvbmcgZGlzY3Vzc2lvbiBvbiB0aGUgZGhjIHdvcmtpbmcgZ3JvdXAgYWJvdXQgdG8gYmUg YWJsZSB0byB1c2UgdGhlIHNhbWUgb3B0aW9uIHRvIHByb3Zpc2lvbiBlaXRoZXIgIHRoZSBuYW1l IG9yIHRoZSBhZGRyZXNzIGJ1dCB0aGUgd2cgZGlkIG5vdCByZWFjaCBjb25zZW5zdXMgb24gdGhh dCBpZGVhLiAgU28gaW4gbXkgdW5kZXJzdGFuZGluZyB5b3UgY2Fubm90IGNhcnJ5IGFuIElQdjYg YWRkcmVzcyBpbnRvIHRoZSBEUy1MaXRlIEFGVFIgTmFtZSBvcHRpb24NCg0KW1FpXSBTb3JyeSBm b3Igbm90IGV4cHJlc3NpbmcgaXQgY29ycmVjdGx5LiBNeSBpbnRlbnNpb24gd2FzIHRoYXQgdGhl IERTLUxpdGUgQUZUUiBOYW1lIG9wdGlvbiBjb3VsZCBiZSB1c2VkIHRvIHRlbGwgdGhlIENFIHRo ZSBCUidzIElQdjYgaW5mby4gVGhlIG9wdGlvbiBzaG91bGQgYmUgdXNlZCBhcyBpdCBpcyBkZXNp Z25lZC4gSSBkaWRuJ3QgdHJ5IHRvIGNoYW5nZSB0aGF0Lg0KDQppdCB3b3VsZCBzb3VuZCBjb25m dXNpbmcgaW4gbXkgb3BpbmlvbiwgdXNpbmcgYSBEUy1MaXRlIHNwZWNpZmljIG9wdGlvbiB0byBw cm92aXNpb24gTUFQIHNwZWNpZmljIHBhcmFtZXRlcnMuDQoNCltRaV0gSW4gdGhlIFVuaWZpZWQg Q1BFIGRyYWZ0LCBpdCB1c2luZyB0aGUgIERTLUxpdGUgQUZUUiBOYW1lIG9wdGlvbiB0byBwcm92 aXNpb24gdGhlIElQdjYgaW5mbyBvZiBCUi4gVGhlIG1hcCBkaGNwIGRyYWZ0IGlzIGdvaW5nIHRv IHJlbW92ZSB0aGUgRE1SIG9wdGlvbi4gU28gSSB0aGluayB0aGVzZSBkcmFmdHMgc2hvdWxkIGJl IGFsaWduZWQuDQoNCkJlc3QgUmVnYXJkcywNClFpIFN1bg0KDQpPbiAyMDEzLTctMTUsIGF0IOS4 iuWNiDc6NDAsIFJvYmVydGEgTWFnbGlvbmUgKHJvYm1nbCkgd3JvdGU6DQoNCg0KSGkgUXUsDQpB IGNvbW1lbnQgb24gcG9pbnQgMjoNCj4yLiBDdXJyZW50bHksIHRoZXJlIGlzIG5vIERNUiBpbiBN QVAtRS4gVGhlIElQdjYgYWRkcmVzcyBvZiB0aGUgQlIgY291bGQgYmUNCj4gcHJvdmlzaW9uZWQg YnkgdGhlIERTLUxpdGUgQUZUUiBOYW1lIG9wdGlvbi4NCg0KVGhlIERTLUxpdGUgQVRGUiBOYW1l IG9wdGlvbiBkZWZpbmVkIGluIFJGQyA2MzM0IGlzIHVzZWQgdG8gY2FycnkgYSBmdWxseSBxdWFs aWZpZWQgZG9tYWluIG5hbWUgb2YgdGhlIEFGVFIgbm90IGFuIElQdjYgYWRkcmVzcy4NClRoZXJl IHdhcyBhIHByb3Bvc2FsIGFuZCBhIGxvbmcgZGlzY3Vzc2lvbiBvbiB0aGUgZGhjIHdvcmtpbmcg Z3JvdXAgYWJvdXQgdG8gYmUgYWJsZSB0byB1c2UgdGhlIHNhbWUgb3B0aW9uIHRvIHByb3Zpc2lv biBlaXRoZXIgIHRoZSBuYW1lIG9yIHRoZSBhZGRyZXNzIGJ1dCB0aGUgd2cgZGlkIG5vdCByZWFj aCBjb25zZW5zdXMgb24gdGhhdCBpZGVhLiAgU28gaW4gbXkgdW5kZXJzdGFuZGluZyB5b3UgY2Fu bm90IGNhcnJ5IGFuIElQdjYgYWRkcmVzcyBpbnRvIHRoZSBEUy1MaXRlIEFGVFIgTmFtZSBvcHRp b24uDQpJbiBhZGRpdGlvbiBldmVuIGlmIHlvdSBjb3VsZCwgaXQgd291bGQgc291bmQgY29uZnVz aW5nIGluIG15IG9waW5pb24sIHVzaW5nIGEgRFMtTGl0ZSBzcGVjaWZpYyBvcHRpb24gdG8gcHJv dmlzaW9uIE1BUCBzcGVjaWZpYyBwYXJhbWV0ZXJzLg0KDQpUaGFua3MNClJlZ2FyZHMNClJvYmVy dGENCg0K --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D27726Exmbrcdx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly85NDgvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5 IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJ cGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVpdGkgU0MiOw0KCXBhbm9zZS0xOjAgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBNaW5jaG8iOw0K CXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXN0 eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxl LWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQi Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFFpLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9ucy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBzdGlsbCB0aGluayB0aGF0IGhhdmluZyBhIERNUiBvcHRp b24gZm9yIE1BUCB3b3VsZCBtb3JlIGNsZWFyLCBidXQgaWYgdGhlIFdHIGhhcyBkZWNpZGVkIHRv IHJlLXVzZSB0aGUgRFMtTGl0ZSBBRlRSIE5hbWUgb3B0aW9uIEnigJltIG9rIHdpdGggdGhhdCBh cyBsb25nIGFzDQogaXQgaXMgdXNlZCBhcyBkZXNpZ25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb2JlcnRhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gUWkgU3VuIFttYWlsdG86c3VucWkuY3NuZXQudGh1QGdtYWlsLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEp1bHkgMTQsIDIwMTMgOToxOSBQTTxicj4N CjxiPlRvOjwvYj4gUm9iZXJ0YSBNYWdsaW9uZSAocm9ibWdsKTxicj4NCjxiPkNjOjwvYj4gU29m dHdpcmVzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbU29mdHdpcmVzXSBDb21tZW50cyBvbiBk cmFmdC1pZXRmLXNvZnR3aXJlLW1hcC1kZXBsb3ltZW50LTAxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlaXRpIFNDJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EZWFyIFJvYmVydGEsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVpdGkgU0MmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIERTLUxpdGUgQVRGUiBOYW1l IG9wdGlvbiBkZWZpbmVkIGluIFJGQyA2MzM0IGlzIHVzZWQgdG8gY2FycnkgYSBmdWxseSBxdWFs aWZpZWQgZG9tYWluIG5hbWUgb2YgdGhlIEFGVFIgbm90IGFuIElQdjYgYWRkcmVzcy48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhlcmUgd2FzIGEgcHJvcG9zYWwgYW5kIGEgbG9uZyBkaXNjdXNzaW9u IG9uIHRoZSBkaGMgd29ya2luZyBncm91cCBhYm91dCB0byBiZSBhYmxlIHRvIHVzZSB0aGUgc2Ft ZSBvcHRpb24gdG8gcHJvdmlzaW9uIGVpdGhlciAmbmJzcDt0aGUgbmFtZSBvciB0aGUgYWRkcmVz cyBidXQNCiB0aGUgd2cgZGlkIG5vdCByZWFjaCBjb25zZW5zdXMgb24gdGhhdCBpZGVhLiAmbmJz cDtTbyBpbiBteSB1bmRlcnN0YW5kaW5nIHlvdSBjYW5ub3QgY2FycnkgYW4gSVB2NiBhZGRyZXNz IGludG8gdGhlIERTLUxpdGUgQUZUUiBOYW1lIG9wdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWl0aSBTQyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVpdGkgU0MmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltR aV0gU29ycnkgZm9yIG5vdCBleHByZXNzaW5nIGl0IGNvcnJlY3RseS4gTXkgaW50ZW5zaW9uIHdh cyB0aGF0IHRoZSBEUy1MaXRlIEFGVFIgTmFtZSBvcHRpb24gY291bGQgYmUgdXNlZCB0byB0ZWxs IHRoZSBDRSB0aGUgQlIncyBJUHY2IGluZm8uIFRoZSBvcHRpb24gc2hvdWxkDQogYmUgdXNlZCBh cyBpdCBpcyBkZXNpZ25lZC4gSSBkaWRuJ3QgdHJ5IHRvIGNoYW5nZSB0aGF0LiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlaXRpIFNDJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPml0IHdvdWxkIHNv dW5kIGNvbmZ1c2luZyBpbiBteSBvcGluaW9uLCB1c2luZyBhIERTLUxpdGUgc3BlY2lmaWMgb3B0 aW9uIHRvIHByb3Zpc2lvbiBNQVAgc3BlY2lmaWMgcGFyYW1ldGVycy48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVpdGkgU0MmcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlaXRpIFNDJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5bUWldIEluIHRoZSBVbmlmaWVkIENQRSBkcmFmdCwgaXQgdXNpbmcgdGhlJm5ic3A7Jm5i c3A7RFMtTGl0ZSBBRlRSIE5hbWUgb3B0aW9uIHRvIHByb3Zpc2lvbiB0aGUgSVB2NiBpbmZvIG9m IEJSLiBUaGUgbWFwIGRoY3AgZHJhZnQgaXMgZ29pbmcgdG8gcmVtb3ZlIHRoZSBETVIgb3B0aW9u LiBTbyBJDQogdGhpbmsgdGhlc2UgZHJhZnRzIHNob3VsZCBiZSBhbGlnbmVkLiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlaXRpIFNDJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWl0aSBTQyZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTMu NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWl0 aSBTQyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UWkgU3VuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gMjAxMy03LTE1LCBhdCA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgTWluY2hvJnF1b3Q7Ij7kuIrljYg8L3NwYW4+Nzo0MCwgUm9iZXJ0YSBNYWdsaW9uZSAo cm9ibWdsKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBR dSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QSBjb21tZW50 IG9uIHBvaW50IDI6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjIuIEN1cnJlbnRseSwgdGhlcmUgaXMgbm8gRE1SIGluIE1B UC1FLiBUaGUgSVB2NiBhZGRyZXNzIG9mIHRoZSBCUiBjb3VsZCBiZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7 IHByb3Zpc2lvbmVkIGJ5IHRoZSBEUy1MaXRlIEFGVFIgTmFtZSBvcHRpb24uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgRFMtTGl0ZSBBVEZSIE5hbWUgb3B0aW9u IGRlZmluZWQgaW4gUkZDIDYzMzQgaXMgdXNlZCB0byBjYXJyeSBhIGZ1bGx5IHF1YWxpZmllZCBk b21haW4gbmFtZSBvZiB0aGUgQUZUUiBub3QgYW4gSVB2NiBhZGRyZXNzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSB3YXMgYSBwcm9wb3NhbCBhbmQg YSBsb25nIGRpc2N1c3Npb24gb24gdGhlIGRoYyB3b3JraW5nIGdyb3VwIGFib3V0IHRvIGJlIGFi bGUgdG8gdXNlIHRoZSBzYW1lIG9wdGlvbiB0byBwcm92aXNpb24gZWl0aGVyICZuYnNwO3RoZSBu YW1lIG9yIHRoZSBhZGRyZXNzIGJ1dA0KIHRoZSB3ZyBkaWQgbm90IHJlYWNoIGNvbnNlbnN1cyBv biB0aGF0IGlkZWEuICZuYnNwO1NvIGluIG15IHVuZGVyc3RhbmRpbmcgeW91IGNhbm5vdCBjYXJy eSBhbiBJUHY2IGFkZHJlc3MgaW50byB0aGUgRFMtTGl0ZSBBRlRSIE5hbWUgb3B0aW9uLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBhZGRpdGlvbiBldmVu IGlmIHlvdSBjb3VsZCwgaXQgd291bGQgc291bmQgY29uZnVzaW5nIGluIG15IG9waW5pb24sIHVz aW5nIGEgRFMtTGl0ZSBzcGVjaWZpYyBvcHRpb24gdG8gcHJvdmlzaW9uIE1BUCBzcGVjaWZpYyBw YXJhbWV0ZXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9iZXJ0YTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D27726Exmbrcdx01ciscoc_-- From internet-drafts@ietf.org Mon Jul 15 06:16:19 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40F411E80FB; Mon, 15 Jul 2013 06:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 l8rv1iWny59b; Mon, 15 Jul 2013 06:16:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C12111E80E2; Mon, 15 Jul 2013 06:16:19 -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.51.p2 Message-ID: <20130715131619.13163.43802.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 06:16:19 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-deployment-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 13:16:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port (MAP) - Deployment Considera= tions Author(s) : Qiong Sun Maoke Chen Gang Chen Tina Tsou Simon Perreault Filename : draft-ietf-softwire-map-deployment-02.txt Pages : 31 Date : 2013-07-15 Abstract: This document describes when and how an operator uses the technique of Mapping of Address and Port (MAP) for the IPv4 residual deployment in the IPv6-dominant domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-deployment-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-deployment-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yiu_lee@cable.comcast.com Mon Jul 15 08:29:55 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C89711E8105 for ; Mon, 15 Jul 2013 08:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 ieNJnjTNbiKY for ; Mon, 15 Jul 2013 08:29:49 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2C621E808C for ; Mon, 15 Jul 2013 08:29:46 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.82515201; Mon, 15 Jul 2013 09:27:17 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.138]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Mon, 15 Jul 2013 11:29:36 -0400 From: "Lee, Yiu" To: Softwires-wg Thread-Topic: [Softwires] Changes to DHCP MAP Option draft Thread-Index: AQHOgXAcKQw+JHrTPUaTtXTczj5unA== Date: Mon, 15 Jul 2013 15:29:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.249] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3456732576_585429" MIME-Version: 1.0 Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:29:55 -0000 --B_3456732576_585429 Content-type: multipart/alternative; boundary="B_3456732572_568813" --B_3456732572_568813 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Since this is a WG draft, did the authors ask the WG to update this? When the WG accepted this draft, it was only for MAP. But seems the scope has been changed. This should start as an Individual draft. I will recommend to revert back to the last version and present this in Berlin to replace the MAP draft if the WG agrees with it. From: Wojciech Dec Date: Thursday, July 11, 2013 10:43 AM To: Qi Sun Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft Yes, there was a long thread started by Tomek. Given that the option is applicable beyond MAP a *suggestion* was to rename it. I'm personally ok either way. The "Softwire46" option is the currently proposed name. --B_3456732572_568813 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Since this is a WG draft, di= d the authors ask the WG to update this? When the WG accepted this draft, it= was only for MAP. But seems the scope has been changed. This should start a= s an Individual draft. I will recommend to revert back to the last version a= nd present this in Berlin to replace the MAP draft if the WG agrees with it.=


From: Wojciech Dec <wdec.ietf@gmail.com<= /a>>
Date: Thursday, July 11, 2= 013 10:43 AM
To: Qi Sun <sunqi.csnet.thu@gmail.com>
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] Changes to DHCP MAP Option draft


Yes, there was a long thread started by Tomek. Given that = the option is applicable beyond MAP a *suggestion* was to rename it. I'm per= sonally ok either way. The "Softwire46" option is the currently proposed nam= e. --B_3456732572_568813-- --B_3456732576_585429 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBmnM1yj31sKFUzn+oXNeZ9MA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEzMDcwOTAwMDAwMFoX DTE0MDcwOTIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKF3gwrc9AzRX19+70kG1ar pAx2n0rRVmEPMVO0MXueargwwWcId5UjVjCQs/OZKrPb9SJ9zH+UoBKDWWGWwRowzbGLuhuO vDZzN5D5ugRXTfYvk3bbOMJoAWDU6+HCWrUhrLIeEia/PExE8Rr99HfLsEQldER8XyXq6r/3 Dr5WASl1l/hpFe+rxAAa5XJT+pNMOCxIMCPj8VpzeYJOmHzfLxWcaeYl9VymU4ICGxxyLXUg bZtQb3DMYxCMfEwzdiLBpyjJE46uXnLgaB9HDhXpZ3e9fZsTDQ/ZCdybmbtHIoT3Tp3XwUeZ qSzIaHZf/eqgyjjLXvGogQGWUSDRWrkCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMVLGGx0ZxLhzDsooB5PJ/xYsB1zAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AHo4//31fCpbGVpLs5kiMg5PW8JeyPjK8Tet13aS7l/HQxWgB3MRcuEmJy6zvME3Lk7xEdBG mRRNuuvW4i5yL69ozhdEEP6XrQm+u25i90V8HxE0nQ/+vN5obi531TsXhmCxaSDGmRHftmLT nFKobGVjbnPa4QmPUPw7umHQrGfrIIwYKkFIiiEJy2513So40fe9pfZesqb4NUAcCivDcGvN bZWHWtNUDRx2Z2jtJs3LkrN7Hz1qPc0/Cpo0rYs9n4i+0mR4m7uponpSkId8anHov8MaPeJu ayRseFi+82YxnT2lAw+bMfGJEtQKPZ/A8KlYZsxVuklQ9cPidH9ZpmkwggUaMIIEAqADAgEC 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 Q0ECEGaczXKPfWwoVTOf6hc15n0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQefgL3 XWzpL/HOJC/8+W0XkpxwyzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMzA3MTUxNTI5MzJaMA0GCSqGSIb3DQEBAQUABIIBAAgLcOiwFH5nEsw9gYCKnIpX jfIVfq68RBEcVKNPSOnik5iI0XZ0VopUcFo4vlWi0sR9aDLmrbFYbAm4aH9b+BtrKwYzTUmK 5PejuedMKUlqNgSfcmA8UtN4wX+fP4GNZ07YMA10rCiNSJSIaf8vyA4j+vlC03gpAQn0X51G JMO4Gcryau1uFHg28lnY0A0lkzIlQY3e9DcmEG0spcEwOUD9ryCtjKkq41U6o1zqZjAgDACg ugVrstbWR4dAoZmLAmPCk05nRHvk9zMP3OpwZFNqFdu/J/JUW3ovQ1rrzzJGfGMGA9TxgJxz N48CfYlJSEhOicvtLNS9/hElH45WX8o= --B_3456732576_585429-- From wdec.ietf@gmail.com Mon Jul 15 09:01:28 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500EA11E80EA for ; Mon, 15 Jul 2013 09:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ai2Bzea9kAbU for ; Mon, 15 Jul 2013 09:01:27 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 702D011E811B for ; Mon, 15 Jul 2013 09:01:22 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id cz11so6440961qeb.22 for ; Mon, 15 Jul 2013 09:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FjXeV/Oxme7H6t5EMGIFNI1BXzIDbFDdpxsVlUt5bto=; b=g4q3v2cvve/tsfXAAr2GEiIJ1BInNwgieH3Q1XlG54tX2pEem22M6NQZeUORw7SX0k f+ditX/XgG2mUvK2rO38VVvWqyQIrS4RgZikCK3objwlXD8nn8jpj0LfPwQCuoDM7F+B w5yZNOTzKYKd1LaV84B7UTn7lZwg6zjK2VEHdD7aMnIIAwzdp5MI4WB+OLWUl1yoz2jw WaLA6Tu1Zd1K1JtcsZO7bhLr4yZxR7ywvyPMrPKhuSm4Fq+9IeXCMzfKg04ArD57ZA9P OpSFHqt4BN5CK8GbzhQteZRDmr+vUhsd7REb+uX7kJZzH5TiW3Lm/04aIPr5BpGK77yJ /qpw== MIME-Version: 1.0 X-Received: by 10.49.110.68 with SMTP id hy4mr50140832qeb.6.1373904075610; Mon, 15 Jul 2013 09:01:15 -0700 (PDT) Received: by 10.49.134.2 with HTTP; Mon, 15 Jul 2013 09:01:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 18:01:15 +0200 Message-ID: From: Wojciech Dec To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=047d7bdc90aa61fc6104e18ef8ab Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:01:28 -0000 --047d7bdc90aa61fc6104e18ef8ab Content-Type: text/plain; charset=ISO-8859-1 Yes. See Mail of July 8. So far your objection is the only one, although I don't quite see in it any technically grounded objection. A fair bit of discussions between authors (MAP and lw46), softwire & dhc chairs, and WG participants have taken place, and naturally will also be held in Berlin. Re-spinning draft versions is easy. On 15 July 2013 17:29, Lee, Yiu wrote: > Since this is a WG draft, did the authors ask the WG to update this? When > the WG accepted this draft, it was only for MAP. But seems the scope has > been changed. This should start as an Individual draft. I will recommend to > revert back to the last version and present this in Berlin to replace the > MAP draft if the WG agrees with it. > > > From: Wojciech Dec > Date: Thursday, July 11, 2013 10:43 AM > To: Qi Sun > Cc: Softwires-wg > Subject: Re: [Softwires] Changes to DHCP MAP Option draft > > > Yes, there was a long thread started by Tomek. Given that the option is > applicable beyond MAP a *suggestion* was to rename it. I'm personally ok > either way. The "Softwire46" option is the currently proposed name. > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --047d7bdc90aa61fc6104e18ef8ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes. See Mail of July 8. So far your objection i= s the only one, although I don't quite see in it any technically ground= ed objection.
A fair bit of discussions between authors (MAP and l= w46), softwire & dhc chairs, and WG participants have taken place, and = naturally will also be held in Berlin.

Re-spinning draft versions is easy.


On 15 July 2013 17:29,= Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Since this is a WG draft, did th= e authors ask the WG to update this? When the WG accepted this draft, it wa= s only for MAP. But seems the scope has been changed. This should start as = an Individual draft. I will recommend to revert back to the last version an= d present this in Berlin to replace the MAP draft if the WG agrees with it.=


From: Wojciech Dec <wdec.ietf@gmail.com>Date: Thursday, July 11, 2013 10= :43 AM
To: Qi Sun <sunqi.csnet.thu@gmail.com&g= t;
Cc: Softwires-wg <softwires@ietf.org>=
Subject: Re: [Softwires] Changes t= o DHCP MAP Option draft


Yes, there was a long = thread started by Tomek. Given that the option is applicable beyond MAP a *= suggestion* was to rename it. I'm personally ok either way. The "S= oftwire46" option is the currently proposed name.

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


--047d7bdc90aa61fc6104e18ef8ab-- From yiu_lee@cable.comcast.com Mon Jul 15 09:48:51 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFBE21E8101 for ; Mon, 15 Jul 2013 09:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 RXMNTrAJWmB4 for ; Mon, 15 Jul 2013 09:48:45 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A1C5E21E80BE for ; Mon, 15 Jul 2013 09:48:45 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.82538911; Mon, 15 Jul 2013 10:46:44 -0600 Received: from PACDCEXHUB05.cable.comcast.com (24.40.56.122) by PACDCEXHUB01.cable.comcast.com (24.40.56.114) with Microsoft SMTP Server (TLS) id 14.2.318.1; Mon, 15 Jul 2013 12:48:38 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.138]) by pacdcexhub05.cable.comcast.com ([fe80::3d40:bdea:7266:7f5a%18]) with mapi id 14.02.0318.001; Mon, 15 Jul 2013 12:48:37 -0400 From: "Lee, Yiu" To: Softwires-wg Thread-Topic: [Softwires] Changes to DHCP MAP Option draft Thread-Index: AQHOgXsmZuVR6PPmskWzwEokUCwbHA== Date: Mon, 15 Jul 2013 16:48:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.247] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3456737321_883920" MIME-Version: 1.0 Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:48:51 -0000 --B_3456737321_883920 Content-type: multipart/alternative; boundary="B_3456737320_886382" --B_3456737320_886382 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Woj, I am not objecting it. I just stated the new draft has been updated the scope w/o getting explicit consent from the ML. BR, Yiu From: Wojciech Dec Date: Monday, July 15, 2013 12:01 PM To: "Yiu L. LEE" Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft Yes. See Mail of July 8. So far your objection is the only one, although I don't quite see in it any technically grounded objection. A fair bit of discussions between authors (MAP and lw46), softwire & dhc chairs, and WG participants have taken place, and naturally will also be held in Berlin. Re-spinning draft versions is easy. On 15 July 2013 17:29, Lee, Yiu wrote: > Since this is a WG draft, did the authors ask the WG to update this? When the > WG accepted this draft, it was only for MAP. But seems the scope has been > changed. This should start as an Individual draft. I will recommend to revert > back to the last version and present this in Berlin to replace the MAP draft > if the WG agrees with it. > > > From: Wojciech Dec > Date: Thursday, July 11, 2013 10:43 AM > To: Qi Sun > Cc: Softwires-wg > Subject: Re: [Softwires] Changes to DHCP MAP Option draft > > > Yes, there was a long thread started by Tomek. Given that the option is > applicable beyond MAP a *suggestion* was to rename it. I'm personally ok > either way. The "Softwire46" option is the currently proposed name. > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --B_3456737320_886382 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Woj,

I am not objecting it. I just stated the new draft has been updated the sc= ope w/o getting explicit consent from the ML. 

BR,
Yiu

From: Wojciech Dec <wdec.ietf@gmail.c= om>
Date: Monday, July 15, = 2013 12:01 PM
To: "Yiu L. LEE" <= ;yiu_lee@cable.comcast.com>= ;
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] Changes to DHCP MAP Option draft<= br>

Yes. See Mail of July 8. S= o far your objection is the only one, although I don't quite see in it any t= echnically grounded objection.
A fair bit of discussions between authors (MAP and lw46), softwire & dh= c chairs, and WG participants have taken place, and naturally will also be h= eld in Berlin.

Re-spinning draft versions is easy.


On 15 July= 2013 17:29, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
=
Since this is a WG draft, did the authors= ask the WG to update this? When the WG accepted this draft, it was only for= MAP. But seems the scope has been changed. This should start as an Individu= al draft. I will recommend to revert back to the last version and present this in Berlin to replace the MAP draft if the WG agrees with = it.


From: Wojciech Dec <wdec.ietf@gmail.com>
Date: Thursday, July 11, 2013 10:43 AM
To: Qi Sun <sunqi.csnet.thu@gmail.com>
Cc: Softwires-wg <softwires@ietf.org>
Subject= : Re: [Softwires] Changes to DHCP MAP Option draft


Yes, there was a long thread started by Tomek. Given that the option is applica= ble beyond MAP a *suggestion* was to rename it. I'm personally ok either way= . The "Softwire46" option is the currently proposed name.

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


--B_3456737320_886382-- --B_3456737321_883920 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBmnM1yj31sKFUzn+oXNeZ9MA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEzMDcwOTAwMDAwMFoX DTE0MDcwOTIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKF3gwrc9AzRX19+70kG1ar pAx2n0rRVmEPMVO0MXueargwwWcId5UjVjCQs/OZKrPb9SJ9zH+UoBKDWWGWwRowzbGLuhuO vDZzN5D5ugRXTfYvk3bbOMJoAWDU6+HCWrUhrLIeEia/PExE8Rr99HfLsEQldER8XyXq6r/3 Dr5WASl1l/hpFe+rxAAa5XJT+pNMOCxIMCPj8VpzeYJOmHzfLxWcaeYl9VymU4ICGxxyLXUg bZtQb3DMYxCMfEwzdiLBpyjJE46uXnLgaB9HDhXpZ3e9fZsTDQ/ZCdybmbtHIoT3Tp3XwUeZ qSzIaHZf/eqgyjjLXvGogQGWUSDRWrkCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMVLGGx0ZxLhzDsooB5PJ/xYsB1zAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AHo4//31fCpbGVpLs5kiMg5PW8JeyPjK8Tet13aS7l/HQxWgB3MRcuEmJy6zvME3Lk7xEdBG mRRNuuvW4i5yL69ozhdEEP6XrQm+u25i90V8HxE0nQ/+vN5obi531TsXhmCxaSDGmRHftmLT nFKobGVjbnPa4QmPUPw7umHQrGfrIIwYKkFIiiEJy2513So40fe9pfZesqb4NUAcCivDcGvN bZWHWtNUDRx2Z2jtJs3LkrN7Hz1qPc0/Cpo0rYs9n4i+0mR4m7uponpSkId8anHov8MaPeJu ayRseFi+82YxnT2lAw+bMfGJEtQKPZ/A8KlYZsxVuklQ9cPidH9ZpmkwggUaMIIEAqADAgEC 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 Q0ECEGaczXKPfWwoVTOf6hc15n0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTRdDL/ EbOOU1zioSrSy0aGzYWzTzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMzA3MTUxNjQ4NDBaMA0GCSqGSIb3DQEBAQUABIIBAIucqwu0HotGU1ZJgCrFb0Xx Tqy6C5RSr+Ph2txUfJVx1a68L6K2qLWre17Y7KYEgqqcP6rH1ZxjlcWRiBp4gchHrWQbnL7x MARpkA4R0lNNb9sTwkx/yvrOwjR4+S4l6Iore1hK/iAsX7eFS0AD9nVaFw7xxmYnY1TZgbhO pp1d32HMn94xRzESO0E3tpntaFR6g6hP4JQQFReqs9vua1k/7LUbVAYDweQ8Z3YPIrj7y8G2 vjOmwwtKAuC+z4iCwai6CVcQoj46wq3oXIZrALv3lXSB1kt5P1WNQUl9xm03ywZOS5CVY8G4 qc6T9CdJjLClYodS53ezqyapoUAbxp0= --B_3456737321_883920-- From internet-drafts@ietf.org Mon Jul 15 09:59:51 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF3221E80BB; Mon, 15 Jul 2013 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.236 X-Spam-Level: X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001, 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 tYillquzP19S; Mon, 15 Jul 2013 09:59:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8970A11E8108; Mon, 15 Jul 2013 09:59:50 -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.51.p2 Message-ID: <20130715165950.1249.20359.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 09:59:50 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 16:59:51 -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 : DHCPv6 Options for configuration of Softwire Address and= Port Mapped Clients Author(s) : Tomasz Mrugalski Xiaohong Deng Ole Troan Congxiao Bao Wojciech Dec Freelancer Technologies Filename : draft-ietf-softwire-map-dhcp-04.txt Pages : 20 Date : 2013-07-15 Abstract: This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address+Port (A+P) for providing IPv4 connectivity across an IPv6 network, as specified by the IETF Softwires Working Group, including those where the IPv4 A+P parameters are optionally derived from the CE's IPv6 network prefix by algorithmic means. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-dhcp-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sarikaya2012@gmail.com Mon Jul 15 10:01:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5685411E8182 for ; Mon, 15 Jul 2013 10:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RmV0sK3255xv for ; Mon, 15 Jul 2013 10:01:24 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4B22611E8184 for ; Mon, 15 Jul 2013 10:00:23 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so9582313lba.16 for ; Mon, 15 Jul 2013 10:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=WbpOuCq39bePS83H2TCJg8WXZiUqWF3L0+ZpaQBs3Yo=; b=n51mT8ogofFziJZxMK+/mY0MN2R5GUZa94bIQhkqkmBquW9zBaS6YoR9kaiqEO+p53 pOe8n0KzRQWgdQh7sX/SzQjag30dIMeJw1Se4HpDCm/NblWGHHhg8OfWw9z7rA4OyUj7 vt4ncHJWEKCDynn9dMkR61Ex5QYTd4+u9d1BnCY0rgGwbwstCNXDrCJFrEUjVAx8JRYV FH5uazFyLuty6DcONIa+QFdmma7+TFuI41Mg5ZBwnyKFLSQXjNehk3GOIY3y33FoOU9m nHHRPJzmI8RL3ZtX4JHrMEZokvlOqX5rMPmRN0SPcDWWkyzDYXnd8JhIagdon1vO0E02 p05w== MIME-Version: 1.0 X-Received: by 10.152.21.131 with SMTP id v3mr25485113lae.50.1373907616482; Mon, 15 Jul 2013 10:00:16 -0700 (PDT) Received: by 10.114.176.37 with HTTP; Mon, 15 Jul 2013 10:00:16 -0700 (PDT) Date: Mon, 15 Jul 2013 12:00:16 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: multipart/alternative; boundary=089e0158b6946f4ad704e18fcb8c Subject: [Softwires] draft-ietf-softwire-mesh-multicast-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:01:25 -0000 --089e0158b6946f4ad704e18fcb8c Content-Type: text/plain; charset=ISO-8859-1 Hi Authors, If Softwire mesh means packets from the host to one CE are directly routed to the destination CE, I am puzzled how multicast can be supported in such a network? May be my mesh network understanding is wrong? Regards, Behcet On Mon, Jul 15, 2013 at 5:19 AM, wrote: > > 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 : Softwire Mesh Multicast > Author(s) : Mingwei Xu > Yong Cui > Jianping Wu > Shu Yang > Chris Metz > Greg Shepherd > Filename : draft-ietf-softwire-mesh-multicast-05.txt > Pages : 21 > Date : 2013-07-15 > > Abstract: > The Internet needs to support IPv4 and IPv6 packets. Both address > families and their attendant protocol suites support multicast of the > single-source and any-source varieties. As part of the transition to > IPv6, there will be scenarios where a backbone network running one IP > address family internally (referred to as internal IP or I-IP) will > provide transit services to attached client networks running another > IP address family (referred to as external IP or E-IP). It is > expected that the I-IP backbone will offer unicast and multicast > transit services to the client E-IP networks. > > Softwire Mesh is a solution to E-IP unicast and multicast support > across an I-IP backbone. This document describes the mechanisms for > supporting Internet-style multicast across a set of E-IP and I-IP > networks supporting softwire mesh. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-mesh-multicast-05 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --089e0158b6946f4ad704e18fcb8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Authors,

If Softwire mesh means packets from the host to one CE a= re directly routed to the destination CE, I am puzzled how multicast can be= supported in such a network?

May be my mesh network understanding i= s wrong?

Regards,

Behcet

On Mon, Jul 15= , 2013 at 5:19 AM, <internet-drafts@ietf.org> wrote:=

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Softwires Working Group of the IETF.
=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Softwire Mesh Multicast
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Mingwei Xu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yong Cui
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jianping Wu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Shu Yang
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Chris Metz
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Greg Shepherd
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-mesh-multicas= t-05.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-15

Abstract:
=A0 =A0The Internet needs to support IPv4 and IPv6 packets. =A0Both address=
=A0 =A0families and their attendant protocol suites support multicast of th= e
=A0 =A0single-source and any-source varieties. =A0As part of the transition= to
=A0 =A0IPv6, there will be scenarios where a backbone network running one I= P
=A0 =A0address family internally (referred to as internal IP or I-IP) will<= br> =A0 =A0provide transit services to attached client networks running another=
=A0 =A0IP address family (referred to as external IP or E-IP). =A0It is
=A0 =A0expected that the I-IP backbone will offer unicast and multicast
=A0 =A0transit services to the client E-IP networks.

=A0 =A0Softwire Mesh is a solution to E-IP unicast and multicast support =A0 =A0across an I-IP backbone. =A0This document describes the mechanisms f= or
=A0 =A0supporting Internet-style multicast across a set of E-IP and I-IP =A0 =A0networks supporting softwire mesh.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire= -mesh-multicast

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-softwire-mesh-mul= ticast-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-s= oftwire-mesh-multicast-05


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

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

--089e0158b6946f4ad704e18fcb8c-- From sunqi.csnet.thu@gmail.com Mon Jul 15 10:41:43 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847F321E8104 for ; Mon, 15 Jul 2013 10:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 jityLVbAwuyX for ; Mon, 15 Jul 2013 10:41:42 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D942D11E8189 for ; Mon, 15 Jul 2013 10:41:42 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so11358299pad.30 for ; Mon, 15 Jul 2013 10:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=jlJuPCoiT+ZrkaaVmf/ZhOkD6xkrqmmCUNr3Ve1XrJo=; b=DDPUAYpWeo0r2GTIIVy/VE4WFATfZHjEl7D49YS73oouC9ps1VrUJHyEupOUzVU7rQ 7nuFnzzmd3BabneC/y4+ot51e45/k/2YlP7GJHBZL8Q5/c7GjAE/NQGseWjQFaGTaLWV /aKsEwmTSy00iaknbwLII49Sbx4sKnUGb2sKo69IF+PhOWpvvNdrLrvASaNXOgpbI7w2 FmIXnlbKLFknT+ZHG7ynfU1XgjqzWtb6U4ePPza7slbTeBfSLpfZ0E/x4oMtf03n+mGN OX8k2iSsmGa02vByZZfLFdK0NILJTfM7GH4RdiTOItStct6X1ecCk5aR7zSJAnGf2aKN /o4g== X-Received: by 10.68.60.132 with SMTP id h4mr9971203pbr.177.1373910102593; Mon, 15 Jul 2013 10:41:42 -0700 (PDT) Received: from [192.168.0.115] ([114.255.40.13]) by mx.google.com with ESMTPSA id z19sm65699979paf.12.2013.07.15.10.41.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Jul 2013 10:41:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-127-465898884 From: Qi Sun In-Reply-To: Date: Tue, 16 Jul 2013 01:41:29 +0800 Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 17:41:43 -0000 --Apple-Mail-127-465898884 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Woj , The scope of the document has changed dramatically. I think it necessary = to get more consensus from the WG to do so. =46rom my reading, it's = something different from the draft-ietf-softwire-map-dhcp. It's more = like a 'unified-dhcp'. We need more discussing on this. Best Regards, Qi On 2013-7-16, at =E4=B8=8A=E5=8D=8812:01, Wojciech Dec wrote: > Yes. See Mail of July 8. So far your objection is the only one, = although I don't quite see in it any technically grounded objection. > A fair bit of discussions between authors (MAP and lw46), softwire & = dhc chairs, and WG participants have taken place, and naturally will = also be held in Berlin. >=20 > Re-spinning draft versions is easy. >=20 >=20 > On 15 July 2013 17:29, Lee, Yiu wrote: > Since this is a WG draft, did the authors ask the WG to update this? = When the WG accepted this draft, it was only for MAP. But seems the = scope has been changed. This should start as an Individual draft. I will = recommend to revert back to the last version and present this in Berlin = to replace the MAP draft if the WG agrees with it. >=20 >=20 > From: Wojciech Dec > Date: Thursday, July 11, 2013 10:43 AM > To: Qi Sun > Cc: Softwires-wg > Subject: Re: [Softwires] Changes to DHCP MAP Option draft >=20 >=20 > Yes, there was a long thread started by Tomek. Given that the option = is applicable beyond MAP a *suggestion* was to rename it. I'm personally = ok either way. The "Softwire46" option is the currently proposed name. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-127-465898884 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Woj = ,

The scope of the document has changed = dramatically. I think it necessary to get more consensus from the WG to = do so. =46rom my reading, it's something different from the = draft-ietf-softwire-map-dhcp. It's more like a 'unified-dhcp'. We need = more discussing on this.


Best = Regards,
Qi

On 2013-7-16, at =E4=B8=8A=E5=8D=8812:01, Wojciech Dec = wrote:

Yes. See Mail of July 8. So far = your objection is the only one, although I don't quite see in it any = technically grounded objection.
A fair bit of discussions = between authors (MAP and lw46), softwire & dhc chairs, and WG = participants have taken place, and naturally will also be held in = Berlin.

Re-spinning draft versions is easy.


On 15 July 2013 = 17:29, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Since this is a WG draft, did the authors ask the WG to update = this? When the WG accepted this draft, it was only for MAP. But seems = the scope has been changed. This should start as an Individual draft. I = will recommend to revert back to the last version and present this in = Berlin to replace the MAP draft if the WG agrees with it.


From: Wojciech Dec <wdec.ietf@gmail.com>
Date: Thursday, July 11, 2013 10:43 = AM
To: Qi Sun <sunqi.csnet.thu@gmail.com>
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] = Changes to DHCP MAP Option draft


Yes, there was a = long thread started by Tomek. Given that the option is applicable beyond = MAP a *suggestion* was to rename it. I'm personally ok either way. The = "Softwire46" option is the currently proposed name.

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


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

= --Apple-Mail-127-465898884-- From wdec.ietf@gmail.com Mon Jul 15 11:25:45 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5811E8149 for ; Mon, 15 Jul 2013 11:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CYmv6FgmXMTA for ; Mon, 15 Jul 2013 11:25:43 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 24B4E11E81BD for ; Mon, 15 Jul 2013 11:25:40 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so1788185qab.14 for ; Mon, 15 Jul 2013 11:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Igr9D+zLTPEy80V/q+tTcSzhyXk1a1mCieaey/SD39U=; b=LgwnubhhBv8DiRUMkerUnCsNfaZt//cdd3PbShuAIDX0ZTadZliDH1MXctNRSeXsZA hIfOwn1hXhhbSpw35eXv9hYBpzeqyUs/epLz/aC5bLM8XJKJpNEhc+p1S6jd6+JF9Vbi 8Fe3x0fWNbPZPmnLVodZxipyEjyNnIkJLe3kmM8heedezNilnYkOK2pmnIohZJTd6uYX Cq+bI4+r3POjIg8eLO24Xg/KTG7Gw8sP4BOevZ2u+SFEPhDOb9ii6P9cXN2Gae0kSxgN u49R7xAgVj6DyDSNs6GOLQ8xvcdzFn7bXfo32SChsgzQsQO0c/5vpdxJxb5JYUOu0Hik niog== MIME-Version: 1.0 X-Received: by 10.224.90.1 with SMTP id g1mr55577413qam.0.1373912735969; Mon, 15 Jul 2013 11:25:35 -0700 (PDT) Received: by 10.49.134.2 with HTTP; Mon, 15 Jul 2013 11:25:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Jul 2013 20:25:35 +0200 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=001a11c2c74894774c04e190fc90 Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:25:45 -0000 --001a11c2c74894774c04e190fc90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Qi, the scope remains unchanged: Define DHCPv6 options for CPEs that a MAP CPE can use. It so happens that these same options can be used by any A+P CPE, and I have previously made the case that most of the existing proposals can use the same scheme of dhcp options: Please see - http://www.ietf.org/proceedings/84/slides/slides-84-softwire-13.pdf. This was the document that actually paved for discussion of what then became the uCPE. What more, based on the prototype implementations of the options defined in draft-ietf-map-dhcp-03 we know that they were perfectly capable of addressing MAP, Lw46, ds-lite, etc, CPEs. The fact that they have changed is to address the expressed reservations from parties about the options being "too MAP specific", about flags, naming, etc. I gave the outline of those changes before publishing, and they were also the subject of discussion by numerous parties (not just authors) before. Anyway, for me, the previous "MAP centric" draft was ready for WG last call (bar a few edits). The changes made in -04 reflect the desire to actually have a set of options that address common concerns that apply to A+P. Perhaps you could explain what is the issue in this that needs to be discussed? Alternatively, we can proceed to nail any outstanding technical issues and have the draft sail quickly. Thanks. Woj. On 15 July 2013 19:41, Qi Sun wrote: > > Hi Woj , > > The scope of the document has changed dramatically. I think it necessary > to get more consensus from the WG to do so. From my reading, it's somethi= ng > different from the draft-ietf-softwire-map-dhcp. It's more like a > 'unified-dhcp'. We need more discussing on this. > > > Best Regards, > Qi > > > On 2013-7-16, at =E4=B8=8A=E5=8D=8812:01, Wojciech Dec wrote: > > Yes. See Mail of July 8. So far your objection is the only one, although = I > don't quite see in it any technically grounded objection. > A fair bit of discussions between authors (MAP and lw46), softwire & dhc > chairs, and WG participants have taken place, and naturally will also be > held in Berlin. > > Re-spinning draft versions is easy. > > > On 15 July 2013 17:29, Lee, Yiu wrote: > >> Since this is a WG draft, did the authors ask the WG to update this? Whe= n >> the WG accepted this draft, it was only for MAP. But seems the scope has >> been changed. This should start as an Individual draft. I will recommend= to >> revert back to the last version and present this in Berlin to replace th= e >> MAP draft if the WG agrees with it. >> >> >> From: Wojciech Dec >> Date: Thursday, July 11, 2013 10:43 AM >> To: Qi Sun >> Cc: Softwires-wg >> Subject: Re: [Softwires] Changes to DHCP MAP Option draft >> >> >> Yes, there was a long thread started by Tomek. Given that the option is >> applicable beyond MAP a *suggestion* was to rename it. I'm personally ok >> either way. The "Softwire46" option is the currently proposed name. >> >> _______________________________________________ >> 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 > > > --001a11c2c74894774c04e190fc90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Qi,

the scope=C2= =A0 remains unchanged: Define DHCPv6 options for CPEs that a MAP CPE can us= e. It so happens that these same options can be used by any A+P CPE, and I = have previously made the case that most of the existing proposals can use t= he same scheme of dhcp options: Please see - http://www.ietf.org/proce= edings/84/slides/slides-84-softwire-13.pdf. This was the document that = actually paved for discussion of what then became the uCPE.
What more, based on the prototype implementations of the options defined in= draft-ietf-map-dhcp-03 we know that they were perfectly capable of address= ing MAP, Lw46, ds-lite, etc, CPEs. The fact that they have changed is to ad= dress the expressed reservations from parties about the options being "= ;too MAP specific", about flags, naming, etc. I gave the outline of th= ose changes before publishing, and they were also the subject of discussion= by numerous parties (not just authors) before.

Anyway, for me, the previous "MAP centric" draft was re= ady for WG last call (bar a few edits). The changes made in -04 reflect the= desire to actually have a set of options that address common concerns that= apply to A+P.
Perhaps you could explain what is the issue in this that needs to be discus= sed?

Alternatively, we can proceed to nail any outstanding tec= hnical issues and have the draft sail quickly.

Thanks.
Woj.




On 15 July 2013 = 19:41, Qi Sun <sunqi.csnet.thu@gmail.com> wrote:

Hi Woj ,

The scope of the document has change= d dramatically. I think it necessary to get more consensus from the WG to d= o so. From my reading, it's something different from the draft-ietf-sof= twire-map-dhcp. It's more like a 'unified-dhcp'. We need more d= iscussing on this.


Best Regards,
Qi

On 2013-7-16, at =E4=B8=8A=E5=8D=8812:01, Wojciech Dec wrote:=

Yes. See Mai= l of July 8. So far your objection is the only one, although I don't qu= ite see in it any technically grounded objection.
A fair bit of discussions between authors (MAP and lw46), softwire &a= mp; dhc chairs, and WG participants have taken place, and naturally will al= so be held in Berlin.

Re-spinning draft versions is easy.


On 15 July 2013 17:29,= Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Since this is a WG draft, did th= e authors ask the WG to update this? When the WG accepted this draft, it wa= s only for MAP. But seems the scope has been changed. This should start as = an Individual draft. I will recommend to revert back to the last version an= d present this in Berlin to replace the MAP draft if the WG agrees with it.=


From: Wojciech Dec <wdec.ietf@gmail.com>Date: Thursday, July 11, 2013 10= :43 AM
To: Qi Sun <sunqi.csnet.thu@gmail.com&g= t;
Cc: Softwires-wg <softwires@ietf.org>=
Subject: Re: [Softwires] Changes t= o DHCP MAP Option draft


Yes, there was a long thread starte= d by Tomek. Given that the option is applicable beyond MAP a *suggestion* w= as to rename it. I'm personally ok either way. The "Softwire46&quo= t; option is the currently proposed name.

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


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


--001a11c2c74894774c04e190fc90-- From internet-drafts@ietf.org Mon Jul 15 12:49:06 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D38A11E8233; Mon, 15 Jul 2013 12:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 lGT6bdCzreag; Mon, 15 Jul 2013 12:49:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADC811E81DD; Mon, 15 Jul 2013 12:49:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715194906.11380.91152.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 12:49:06 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 19:49:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Lightweight 4over6: An Extension to the DS-Lite Architec= ture Author(s) : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-01.txt Pages : 19 Date : 2013-07-15 Abstract: DS-Lite [RFC6333] describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address Translation function from the DS-Lite AFTR to the B4, removing the requirement for a Carrier Grade NAT function in the AFTR. This reduces the amount of centralized state that must be held to a per- subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the B4s. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yangshu1988@gmail.com Tue Jul 16 06:03:06 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23ED21F9D4C for ; Tue, 16 Jul 2013 06:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6mybXJoQQYaV for ; Tue, 16 Jul 2013 06:03:06 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id CF24621F9A1E for ; Tue, 16 Jul 2013 06:03:05 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so4128153wiw.2 for ; Tue, 16 Jul 2013 06:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Y++W0XSh1g76YI/HMap0bK7PHRKZ0Bv0OteeSrLs7+8=; b=R3FhCxkzTlSBKED8uvnzbbdRFl1yixeofydfSErdUaQtxKAdhl7OZIbOLQ8TX9b2/u yzIgwBCaz/4PNZTCdzp6GVpD/pt88KHNtkL9nAHQtwlIBBlZEFR332oWRMhRT2uVowPg Xl09SnZx57xrd82FXF6BCLR654zKIXWabssAgjqz70/5wjD39azxeZjhuGpYySK80kg1 aem5UGrTm6OlX19CBLsGudjSXWi06TkZTfnrh5IqtTgv23WMR05/qYg+EuCiLQvOKeZk 9xVe7cOOjDm7mtDrbeGi9vHqMnpwmLJ6c22jRWx0BO90wvLKuoAGJqUOVJDFxGmvSbpx VyvA== MIME-Version: 1.0 X-Received: by 10.181.11.227 with SMTP id el3mr12401225wid.31.1373979784886; Tue, 16 Jul 2013 06:03:04 -0700 (PDT) Received: by 10.194.55.131 with HTTP; Tue, 16 Jul 2013 06:03:04 -0700 (PDT) Date: Tue, 16 Jul 2013 21:03:04 +0800 Message-ID: From: Shu Yang To: softwires@ietf.org, sarikaya@ieee.org Content-Type: multipart/alternative; boundary=f46d043be25e01c25504e1a099fd Subject: Re: [Softwires] draft-ietf-softwire-mesh-multicast-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:03:06 -0000 --f46d043be25e01c25504e1a099fd Content-Type: text/plain; charset=ISO-8859-1 Dear Behcet, > If Softwire mesh means packets from the host to > one CE are directly routed to the destination CE, I > am puzzled how multicast can be supported in such a network? In Softwire mesh multicast, packets from source host are first routed to AFBR (address family border router), using multicast. Then packets travel through the core towards another AFBR (as the core runs MPBGP), with either unicast or multicast. At last, packets are routed to the destination, with multicast again. Your further review and comments are more than welcome. Best Regards, Shu Yang --f46d043be25e01c25504e1a099fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Behcet,

> If Softwir= e mesh means packets from the host to=A0
> one CE are directly= routed to the destination CE, I=A0
> am puzzled how multicast= can be supported in such a network?

In Softwire mesh multicast, packets from source host ar= e first=A0
routed to AFBR (address family border router), using m= ulticast.=A0
Then packets travel through the core towards another= AFBR=A0
(as the core runs MPBGP), with either unicast or multicast.=A0
At last, packets are routed to the destination, with multicast=A0
<= div>again.

Your further review and comments are mo= re than welcome.

Best Regards,
Shu Yang
--f46d043be25e01c25504e1a099fd-- From sarikaya2012@gmail.com Tue Jul 16 12:08:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E3D21F8493 for ; Tue, 16 Jul 2013 12:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zf+o7ZbKxuCv for ; Tue, 16 Jul 2013 12:08:00 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 71BD121F99A8 for ; Tue, 16 Jul 2013 12:07:59 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id v20so914284lbc.17 for ; Tue, 16 Jul 2013 12:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HkEH4y9M5OWviAkntb5GLQtwKeoq/R+b/3z54I/xVZo=; b=GLIPv/neyXMFXf/wcZOReRK73KwnA4qhGg+p5elMORAgWu86uAe2fMIhh2qyDvJtD3 aegh6MSbatC4UQrfJklOGwqYquk55rMNFVSQcDEvy4Sq78SObupto2ExUTjstINVFlzj Gef7zHx8OqPOILobBi2qOGjTGr9q0lbz+Qbp7K7yTbgj+S1vcSPBNGrjCdaJ/G5N0kbt m7pu6gPav4QPCYMnl3K9GIkmcqTfzgMLMwCvslt2/j3XREDnzHA23m11wYtyBn5tS0Uy s4Vq7z7WUpPwUCnfO4vkPWzu0O30LYLIVI72uPOfXuViEgJyf61QyP7vFM/VDiT+sIHN h2IA== MIME-Version: 1.0 X-Received: by 10.112.204.35 with SMTP id kv3mr1664732lbc.84.1374001678316; Tue, 16 Jul 2013 12:07:58 -0700 (PDT) Received: by 10.114.176.37 with HTTP; Tue, 16 Jul 2013 12:07:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Jul 2013 14:07:58 -0500 Message-ID: From: Behcet Sarikaya To: Shu Yang Content-Type: multipart/alternative; boundary=001a11c3bf1ef4f7f604e1a5b1ca Cc: softwires@ietf.org Subject: Re: [Softwires] draft-ietf-softwire-mesh-multicast-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:08:00 -0000 --001a11c3bf1ef4f7f604e1a5b1ca Content-Type: text/plain; charset=ISO-8859-1 Dear Shu, Please see inline. Regards, Behcet On Tue, Jul 16, 2013 at 8:03 AM, Shu Yang wrote: > Dear Behcet, > > > If Softwire mesh means packets from the host to > > one CE are directly routed to the destination CE, I > > am puzzled how multicast can be supported in such a network? > > In Softwire mesh multicast, packets from source host are first > routed to AFBR (address family border router), using multicast. > Then packets travel through the core towards another AFBR > (as the core runs MPBGP), with either unicast or multicast. > At last, packets are routed to the destination, with multicast > again. > > My question is not about how you propose to support multicast. But my question is a very fundamental one. I think that mesh architecture is a very specific architecture. It seems that it will work only for unicast. As to your approach, of course you can do things like that but that would also work for non mesh architecture, right? Your further review and comments are more than welcome. > > Best Regards, > Shu Yang > --001a11c3bf1ef4f7f604e1a5b1ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Shu,

Please see inline.

Regards,

Behcet

On Tue, Jul 16, 2013 at 8:03 AM, Shu Yang <ya= ngshu1988@gmail.com> wrote:
Dear Behcet,

> If Softwire mesh means packets from = the host to=A0
> one CE are directly routed to the destination CE, I=A0
= > am puzzled how multicast can be supported in such a network?

In Softwire mesh multicast, packets from source h= ost are first=A0
routed to AFBR (address family border router), u= sing multicast.=A0
Then packets travel through the core towards a= nother AFBR=A0
(as the core runs MPBGP), with either unicast or multicast.=A0
At last, packets are routed to the destination, with multicast=A0<= div>again.


My question is n= ot about how you propose to support multicast.

But my question is a very fundamental=A0 one. I think that mesh archite= cture is a very specific architecture. It seems that it will work only for = unicast.

As to your approach, of course you can do things like that = but that would also work for non mesh architecture, right?


Your further review and comments are more than welcome.

Best Regards,
Shu Yang

--001a11c3bf1ef4f7f604e1a5b1ca-- From yangshu1988@gmail.com Wed Jul 17 07:46:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F233921F9D2C for ; Wed, 17 Jul 2013 07:46:21 -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, 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 j+uyAsPMwmpw for ; Wed, 17 Jul 2013 07:46:21 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 449A921F9294 for ; Wed, 17 Jul 2013 07:46:20 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id c11so1852149wgh.25 for ; Wed, 17 Jul 2013 07:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DsB0CfC+fS1UJwUwMqiexkq2Y/801yqWP4PZ9W5wVCg=; b=Uv3QSyCP7EqUViN3mjbDCVhZdn5KpG8p52DakZoD9NNzOIXX9qErJsnVly8Bl6rI7v O0A3m3jR5dA627N2Xbrc8wFTUIP8xf1DKKM/wKoPfj7BDFk+dB8mDPwSSBHzw3wvy81d tJ2/38B4K704E0rGOjDaycRJlsihpNTa0MzQzWlqtZs4FONdRmn0rrqwfEbuB3Qex1NC Hw91YVLmEplM//lAlApsUSQe4I0rJo7cDYuZ4cxINvyVWmnsIzyEEr75ai1EwnTF1Uqn TX9IxddSX8d76LxHPelGrwRRfGTFfaAQfEapnCLykZ7glmrvsDKyeaUcpI/P32M49vbS /O7w== MIME-Version: 1.0 X-Received: by 10.180.36.107 with SMTP id p11mr4978660wij.31.1374072380314; Wed, 17 Jul 2013 07:46:20 -0700 (PDT) Received: by 10.194.55.131 with HTTP; Wed, 17 Jul 2013 07:46:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 22:46:20 +0800 Message-ID: From: Shu Yang To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: Re: [Softwires] draft-ietf-softwire-mesh-multicast-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:46:22 -0000 Hi, Dear Behcet, > But my question is a very fundamental one. I think that mesh architecture is > a very specific architecture. It seems that it will work only for unicast. In Section 11 of RFC5565, it's recommended that softwire multicast be supported within the mesh framework. Best Regards, Shu Yang On Wed, Jul 17, 2013 at 3:07 AM, Behcet Sarikaya wrote: > > Dear Shu, > > Please see inline. > > Regards, > > Behcet > > On Tue, Jul 16, 2013 at 8:03 AM, Shu Yang wrote: >> >> Dear Behcet, >> >> > If Softwire mesh means packets from the host to >> > one CE are directly routed to the destination CE, I >> > am puzzled how multicast can be supported in such a network? >> >> In Softwire mesh multicast, packets from source host are first >> routed to AFBR (address family border router), using multicast. >> Then packets travel through the core towards another AFBR >> (as the core runs MPBGP), with either unicast or multicast. >> At last, packets are routed to the destination, with multicast >> again. >> > > My question is not about how you propose to support multicast. > > But my question is a very fundamental one. I think that mesh architecture is a very specific architecture. It seems that it will work only for unicast. > > As to your approach, of course you can do things like that but that would also work for non mesh architecture, right? > > >> Your further review and comments are more than welcome. >> >> Best Regards, >> Shu Yang > > From sarikaya2012@gmail.com Wed Jul 17 09:47:53 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F6021F9B8C for ; Wed, 17 Jul 2013 09:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 E0TDl-T2KR85 for ; Wed, 17 Jul 2013 09:47:53 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8B72E21F9ADD for ; Wed, 17 Jul 2013 09:47:52 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so1655660lab.41 for ; Wed, 17 Jul 2013 09:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4jANjqVjNrppKhWiBXfCs9g1iF/iWgIWKoTFLSDf3Nw=; b=F5JOMTzHmc+Cspw0DjlWqQzq5La9pJf73XSZjR9/bq5U1Nq7EoAWYDQIIe5Q1Klb8q lbvD9tBGLmM2tTrIzcRnIIbpvJtL4S8IMZc4bcqsquDOhdyQOvy3IjoYyB0+ibCg0F7h GYomwrkBCCic7f8vrglieSFK4eMC/lc55YU8+e1bLli93mDW/Q//i9roISVdLJtuXP1N YBdF70Il343MFvaVc4TlYQfiG72aDr1jaLeQLFlwBdGy2B7Fc+vhkjTBkM20hlfiwaUV Nhpv1IxOo68vGyaTnLJUHrrM9EEfk1iPPdCoEeETSECG+NnVASe3jirdZGvZY8twdSx3 48fA== MIME-Version: 1.0 X-Received: by 10.152.120.228 with SMTP id lf4mr3343395lab.65.1374079671444; Wed, 17 Jul 2013 09:47:51 -0700 (PDT) Received: by 10.114.176.37 with HTTP; Wed, 17 Jul 2013 09:47:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Jul 2013 11:47:51 -0500 Message-ID: From: Behcet Sarikaya To: Shu Yang Content-Type: multipart/alternative; boundary=089e01176915b5a9cd04e1b7daaa Cc: Softwires-wg Subject: Re: [Softwires] draft-ietf-softwire-mesh-multicast-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 16:47:53 -0000 --089e01176915b5a9cd04e1b7daaa Content-Type: text/plain; charset=ISO-8859-1 Hi Shu, I was referring to the mesh mode as opposed to hub and spoke mode (in http://tools.ietf.org/html/draft-ietf-softwire-map-07). I think that mesh mode and the softwire mesh (in RFC 5565) are two different things. I must admit that I don't know the mesh architecture you are talking about and don't have time to study it these days. Regarding your draft, you define AFBR. I checked other Softwire transition protocols, I could not find such an entity. It is puzzling to me. Regards, Behcet On Wed, Jul 17, 2013 at 9:46 AM, Shu Yang wrote: > Hi, Dear Behcet, > > > But my question is a very fundamental one. I think that mesh > architecture is > > a very specific architecture. It seems that it will work only for > unicast. > > In Section 11 of RFC5565, it's recommended that softwire multicast be > supported > within the mesh framework. > > Best Regards, > Shu Yang > > On Wed, Jul 17, 2013 at 3:07 AM, Behcet Sarikaya > wrote: > > > > Dear Shu, > > > > Please see inline. > > > > Regards, > > > > Behcet > > > > On Tue, Jul 16, 2013 at 8:03 AM, Shu Yang wrote: > >> > >> Dear Behcet, > >> > >> > If Softwire mesh means packets from the host to > >> > one CE are directly routed to the destination CE, I > >> > am puzzled how multicast can be supported in such a network? > >> > >> In Softwire mesh multicast, packets from source host are first > >> routed to AFBR (address family border router), using multicast. > >> Then packets travel through the core towards another AFBR > >> (as the core runs MPBGP), with either unicast or multicast. > >> At last, packets are routed to the destination, with multicast > >> again. > >> > > > > My question is not about how you propose to support multicast. > > > > But my question is a very fundamental one. I think that mesh > architecture is a very specific architecture. It seems that it will work > only for unicast. > > > > As to your approach, of course you can do things like that but that > would also work for non mesh architecture, right? > > > > > >> Your further review and comments are more than welcome. > >> > >> Best Regards, > >> Shu Yang > > > > > --089e01176915b5a9cd04e1b7daaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shu,

I was r= eferring to the mesh mode as opposed to hub and spoke mode (in http://tools.ietf.org= /html/draft-ietf-softwire-map-07).

I think that mesh mode and the softwire mesh (in RFC 5565) are tw= o different things. I must admit that I don't know the mesh architectur= e you are talking about and don't have time to study it these days.

Regarding your draft, you define AFBR. I checked other Softwire t= ransition protocols, I could not find such an entity.
It is puzzli= ng to me.

Regards,

Behcet


On Wed, Jul 17, 2013 at 9:46 AM, Shu Yan= g <yangshu1988@gmail.com> wrote:
Hi, Dear Behcet,

> But my question is a very fundamental =A0one. I think that mesh archit= ecture is
> a very specific architecture. It seems that it will work only for unic= ast.

In Section 11 of RFC5565, =A0it's recommended that softwire multi= cast be supported
within the mesh framework.

Best Regards,
Shu Yang

On Wed, Jul 17, 2013 at 3:07 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
>
> Dear Shu,
>
> Please see inline.
>
> Regards,
>
> Behcet
>
> On Tue, Jul 16, 2013 at 8:03 AM, Shu Yang <yangshu1988@gmail.com> wrote:
>>
>> Dear Behcet,
>>
>> > If Softwire mesh means packets from the host to
>> > one CE are directly routed to the destination CE, I
>> > am puzzled how multicast can be supported in such a network?<= br> >>
>> In Softwire mesh multicast, packets from source host are first
>> routed to AFBR (address family border router), using multicast. >> Then packets travel through the core towards another AFBR
>> (as the core runs MPBGP), with either unicast or multicast.
>> At last, packets are routed to the destination, with multicast
>> again.
>>
>
> My question is not about how you propose to support multicast.
>
> But my question is a very fundamental =A0one. I think that mesh archit= ecture is a very specific architecture. It seems that it will work only for= unicast.
>
> As to your approach, of course you can do things like that but that wo= uld also work for non mesh architecture, right?
>
>
>> Your further review and comments are more than welcome.
>>
>> Best Regards,
>> Shu Yang
>
>

--089e01176915b5a9cd04e1b7daaa-- From tomasz.mrugalski@gmail.com Wed Jul 17 13:26:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D297321F99F1 for ; Wed, 17 Jul 2013 13:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 fxRlP8Htu1Bi for ; Wed, 17 Jul 2013 13:26:02 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 171CC21F99FC for ; Wed, 17 Jul 2013 13:26:01 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id d7so907844bkh.11 for ; Wed, 17 Jul 2013 13:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:x-tagtoolbar-keys :content-type:content-transfer-encoding; bh=YwTa2b3tLM0orWE1gwByx86k+vYuveM8Hh3XEGVkdWw=; b=ospJ5gQSJL9sJBojDeFIYAYMWtIVi8DTwiYQV/1KF6JEUO6dpr2HT8INs4hk7cHXWZ U1+golKnjoYc111gom8q5ZSMRZPAtN5ZaNFQE5uDoM8BiA8vMCjmdW7UXc9XhfSm83bM EY9CjsDBiIrxvNzpWRTsG4SnxRxniopI1BTDgkhTY/BjWijPeuoC0jBKm1c5Y29UyRc3 Wg85EwPGTRdHw72Cp/QndUpXbxGrRkKQrmDuVrBzc2Gm5OODQ22/BgP6vgHNy/9ATJpN fNnt1z+L2CHRGJZ7Ufc4MtGamwtqZaKzpkXgSRFL14ER42vVBxJBXaePMBeorEnR38iu kp3w== X-Received: by 10.204.62.201 with SMTP id y9mr1287678bkh.23.1374092759987; Wed, 17 Jul 2013 13:25:59 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id if11sm2486855bkc.15.2013.07.17.13.25.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 13:25:59 -0700 (PDT) Message-ID: <51E6FDD3.9020108@gmail.com> Date: Wed, 17 Jul 2013 22:25:55 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: X-Enigmail-Version: 1.4.6 X-TagToolbar-Keys: D20130717222555463 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:26:02 -0000 On 15.07.2013 18:48, Lee, Yiu wrote: > Woj, > > I am not objecting it. I just stated the new draft has been updated the > scope w/o getting explicit consent from the ML. The proposed unification of DHCP provisioning method was discussed at length during last meeting (and I think in Atlanta as well). See minutes: http://www.ietf.org/proceedings/86/minutes/minutes-86-softwire Here's the relevant part (excellent notes btw): Tomek: Should the draft be kept as it is with a new name? Suresh: It is not so important to change the name. Makes sense to fold this into the MAP DHCP document. Also see Ian's presentation from Orlando: http://www.ietf.org/proceedings/86/slides/slides-86-softwire-3.pdf I won't make any statements about Softwire aspects of the draft, but I can tell that the draft looks reasonable from the DHCP perspective. It is intended as a generic extensible mechanism for provisioning A+P solutions, hence the options name change (OPTION_MAP_* => OPTION_S46_*). Woj sent me an unpublished version asking for a review and I have provided one. There was a handful of nits, but nothing serious. draft-ietf-softwire-map-dhcp seems to adhere to DHCPv6 option guidelines (draft-ietf-dhc-option-guidelines-12). As a DHC co-chair, I plan to encourage DHCP folks to participate in a broader review as soon as this draft reaches WGLC in Softwires (which I hope will happen soon). Hope that helps, Tomek From suresh.krishnan@ericsson.com Wed Jul 17 14:25:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AC921F9EC4 for ; Wed, 17 Jul 2013 14:25:57 -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 orXJkImfvopm for ; Wed, 17 Jul 2013 14:25:52 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0585D21F9E94 for ; Wed, 17 Jul 2013 14:25:49 -0700 (PDT) X-AuditID: c6180641-b7f986d000007a82-51-51e70bdd9485 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4B.CD.31362.DDB07E15; Wed, 17 Jul 2013 23:25:49 +0200 (CEST) Received: from [142.133.113.185] (147.117.188.134) by smtps-am.internal.ericsson.com (147.117.188.78) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 17 Jul 2013 17:25:48 -0400 Message-ID: <51E70B41.8030000@ericsson.com> Date: Wed, 17 Jul 2013 17:23:13 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Lee, Yiu" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.134] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyuXSPn+5d7ueBBqfmClscXraVyWLBpx9s Dkwezx/7eixZ8pMpgCmKyyYlNSezLLVI3y6BK2Pyy++MBWtEKlp6ljA3MP7j72Lk5JAQMJH4 d+wGO4QtJnHh3nq2LkYuDiGBo4wS17cvZQNJCAnsZJS4/1cHxOYV0JbYPvMFWJxFQFVi76HH zCA2G9CgDTs/M4HYogJhEh+WLWGCqBeUODnzCQuILSKgJfH8xFSwemag3nVNk8BsYQFLiePL 7rNA7AqR+Pz2ONh8ToFQiQk77rBAHCcpseVFOztEr57ElKstjBC2vMT2t3OYIXo1Jbau+c4K Ua8s8e/dCpYJjMKzkJwxC0n7LCTtCxiZVzFylBanluWmGxluYgSG8DEJNscdjAs+WR5ilOZg URLn3aB3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY/YtCf1SIenKezyRLjkXj6THrK64 9WX7jV8W/P+mdM6cVJTh9nzd8lWrnjtEh3JrKVx3t1La9H+T+wltq5VnL3xvOfOaWedJ5MmU upCzpVJiLMYf92hJ/arTqrKI81lxZXmvgrDBy/uMmrYXvdcVVRy6cSRU9Vz5Q5cPGqphPgIH uFtffPyfp8RSnJFoqMVcVJwIAFby8JAvAgAA Cc: Softwires-wg Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:25:57 -0000 Hi Yiu, As Tomek said we discussed this a bit in Orlando. If you are concerned about this, we can do a short call on the list and follow up at the meeting to see if there are any objections in the wg. Does that work for you? Thanks Suresh On 07/15/2013 12:48 PM, Lee, Yiu wrote: > Woj, > > I am not objecting it. I just stated the new draft has been updated the > scope w/o getting explicit consent from the ML. > > BR, > Yiu > > From: Wojciech Dec > > Date: Monday, July 15, 2013 12:01 PM > To: "Yiu L. LEE" > > Cc: Softwires-wg > > Subject: Re: [Softwires] Changes to DHCP MAP Option draft > > Yes. See Mail of July 8. So far your objection is the only one, although > I don't quite see in it any technically grounded objection. > A fair bit of discussions between authors (MAP and lw46), softwire & dhc > chairs, and WG participants have taken place, and naturally will also be > held in Berlin. > > Re-spinning draft versions is easy. > > > On 15 July 2013 17:29, Lee, Yiu > wrote: > > Since this is a WG draft, did the authors ask the WG to update this? > When the WG accepted this draft, it was only for MAP. But seems the > scope has been changed. This should start as an Individual draft. I > will recommend to revert back to the last version and present this > in Berlin to replace the MAP draft if the WG agrees with it. > > > From: Wojciech Dec > > Date: Thursday, July 11, 2013 10:43 AM > To: Qi Sun > > Cc: Softwires-wg > > Subject: Re: [Softwires] Changes to DHCP MAP Option draft > > > Yes, there was a long thread started by Tomek. Given that the option > is applicable beyond MAP a *suggestion* was to rename it. I'm > personally ok either way. The "Softwire46" option is the currently > proposed name. > > _______________________________________________ > 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 yangshu1988@gmail.com Thu Jul 18 08:40:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3074011E8166 for ; Thu, 18 Jul 2013 08:40:38 -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=[AWL=0.000, 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 aGEZrZ7QnHl5 for ; Thu, 18 Jul 2013 08:40:37 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 61B8211E8158 for ; Thu, 18 Jul 2013 08:40:37 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hj3so6813715wib.4 for ; Thu, 18 Jul 2013 08:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hWRIn+qhbI6OKzztuBGUIfZbnAIBsixmk1vq61HGSq0=; b=FQGnNHwGazVvPXJEAjt22M4ZTST3F9W4ODtEznJD80NfHMDypcVDEj22FptBB+Fg66 F1eOqGHLv34/jLd4+ByjaV927pl71X2+hE6YVKS0MRby7+ttVWSALEmoVRtDQuYAtIi/ 9skyK6JFhhemQq1ozhQGtwRwQAKsj3gaUX46iC98XUBOT+GMDAjMTExJknAQEj62pul6 7CYCZICR6k3REdJ4RbUAjLq/qycr1KIr7lOvIL1ovA1QZ8l6aoZLDedb0pGTWWAr03EZ K590YcrT/k+cadzB4FXz1kzTcyy9MiOoY+b7rQeYFbwkr898HY5S57CdSBfp8a0LCQop 7mHg== MIME-Version: 1.0 X-Received: by 10.194.243.101 with SMTP id wx5mr8984188wjc.49.1374162035317; Thu, 18 Jul 2013 08:40:35 -0700 (PDT) Received: by 10.194.55.131 with HTTP; Thu, 18 Jul 2013 08:40:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Jul 2013 23:40:35 +0800 Message-ID: From: Shu Yang To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires-wg Subject: Re: [Softwires] draft-ietf-softwire-mesh-multicast-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:40:38 -0000 Hi, Dear Behcet, > I was referring to the mesh mode as opposed to hub and spoke mode (in > http://tools.ietf.org/html/draft-ietf-softwire-map-07). In my memory, the two modes were also defined in RFC 4925, which defined the softwire problem, including softwire mesh and softwire hub and spoke. Then RFC 5565 provided the framework for softwire mesh. We are motivated by multicast routing within softwire mesh. > Regarding your draft, you define AFBR. I checked other Softwire transition > protocols, I could not find such an entity. > It is puzzling to me. AFBR was defined in RFC 5565. Best Regards, Shu Yang On Thu, Jul 18, 2013 at 12:47 AM, Behcet Sarikaya wrote: > Hi Shu, > > I was referring to the mesh mode as opposed to hub and spoke mode (in > http://tools.ietf.org/html/draft-ietf-softwire-map-07). > > I think that mesh mode and the softwire mesh (in RFC 5565) are two different > things. I must admit that I don't know the mesh architecture you are talking > about and don't have time to study it these days. > > Regarding your draft, you define AFBR. I checked other Softwire transition > protocols, I could not find such an entity. > It is puzzling to me. > > Regards, > > Behcet > > > On Wed, Jul 17, 2013 at 9:46 AM, Shu Yang wrote: >> >> Hi, Dear Behcet, >> >> > But my question is a very fundamental one. I think that mesh >> > architecture is >> > a very specific architecture. It seems that it will work only for >> > unicast. >> >> In Section 11 of RFC5565, it's recommended that softwire multicast be >> supported >> within the mesh framework. >> >> Best Regards, >> Shu Yang >> >> On Wed, Jul 17, 2013 at 3:07 AM, Behcet Sarikaya >> wrote: >> > >> > Dear Shu, >> > >> > Please see inline. >> > >> > Regards, >> > >> > Behcet >> > >> > On Tue, Jul 16, 2013 at 8:03 AM, Shu Yang wrote: >> >> >> >> Dear Behcet, >> >> >> >> > If Softwire mesh means packets from the host to >> >> > one CE are directly routed to the destination CE, I >> >> > am puzzled how multicast can be supported in such a network? >> >> >> >> In Softwire mesh multicast, packets from source host are first >> >> routed to AFBR (address family border router), using multicast. >> >> Then packets travel through the core towards another AFBR >> >> (as the core runs MPBGP), with either unicast or multicast. >> >> At last, packets are routed to the destination, with multicast >> >> again. >> >> >> > >> > My question is not about how you propose to support multicast. >> > >> > But my question is a very fundamental one. I think that mesh >> > architecture is a very specific architecture. It seems that it will work >> > only for unicast. >> > >> > As to your approach, of course you can do things like that but that >> > would also work for non mesh architecture, right? >> > >> > >> >> Your further review and comments are more than welcome. >> >> >> >> Best Regards, >> >> Shu Yang >> > >> > > > From yiu_lee@cable.comcast.com Thu Jul 18 11:24:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C45011E81C1 for ; Thu, 18 Jul 2013 11:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.81 X-Spam-Level: X-Spam-Status: No, score=-3.81 tagged_above=-999 required=5 tests=[AWL=1.421, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 En-u6oASNGZL for ; Thu, 18 Jul 2013 11:24:26 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 947B411E81B7 for ; Thu, 18 Jul 2013 11:24:21 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.83308330; Thu, 18 Jul 2013 12:23:42 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.138]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Thu, 18 Jul 2013 14:24:19 -0400 From: "Lee, Yiu" To: Softwires-wg Thread-Topic: [Softwires] Changes to DHCP MAP Option draft Thread-Index: AQHOg+QEvUESYyHJ2UCjruDpY5mdlw== Date: Thu, 18 Jul 2013 18:24:18 +0000 Message-ID: In-Reply-To: <51E70B41.8030000@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [68.87.16.249] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3457002257_1312435" MIME-Version: 1.0 Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:24:33 -0000 --B_3457002257_1312435 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit It works for me. Thanks, Yiu On 7/17/13 5:23 PM, "Suresh Krishnan" wrote: >Hi Yiu, > As Tomek said we discussed this a bit in Orlando. If you are concerned >about this, we can do a short call on the list and follow up at the >meeting to see if there are any objections in the wg. Does that work for >you? > >Thanks >Suresh > >On 07/15/2013 12:48 PM, Lee, Yiu wrote: >> Woj, >> >> I am not objecting it. I just stated the new draft has been updated the >> scope w/o getting explicit consent from the ML. >> >> BR, >> Yiu >> >> From: Wojciech Dec > >> Date: Monday, July 15, 2013 12:01 PM >> To: "Yiu L. LEE" > > >> Cc: Softwires-wg > >> Subject: Re: [Softwires] Changes to DHCP MAP Option draft >> >> Yes. See Mail of July 8. So far your objection is the only one, although >> I don't quite see in it any technically grounded objection. >> A fair bit of discussions between authors (MAP and lw46), softwire & dhc >> chairs, and WG participants have taken place, and naturally will also be >> held in Berlin. >> >> Re-spinning draft versions is easy. >> >> >> On 15 July 2013 17:29, Lee, Yiu > > wrote: >> >> Since this is a WG draft, did the authors ask the WG to update this? >> When the WG accepted this draft, it was only for MAP. But seems the >> scope has been changed. This should start as an Individual draft. I >> will recommend to revert back to the last version and present this >> in Berlin to replace the MAP draft if the WG agrees with it. >> >> >> From: Wojciech Dec >> >> Date: Thursday, July 11, 2013 10:43 AM >> To: Qi Sun > > >> Cc: Softwires-wg > >> Subject: Re: [Softwires] Changes to DHCP MAP Option draft >> >> >> Yes, there was a long thread started by Tomek. Given that the option >> is applicable beyond MAP a *suggestion* was to rename it. I'm >> personally ok either way. The "Softwire46" option is the currently >> proposed name. >> >> _______________________________________________ >> 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_3457002257_1312435 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBmnM1yj31sKFUzn+oXNeZ9MA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEzMDcwOTAwMDAwMFoX DTE0MDcwOTIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOKF3gwrc9AzRX19+70kG1ar pAx2n0rRVmEPMVO0MXueargwwWcId5UjVjCQs/OZKrPb9SJ9zH+UoBKDWWGWwRowzbGLuhuO vDZzN5D5ugRXTfYvk3bbOMJoAWDU6+HCWrUhrLIeEia/PExE8Rr99HfLsEQldER8XyXq6r/3 Dr5WASl1l/hpFe+rxAAa5XJT+pNMOCxIMCPj8VpzeYJOmHzfLxWcaeYl9VymU4ICGxxyLXUg bZtQb3DMYxCMfEwzdiLBpyjJE46uXnLgaB9HDhXpZ3e9fZsTDQ/ZCdybmbtHIoT3Tp3XwUeZ qSzIaHZf/eqgyjjLXvGogQGWUSDRWrkCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMVLGGx0ZxLhzDsooB5PJ/xYsB1zAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AHo4//31fCpbGVpLs5kiMg5PW8JeyPjK8Tet13aS7l/HQxWgB3MRcuEmJy6zvME3Lk7xEdBG mRRNuuvW4i5yL69ozhdEEP6XrQm+u25i90V8HxE0nQ/+vN5obi531TsXhmCxaSDGmRHftmLT nFKobGVjbnPa4QmPUPw7umHQrGfrIIwYKkFIiiEJy2513So40fe9pfZesqb4NUAcCivDcGvN bZWHWtNUDRx2Z2jtJs3LkrN7Hz1qPc0/Cpo0rYs9n4i+0mR4m7uponpSkId8anHov8MaPeJu ayRseFi+82YxnT2lAw+bMfGJEtQKPZ/A8KlYZsxVuklQ9cPidH9ZpmkwggUaMIIEAqADAgEC 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 Q0ECEGaczXKPfWwoVTOf6hc15n0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRSX59N zZH5bPbuh1i1pCLBaEbv4zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMzA3MTgxODI0MTZaMA0GCSqGSIb3DQEBAQUABIIBAERKI7dWgOy7S4KPi6wGtKCs RgIuFhKVx5f7sph1ANXKcNslnkDKzsLOCKIPQx/VMhbIt0IC6e6L4WaZbeXHWI6LDlu3CEBJ q0AG04iIbqqmvf6eGVybQNzMjF1kMYawCfzTI2NQn290rJCVfqmu1VOxvifKzi+TA9HQPYkS qYr+8M4AElH251ZdJHwPKxLVJd/5Jp5k2FpP0syXuAAd/o9J3XYsVkK28P14oUE75PohBqFM oxjp5Rjh0vaQs8C6DmIjdeJ92yC6XnTKh1YZBKeQgMrXB+jfzKMDZJvTw/QMBspSFi3WQte3 o7h71BirMs6RE7quAsLBX6uTifnFlZ8= --B_3457002257_1312435-- From ian.farrer@telekom.de Fri Jul 19 04:08:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D015821F9AAE for ; Fri, 19 Jul 2013 04:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 AUhEmmHsEEhO for ; Fri, 19 Jul 2013 04:08:23 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id B2B8C21F9011 for ; Fri, 19 Jul 2013 04:08:19 -0700 (PDT) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 19 Jul 2013 13:08:17 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 19 Jul 2013 13:08:17 +0200 From: To: , Date: Fri, 19 Jul 2013 13:08:24 +0200 Thread-Topic: [Softwires] Changes to DHCP MAP Option draft Thread-Index: Ac6EcESIYTBNGzhATd2HQdjWogvGEQ== Message-ID: In-Reply-To: <51E70B41.8030000@ericsson.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 11:08:27 -0000 Hi Suresh / Yiu, >From my perspective, the new version of the MAP DHCP draft is very much aligned with the recent discussions that we've had in the SW & DHC workgroups. There's still a little fine tuning needed, but it's pretty close to what's been proposed in draft-ietf-softwire-unified-cpe and definitely a big step in the right direction. What I think the problem here is that we have had quite a lot of change within the SW workgroup and the corresponding active drafts across the last 6 months or so. The provisioning drafts are now being updated to reflect these changes. At the same time, the provisioning mechanisms are being updated and extended (e.g. DHCPv4overDHCPv6, dynamic v4 provisioning and probably others). In order to pull all of this together and to enable meaningful discussion, I suggest that there needs to be an overview of the relevant provisioning drafts, mechanisms, DHCP options and whatever else documented in one place so that we can take stock of how (and maybe if) all of this works together. If people agree that this is the right way forward, I'll volunteer to put this overview together. I would also ask for another volunteer to assist, though as I'm sure that I don't have the complete overview. If there's still space on the agenda for Berlin, then we can use this as the basis of the discussion. Cheers, Ian On 17/07/2013 23:23, "Suresh Krishnan" wrote: >Hi Yiu, > As Tomek said we discussed this a bit in Orlando. If you are concerned >about this, we can do a short call on the list and follow up at the >meeting to see if there are any objections in the wg. Does that work for >you? > >Thanks >Suresh > >On 07/15/2013 12:48 PM, Lee, Yiu wrote: >> Woj, >>=20 >> I am not objecting it. I just stated the new draft has been updated the >> scope w/o getting explicit consent from the ML. >>=20 >> BR, >> Yiu >>=20 >> From: Wojciech Dec > >> Date: Monday, July 15, 2013 12:01 PM >> To: "Yiu L. LEE" > > >> Cc: Softwires-wg > >> Subject: Re: [Softwires] Changes to DHCP MAP Option draft >>=20 >> Yes. See Mail of July 8. So far your objection is the only one, although >> I don't quite see in it any technically grounded objection. >> A fair bit of discussions between authors (MAP and lw46), softwire & dhc >> chairs, and WG participants have taken place, and naturally will also be >> held in Berlin. >>=20 >> Re-spinning draft versions is easy. >>=20 >>=20 >> On 15 July 2013 17:29, Lee, Yiu > > wrote: >>=20 >> Since this is a WG draft, did the authors ask the WG to update this? >> When the WG accepted this draft, it was only for MAP. But seems the >> scope has been changed. This should start as an Individual draft. I >> will recommend to revert back to the last version and present this >> in Berlin to replace the MAP draft if the WG agrees with it. >>=20 >>=20 >> From: Wojciech Dec >> >> Date: Thursday, July 11, 2013 10:43 AM >> To: Qi Sun > > >> Cc: Softwires-wg > >> Subject: Re: [Softwires] Changes to DHCP MAP Option draft >>=20 >>=20 >> Yes, there was a long thread started by Tomek. Given that the option >> is applicable beyond MAP a *suggestion* was to rename it. I'm >> personally ok either way. The "Softwire46" option is the currently >> proposed name. >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From mohamed.boucadair@orange.com Mon Jul 22 02:28:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5D21E8050 for ; Mon, 22 Jul 2013 02:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3atqansiw4qj for ; Mon, 22 Jul 2013 02:28:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 69AA021F99B0 for ; Mon, 22 Jul 2013 02:18:49 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A274C3B4BB8; Mon, 22 Jul 2013 11:18:42 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 82A2D4C024; Mon, 22 Jul 2013 11:18:42 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 22 Jul 2013 11:18:42 +0200 From: To: "ian.farrer@telekom.de" , "suresh.krishnan@ericsson.com" , "Yiu_Lee@Cable.Comcast.com" Date: Mon, 22 Jul 2013 11:18:40 +0200 Thread-Topic: [Softwires] Changes to DHCP MAP Option draft Thread-Index: Ac6EcESIYTBNGzhATd2HQdjWogvGEQCSrumQ Message-ID: <94C682931C08B048B7A8645303FDC9F36EE2DDBAF5@PUEXCB1B.nanterre.francetelecom.fr> References: <51E70B41.8030000@ericsson.com> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.22.74241 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Changes to DHCP MAP Option draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 09:28:20 -0000 Hi Ian, all, I agree with you the changes are in the good direction and are much complia= nt draft-ietf-softwire-unified-cpe.=20 IMHO, draft-ietf-softwire-map-dhcp is sufficient on its own to accommodate = softwire-related needs. I understand this is only my opinion and that the W= G may consider the companion dhc documents you mentioned as needed. In such= case, draft-ietf-softwire-unified-cpe should be the place to specify under= which conditions draft-ietf-softwire-map-dhcp or dhc I-Ds are to be follow= ed. Cheers, Med >-----Message d'origine----- >De=A0: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De l= a >part de ian.farrer@telekom.de >Envoy=E9=A0: vendredi 19 juillet 2013 13:08 >=C0=A0: suresh.krishnan@ericsson.com; Yiu_Lee@Cable.Comcast.com >Cc=A0: softwires@ietf.org >Objet=A0: Re: [Softwires] Changes to DHCP MAP Option draft > >Hi Suresh / Yiu, > >From my perspective, the new version of the MAP DHCP draft is very much >aligned with the recent discussions that we've had in the SW & DHC >workgroups. There's still a little fine tuning needed, but it's pretty >close to what's been proposed in draft-ietf-softwire-unified-cpe and >definitely a big step in the right direction. > >What I think the problem here is that we have had quite a lot of change >within the SW workgroup and the corresponding active drafts across the >last 6 months or so. The provisioning drafts are now being updated to >reflect these changes. At the same time, the provisioning mechanisms are >being updated and extended (e.g. DHCPv4overDHCPv6, dynamic v4 provisioning >and probably others). > >In order to pull all of this together and to enable meaningful discussion, >I suggest that there needs to be an overview of the relevant provisioning >drafts, mechanisms, DHCP options and whatever else documented in one place >so that we can take stock of how (and maybe if) all of this works together= . > >If people agree that this is the right way forward, I'll volunteer to put >this overview together. I would also ask for another volunteer to assist, >though as I'm sure that I don't have the complete overview. > >If there's still space on the agenda for Berlin, then we can use this as >the basis of the discussion. > >Cheers, >Ian > > > > >On 17/07/2013 23:23, "Suresh Krishnan" >wrote: > >>Hi Yiu, >> As Tomek said we discussed this a bit in Orlando. If you are concerned >>about this, we can do a short call on the list and follow up at the >>meeting to see if there are any objections in the wg. Does that work for >>you? >> >>Thanks >>Suresh >> >>On 07/15/2013 12:48 PM, Lee, Yiu wrote: >>> Woj, >>> >>> I am not objecting it. I just stated the new draft has been updated the >>> scope w/o getting explicit consent from the ML. >>> >>> BR, >>> Yiu >>> >>> From: Wojciech Dec > >>> Date: Monday, July 15, 2013 12:01 PM >>> To: "Yiu L. LEE" >> > >>> Cc: Softwires-wg > >>> Subject: Re: [Softwires] Changes to DHCP MAP Option draft >>> >>> Yes. See Mail of July 8. So far your objection is the only one, althoug= h >>> I don't quite see in it any technically grounded objection. >>> A fair bit of discussions between authors (MAP and lw46), softwire & dh= c >>> chairs, and WG participants have taken place, and naturally will also b= e >>> held in Berlin. >>> >>> Re-spinning draft versions is easy. >>> >>> >>> On 15 July 2013 17:29, Lee, Yiu >> > wrote: >>> >>> Since this is a WG draft, did the authors ask the WG to update this= ? >>> When the WG accepted this draft, it was only for MAP. But seems the >>> scope has been changed. This should start as an Individual draft. I >>> will recommend to revert back to the last version and present this >>> in Berlin to replace the MAP draft if the WG agrees with it. >>> >>> >>> From: Wojciech Dec >>> >>> Date: Thursday, July 11, 2013 10:43 AM >>> To: Qi Sun >> > >>> Cc: Softwires-wg > >>> Subject: Re: [Softwires] Changes to DHCP MAP Option draft >>> >>> >>> Yes, there was a long thread started by Tomek. Given that the optio= n >>> is applicable beyond MAP a *suggestion* was to rename it. I'm >>> personally ok either way. The "Softwire46" option is the currently >>> proposed name. >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From gnocuil@gmail.com Wed Jul 24 09:54:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CEA11E8115 for ; Wed, 24 Jul 2013 09:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 t8OMdkR6XLNZ for ; Wed, 24 Jul 2013 09:54:33 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 56FF111E80F9 for ; Wed, 24 Jul 2013 09:54:13 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so659110wgg.12 for ; Wed, 24 Jul 2013 09:54: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:from:date:message-id:subject:to :content-type; bh=nlos4ChhhWfyq/tsDqfqBDuvBNkX2+7j5FrxJy8msOQ=; b=XD6qMpInZBGl++tbCFzpyZI01SN7XGbhKOgpEoqzFlp5y3GpG/xdhjOQMPvJgEX/3k xZVI03f8O8UDrjKMTbJcvaO6Mk7PovW/xdYd/xjgfSVdYoJb2rpBaTXWVwoadxzIg6x4 o2CG6W48L36YL3AYooyOyDH2Y/7MxwzT3Fqyre1hAhlLCyZOJrHS761wg0nBApDmCRUf mFhgNbCmvr94JhdFhh19gSnZOIjYmxzl+w+IxuWLIIO6fw2u3qsJn4QITL+kaFhyxTlU wypYsh0RV3/ChGzJv3R6TKfUC+YRrrmXLW7n2EDxRqLtEv4LRWq/rlvAv+HlV88zhn88 wqhw== X-Received: by 10.194.58.11 with SMTP id m11mr27888939wjq.45.1374684851585; Wed, 24 Jul 2013 09:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.10.67 with HTTP; Wed, 24 Jul 2013 09:53:51 -0700 (PDT) In-Reply-To: <20130715145945.5655.80940.idtracker@ietfa.amsl.com> References: <20130715145945.5655.80940.idtracker@ietfa.amsl.com> From: Cong Liu Date: Thu, 25 Jul 2013 00:53:51 +0800 Message-ID: To: softwires@ietf.org Content-Type: multipart/alternative; boundary=047d7bacb8ea41c90c04e244c2dc Subject: [Softwires] Fwd: New Version Notification for draft-liu-softwire-lw4over6-dhcp-deployment-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, 24 Jul 2013 16:54:34 -0000 --047d7bacb8ea41c90c04e244c2dc Content-Type: text/plain; charset=ISO-8859-1 Dear all, We have published a new draft discussing how to deploy Lightweight 4over6 using DHCPv4-over-DHCPv6 as the provisioning protocol. Comments are welcome. Best Regards, Cong Liu ---------- Forwarded message ---------- From: Date: 2013/7/15 Subject: New Version Notification for draft-liu-softwire-lw4over6-dhcp-deployment-00.txt To: Qi Sun , Cong Liu A new version of I-D, draft-liu-softwire-lw4over6-dhcp-deployment-00.txt has been successfully submitted by Cong Liu and posted to the IETF repository. Filename: draft-liu-softwire-lw4over6-dhcp-deployment Revision: 00 Title: Lightweight 4over6 deployment with DHCPv4 over DHCPv6 Creation date: 2013-07-15 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-liu-softwire-lw4over6-dhcp-deployment-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-softwire-lw4over6-dhcp-deployment Htmlized: http://tools.ietf.org/html/draft-liu-softwire-lw4over6-dhcp-deployment-00 Abstract: Lightweight 4over6 is designed to support several dynamic provisioning protocols. This document discusses how to deploy Lightweight 4over6 using DHCPv4 over DHCPv6 as the provisioning protocol. The IETF Secretariat --047d7bacb8ea41c90c04e244c2dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

We have published a new draft discu= ssing how to deploy Lightweight 4over6 using DHCPv4-over-DHCPv6 as the prov= isioning protocol.=A0

Comments are welcome.

Best Regards,
Cong Liu


---------- Forwarded message ----------<= br>From: <internet-drafts@ietf.org>
Date: 2013/7/15
Subject: New Version Notification for draft-liu-softwire= -lw4over6-dhcp-deployment-00.txt
To: Qi Sun <sunqi@csnet1.cs.tsinghua.edu.cn>, Cong Li= u <gnocuil@gmail.com>



A new version of I-D, draft-liu-softwire-lw4over6-dhcp-deployment-00.txt has been successfully submitted by Cong Liu and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-liu-softwire-lw4over6-dhcp-deployment
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Lightweight 4over6 deployment with DHCPv4 over D= HCPv6
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 7
URL: =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.ietf.org/internet-drafts/draft-liu-softwire-lw4over6-dhcp-deployment= -00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-liu-softwire-lw4over6-dhcp-deployment
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-liu-softwire-lw4over6-dhcp-deployment-00


Abstract:
=A0 =A0Lightweight 4over6 is designed to support several dynamic
=A0 =A0provisioning protocols. =A0This document discusses how to deploy
=A0 =A0Lightweight 4over6 using DHCPv4 over DHCPv6 as the provisioning
=A0 =A0protocol.




The IETF Secretariat


--047d7bacb8ea41c90c04e244c2dc-- From gnocuil@gmail.com Wed Jul 24 10:27:23 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66BF11E8111 for ; Wed, 24 Jul 2013 10:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jAAo0D-9SYN5 for ; Wed, 24 Jul 2013 10:27:23 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9226911E8151 for ; Wed, 24 Jul 2013 10:27:22 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so749416wib.6 for ; Wed, 24 Jul 2013 10:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=xmHT5ABEJCNe2kBUrda3EUUFc/kaTTZ2PQzwQQnjWdQ=; b=noCTWjec0aWNKlsCS9zJyhKMdUthtHU6hmLAFzlyRSiWrWqS/CJOTPiU+uXFM/DC2t Bu2uepJtQkDxoPr9fcXW+Xg54iHWWfH2dHD9S+n1ihmXQOMA7ELfFV4jSl4WIcOmBL9f jEmTyBCvNVbP8xy5xUHdAw5Hvd8cc9MET53JgxdckOUnerkiDkr6cELHCDVfJXMUCsj1 RBztHRy8XS+nB+ag1/1ze8THTWKwKFhqha45yQ/zZEpLX8BGchUlB6lgs2LJQYFgVeL9 /S8/bfZHU0Q16vslzJiIJnxtH9yEKf7gbU/+MXFGVaIihYiSnr/nxK4UHFhZkMhBggnQ 1JxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=xmHT5ABEJCNe2kBUrda3EUUFc/kaTTZ2PQzwQQnjWdQ=; b=oN+kXEXKaUsjnJg+sszPA1n5d6uk6e7wHEfRnzvV3tRcLyIdRhRfCISdn49drt7u1M uswiA/uRWWf8E4ufPYx03RgY6qz2IZkPQPs4+0YKkBvp7LAHJjycM70W/RR1p8LPVTRf 50urgt4AJTEVvijeI4g+svYeRaYAXJZd0l/hBxV1LbRjk3Ye+E7ni0QhE1znra5MNAtj KmcwZmJLg37AovgMWE3lkm8X69jOsgsIuypghJwwJD3NiQOhyoCG8Qi4+TGBbLpiMQMj qsSpU3U6mqoPp/yE9rmgmNldgkCc0ZXGACEt0O/MIcysBopXb+E+5cUXDagO7mjKZuao o5SA== X-Received: by 10.180.206.70 with SMTP id lm6mr3437045wic.50.1374686841656; Wed, 24 Jul 2013 10:27:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.10.67 with HTTP; Wed, 24 Jul 2013 10:27:01 -0700 (PDT) In-Reply-To: <20130715191241.26257.24401.idtracker@ietfa.amsl.com> References: <20130715191241.26257.24401.idtracker@ietfa.amsl.com> From: Cong Liu Date: Thu, 25 Jul 2013 01:27:01 +0800 Message-ID: To: softwires Content-Type: multipart/alternative; boundary=001a11c265bedfdaec04e2453807 Subject: [Softwires] Fwd: New Version Notification for draft-lee-softwire-lw4over6-failover-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:27:24 -0000 --001a11c265bedfdaec04e2453807 Content-Type: text/plain; charset=ISO-8859-1 Dear all, This new draft discusses failover mechanism and considerations in Lightweight 4over6. Comments are welcome. Best Regards, Cong Liu ---------- Forwarded message ---------- From: Date: 2013/7/16 Subject: New Version Notification for draft-lee-softwire-lw4over6-failover-01.txt To: Cong Liu , "Yiu L. Lee" , Qiong Sun A new version of I-D, draft-lee-softwire-lw4over6-failover-01.txt has been successfully submitted by Yiu L. Lee and posted to the IETF repository. Filename: draft-lee-softwire-lw4over6-failover Revision: 01 Title: Simple Failover Mechanism for Lightweight 4over6 Creation date: 2013-07-15 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-lee-softwire-lw4over6-failover-01.txt Status: http://datatracker.ietf.org/doc/draft-lee-softwire-lw4over6-failover Htmlized: http://tools.ietf.org/html/draft-lee-softwire-lw4over6-failover-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-lee-softwire-lw4over6-failover-01 Abstract: This memo specifies a simple mechanism for Lightweight AFTR (lwAFTR) to notify Lightweight B4 (lwB4) to initiate the recreation of the binding when lwAFTR does not have the subscriber mapping in the mapping table. This often happens at failover the backup lwAFTR does not have the subscriber mapping information to process the packets between lwB4 and external IPv4 host. The IETF Secretariat --001a11c265bedfdaec04e2453807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

This new draft discusses failover m= echanism and considerations in Lightweight 4over6.

Comments are welcome.

Best Regards,
Cong Liu


---------- Forwarded message ----------<= br>From: <internet-drafts@ietf.org>
Date: 2013/7/16
Subject: New Version Notification for draft-lee-softwire= -lw4over6-failover-01.txt
To: Cong Liu <gnocuil@gmail.com>, "Yiu L. Lee" <yiu_lee@cable.comcast.com>, Qiong Su= n <sunqiong@ctbri.com.cn>= ;



A new version of I-D, draft-lee-softwire-lw4over6-failover-01.txt
has been successfully submitted by Yiu L. Lee and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-lee-softwire-lw4over6-failover
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Simple Failover Mechanism for Lightweight 4over6=
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 10
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/internet-drafts/draft-lee-softwire-lw4over6-failover-01.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.= org/doc/draft-lee-softwire-lw4over6-failover
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/d= raft-lee-softwire-lw4over6-failover-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.= org/rfcdiff?url2=3Ddraft-lee-softwire-lw4over6-failover-01

Abstract:
=A0 =A0This memo specifies a simple mechanism for Lightweight AFTR (lwAFTR)=
=A0 =A0to notify Lightweight B4 (lwB4) to initiate the recreation of the =A0 =A0binding when lwAFTR does not have the subscriber mapping in the
=A0 =A0mapping table. =A0This often happens at failover the backup lwAFTR d= oes
=A0 =A0not have the subscriber mapping information to process the packets =A0 =A0between lwB4 and external IPv4 host.





The IETF Secretariat


--001a11c265bedfdaec04e2453807-- From cuiyong@gmail.com Thu Jul 25 13:48:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A512921F90A7 for ; Thu, 25 Jul 2013 13:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 IKKM9Px5Mbwg for ; Thu, 25 Jul 2013 13:48:32 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 564E621F9339 for ; Thu, 25 Jul 2013 13:48:30 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id f8so2674601obp.3 for ; Thu, 25 Jul 2013 13:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Pb+o+QsOiLhFAEt00ipVgWJlXB3UN5CB89nxWIpOqKo=; b=0Ww+0uEIIatUOWm7DTyyWy32XZzqqqnDy1xFyQVqQABIqlOMsDCdJk9tPliXTyEOsG UV0RsB/N1dCTFQvkDhZpFpc8n+c7tA8sYUEfPZCEpYaByJqvnoTyw9DpElNqiOJNQLxW v7lsN7haQpwsJgOZxJQ7juQTRckEiqQmexA1fCTGPEOyh1Myp4hArXCU676gbZ5icwAV L0ZS9/pGGcRhoape1VK5OfVkjWFqxYNmLsf2lFPXAT/2zSTKKeVt7gzQJIvgmL6Ez1YW p4Cr9X1UsCE1Amsw6by6Xm58PZNmqIO1f2A+dzGTH/g+nCQ1VUKiIJAkb3wouO/BJefP kqug== MIME-Version: 1.0 X-Received: by 10.60.34.194 with SMTP id b2mr44084344oej.2.1374785309780; Thu, 25 Jul 2013 13:48:29 -0700 (PDT) Sender: cuiyong@gmail.com Received: by 10.182.52.166 with HTTP; Thu, 25 Jul 2013 13:48:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Jul 2013 04:48:29 +0800 X-Google-Sender-Auth: Z2HdAdYg0e9EYmFI8CrCRxkB4hU Message-ID: From: Yong Cui To: Softwires WG Content-Type: text/plain; charset=ISO-8859-1 Cc: Yong Cui Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 25 Jul 2013 20:48:32 -0000 Dear all, We have published our draft agenda on IETF website: https://datatracker.ietf.org/meeting/87/agenda/softwire/ Please send your slides by replying this email to Suresh and me by Sunday 9pm at the venue local time. Some of you may have already sent your slides, but you are encouraged to reply this email again in order to avoid that your original emails may be blocked by the email system:( Thanks, Yong & Suresh 2013/7/9 Yong Cui : > Hi folks, > > > We will have our Softwires session on Tuesday morning in the coming IETF > meeting in Berlin. > > If you would like to have a time slot, please reply this email and send your > request to Suresh and me in the following format by July 12 (Friday): > > (name, title, link to IETF datatracker, minutes requested). > > > Thanks, > > Yong & Suresh From leaf.yeh.sdo@gmail.com Fri Jul 26 01:14:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415E621F8411 for ; Fri, 26 Jul 2013 01:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjbx0gcPW74N for ; Fri, 26 Jul 2013 01:14:47 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 911FE21F8E70 for ; Fri, 26 Jul 2013 01:14:47 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so2982979pab.11 for ; Fri, 26 Jul 2013 01:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=dRLnccD+CKj6arXOKdTbNTa0bQQ84TykCxmEEhbBC9c=; b=sB7yOYE1nkibQTnTA5ma2i1B0E0By8XZztpMeW5PLnK7nHGj2W+MAXCCvS1R34/TjP WkHG1BpEI2eqAukx7Mx3cpLZV1QtfVBKPsWrOHRCiBj7FCGcHwTgBjK+XrNMqmcxgiK+ orEWS1i5AunLnjW3YIAsDQlYZCs37KjXFeRGm3SMmgp5mEh8WQcqrmEfAcxH0fSOBdSS jIPWAUjIfDgG/dSARG7lJC1V7lndRoLMmuklRTP284oBPWTc1mdEav0YuxZhUL8WdB0b 1jKQmwQiAnaN6sWqDaodk0sKu89agbwCQhCFneHg8LJFPjcn5c4T+vbcTxQaclEtcIIK St4Q== X-Received: by 10.68.1.226 with SMTP id 2mr51578916pbp.150.1374826486550; Fri, 26 Jul 2013 01:14:46 -0700 (PDT) Received: from PC ([114.248.234.99]) by mx.google.com with ESMTPSA id mr3sm58692418pbb.27.2013.07.26.01.14.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jul 2013 01:14:45 -0700 (PDT) From: "Leaf Yeh" To: "'Wojciech Dec'" References: <20130715165950.1249.20359.idtracker@ietfa.amsl.com> In-Reply-To: <20130715165950.1249.20359.idtracker@ietfa.amsl.com> Date: Fri, 26 Jul 2013 16:14:39 +0800 Message-ID: <51f22ff5.a37d440a.7e71.4ad2@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6BfOupy+UtbhjgTva8/Wi3cPhpTQIWeq+Q Content-Language: zh-cn Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 08:14:49 -0000 Woj, My cosign and address shall be: Leaf Y. Yeh Freelancer Technologies P. R. China Email: leaf.yeh.sdo@gmail.com which is the same as that @ https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/?include_t ext=1 Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, July 16, 2013 1:00 AM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients Author(s) : Tomasz Mrugalski Xiaohong Deng Ole Troan Congxiao Bao Wojciech Dec Freelancer Technologies Filename : draft-ietf-softwire-map-dhcp-04.txt Pages : 20 Date : 2013-07-15 Abstract: This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address+Port (A+P) for providing IPv4 connectivity across an IPv6 network, as specified by the IETF Softwires Working Group, including those where the IPv4 A+P parameters are optionally derived from the CE's IPv6 network prefix by algorithmic means. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-dhcp-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Sun Jul 28 23:00:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE321E8051; Sun, 28 Jul 2013 23:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 D4AVUfrAByrz; Sun, 28 Jul 2013 23:00:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 682DA11E80D3; Sun, 28 Jul 2013 23:00:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729060032.14489.55960.idtracker@ietfa.amsl.com> Date: Sun, 28 Jul 2013 23:00:32 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-10.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, 29 Jul 2013 06:00:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Public IPv4 over IPv6 Access Network Author(s) : Yong Cui Jianping Wu Peng Wu Olivier Vautrin Yiu L. Lee Filename : draft-ietf-softwire-public-4over6-10.txt Pages : 14 Date : 2013-07-28 Abstract: This document describes a mechanism called Public 4over6 which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments, but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows the Hub and Spoke softwire model, and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over IPv6 access network. The bi-directionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users, as well as maintaining IPv4- IPv6 address binding on the border relay. Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers, etc., while an operator makes the transition of the access network to an IPv6-only access network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-public-4over6-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cuiyong@gmail.com Mon Jul 29 03:01:55 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EFA21F9F08 for ; Mon, 29 Jul 2013 03:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 D5LBAcZBWOVf for ; Mon, 29 Jul 2013 03:01:54 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7C421F99E3 for ; Mon, 29 Jul 2013 03:01:50 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so12235297oah.25 for ; Mon, 29 Jul 2013 03:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vnQYT3w+0pQ+JZuK659uZuT63HWXazEwuUZmP/vgGHc=; b=OaI8O47TRSSjs0tcdF62450oEORNj2QC5GIISXi14fZ/CJ+oi8K5G0NSZwIB1DNXtw ONIVKjW0UKlHnKwvj0qkFyw2gej/83rwa9Z/Lw9JAcjNFc++sJAgQzrfWWywZ0q2zFGF Hex2G4rEmBXeCKXzLvRkx0e9JPAD/0cTd7amd1tGvm3Lr4YBTUQC3fdRo9Q0rTVJQJZb gmkHcgC6GfmFt9WiivaUnvSlmQmjYNqIv8w/OFJ/35fqaIeYjxpKqbTEwqiR2jelFxJC ZHWRYqHwy43m860b1sGGnC9ZGVLod1DvJYmcql1fXoZ2LTp7ZuofQOjTD/3Dy6tuXVqB iPsQ== MIME-Version: 1.0 X-Received: by 10.182.128.68 with SMTP id nm4mr17322231obb.56.1375092110192; Mon, 29 Jul 2013 03:01:50 -0700 (PDT) Sender: cuiyong@gmail.com Received: by 10.182.52.166 with HTTP; Mon, 29 Jul 2013 03:01:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 18:01:50 +0800 X-Google-Sender-Auth: imgoBEe_YJWHxw9sdxcPWo8v8Gs Message-ID: From: Yong Cui To: Softwires WG Content-Type: text/plain; charset=ISO-8859-1 Cc: Yong Cui Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 29 Jul 2013 10:01:55 -0000 Dear all, We still miss some of your slides. Presentation items are listed on the IETF website: https://datatracker.ietf.org/meeting/87/agenda/softwire/ Particularly, Wojciech Dec, Qiong Sun, Behcet Sarikaya and Hui Ni, would you please send your slides on items 04, 05, 09, 16 and 20 to us by 5pm Monday at IETF local time? Yong 2013/7/26 Yong Cui : > Dear all, > > We have published our draft agenda on IETF website: > https://datatracker.ietf.org/meeting/87/agenda/softwire/ > > Please send your slides by replying this email to Suresh and me by > Sunday 9pm at the venue local time. > > Some of you may have already sent your slides, but you are encouraged > to reply this email again in order to avoid that your original emails > may be blocked by the email system:( > > Thanks, > > Yong & Suresh > > > 2013/7/9 Yong Cui : >> Hi folks, >> >> >> We will have our Softwires session on Tuesday morning in the coming IETF >> meeting in Berlin. >> >> If you would like to have a time slot, please reply this email and send your >> request to Suresh and me in the following format by July 12 (Friday): >> >> (name, title, link to IETF datatracker, minutes requested). >> >> >> Thanks, >> >> Yong & Suresh From sunqi.csnet.thu@gmail.com Mon Jul 29 07:45:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFD021F99E2 for ; Mon, 29 Jul 2013 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 N5nMcDqe4FLV for ; Mon, 29 Jul 2013 07:45:29 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 99A7E21F995E for ; Mon, 29 Jul 2013 07:45:29 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id up15so4083688pbc.12 for ; Mon, 29 Jul 2013 07:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer; bh=7x7QNpzO3rp/gt5zh3UdgmR1MilAm9xyfBrx/V1mleg=; b=eqv5HaIUgldoyRxqAbmEIoctR5nn+9kXL9YUHoXO5hbYAk3iRKsuYTQVvcbM2cHa88 0UWQ1OiXBDo/vDEDXrQQobHsCcicfNvYUYdxev2HCHG5RIx+La66Zb16ZaeA5Wso686G KmZGhoaKekEjYjn2WHlEpDfPqMjOtpNbR8xDeD17jwFsE0wBeGEL8gR9xQai9XtWzyRD XiTf2zM4USEEJY34ESNDLMv/AVeruiFCH2zonUP+g0RuycLlhZxnZRwUX7avI7CP8rrm 6pzo6hOB/v4zVuxgpvdU6SbN7GM55EhxYUR/BZJU3zh42ujY2Ef5c4YgklMejYze3eEu M6og== X-Received: by 10.66.7.164 with SMTP id k4mr68570254paa.142.1375109129207; Mon, 29 Jul 2013 07:45:29 -0700 (PDT) Received: from ?IPv6:2001:df8::16:9284:dff:fef3:d346? ([2001:df8:0:16:9284:dff:fef3:d346]) by mx.google.com with ESMTPSA id xe9sm4753087pab.0.2013.07.29.07.45.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 07:45:28 -0700 (PDT) From: Qi Sun Content-Type: multipart/alternative; boundary=Apple-Mail-121--482554454 Date: Mon, 29 Jul 2013 16:45:20 +0200 Message-Id: To: draft-ietf-softwire-map-dhcp@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg WG Subject: [Softwires] comments on draft-ietf-softwire-map-dhcp-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 29 Jul 2013 14:45:30 -0000 --Apple-Mail-121--482554454 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear authors, I have some observations on the new map-dhcp draft: Sec 1, para 2 Networks with numerous CEs require dynamic configuration of these parameters on CEs, which forms the requirement for a dynamic provisioning mechanism using DHCPv6 [RFC3315] options that are the subject of this document. [Qi] The dynamic feature of DHCPv6 is for the management of IPv6 = address/prefix, rather than for that of IPv4 address/port-set. And the = subject of this document is, IMHO, assigning IPv4 address/port-set = across IPv6 network using DHCPv6 options. It's also not the DHCPv6 = server's job to dynamically manage the IPv4 address/port-set. sec 3, bullet 1: Key parameters of a BR include: i) The IPv4 Prefix - Used to derive the CE's IPv4 address; ii) The Embedded Address bit length - Used to derive how many, if any, of the CE's end-user IPv6 prefix are to be mapped to its IPv4 address and port-set. iii) The IPv6 prefix - used to scope the CE's IPv6 domain for the S46 service [Qi] All these are for MAP. What lw4o6 needs are IPv6 address/prefix, = IPv4 address and port set (optionally). The IPv6 address/prefix is = assigned through normal DHCPv6 process, not through the newly defined = option. So would it be helpful that we reflect that in this document? Sec 6, bullet 3: (0/0 IPv4 prefix) + (128 IPv6 prefix) =3D=3D> encapsulation mode (0/0 IPv4 prefix) + (shorter than 128 IPv6 prefix) =3D=3D> translation = mode [Qi] What happens if the length of the IPv4 prefix is zero, while the = content of IPv4 prefix is not 0.0.0.0? My suggestion is once the length of the IPv4 prefix is zero, the CE = SHOULD ignore the content of the IPv4 prefix.=20 Sec 4.6, bullet 4 o The presence of a OPTION_S46_BRULE option indicates to the CE that NAPT44 mode of operation is to be used, and the conveyed A+P parameters applied. [Qi] Does this mean no matter whether the CE is configured with a shared = IPv4 address, NAT44 mode will be used anyway? Sec 7: This type of DHCP server and configuration store deployment is recommended when the intent is to utilize full IPv4-IPv6 address independence of any given CE, by issuing unique options to each CE. [Qi] Port Parameters Option is actually a per-client option. This is = true no matter whether the full IPv4-IPv6 address independence is = needed. Length of PSID is a parameter shared by CEs in a domain. Maybe = we need to clarify that? More extensive than those possible by means of DHCPv6 in conjunction with the options in this document, should consider the use of DHCPv4 over IPv6 as specified in [I-D.ietf-dhc-dhcpv4-over-ipv6]. [Qi] I think there should be a reference to dhcpv4-over-dhcpv6. Nits: sec 1, para 2 responsible for forwarding between an IPv6 network domain and external public IPv4 network, =3D> an external public IPv4 network S46 Port Parameters Option=20 =3D> sub-option? Not sure OPTION_S46__PORTPARAMS =3D> OPTION_S46_PORTPARAMS Best Regards, Qi --Apple-Mail-121--482554454 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = authors,

I have some observations on the new = map-dhcp draft:


  parameters on CEs, which forms the = requirement for a dynamic
  provisioning mechanism using = DHCPv6 [RFC3315] = options that are the
   subject of this = document.

[Qi] The dynamic feature of DHCPv6 is for = the management of IPv6 address/prefix, rather than for that of IPv4 = address/port-set. And the subject of this document is, IMHO, assigning = IPv4 address/port-set across IPv6 network using DHCPv6 options. It's = also not the DHCPv6 server's job to dynamically manage the IPv4 = address/port-set.
sec 3, bullet 1:
      length - Used to = derive how many, if any, of the CE's end-user
      iii) The IPv6 prefix = - used to scope the CE's IPv6 domain for the
[Qi] All these are for = MAP. What lw4o6 needs are IPv6 address/prefix, IPv4 address and port set = (optionally). The IPv6 address/prefix is assigned through normal DHCPv6 = process, not through the newly defined option. So would it be helpful = that we reflect that in this document?

Sec 6, bullet = 3:
(0/0 IPv4 prefix) + (128 = IPv6 prefix) =3D=3D> encapsulation mode
(0/0 IPv4 prefix) + (shorter than 128 IPv6 prefix) =3D=3D> = translation mode
[Qi] What = happens if the length of the IPv4 prefix is zero, while the content of = IPv4 prefix is not 0.0.0.0?
My = suggestion is once the length of the IPv4 prefix is zero, the CE SHOULD = ignore the content of the IPv4 prefix. 

Sec 4.6, bullet 4
      parameters = applied.

[Qi] Does this mean no matter whether the = CE is configured with a shared IPv4 address, NAT44 mode will be used = anyway?

Sec 7:
   = independence of any given CE, by issuing unique options to each = CE.

[Qi] Port Parameters Option is actually a = per-client option. This is true no matter whether the full IPv4-IPv6 = address independence is needed. Length of PSID is a parameter shared by = CEs in a domain. Maybe we need to clarify that?

<= div style=3D"font-family: Arial; ">[Qi] I think there should be a = reference to dhcpv4-over-dhcpv6.
Nits:
sec 1, para 2
   IPv6 network domain and = external public IPv4 network,

S46 Port = Parameters Option 
=3D> = sub-option? Not sure

Best = Regards,
Qi
= --Apple-Mail-121--482554454-- From sureshk@juniper.net Mon Jul 29 14:51:07 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23521F9BC2; Mon, 29 Jul 2013 14:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.088 X-Spam-Level: * X-Spam-Status: No, score=1.088 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63OHZCMEyoi0; Mon, 29 Jul 2013 14:51:01 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 208D521F9A33; Mon, 29 Jul 2013 14:51:00 -0700 (PDT) Received: from mail11-db9-R.bigfish.com (10.174.16.233) by DB9EHSOBE003.bigfish.com (10.174.14.66) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 21:50:53 +0000 Received: from mail11-db9 (localhost [127.0.0.1]) by mail11-db9-R.bigfish.com (Postfix) with ESMTP id 387F7C0244; Mon, 29 Jul 2013 21:50:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I936eI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail11-db9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=sureshk@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail11-db9 (localhost.localdomain [127.0.0.1]) by mail11-db9 (MessageSwitch) id 1375134651736057_27537; Mon, 29 Jul 2013 21:50:51 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.246]) by mail11-db9.bigfish.com (Postfix) with ESMTP id ADEB7300046; Mon, 29 Jul 2013 21:50:51 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.53) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 21:50:50 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 14:50:48 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.3.146.0; Mon, 29 Jul 2013 14:50:48 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 15:03:46 -0700 Received: from mail18-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 21:50:46 +0000 Received: from mail18-tx2 (localhost [127.0.0.1]) by mail18-tx2-R.bigfish.com (Postfix) with ESMTP id 573091A0146; Mon, 29 Jul 2013 21:50:46 +0000 (UTC) Received: from mail18-tx2 (localhost.localdomain [127.0.0.1]) by mail18-tx2 (MessageSwitch) id 1375134574729543_20471; Mon, 29 Jul 2013 21:49:34 +0000 (UTC) Received: from TX2EHSMHS032.bigfish.com (unknown [10.9.14.239]) by mail18-tx2.bigfish.com (Postfix) with ESMTP id 270A14A0245; Mon, 29 Jul 2013 21:49:29 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS032.bigfish.com (10.9.99.132) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 21:49:29 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.249]) by BL2PRD0510HT002.namprd05.prod.outlook.com ([10.255.100.37]) with mapi id 14.16.0341.000; Mon, 29 Jul 2013 21:49:26 +0000 From: Suresh Kumar Vinapamula Venkata To: "pcp@ietf.org" , "softwires@ietf.org" Thread-Topic: New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-00.txt Thread-Index: AQHOjKV+DqnVR/+wNEag014aVhLhTA== Date: Mon, 29 Jul 2013 21:49:26 +0000 Message-ID: In-Reply-To: <20130729172759.6145.45952.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.100.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A39C33B7B41664C8709C7FC91113E39@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Softwires] FW: New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-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, 29 Jul 2013 21:51:08 -0000 Dear All,=20 We submitted a new draft that sketches a set of recommendations for the possible issues when B4 address changes. Suresh On 7/29/13 10:27 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-vinapamula-softwire-dslite-prefix-binding-00.txt >has been successfully submitted by Suresh Vinapamula and posted to the >IETF repository. > >Filename: draft-vinapamula-softwire-dslite-prefix-binding >Revision: 00 >Title: Recommendation for Prefix Binding in the Softwire DS-Lite Context >Creation date: 2013-07-29 >Group: Individual Submission >Number of pages: 5 >URL: =20 >http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-dslite-prefi >x-binding-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-prefix-bi >nding >Htmlized: =20 >http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix-binding >-00 > > >Abstract: > This document describes possible issues induced by the change of the > B4 IPv6 address and sketches a set of recommendations. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > From swmike@swm.pp.se Tue Jul 30 00:14:13 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEBF21F9371 for ; Tue, 30 Jul 2013 00:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8XZuon5nrYI for ; Tue, 30 Jul 2013 00:14:12 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 9F88D21F87B7 for ; Tue, 30 Jul 2013 00:14:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AB0269C; Tue, 30 Jul 2013 09:14:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9E8A09A; Tue, 30 Jul 2013 09:14:10 +0200 (CEST) Date: Tue, 30 Jul 2013 09:14:10 +0200 (CEST) From: Mikael Abrahamsson To: Yong Cui In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Softwires WG Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 07:14:13 -0000 On Tue, 9 Jul 2013, Yong Cui wrote: http://tools.ietf.org/wg/softwire/agenda?item=agenda-87-softwire.html -> http://tools.ietf.org/agenda/87/slides/slides-87-softwire-0.pdf The above link to the chair slides gives empty file, could you please look into that? -- Mikael Abrahamsson email: swmike@swm.pp.se From tomasz.mrugalski@gmail.com Tue Jul 30 00:29:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF3B21E80C2 for ; Tue, 30 Jul 2013 00:29:47 -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 Mh-ymJpJVvSy for ; Tue, 30 Jul 2013 00:29:47 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id E74DD11E8174 for ; Tue, 30 Jul 2013 00:29:44 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so2319318pbc.23 for ; Tue, 30 Jul 2013 00:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=lFG6ZtId9g/TXOLkV8Y+Y9lUxL/6plkbFI+wo3jC7k0=; b=i+HvvXsXjXP4Zp222AV2jjA+mRWJYN6Zod0BEHOuOk50wS64iHFPceOX68IZTA4itF ZucXSiO0YBmuue4M3AP2ThC4MPkntHJewvEeMV+XxKqHT+EJvZ5bUrZBecuJi9qasWAI Q6O8B5+fKTKay+rx84GRPrpyoFBEUujmum38ygOo5/VkjrXwkLPQKBRccMUv+DbYlnHE RBHZYZarg+2OhXlx9xJrZLQqIhC4JcX+d/cDt94kiflHoDU+vCLtJmvUNWc8aKnTM3yc bQr7Yj6FD/8KKajoWdX7AxGCElR3HtG3pLYCyLAB+ZlvQ7qw16nawDwfAcKJYLfLXS++ 67zQ== X-Received: by 10.66.221.2 with SMTP id qa2mr72929915pac.188.1375169384503; Tue, 30 Jul 2013 00:29:44 -0700 (PDT) Received: from dhcp-108b.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPSA id bg3sm81311369pbb.44.2013.07.30.00.29.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 00:29:43 -0700 (PDT) Message-ID: <51F76B65.7070504@gmail.com> Date: Tue, 30 Jul 2013 09:29:41 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Softwires-wg X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Softwires] Quick comment on draft-ietf-softwire-unified-cpe-01 presentation - DHCP option already defined X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 07:29:47 -0000 I just wanted to quickly comment on Simon's presentation. On slide 3, there was a question asked whether OPTION_MAP_BIND_DYN is needed to signal to the client whether DHCPv4-over-DHCPv6 should be enabled or not. That option is already defined. See section 6.2 of the dhcpv4-over-dhcpv6 drafts: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-01#section-6.2 A quick explanation - that option is defined as a top level option, not as a sub-option in MAP container. That's actually better. Although MAP and perhaps lw4over6 are primary use cases for DHCPv4-over-DHCPv6, the DHCPv4-over-DHCPv6 is really a generic purpose and can potentially be used in different deployment scenarios, so there's no need to tie it with MAP option. If you are interested, dhcpv4-over-dhcpv6 is going to be presented and discussed twice: Wednesday, July 31, 1620-1720 CEST (joint sunset4/dhc session) Thursday, August 1, 0900-1130 CEST (dhc) You are more than welcome to join in the discussion. Tomek From swmike@swm.pp.se Tue Jul 30 01:16:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281EE21F9B26 for ; Tue, 30 Jul 2013 01:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swz6qCdDDvoq for ; Tue, 30 Jul 2013 01:16:15 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7442921F9AFD for ; Tue, 30 Jul 2013 01:16:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9807E9E; Tue, 30 Jul 2013 10:16:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 85EB79A for ; Tue, 30 Jul 2013 10:16:14 +0200 (CEST) Date: Tue, 30 Jul 2013 10:16:14 +0200 (CEST) From: Mikael Abrahamsson To: softwires@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [Softwires] regarding discussion IETF87 tuesday regarding DHCP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 08:16:16 -0000 Hello. Just want to be sure a certain use case is covered by the current draft: I'm an ISP and I don't control CPEs. Customers buy them at local electronics store and plug the in. I want to support "all" (or subsetof) transition mechanisms for 4 over 6 and 6 over 4 etc. Customers might purchase devices that support 0 to all of these mechanisms. Is there anything in the current discussions about "unified cpe" that causes problems in the above scenario? I don't know if I understood correctly when I heard stuff about overloading options with slightly different meanings in different contexts? -- Mikael Abrahamsson email: swmike@swm.pp.se From cuiyong@gmail.com Tue Jul 30 03:05:08 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6299711E81C8 for ; Tue, 30 Jul 2013 03:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 botRomVPOzaW for ; Tue, 30 Jul 2013 03:05:06 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 23BC211E8144 for ; Tue, 30 Jul 2013 03:05:06 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so11600551obc.12 for ; Tue, 30 Jul 2013 03:05:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LW651JpCmKzDVdA9Evc/INBtu0vx5nEUiErbiWh0JZ8=; b=waYx8GhaaN6+ksrwhwaa8Z3eUYtOTmBqWsqkar8LEpZOHl6wZRWrvDnnowCyrD8alI tKfCFrEYRO5ggvdx5yjcJvZs9QgGvTA1h/UogSxbWOvXAZZ4zmfefbqnoEFfZkxFICM9 130iNz2kzRVKZRi8ju0Ve8ly9Z9LhwYERiXs4pnR9tC9oHA0OIBtQ0aQe4Col9XaC6Im zUqU/gooCILYBqm2oGlsU0Gaj2P6w2cHn0v+yAo2oeWWKztSRb+L+98+X6g9XtNkvUGs aO615fU6/5nGG6cj/Kk/ngkLMLGlHHG4JI/5fbghkQ+SwfkAB5luc/4HHYaWgP8kRB0S dxLQ== MIME-Version: 1.0 X-Received: by 10.60.92.102 with SMTP id cl6mr15366365oeb.90.1375178705654; Tue, 30 Jul 2013 03:05:05 -0700 (PDT) Sender: cuiyong@gmail.com Received: by 10.182.52.166 with HTTP; Tue, 30 Jul 2013 03:05:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 18:05:05 +0800 X-Google-Sender-Auth: gduf2jUE0o0cOubrORVFOFNEMG8 Message-ID: From: Yong Cui To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires WG Subject: Re: [Softwires] Call for agenda in IETF 87 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 10:05:08 -0000 Thanks for finding the bug:) I checked the slides at the following link on the datatracker yesterday and the .pptx slides are good. https://datatracker.ietf.org/meeting/87/materials.html But the tools page gave an empty file. I uploaded the .pdf file now and both sites work well. Yong 2013/7/30 Mikael Abrahamsson : > On Tue, 9 Jul 2013, Yong Cui wrote: > > http://tools.ietf.org/wg/softwire/agenda?item=agenda-87-softwire.html > > -> http://tools.ietf.org/agenda/87/slides/slides-87-softwire-0.pdf > > The above link to the chair slides gives empty file, could you please look > into that? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se From simon.perreault@viagenie.ca Tue Jul 30 03:37:41 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C73011E81D7 for ; Tue, 30 Jul 2013 03:37:41 -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 EeRGci5qK1Zz for ; Tue, 30 Jul 2013 03:37:40 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A81BE21F9B3F for ; Tue, 30 Jul 2013 03:37:40 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0677040428 for ; Tue, 30 Jul 2013 06:37:39 -0400 (EDT) Message-ID: <51F79773.70505@viagenie.ca> Date: Tue, 30 Jul 2013 12:37:39 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: <51F76B65.7070504@gmail.com> In-Reply-To: <51F76B65.7070504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Quick comment on draft-ietf-softwire-unified-cpe-01 presentation - DHCP option already defined X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 10:37:41 -0000 Le 2013-07-30 09:29, Tomek Mrugalski a écrit : > I just wanted to quickly comment on Simon's presentation. On slide 3, > there was a question asked whether OPTION_MAP_BIND_DYN is needed to > signal to the client whether DHCPv4-over-DHCPv6 should be enabled or not. > > That option is already defined. See section 6.2 of the > dhcpv4-over-dhcpv6 drafts: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-01#section-6.2 > > A quick explanation - that option is defined as a top level option, not > as a sub-option in MAP container. That's actually better. Although MAP > and perhaps lw4over6 are primary use cases for DHCPv4-over-DHCPv6, the > DHCPv4-over-DHCPv6 is really a generic purpose and can potentially be > used in different deployment scenarios, so there's no need to tie it > with MAP option. This makes *a lot* of sense. Unless the WG disagrees, it will be part of the next revision of unified-cpe. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Jul 30 03:43:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1AA21E8084 for ; Tue, 30 Jul 2013 03:43: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 9e0daV9dV44R for ; Tue, 30 Jul 2013 03:43:11 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 96E4821E8085 for ; Tue, 30 Jul 2013 03:43:08 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0E36146FC3 for ; Tue, 30 Jul 2013 06:43:07 -0400 (EDT) Message-ID: <51F798BB.8040800@viagenie.ca> Date: Tue, 30 Jul 2013 12:43:07 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] regarding discussion IETF87 tuesday regarding DHCP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 10:43:12 -0000 Le 2013-07-30 10:16, Mikael Abrahamsson a écrit : > Just want to be sure a certain use case is covered by the current draft: > > I'm an ISP and I don't control CPEs. Customers buy them at local > electronics store and plug the in. I want to support "all" (or subsetof) > transition mechanisms for 4 over 6 and 6 over 4 etc. Customers might > purchase devices that support 0 to all of these mechanisms. > > Is there anything in the current discussions about "unified cpe" that > causes problems in the above scenario? I don't know if I understood > correctly when I heard stuff about overloading options with slightly > different meanings in different contexts? I see three options: If OPTION_MAP_BIND doesn't exist: Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get to benefit from meshing if you support it. Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and another with EA-length=N. You get to benefit from meshing, but then we need to specify how CPEs are to handle multiple BRULEs. If OPTION_MAP_BIND exists: Option 3: Send OPTION_S46_BRULE with EA-length=N and OPTION_MAP_BIND. The current consensus, as I understand it, is for option 3. 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 swmike@swm.pp.se Tue Jul 30 04:17:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5332821F9EC2 for ; Tue, 30 Jul 2013 04:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTp+1jTFRcBM for ; Tue, 30 Jul 2013 04:17:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7DB11E8133 for ; Tue, 30 Jul 2013 04:17:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 15FEB9C; Tue, 30 Jul 2013 13:17:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 081B29A for ; Tue, 30 Jul 2013 13:17:34 +0200 (CEST) Date: Tue, 30 Jul 2013 13:17:34 +0200 (CEST) From: Mikael Abrahamsson To: softwires@ietf.org In-Reply-To: <51F798BB.8040800@viagenie.ca> Message-ID: References: <51F798BB.8040800@viagenie.ca> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Softwires] regarding discussion IETF87 tuesday regarding DHCP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 11:17:36 -0000 On Tue, 30 Jul 2013, Simon Perreault wrote: > I see three options: > > If OPTION_MAP_BIND doesn't exist: > > Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get to > benefit from meshing if you support it. > > Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and another with > EA-length=N. You get to benefit from meshing, but then we need to specify how > CPEs are to handle multiple BRULEs. > > If OPTION_MAP_BIND exists: > > Option 3: Send OPTION_S46_BRULE with EA-length=N and OPTION_MAP_BIND. > > The current consensus, as I understand it, is for option 3. So, I had some discussion regarding this over lunch, and I now think i have some more insight. So, I have a few problems with the current way this is supposed to be implemented. I would like to be able to support multiple transition mechanisms using a static dhcp server configuration file. For instance: If I add option 212 to DHCP server config and the client wants a 6RD relay, I give a static answer. If it wants something else, I have a static answer for it, tftp server, whatever. If it's not in the config file, I have no answer. Completely stateless and static, no logic needed. I would like to see DHCPv6 work the same way for this, regarding AFTRs. I would like to see separate AFTR requests for different types of AFTRs. Basically, the AFTR DHCP option should reflect what kind of AFTR is being handed out. I don't want to have a single AFTR handle all protocols (not in DHCP, not in real life), and I don't want magic depending on certain bits in the answer to find out what kind of AFTR should be handed out. Why can't we have the client ask for lw4over6 if it wants it, and ask for MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server trying to figure out through logic what the client might be asking for? Of course, people can implement logic if they want to (if client supports MAP-E, lw4over6 and $NEWFOO, just give it pw4over6), otherwise just answer with all things that is supported in the network. I would probably be good if there was some kind of preference figure in there as well with the options, so that the ISP can indicate preference to what mechanism should be used if there are multiple doing basically the same thing. This would (I think) address what Ted Lemon was saying that the current logic requirements is complicating the DHCPv6 server because it needs to have intelligence to figure out what response to give depending on what options are being asked for. Now it's possible to give out multiple answers at the same time if the client asks for it. -- Mikael Abrahamsson email: swmike@swm.pp.se From tomasz.mrugalski@gmail.com Tue Jul 30 04:44:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26E021F957B for ; Tue, 30 Jul 2013 04:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.039, 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 vgGFoRXP-Foh for ; Tue, 30 Jul 2013 04:44:29 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 93DEB21F842B for ; Tue, 30 Jul 2013 04:44:29 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so5885112pbc.4 for ; Tue, 30 Jul 2013 04:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=HdMBv41UdX879k/REzDrrGzE1KY7IvbHeu/I/gUSy1M=; b=pn3JE8paEdkaj+lZ8sj2lw/IDOafrFrftAg4lGcL9wYKuhq1FlLIgnaU/57mN6Gepb kkPKst2wgpXSd5u6rRL1BHhJCzAHfh3TymxVBdBTYGc/ZeP2YUwgAH8yDKE7V2BgjG2Z UP6gWnEXhpaFTtkdQy1lZmKKP6500TC1HlR9zZI2sKuQhB3mvKB8GFLSf1IQsR1D7Abn S97goptDvzs6Iy2Tpl3Yogenet4yyDKxZrXpTEBqmKmuC8Ix2m/K8UVNR19EoIJx+ZjA dBNTbcY/jT7H3bFWcLlQRanXjVDFOlKURgUdSb9H7v0WXUXM2HVFIQmafyvb1sPI+w/V ZlkQ== X-Received: by 10.66.154.1 with SMTP id vk1mr66902597pab.85.1375184668647; Tue, 30 Jul 2013 04:44:28 -0700 (PDT) Received: from dhcp-108b.meeting.ietf.org ([2001:df8:0:16:cabc:c8ff:fedf:daff]) by mx.google.com with ESMTPSA id xe9sm82620161pbc.21.2013.07.30.04.44.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 04:44:27 -0700 (PDT) Message-ID: <51F7A719.6030202@gmail.com> Date: Tue, 30 Jul 2013 13:44:25 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Softwires-wg X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:44:30 -0000 Here are some random comments about draft-ietf-softwire-map-dhcp-04 draft: 1. These are the original reasons for using MAP (now Softwire46) container: http://www.ietf.org/mail-archive/web/softwires/current/msg04701.html They can be summarized as: It was impossible to get a clear confirmation that only a single MAP domain will ever be configured on a given network. MAP design was fluctuating. Also, it is unclear what use cases may come out of Homenet, especially with regards to multiple provisioning domains. Keeping the S46 options in a separate container give us more likelihood of future compatibility with whatever may come our way (from Homenet, from MIF and multiple provisioning domains or somewhere else). As I said before, none of the arguments on its own is strong enough to warrant a container, but taking them all together they are convincing enough (in my personal option, with my dhc chair hat off) to go with a container. Having said all that, I do not object removing the container. 2. I brought the question on how to request sub-options in DHCPv6. It was discussed couple meetings ago in DHC session. The draft was named http://tools.ietf.org/id/draft-mrugalski-dhc-dhcpv6-suboptions-04.txt. The answer I got for the question "how to request sub-options in DHCPv6?" from DHC was "use regular, top level ORO". 3. If you look at the evolution of map-dhcp draft, it is somewhat worrying. There used to be an enum field that clearly specified the mode (at that time it was only MAP-E or MAP-T, but it was trivial to extend the enum list to cover other cases). That was removed as requested. Now the argument is being made that the CPE does not know which mode it should run. Even more, options are being split to provide the capability to differentiate between modes. 4. DHCPv6 server can discover DHCPv6 client's capabilities in two ways. The first and more obvious one is to draw conclusions from contents of ORO. The other one that is less common, but equally valid is to make the client send an option (note the difference: send an actual option, not option code in ORO). See rapid-commit option for example. If you choose to do that, I encourage you to read draft-ietf-dhc-option-guidelines, section 5.2 for a nice discussion how to use such an option. That's point is made with my dhc chair hat on. 5. Ian insisted on having a way to communicate that a certain CPE is able to support only EA-len 0. I suppose you could make the same argument about trimming down other capabilities in an arbitrary way to have a subset of MAP/lw4over6/whatever-else-you-want to make its implementation simpler. Perhaps it would be useful to have the capability to communicate CPE capability? Although not very popular, it is possible for clients to send options they are requesting from the server with values used as hints. See 4th paragraph in section 17.1.1 of RFC3315 for details. Classic example is a client that sends IA_NA option with IAADDRESS in it with preferred and valid lifetimes set to values the client would like to get. That gives the server the information about client's preference. However, it should be clear that those values are hints only. Server is certainly allowed to ignore them completely. On a practical side, support for such capability is available, but rather uncommon in existing implementations. Hope that helps, Tomek From simon.perreault@viagenie.ca Tue Jul 30 04:59:04 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFF421F9D55 for ; Tue, 30 Jul 2013 04:58:48 -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 hiGw2PwY80IP for ; Tue, 30 Jul 2013 04:58:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id EC66C21F9C2D for ; Tue, 30 Jul 2013 04:58:36 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2002::1004]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5016140428 for ; Tue, 30 Jul 2013 07:58:25 -0400 (EDT) Message-ID: <51F7AA5F.7000307@viagenie.ca> Date: Tue, 30 Jul 2013 13:58:23 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: <51F798BB.8040800@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] regarding discussion IETF87 tuesday regarding DHCP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 11:59:04 -0000 Le 2013-07-30 13:17, Mikael Abrahamsson a écrit : > On Tue, 30 Jul 2013, Simon Perreault wrote: > >> I see three options: >> >> If OPTION_MAP_BIND doesn't exist: >> >> Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get >> to benefit from meshing if you support it. >> >> Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and >> another with EA-length=N. You get to benefit from meshing, but then we >> need to specify how CPEs are to handle multiple BRULEs. >> >> If OPTION_MAP_BIND exists: >> >> Option 3: Send OPTION_S46_BRULE with EA-length=N and OPTION_MAP_BIND. >> >> The current consensus, as I understand it, is for option 3. > > So, I had some discussion regarding this over lunch, and I now think i > have some more insight. > > So, I have a few problems with the current way this is supposed to be > implemented. I would like to be able to support multiple transition > mechanisms using a static dhcp server configuration file. For instance: > > If I add option 212 to DHCP server config and the client wants a 6RD > relay, I give a static answer. If it wants something else, I have a > static answer for it, tftp server, whatever. If it's not in the config > file, I have no answer. Completely stateless and static, no logic needed. > > I would like to see DHCPv6 work the same way for this, regarding AFTRs. > I would like to see separate AFTR requests for different types of AFTRs. > Basically, the AFTR DHCP option should reflect what kind of AFTR is > being handed out. I don't want to have a single AFTR handle all > protocols (not in DHCP, not in real life), and I don't want magic > depending on certain bits in the answer to find out what kind of AFTR > should be handed out. > > Why can't we have the client ask for lw4over6 if it wants it, and ask > for MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server > trying to figure out through logic what the client might be asking for? > Of course, people can implement logic if they want to (if client > supports MAP-E, lw4over6 and $NEWFOO, just give it pw4over6), otherwise > just answer with all things that is supported in the network. I would > probably be good if there was some kind of preference figure in there as > well with the options, so that the ISP can indicate preference to what > mechanism should be used if there are multiple doing basically the same > thing. > > This would (I think) address what Ted Lemon was saying that the current > logic requirements is complicating the DHCPv6 server because it needs to > have intelligence to figure out what response to give depending on what > options are being asked for. Now it's possible to give out multiple > answers at the same time if the client asks for it. Totally agree. And I believe both options 2 and 3 above fulfill that requirement. 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 Ted.Lemon@nominum.com Tue Jul 30 05:09:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441DC11E81D9 for ; Tue, 30 Jul 2013 05:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muMgJhUMSeno for ; Tue, 30 Jul 2013 05:09:04 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id ADDF711E81E1 for ; Tue, 30 Jul 2013 05:08:58 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUfes2ln489ZJpw7s0qQ/1qHA71U8AN/I@postini.com; Tue, 30 Jul 2013 05:08:58 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0F9491B825B for ; Tue, 30 Jul 2013 05:08:58 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B7CFF190065; Tue, 30 Jul 2013 05:08:56 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 05:08:56 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [Softwires] Random comments about DHCP discussion Thread-Index: AQHOjRopHZIoTdkX1U+PJ/bV+9JIzJl9lkSA Date: Tue, 30 Jul 2013 12:08:56 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775236BA5@mbx-01.win.nominum.com> References: <51F7A719.6030202@gmail.com> In-Reply-To: <51F7A719.6030202@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <11876AE3BF786544ABF7ACE9981A112A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:09:12 -0000 On Jul 30, 2013, at 1:44 PM, Tomek Mrugalski w= rote: > 5. Ian insisted on having a way to communicate that a certain CPE is > able to support only EA-len 0. I suppose you could make the same > argument about trimming down other capabilities in an arbitrary way to > have a subset of MAP/lw4over6/whatever-else-you-want to make its > implementation simpler. I think you can infer that the client is willing to do DHCPv4-over-DHCPv6 b= y looking at the ORO to see if it requests the flag option that enables or = disables it. It may be that all the various partial implementations that = are possible can already be inferred from the ORO, but I agree that it is u= seful to be able to do this, given that we've agreed that partial implement= ations are expected to happen for ISP-specific deployments. Thanks for summarizing this. As you may have noticed, I missed the discus= sion about why we need to support multiple mappings. From bingxuere@gmail.com Tue Jul 30 06:33:41 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E23B11E81F7 for ; Tue, 30 Jul 2013 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19egu-6L2oAY for ; Tue, 30 Jul 2013 06:33:40 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2937611E81D9 for ; Tue, 30 Jul 2013 06:33:40 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id db10so4024231veb.28 for ; Tue, 30 Jul 2013 06:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3Y1qYh9P5gJFt7p5E6kCwyfr+SsYspN+AoaHlz32P6Y=; b=Iet9Dz0Jc+hbTdf3HyOftBJGfxCQfPMPjVPoWeFangyRZAmbEM9XNxn6MrrgN+QS1V Ej8bkzHtvijMdGKB4V6j945KBH4L8ZumgsZTmU5cHwT6YTbxPxRPXIgsHJaAnJhO76Ik LCRlUjfXHXDCYkOSMUepARM5CBPNEWSFCzC9HhZtuvX2WzhdPW1OW03CQ1hEbwAwavkB jCZj+RJuP/tGapQv0Xrd1cNCUoZncEVcDoKle5tRuAX7lixdjObrk+70VuDsEanXeqNJ RGX/JJz0lwmqOV2pIh281SJ+bBNnq/ZK0Ia80ipiUsqvOOCDuqwUDwI+I8gzqNqolEqQ hEpA== X-Received: by 10.220.249.67 with SMTP id mj3mr10023327vcb.23.1375191219589; Tue, 30 Jul 2013 06:33:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.66 with HTTP; Tue, 30 Jul 2013 06:32:59 -0700 (PDT) In-Reply-To: References: <51F798BB.8040800@viagenie.ca> From: Qiong Date: Tue, 30 Jul 2013 21:32:59 +0800 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=089e013a15e62457b204e2baa8d4 Cc: "softwires@ietf.org" Subject: Re: [Softwires] regarding discussion IETF87 tuesday regarding DHCP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 13:33:41 -0000 --089e013a15e62457b204e2baa8d4 Content-Type: text/plain; charset=UTF-8 Hi Mikael, Our I-D.sun-softwire-lw4over6-dhcpv6-00 is trying to solve it in this way, using a separate dhcpv6 option to request the FQDN of lwAFTR. So that the dhcpv6 server can tell whether it is a lw4over6 client or a ds-lite client. Best wishes Qiong On Tue, Jul 30, 2013 at 7:17 PM, Mikael Abrahamsson wrote: > On Tue, 30 Jul 2013, Simon Perreault wrote: > > I see three options: >> >> If OPTION_MAP_BIND doesn't exist: >> >> Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get to >> benefit from meshing if you support it. >> >> Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and another >> with EA-length=N. You get to benefit from meshing, but then we need to >> specify how CPEs are to handle multiple BRULEs. >> >> If OPTION_MAP_BIND exists: >> >> Option 3: Send OPTION_S46_BRULE with EA-length=N and OPTION_MAP_BIND. >> >> The current consensus, as I understand it, is for option 3. >> > > So, I had some discussion regarding this over lunch, and I now think i > have some more insight. > > So, I have a few problems with the current way this is supposed to be > implemented. I would like to be able to support multiple transition > mechanisms using a static dhcp server configuration file. For instance: > > If I add option 212 to DHCP server config and the client wants a 6RD > relay, I give a static answer. If it wants something else, I have a static > answer for it, tftp server, whatever. If it's not in the config file, I > have no answer. Completely stateless and static, no logic needed. > > I would like to see DHCPv6 work the same way for this, regarding AFTRs. I > would like to see separate AFTR requests for different types of AFTRs. > Basically, the AFTR DHCP option should reflect what kind of AFTR is being > handed out. I don't want to have a single AFTR handle all protocols (not in > DHCP, not in real life), and I don't want magic depending on certain bits > in the answer to find out what kind of AFTR should be handed out. > > Why can't we have the client ask for lw4over6 if it wants it, and ask for > MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server trying to > figure out through logic what the client might be asking for? Of course, > people can implement logic if they want to (if client supports MAP-E, > lw4over6 and $NEWFOO, just give it pw4over6), otherwise just answer with > all things that is supported in the network. I would probably be good if > there was some kind of preference figure in there as well with the options, > so that the ISP can indicate preference to what mechanism should be used if > there are multiple doing basically the same thing. > > This would (I think) address what Ted Lemon was saying that the current > logic requirements is complicating the DHCPv6 server because it needs to > have intelligence to figure out what response to give depending on what > options are being asked for. Now it's possible to give out multiple answers > at the same time if the client asks for it. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --089e013a15e62457b204e2baa8d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mikael,

Our I-D.sun-softwire-l= w4over6-dhcpv6-00 is trying to solve it in this way, using a separate dhcpv= 6 option to request the FQDN of lwAFTR. So that the dhcpv6 server can tell = whether it is a lw4over6 client or a ds-lite client.

Best wishes
Qiong



=
On Tue, Jul 30, 2013 at 7:17 PM, Mikael Abra= hamsson <swmike@swm.pp.se> wrote:
On Tue, 30 Jul 2013, Simon= Perreault wrote:

I see three options:

If OPTION_MAP_BIND doesn't exist:

Option 1: Send OPTION_S46_BRULE with EA-length =3D 0. But you don't get= to benefit from meshing if you support it.

Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=3D0, and another = with EA-length=3DN. You get to benefit from meshing, but then we need to sp= ecify how CPEs are to handle multiple BRULEs.

If OPTION_MAP_BIND exists:

Option 3: Send OPTION_S46_BRULE with EA-length=3DN and OPTION_MAP_BIND.

The current consensus, as I understand it, is for option 3.

So, I had some discussion regarding this over lunch, and I now think i have= some more insight.

So, I have a few problems with the current way this is supposed to be imple= mented. I would like to be able to support multiple transition mechanisms u= sing a static dhcp server configuration file. For instance:

If I add option 212 to DHCP server config and the client wants a 6RD relay,= I give a static answer. If it wants something else, I have a static answer= for it, tftp server, whatever. If it's not in the config file, I have = no answer. Completely stateless and static, no logic needed.

I would like to see DHCPv6 work the same way for this, regarding AFTRs. I w= ould like to see separate AFTR requests for different types of AFTRs. Basic= ally, the AFTR DHCP option should reflect what kind of AFTR is being handed= out. I don't want to have a single AFTR handle all protocols (not in D= HCP, not in real life), and I don't want magic depending on certain bit= s in the answer to find out what kind of AFTR should be handed out.

Why can't we have the client ask for lw4over6 if it wants it, and ask f= or MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server trying= to figure out through logic what the client might be asking for? Of course= , people can implement logic if they want to (if client supports MAP-E, lw4= over6 and $NEWFOO, just give it pw4over6), otherwise just answer with all t= hings that is supported in the network. I would probably be good if there w= as some kind of preference figure in there as well with the options, so tha= t the ISP can indicate preference to what mechanism should be used if there= are multiple doing basically the same thing.

This would (I think) address what Ted Lemon was saying that the current log= ic requirements is complicating the DHCPv6 server because it needs to have = intelligence to figure out what response to give depending on what options = are being asked for. Now it's possible to give out multiple answers at = the same time if the client asks for it.


--
Mikael Abrahamsson =C2=A0 =C2=A0email: swmike@swm.pp.se
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--089e013a15e62457b204e2baa8d4-- From sarikaya2012@gmail.com Tue Jul 30 07:25:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2904311E8107 for ; Tue, 30 Jul 2013 07:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 X0acTIZC3McK for ; Tue, 30 Jul 2013 07:25:14 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6121F9C8B for ; Tue, 30 Jul 2013 07:24:41 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id o7so3383283lbv.17 for ; Tue, 30 Jul 2013 07:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=hAPFLLZ9C0Z/6SUP05FMBQa8EsmfvT6XNWcte2TsW50=; b=jYflfuUpFRDbvCt2+S9MTxA0WkOZsl+eZARNWDSprZ4zafrb5NfQ4Y5Xy0iBmdq10r roke8PYY8dl9ztoq1Uv7DNXZ1odq1gcArnV5qfehPn2WPk6IPvzkRHnS//24Ifb3rF7W Nosfuv1NuW6/9vevzexVY0ItzTp4H7G8+CCiSURwIHdWFTim6r0DVZK6iufFf87Gi7C4 hdEweW960/rJX4n+/vRGo8SX08vjGmFT2k0jsH2XMznoYDS11KkvVy+EZuXWGEW7L8VZ MFdd1o0kGyJO+82GmdHAcF88RWOR36UCIBUvPDqv22ETSXTuyis/4Rpvdv8NwPJkRilI 4Upg== MIME-Version: 1.0 X-Received: by 10.152.21.131 with SMTP id v3mr29344790lae.50.1375194280769; Tue, 30 Jul 2013 07:24:40 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Tue, 30 Jul 2013 07:24:40 -0700 (PDT) Date: Tue, 30 Jul 2013 09:24:40 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: multipart/alternative; boundary=089e0158b6949a3e1504e2bb5eb4 Cc: Yong Cui Subject: [Softwires] Adopting 6rd and MAP Multicast Drafts X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:25:16 -0000 --089e0158b6949a3e1504e2bb5eb4 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Today in Softwire session there was not enough time for us to present our drafts on 6rd and MAP multicast support: http://tools.ietf.org/id/draft-sarikaya-softwire-6rdmulticast-05.txt and http://tools.ietf.org/id/draft-sarikaya-softwire-map-multicast-00.txt Both drafts are the only drafts presenting the solution and they are mature enough. Suresh recommended Cathy and myself to ask for support from the working group on these two drafts. We hereby ask the WG to support the adoption of these drafts. Thanks, Cathy and Behcet --089e0158b6949a3e1504e2bb5eb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

To= day in Softwire session there was not enough time for us to present our dra= fts on 6rd and MAP multicast support:
http://tools.ietf.org/id/dra= ft-sarikaya-softwire-6rdmulticast-05.txt
and
http://tools.ietf.org/id/draft-sarikaya-softwire-map-mu= lticast-00.txt

Both drafts are the only drafts presenting = the solution and they are mature enough.

Suresh recommended Cathy and myself to ask for support from the working= group on these two drafts.

We hereby ask the WG to support th= e adoption of these drafts.


Thanks,

Cathy and Behcet
--089e0158b6949a3e1504e2bb5eb4-- From wdec.ietf@gmail.com Tue Jul 30 08:10:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06B811E81D6 for ; Tue, 30 Jul 2013 08:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58+kAd2nXiHY for ; Tue, 30 Jul 2013 08:10:15 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9A21F84B1 for ; Tue, 30 Jul 2013 08:09:45 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p11so2682917pdj.4 for ; Tue, 30 Jul 2013 08:09:18 -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=DJkbmsf4E0zYC/Yqx1W3BTFb8tfyrNeTPOJmwWV3Lno=; b=scVyK2fMj5dCNZexT/FU9WrN8e7qGF+YGo2XkHW9pxI5xr0vLomTxGD5e8+um91ZnX DQ1qL6Q7/vKyM57OHUPP6/IMt9LKVxQF5lg9PF/JX8WUItyP1m2076eU/b/yo1MsCpMM Y1cKzOctcV7yrvIGbl4yEmD3ktL4lIEUoNa6CbBhBD7SrpOuigpbdwprs1r5MzTDDhmd oFHXAZSdeDJxpwXf9EMSQF44TfGqlrXcjcnZ9c0dmIhlKgO1YI5o6UUVlHk7bJW3UwV5 uJPNjFuTa2RrRhD6FoFYV9sXaEYAGddxzY4HUCvPkQ7WY2h1iJdjOhu3LaO13nFaowW7 0bwg== MIME-Version: 1.0 X-Received: by 10.66.219.38 with SMTP id pl6mr76369833pac.59.1375196958455; Tue, 30 Jul 2013 08:09:18 -0700 (PDT) Received: by 10.70.5.3 with HTTP; Tue, 30 Jul 2013 08:09:18 -0700 (PDT) In-Reply-To: <51F798BB.8040800@viagenie.ca> References: <51F798BB.8040800@viagenie.ca> Date: Tue, 30 Jul 2013 17:09:18 +0200 Message-ID: From: Wojciech Dec To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b5d611e34868f04e2bbfeaa Cc: Softwires-wg Subject: Re: [Softwires] regarding discussion IETF87 tuesday regarding DHCP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 15:10:17 -0000 --047d7b5d611e34868f04e2bbfeaa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, inline... On 30 July 2013 12:43, Simon Perreault wrote: > Le 2013-07-30 10:16, Mikael Abrahamsson a =E9crit : > > Just want to be sure a certain use case is covered by the current draft: >> >> I'm an ISP and I don't control CPEs. Customers buy them at local >> electronics store and plug the in. I want to support "all" (or subsetof) >> transition mechanisms for 4 over 6 and 6 over 4 etc. Customers might >> purchase devices that support 0 to all of these mechanisms. >> >> Is there anything in the current discussions about "unified cpe" that >> causes problems in the above scenario? I don't know if I understood >> correctly when I heard stuff about overloading options with slightly >> different meanings in different contexts? >> > > I see three options: > > If OPTION_MAP_BIND doesn't exist: > > Option 1: Send OPTION_S46_BRULE with EA-length =3D 0. But you don't get t= o > benefit from meshing if you support it. > > Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=3D0, and anothe= r > with EA-length=3DN. You get to benefit from meshing, but then we need to > specify how CPEs are to handle multiple BRULEs. > Woj> This is strictly speaking not correct, in terms of enabling meshing. To do that, one would send an FRULE with pretty much the same content as the BRULE. Multiple BRULES really come into the picture with CE's attached to "multiple domains" Regards, Woj. > > If OPTION_MAP_BIND exists: > > Option 3: Send OPTION_S46_BRULE with EA-length=3DN and OPTION_MAP_BIND. > > > The current consensus, as I understand it, is for option 3. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.**ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > --047d7b5d611e34868f04e2bbfeaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

inline...


On 30 July 2013 12:43, Simon Perreau= lt <simon.perreault@viagenie.ca> wrote:
Le 2013-07-30 10:16, Mikael Abrahamsson a = =E9crit :

Just want to be sure a certain use case is covered by the current draft:
I'm an ISP and I don't control CPEs. Customers buy them at local electronics store and plug the in. I want to support "all" (or su= bsetof)
transition mechanisms for 4 over 6 and 6 over 4 etc. Customers might
purchase devices that support 0 to all of these mechanisms.

Is there anything in the current discussions about "unified cpe" = that
causes problems in the above scenario? I don't know if I understood
correctly when I heard stuff about overloading options with slightly
different meanings in different contexts?

I see three options:

If OPTION_MAP_BIND doesn't exist:

Option 1: Send OPTION_S46_BRULE with EA-length =3D 0. But you don't get= to benefit from meshing if you support it.

Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=3D0, and another = with EA-length=3DN. You get to benefit from meshing, but then we need to sp= ecify how CPEs are to handle multiple BRULEs.

Woj> This is strictly speaking not correct, in terms of enabling me= shing. To do that, one would send an FRULE with pretty much the same conten= t as the BRULE.
Multiple BRULES=A0 really come into the pictu= re with CE's attached to "multiple domains"

Regards,
Woj.

If OPTION_MAP_BIND exists:

Option 3: Send OPTION_S46_BRULE with EA-length=3DN and OPTION_MAP_BIND.


The current consensus, as I understand it, is for option 3.

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

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

--047d7b5d611e34868f04e2bbfeaa-- From mark@townsley.net Tue Jul 30 09:07:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E5611E8219 for ; Tue, 30 Jul 2013 09:07:44 -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 5cCg0IdSwJzw for ; Tue, 30 Jul 2013 09:07:39 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4398E21F9DCA for ; Tue, 30 Jul 2013 09:05:10 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id mz10so1144291bkb.3 for ; Tue, 30 Jul 2013 09:05:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ezWKCDQ59teQeEIDxcsUZlr549ypT9UWCGK9IyPSZbs=; b=CdR5AaeVQjtRFwfeHdqWC68N3UCnqERengS3Hck0jD7iqOlbDvpjdl0usa9iRSQK1L 3js6K1TJvfepGyE8RGGQ4BJ9cj0XYWYDKJnnwYnmC8HI+cNDHtIEXhMrefnTlH4ggpiv LKi7A2HPsZBLtjDgaXloAPxcFrU8Oq296YWTHbdDJDAtloojUM4CLczPNevP4bvkTikW /Cy8TxAUhCgJnxNRyqBdA1qn0l5UCYuXbVdzTqfIWp/5PmCa/26FNr5d7UrRNSwAZNH2 yJzcoT1hyHOh/Eb1YM3mOET9elorOcJduTJBwml1aGjCsGgvYOlwwVK8g+p2gbMXi5Wj KjYw== X-Received: by 10.204.187.66 with SMTP id cv2mr5035835bkb.52.1375200307851; Tue, 30 Jul 2013 09:05:07 -0700 (PDT) Received: from [192.168.178.40] (p509987f7.dip0.t-ipconnect.de. [80.153.135.247]) by mx.google.com with ESMTPSA id g5sm17868592bkh.17.2013.07.30.09.05.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 09:05:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Tue, 30 Jul 2013 18:05:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9C821C4C-5B63-4815-9802-5EA39834F49E@townsley.net> References: <51F798BB.8040800@viagenie.ca> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkhVx3H2kpWmcymEv+RUhdI5/UyKh/TsvvKwxojACBb65aB69td8af2ISgEeU1sYL/PUS7+ Cc: softwires@ietf.org Subject: Re: [Softwires] regarding discussion IETF87 tuesday regarding DHCP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 16:07:44 -0000 Mikael, We discussed this in the hallway a bit, but I'll bring it to the list. The benefit of the "unified CPE" is not rooted in fewer DHCP options. = The real benefit is when there is a single feature for CPE vendors to = implement. The more feature fragmentation (our linksys folks called this = "splatter"), the less economy of scale, the greater cost, overall, to = everyone. With a single "unified" feature, there would be no need to = discover whether the CPE was LW46-only, MAP-E-only, or MAP-T-only, or = some other combination - It would always be all three, because they = would all be part of the same thing. Your DHCP options would then be = simple and static, and you would not have to match them up with the type = of CPE you had.=20 If the features we are talking about were dramatically different from = one another, this would of course be a waste of time. They aren't = though. =46rom DS-Lite to LW46 to MAP, all are really built up from the = same components. One breakdown being: 1. An tunnel encap type and destination: There are only two variants for = encap type, "T" or "E". One could imagine more, and this wouldn't be the = first tunneling protocol that had multiple ways of getting packets from = one end of a tunnel to another. 4rd might be representable as a = tunnel-type as well. 2. IPv4+Port to IPv6 binding/mapping: 6rd and "MAP" have what amounts to = "tunnel aggregation". As an analogy, think of a single-subscriber tunnel = (LW46) as a "hostroute tunnel", and a many-subscriber tunnel as a CIDR = prefix for a set of tunnels. What if you had an IP router that could = configure a /31 static route, but made you install a separate "hostroute = support" feature for a /32? You'd certainly be angry at your vendor ;-) 3. If you include "classic DS-Lite" in the unified feature, the final = component is which side of the tunnel the stateful NAPT lives. But, I = think that this ship has already sailed. Meaning, we will already be = asking CPE to support and maintain two separate 4/6 features. Asking = them to support 3 or more is suicide for retail CPE vendors, IPv6 = certification, etc.=20 If you assume there is truly *one* CPE function, you may have 110% of = the code for that vs. any single mode of operation, but you cover 300% = of the functionality! =46rom a protocol perspective, the WG is _very_ = close to being able to achieve this - and should be commended for it. = One final step here and the economies of scale win could be great.=20 If we don't take that step, we're not only setting ourselves up for a = much bigger fight getting this into CPE gear in a consistent manner = across the industry, we are likely wasting our time representing the = separate functions in shared DHCP options.=20 - Mark PS: the "tunnel hostroute" works in 6rd as well - if you configure a 6rd = CPE in the right way, it works as a point to point IP in IP tunnel to = Hurricane Electric.=20 On Jul 30, 2013, at 1:17 PM, Mikael Abrahamsson wrote: > On Tue, 30 Jul 2013, Simon Perreault wrote: >=20 >> I see three options: >>=20 >> If OPTION_MAP_BIND doesn't exist: >>=20 >> Option 1: Send OPTION_S46_BRULE with EA-length =3D 0. But you don't = get to benefit from meshing if you support it. >>=20 >> Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=3D0, and = another with EA-length=3DN. You get to benefit from meshing, but then we = need to specify how CPEs are to handle multiple BRULEs. >>=20 >> If OPTION_MAP_BIND exists: >>=20 >> Option 3: Send OPTION_S46_BRULE with EA-length=3DN and = OPTION_MAP_BIND. >>=20 >> The current consensus, as I understand it, is for option 3. >=20 > So, I had some discussion regarding this over lunch, and I now think i = have some more insight. >=20 > So, I have a few problems with the current way this is supposed to be = implemented. I would like to be able to support multiple transition = mechanisms using a static dhcp server configuration file. For instance: >=20 > If I add option 212 to DHCP server config and the client wants a 6RD = relay, I give a static answer. If it wants something else, I have a = static answer for it, tftp server, whatever. If it's not in the config = file, I have no answer. Completely stateless and static, no logic = needed. >=20 > I would like to see DHCPv6 work the same way for this, regarding = AFTRs. I would like to see separate AFTR requests for different types of = AFTRs. Basically, the AFTR DHCP option should reflect what kind of AFTR = is being handed out. I don't want to have a single AFTR handle all = protocols (not in DHCP, not in real life), and I don't want magic = depending on certain bits in the answer to find out what kind of AFTR = should be handed out. >=20 > Why can't we have the client ask for lw4over6 if it wants it, and ask = for MAP-E or MAP-T or whatever it wants, instead of the DHCPv6 server = trying to figure out through logic what the client might be asking for? = Of course, people can implement logic if they want to (if client = supports MAP-E, lw4over6 and $NEWFOO, just give it pw4over6), otherwise = just answer with all things that is supported in the network. I would = probably be good if there was some kind of preference figure in there as = well with the options, so that the ISP can indicate preference to what = mechanism should be used if there are multiple doing basically the same = thing. >=20 > This would (I think) address what Ted Lemon was saying that the = current logic requirements is complicating the DHCPv6 server because it = needs to have intelligence to figure out what response to give depending = on what options are being asked for. Now it's possible to give out = multiple answers at the same time if the client asks for it. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Tina.Tsou.Zouting@huawei.com Tue Jul 30 11:59:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61B21E80B7 for ; Tue, 30 Jul 2013 11: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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-yGEtY2uKTD for ; Tue, 30 Jul 2013 11:58:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4A621E8087 for ; Tue, 30 Jul 2013 11:58:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVO65023; Tue, 30 Jul 2013 18:58:52 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 19:58:42 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 19:58:35 +0100 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.217]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Tue, 30 Jul 2013 11:58:30 -0700 From: Tina TSOU To: "" Thread-Topic: [Softwires] Adopting 6rd and MAP Multicast Drafts Thread-Index: AQHOjTCnsQV0P8QWw0+ZfQxxrU4IYJl9ky0F Date: Tue, 30 Jul 2013 18:58:28 +0000 Message-ID: <2FEEDE52-3C39-4680-91A0-E8999840920B@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: multipart/alternative; boundary="_000_2FEEDE523C39468091A0E8999840920Bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires-wg , Yong Cui Subject: Re: [Softwires] Adopting 6rd and MAP Multicast Drafts X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2013 18:59:00 -0000 --_000_2FEEDE523C39468091A0E8999840920Bhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I support the adoption. Thank you, Tina On Jul 30, 2013, at 7:25 AM, "Behcet Sarikaya" > wrote: Hi all, Today in Softwire session there was not enough time for us to present our d= rafts on 6rd and MAP multicast support: http://tools.ietf.org/id/draft-sarikaya-softwire-6rdmulticast-05.txt and http://tools.ietf.org/id/draft-sarikaya-softwire-map-multicast-00.txt Both drafts are the only drafts presenting the solution and they are mature= enough. Suresh recommended Cathy and myself to ask for support from the working gro= up on these two drafts. We hereby ask the WG to support the adoption of these drafts. Thanks, Cathy and Behcet --_000_2FEEDE523C39468091A0E8999840920Bhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,
I support the adoption.

Thank you,
Tina

On Jul 30, 2013, at 7:25 AM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

Hi all,

Today in Softwire session there was not enough time for us to present our d= rafts on 6rd and MAP multicast support:
http://tools.ietf.org/id/draft-sarikaya-softwire-6rdmulticast-05.txt<= /a>
and
http://tools.ietf.org/id/draft-sarikaya-softwire-map-multicast-00.tx= t

Both drafts are the only drafts presenting the solution and they are mature= enough.

Suresh recommended Cathy and myself to ask for support from the working gro= up on these two drafts.

We hereby ask the WG to support the adoption of these drafts.


Thanks,

Cathy and Behcet
--_000_2FEEDE523C39468091A0E8999840920Bhuaweicom_-- From rajiva@cisco.com Tue Jul 30 13:17:07 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB39311E8117 for ; Tue, 30 Jul 2013 13:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAZ+7Yeuh9N9 for ; Tue, 30 Jul 2013 13:17:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6265111E80F6 for ; Tue, 30 Jul 2013 13:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4226; q=dns/txt; s=iport; t=1375215421; x=1376425021; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/tRVFrAUxnocVj+yaq37fVr7X5oy4iPOugzlOjrXwrk=; b=nJhzQSpC+ZhvmDoFPqKLAYLc2ucthmnWKrenkwJYTaZOvuP80doAGVHf bxAeWUfNWCDgWUuHpqB5karkT7JymT3iXpX2f5FWW8NpBVBTiMIWJRD8r SqlHqIkX5Q6aAdtnX8SOVK7AtR1A0Hg5z4mzEBKdixdx1kwOzO9MTPmeL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAM8e+FGtJXHB/2dsb2JhbABbgwY1vmiBHxZ0giQBAQEDAQEBATc0CwULAgEIDigQIQYLJQIEDgUJh3UDCQYMr3YNiF6NDYEoEYEFMwIFgxhxA5V2gWmBKYp9hSaDFIFx X-IronPort-AV: E=Sophos;i="4.89,781,1367971200"; d="scan'208";a="241467830" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2013 20:16:59 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6UKGwXp005900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 20:16:58 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.244]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 15:16:58 -0500 From: "Rajiv Asati (rajiva)" To: Tomek Mrugalski Thread-Topic: [Softwires] Random comments about DHCP discussion Thread-Index: AQHOjRorRwZeVGbONU6T2JBcD4/uEJl9qUcB Date: Tue, 30 Jul 2013 20:16:57 +0000 Message-ID: <31E009BB-61DF-4C95-9859-2A2F345E7837@cisco.com> References: <51F7A719.6030202@gmail.com> In-Reply-To: <51F7A719.6030202@gmail.com> Accept-Language: en-US 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 Cc: Softwires-wg Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 20:17:08 -0000 Tomek, > They can be summarized as: It was impossible to get a clear confirmation > that only a single MAP domain will ever be configured on a given > network.=20 I can confirm that a single MAP domain is not found to be sufficient in the= network for the deployment we have been involved in.=20 We are talking about of 100s of domains in the network.=20 Cheers, Rajiv Sent from my Phone On Jul 30, 2013, at 7:44 AM, "Tomek Mrugalski" = wrote: > Here are some random comments about draft-ietf-softwire-map-dhcp-04 > draft: >=20 > 1. These are the original reasons for using MAP (now Softwire46) > container: > http://www.ietf.org/mail-archive/web/softwires/current/msg04701.html >=20 > They can be summarized as: It was impossible to get a clear confirmation > that only a single MAP domain will ever be configured on a given > network. MAP design was fluctuating. Also, it is unclear what use cases > may come out of Homenet, especially with regards to multiple > provisioning domains. Keeping the S46 options in a separate container > give us more likelihood of future compatibility with whatever may come > our way (from Homenet, from MIF and multiple provisioning domains or > somewhere else). >=20 > As I said before, none of the arguments on its own is strong enough to > warrant a container, but taking them all together they are convincing > enough (in my personal option, with my dhc chair hat off) to go with a > container. Having said all that, I do not object removing the container. >=20 > 2. I brought the question on how to request sub-options in DHCPv6. It > was discussed couple meetings ago in DHC session. The draft was named > http://tools.ietf.org/id/draft-mrugalski-dhc-dhcpv6-suboptions-04.txt. > The answer I got for the question "how to request sub-options in > DHCPv6?" from DHC was "use regular, top level ORO". >=20 > 3. If you look at the evolution of map-dhcp draft, it is somewhat > worrying. There used to be an enum field that clearly specified the mode > (at that time it was only MAP-E or MAP-T, but it was trivial to extend > the enum list to cover other cases). That was removed as requested. Now > the argument is being made that the CPE does not know which mode it > should run. Even more, options are being split to provide the capability > to differentiate between modes. >=20 > 4. DHCPv6 server can discover DHCPv6 client's capabilities in two ways. > The first and more obvious one is to draw conclusions from contents of > ORO. The other one that is less common, but equally valid is to make the > client send an option (note the difference: send an actual option, not > option code in ORO). See rapid-commit option for example. If you choose > to do that, I encourage you to read draft-ietf-dhc-option-guidelines, > section 5.2 for a nice discussion how to use such an option. That's > point is made with my dhc chair hat on. >=20 > 5. Ian insisted on having a way to communicate that a certain CPE is > able to support only EA-len 0. I suppose you could make the same > argument about trimming down other capabilities in an arbitrary way to > have a subset of MAP/lw4over6/whatever-else-you-want to make its > implementation simpler. Perhaps it would be useful to have the > capability to communicate CPE capability? Although not very popular, it > is possible for clients to send options they are requesting from the > server with values used as hints. See 4th paragraph in section 17.1.1 of > RFC3315 for details. Classic example is a client that sends IA_NA option > with IAADDRESS in it with preferred and valid lifetimes set to values > the client would like to get. That gives the server the information > about client's preference. However, it should be clear that those values > are hints only. Server is certainly allowed to ignore them completely. > On a practical side, support for such capability is available, but > rather uncommon in existing implementations. >=20 > Hope that helps, > Tomek >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Wed Jul 31 02:06:45 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C021F99CD for ; Wed, 31 Jul 2013 02:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AlLm7-hv5PI for ; Wed, 31 Jul 2013 02:06:40 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7376521F9B5C for ; Wed, 31 Jul 2013 01:52:09 -0700 (PDT) Received: from dhcp-10-61-97-185.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id C46AB5F68; Wed, 31 Jul 2013 01:51:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51F7A719.6030202@gmail.com> Date: Wed, 31 Jul 2013 10:51:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27B082B8-C9BC-4B57-9B1B-389698B42815@employees.org> References: <51F7A719.6030202@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1508) Cc: Softwires-wg Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:06:45 -0000 Tomek, > Here are some random comments about draft-ietf-softwire-map-dhcp-04 > draft: >=20 > 1. These are the original reasons for using MAP (now Softwire46) > container: > http://www.ietf.org/mail-archive/web/softwires/current/msg04701.html >=20 > They can be summarized as: It was impossible to get a clear = confirmation > that only a single MAP domain will ever be configured on a given > network. MAP design was fluctuating. Also, it is unclear what use = cases > may come out of Homenet, especially with regards to multiple > provisioning domains. Keeping the S46 options in a separate container > give us more likelihood of future compatibility with whatever may come > our way (from Homenet, from MIF and multiple provisioning domains or > somewhere else). >=20 > As I said before, none of the arguments on its own is strong enough to > warrant a container, but taking them all together they are convincing > enough (in my personal option, with my dhc chair hat off) to go with a > container. Having said all that, I do not object removing the = container. the MAP specification explicitly allows for a MAP CE to belong to = multiple MAP domains. > 2. I brought the question on how to request sub-options in DHCPv6. It > was discussed couple meetings ago in DHC session. The draft was named > http://tools.ietf.org/id/draft-mrugalski-dhc-dhcpv6-suboptions-04.txt. > The answer I got for the question "how to request sub-options in > DHCPv6?" from DHC was "use regular, top level ORO". I think there should be a goal in designing this DHCP option _NOT_ to = require sub-option ORO requests. also see the discussion on "unified" CPE. if we require this I don't see = the point of having a single DHCP option. > 3. If you look at the evolution of map-dhcp draft, it is somewhat > worrying. There used to be an enum field that clearly specified the = mode > (at that time it was only MAP-E or MAP-T, but it was trivial to extend > the enum list to cover other cases). That was removed as requested. = Now > the argument is being made that the CPE does not know which mode it > should run. Even more, options are being split to provide the = capability > to differentiate between modes. right. if I understood Mark's email correctly, I think he made the point = that there shouldn't be modes. a unified CPE supports all. now, if we want to include mechanisms that = we have consensus on not putting on standards track in "unified", that I'm unsure about. > 4. DHCPv6 server can discover DHCPv6 client's capabilities in two = ways. > The first and more obvious one is to draw conclusions from contents of > ORO. The other one that is less common, but equally valid is to make = the > client send an option (note the difference: send an actual option, not > option code in ORO). See rapid-commit option for example. If you = choose > to do that, I encourage you to read draft-ietf-dhc-option-guidelines, > section 5.2 for a nice discussion how to use such an option. That's > point is made with my dhc chair hat on. I think it should be a design goal, that the DHCPv6 option can be = "static" and the same for all clients. MAP/LW46 has lots of capabilities. hub and spoke, mesh, shared IPv4 = address, full IPv4 address, IPv4 prefix, contiguous or non-contiguous port = spaces, encapsulation or translation, embedded address bits, or 1:1... I don't think negotiating these capabilities individually via DHCP is at = all a good idea. a general CPE confirming with the MAP/LW46 specifications must implement = all features. in a controlled environment, e.g. where the SP controls both CPE, BR and = provisioning, a CPE might only implement a subset. that's not something we need to cover in = the specs though. > 5. Ian insisted on having a way to communicate that a certain CPE is > able to support only EA-len 0. I suppose you could make the same > argument about trimming down other capabilities in an arbitrary way to > have a subset of MAP/lw4over6/whatever-else-you-want to make its > implementation simpler. Perhaps it would be useful to have the > capability to communicate CPE capability? Although not very popular, = it > is possible for clients to send options they are requesting from the > server with values used as hints. See 4th paragraph in section 17.1.1 = of > RFC3315 for details. Classic example is a client that sends IA_NA = option > with IAADDRESS in it with preferred and valid lifetimes set to values > the client would like to get. That gives the server the information > about client's preference. However, it should be clear that those = values > are hints only. Server is certainly allowed to ignore them completely. > On a practical side, support for such capability is available, but > rather uncommon in existing implementations. as stated above, I think we've lost if we end up with capabilities = negotiations. cheers, Ole= From Ted.Lemon@nominum.com Wed Jul 31 06:14:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62AC21F9B14 for ; Wed, 31 Jul 2013 06:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.533 X-Spam-Level: X-Spam-Status: No, score=-106.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1aGcQvu6AYA for ; Wed, 31 Jul 2013 06:14:23 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 1981521F9B0C for ; Wed, 31 Jul 2013 06:14:23 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUfkNrnYvQceUgueDNmcPk9MwvvoJMSRp@postini.com; Wed, 31 Jul 2013 06:14:23 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5EA271B813B for ; Wed, 31 Jul 2013 06:14:22 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0CDA6190065; Wed, 31 Jul 2013 06:14:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 06:14:15 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [Softwires] Random comments about DHCP discussion Thread-Index: AQHOjRopHZIoTdkX1U+PJ/bV+9JIzJl+8Y0AgABJSoA= Date: Wed, 31 Jul 2013 13:14:14 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077523A5BC@mbx-01.win.nominum.com> References: <51F7A719.6030202@gmail.com> <27B082B8-C9BC-4B57-9B1B-389698B42815@employees.org> In-Reply-To: <27B082B8-C9BC-4B57-9B1B-389698B42815@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:14:30 -0000 On Jul 31, 2013, at 10:51 AM, Ole Troan wrote: > I think there should be a goal in designing this DHCP option _NOT_ to req= uire sub-option ORO requests. > also see the discussion on "unified" CPE. if we require this I don't see = the point of having > a single DHCP option. I think it's fine to specify the encapsulated options in a top-level ORO. From ecordeiro@nic.br Wed Jul 31 06:59:51 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6550D21F8475 for ; Wed, 31 Jul 2013 06:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Hf7mOrtVLbig for ; Wed, 31 Jul 2013 06:59:49 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6681411E8192 for ; Wed, 31 Jul 2013 06:59:19 -0700 (PDT) Received: from dhcp-5682.meeting.ietf.org (dhcp-5682.meeting.ietf.org [130.129.86.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id C90C02080571 for ; Wed, 31 Jul 2013 10:58:53 -0300 (BRT) Message-ID: <51F9181B.7080809@nic.br> Date: Wed, 31 Jul 2013 15:58:51 +0200 From: Edwin Cordeiro User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "softwires@ietf.org WG" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Softwires] Next steps draft-cordeiro-softwire-experience-mapt-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, 31 Jul 2013 13:59:51 -0000 Hi all, As presented on the last softwires meeting, the testing made on MAP-T (draft-cordeiro-softwire-experience-mapt-01) network had problems with FTP (active), inbound ping (and inbound traffic for unsolicited connection) and traceroute. Also had limitations on bittorrent, as no incoming connections were possible. I'm willing to help anyone else who want to expand this test. My question to the wg is what is the next step for this draft. Should it be adopted by the working group? Does it need additional development? Thanks, Edwin From ecordeiro@nic.br Wed Jul 31 08:05:15 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969AC21F9C99 for ; Wed, 31 Jul 2013 08:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 i7loJxMnl+-G for ; Wed, 31 Jul 2013 08:05:15 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8D83F21F9D56 for ; Wed, 31 Jul 2013 08:05:14 -0700 (PDT) Received: from dhcp-5682.meeting.ietf.org (unknown [IPv6:2001:df8:0:80:700f:5cea:6804:27d8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 3BB8B20805D9 for ; Wed, 31 Jul 2013 12:05:12 -0300 (BRT) Message-ID: <51F927A5.8010104@nic.br> Date: Wed, 31 Jul 2013 17:05:09 +0200 From: Edwin Cordeiro User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------080909010007070306080906" Subject: Re: [Softwires] Call for adoption of draft-cai-softwire-6rd-mib-05 as wg draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:05:15 -0000 This is a multi-part message in MIME format. --------------080909010007070306080906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I reviewed this draft and support it's adoption. Some comments about it: - I believe there is a typo error: typed sixRdSecurityCeck instead of sixRdSecurityCheck all over the draft - In the introduction, shouldn't it be explicit that this same MIB supports both CPE and BR? Regards, Edwin Em 29/05/13 21:40, Lee, Yiu escreveu: > Support > > On 5/24/13 8:56 AM, "Yong Cui" wrote: > >> Hi all, >> >> This call is being initiated to determine whether there is WG >> consensus towards adoption of draft-cai-softwire-6rd-mib-05 as a >> softwire WG draft. >> >> Please state whether or not you're in favor of the adoption by replying >> to this email. If you are not in favor, please also state your objections >> in your response. >> >> The call will complete at midnight PDT on 2013-06-02. >> >> >> Regards >> Suresh & Yong >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires --------------080909010007070306080906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I reviewed this draft and support it's adoption.

Some comments about it:
- I believe there is a typo error: typed sixRdSecurityCeck instead of sixRdSecurityCheck all over the draft
- In the introduction, shouldn't it be explicit that this same MIB supports both CPE and BR?

Regards,
Edwin
Em 29/05/13 21:40, Lee, Yiu escreveu:
Support

On 5/24/13 8:56 AM, "Yong Cui" <cuiyong@tsinghua.edu.cn> wrote:


Hi all,

This call is being initiated to determine whether there is WG
consensus towards adoption of draft-cai-softwire-6rd-mib-05 as a
softwire WG draft.

Please state whether or not you're in favor of the adoption by replying
to this email. If you are not in favor, please also state your objections
in your response. 

The call will complete at midnight PDT on 2013-06-02.


Regards
Suresh & Yong

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



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

--------------080909010007070306080906-- From xiechf01@gmail.com Wed Jul 31 08:13:11 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0817721F9B5B for ; Wed, 31 Jul 2013 08:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5M+RkvyP2K5 for ; Wed, 31 Jul 2013 08:13:10 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 94C1921F9B53 for ; Wed, 31 Jul 2013 08:13:10 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id u10so781363pdi.8 for ; Wed, 31 Jul 2013 08:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type; bh=brtiBNrLzTxgTv5lTMVqeh1QjiVSorupNxMqzPJtcyQ=; b=tYke4O/jL5sVKqpnYUTAVncHYXFZtv/Sp5/9u4WoxjSnZIHXmymE9Bf34jN3eymT2i wSlUwbGTnx3F0eUx55ujW+M8ard2H9FkkKUdhLSQEdhXJL5HhApU8eKeFGC5h/f2dIJY 67/+Z57UF1mbxdVYzA+U3bzQSBearPRcVSvJbcQNWngY29SUlJH33JrfCqn5NC15fqt9 Fec+DSamJ3+gxHpaZyZ8n0iPEIRUJMmymzdHPGXUqB4PmI9a16aHIczi/Avfhm65cNOV N5n4HifD50cbUxdTkH3EMv0Xxxsvi5t0KhAWFMDv2pIxwEH8sq7Ca0rJY8jaNlQRJoyw f8Ew== X-Received: by 10.68.197.104 with SMTP id it8mr1023155pbc.17.1375283590332; Wed, 31 Jul 2013 08:13:10 -0700 (PDT) Received: from xiechf-PC2 (dhcp-10e1.meeting.ietf.org. [130.129.16.225]) by mx.google.com with ESMTPSA id sp4sm2671662pbc.45.2013.07.31.08.13.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 31 Jul 2013 08:13:09 -0700 (PDT) Date: Wed, 31 Jul 2013 17:13:03 +0200 From: "Chongfeng Xie" To: "Softwires WG" X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201307311713011039141@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart614257042120_=----" Subject: [Softwires] For comments about draft-sun-softwire-lightweigh-4over6-deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiechf01 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:13:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart614257042120_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCiBIaSwgYWxsLA0KICAgICAgICANCiAgICAgICAgRHVlIHRvIHRoZSB0aW1lIGxpbWl0IG9m IFNvZnR3aXJlIG1lZXRpbmcgb2YgVHVlc2RheSBtb3JuaW5nLCAgcHJlc2VudGF0aW9uIG9mICAi TGlnaHR3ZWlnaHQgNG92ZXI2IGRlcGxveW1lbnQiIGRpZG4ndCByZWNlaXZlIGFueSBjb21tZW50 cyBmcm9tIHRoZSBmbG9vci4gDQpTbyB3b3VsZCB5b3UgZ2l2ZSB1cyB5b3VyIGNvbW1lbnRzIGFi b3V0IHRoaXM/IFRoZSB3aG9sZSBkcmFmdCBjYW4gYmUgZm91bmQgYXQsIA0KDQogICAgICAgICAg ICAgICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zdW4tc29m dHdpcmUtbGlnaHR3ZWlnaC00b3ZlcjYtZGVwbG95bWVudC8NCg0KICAgICAgIFRoYW5rIHlvdSBm b3IgeW91ciBhdHRlbnRpb24hDQoNCiAgQ2hvbmdmZW5nIFhpZSAgIA== ------=_001_NextPart614257042120_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
 Hi, all,
        
      =20  Due to the time limit of Softwire = ;meeting of Tuesday morning, =20 presentation of  "Lightweight 4over6 deployment"&= nbsp;didn't receive any comments from the fl= oor. 
So would you give us your comments = ;about this? The whole draft can be fou= nd at, 
 
           &nb= sp;        =20  http://datatracker.ietf.org/doc/draft-sun-softwire-lightweigh-4over6= -deployment/
 
       Thank you for your=20 attention!
 
  Chongfeng Xie   
 
 
------=_001_NextPart614257042120_=------ From simon.perreault@viagenie.ca Wed Jul 31 10:27:03 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C458711E818F for ; Wed, 31 Jul 2013 10:27:03 -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 s4rD9nk3U35C for ; Wed, 31 Jul 2013 10:27:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A868411E8186 for ; Wed, 31 Jul 2013 10:27:02 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 21EC740415 for ; Wed, 31 Jul 2013 13:27:02 -0400 (EDT) Message-ID: <51F948E5.5070605@viagenie.ca> Date: Wed, 31 Jul 2013 19:27:01 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: softwires@ietf.org References: <51F7A719.6030202@gmail.com> <27B082B8-C9BC-4B57-9B1B-389698B42815@employees.org> In-Reply-To: <27B082B8-C9BC-4B57-9B1B-389698B42815@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:27:04 -0000 Le 2013-07-31 10:51, Ole Troan a écrit : > the MAP specification explicitly allows for a MAP CE to belong to multiple MAP domains. ...on a single interface? 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 otroan@employees.org Wed Jul 31 14:20:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D8D21F9EF5 for ; Wed, 31 Jul 2013 14:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqtGKSWYyxFu for ; Wed, 31 Jul 2013 14:20:33 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id DD2D621F9F44 for ; Wed, 31 Jul 2013 14:20:14 -0700 (PDT) Received: from dhcp-10-61-98-35.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 0ECF75F7F; Wed, 31 Jul 2013 14:20:12 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ole Troan In-Reply-To: <51F948E5.5070605@viagenie.ca> Date: Wed, 31 Jul 2013 23:20:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2FC3A650-FF8E-416B-ADB9-B3496C890159@employees.org> References: <51F7A719.6030202@gmail.com> <27B082B8-C9BC-4B57-9B1B-389698B42815@employees.org> <51F948E5.5070605@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1508) Cc: softwires@ietf.org Subject: Re: [Softwires] Random comments about DHCP discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 21:20:33 -0000 Simon, >> the MAP specification explicitly allows for a MAP CE to belong to = multiple MAP domains. >=20 > ...on a single interface? yes, and it would also require two separate IPv6 prefixes delegated to = the CE. the most obvious use case would be a renumbering event. cheers, Ole