From jacni@jacni.com Mon Jul 2 09:00:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DF121F854F for ; Mon, 2 Jul 2012 09:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDGVOPOzymW7 for ; Mon, 2 Jul 2012 09:00:29 -0700 (PDT) Received: from srv05.olivemail.cn (unknown [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 239E721F8713 for ; Mon, 2 Jul 2012 09:00:28 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 58A063801FA for ; Mon, 2 Jul 2012 12:00:33 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id BB77334008E for ; Tue, 3 Jul 2012 00:00:31 +0800 (CST) Received: from [10.79.100.40] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJC7TwKcxfFP69ALAA--.22331S2; Tue, 03 Jul 2012 00:00:30 +0800 (CST) Message-ID: <4FF1C59A.6020600@jacni.com> Date: Tue, 03 Jul 2012 00:00:26 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stig Venaas References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> <4FEBEA85.6010201@jacni.com> <4FEC9270.1050500@venaas.com> In-Reply-To: <4FEC9270.1050500@venaas.com> Content-Type: multipart/alternative; boundary="------------060304080703060403040408" X-CM-TRANSID: +AWowJC7TwKcxfFP69ALAA--.22331S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZw1Utw45uF45GFyDGFy8Xwb_yoWrCFyDpa y8Ka1Ygr1DAFW8Aw1kAw1rZa4YywsagrWUJ3s8GryDZa98Ga4DKr1Syw4YkryDWwn5ur4a qFsF9r98C3ZYy3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUU0bIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnWxYjsxI4VWkKwAYFVCjjxCrM7AEwI8IwI0E74AGY7Cv6cx26r4UM7CY 07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I 8E87Iv67AKxVWUJVW8JwACjcxG0xvEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY 0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrx kI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07j6wZcUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQETEko7lRfF-wBCsK Cc: Softwires-wg Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 16:00:30 -0000 This is a multi-part message in MIME format. --------------060304080703060403040408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stig, Inline please, On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote: > On 6/27/2012 10:24 PM, Jacni Qin wrote: >> Hi Stig, >> >> Thanks for you comments and support, please see below inline. >> >> On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote: >>> FWIW, here is my take on this. >>> >>> >>> On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: >>> [...] >>>> That's a big IF. Not everybody has to do it the same way. >>>> >>>> The solution in draft-ietf-softwire-dslite-multicast-02 >>>> builds itself something without considering what DS-Lite is doing. >>>> As I told you before, DS-Lite unicast is a tunneling technology. If >>>> you don't like it it is not DS-Lite multicast to fix this. >>>> How many times this should be reminded to you? >>> >>> draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing >>> specific to DS-Lite, and I've been saying that the draft should be >>> updated to reflect that. >>> >>> However, even though it is generic, I think it is a good solution for >>> use in DS-Lite deployments (in addition to many other deployments). >> As discussed in the previous messages of the thread, our motive is solve >> the problems >> for those who want multicast in their DS-Lite deployment. >> So we limited the scope. Where the DS-Lite is not deployed, it doesn't >> apply. > > I understand that the motive is to have a solution for DS-Lite, but IMO > the key part is the solution itself. I think you should focus on the > solution and then discuss how it can be used in several scenarios, where > DS-Lite is one of them. Yes, we're focusing on the solution itself, and there is a Problem Statement draft discussing several scenarios during the transition of multicast. ;-) > > Wouldn't it be a shame if people have a need for your solution, but are > not aware of it, or doesn't consider it because they think it only > applies to DS-Lite? > > Don't you agree that we should generally find good generic solutions and > describe them as such? We don't want to write basically identical docs > for each scenario. And in the worst case instead of having a single good > solution, having solutions that are only almost identical, maybe > requiring multiple slightly different implementations to solve each of > the problems, where a single solution and a single implementation would > be sufficient? > > As a general principle when you come up with a solution to a problem, > don't you try to see what else it can solve, and try to present it as > a solution to all the problems? At least that is always my thinking. I totally understand your point and logic. In addition to the motive, based on lessons learnt from what we did for unicast solutions, it's been concluded that working on the scenarios with high priority is a better choice. So we did that following the WG's charter. We ever know trying a single solution for all is not a good idea. And as mentioned above, I think the draft, http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00 will say clearly about the background, our choices, what led to this, and will help people to analyze their requirements/scenarios, then to find an appropriate solution. > > It looks like we may disagree on this. I'm hoping I can make people see > the merits of making general solutions and presenting them as such. At > least for me, that seems like a good thing to strive for. Ideally, I like general solutions as well. While for transition, as for unicast, I believe we should try another way. :-) > > I know I've been repeating myself several times in emails to the list. > I feel strongly about this as a general principle. I don't know what > more I can say to stress my point though. Thanks for your patience and the discussion anyway, it helps for the clarifications. Cheers, Jacni > > Stig > >> >> If some pieces of the approach can be reused in the future, to solve the >> multicast issues in >> other deployments, that'd be good. >> While personally, I'd prefer we stay focus on the currently scenario. >> Extensions if needed, may be raised respectively for other deployments. >> More are detailed in, >> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. >> >> >> Cheers, >> Jacni >>> >>> Whether additional solutions are needed for DS-Lite is something the >>> WG should consider. Maybe it already has, I haven't paid enough >>> attention. >>> >>> Stig >>> >> >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > > --------------060304080703060403040408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stig,

Inline please,
On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote:
On 6/27/2012 10:24 PM, Jacni Qin wrote:
Hi Stig,

Thanks for you comments and support, please see below inline.

On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote:
FWIW, here is my take on this.


On 6/27/2012 8:30 AM, Behcet Sarikaya wrote:
[...]
That's a big IF. Not everybody has to do it the same way.

The solution in draft-ietf-softwire-dslite-multicast-02
builds itself something without considering what DS-Lite is doing.
As I told you before, DS-Lite unicast is a tunneling technology. If
you don't like it it is not DS-Lite multicast to fix this.
How many times this should be reminded to you?

draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing
specific to DS-Lite, and I've been saying that the draft should be
updated to reflect that.

However, even though it is generic, I think it is a good solution for
use in DS-Lite deployments (in addition to many other deployments).
As discussed in the previous messages of the thread, our motive is solve
the problems
for those who want multicast in their DS-Lite deployment.
So we limited the scope. Where the DS-Lite is not deployed, it doesn't
apply.

I understand that the motive is to have a solution for DS-Lite, but IMO
the key part is the solution itself. I think you should focus on the
solution and then discuss how it can be used in several scenarios, where
DS-Lite is one of them.
Yes, we're focusing on the solution itself, and there is a Problem Statement draft
discussing several scenarios during the transition of multicast. ;-)


Wouldn't it be a shame if people have a need for your solution, but are
not aware of it, or doesn't consider it because they think it only
applies to DS-Lite?

Don't you agree that we should generally find good generic solutions and
describe them as such? We don't want to write basically identical docs
for each scenario. And in the worst case instead of having a single good
solution, having solutions that are only almost identical, maybe
requiring multiple slightly different implementations to solve each of
the problems, where a single solution and a single implementation would
be sufficient?

As a general principle when you come up with a solution to a problem,
don't you try to see what else it can solve, and try to present it as
a solution to all the problems? At least that is always my thinking.
I totally understand your point and logic.

In addition to the motive, based on lessons learnt from what we did for
unicast solutions, it's been concluded that working on the scenarios with
high priority is a better choice. So we did that following the WG's charter.

We ever know trying a single solution for all is not a good idea.
And as mentioned above, I think the draft, http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00
will say clearly about the background, our choices, what led to this, and will
help people to analyze their requirements/scenarios, then to find an appropriate solution.


It looks like we may disagree on this. I'm hoping I can make people see
the merits of making general solutions and presenting them as such. At
least for me, that seems like a good thing to strive for.
Ideally, I like general solutions as well. While for transition, as for unicast, I believe
we should try another way. :-)


I know I've been repeating myself several times in emails to the list.
I feel strongly about this as a general principle. I don't know what
more I can say to stress my point though.
Thanks for your patience and the discussion anyway, it helps for the clarifications.


Cheers,
Jacni


Stig


If some pieces of the approach can be reused in the future, to solve the
multicast issues in
other deployments, that'd be good.
While personally, I'd prefer we stay focus on the currently scenario.
Extensions if needed, may be raised respectively for other deployments.
More are detailed in,
http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00.


Cheers,
Jacni

Whether additional solutions are needed for DS-Lite is something the
WG should consider. Maybe it already has, I haven't paid enough
attention.

Stig





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







--------------060304080703060403040408-- From stig@venaas.com Mon Jul 2 10:58:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F0C11E80EA for ; Mon, 2 Jul 2012 10:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DuSerH9POwU for ; Mon, 2 Jul 2012 10:58:02 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 6632011E80EC for ; Mon, 2 Jul 2012 10:58:02 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id B17B47FD8; Mon, 2 Jul 2012 19:58:06 +0200 (CEST) Message-ID: <4FF1E111.9020201@venaas.com> Date: Mon, 02 Jul 2012 10:57:37 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jacni Qin References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> <4FEBEA85.6010201@jacni.com> <4FEC9270.1050500@venaas.com> <4FF1C59A.6020600@jacni.com> In-Reply-To: <4FF1C59A.6020600@jacni.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires-wg Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 17:58:03 -0000 Hi On 7/2/2012 9:00 AM, Jacni Qin wrote: > Hi Stig, > > Inline please, > > On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote: >> On 6/27/2012 10:24 PM, Jacni Qin wrote: >>> Hi Stig, >>> >>> Thanks for you comments and support, please see below inline. >>> >>> On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote: >>>> FWIW, here is my take on this. >>>> >>>> >>>> On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: >>>> [...] >>>>> That's a big IF. Not everybody has to do it the same way. >>>>> >>>>> The solution in draft-ietf-softwire-dslite-multicast-02 >>>>> builds itself something without considering what DS-Lite is doing. >>>>> As I told you before, DS-Lite unicast is a tunneling technology. If >>>>> you don't like it it is not DS-Lite multicast to fix this. >>>>> How many times this should be reminded to you? >>>> >>>> draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing >>>> specific to DS-Lite, and I've been saying that the draft should be >>>> updated to reflect that. >>>> >>>> However, even though it is generic, I think it is a good solution for >>>> use in DS-Lite deployments (in addition to many other deployments). >>> As discussed in the previous messages of the thread, our motive is solve >>> the problems >>> for those who want multicast in their DS-Lite deployment. >>> So we limited the scope. Where the DS-Lite is not deployed, it doesn't >>> apply. >> >> I understand that the motive is to have a solution for DS-Lite, but IMO >> the key part is the solution itself. I think you should focus on the >> solution and then discuss how it can be used in several scenarios, where >> DS-Lite is one of them. > Yes, we're focusing on the solution itself, and there is a Problem > Statement draft > discussing several scenarios during the transition of multicast. ;-) > >> >> Wouldn't it be a shame if people have a need for your solution, but are >> not aware of it, or doesn't consider it because they think it only >> applies to DS-Lite? >> >> Don't you agree that we should generally find good generic solutions and >> describe them as such? We don't want to write basically identical docs >> for each scenario. And in the worst case instead of having a single good >> solution, having solutions that are only almost identical, maybe >> requiring multiple slightly different implementations to solve each of >> the problems, where a single solution and a single implementation would >> be sufficient? >> >> As a general principle when you come up with a solution to a problem, >> don't you try to see what else it can solve, and try to present it as >> a solution to all the problems? At least that is always my thinking. > I totally understand your point and logic. > > In addition to the motive, based on lessons learnt from what we did for > unicast solutions, it's been concluded that working on the scenarios with > high priority is a better choice. So we did that following the WG's charter. I think you could make it more generic by changing the title, and minor changes to abstract/intro. You could say that this was designed to allow for multicast in DS-Lite, but that it also applies to other cases where you need to provide IPv4 multicast through an IPv6 multicast network or something like that. > We ever know trying a single solution for all is not a good idea. Yes, but your solution is more useful than just DS-Lite. You have no dependency of DS-Lite, right? Stig > And as mentioned above, I think the draft, > http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00 > will say clearly about the background, our choices, what led to this, > and will > help people to analyze their requirements/scenarios, then to find an > appropriate solution. > >> >> It looks like we may disagree on this. I'm hoping I can make people see >> the merits of making general solutions and presenting them as such. At >> least for me, that seems like a good thing to strive for. > Ideally, I like general solutions as well. While for transition, as for > unicast, I believe > we should try another way. :-) > >> >> I know I've been repeating myself several times in emails to the list. >> I feel strongly about this as a general principle. I don't know what >> more I can say to stress my point though. > Thanks for your patience and the discussion anyway, it helps for the > clarifications. > > > Cheers, > Jacni > >> >> Stig >> >>> >>> If some pieces of the approach can be reused in the future, to solve the >>> multicast issues in >>> other deployments, that'd be good. >>> While personally, I'd prefer we stay focus on the currently scenario. >>> Extensions if needed, may be raised respectively for other deployments. >>> More are detailed in, >>> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. >>> >>> >>> Cheers, >>> Jacni >>>> >>>> Whether additional solutions are needed for DS-Lite is something the >>>> WG should consider. Maybe it already has, I haven't paid enough >>>> attention. >>>> >>>> Stig >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >> >> > > From internet-drafts@ietf.org Mon Jul 2 18:08:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979D211E80F8; Mon, 2 Jul 2012 18:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Yz21Em4uo+S9; Mon, 2 Jul 2012 18:08:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0911E8080; Mon, 2 Jul 2012 18:08:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120703010853.25859.6916.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 18:08:53 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-mesh-mib-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 01:08:53 -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 Management Information Base(MIB) Author(s) : Yong Cui Jiang Dong Peng Wu Mingwei Xu Filename : draft-ietf-softwire-mesh-mib-00.txt Pages : 14 Date : 2012-07-01 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular it defines objects for managing softwire mesh [RFC5565]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-mesh-mib-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From despres.remi@laposte.net Wed Jul 4 08:04:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDE121F8819 for ; Wed, 4 Jul 2012 08:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5brO8mh7Ybjw for ; Wed, 4 Jul 2012 08:04:25 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id D82E821F8815 for ; Wed, 4 Jul 2012 08:04:24 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 73E4270001F9; Wed, 4 Jul 2012 17:04:34 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 448AB70001F4; Wed, 4 Jul 2012 17:04:33 +0200 (CEST) X-SFR-UUID: 20120704150434280.448AB70001F4@msfrf2413.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Jul 2012 17:04:29 +0200 Message-Id: <26638DBC-EB84-4850-886E-A4289DCFD4BD@laposte.net> To: "softwires@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Lorenzo Colitti Subject: [Softwires] TCP/IPv6 faster than TCP/IPv4/IPv6? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 04 Jul 2012 15:04:25 -0000 Hi all, There has been discussions, during IETF 83 and after, to warn that, in = some circumstances, direct TCP over IPv6 can be significantly faster = than TCP/IPv4/IPv6. A cc is sent to Lorenzo, because he privately reported some direct = knowledge of the subject (I personally have none). Although this is obviously relevant when comparing 4rd or MAP-T to = MAP-E, more data should IMHO be available on real facts before posting = an issue on the tracker.=20 Thanks to anyone who has information about this for sharing it. Regards, RD From tomasz.mrugalski@gmail.com Wed Jul 4 09:31:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC8F21F877D for ; Wed, 4 Jul 2012 09:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLnZdT7RDZ54 for ; Wed, 4 Jul 2012 09:31:21 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D58F821F8776 for ; Wed, 4 Jul 2012 09:31:20 -0700 (PDT) Received: by eekd4 with SMTP id d4so3211409eek.31 for ; Wed, 04 Jul 2012 09:31:31 -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=EKl5l2Za9KSIwKkUCWDkztm2x4+/OpBweaVUvfXMWRk=; b=kFg1GJhxweDMXkIq4CF45TbSDDpmwXavhK0E2VpgKuLPvsIph9frLV2Ij+fw0beSjV BRyodF7i0m6LabOZMrxMlLjbWTC5BClOfAt613Z4JvOUuTnu4tmC4fStKhAPTbkT4tN8 4cErG/Za56FEi4RRMrThQ7g1EYkDPRp2652lI3DlR/PSL8znHrHdB+pbGH2ARBep8tfy BnpbXAIClxHWMZSPlKjkCo4/dJvR7UycLnI31KwclmluB6kj6Od6UBSWX6A4tqaUpYAt fd9dMPHwipQPVy7oL4RTXaI4Pee2f7XflQ30FMB8cyi3Go7CAs3aLzw8gRnD0Zkr1yUl 4wbA== Received: by 10.14.47.3 with SMTP id s3mr5780608eeb.127.1341419491232; Wed, 04 Jul 2012 09:31:31 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:3536:f556:ac0f:5d9b? ([2001:470:6061:1:3536:f556:ac0f:5d9b]) by mx.google.com with ESMTPS id z5sm55493404eem.3.2012.07.04.09.31.30 (version=SSLv3 cipher=OTHER); Wed, 04 Jul 2012 09:31:30 -0700 (PDT) Message-ID: <4FF46FDE.8040506@gmail.com> Date: Wed, 04 Jul 2012 18:31:26 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Softwires-wg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Softwires] MAP-DHCP draft adoption? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 04 Jul 2012 16:31:21 -0000 Dear chairs, dear group, Some time after Paris it was decided that MAP should be adopted as a WG item. I assume that the general agreement is that this decision covers its companion document that specifies provisioning mechanism over DHCPv6 as well. After Paris meeting work on DHCPv6 options continued. Two authors left, one joined. There was some editorial and non-editorial changes. Many of those changes are a result of following main MAP draft. Others are DHCPv6 clarifications. A separate option for DMR was defined. Port parameters option was slightly modified. That updated version was just uploaded as draft-mdt-softwire-map-dhcp-option-03. You can use standard links to compare them, if you want to. It would be good to avoid hiccups similar to those encountered after -00 versions of ietf-softwire-map and ietf-softwire-4rd were posted. Taking this into consideration, I would like to ask the following: Which version should be uploaded as -00 WG document: the old one (-02, that was published in January) or the updated one (-03, with aforementioned changes)? I suppose that question is directed to chairs, but group's comments is welcome as well. If we decide to adopt -02, we will still need to do minor changes, namely removal of two authors who asked to be removed. All changes between -02 and -03 seems reasonable in authors' opinion, so we will be proposing to include them in future versions. If we decide to adopt -03, we will avoid extra work of going over all changes and getting them approved one by one. If any of the changes are considered controversial, we can remove them in the next revision if that is WG consensus. If you don't have any preference, I would recommend going with -03. Thanks in advance, Tomek From jmh@joelhalpern.com Wed Jul 4 10:40:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6956E21F8760 for ; Wed, 4 Jul 2012 10:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4m+dShGmDUf for ; Wed, 4 Jul 2012 10:40:30 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E638D21F86EB for ; Wed, 4 Jul 2012 10:40:30 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id B3F99558133 for ; Wed, 4 Jul 2012 10:40:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 2FBAD1C9BE5; Wed, 4 Jul 2012 10:40:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.105] (pool-71-161-51-217.clppva.btas.verizon.net [71.161.51.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 67FC31C076A; Wed, 4 Jul 2012 10:40:40 -0700 (PDT) Message-ID: <4FF4800D.3070806@joelhalpern.com> Date: Wed, 04 Jul 2012 13:40:29 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tomek Mrugalski References: <4FF46FDE.8040506@gmail.com> In-Reply-To: <4FF46FDE.8040506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires-wg Subject: Re: [Softwires] MAP-DHCP draft adoption? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 04 Jul 2012 17:40:31 -0000 In the IETF, a document being adopted by a working group does not generally imply that other related documents are adopted. There may be many reasons why the WG does not (or does) wish to do so. Each docoument is adopted when the chgairs, after consulting the working group, determine that it is adopted. Yours, Joel On 7/4/2012 12:31 PM, Tomek Mrugalski wrote: > Dear chairs, dear group, > > Some time after Paris it was decided that MAP should be adopted as a WG > item. I assume that the general agreement is that this decision covers > its companion document that specifies provisioning mechanism over DHCPv6 > as well. > > After Paris meeting work on DHCPv6 options continued. Two authors left, > one joined. There was some editorial and non-editorial changes. Many of > those changes are a result of following main MAP draft. Others are > DHCPv6 clarifications. A separate option for DMR was defined. Port > parameters option was slightly modified. That updated version was just > uploaded as draft-mdt-softwire-map-dhcp-option-03. You can use standard > links to compare them, if you want to. > > It would be good to avoid hiccups similar to those encountered after -00 > versions of ietf-softwire-map and ietf-softwire-4rd were posted. Taking > this into consideration, I would like to ask the following: > > Which version should be uploaded as -00 WG document: the old one (-02, > that was published in January) or the updated one (-03, with > aforementioned changes)? > > I suppose that question is directed to chairs, but group's comments is > welcome as well. > > If we decide to adopt -02, we will still need to do minor changes, > namely removal of two authors who asked to be removed. All changes > between -02 and -03 seems reasonable in authors' opinion, so we will be > proposing to include them in future versions. > > If we decide to adopt -03, we will avoid extra work of going over all > changes and getting them approved one by one. If any of the changes are > considered controversial, we can remove them in the next revision if > that is WG consensus. > > If you don't have any preference, I would recommend going with -03. > > Thanks in advance, > Tomek > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From achatz@forthnetgroup.gr Thu Jul 5 04:52:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2955721F869A; Thu, 5 Jul 2012 04:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kskOaffXs9KG; Thu, 5 Jul 2012 04:52:10 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4174421F869C; Thu, 5 Jul 2012 04:52:09 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65BqKOJ007796; Thu, 5 Jul 2012 14:52:20 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65BqKTL000812; Thu, 5 Jul 2012 14:52:20 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65BqKHj008550; Thu, 5 Jul 2012 14:52:20 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4FF57FF4.7010304@forthnetgroup.gr> Date: Thu, 05 Jul 2012 14:52:20 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: v6ops@ietf.org, softwires@ietf.org Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Softwires] DS-Lite & DNS X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 05 Jul 2012 11:52:11 -0000
Hi all,

I'm reading in RFC 6333:

 
5.5.  DNS

   A B4 element is only configured from the service provider with IPv6.
   As such, it can only learn the address of a DNS recursive server
   through DHCPv6 (or other similar method over IPv6).  As DHCPv6 only
   defines an option to get the IPv6 address of such a DNS recursive
   server, the B4 element cannot easily discover the IPv4 address of
   such a recursive DNS server, and as such will have to perform all DNS
   resolution over IPv6.

   The B4 element can pass this IPv6 address to downstream IPv6 nodes,
   but not to downstream IPv4 nodes.  As such, the B4 element SHOULD
   implement a DNS proxy, following the recommendations of [RFC5625].


6.4.  DNS

   As noted previously, a DS-Lite node implementing a B4 element will
   perform DNS resolution over IPv6.  As a result, DNS packets are not
   expected to go through the AFTR element.

What would be the expected behavior if i configure manually an IPv4 DNS server to a host attached to the CPE?
According to RFC5625:
 
Except when required to enforce an active security or network policy
   (such as maintaining a pre-authentication "walled garden"), end-users
   SHOULD be able to send their DNS queries to specified upstream
   resolvers, thereby bypassing the proxy altogether.  In this case, the
   gateway SHOULD NOT modify the DNS request or response packets in any
   way.

Does this mean that the 6.4 statement "DNS packets are not expected to go through the AFTR element." is not always valid?

Also, can draft-ietf-dhc-dhcpv4-over-ipv6 be considered an alternative option for passing IPv4 info to clients over IPv6 in DS-Lite networks?


 
--
Tassos
From arnaud.ongenae@alcatel-lucent.com Thu Jul 5 04:58:16 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE4021F861C for ; Thu, 5 Jul 2012 04:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 SgDpg57D8WV1 for ; Thu, 5 Jul 2012 04:58:16 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id BB4BD21F85A1 for ; Thu, 5 Jul 2012 04:58:15 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q65Bvqe5028904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 5 Jul 2012 13:58:26 +0200 Received: from [138.203.8.163] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Jul 2012 13:58:09 +0200 Message-ID: <4FF580D6.3020103@alcatel-lucent.com> Date: Thu, 5 Jul 2012 13:56:06 +0200 From: Arnaud Ongenae Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: References: <4FF57FF4.7010304@forthnetgroup.gr> In-Reply-To: <4FF57FF4.7010304@forthnetgroup.gr> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [Softwires] DS-Lite & DNS X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 05 Jul 2012 11:58:16 -0000 If you configure manually the DNS to use for example OpenDNS or Google, you'll go through the tunnel for every DNS request, you'll consume several of your udp sessions on the NAT. It will (must) work. IMHO, this configuration is outside the scope of this specification. Arnaud Ongenae QA Engineer IPD - Belgium On 07/05/2012 01:52 PM, Tassos Chatzithomaoglou wrote: > Does this mean that the 6.4 statement "DNS packets are not expected to > go through the AFTR element." is not always valid? From achatz@forthnetgroup.gr Thu Jul 5 06:06:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE121F869D; Thu, 5 Jul 2012 06:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAo9tK8sUdmQ; Thu, 5 Jul 2012 06:06:37 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id C40B421F8630; Thu, 5 Jul 2012 06:06:36 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65D6mkX019553; Thu, 5 Jul 2012 16:06:48 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65D6nDq016724; Thu, 5 Jul 2012 16:06:49 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65D6mL9025511; Thu, 5 Jul 2012 16:06:48 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4FF59168.3030600@forthnetgroup.gr> Date: Thu, 05 Jul 2012 16:06:48 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Wuyts Carl References: <4FF57FF4.7010304@forthnetgroup.gr> <867F4B6A1672E541A94676D556793ACD149FA79734@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD149FA79734@MOPESMBX01.eu.thmulti.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" , "v6ops@ietf.org" Subject: Re: [Softwires] [v6ops] DS-Lite & DNS X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 05 Jul 2012 13:06:38 -0000
Since i (as an operator) manage the CPE but not the host, i got a little bit worried and confused by the statement "DNS packets are not expected to go through the AFTR element", since the subscriber can easily send such packets.
So my understanding is that this is a supported scenario, but probably not a recommended one.

Wuyts Carl wrote on 05/07/2012 15:01:

HI,

 

First of all, assigning DNS info to host behind a CPE doesn’t look a scalable thing/solution to me, although possible of course.

Secondly, I think the issue stated in the RFC is on how to get DNS info to the CPE/hosts, rather than how the message flow is for DNS queries (v4/v6).

With a DNS Proxy, your DNs query, no matter A/AAA or v4/v6 transport, will be sent to the CPE which in its turn can forward it to its available DNS servers (which he potentially can get through different channels like PPP, DHCPv4 and v6, static,  …; for dslite solution it’ll be static or dhcpv6 most likely). 

In your use case, the host knows about the DNS server, so no need to pass the request through the CPE and ask to CPE to handle it, but just route the packet to its destination.  In this case, the question will be: does the CPE has a route to its destination ?  If so (e.g. default route to DSLite tunnel for v4 traffic) the packet will just be routed, if not, packet will be dropped.

 

regs

Carl

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tassos Chatzithomaoglou
Sent: donderdag 5 juli 2012 13:52
To: v6ops@ietf.org; softwires@ietf.org
Subject: [v6ops] DS-Lite & DNS

 


Hi all,

I'm reading in RFC 6333:

5.5.  DNS

 
   A B4 element is only configured from the service provider with IPv6.
   As such, it can only learn the address of a DNS recursive server
   through DHCPv6 (or other similar method over IPv6).  As DHCPv6 only
   defines an option to get the IPv6 address of such a DNS recursive
   server, the B4 element cannot easily discover the IPv4 address of
   such a recursive DNS server, and as such will have to perform all DNS
   resolution over IPv6.
 
   The B4 element can pass this IPv6 address to downstream IPv6 nodes,
   but not to downstream IPv4 nodes.  As such, the B4 element SHOULD
   implement a DNS proxy, following the recommendations of [RFC5625].
 

6.4.  DNS

 
   As noted previously, a DS-Lite node implementing a B4 element will
   perform DNS resolution over IPv6.  As a result, DNS packets are not
   expected to go through the AFTR element.
 


What would be the expected behavior if i configure manually an IPv4 DNS server to a host attached to the CPE?
According to RFC5625:

Except when required to enforce an active security or network policy
   (such as maintaining a pre-authentication "walled garden"), end-users
   SHOULD be able to send their DNS queries to specified upstream
   resolvers, thereby bypassing the proxy altogether.  In this case, the
   gateway SHOULD NOT modify the DNS request or response packets in any
   way.


Does this mean that the 6.4 statement "DNS packets are not expected to go through the AFTR element." is not always valid?

Also, can draft-ietf-dhc-dhcpv4-over-ipv6 be considered an alternative option for passing IPv4 info to clients over IPv6 in DS-Lite networks?



--
Tassos
 


From pacosaddress@gmail.com Thu Jul 5 07:28:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA121F85F8 for ; Thu, 5 Jul 2012 07:28:45 -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 BZ4kd6StMSOL for ; Thu, 5 Jul 2012 07:28:44 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8A67421F86C2 for ; Thu, 5 Jul 2012 07:28:44 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so5214988wib.13 for ; Thu, 05 Jul 2012 07:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2q/bD65p8mOkok2LKuYFaXYVXlwEHU/Q3+AHr+S4yPY=; b=D7yqBKsRveEQ2qcYG+aRjTPiQ84RfwhuNrf64zMU7Cuc4uom9YRw/26WXg6HzhFkZB lCllOmsdj+uFwFiIvM8oln2Hw0huU3AOFTVvModPbMulzuSKuyadY5DtnMoBzRf3h9TT 33hYZ/uh1eO40858/fQ/zoKGpcYyeiGYP7NZCKn1q96JERNZNEoa9sDUVoQWLmfrwihB qPVJ7hzvrIbC6B57wOztg9ZQmZq0Mh+6S4ONU0sVGdPsVubmxQe5S5r7nCuOcIBWkDeP A3R3je6p5vGTC5jrc0EzNt91GK3Q+bBaSMrI+bDxMSDT45oacr3818VSwdmHwY6+2+1V cEuQ== MIME-Version: 1.0 Received: by 10.216.139.196 with SMTP id c46mr8604126wej.220.1341498537393; Thu, 05 Jul 2012 07:28:57 -0700 (PDT) Received: by 10.223.60.8 with HTTP; Thu, 5 Jul 2012 07:28:57 -0700 (PDT) In-Reply-To: <20120628101408.21739.10988.idtracker@ietfa.amsl.com> References: <20120628101408.21739.10988.idtracker@ietfa.amsl.com> Date: Thu, 5 Jul 2012 16:28:57 +0200 Message-ID: From: Paco Cortes To: ot@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 14:28:45 -0000 Hi Ole, I've some comments on draft-ietf-softwire-map-01.txt: 1) Section 5, bullet 3 "Default Mapping Rule". Is there a reason to preclude the usage of more than one Mapping Rule for destinations outside the MAP domain? I would consider desirable that a network provider is able to use different BRs for routing optimization. Example: - one/several BRs for legacy IPv4 services provided by the operator (IPTV, ... using IPv4 prefixes owned by the operator) - one/several towards transit ISPs 2) Section 5.1.1, last sentence It says "For a=0, j MAY be 0 to allow...." But if j would be different from 0, then the factor "R * M * j" in the port number equation in section 5.1 bullet 1 would be a multiple from 65536. As a result, the port number would be invalid if no "modulos 65536" is used, or it would be fully equivalent to j=0 if modulos is used. In the previous sentence you also say that "j larger than 0" ensures excluding the system ports. This is not stricly true as it depends on "a" being less than 7. You should rethink the whole paragraph, and also if you want to mandate that system ports are always excluded (implying a minimum value for "a" and a minimum value for "A"), or if you want to allow for them being also provisioning, what would require some other "MAYs". 4) Section 5.1.2, first sentence. I would recommend that yo put the PSID length k within parenthesis as you do with the second example a few lines below. It would remark that given R=1024 and a=4, then PSID length is derived from it (namely log2(R)). 5) Section 5.2, 2nd last sentence above Figure 4. It says "A MAP node MUST reserve the first IPv6 prefix in a End-user IPv6 prefix for the purpose of MAP". I find confusing speaking about "the first prefix in a prefix". Should it rather say "A MAP node MUST reserve the prefix using this first subnet for the purpose of MAP"? (or similar like "....using the MAP subnet ID...". Best regards, Paco 2012/6/28 : > > 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 : Mapping of Address and Port (MAP) > Author(s) : Ole Troan > Wojciech Dec > Xing Li > Congxiao Bao > Yu Zhai > Satoru Matsushima > Tetsuya Murakami > Filename : draft-ietf-softwire-map-01.txt > Pages : 33 > Date : 2012-06-28 > > Abstract: > This document describes a mechanism for transporting IPv4 packets > across an IPv6 network, and a generic mechanism for mapping between > IPv6 addresses and IPv4 addresses and transport layer ports. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-map-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-01 > > > 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 yiu_lee@cable.comcast.com Thu Jul 5 09:26:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F1B21F870F; Thu, 5 Jul 2012 09:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.272 X-Spam-Level: X-Spam-Status: No, score=-103.272 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPl9hoVI4aEc; Thu, 5 Jul 2012 09:26:47 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21121F8703; Thu, 5 Jul 2012 09:26:47 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.23912679; Thu, 05 Jul 2012 10:09:09 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0309.002; Thu, 5 Jul 2012 12:26:44 -0400 From: "Lee, Yiu" Thread-Topic: [Softwires] [v6ops] DS-Lite & DNS Thread-Index: AQHNWsr3bLQq679MMUCPWZ0Id4LKKQ== Date: Thu, 5 Jul 2012 16:26:44 +0000 Message-ID: In-Reply-To: <4FF59168.3030600@forthnetgroup.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3424336003_9715749" MIME-Version: 1.0 To: Tassos Chatzithomaoglou , Wuyts Carl Cc: "softwires@ietf.org" , "v6ops@ietf.org" Subject: Re: [Softwires] [v6ops] DS-Lite & DNS X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 05 Jul 2012 16:26:48 -0000 --B_3424336003_9715749 Content-type: multipart/alternative; boundary="B_3424336003_9732321" --B_3424336003_9732321 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Since the DNS server at home only manages its own dns-domain, the dns-server should still use the CPE's IP for external dns query. If user decides not to use the CPE's IP, all dns packets would use the tunnel. If an operator wants to block this, in theory this will require implementing ACL to block dns in AFTR. In practice, this would probably make the user very unhappy. Draft-ietf-dns-dhcpv4-over-ipv6 addresses a different use case. This will be used when the CPE will be provisioned with a full public IPv4 address (i.e. No NAT in the AFTR). From: Tassos Chatzithomaoglou Organization: Forthnet Date: Thursday, July 5, 2012 9:06 AM To: Wuyts Carl Cc: "softwires@ietf.org" , "v6ops@ietf.org" Subject: Re: [Softwires] [v6ops] DS-Lite & DNS Since i (as an operator) manage the CPE but not the host, i got a little bit worried and confused by the statement "DNS packets are not expected to go through the AFTR element", since the subscriber can easily send such packets. So my understanding is that this is a supported scenario, but probably not a recommended one. Also, can draft-ietf-dhc-dhcpv4-over-ipv6 be considered an alternative option for passing IPv4 info to clients over IPv6 in DS-Lite networks? --B_3424336003_9732321 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Since the DNS server at home= only manages its own dns-domain, the dns-server should still use the CPE's = IP for external dns query. If user decides not to use the CPE's IP, all dns = packets would use the tunnel. If an operator wants to block this, in theory = this will require implementing ACL to block dns in AFTR. In practice, this w= ould probably make the user very unhappy.

Draft-iet= f-dns-dhcpv4-over-ipv6 addresses a different use case. This will be used whe= n the CPE will be provisioned with a full public IPv4 address (i.e. No NAT i= n the AFTR).


= From: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>
Org= anization: Forthnet
Date: = Thursday, July 5, 2012 9:06 AM
To: = Wuyts Carl <Carl.Wuyts@techn= icolor.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>, "v= 6ops@ietf.org" <v6ops@ietf.org>= ;
Subject: Re: [Softwires] [v6ops]= DS-Lite & DNS

Since i (as an = operator) manage the CPE but not the host, i got a little bit worried and co= nfused by the statement "DNS packets are not expected to go through the AFTR= element", since the subscriber can easily send such packets.
So my under= standing is that this is a supported scenario, but probably not a recommende= d one.


Also, can dr= aft-ietf-dhc-dhcpv4-over-ipv6 be considered an alternative option for passin= g IPv4 info to clients over IPv6 in DS-Lite networks?
--B_3424336003_9732321-- --B_3424336003_9715749 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT3GxRC TwAdSJwPBtF/65hhgCSGrDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA3MDUxNjI2NDNaMA0GCSqGSIb3DQEBAQUABIIBAFfSoVjFDqR4aEcvzEZwYBXq Rjv6BCwhicViTBQXKuUn9q4EMBuUS/obOmzk/QSNjEFogcF2eCWZUy2x7ygjqnrAeDt4tyPu Jit2ott7KtIXioSddTmFysrMbfhTgHPlrehnjfpSZy4tdQ3enQB8jcd5endGii8HNSHP8sXV tH7a7yePNOkzM6POXeEeAqtn4q4o2+Z8CqNAOLJohgLLPJkJU0uENTogvcXgbon8ZXKR/u4V YGydaYk+qrX8XIKgm+Qg4q8c//KtIvN2U0/tNUEb1kBh/8Hzmu5Mxlo+35riUBBNZMGXbO3U aD4Iy8E+RXUNS++BAdicFNDrdcx7+Wg= --B_3424336003_9715749-- From suresh.krishnan@ericsson.com Thu Jul 5 21:33:58 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B276211E8123 for ; Thu, 5 Jul 2012 21:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 lElRRMNuUPFz for ; Thu, 5 Jul 2012 21:33:58 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E2B9911E808D for ; Thu, 5 Jul 2012 21:33:57 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q664YBK3021736; Thu, 5 Jul 2012 23:34:12 -0500 Received: from [164.48.125.62] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 6 Jul 2012 00:34:05 -0400 Message-ID: <4FF66AB7.4090808@ericsson.com> Date: Fri, 6 Jul 2012 00:33:59 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Softwires WG X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Yong Cui Subject: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 06 Jul 2012 04:33:58 -0000 Hi all, This call is being initiated to determine whether there is WG consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. Regards Suresh & Yong From chunfa.sun@g.softbank.co.jp Thu Jul 5 21:46:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9444121F852A for ; Thu, 5 Jul 2012 21:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04PODwQGVJPv for ; Thu, 5 Jul 2012 21:46:21 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with SMTP id E7DB121F8665 for ; Thu, 5 Jul 2012 21:46:20 -0700 (PDT) Received: from mail-qa0-f45.google.com ([209.85.216.45]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT/Ztq4F0ATjl4ayQ2tJe6dFhEifgvV1o@postini.com; Thu, 05 Jul 2012 21:46:36 PDT Received: by qaeb19 with SMTP id b19so227181qae.11 for ; Thu, 05 Jul 2012 21:46:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=VfFH5drHoAU2uk1CZg6Oa31JylSMbzx/YKTlxotzfFM=; b=Fc1Gn0ANbhpe5JsWuKBAubWgDYWrjIrplN4vdW5Gq5nXP5Z4UH2ecIsIzcyFTciJ0j KHeNK+2N8N0/ngkoJXow9vCFFtIhX1gak4kRzNDNnlbg93A6nJ4BZIZlXSobHsiRKTkY HxV+u3tKn7yfZ+xXk4Auo3MFuC15iEHgdGy8v4eg0X4QUk3p44/Y7pmCcTFLpNnykNHt wdmLmPnh7mZnFC2fRc8gtymsMR7ZzysTc3PkTPPme+nNidJXMDxTvIYl9N+xHrP/urDF lXeY0IqrnBz1ceFabMTK3+hPoSYv6tdXrxqSW5tLNpvFHqMN7SUOv4G5okdkMenpbnRd mw6g== MIME-Version: 1.0 Received: by 10.229.135.135 with SMTP id n7mr14612207qct.149.1341549995072; Thu, 05 Jul 2012 21:46:35 -0700 (PDT) Received: by 10.229.177.105 with HTTP; Thu, 5 Jul 2012 21:46:35 -0700 (PDT) In-Reply-To: <4FF66AB7.4090808@ericsson.com> References: <4FF66AB7.4090808@ericsson.com> Date: Fri, 6 Jul 2012 13:46:35 +0900 Message-ID: From: =?UTF-8?B?5a2rIOaYpeeZuu+8iOODjeODg+ODiOODr+ODvOOCr+acrOmDqO+8iS0gU3VuIENodW5mYSAt?= To: Suresh Krishnan Content-Type: multipart/alternative; boundary=00248c6a6726e79d0704c421f2f5 X-Gm-Message-State: ALoCoQn6FvHALKggjE7wc65puDoSbMahEyTY3Qw5DvwdWEi5rZJTHvfrUB2eWybXDhOM0qrQb7mJ Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 06 Jul 2012 04:46:22 -0000 --00248c6a6726e79d0704c421f2f5 Content-Type: text/plain; charset=UTF-8 I am in favor of adopting this document as a softwire WG document. -chunfa 2012/7/6 Suresh Krishnan > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. > > Regards > Suresh & Yong > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --00248c6a6726e79d0704c421f2f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in favor of=C2= =A0=C2= =A0this documenta softwire WG document.=C2=A0

-chunfa

2012/7/6 Suresh Kr= ishnan <suresh.krishnan@ericsson.com>
Hi all,
=C2=A0 This call is being initiated to determine whether there is WG
consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20.

Regards
Suresh & Yong

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



--00248c6a6726e79d0704c421f2f5-- From tomasz.mrugalski@gmail.com Fri Jul 6 00:18:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2611E8099 for ; Fri, 6 Jul 2012 00:18:50 -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 apcnx6IHOxOh for ; Fri, 6 Jul 2012 00:18:49 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7AB11E8079 for ; Fri, 6 Jul 2012 00:18:49 -0700 (PDT) Received: by eekd4 with SMTP id d4so3758919eek.31 for ; Fri, 06 Jul 2012 00:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=WT+Xe4kXPRCjUXAhj+hUffI/zjsqoLPfBXDKIqzX+fM=; b=bHszGSfIJJQOTRYF2VQAN8lEMJGie6d89+j80m5pBIUg/VqDEsjb7UpGy7elF70uCC 8a1379SgnVpTE3BS6KSNMNBbaxwkVBbTJTEQHPwBbJVfq5u7JAHEscxkrZtwMdEoSTU8 4E5F87mZYg4OvL9ZOlPgQ/6hgB4xS1QnTAtwK1kezfkwyHSiks1ucNqzJ54OUdZN2ZNt v+mARKwNhCk16JoTEuYETM4dlyXbnuFTAN/60DlZ+ppUADTliRfSMmSY4f5YpS1doQ9E 6Mj6vIh35YDOTBtKYiE+Nd+R6ECVDwLE4DxdOsl7D377W1aUqzaQ0DSFlVmhwOcR64cN wB+w== Received: by 10.14.53.71 with SMTP id f47mr6839331eec.62.1341559144252; Fri, 06 Jul 2012 00:19:04 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:88ba:509c:2f8f:c645? ([2001:470:6061:1:88ba:509c:2f8f:c645]) by mx.google.com with ESMTPS id q53sm68929704eef.8.2012.07.06.00.19.03 (version=SSLv3 cipher=OTHER); Fri, 06 Jul 2012 00:19:03 -0700 (PDT) Message-ID: <4FF69162.6040909@gmail.com> Date: Fri, 06 Jul 2012 09:18:58 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <4FF66AB7.4090808@ericsson.com> In-Reply-To: <4FF66AB7.4090808@ericsson.com> X-TagToolbar-Keys: D20120706091858168 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 06 Jul 2012 07:18:50 -0000 On 06.07.2012 06:33, Suresh Krishnan wrote: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. I'm in favor of adopting this document. Disclosure: I'm co-author of this draft. Tomek From jiangsheng@huawei.com Fri Jul 6 00:25:30 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1A411E809F for ; Fri, 6 Jul 2012 00:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O07eKMZH5RF8 for ; Fri, 6 Jul 2012 00:25:29 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7263911E8085 for ; Fri, 6 Jul 2012 00:25:29 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHM33626; Fri, 06 Jul 2012 03:25:43 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 00:24:52 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 00:24:43 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Fri, 6 Jul 2012 15:24:39 +0800 From: Sheng Jiang To: Softwires WG Thread-Topic: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 as wg draft Thread-Index: AQHNWzCcD0eOxOpcNkmNlPwV7bFc7pcb2hkQ Date: Fri, 6 Jul 2012 07:24:37 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF5C5B@szxeml545-mbx.china.huawei.com> References: <4FF66AB7.4090808@ericsson.com> In-Reply-To: <4FF66AB7.4090808@ericsson.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.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 06 Jul 2012 07:25:30 -0000 U3VwcG9ydCBhZG9wdGlvbi4NCg0KU2hlbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1i b3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgU3VyZXNoIEtyaXNobmFuDQo+IFNlbnQ6 IEZyaWRheSwgSnVseSAwNiwgMjAxMiAxMjozNCBQTQ0KPiBUbzogU29mdHdpcmVzIFdHDQo+IENj OiBZb25nIEN1aQ0KPiBTdWJqZWN0OiBbU29mdHdpcmVzXSBDYWxsIGZvciBhZG9wdGlvbiBvZg0K PiBkcmFmdC1tZHQtc29mdHdpcmUtbWFwLWRoY3Atb3B0aW9uLTAzIGFzIHdnIGRyYWZ0DQo+IA0K PiBIaSBhbGwsDQo+ICAgVGhpcyBjYWxsIGlzIGJlaW5nIGluaXRpYXRlZCB0byBkZXRlcm1pbmUg d2hldGhlciB0aGVyZSBpcyBXRw0KPiBjb25zZW5zdXMgdG93YXJkcyBhZG9wdGlvbiBvZiBkcmFm dC1tZHQtc29mdHdpcmUtbWFwLWRoY3Atb3B0aW9uLTAzIGFzIGENCj4gc29mdHdpcmUgV0cgZHJh ZnQuIFBsZWFzZSBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2YgdGhlDQo+ IGFkb3B0aW9uIGJ5IHJlcGx5aW5nIHRvIHRoaXMgZW1haWwuIElmIHlvdSBhcmUgbm90IGluIGZh dm9yLCBwbGVhc2UgYWxzbw0KPiBzdGF0ZSB5b3VyIG9iamVjdGlvbnMgaW4geW91ciByZXNwb25z ZS4gVGhlIGNhbGwgd2lsbCBjb21wbGV0ZSBhdA0KPiBtaWRuaWdodCBQRFQgb24gMjAxMi0wNy0y MC4NCj4gDQo+IFJlZ2FyZHMNCj4gU3VyZXNoICYgWW9uZw0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU29mdHdpcmVzIG1haWxpbmcgbGlz dA0KPiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zb2Z0d2lyZXMNCg== From despres.remi@laposte.net Fri Jul 6 00:53:59 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0F221F86B2 for ; Fri, 6 Jul 2012 00:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.759 X-Spam-Level: X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_05=-1.11, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RfCeb-Ri5nJ for ; Fri, 6 Jul 2012 00:53:59 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id B4C8321F86F7 for ; Fri, 6 Jul 2012 00:53:58 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2113.sfr.fr (SMTP Server) with ESMTP id 5B0FA7000078; Fri, 6 Jul 2012 09:54:13 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2113.sfr.fr (SMTP Server) with ESMTP id 7513C700006F; Fri, 6 Jul 2012 09:54:12 +0200 (CEST) X-SFR-UUID: 20120706075412479.7513C700006F@msfrf2113.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FF66AB7.4090808@ericsson.com> Date: Fri, 6 Jul 2012 09:54:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1667E117-D6CC-45D7-8033-31F1BE680422@laposte.net> References: <4FF66AB7.4090808@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 06 Jul 2012 07:53:59 -0000 2012-07-06 06:33, Suresh Krishnan : > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 as = a > softwire WG draft. When I asked Alain whether WG drafts on 4rd and MAP should be = Experimental or Standard-track, he required NO INTENDED STATUS, which = has been done for ietf-softwire-4rd drafts. Noting that Draft-mdt-softwire-map-dhcp-option-03 is Standard track, I = now realize that ietf-softwire-map drafts, both -00 and -01, are = presented as Standard track, in contradiction with my understanding of = what was required. The question is then WHAT TO DO? - Putting all drafts on Standard track would at least be fair, but could = be confusing as it isn't the WG intention to proceed with all of them. - A provisional Experimental status for all drafts until a decision is = made would IMHO be less ambiguous. - In any case, this is a chairs' decision. Whatever the decision, I should reissue a 4rd-03 to reflect it. Since map-dhcp-option-03 is proposed to become WG draft with some new = enhancements, consistency suggests that 4rd-03 can include the security = improvement already documented in 4rd-01 (available since June 19, it = received no objection). OK? Regards, RD > 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 2012-07-20. >=20 > Regards > Suresh & Yong >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From leaf.y.yeh@huawei.com Fri Jul 6 03:03:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F1A21F869A for ; Fri, 6 Jul 2012 03:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.153 X-Spam-Level: X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 xI-5GogNRfo0 for ; Fri, 6 Jul 2012 03:03:47 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6909F21F852C for ; Fri, 6 Jul 2012 03:03:47 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHT43051; Fri, 06 Jul 2012 06:04:02 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 03:02:25 -0700 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 03:02:32 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Fri, 6 Jul 2012 18:02:25 +0800 From: Leaf yeh To: "softwires@ietf.org" Thread-Topic: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 as wg draft Thread-Index: AQHNWzCefNB+zGZtW0GQIk672c3XPJcbUroAgACON0A= Date: Fri, 6 Jul 2012 10:02:24 +0000 Message-ID: References: <4FF66AB7.4090808@ericsson.com> <4FF69162.6040909@gmail.com> In-Reply-To: <4FF69162.6040909@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 06 Jul 2012 10:03:48 -0000 +1 for adoption (Disclosure: MAP design team member). Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Tomek Mrugalski Sent: Friday, July 06, 2012 3:19 PM To: softwires@ietf.org Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-o= ption-03 as wg draft On 06.07.2012 06:33, Suresh Krishnan wrote: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. I'm in favor of adopting this document. Disclosure: I'm co-author of this draft. Tomek _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From suresh.krishnan@ericsson.com Fri Jul 6 14:18:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8DA11E80F3 for ; Fri, 6 Jul 2012 14:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 f9gG8JPI-IEr for ; Fri, 6 Jul 2012 14:18:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E15C311E80DE for ; Fri, 6 Jul 2012 14:18:46 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q66LIbwV030039; Fri, 6 Jul 2012 16:19:03 -0500 Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 6 Jul 2012 17:18:54 -0400 Message-ID: <4FF7563E.2000101@ericsson.com> Date: Fri, 6 Jul 2012 17:18:54 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Softwires WG X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Yong Cui Subject: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Fri, 06 Jul 2012 21:18:47 -0000 Hi all, This call is being initiated to determine whether there is WG consensus towards adoption of draft-mdt-softwire-map-deployment-02 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 2012-07-20. Regards Suresh & Yong From despres.remi@laposte.net Fri Jul 6 22:12:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4185021F855A for ; Fri, 6 Jul 2012 22:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cUd5jHONQsf for ; Fri, 6 Jul 2012 22:12:02 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE1321F8557 for ; Fri, 6 Jul 2012 22:12:01 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 298347000098; Sat, 7 Jul 2012 07:12:19 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2221.sfr.fr (SMTP Server) with ESMTP id 437657000093; Sat, 7 Jul 2012 07:12:18 +0200 (CEST) X-SFR-UUID: 20120707051218276.437657000093@msfrf2221.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FF66AB7.4090808@ericsson.com> Date: Sat, 7 Jul 2012 07:12:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <55E4119C-F0F4-40AA-9020-6B1E089B18C5@laposte.net> References: <4FF66AB7.4090808@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Sat, 07 Jul 2012 05:12:03 -0000 Suresh, For consistency, we do need a complement to map-01 which shows proposed = DHCPv6 formats. =3D> Support to have it as WG draft, provided: - the accepted status status is the same for map and 4rd documents = (still to be determined AFAIK). - It is understood that the WG plans to choose which of the map or 4rd = approach (or any other) will be pursued. Regards, RD=20 This support doesn't mean that the WG document=20 Le 2012-07-06 =E0 06:33, Suresh Krishnan a =E9crit : > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. >=20 > Regards > Suresh & Yong >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Jul 9 01:45:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFAB21F85AC for ; Mon, 9 Jul 2012 01:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.043 X-Spam-Level: X-Spam-Status: No, score=0.043 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e5RbGwRQPyG for ; Mon, 9 Jul 2012 01:45:06 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1015721F85A7 for ; Mon, 9 Jul 2012 01:45:05 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id 04DF47000078; Mon, 9 Jul 2012 10:45:29 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2409.sfr.fr (SMTP Server) with ESMTP id B0BD3700006D; Mon, 9 Jul 2012 10:45:28 +0200 (CEST) X-SFR-UUID: 20120709084528724.B0BD3700006D@msfrf2409.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3-591588645 Date: Mon, 9 Jul 2012 10:45:24 +0200 References: To: "softwires@ietf.org WG" Message-Id: X-Mailer: Apple Mail (2.1084) Cc: Lorenzo Colitti Subject: [Softwires] Fwd: TCP/IPv6 faster than TCP/IPv4/IPv6? X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 09 Jul 2012 08:45:07 -0000 --Apple-Mail-3-591588645 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The following email, sent by lorenzo to the mailing list didn't reach it = because he isn't registered in Softwire. Upon his request, here is a retransmission. Regards, RD > De : Lorenzo Colitti > Date : 2012-07-06 10:59 > =C0 : R=E9mi Despr=E9s > Cc : "softwires@ietf.org WG" > Objet : R=E9p : TCP/IPv6 faster than TCP/IPv4/IPv6? >=20 > On Thu, Jul 5, 2012 at 12:04 AM, R=E9mi Despr=E9s = wrote: > There has been discussions, during IETF 83 and after, to warn that, in = some circumstances, direct TCP over IPv6 can be significantly faster = than TCP/IPv4/IPv6. > A cc is sent to Lorenzo, because he privately reported some direct = knowledge of the subject (I personally have none). >=20 > What I know is: some routers only process UDP/IPv6 and/or TCP/IPv6 on = the fast path and IPv4/IPv6 on the slow path. I know this because I have = one such router at home, and I believe that millions of users in Japan = do as well. The devices are used to connect to the NTT East/West closed = IPv6 network, which provides 100M or 1G link speeds. Some of these users = have IPv6 Internet access over these pipes, and some ISPs are thinking = of tunneling IPv4 over IPv6 to take advantage of the fast IPv6 pipe = (IPv4 only provides 200M). >=20 > My particular router will do 1Gbps of TCP/IPv6 but only about 300Mbps = of TCP/IPv4/IPv6. This particular device is fairly recent, however; I = understand that older devices have worse performance (as low as a few = Mbps). >=20 > I realize this will very much sound like a first-world problem to most = people (my router will only do 300Mbps!), but nevertheless, this is a = barrier to adoption because a service that reduces users's bandwidth by = 3x to 100x is very hard to for an operator launch. >=20 > Cheers, > Lorenzo --Apple-Mail-3-591588645 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 The = following email, sent by lorenzo to the mailing list didn't reach it = because he isn't registered in Softwire.
Upon his request, here is a = retransmission.
Regards,
RD



De : Lorenzo Colitti = <lorenzo@google.com>
Date : 2012-07-06 = 10:59
=C0 : R=E9mi Despr=E9s <despres.remi@laposte.net><= br>
Cc : "softwires@ietf.org WG" <softwires@ietf.org>
Objet : R=E9p : TCP/IPv6 = faster than TCP/IPv4/IPv6?

 On Thu, Jul 5, 2012 at 12:04 AM, R=E9mi = Despr=E9s <despres.remi@laposte.net> = wrote:
There has been discussions, during IETF 83 and after, to warn that, in = some circumstances, direct TCP over IPv6 can be significantly faster = than TCP/IPv4/IPv6.
A cc is sent to Lorenzo, because he privately reported some direct = knowledge of the subject (I personally have = none).

What I know is: some routers = only process UDP/IPv6 and/or TCP/IPv6 on the fast path and IPv4/IPv6 on = the slow path. I know this because I have one such router at home, and I = believe that millions of users in Japan do as well. The devices are used = to connect to the NTT East/West closed IPv6 network, which provides 100M = or 1G link speeds. Some of these users have IPv6 Internet access = over these pipes, and some ISPs are thinking of tunneling IPv4 over IPv6 = to take advantage of the fast IPv6 pipe (IPv4 only provides 200M).

My particular router will do 1Gbps of TCP/IPv6 but = only about 300Mbps of TCP/IPv4/IPv6. This particular device is fairly = recent, however; I understand that older devices have worse performance = (as low as a few Mbps).

I realize this will very much sound like a = first-world problem to most people (my router will only do 300Mbps!), = but nevertheless, this is a barrier to adoption because a service that = reduces users's bandwidth by 3x to 100x is very hard to for an operator = launch.

Cheers,
Lorenzo

= --Apple-Mail-3-591588645-- From xing@cernet.edu.cn Mon Jul 9 03:18:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D2321F8550 for ; Mon, 9 Jul 2012 03:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=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 OisIUwlU6AtM for ; Mon, 9 Jul 2012 03:18:12 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id E4D6321F8555 for ; Mon, 9 Jul 2012 03:18:11 -0700 (PDT) Received: from [127.0.0.1] (unknown [125.34.53.79]) by centos (Coremail) with SMTP id AQAAf3DLAATGrvpP6IEEAA--.15307S5; Mon, 09 Jul 2012 18:13:27 +0800 (CST) Message-ID: <4FFAAFEC.3000109@cernet.edu.cn> Date: Mon, 09 Jul 2012 18:18:20 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Suresh Krishnan References: <4FF66AB7.4090808@ericsson.com> In-Reply-To: <4FF66AB7.4090808@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3DLAATGrvpP6IEEAA--.15307S5 X-Coremail-Antispam: 1UD129KBjvdXoWrWFWUGFWUurW8JrW5Cr4fGrg_yoWxXFc_uw s2g348Gr1UAw42yw4Syr4UA39xur4DXFyjyry5Jr47Z343C3Z8trsrJrZ7Kr17WryUJ343 Gr1xXry0k343GjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbnAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJV W0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcVAKI48JMxkIecxEwVAFwVW8twCF04k20xvY0x0EwIxGrwC20s026c02F40E 14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY6I8E87Iv67AKxVW8JV WxJwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU7WrW UUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Mon, 09 Jul 2012 10:18:13 -0000 Support adoption. xing Suresh Krishnan 写道: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. > > Regards > Suresh & Yong > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > From sarikaya2012@gmail.com Mon Jul 9 13:46:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF94B11E81F9 for ; Mon, 9 Jul 2012 13:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 1Im3NN91Xg7v for ; Mon, 9 Jul 2012 13:46:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE0611E81F5 for ; Mon, 9 Jul 2012 13:46:24 -0700 (PDT) Received: by yenq13 with SMTP id q13so11555352yen.31 for ; Mon, 09 Jul 2012 13:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZfyFnwYMfaSh2BgK5N0JiIGYlIbpp7AhOQ/Zb9fIYAQ=; b=tlJ4FPT4NqmnIpLfjOFTbPYzcveLseedtmiOJL3W+K3EiEzGJ85WytdEEfPgIqygbu SiNPx5pLHu8TJOoF+XeGE7x6GskeYr9pMg87GJu+EkCXulu8uD6QHGYje1sTrbFJ4lpw fXcFcenEBRxTmpHSoqgLqNZkxd1p0QJ5suXN1HSb+DaxlsWmn36mYaB+vn+Z8lL6l8Ku lBWAMIHhssga1buj8YDVcM++jrTsa7hQmQT0EOCsBX+987LeWpPo8Cdo2YAJoQEYNRZF PcuVnymWT6T0hSmWIV9jMOLyLs4RGYjseMZ0akXfLMc76zqZEfLz3fCWiKs8q+tNKD/F lbgQ== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr9671120igc.63.1341866809411; Mon, 09 Jul 2012 13:46:49 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Mon, 9 Jul 2012 13:46:49 -0700 (PDT) In-Reply-To: <4FF1E111.9020201@venaas.com> References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> <4FEBEA85.6010201@jacni.com> <4FEC9270.1050500@venaas.com> <4FF1C59A.6020600@jacni.com> <4FF1E111.9020201@venaas.com> Date: Mon, 9 Jul 2012 15:46:49 -0500 Message-ID: From: Behcet Sarikaya To: Stig Venaas Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires-wg Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 20:46:25 -0000 Well, from the so many mails below it is clear that draft-ietf-softwire-dslite-multicast-02 is anything but multicast extensions document for DS-Lite. Anyway we need to put this into the issue tracker as Suresh asked. Behcet On Mon, Jul 2, 2012 at 12:57 PM, Stig Venaas wrote: > Hi > > > On 7/2/2012 9:00 AM, Jacni Qin wrote: >> >> Hi Stig, >> >> Inline please, >> >> On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote: >>> >>> On 6/27/2012 10:24 PM, Jacni Qin wrote: >>>> >>>> Hi Stig, >>>> >>>> Thanks for you comments and support, please see below inline. >>>> >>>> On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote: >>>>> >>>>> FWIW, here is my take on this. >>>>> >>>>> >>>>> On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: >>>>> [...] >>>>>> >>>>>> That's a big IF. Not everybody has to do it the same way. >>>>>> >>>>>> The solution in draft-ietf-softwire-dslite-multicast-02 >>>>>> builds itself something without considering what DS-Lite is doing. >>>>>> As I told you before, DS-Lite unicast is a tunneling technology. If >>>>>> you don't like it it is not DS-Lite multicast to fix this. >>>>>> How many times this should be reminded to you? >>>>> >>>>> >>>>> draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing >>>>> specific to DS-Lite, and I've been saying that the draft should be >>>>> updated to reflect that. >>>>> >>>>> However, even though it is generic, I think it is a good solution for >>>>> use in DS-Lite deployments (in addition to many other deployments). >>>> >>>> As discussed in the previous messages of the thread, our motive is solve >>>> the problems >>>> for those who want multicast in their DS-Lite deployment. >>>> So we limited the scope. Where the DS-Lite is not deployed, it doesn't >>>> apply. >>> >>> >>> I understand that the motive is to have a solution for DS-Lite, but IMO >>> the key part is the solution itself. I think you should focus on the >>> solution and then discuss how it can be used in several scenarios, where >>> DS-Lite is one of them. >> >> Yes, we're focusing on the solution itself, and there is a Problem >> Statement draft >> discussing several scenarios during the transition of multicast. ;-) >> >>> >>> Wouldn't it be a shame if people have a need for your solution, but are >>> not aware of it, or doesn't consider it because they think it only >>> applies to DS-Lite? >>> >>> Don't you agree that we should generally find good generic solutions and >>> describe them as such? We don't want to write basically identical docs >>> for each scenario. And in the worst case instead of having a single good >>> solution, having solutions that are only almost identical, maybe >>> requiring multiple slightly different implementations to solve each of >>> the problems, where a single solution and a single implementation would >>> be sufficient? >>> >>> As a general principle when you come up with a solution to a problem, >>> don't you try to see what else it can solve, and try to present it as >>> a solution to all the problems? At least that is always my thinking. >> >> I totally understand your point and logic. >> >> In addition to the motive, based on lessons learnt from what we did for >> unicast solutions, it's been concluded that working on the scenarios with >> high priority is a better choice. So we did that following the WG's >> charter. > > > I think you could make it more generic by changing the title, and > minor changes to abstract/intro. > > You could say that this was designed to allow for multicast in DS-Lite, > but that it also applies to other cases where you need to provide IPv4 > multicast through an IPv6 multicast network or something like that. > > >> We ever know trying a single solution for all is not a good idea. > > > Yes, but your solution is more useful than just DS-Lite. You have no > dependency of DS-Lite, right? > > Stig > > >> And as mentioned above, I think the draft, >> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00 >> will say clearly about the background, our choices, what led to this, >> and will >> help people to analyze their requirements/scenarios, then to find an >> appropriate solution. >> >>> >>> It looks like we may disagree on this. I'm hoping I can make people see >>> the merits of making general solutions and presenting them as such. At >>> least for me, that seems like a good thing to strive for. >> >> Ideally, I like general solutions as well. While for transition, as for >> unicast, I believe >> we should try another way. :-) >> >>> >>> I know I've been repeating myself several times in emails to the list. >>> I feel strongly about this as a general principle. I don't know what >>> more I can say to stress my point though. >> >> Thanks for your patience and the discussion anyway, it helps for the >> clarifications. >> >> >> Cheers, >> Jacni >> >>> >>> Stig >>> >>>> >>>> If some pieces of the approach can be reused in the future, to solve the >>>> multicast issues in >>>> other deployments, that'd be good. >>>> While personally, I'd prefer we stay focus on the currently scenario. >>>> Extensions if needed, may be raised respectively for other deployments. >>>> More are detailed in, >>>> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. >>>> >>>> >>>> Cheers, >>>> Jacni >>>>> >>>>> >>>>> Whether additional solutions are needed for DS-Lite is something the >>>>> WG should consider. Maybe it already has, I haven't paid enough >>>>> attention. >>>>> >>>>> Stig >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >>> >>> >>> >> >> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From xing@cernet.edu.cn Mon Jul 9 19:32:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C725311E810A for ; Mon, 9 Jul 2012 19:32:44 -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 aJhLbt270fGl for ; Mon, 9 Jul 2012 19:32:44 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 81F5411E80C1 for ; Mon, 9 Jul 2012 19:32:43 -0700 (PDT) Received: from [IPv6:::1] (unknown [202.38.117.5]) by centos (Coremail) with SMTP id AQAAf3DrlgQ1k_tPnaIEAA--.6671S5; Tue, 10 Jul 2012 10:28:06 +0800 (CST) Message-ID: <4FFB945C.2000704@cernet.edu.cn> Date: Tue, 10 Jul 2012 10:33:00 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Suresh Krishnan References: <4FF7563E.2000101@ericsson.com> In-Reply-To: <4FF7563E.2000101@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3DrlgQ1k_tPnaIEAA--.6671S5 X-Coremail-Antispam: 1UD129KBjvdXoWrWFWUGFWUurW8JrW5Cr4fGrg_yoWxXFc_C3 yvg3WxGr1UAw42yw4Syr4UA39xur4DXryjyry5Jr12v345C3Z8trsrJrWxKr17WryUJ347 Gr1xXry0k343GjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbnAYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWx JwA2z4x0Y4vEx4A2jsIE14v26F4j6r4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr1j6F 4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcVAKI48JMxkIecxEwVAFwVW8JwCF04k20xvY0x0EwIxGrwC20s026c02F40E 14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6Fyj6rWUJwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU7qg4 DUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Tue, 10 Jul 2012 02:32:44 -0000 Support adoption. xing Suresh Krishnan 写道: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-deployment-02 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 2012-07-20. > > Regards > Suresh & Yong > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > From despres.remi@laposte.net Tue Jul 10 02:46:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2058D21F86FE for ; Tue, 10 Jul 2012 02:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcEFHFTFvRMX for ; Tue, 10 Jul 2012 02:45:59 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9666121F86FD for ; Tue, 10 Jul 2012 02:45:59 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2503.sfr.fr (SMTP Server) with ESMTP id 721B77000040; Tue, 10 Jul 2012 11:46:25 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2503.sfr.fr (SMTP Server) with ESMTP id 94D097000078; Tue, 10 Jul 2012 11:46:24 +0200 (CEST) X-SFR-UUID: 20120710094624609.94D097000078@msfrf2503.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FF7563E.2000101@ericsson.com> Date: Tue, 10 Jul 2012 11:46:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net> References: <4FF7563E.2000101@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Tue, 10 Jul 2012 09:46:00 -0000 Hi, Suresh, This draft contains valuable advices which can apply to 4rd as well as = to MAP-T+E, but is exclusively MAP oriented. As such, I find it premature to move it to WG-draft status. If 4rd is chosen for standardization, adapting this deployment draft to = it looks easy.=20 I therefore suggest to keep it as is for the time being (while pursuing = discussion on its contents). Regards, RD=20 Le 2012-07-06 =E0 23:18, Suresh Krishnan a =E9crit : > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-deployment-02 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 2012-07-20. >=20 > Regards > Suresh & Yong >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Tue Jul 10 04:02:37 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1F221F8742 for ; Tue, 10 Jul 2012 04:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSlzT77P4Lb8 for ; Tue, 10 Jul 2012 04:02:36 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52B5521F86A5 for ; Tue, 10 Jul 2012 04:02:36 -0700 (PDT) Received: by qadz3 with SMTP id z3so2122929qad.10 for ; Tue, 10 Jul 2012 04:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zf0bE272KNfeYK9g2rdctq18whhrHdi7i9t9Mp6gbig=; b=eovLqC9UYeXvUjYx/Wqk5NLJi/HMY+R0qzJcUziG2ZlhflGm/+fQKWHwMPhQuDHoaD PVfrP0qEIl/O8m78Nz3SpN6CMmtry9M5TQAncHrFeF660MrMzdy5KVUsnrsjBPk4l6hA CTqbXHpqP3xlKD8rO4yecj2bP5BB+moMVpbhznojaYjUoZTUx9CUSLMB1LT3jeK5zDSj XWF+D18N5kmLOilywBS/ge0jErnFU0zYnbymb9Dlu539OP5v2DWzzDyz4sLCTkKgwmLk a/zd0jJcQGhzOi6Zc15a5oWAzGe0fJK9Sr4ENjfd8dfYZHInHqa99b399Ifq5Hl+Wj4l N1tQ== MIME-Version: 1.0 Received: by 10.229.111.66 with SMTP id r2mr23336360qcp.80.1341918183412; Tue, 10 Jul 2012 04:03:03 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Tue, 10 Jul 2012 04:03:03 -0700 (PDT) In-Reply-To: <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net> References: <4FF7563E.2000101@ericsson.com> <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net> Date: Tue, 10 Jul 2012 20:03:03 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0023544716f0a3d3c304c477ac59 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Tue, 10 Jul 2012 11:02:37 -0000 --0023544716f0a3d3c304c477ac59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, 2012/7/10 R=E9mi Despr=E9s > Hi, Suresh, > > This draft contains valuable advices which can apply to 4rd as well as to > MAP-T+E, but is exclusively MAP oriented. > surely it is a MAP-oriented stuff as only the MAP-T+E are considered right now as the deployment paradigm in the draft. therefore i don't think it should wait 4rd being chosen for standardization. on the other hand, were 4rd rather than MAP chosen for standardization in the future, this deployment draft might be deprecated or its contents might be re-used and revised for 4rd deployment. no matter what the result would be, i don't see any problem of dealing that in the framework of a WG document. hope you may consider over this again. thanks! - maoke > As such, I find it premature to move it to WG-draft status. > > If 4rd is chosen for standardization, adapting this deployment draft to i= t > looks easy. > I therefore suggest to keep it as is for the time being (while pursuing > discussion on its contents). > > Regards, > RD > > > Le 2012-07-06 =E0 23:18, Suresh Krishnan a =E9crit : > > > Hi all, > > This call is being initiated to determine whether there is WG > > consensus towards adoption of draft-mdt-softwire-map-deployment-02 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 als= o > > state your objections in your response. The call will complete at > > midnight PDT on 2012-07-20. > > > > 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 > --0023544716f0a3d3c304c477ac59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Remi,

2012/7/10 R=E9mi Despr=E9= s <despres.remi@laposte.net>
Hi, Suresh,

This draft contains valuable advices which can apply to 4rd as well as to M= AP-T+E, but is exclusively MAP oriented.

surely it is a MAP-oriented stuff as only the MAP-T+E are considered righ= t now as the deployment paradigm in the draft. therefore i don't think = it should wait 4rd being chosen for standardization.=A0

on the other hand, were 4rd rather than MAP chosen for = standardization in the future, this deployment draft might be deprecated or= its contents might be re-used and revised for 4rd deployment. no matter wh= at the result would be, i don't see any problem of dealing that in the = framework of a WG document.=A0

hope you may consider over this again. thanks!

- maoke
=A0
As such, I find it premature to move it to WG-draft status.

If 4rd is chosen for standardization, adapting this deployment draft to it = looks easy.
I therefore suggest to keep it as is =A0for the time being (while pursuing = discussion on its contents).

Regards,
RD


Le 2012-07-06 =E0 23:18, Suresh Krishnan a =E9crit :

> Hi all,
> =A0This call is being initiated to determine whether there is WG
> consensus towards adoption of draft-mdt-softwire-map-deployment-02 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 al= so
> state your objections in your response. The call will complete at
> midnight PDT on 2012-07-20.
>
> 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

--0023544716f0a3d3c304c477ac59-- From despres.remi@laposte.net Tue Jul 10 05:28:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A4D21F8579 for ; Tue, 10 Jul 2012 05:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS1xLieYnYGT for ; Tue, 10 Jul 2012 05:28:15 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id BF40D21F856D for ; Tue, 10 Jul 2012 05:28:14 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id EDAFD700006B; Tue, 10 Jul 2012 14:28:40 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 0CD8470000B0; Tue, 10 Jul 2012 14:28:39 +0200 (CEST) X-SFR-UUID: 20120710122840527.0CD8470000B0@msfrf2309.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-691383196 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 10 Jul 2012 14:28:39 +0200 Message-Id: References: <4FF7563E.2000101@ericsson.com> <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Tue, 10 Jul 2012 12:28:15 -0000 --Apple-Mail-4-691383196 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-07-10 13:03, Maoke : > hi Remi, >=20 > 2012/7/10 R=E9mi Despr=E9s > Hi, Suresh, >=20 > This draft contains valuable advices which can apply to 4rd as well as = to MAP-T+E, but is exclusively MAP oriented. >=20 > surely it is a MAP-oriented stuff as only the MAP-T+E are considered = right now as the deployment paradigm in the draft. therefore i don't = think it should wait 4rd being chosen for standardization.=20 >=20 > on the other hand, were 4rd rather than MAP chosen for standardization = in the future, this deployment draft might be deprecated or its contents = might be re-used and revised for 4rd deployment. Well, if this understanding is shared by the chairs, please consider = that my objection to have this draft as WG document now is without = object.=20 A confirmation of this understanding will however be appreciated if it = is the right one. Thanks, RD > no matter what the result would be, i don't see any problem of dealing = that in the framework of a WG document.=20 >=20 > hope you may consider over this again. thanks! >=20 > - maoke > =20 > As such, I find it premature to move it to WG-draft status. >=20 > If 4rd is chosen for standardization, adapting this deployment draft = to it looks easy. > I therefore suggest to keep it as is for the time being (while = pursuing discussion on its contents). >=20 > Regards, > RD >=20 >=20 > Le 2012-07-06 =E0 23:18, Suresh Krishnan a =E9crit : >=20 > > Hi all, > > This call is being initiated to determine whether there is WG > > consensus towards adoption of draft-mdt-softwire-map-deployment-02 = 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 2012-07-20. > > > > 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 >=20 --Apple-Mail-4-691383196 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
hi = Remi,

2012/7/10 R=E9mi Despr=E9s = <despres.remi@laposte.net>
Hi, Suresh,

This draft contains valuable advices which can apply to 4rd as well as = to MAP-T+E, but is exclusively MAP = oriented.

surely it is a = MAP-oriented stuff as only the MAP-T+E are considered right now as the = deployment paradigm in the draft. therefore i don't think it should wait = 4rd being chosen for standardization. 

on the other hand, were 4rd rather than MAP chosen = for standardization in the future, this deployment draft might be = deprecated or its contents might be re-used and revised for 4rd = deployment.

Well, if this = understanding is shared by the chairs, please consider that my objection = to have this draft as WG document now is without = object. 
A confirmation of this understanding will = however be appreciated if it is the right = one.

Thanks,
RD



no matter what the result would be, i don't = see any problem of dealing that in the framework of a WG = document. 

hope you may consider over this again. = thanks!

- = maoke
 
As such, I find it premature to move it to WG-draft status.

If 4rd is chosen for standardization, adapting this deployment draft to = it looks easy.
I therefore suggest to keep it as is  for the time being (while = pursuing discussion on its contents).

Regards,
RD


Le 2012-07-06 =E0 23:18, Suresh Krishnan a =E9crit :

> Hi all,
>  This call is being initiated to determine whether there is = WG
> consensus towards adoption of draft-mdt-softwire-map-deployment-02 = 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 2012-07-20.
>
> 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


= --Apple-Mail-4-691383196-- From simon.perreault@viagenie.ca Tue Jul 10 07:33:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E1921F8596 for ; Tue, 10 Jul 2012 07:33:18 -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 FQ7hF37-fr7a for ; Tue, 10 Jul 2012 07:33:16 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id A0F3621F8413 for ; Tue, 10 Jul 2012 07:33:13 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0DD6940065 for ; Tue, 10 Jul 2012 10:33:40 -0400 (EDT) Message-ID: <4FFC3D43.1010704@viagenie.ca> Date: Tue, 10 Jul 2012 10:33:39 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: softwires@ietf.org References: <4FF7563E.2000101@ericsson.com> <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net> In-Reply-To: <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Tue, 10 Jul 2012 14:33:18 -0000 On 07/10/2012 05:46 AM, Rmi Desprs wrote: > This draft contains valuable advices which can apply to 4rd as well as to MAP-T+E, but is exclusively MAP oriented. > As such, I find it premature to move it to WG-draft status. > > If 4rd is chosen for standardization, adapting this deployment draft to it looks easy. > I therefore suggest to keep it as is for the time being (while pursuing discussion on its contents). I tend to agree with Rmi. The draft could also apply to 4rd very easily: a search and replace, some minor modifications, and we're done. If we eventually need to change what protocol this document applies to, it would be better to do it before adoption rather than after. Just because of process. We wouldn't want to deal with an objection late into the process claiming that this draft diverged from the scope it had when it was adopted, and maybe have to backtrack and do it all over again. So I say we play it safe, wait for the MAP-vs-4rd situation to be resolved, adjust the document as necessary, then adopt. Assuming the MAP-vs-4rd situation gets resolved quickly (hint! hint!), a small delay shouldn't be a problem. My 2 Canadian. Simon From phdgang@gmail.com Tue Jul 10 09:36:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BEC11E80D2 for ; Tue, 10 Jul 2012 09:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMZANxNEe4ql for ; Tue, 10 Jul 2012 09:35:59 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5898611E80CE for ; Tue, 10 Jul 2012 09:35:59 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so115584wgb.13 for ; Tue, 10 Jul 2012 09:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Bk3shZx85TWjyiEgXBlzOW3qn9JPGEDrjVCJfUG7a2k=; b=SIZrCQRVj43HvmIFPwkC2U0naer4BpOkZWZyl+xe24IjSAJGi3UfGyilX/Nzll15fa Q/i3Rq/HJthB4DT2rhTt7Z6XhATJ89cRjSThaTefT0nvVb+nFLSn5/98yW7ZesY2M/N8 f2gP1UOUQlzzhTYq1BSEeT8GyVB7Lc4VIaieE+KmBpFlO5I0rFe93dznED3Lynv6Fzyi v9duxsuItuxqmZM1gWvpPuQ44fVRJ2yhIyxDLNufXFbbgAl04xP43IO2SN1O22IG4ueY WKjo2BeU8XM03KRlv4wozDh1Pp1yZDf3hmteu3R5elT8Nn/oUBzOzfHrTcbVZvJj4kF7 uZjA== MIME-Version: 1.0 Received: by 10.216.29.212 with SMTP id i62mr14435739wea.28.1341938186638; Tue, 10 Jul 2012 09:36:26 -0700 (PDT) Received: by 10.180.87.102 with HTTP; Tue, 10 Jul 2012 09:36:26 -0700 (PDT) In-Reply-To: <20120709150443.903.3661.idtracker@ietfa.amsl.com> References: <20120709150443.903.3661.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 00:36:26 +0800 Message-ID: From: GangChen To: softwires Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] Fwd: I-D Action: draft-chen-softwire-ce-non-pd-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:36:00 -0000 Hello all, A new draft have been posted to address the case, where there was no DHCP-PD available to parameter provisioning in carrier-side stateless solution. Your comments are appreciated Many thanks Gang ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 09 Jul 2012 08:04:43 -0700 Subject: I-D Action: draft-chen-softwire-ce-non-pd-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Parameter Provisioning with non-DHCP-PD in Carrier-side Stateless Solution Author(s) : Gang Chen Filename : draft-chen-softwire-ce-non-pd-00.txt Pages : 7 Date : 2012-07-09 Abstract: The deployment of carrier-side stateless solution requires some particular considerations in mobile network contexts. The widely existed legacy network restricts the development of IP address provisioning based on DHCP-PD. The memo provided several potential approaches to facilitate the issues and provide the possibilities leveraging 3GPP mechanism. The stateless algorithm is required to be updated depending to the preferred solution accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-softwire-ce-non-pd There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-softwire-ce-non-pd-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Tina.Tsou.Zouting@huawei.com Tue Jul 10 10:10:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F032A21F87AF for ; Tue, 10 Jul 2012 10:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=0.735, 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 0nwcqemtyoTN for ; Tue, 10 Jul 2012 10:10:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4997721F87AE for ; Tue, 10 Jul 2012 10:10:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHQ22240; Tue, 10 Jul 2012 13:11:24 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 10:09:13 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.208]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 10:09:08 -0700 From: Tina TSOU To: Simon Perreault Thread-Topic: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 as wg draft Thread-Index: AQHNXqkL0oe45aWnpUyL0Z2h9eBdlpciwB1q Date: Tue, 10 Jul 2012 17:09:08 +0000 Message-ID: <2440D7C2-D9BD-44D4-A1A6-7C5A1949F95C@huawei.com> References: <4FF7563E.2000101@ericsson.com> <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net>, <4FFC3D43.1010704@viagenie.ca> In-Reply-To: <4FFC3D43.1010704@viagenie.ca> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Tue, 10 Jul 2012 17:10:57 -0000 Tina On Jul 10, 2012, at 7:34 AM, "Simon Perreault" wrote: > On 07/10/2012 05:46 AM, R=E9mi Despr=E9s wrote: >> This draft contains valuable advices which can apply to 4rd as well as t= o MAP-T+E, but is exclusively MAP oriented. >> As such, I find it premature to move it to WG-draft status. >>=20 >> If 4rd is chosen for standardization, adapting this deployment draft to = it looks easy. >> I therefore suggest to keep it as is for the time being (while pursuing= discussion on its contents). >=20 > I tend to agree with R=E9mi. The draft could also apply to 4rd very easil= y: a search and replace, some minor modifications, and we're done. How about use the word "stateless"? Then it can work now and later. >=20 > If we eventually need to change what protocol this document applies to, i= t would be better to do it before adoption rather than after. Just because = of process. We wouldn't want to deal with an objection late into the proces= s claiming that this draft diverged from the scope it had when it was adopt= ed, and maybe have to backtrack and do it all over again. >=20 > So I say we play it safe, wait for the MAP-vs-4rd situation to be resolve= d, adjust the document as necessary, then adopt. >=20 > Assuming the MAP-vs-4rd situation gets resolved quickly (hint! hint!), a = small delay shouldn't be a problem. >=20 > My 2=A2 Canadian. >=20 > Simon > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From suresh.krishnan@ericsson.com Tue Jul 10 11:34:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079FC21F8722 for ; Tue, 10 Jul 2012 11:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CvpH2BfFLWd for ; Tue, 10 Jul 2012 11:34:23 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 76B4D21F86D7 for ; Tue, 10 Jul 2012 11:34:23 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6AIYlSH016840; Tue, 10 Jul 2012 13:34:49 -0500 Received: from [142.133.112.108] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Tue, 10 Jul 2012 14:34:46 -0400 Message-ID: <4FFC75C6.3000006@ericsson.com> Date: Tue, 10 Jul 2012 14:34:46 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4FF7563E.2000101@ericsson.com> <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Tue, 10 Jul 2012 18:34:24 -0000 Hi Remi, On 07/10/2012 08:28 AM, Rmi Desprs wrote: > > 2012-07-10 13:03, Maoke : > >> hi Remi, >> >> 2012/7/10 Rmi Desprs > > >> >> Hi, Suresh, >> >> This draft contains valuable advices which can apply to 4rd as >> well as to MAP-T+E, but is exclusively MAP oriented. >> >> >> surely it is a MAP-oriented stuff as only the MAP-T+E are considered >> right now as the deployment paradigm in the draft. therefore i don't >> think it should wait 4rd being chosen for standardization. >> >> on the other hand, were 4rd rather than MAP chosen for standardization >> in the future, this deployment draft might be deprecated or its >> contents might be re-used and revised for 4rd deployment. > > Well, if this understanding is shared by the chairs, please consider > that my objection to have this draft as WG document now is without object. > A confirmation of this understanding will however be appreciated if it > is the right one. Yes. Once the document comes under wg change control, it is the consensus of the wg that will drive it further. If there is wg consensus to include 4rd related text in this document either in addition to or in lieu of the MAP related text, that is what will happen. Thanks Suresh From sarikaya2012@gmail.com Tue Jul 10 15:33:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A982111E80E6 for ; Tue, 10 Jul 2012 15:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 TbhkIgkdec5D for ; Tue, 10 Jul 2012 15:33:31 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB7111E809F for ; Tue, 10 Jul 2012 15:33:31 -0700 (PDT) Received: by yhfs35 with SMTP id s35so794779yhf.27 for ; Tue, 10 Jul 2012 15:33:59 -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=YE/us83luqtwXarw0fQ7MM9+wT7FCqbm1EHndonKaGs=; b=la7gM3FvpQwVFT0wDgZKdR6Qrs4ynGqnb/QHGb/Uj2SI72SBv/Auzo9t13lN3T/A2M 3Jbpq5lcTW+80SgbVY6VJUSEBONaw6wHyRZpTPFOJR0jznwK1bfgBUfOfs2ZMdCICmc/ NLt1vv/z4emSWsXPkCRZTF3uCis2SJCEkRT+QwS6mWStyHLgd6XJCsXQg3Bk8G5TC4u/ bjOJ/uNkpjJvkHTSKEQWHtlOHrfMEeu/9UBzvZhQjo7Ta7ig+Ny2dqe1dk4z7cvsK9th nlHZUUrU2sNt+bNT5RC3sGyAXzib2WC0rllkscCOPtoWwg6+Hy6OoFd1BeqaDmlO3Xdu LnoQ== MIME-Version: 1.0 Received: by 10.50.194.132 with SMTP id hw4mr12915592igc.63.1341959639319; Tue, 10 Jul 2012 15:33:59 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Tue, 10 Jul 2012 15:33:59 -0700 (PDT) In-Reply-To: <4FECC221.5080206@ericsson.com> References: <4FECC221.5080206@ericsson.com> Date: Tue, 10 Jul 2012 17:33:59 -0500 Message-ID: From: Behcet Sarikaya To: Suresh Krishnan Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires WG Subject: Re: [Softwires] Issue tracker for wg 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, 10 Jul 2012 22:33:31 -0000 Dear Chair, In creating a new ticket, should we cc to the list softwires@ietf.org? Kind regards, Behcet On Thu, Jun 28, 2012 at 3:44 PM, Suresh Krishnan wrote: > Hi all, > In order to handle document issues in an orderly manner, we have setup > an issue tracker for the softwire working group. Each of the wg drafts > has been setup as an available component to file issues on. At this > point, we have setup the tracker so that creation of issues is open to > everyone (and not just chairs and document editors), but we may revisit > this decision in the future based on the usage of the tracker. > > The list of all open tickets (none at this moment) can be found at > > http://trac.tools.ietf.org/wg/softwire/trac/report/1 > > To create a new ticket use (requires a tools login) > > http://trac.tools.ietf.org/wg/softwire/trac/newticket > > Further documentation and guides can be found at > > http://trac.tools.ietf.org/wg/softwire/trac/wiki > > Thanks > Suresh & Yong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From suresh.krishnan@ericsson.com Tue Jul 10 21:27:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE3011E8072 for ; Tue, 10 Jul 2012 21:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 xAhgdKbYB8M5 for ; Tue, 10 Jul 2012 21:27:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id BC7B221F8535 for ; Tue, 10 Jul 2012 21:27:46 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6B4SAMi004629; Tue, 10 Jul 2012 23:28:12 -0500 Received: from [164.48.125.32] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 11 Jul 2012 00:28:05 -0400 Message-ID: <4FFD00C5.7000709@ericsson.com> Date: Wed, 11 Jul 2012 00:27:49 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "sarikaya@ieee.org" References: <4FECC221.5080206@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Softwires WG , Behcet Sarikaya Subject: Re: [Softwires] Issue tracker for wg X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 04:27:48 -0000 Hi Behcet, On 07/10/2012 06:33 PM, Behcet Sarikaya wrote: > Dear Chair, > > In creating a new ticket, should we cc to the list > softwires@ietf.org? Not necessary. I have set up the tracker to automatically send mail to the mailing list. Thanks Suresh From despres.remi@laposte.net Tue Jul 10 23:44:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38AF411E80ED for ; Tue, 10 Jul 2012 23:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3YZDdcRBYlL for ; Tue, 10 Jul 2012 23:44:37 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 4690111E80E8 for ; Tue, 10 Jul 2012 23:44:37 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id F2471700006C; Wed, 11 Jul 2012 08:45:05 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2417.sfr.fr (SMTP Server) with ESMTP id 48C217000043; Wed, 11 Jul 2012 08:45:05 +0200 (CEST) X-SFR-UUID: 20120711064505298.48C217000043@msfrf2417.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4FFC75C6.3000006@ericsson.com> Date: Wed, 11 Jul 2012 08:45:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66A940A3-A3DC-4443-8AAC-9D3217C8018A@laposte.net> References: <4FF7563E.2000101@ericsson.com> <98C96596-304C-46E7-A854-5A25E81C4C79@laposte.net> <4FFC75C6.3000006@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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, 11 Jul 2012 06:44:38 -0000 2012-07-10 =E0 20:34, Suresh Krishnan : ... > Once the document comes under wg change control, it is the > consensus of the wg that will drive it further. If there is wg = consensus > to include 4rd related text in this document either in addition to or = in > lieu of the MAP related text, that is what will happen. Well clarified =3D> agreement to have such a draft as WG document now. Thanks, RD From sarikaya2012@gmail.com Wed Jul 11 12:41:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F3611E8145 for ; Wed, 11 Jul 2012 12:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4m3SmsTNl1m for ; Wed, 11 Jul 2012 12:41:08 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9103A11E813F for ; Wed, 11 Jul 2012 12:41:06 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1755487ggn.31 for ; Wed, 11 Jul 2012 12:41:37 -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=0MulYXAKeN7zIxRRxv1BYoD17tq2LF16YVqaWKcEM1E=; b=miALr7v79R8rHD6yIXzfSvBqQK1GXx2muQOR5CV07+FeARJ4WqwMV5VkMdFBO7W/w3 DgowsVkf7ZM2qOzhQYFUoeYr5w4/CXShGfq0VnpyuXRqPgQVVE1+x8Iy/WqF6YoFecWb eAM+JcrTEkHGu61PHiQRFzkEYuUhwZemr4OeWmLfsQewSNWzR5PMMFZGdmCdYFv+NHZj hUaI2abAXUIdSZNKZsFWSrWYqyqcGJru3xj/rPmP45+XBw834sOUagV35ZXxyr/tbO7B m471V5PX/lnke5kl39Cfuf8JgRR7Gi0h1H0WcQ4h7UafBdeGSPtKEHhe5Gv1uIoFaxY9 p62g== MIME-Version: 1.0 Received: by 10.50.183.200 with SMTP id eo8mr15788744igc.63.1342035697279; Wed, 11 Jul 2012 12:41:37 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Wed, 11 Jul 2012 12:41:37 -0700 (PDT) Date: Wed, 11 Jul 2012 14:41:37 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] Comment on draft-ietf-softwire-4rd-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 19:41:09 -0000 Hi Remi, I was reading this draft and one sentence in the abstract drew my attention: To cope with the IPv4 address shortage, customers can be assigned IPv4 addresses with restricted port sets. I think this means A+P at the customer level. I was under the impression that A+P use in 4rd was restricted to the CE level. As you know A+P has limitations, i.e. it can not be used on shared links such as 802.3 or 802.11. I am not sure if it is mentioned in the draft. I thought this feature was not in draft-despres-softwire-4rd-00 at least the above sentence is not in the abstract. Have you attended 2009 BoF on A+P? There the message was clear: do not use A+P at the customer level. What is the point of bringing it back? 4rd does it or does it not already help in IPv4 address shortage? Regards, Behcet From despres.remi@laposte.net Thu Jul 12 00:38:16 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C5521F857D for ; Thu, 12 Jul 2012 00:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oPmqUNSe+Yy for ; Thu, 12 Jul 2012 00:38:15 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 207C721F8573 for ; Thu, 12 Jul 2012 00:38:10 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2519.sfr.fr (SMTP Server) with ESMTP id 59B0B7000068; Thu, 12 Jul 2012 09:38:42 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2519.sfr.fr (SMTP Server) with ESMTP id EA1EB700009C; Thu, 12 Jul 2012 09:38:41 +0200 (CEST) X-SFR-UUID: 20120712073841959.EA1EB700009C@msfrf2519.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 12 Jul 2012 09:38:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] Comment on draft-ietf-softwire-4rd-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 07:38:16 -0000 Hi, Behcet, In the abstract, "customers" is intended to mean customers *of = operators* (CPEs, not end-user hosts). This can be clarified by, for example, replacing "customers" by = "customer sites". Agreed? Thanks, RD Le 2012-07-11 =E0 21:41, Behcet Sarikaya a =E9crit : > Hi Remi, >=20 > I was reading this draft and one sentence in the abstract drew my = attention: >=20 > To cope with the IPv4 address shortage, customers can be > assigned IPv4 addresses with restricted port sets. >=20 > I think this means A+P at the customer level. >=20 > I was under the impression that A+P use in 4rd was restricted to the = CE level. >=20 > As you know A+P has limitations, i.e. it can not be used on shared > links such as 802.3 or 802.11. > I am not sure if it is mentioned in the draft. >=20 > I thought this feature was not in draft-despres-softwire-4rd-00 at > least the above sentence is not in the abstract. >=20 > Have you attended 2009 BoF on A+P? > There the message was clear: do not use A+P at the customer level. >=20 > What is the point of bringing it back? 4rd does it or does it not > already help in IPv4 address shortage? >=20 > Regards, >=20 > Behcet > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sarikaya2012@gmail.com Thu Jul 12 10:22:46 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EBD21F871D for ; Thu, 12 Jul 2012 10:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgmXZy+Q3T+e for ; Thu, 12 Jul 2012 10:22:45 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EEFB21F870B for ; Thu, 12 Jul 2012 10:22:45 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2904319ghb.31 for ; Thu, 12 Jul 2012 10:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=MtsaG7Oznq9QGTCWzxgHuK6Rye33LHb/V9ariovqKrs=; b=vB5HaeK3kZkw0gw6E6Ig8irOcYNdMHJ5ZszQikTlhoq0nkXyv44JpzMONV4OKpAt0A OPqOEmE5ckm1NEYQgfyYibO66B9quPO2uhP4gPOFJY7oiRruJW91LDQmqe5F4sjNqrGS N6aJJyweAXVG52pwnGsiD3Lplx7kAk/2HNzVtR7bPJ3ePrrwe/UrSl6zaY1eGZl4Vdex W85J17Iu9fJr2aRQcdAoFL2utFPBAc19yCaQr1+T+6YWu1Oh3h1bdOIDQ6Bn6EjcF9JV McILIfjSkn2PzcBjWBDuq407TaNgIkP4pDdO+tnqFEwGqYhOtu81t/WIldi5CwX6/fyd dV+Q== MIME-Version: 1.0 Received: by 10.50.154.233 with SMTP id vr9mr18628220igb.9.1342113798364; Thu, 12 Jul 2012 10:23:18 -0700 (PDT) Received: by 10.231.118.210 with HTTP; Thu, 12 Jul 2012 10:23:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 12:23:18 -0500 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg Subject: Re: [Softwires] Comment on draft-ietf-softwire-4rd-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 17:22:47 -0000 On Thu, Jul 12, 2012 at 2:38 AM, R=E9mi Despr=E9s wrote: > Hi, Behcet, > > In the abstract, "customers" is intended to mean customers *of operators*= (CPEs, not end-user hosts). > This can be clarified by, for example, replacing "customers" by "customer= sites". > Agreed? Agreed :-). That resolves my concern. My comment applies to MAP as well if the same support I mentioned exists there, I need to check it. Regards, Behcet > > Thanks, > RD > > > Le 2012-07-11 =E0 21:41, Behcet Sarikaya a =E9crit : > >> Hi Remi, >> >> I was reading this draft and one sentence in the abstract drew my attent= ion: >> >> To cope with the IPv4 address shortage, customers can be >> assigned IPv4 addresses with restricted port sets. >> >> I think this means A+P at the customer level. >> >> I was under the impression that A+P use in 4rd was restricted to the CE = level. >> >> As you know A+P has limitations, i.e. it can not be used on shared >> links such as 802.3 or 802.11. >> I am not sure if it is mentioned in the draft. >> >> I thought this feature was not in draft-despres-softwire-4rd-00 at >> least the above sentence is not in the abstract. >> >> Have you attended 2009 BoF on A+P? >> There the message was clear: do not use A+P at the customer level. >> >> What is the point of bringing it back? 4rd does it or does it not >> already help in IPv4 address shortage? >> >> Regards, >> >> Behcet >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From jacni@jacni.com Thu Jul 12 20:20:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD1A21F85C0 for ; Thu, 12 Jul 2012 20:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63gXxGgFmE94 for ; Thu, 12 Jul 2012 20:20:08 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1B821F85BB for ; Thu, 12 Jul 2012 20:20:07 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id EFCBB380234 for ; Thu, 12 Jul 2012 23:20:40 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 25ADD3400FC for ; Fri, 13 Jul 2012 11:20:39 +0800 (CST) Received: from [10.79.99.102] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJBrqwYDlP9PgsUZAA--.44300S2; Fri, 13 Jul 2012 11:20:36 +0800 (CST) Message-ID: <4FFF93FC.6090306@jacni.com> Date: Fri, 13 Jul 2012 11:20:28 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Yong Cui References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090607080706050100070004" X-CM-TRANSID: +AWowJBrqwYDlP9PgsUZAA--.44300S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZw1kWFyfur4xWw1rtF4kXrb_yoW5CF4rpa yfJw1xGr4ktr1rJw1DAw4jvr10kFn5tw4Yy3W5Gw18Zr98CF1jyF1YkryfXa4UGryrAr4U Zryjkw15Aas8Aw7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnmxYjsxI4VWkCwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCYjI0SjxkI62AI1cAE67vIY487MxAIw28IcxkI7VAKI48JMI8E67AF67kF1VAF wI0_Jrv_JF1lIxkGc2Ij64vIr4UvcSsGvfC2KfnxnUUI43ZEXa7IU0_WrtUUUUU== X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQENEko7lRpWxgAJs4 Cc: Softwires WG Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 03:20:09 -0000 This is a multi-part message in MIME format. --------------090607080706050100070004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Please see below the text updated according to the comments received. Many thanks to Stig, Simon, Shailesh, and others for their review and discussions. ---------------------------------------------------- 4.2. Multicast Distribution Tree Computation ... The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so as to represent the IPv4-embedded IPv6 source in the IPv6 multicast network, and to pass the Reverse Path Forwarding (RPF) check on multicast devices. 4.3. Multicast Data Forwarding ... /* A note is added*/ Note: At this point, only IPv4-in-IPv6 encapsulation is defined; Whether or not to support other types of encapsulation is left for future consideration. 6.1. IGMP-MLD Interworking Function The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying function and the address synthesizing operations. The IGMP/MLD Proxying function is specified in [RFC4605]. The address synthesizing is stateless and MUST follow [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052]. The mB4 with the IGMP-MLD Interworking Function embedded relays between the IGMP domain and the MLD domain. The mB4 performs the host portion of the MLD protocol on the upstream interface. The composition of IPv6 membership in this context is constructed through address synthesizing operations and MUST synchronize with the membership database maintained in the IGMP domain. MLD messages will be forwarded natively towards the MLD Querier located upstream in the IPv6 network. The mB4 also performs the router portion of the IGMP protocol on the downstream interface(s). Refer to [RFC4605] for more details +----------+ IGMP +-------+ MLD +---------+ | IPv4 |---------| mB4 |---------| MLD | | Receiver | | | | Querier | +----------+ +-------+ +---------+ Figure 2: IGMP-MLD Interworking If SSM is deployed, the mB4 MUST construct the IPv6 source address (or retrieve the IPv4 source address) using the uPrefix64. The mB4 may create a membership database which associates the IPv4-IPv6 multicast groups with the interfaces (e.g., Wi-Fi and Wired Ethernet) facing IPv4 multicast receivers. 7.2. Processing PIM Message /* TIB is used to replace mRIB*/ 7.5. TTL/Scope The Scope field of IPv4-in-IPv6 multicast addresses should be valued accordingly (e.g, to "E", Global scope;) in the deployment environment. This specification does not discuss the scope value that should be used. ------------------------------------------------------ Cheers, Jacni On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote: > Hi folks, > > This is a wg last call on draft-ietf-softwire-dslite-multicast-02. > http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ > > As usual, please send editorial comments to the authors and > substantive comments to the mailing list. > > This wg last call will end on June 10 at 12pm EDT. > > > Yong & Alain > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --------------090607080706050100070004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

Please see below the text updated according to the comments received.
Many thanks to Stig, Simon, Shailesh, and others for their review and discussions.

----------------------------------------------------
4.2.  Multicast Distribution Tree Computation

...

   The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so
   as to represent the IPv4-embedded IPv6 source in the IPv6 multicast
   network, and to pass the Reverse Path Forwarding (RPF) check on
   multicast devices.

4.3.  Multicast Data Forwarding

...
/* A note is added*/

   Note: At this point, only IPv4-in-IPv6 encapsulation is defined;
   Whether or not to support other types of encapsulation is left for
   future consideration.

6.1.  IGMP-MLD Interworking Function

   The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying
   function and the address synthesizing operations.  The IGMP/MLD
   Proxying function is specified in [RFC4605].  The address
   synthesizing is stateless and MUST follow
   [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052].

   The mB4 with the IGMP-MLD Interworking Function embedded relays
   between the IGMP domain and the MLD domain.  The mB4 performs the
   host portion of the MLD protocol on the upstream interface.  The
   composition of IPv6 membership in this context is constructed through
   address synthesizing operations and MUST synchronize with the
   membership database maintained in the IGMP domain.  MLD messages will
   be forwarded natively towards the MLD Querier located upstream in the
   IPv6 network.  The mB4 also performs the router portion of the IGMP
   protocol on the downstream interface(s).  Refer to [RFC4605] for more
   details


             +----------+   IGMP  +-------+   MLD   +---------+
             |   IPv4   |---------|  mB4  |---------|   MLD   |
             | Receiver |         |       |         | Querier |
             +----------+         +-------+         +---------+

                      Figure 2: IGMP-MLD Interworking

   If SSM is deployed, the mB4 MUST construct the IPv6 source address
   (or retrieve the IPv4 source address) using the uPrefix64.  The mB4
   may create a membership database which associates the IPv4-IPv6
   multicast groups with the interfaces (e.g., Wi-Fi and Wired Ethernet)
   facing IPv4 multicast receivers.


7.2. Processing PIM Message

/* TIB is used to replace mRIB*/


7.5.  TTL/Scope

   The Scope field of IPv4-in-IPv6 multicast addresses should be valued
   accordingly (e.g, to "E", Global scope;) in the deployment
   environment.  This specification does not discuss the scope value
   that should be used.
------------------------------------------------------


Cheers,
Jacni
On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote:
Hi folks,

This is a wg last call on draft-ietf-softwire-dslite-multicast-02.
http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/

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

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


Yong & Alain



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


--------------090607080706050100070004-- From jacni@jacni.com Thu Jul 12 20:21:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E67821F85D4 for ; Thu, 12 Jul 2012 20:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giTHvmEpZAMY for ; Thu, 12 Jul 2012 20:21:13 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id CC17B21F85C0 for ; Thu, 12 Jul 2012 20:21:13 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 59B9F380234 for ; Thu, 12 Jul 2012 23:21:48 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id D4121340115 for ; Fri, 13 Jul 2012 11:21:46 +0800 (CST) Received: from [10.79.99.102] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJCbLwJJlP9PEMYZAA--.45151S2; Fri, 13 Jul 2012 11:21:46 +0800 (CST) Message-ID: <4FFF9443.8060903@jacni.com> Date: Fri, 13 Jul 2012 11:21:39 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> <4FEBEA85.6010201@jacni.com> <4FEC9270.1050500@venaas.com> <4FF1C59A.6020600@jacni.com> <4FF1E111.9020201@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: +AWowJCbLwJJlP9PEMYZAA--.45151S2 X-Coremail-Antispam: 1UD129KBjvJXoW3Gr13ZFyxZr4xZrWDtry7KFg_yoWxGFW8pa y8Ga1UKr4kJrWrAwn2yw1rZ3Wjyw4IqrWUXwn8JryUZ3s8tF1Dtr1ftr45CFyDWrn5Wr42 vF1DCry3W3WYy3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUU0bIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnA8YjsxI4VWkKwAYFVCjjxCrM7AEwI8IwI0E74AGY7Cv6cx26r4UM7CY 07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7V C0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41lc7I2 V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwC2zVAF1VAY17CE14v26r126r1DMI IYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07jVoGdUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQENEko7lRpWxgAKs7 Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 03:21:14 -0000 On 7/10/2012 Tuesday 4:46 AM, Behcet Sarikaya wrote: > Well, from the so many mails below it is clear that No, it's clearly clarified from the mails, about the motive, and the problems to be solved. > draft-ietf-softwire-dslite-multicast-02 is anything but multicast > extensions document for DS-Lite. And it's clear that the "extensions" are definitely NOT to simply use the unicast tunnel for multicast delivery in DS-Lite deployment. Cheers, Jacni > > Anyway we need to put this into the issue tracker as Suresh asked. > > Behcet > > On Mon, Jul 2, 2012 at 12:57 PM, Stig Venaas wrote: >> Hi >> >> >> On 7/2/2012 9:00 AM, Jacni Qin wrote: >>> Hi Stig, >>> >>> Inline please, >>> >>> On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote: >>>> On 6/27/2012 10:24 PM, Jacni Qin wrote: >>>>> Hi Stig, >>>>> >>>>> Thanks for you comments and support, please see below inline. >>>>> >>>>> On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote: >>>>>> FWIW, here is my take on this. >>>>>> >>>>>> >>>>>> On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: >>>>>> [...] >>>>>>> That's a big IF. Not everybody has to do it the same way. >>>>>>> >>>>>>> The solution in draft-ietf-softwire-dslite-multicast-02 >>>>>>> builds itself something without considering what DS-Lite is doing. >>>>>>> As I told you before, DS-Lite unicast is a tunneling technology. If >>>>>>> you don't like it it is not DS-Lite multicast to fix this. >>>>>>> How many times this should be reminded to you? >>>>>> >>>>>> draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing >>>>>> specific to DS-Lite, and I've been saying that the draft should be >>>>>> updated to reflect that. >>>>>> >>>>>> However, even though it is generic, I think it is a good solution for >>>>>> use in DS-Lite deployments (in addition to many other deployments). >>>>> As discussed in the previous messages of the thread, our motive is solve >>>>> the problems >>>>> for those who want multicast in their DS-Lite deployment. >>>>> So we limited the scope. Where the DS-Lite is not deployed, it doesn't >>>>> apply. >>>> >>>> I understand that the motive is to have a solution for DS-Lite, but IMO >>>> the key part is the solution itself. I think you should focus on the >>>> solution and then discuss how it can be used in several scenarios, where >>>> DS-Lite is one of them. >>> Yes, we're focusing on the solution itself, and there is a Problem >>> Statement draft >>> discussing several scenarios during the transition of multicast. ;-) >>> >>>> Wouldn't it be a shame if people have a need for your solution, but are >>>> not aware of it, or doesn't consider it because they think it only >>>> applies to DS-Lite? >>>> >>>> Don't you agree that we should generally find good generic solutions and >>>> describe them as such? We don't want to write basically identical docs >>>> for each scenario. And in the worst case instead of having a single good >>>> solution, having solutions that are only almost identical, maybe >>>> requiring multiple slightly different implementations to solve each of >>>> the problems, where a single solution and a single implementation would >>>> be sufficient? >>>> >>>> As a general principle when you come up with a solution to a problem, >>>> don't you try to see what else it can solve, and try to present it as >>>> a solution to all the problems? At least that is always my thinking. >>> I totally understand your point and logic. >>> >>> In addition to the motive, based on lessons learnt from what we did for >>> unicast solutions, it's been concluded that working on the scenarios with >>> high priority is a better choice. So we did that following the WG's >>> charter. >> >> I think you could make it more generic by changing the title, and >> minor changes to abstract/intro. >> >> You could say that this was designed to allow for multicast in DS-Lite, >> but that it also applies to other cases where you need to provide IPv4 >> multicast through an IPv6 multicast network or something like that. >> >> >>> We ever know trying a single solution for all is not a good idea. >> >> Yes, but your solution is more useful than just DS-Lite. You have no >> dependency of DS-Lite, right? >> >> Stig >> >> >>> And as mentioned above, I think the draft, >>> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00 >>> will say clearly about the background, our choices, what led to this, >>> and will >>> help people to analyze their requirements/scenarios, then to find an >>> appropriate solution. >>> >>>> It looks like we may disagree on this. I'm hoping I can make people see >>>> the merits of making general solutions and presenting them as such. At >>>> least for me, that seems like a good thing to strive for. >>> Ideally, I like general solutions as well. While for transition, as for >>> unicast, I believe >>> we should try another way. :-) >>> >>>> I know I've been repeating myself several times in emails to the list. >>>> I feel strongly about this as a general principle. I don't know what >>>> more I can say to stress my point though. >>> Thanks for your patience and the discussion anyway, it helps for the >>> clarifications. >>> >>> >>> Cheers, >>> Jacni >>> >>>> Stig >>>> >>>>> If some pieces of the approach can be reused in the future, to solve the >>>>> multicast issues in >>>>> other deployments, that'd be good. >>>>> While personally, I'd prefer we stay focus on the currently scenario. >>>>> Extensions if needed, may be raised respectively for other deployments. >>>>> More are detailed in, >>>>> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. >>>>> >>>>> >>>>> Cheers, >>>>> Jacni >>>>>> >>>>>> Whether additional solutions are needed for DS-Lite is something the >>>>>> WG should consider. Maybe it already has, I haven't paid enough >>>>>> attention. >>>>>> >>>>>> Stig >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>> >>>> >>>> >>>> >>> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From stig@venaas.com Thu Jul 12 22:43:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AF521F8707 for ; Thu, 12 Jul 2012 22:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0Bzo7va99Rx for ; Thu, 12 Jul 2012 22:43:20 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id F189421F86D6 for ; Thu, 12 Jul 2012 22:43:19 -0700 (PDT) Received: from [10.21.146.36] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D8A827FCE; Fri, 13 Jul 2012 07:43:45 +0200 (CEST) Message-ID: <4FFFB5AD.9060606@venaas.com> Date: Thu, 12 Jul 2012 22:44:13 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jacni Qin References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> <4FEBEA85.6010201@jacni.com> <4FEC9270.1050500@venaas.com> <4FF1C59A.6020600@jacni.com> <4FF1E111.9020201@venaas.com> <4FFF9443.8060903@jacni.com> In-Reply-To: <4FFF9443.8060903@jacni.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 05:43:21 -0000 On 12.07.2012 20:21, Jacni Qin wrote: > > On 7/10/2012 Tuesday 4:46 AM, Behcet Sarikaya wrote: >> Well, from the so many mails below it is clear that > No, it's clearly clarified from the mails, about the motive, and the > problems to be solved. > >> draft-ietf-softwire-dslite-multicast-02 is anything but multicast >> extensions document for DS-Lite. > And it's clear that the "extensions" are definitely NOT to simply use > the unicast tunnel for multicast delivery > in DS-Lite deployment. FWIW, I think the document is a good solution for multicast in a DS-Lite environment. I just would like some modifications to the document to reflect that it is a more generic solution. Stig > > > Cheers, > Jacni > >> >> Anyway we need to put this into the issue tracker as Suresh asked. >> >> Behcet >> >> On Mon, Jul 2, 2012 at 12:57 PM, Stig Venaas wrote: >>> Hi >>> >>> >>> On 7/2/2012 9:00 AM, Jacni Qin wrote: >>>> Hi Stig, >>>> >>>> Inline please, >>>> >>>> On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote: >>>>> On 6/27/2012 10:24 PM, Jacni Qin wrote: >>>>>> Hi Stig, >>>>>> >>>>>> Thanks for you comments and support, please see below inline. >>>>>> >>>>>> On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote: >>>>>>> FWIW, here is my take on this. >>>>>>> >>>>>>> >>>>>>> On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: >>>>>>> [...] >>>>>>>> That's a big IF. Not everybody has to do it the same way. >>>>>>>> >>>>>>>> The solution in draft-ietf-softwire-dslite-multicast-02 >>>>>>>> builds itself something without considering what DS-Lite is doing. >>>>>>>> As I told you before, DS-Lite unicast is a tunneling technology. If >>>>>>>> you don't like it it is not DS-Lite multicast to fix this. >>>>>>>> How many times this should be reminded to you? >>>>>>> >>>>>>> draft-ietf-softwire-dslite-multicast-02 is a generic solution, >>>>>>> nothing >>>>>>> specific to DS-Lite, and I've been saying that the draft should be >>>>>>> updated to reflect that. >>>>>>> >>>>>>> However, even though it is generic, I think it is a good solution >>>>>>> for >>>>>>> use in DS-Lite deployments (in addition to many other deployments). >>>>>> As discussed in the previous messages of the thread, our motive is >>>>>> solve >>>>>> the problems >>>>>> for those who want multicast in their DS-Lite deployment. >>>>>> So we limited the scope. Where the DS-Lite is not deployed, it >>>>>> doesn't >>>>>> apply. >>>>> >>>>> I understand that the motive is to have a solution for DS-Lite, but >>>>> IMO >>>>> the key part is the solution itself. I think you should focus on the >>>>> solution and then discuss how it can be used in several scenarios, >>>>> where >>>>> DS-Lite is one of them. >>>> Yes, we're focusing on the solution itself, and there is a Problem >>>> Statement draft >>>> discussing several scenarios during the transition of multicast. ;-) >>>> >>>>> Wouldn't it be a shame if people have a need for your solution, but >>>>> are >>>>> not aware of it, or doesn't consider it because they think it only >>>>> applies to DS-Lite? >>>>> >>>>> Don't you agree that we should generally find good generic >>>>> solutions and >>>>> describe them as such? We don't want to write basically identical docs >>>>> for each scenario. And in the worst case instead of having a single >>>>> good >>>>> solution, having solutions that are only almost identical, maybe >>>>> requiring multiple slightly different implementations to solve each of >>>>> the problems, where a single solution and a single implementation >>>>> would >>>>> be sufficient? >>>>> >>>>> As a general principle when you come up with a solution to a problem, >>>>> don't you try to see what else it can solve, and try to present it as >>>>> a solution to all the problems? At least that is always my thinking. >>>> I totally understand your point and logic. >>>> >>>> In addition to the motive, based on lessons learnt from what we did for >>>> unicast solutions, it's been concluded that working on the scenarios >>>> with >>>> high priority is a better choice. So we did that following the WG's >>>> charter. >>> >>> I think you could make it more generic by changing the title, and >>> minor changes to abstract/intro. >>> >>> You could say that this was designed to allow for multicast in DS-Lite, >>> but that it also applies to other cases where you need to provide IPv4 >>> multicast through an IPv6 multicast network or something like that. >>> >>> >>>> We ever know trying a single solution for all is not a good idea. >>> >>> Yes, but your solution is more useful than just DS-Lite. You have no >>> dependency of DS-Lite, right? >>> >>> Stig >>> >>> >>>> And as mentioned above, I think the draft, >>>> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00 >>>> will say clearly about the background, our choices, what led to this, >>>> and will >>>> help people to analyze their requirements/scenarios, then to find an >>>> appropriate solution. >>>> >>>>> It looks like we may disagree on this. I'm hoping I can make people >>>>> see >>>>> the merits of making general solutions and presenting them as such. At >>>>> least for me, that seems like a good thing to strive for. >>>> Ideally, I like general solutions as well. While for transition, as for >>>> unicast, I believe >>>> we should try another way. :-) >>>> >>>>> I know I've been repeating myself several times in emails to the list. >>>>> I feel strongly about this as a general principle. I don't know what >>>>> more I can say to stress my point though. >>>> Thanks for your patience and the discussion anyway, it helps for the >>>> clarifications. >>>> >>>> >>>> Cheers, >>>> Jacni >>>> >>>>> Stig >>>>> >>>>>> If some pieces of the approach can be reused in the future, to >>>>>> solve the >>>>>> multicast issues in >>>>>> other deployments, that'd be good. >>>>>> While personally, I'd prefer we stay focus on the currently scenario. >>>>>> Extensions if needed, may be raised respectively for other >>>>>> deployments. >>>>>> More are detailed in, >>>>>> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Jacni >>>>>>> >>>>>>> Whether additional solutions are needed for DS-Lite is something the >>>>>>> WG should consider. Maybe it already has, I haven't paid enough >>>>>>> attention. >>>>>>> >>>>>>> Stig >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Softwires mailing list >>>>>> Softwires@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires > > From tom.taylor.stds@gmail.com Fri Jul 13 06:22:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FAC21F8864 for ; Fri, 13 Jul 2012 06:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZYF-zlL6tuJ for ; Fri, 13 Jul 2012 06:22:23 -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 2820221F8863 for ; Fri, 13 Jul 2012 06:22:22 -0700 (PDT) Received: by bkty7 with SMTP id y7so2805139bkt.31 for ; Fri, 13 Jul 2012 06:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=ypO0ibxao7RqnDVCZW2TT4Wo3xcGLb3zKymh8fx9HzI=; b=bFpOTsEHmnhnVCnfZVb2b2TxWk1vf4OZH4QqOq9JbKDHA+XRpBjX82aqpMjtLd1jqA 1PzelfAHftRRvFnjc6ogLHjjpmiOUUurayVgMtqtrkDcG9LoIKVT9IvCZMWx8KWjpz5i ItOD0pYfNFCyJDpwfOl4lC9W9PpcIvT4UDPNFD8/nairJFpI8unkvCCfMquQgbiPw+4/ zXgtOs7IySVijtxVno+Jt73v8V8ww4AIcxWDuLBpqVUnYCB3YJX3Ba3H9KHCwxaIX0Ws kR0MvDNAy6ki/BKC8sVpJ2jc/XT77t7s+cmYrUyp8+uaCCxhvNzgtHIj/bHNj4+1SUtO hLIQ== Received: by 10.204.128.65 with SMTP id j1mr846313bks.93.1342185778613; Fri, 13 Jul 2012 06:22:58 -0700 (PDT) Received: from [127.0.0.1] ([207.112.101.80]) by mx.google.com with ESMTPS id c18sm4756492bkv.8.2012.07.13.06.22.57 (version=SSLv3 cipher=OTHER); Fri, 13 Jul 2012 06:22:58 -0700 (PDT) Message-ID: <50002130.5080000@gmail.com> Date: Fri, 13 Jul 2012 09:22:56 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stig Venaas References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> <4FEBEA85.6010201@jacni.com> <4FEC9270.1050500@venaas.com> <4FF1C59A.6020600@jacni.com> <4FF1E111.9020201@venaas.com> <4FFF9443.8060903@jacni.com> <4FFFB5AD.9060606@venaas.com> In-Reply-To: <4FFFB5AD.9060606@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120713-0, 13/07/2012), Outbound message X-Antivirus-Status: Clean Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 13:22:24 -0000 On 13/07/2012 1:44 AM, Stig Venaas wrote: > On 12.07.2012 20:21, Jacni Qin wrote: >> >> On 7/10/2012 Tuesday 4:46 AM, Behcet Sarikaya wrote: >>> Well, from the so many mails below it is clear that >> No, it's clearly clarified from the mails, about the motive, and the >> problems to be solved. >> >>> draft-ietf-softwire-dslite-multicast-02 is anything but multicast >>> extensions document for DS-Lite. >> And it's clear that the "extensions" are definitely NOT to simply use >> the unicast tunnel for multicast delivery >> in DS-Lite deployment. > > FWIW, I think the document is a good solution for multicast in a DS-Lite > environment. I just would like some modifications to the document to > reflect that it is a more generic solution. > > Stig > .. I heartily agree with Stig. I think the WG has the choice either to generalize this document or accept draft-tsou-softwire-6rd-multicast-01 as a parallel solution for the 6rd environment. A single more general document makes more sense. Tom From bingxuere@gmail.com Fri Jul 13 08:58:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C50B21F8709 for ; Fri, 13 Jul 2012 08:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIeVS0BYGLRM for ; Fri, 13 Jul 2012 08:58:54 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68DB821F86FD for ; Fri, 13 Jul 2012 08:58:54 -0700 (PDT) Received: by ggnc4 with SMTP id c4so4073555ggn.31 for ; Fri, 13 Jul 2012 08:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=axrXvt53bI8crc/SJMua3o+Ep1JcNg81TmGzK4vQSbk=; b=tyS3FJWFOTHVvF0lcBCYTPfi4SrTL2/9B6hP4w4eSBEvfhmDEhZ0IrqVJhH8RSEYv/ ExJHNiR4yLSqiu0wrmSeDjKOve+iHI/RRU0zQ+bnn9COsqQdV4jJBdVbaramlDnV3DlX u2xsl773BVrUgpbGFX6OuD618WNcmHbu3Rc1orHgF2LkrN77tCR37yaaDvQAyUJStnom K7R8G5SshJ/gq2bvAG3RMaPLaaeXuWP8fMl3YRc/acYzlSE43sPiCluzza6Jm7QDYSOl m1aiIakiUBbWMlbGTGbdf1iovxMWqFILchQqz9eap7hf/S/v5EtKpVJ6lI7TPyrMpAjG 5Kyg== Received: by 10.42.145.7 with SMTP id d7mr1167962icv.45.1342195170212; Fri, 13 Jul 2012 08:59:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Fri, 13 Jul 2012 08:58:50 -0700 (PDT) From: Qiong Date: Fri, 13 Jul 2012 23:58:50 +0800 Message-ID: To: softwires@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6136b856fa1e04c4b82a16 Cc: Yong Cui Subject: [Softwires] Fwd: New Version Notification for draft-cui-softwire-b4-translated-ds-lite-07.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 15:58:55 -0000 --90e6ba6136b856fa1e04c4b82a16 Content-Type: text/plain; charset=UTF-8 Hi, all, We have published a -07 version of lightweight 4over6. This new version improves the preciseness of the ICMP handling mechanism description. Up to now, this draft has finished merging with I-D.zhou-softwire-b4-nat and I-D.penno-softwire-sdnat as requested by the WG and has settled all the technical details based on comments from the WG. It reflects widely requirements from 7 operators including China Telecom, Tsinghua, Comcast, France Telecom, Deutsche Telekom,Bouygues Telecom and Freebits, and vendors from Huawei, Juniper and Cisco. It has running code already published in http://sourceforge.net/projects/laft6/ and has a field trial in commerial network. >From the authors of this document's view, it is ready to be adopted as working group document. We would be appreciated to have your comments. Thanks in advance ! Best wishes Qiong ---------- Forwarded message ---------- A new version of I-D, draft-cui-softwire-b4-translated-ds-lite-07.txt has been successfully submitted by Ian Farrer and posted to the IETF repository. Filename: draft-cui-softwire-b4-translated-ds-lite Revision: 07 Title: Lightweight 4over6: An Extension to the DS-Lite Architecture Creation date: 2012-07-13 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-cui-softwire-b4-translated-ds-lite-07.txt Status: http://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite Htmlized: http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-07 Diff: http://tools.ietf.org/rfcdiff?url2=draft-cui-softwire-b4-translated-ds-lite-07 Abstract: This document specifies an extension to DS-Lite called Lightweight 4over6. This mechanism moves the translation function from the tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the mapping scale on the concentrator to a per-subscriber level. To delegate the NAPT function to the initiators, port-restricted IPv4 addresses are allocated to the initiators. The IETF Secretariat -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --90e6ba6136b856fa1e04c4b82a16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, all,

We have published a -07 version of lightweight 4over6. This= new version improves the preciseness of the ICMP handling mechanism descri= ption.

Up to now, this draft has finished merging with I-D.zhou-soft= wire-b4-nat and I-D.penno-softwire-sdnat as requested by the WG and has set= tled all the technical details based on comments from the WG. It reflects w= idely requirements from 7 operators including China Telecom, Tsinghua, Comc= ast, France Telecom, Deutsche Telekom,Bouygues Telecom and Freebits, and ve= ndors from Huawei, Juniper and Cisco. It has running code already published= in http://sourceforge.n= et/projects/laft6/ and has a field trial in commerial network.

From the authors of this document's view, it is ready to be adopted= as=20 working group document. We would be appreciated to have your comments.
=
Thanks in advance !

Best wishes
Qiong

---------- Forwa= rded message ----------

A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-= D,=C2=A0draft-cui-softwire-b4-translated-ds-lite-07.txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Ian=C2=A0F= arrer=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
=C2=A0
Filename: =C2=A0draft-cui-softwire-b4-translated-ds-lite
Revision: =C2=A007
Title: =C2=A0Lightweight=C2=A04over6:=C2=A0An=C2=A0Extension=C2=A0to= =C2=A0the=C2=A0DS-Lite=C2=A0Architecture
Creation=C2=A0date: =C2=A02012-07-13
WG=C2=A0ID: =C2=A0Individual=C2=A0Submission
Number=C2=A0of=C2=A0pages:=C2=A016
=C2=A0
Abstract:
=C2=A0=C2=A0=C2=A0This=C2=A0document=C2=A0specifies=C2=A0an=C2=A0exten= sion=C2=A0to=C2=A0DS-Lite=C2=A0called=C2=A0Lightweight
=C2=A0=C2=A0=C2=A04over6.=C2=A0=C2=A0This=C2=A0mechanism=C2=A0moves=C2= =A0the=C2=A0translation=C2=A0function=C2=A0from=C2=A0the
=C2=A0=C2=A0=C2=A0tunnel=C2=A0concentrator=C2=A0(AFTR)=C2=A0to=C2=A0in= itiators=C2=A0(B4s),=C2=A0and=C2=A0hence=C2=A0reduces=C2=A0the
=C2=A0=C2=A0=C2=A0mapping=C2=A0scale=C2=A0on=C2=A0the=C2=A0concentrato= r=C2=A0to=C2=A0a=C2=A0per-subscriber=C2=A0level.=C2=A0=C2=A0To
=C2=A0=C2=A0=C2=A0delegate=C2=A0the=C2=A0NAPT=C2=A0function=C2=A0to=C2= =A0the=C2=A0initiators,=C2=A0port-restricted=C2=A0IPv4
=C2=A0=C2=A0=C2=A0addresses=C2=A0are=C2=A0allocated=C2=A0to=C2=A0the= =C2=A0initiators.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0
=C2=A0
The=C2=A0IETF=C2=A0Secretariat


--
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 SunChina Telecom Beijing Research Institude


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

--90e6ba6136b856fa1e04c4b82a16-- From stig@venaas.com Fri Jul 13 13:56:49 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D236B11E80FF for ; Fri, 13 Jul 2012 13:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u79YqVu-vHiY for ; Fri, 13 Jul 2012 13:56:48 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 7B31211E80FD for ; Fri, 13 Jul 2012 13:56:48 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D0ECE7FB9; Fri, 13 Jul 2012 22:57:23 +0200 (CEST) Message-ID: <50008BAD.8060802@venaas.com> Date: Fri, 13 Jul 2012 13:57:17 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jacni Qin References: <4FFF93FC.6090306@jacni.com> In-Reply-To: <4FFF93FC.6090306@jacni.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 20:56:50 -0000 On 7/12/2012 8:20 PM, Jacni Qin wrote: > Hi all, > > Please see below the text updated according to the comments received. > Many thanks to Stig, Simon, Shailesh, and others for their review and > discussions. Thanks, this addresses at least some of my concerns. Let me try to list the issues I mentioned in my review that I think may not be addressed. 1. Update the text to make it clear it is a generic solution, but with applicability to DS-Lite. 2. It refers to draft-ietf-mboned-64-multicast-address-format-01. I think may need to wait and see what happens to this. It depends on discussion in the ipv6 wg whether this format will be chosen. The examples in this draft may need to be updated depending on the format chosen. 3. In 4.2 it says "The MLD Querier (typically acts as the PIMv6 Designated Router)", but if there are multiple routers, then the querier is typically not the DR. 4. Talk about what tunnel types are used. Either pick a specific type, or I think better, explain how this solution can be used with different types. E.g. IPv4 in IPv6, and GRE. 5. Security considerations should say something about scoping I think. How scopes for v4 and v6 may differ, and also how one can in a global IPv6 group specify a non-global IPv4 group... Some kind of filtering should be in place to protect against this. Apart from this I had only minor comments which hopefully will be addressed in the next version. Stig > > ---------------------------------------------------- > 4.2. Multicast Distribution Tree Computation > > ... > > The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so > as to represent the IPv4-embedded IPv6 source in the IPv6 multicast > network, and to pass the Reverse Path Forwarding (RPF) check on > multicast devices. > > 4.3. Multicast Data Forwarding > > ... > /* A note is added*/ > > Note: At this point, only IPv4-in-IPv6 encapsulation is defined; > Whether or not to support other types of encapsulation is left for > future consideration. > > 6.1. IGMP-MLD Interworking Function > > The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying > function and the address synthesizing operations. The IGMP/MLD > Proxying function is specified in [RFC4605]. The address > synthesizing is stateless and MUST follow > [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052]. > > The mB4 with the IGMP-MLD Interworking Function embedded relays > between the IGMP domain and the MLD domain. The mB4 performs the > host portion of the MLD protocol on the upstream interface. The > composition of IPv6 membership in this context is constructed through > address synthesizing operations and MUST synchronize with the > membership database maintained in the IGMP domain. MLD messages will > be forwarded natively towards the MLD Querier located upstream in the > IPv6 network. The mB4 also performs the router portion of the IGMP > protocol on the downstream interface(s). Refer to [RFC4605] for more > details > > > +----------+ IGMP +-------+ MLD +---------+ > | IPv4 |---------| mB4 |---------| MLD | > | Receiver | | | | Querier | > +----------+ +-------+ +---------+ > > Figure 2: IGMP-MLD Interworking > > If SSM is deployed, the mB4 MUST construct the IPv6 source address > (or retrieve the IPv4 source address) using the uPrefix64. The mB4 > may create a membership database which associates the IPv4-IPv6 > multicast groups with the interfaces (e.g., Wi-Fi and Wired Ethernet) > facing IPv4 multicast receivers. > > > 7.2. Processing PIM Message > > /* TIB is used to replace mRIB*/ > > > 7.5. TTL/Scope > > The Scope field of IPv4-in-IPv6 multicast addresses should be valued > accordingly (e.g, to "E", Global scope;) in the deployment > environment. This specification does not discuss the scope value > that should be used. > ------------------------------------------------------ > > > Cheers, > Jacni > > > On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote: >> Hi folks, >> >> This is a wg last call on draft-ietf-softwire-dslite-multicast-02. >> http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ >> >> As usual, please send editorial comments to the authors and >> substantive comments to the mailing list. >> >> This wg last call will end on June 10 at 12pm EDT. >> >> >> Yong & Alain >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From pengwu.thu@gmail.com Sat Jul 14 04:45:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE2B21F8711 for ; Sat, 14 Jul 2012 04:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnZzGvqX9-Rw for ; Sat, 14 Jul 2012 04:45:31 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id DEE1C21F869D for ; Sat, 14 Jul 2012 04:45:30 -0700 (PDT) Received: by qaea16 with SMTP id a16so779063qae.10 for ; Sat, 14 Jul 2012 04:46:09 -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=ac0I41KprqoTQpxLziWdrdXfobkc6fFEw/T3flsstVA=; b=iO2x/+D/GyCxgDcunPGvgx779IUypc99KZW1CSVXbNo3Tt2W17/+jsXKEmUhKHin7P FbZcto94xOep1UDm6Pu2xzrusf4LW52lbOtIgMqWU5MMcwsYkAvpq9PMF8nC3BFnqhTE V1bMlZgFdfruiHjJ4IxVBCbMSuuTdd+0o1fWsHXek1epLcsXPJP9JH0H6NbJTIHRkuPB A+DGrNUEbDecvspvvz04wHrEVFuyk8XDWBtitFvA+oNAld+1flrxcmwIuV2jz8K7sAGn EmlH83qDzMk4G+v0UulV8g62W/VycIosDPSr+fRHsRG5d4paQXPV+hb+3dUjGQE2/fT1 Rb4Q== MIME-Version: 1.0 Received: by 10.224.194.1 with SMTP id dw1mr162487qab.27.1342266369261; Sat, 14 Jul 2012 04:46:09 -0700 (PDT) Received: by 10.229.135.77 with HTTP; Sat, 14 Jul 2012 04:46:09 -0700 (PDT) In-Reply-To: References: Date: Sat, 14 Jul 2012 19:46:09 +0800 Message-ID: From: Peng Wu To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires-wg Subject: Re: [Softwires] Comment on draft-ietf-softwire-4rd-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 11:45:31 -0000 Hi Behcet, About the statement of "do not use A+P at the customer level", could you provide some background information, For example list the reasons? BTW, for the record, what does "customer" mean exactly here? Is home gateway also a customer-level terminology, or you only mean do not apply A+P to IPv6-connected host? Thanks a lot. On Thu, Jul 12, 2012 at 3:41 AM, Behcet Sarikaya wrote: > Hi Remi, > > I was reading this draft and one sentence in the abstract drew my attention: > > To cope with the IPv4 address shortage, customers can be > assigned IPv4 addresses with restricted port sets. > > I think this means A+P at the customer level. > > I was under the impression that A+P use in 4rd was restricted to the CE level. > > As you know A+P has limitations, i.e. it can not be used on shared > links such as 802.3 or 802.11. > I am not sure if it is mentioned in the draft. > > I thought this feature was not in draft-despres-softwire-4rd-00 at > least the above sentence is not in the abstract. > > Have you attended 2009 BoF on A+P? > There the message was clear: do not use A+P at the customer level. > > What is the point of bringing it back? 4rd does it or does it not > already help in IPv4 address shortage? > > Regards, > > Behcet > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Sat Jul 14 18:52:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6865021F85EF; Sat, 14 Jul 2012 18:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 UvGzQyXmKtXy; Sat, 14 Jul 2012 18:52:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20E521F85B8; Sat, 14 Jul 2012 18:52:02 -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.30p3 Message-ID: <20120715015202.24255.97598.idtracker@ietfa.amsl.com> Date: Sat, 14 Jul 2012 18:52:02 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-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: Sun, 15 Jul 2012 01:52:03 -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-03.txt Pages : 27 Date : 2012-07-14 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-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-mesh-multicast-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jul 15 20:56:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDDD11E80C7; Sun, 15 Jul 2012 20:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 ea3ZuP5dhvTW; Sun, 15 Jul 2012 20:56:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6364811E807F; Sun, 15 Jul 2012 20:56:40 -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.30p3 Message-ID: <20120716035640.14481.37732.idtracker@ietfa.amsl.com> Date: Sun, 15 Jul 2012 20:56:40 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-public-4over6-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, 16 Jul 2012 03:56:41 -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-02.txt Pages : 13 Date : 2012-07-15 Abstract: When the service provider networks are upgraded to IPv6, IPv4 connectivity will still be demanded by network users, at least in the recent future. This draft proposes a mechanism for end hosts or networks in IPv6 access networks to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the softwire hub and spoke model, and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. The bi-directionality of end-to-end communication is achieved by allocating public IPv4 addresses to end hosts/networks, with no dependency on IPv6 addressing. 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-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-public-4over6-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jacni@jacni.com Mon Jul 16 08:46:52 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C74D21F86F2 for ; Mon, 16 Jul 2012 08:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L39b6CC5wGbg for ; Mon, 16 Jul 2012 08:46:52 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id 04B0421F86F1 for ; Mon, 16 Jul 2012 08:46:51 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 46C09380200 for ; Mon, 16 Jul 2012 11:47:35 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id 9804A3400EF for ; Mon, 16 Jul 2012 23:47:33 +0800 (CST) Received: from [10.79.103.103] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJAL_QOPNwRQN5UdAA--.48059S2; Mon, 16 Jul 2012 23:47:33 +0800 (CST) Message-ID: <5004378D.6070304@jacni.com> Date: Mon, 16 Jul 2012 23:47:25 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tom Taylor References: <94C682931C08B048B7A8645303FDC9F36E331FF091@PUEXCB1B.nanterre.francetelecom.fr> <4FE8007D.7000102@jacni.com> <4FE8F609.1040407@jacni.com> <4FEB6831.5060100@venaas.com> <4FEBEA85.6010201@jacni.com> <4FEC9270.1050500@venaas.com> <4FF1C59A.6020600@jacni.com> <4FF1E111.9020201@venaas.com> <4FFF9443.8060903@jacni.com> <4FFFB5AD.9060606@venaas.com> <50002130.5080000@gmail.com> In-Reply-To: <50002130.5080000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: +AWowJAL_QOPNwRQN5UdAA--.48059S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Cw1DCry5Xr1fZr47WryDWrg_yoW8XrWfp3 4DG3W2gFs7ZrWayw1jyw1kuryIya1xtr4jkas8Jw45Aay5W340qw1rKa15uF9rXr4kZayj va9Fkr9xW3WYk3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUU0bIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnA8YjsxI4VWxJwAYFVCjjxCrM7AEwI8IwI0E74AGY7Cv6cx26r4UM7CY 07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7V C0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lF7xvr2IY64vIr41lc7I2 V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwC2zVAF1VAY17CE14v26r126r1DMI IYrxkI7VAKI48JYxBIdaVFxhVjvjDU0xZFpf9x07j-3ktUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAREko7lRsISgAAs- Cc: Softwires-wg , Behcet Sarikaya Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 15:46:52 -0000 On 7/13/2012 Friday 9:22 PM, Tom Taylor wrote: > > > On 13/07/2012 1:44 AM, Stig Venaas wrote: >> On 12.07.2012 20:21, Jacni Qin wrote: >>> >>> On 7/10/2012 Tuesday 4:46 AM, Behcet Sarikaya wrote: >>>> Well, from the so many mails below it is clear that >>> No, it's clearly clarified from the mails, about the motive, and the >>> problems to be solved. >>> >>>> draft-ietf-softwire-dslite-multicast-02 is anything but multicast >>>> extensions document for DS-Lite. >>> And it's clear that the "extensions" are definitely NOT to simply use >>> the unicast tunnel for multicast delivery >>> in DS-Lite deployment. >> >> FWIW, I think the document is a good solution for multicast in a DS-Lite >> environment. I just would like some modifications to the document to >> reflect that it is a more generic solution. >> >> Stig >> > .. > I heartily agree with Stig. I think the WG has the choice either to > generalize this document or accept > draft-tsou-softwire-6rd-multicast-01 as a parallel solution for the > 6rd environment. A single more general document makes more sense. What you're talking is totally different from Stig's. As we all know, the ONLY target scenario of this document is DS-Lite environment, even we loose the text and make the door open for the current mechanisms to be reused by future possible scenarios, there won't be any overlap with the target scenario of draft-tsou-softwire-6rd-multicast-01. So I think parallel solutions are better. Cheers, Jacni > > Tom > > From jacni@jacni.com Mon Jul 16 09:04:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD8921F85E6 for ; Mon, 16 Jul 2012 09:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNy9w9rXlY1H for ; Mon, 16 Jul 2012 09:04:20 -0700 (PDT) Received: from srv05.olivemail.cn (mx100.vip.olivemail.net [74.82.185.218]) by ietfa.amsl.com (Postfix) with ESMTP id DA75121F85DF for ; Mon, 16 Jul 2012 09:04:19 -0700 (PDT) Received: from srv01.olivemail.cn (unknown [202.105.21.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by srv05.olivemail.cn (Olivemail) with ESMTPS id 4989D38020D for ; Mon, 16 Jul 2012 12:05:04 -0400 (EDT) Received: from oray.cn (unknown [202.105.21.248]) by srv01.olivemail.cn (Olivemail) with ESMTP id AEF4B890011 for ; Tue, 17 Jul 2012 00:05:02 +0800 (CST) Received: from [10.79.103.103] (unknown [64.104.125.217]) by app (Coremail) with SMTP id +AWowJB7pQesOwRQ1JgdAA--.49998S2; Tue, 17 Jul 2012 00:05:01 +0800 (CST) Message-ID: <50043BAB.1060702@jacni.com> Date: Tue, 17 Jul 2012 00:04:59 +0800 From: Jacni Qin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Stig Venaas References: <4FFF93FC.6090306@jacni.com> <50008BAD.8060802@venaas.com> In-Reply-To: <50008BAD.8060802@venaas.com> Content-Type: multipart/alternative; boundary="------------000403010508010200040502" X-CM-TRANSID: +AWowJB7pQesOwRQ1JgdAA--.49998S2 X-Coremail-Antispam: 1UD129KBjvJXoWxtFWUKryxGF45Zry5tFyDAwb_yoW7XryUpa 93tF17GF4kJr1xJw1kAw429ry0kFn5tw4Utw15Jw18ur98CF10yr1Ykr1rZa4DGryrJr4U ZrWjkry5Aas5A3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnL8YjsxI4VWkKwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG 6rWj6s0DMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwACjcxG0x vEwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY 0x0EwIxGrwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JYxBIdaVFxhVjvjDU0x ZFpf9x07j6wZcUUUUU= X-CM-SenderInfo: xmdf0xo6mdu03lof0z/1tbiAQAREko7lRsISgABs+ Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:04:21 -0000 This is a multi-part message in MIME format. --------------000403010508010200040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Stig, Thanks a lot for your comments. On 7/14/2012 Saturday 4:57 AM, Stig Venaas wrote: > On 7/12/2012 8:20 PM, Jacni Qin wrote: >> Hi all, >> >> Please see below the text updated according to the comments received. >> Many thanks to Stig, Simon, Shailesh, and others for their review and >> discussions. > > Thanks, this addresses at least some of my concerns. > > Let me try to list the issues I mentioned in my review that I think > may not be addressed. > > 1. Update the text to make it clear it is a generic solution, but with > applicability to DS-Lite. We're trying to figure out what we can do on this. > > 2. It refers to draft-ietf-mboned-64-multicast-address-format-01. I > think may need to wait and see what happens to this. It depends on > discussion in the ipv6 wg whether this format will be chosen. The > examples in this draft may need to be updated depending on the > format chosen. Fine. > > 3. In 4.2 it says "The MLD Querier (typically acts as the PIMv6 > Designated Router)", but if there are multiple routers, then the > querier is typically not the DR. We just wanted to include the MLD-PIM inter-operations, while to avoid the confusion, we can remove the "(typically acts as the PIMv6 Designated Router)" > > 4. Talk about what tunnel types are used. Either pick a specific type, > or I think better, explain how this solution can be used with > different types. E.g. IPv4 in IPv6, and GRE. A note has been added, which says, Note: At this point, only IPv4-in-IPv6 encapsulation is defined; Whether or not to support other types of encapsulation is left for future consideration. > > 5. Security considerations should say something about scoping I think. > How scopes for v4 and v6 may differ, and also how one can in a > global IPv6 group specify a non-global IPv4 group... Some kind of > filtering should be in place to protect against this. Could you help on this to propose some text? Thanks a lot. > > Apart from this I had only minor comments which hopefully will be > addressed in the next version. Thanks for your comments, surely we'll try. Cheers, Jacni > > Stig > >> >> ---------------------------------------------------- >> 4.2. Multicast Distribution Tree Computation >> >> ... >> >> The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so >> as to represent the IPv4-embedded IPv6 source in the IPv6 multicast >> network, and to pass the Reverse Path Forwarding (RPF) check on >> multicast devices. >> >> 4.3. Multicast Data Forwarding >> >> ... >> /* A note is added*/ >> >> Note: At this point, only IPv4-in-IPv6 encapsulation is defined; >> Whether or not to support other types of encapsulation is left for >> future consideration. >> >> 6.1. IGMP-MLD Interworking Function >> >> The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying >> function and the address synthesizing operations. The IGMP/MLD >> Proxying function is specified in [RFC4605]. The address >> synthesizing is stateless and MUST follow >> [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052]. >> >> The mB4 with the IGMP-MLD Interworking Function embedded relays >> between the IGMP domain and the MLD domain. The mB4 performs the >> host portion of the MLD protocol on the upstream interface. The >> composition of IPv6 membership in this context is constructed >> through >> address synthesizing operations and MUST synchronize with the >> membership database maintained in the IGMP domain. MLD messages >> will >> be forwarded natively towards the MLD Querier located upstream in >> the >> IPv6 network. The mB4 also performs the router portion of the IGMP >> protocol on the downstream interface(s). Refer to [RFC4605] for >> more >> details >> >> >> +----------+ IGMP +-------+ MLD +---------+ >> | IPv4 |---------| mB4 |---------| MLD | >> | Receiver | | | | Querier | >> +----------+ +-------+ +---------+ >> >> Figure 2: IGMP-MLD Interworking >> >> If SSM is deployed, the mB4 MUST construct the IPv6 source address >> (or retrieve the IPv4 source address) using the uPrefix64. The mB4 >> may create a membership database which associates the IPv4-IPv6 >> multicast groups with the interfaces (e.g., Wi-Fi and Wired >> Ethernet) >> facing IPv4 multicast receivers. >> >> >> 7.2. Processing PIM Message >> >> /* TIB is used to replace mRIB*/ >> >> >> 7.5. TTL/Scope >> >> The Scope field of IPv4-in-IPv6 multicast addresses should be valued >> accordingly (e.g, to "E", Global scope;) in the deployment >> environment. This specification does not discuss the scope value >> that should be used. >> ------------------------------------------------------ >> >> >> Cheers, >> Jacni >> >> >> On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote: >>> Hi folks, >>> >>> This is a wg last call on draft-ietf-softwire-dslite-multicast-02. >>> http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ >>> >>> As usual, please send editorial comments to the authors and >>> substantive comments to the mailing list. >>> >>> This wg last call will end on June 10 at 12pm EDT. >>> >>> >>> Yong & Alain >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > --------------000403010508010200040502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stig,

Thanks a lot for your comments.
On 7/14/2012 Saturday 4:57 AM, Stig Venaas wrote:
On 7/12/2012 8:20 PM, Jacni Qin wrote:
Hi all,

Please see below the text updated according to the comments received.
Many thanks to Stig, Simon, Shailesh, and others for their review and
discussions.

Thanks, this addresses at least some of my concerns.

Let me try to list the issues I mentioned in my review that I think
may not be addressed.

1. Update the text to make it clear it is a generic solution, but with
   applicability to DS-Lite.
We're trying to figure out what we can do on this.


2. It refers to draft-ietf-mboned-64-multicast-address-format-01. I
   think may need to wait and see what happens to this. It depends on
   discussion in the ipv6 wg whether this format will be chosen. The
   examples in this draft may need to be updated depending on the
   format chosen.
Fine.


3. In 4.2 it says "The MLD Querier (typically acts as the PIMv6
   Designated Router)", but if there are multiple routers, then the
   querier is typically not the DR.
We just wanted to include the MLD-PIM inter-operations, while to avoid the
confusion, we can remove the "(typically acts as the PIMv6 Designated Router)"


4. Talk about what tunnel types are used. Either pick a specific type,
   or I think better, explain how this solution can be used with
   different types. E.g. IPv4 in IPv6, and GRE.
A note has been added, which says,

    Note: At this point, only IPv4-in-IPv6 encapsulation is defined;
    Whether or not to support other types of encapsulation is left for
    future consideration.


5. Security considerations should say something about scoping I think.
   How scopes for v4 and v6 may differ, and also how one can in a
   global IPv6 group specify a non-global IPv4 group... Some kind of
   filtering should be in place to protect against this.

Could you help on this to propose some text? Thanks a lot.


Apart from this I had only minor comments which hopefully will be
addressed in the next version.
Thanks for your comments, surely we'll try.


Cheers,
Jacni


Stig


----------------------------------------------------
4.2.  Multicast Distribution Tree Computation

...

    The mAFTR MUST advertise the route of uPrefix64 with an IPv6 IGP, so
    as to represent the IPv4-embedded IPv6 source in the IPv6 multicast
    network, and to pass the Reverse Path Forwarding (RPF) check on
    multicast devices.

4.3.  Multicast Data Forwarding

...
/* A note is added*/

    Note: At this point, only IPv4-in-IPv6 encapsulation is defined;
    Whether or not to support other types of encapsulation is left for
    future consideration.

6.1.  IGMP-MLD Interworking Function

    The IGMP-MLD Interworking Function combines the IGMP/MLD Proxying
    function and the address synthesizing operations.  The IGMP/MLD
    Proxying function is specified in [RFC4605].  The address
    synthesizing is stateless and MUST follow
    [I-D.ietf-mboned-64-multicast-address-format] and [RFC6052].

    The mB4 with the IGMP-MLD Interworking Function embedded relays
    between the IGMP domain and the MLD domain.  The mB4 performs the
    host portion of the MLD protocol on the upstream interface.  The
    composition of IPv6 membership in this context is constructed through
    address synthesizing operations and MUST synchronize with the
    membership database maintained in the IGMP domain.  MLD messages will
    be forwarded natively towards the MLD Querier located upstream in the
    IPv6 network.  The mB4 also performs the router portion of the IGMP
    protocol on the downstream interface(s).  Refer to [RFC4605] for more
    details


              +----------+   IGMP  +-------+   MLD +---------+
              |   IPv4   |---------|  mB4  |---------|   MLD |
              | Receiver |         |       |         | Querier |
              +----------+         +-------+ +---------+

                       Figure 2: IGMP-MLD Interworking

    If SSM is deployed, the mB4 MUST construct the IPv6 source address
    (or retrieve the IPv4 source address) using the uPrefix64. The mB4
    may create a membership database which associates the IPv4-IPv6
    multicast groups with the interfaces (e.g., Wi-Fi and Wired Ethernet)
    facing IPv4 multicast receivers.


7.2. Processing PIM Message

/* TIB is used to replace mRIB*/


7.5.  TTL/Scope

    The Scope field of IPv4-in-IPv6 multicast addresses should be valued
    accordingly (e.g, to "E", Global scope;) in the deployment
    environment.  This specification does not discuss the scope value
    that should be used.
------------------------------------------------------


Cheers,
Jacni


On 5/27/2012 Sunday 10:34 PM, Yong Cui wrote:
Hi folks,

This is a wg last call on draft-ietf-softwire-dslite-multicast-02.
http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/

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

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


Yong & Alain



_______________________________________________
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







--------------000403010508010200040502-- From internet-drafts@ietf.org Mon Jul 16 09:28:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1641811E808C; Mon, 16 Jul 2012 09:28:56 -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.071, 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 oTqpuWuzER1l; Mon, 16 Jul 2012 09:28:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F6411E8072; Mon, 16 Jul 2012 09:28: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.30p3 Message-ID: <20120716162855.25900.62559.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 09:28:55 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-4rd-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:28: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 : IPv4 Residual Deployment via IPv6 - a Stateless Solution= (4rd) Author(s) : Remi Despres Reinaldo Penno Yiu Lee Gang Chen Sheng Jiang Maoke Chen Filename : draft-ietf-softwire-4rd-03.txt Pages : 43 Date : 2012-07-16 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 IPv4 addresses with restricted port sets. In some scenarios, 4rd-capable customer nodes can exchange packets of their IPv4-only applications via stateful NAT64s that are upgraded to support 4rd tunnels (in addition to their IP/ICMP translation of [RFC6145]). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-4rd-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-4rd-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Internet-Drafts@ietf.org Mon Jul 16 14:11:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0958111E8106; Mon, 16 Jul 2012 14:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 yN-w3OSIJe07; Mon, 16 Jul 2012 14:11:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409EC11E80C0; Mon, 16 Jul 2012 14:11:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716211138.21282.74059.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 14:11:38 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D ACTION:draft-ietf-softwire-dslite-mib-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, 16 Jul 2012 21:11:39 -0000 --NextPart 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 : DS-Lite Management Information Base (MIB) Author(s) : Y. Fu, et al Filename : draft-ietf-softwire-dslite-mib Pages : 30 Date : July 16, 2012 This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for DS-Lite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-dslite-mib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-softwire-dslite-mib"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-07-16141137.I-D@ietf.org> --NextPart-- From leo.liubing@huawei.com Mon Jul 16 18:40:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AB521F8665 for ; Mon, 16 Jul 2012 18:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.823 X-Spam-Level: X-Spam-Status: No, score=-5.823 tagged_above=-999 required=5 tests=[AWL=0.776, 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 jhQIlGdpVZ+7 for ; Mon, 16 Jul 2012 18:40:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C4B1B21F8663 for ; Mon, 16 Jul 2012 18:40:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU82815; Mon, 16 Jul 2012 21:41:26 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 18:39:47 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 18:39:46 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 17 Jul 2012 09:39:36 +0800 From: "Liubing (Leo)" To: Softwires WG Thread-Topic: MAP&4rd Radius-//FW: New Version Notification for draft-jiang-softwire-4rd-radius-01.txt Thread-Index: AQHNY70FRu29gq28RkuKP4ZbJqjATQ== Date: Tue, 17 Jul 2012 01:39:35 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F4529326A76@szxeml509-mbs> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.42] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] MAP&4rd Radius-//FW: New Version Notification for draft-jiang-softwire-4rd-radius-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:40:41 -0000 SGksIGFsbA0KDQpXZSd2ZSB1cGRhdGVkIHRoZSBNQVAmNHJkIHJhZGl1cyBhdHRyaWJ1dGUgZHJh ZnRzLiANClRoZXkgYXJlIHR3byBzZXBhcmF0ZWQgZG9jdW1lbnRzLCBob3dldmVyLCB0aGV5IGFy ZSBzaW1pbGFyIHNvIEkgaW5jbHVkZSB0aGVtIGludG8gb25lIG1haWwganVzdCBmb3IgeW91ciBj b252ZW5pZW50Lg0KDQpQbGVhc2UgY29tbWVudCwgbWFueSB0aGFua3MuDQoNCkIuUi4NCkJpbmcs IFNoZW5nICYgWXUNCg0KDQoNCg0KKioqKioqKioqKioqKioqKk1BUCByYWRpdXMqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCkZpbGVuYW1lOgkgZHJhZnQtamlhbmct c29mdHdpcmUtbWFwLXJhZGl1cw0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgUkFESVVTIEF0dHJp YnV0ZSBmb3IgTUFQDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wNy0xNg0KV0cgSUQ6CQkgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEzDQpVUkw6ICAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWppYW5nLXNvZnR3aXJlLW1h cC1yYWRpdXMtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cw0KSHRtbGl6ZWQ6ICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaWFuZy1zb2Z0d2lyZS1tYXAtcmFk aXVzLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cy0wMQ0KDQpBYnN0cmFjdDoNCiAgIE1h cHBpbmcgb2YgQWRkcmVzcyBhbmQgUG9ydCAoTUFQKSBpcyBhIHN0YXRlbGVzcyBtZWNoYW5pc20g Zm9yDQogICBydW5uaW5nIElQdjQgb3ZlciBJUHY2LW9ubHkgaW5mcmFzdHJ1Y3R1cmUuIEl0IHBy b3ZpZGVzIGJvdGggSVB2NCBhbmQNCiAgIElQdjYgY29ubmVjdGl2aXR5IHNlcnZpY2VzIHNpbXVs dGFuZW91c2x5IGR1cmluZyB0aGUgSVB2NC9JUHY2IGNvLQ0KICAgZXhpc3RpbmcgcGVyaW9kLiBU aGUgRHluYW1pYyBIb3N0IENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgZm9yIElQdjYNCiAgIChESENQ djYpIE1BUCBvcHRpb25zIGhhcyBiZWVuIGRlZmluZWQgdG8gY29uZmlndXJlIE1BUCBDdXN0b21l ciBFZGdlDQogICAoQ0UpLiBIb3dldmVyLCBpbiBtYW55IG5ldHdvcmtzLCB0aGUgY29uZmlndXJh dGlvbiBpbmZvcm1hdGlvbiBtYXkgYmUNCiAgIHN0b3JlZCBpbiBBdXRoZW50aWNhdGlvbiBBdXRo b3JpemF0aW9uIGFuZCBBY2NvdW50aW5nIChBQUEpIHNlcnZlcnMNCiAgIHdoaWxlIHVzZXIgY29u ZmlndXJhdGlvbiBpcyBtYWlubHkgZnJvbSBCcm9hZGJhbmQgTmV0d29yayBHYXRld2F5DQogICAo Qk5HKSB0aHJvdWdoIERIQ1B2NiBwcm90b2NvbC4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgUmVt b3RlDQogICBBdXRoZW50aWNhdGlvbiBEaWFsIEluIFVzZXIgU2VydmljZSAoUkFESVVTKSBhdHRy aWJ1dGUgdGhhdCBjYXJyaWVzDQogICBNQVAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBmcm9t IEFBQSBzZXJ2ZXIgdG8gQk5HLiBUaGUgTUFQIFJBRElVUw0KICAgYXR0cmlidXRlIGFyZSBkZXNp Z25lZCBmb2xsb3dpbmcgdGhlIHNpbXBsaWZ5IHByaW5jaXBsZS4gSXQgcHJvdmlkZXMNCiAgIGp1 c3QgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGZvcm0gdGhlIGNvcnJlc3BvbmRlbnQgREhDUHY2IE1B UCBvcHRpb24uDQoNCg0KDQoqKioqKioqKioqKioqKioqNHJkIHJhZGl1cyoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWppYW5nLXNvZnR3aXJlLTRyZC1yYWRpdXMtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtamlhbmctc29mdHdpcmUtNHJkLXJhZGl1cw0KUmV2aXNp b246CSAwMQ0KVGl0bGU6CQkgUkFESVVTIEF0dHJpYnV0ZSBmb3IgNHJkDQpDcmVhdGlvbiBkYXRl OgkgMjAxMi0wNy0xNg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDEzDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWppYW5nLXNvZnR3aXJlLTRyZC1yYWRpdXMtMDEudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctc29mdHdp cmUtNHJkLXJhZGl1cw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1qaWFuZy1zb2Z0d2lyZS00cmQtcmFkaXVzLTAxDQpEaWZmOiAgICAgICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamlhbmctc29mdHdpcmUtNHJk LXJhZGl1cy0wMQ0KDQpBYnN0cmFjdDoNCiAgIElQdjQgUmVzaWR1YWwgRGVwbG95bWVudCB2aWEg SVB2NiAoNHJkKSBpcyBhIHN0YXRlbGVzcyBtZWNoYW5pc20gZm9yDQogICBydW5uaW5nIElQdjQg b3ZlciBJUHY2LW9ubHkgaW5mcmFzdHJ1Y3R1cmUuIEl0IHByb3ZpZGVzIGJvdGggSVB2NCBhbmQN CiAgIElQdjYgY29ubmVjdGl2aXR5IHNlcnZpY2VzIHNpbXVsdGFuZW91c2x5IGR1cmluZyB0aGUg SVB2NC9JUHY2IGNvLQ0KICAgZXhpc3RpbmcgcGVyaW9kLiBUaGUgRHluYW1pYyBIb3N0IENvbmZp Z3VyYXRpb24gUHJvdG9jb2wgZm9yIElQdjYNCiAgIChESENQdjYpIDRyZCBvcHRpb25zIGhhcyBi ZWVuIGRlZmluZWQgdG8gY29uZmlndXJlIDRyZCBDdXN0b21lciBFZGdlDQogICAoQ0UpLiBIb3dl dmVyLCBpbiBtYW55IG5ldHdvcmtzLCB0aGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBtYXkg YmUNCiAgIHN0b3JlZCBpbiBBdXRoZW50aWNhdGlvbiBBdXRob3JpemF0aW9uIGFuZCBBY2NvdW50 aW5nIChBQUEpIHNlcnZlcnMNCiAgIHdoaWxlIHVzZXIgY29uZmlndXJhdGlvbiBpcyBtYWlubHkg ZnJvbSBCcm9hZGJhbmQgTmV0d29yayBHYXRld2F5DQogICAoQk5HKSB0aHJvdWdoIERIQ1B2NiBw cm90b2NvbC4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgUmVtb3RlDQogICBBdXRoZW50aWNhdGlv biBEaWFsIEluIFVzZXIgU2VydmljZSAoUkFESVVTKSBhdHRyaWJ1dGUgdGhhdCBjYXJyaWVzDQog ICA0cmQgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBmcm9tIEFBQSBzZXJ2ZXIgdG8gQk5HLiBU aGUgNHJkIFJBRElVUw0KICAgYXR0cmlidXRlIGFyZSBkZXNpZ25lZCBmb2xsb3dpbmcgdGhlIHNp bXBsaWZ5IHByaW5jaXBsZS4gSXQgcHJvdmlkZXMNCiAgIGp1c3QgZW5vdWdoIGluZm9ybWF0aW9u IHRvIGZvcm0gdGhlIGNvcnJlc3BvbmRlbnQgREhDUHY2IDRyZCBvcHRpb24uDQoNCg== From leo.liubing@huawei.com Mon Jul 16 18:51:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9E11E8091 for ; Mon, 16 Jul 2012 18:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.582, 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 H8Q-6DkVT+0y for ; Mon, 16 Jul 2012 18:51:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2511E80B5 for ; Mon, 16 Jul 2012 18:50:52 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU83340; Mon, 16 Jul 2012 21:51:38 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 18:50:15 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 18:50:14 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 17 Jul 2012 09:50:04 +0800 From: "Liubing (Leo)" To: Softwires WG Thread-Topic: 4rd MIB-//FW: New Version Notification for draft-fu-softwire-4rd-mib-01.txt Thread-Index: AQHNY757pihjGm1KSEafisqyeHJFZQ== Date: Tue, 17 Jul 2012 01:50:03 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F4529326A8A@szxeml509-mbs> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.42] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] 4rd MIB-//FW: New Version Notification for draft-fu-softwire-4rd-mib-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:51:01 -0000 SGksIGFsbA0KDQpIZXJlJ3MgdGhlIHVwZGF0ZWQgNHJkIE1JQiBkcmFmdC4gDQoNClBsZWFzZSBj b21tZW50LCBtYW55IHRoYW5rcy4NCg0KQi5SLg0KQmluZywgU2hlbmcgJiBZdQ0KDQoNCioqKioq KioqKioqKioqKioqKio0cmQgTUlCKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZ1LXNvZnR3aXJlLTRyZC1taWItMDEudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFl1IEZ1IGFuZCBwb3N0ZWQgdG8gdGhl DQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZnUtc29mdHdpcmUtNHJkLW1p Yg0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgRGVmaW5pdGlvbnMgb2YgTWFuYWdlZCBPYmplY3Rz IGZvciA0cmQNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA3LTE2DQpXRyBJRDoJCSBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTUNClVSTDogICAgICAgICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZnUtc29mdHdpcmUtNHJkLW1pYi0w MS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1mdS1zb2Z0d2lyZS00cmQtbWliDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWZ1LXNvZnR3aXJlLTRyZC1taWItMDENCkRpZmY6ICAgICAgICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mdS1zb2Z0d2lyZS00 cmQtbWliLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIGRlZmluZXMgYSBwb3J0aW9uIG9m IHRoZSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UgKE1JQikNCiAgIGZvciB1c2Ugd2l0aCBu ZXR3b3JrIG1hbmFnZW1lbnQgcHJvdG9jb2xzIGluIHRoZSBJbnRlcm5ldCBjb21tdW5pdHkuDQog ICBJbiBwYXJ0aWN1bGFyLCBpdCBkZWZpbmVzIG1hbmFnZWQgb2JqZWN0cyBmb3IgNHJkLg0K From leo.liubing@huawei.com Mon Jul 16 18:58:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EF321F869D for ; Mon, 16 Jul 2012 18:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.466, 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 F6Lh5slPW9ha for ; Mon, 16 Jul 2012 18:58:31 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D96B121F869C for ; Mon, 16 Jul 2012 18:58:30 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIB80476; Mon, 16 Jul 2012 21:59:17 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 18:57:48 -0700 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 18:57:50 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Tue, 17 Jul 2012 09:57:41 +0800 From: "Liubing (Leo)" To: Softwires WG Thread-Topic: MAP MIB-//FW: New Version Notification for draft-fu-softwire-map-mib-01.txt Thread-Index: AQHNY7+LyQ9y/oxv1kChB2Da4r5IkA== Date: Tue, 17 Jul 2012 01:57:40 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F4529326A9D@szxeml509-mbs> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.42] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] MAP MIB-//FW: New Version Notification for draft-fu-softwire-map-mib-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 01:58:31 -0000 SGksIGFsbA0KDQpUaGUgTUFQIE1JQiB3YXMgYWxzbyB1cGRhdGVkLiBQbGVhc2UgcmV2aWV3IGFu ZCBjb21tZW50cy4NCk1hbnkgdGhhbmtzIQ0KDQpCLlIuDQpUaGUgYXV0aG9ycw0KDQoNCg0KKioq KioqKioqKioqKioqKipNQVAgTUlCKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq Kg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZ1LXNvZnR3aXJlLW1hcC1taWItMDEudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFl1IEZ1IGFuZCBwb3N0ZWQgdG8g dGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtZnUtc29mdHdpcmUtbWFw LW1pYg0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgRGVmaW5pdGlvbnMgb2YgTWFuYWdlZCBPYmpl Y3RzIGZvciBNQVAtRQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTYNCldHIElEOgkJIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNQ0KVVJMOiAgICAgICAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1mdS1zb2Z0d2lyZS1tYXAt bWliLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZ1LXNvZnR3aXJlLW1hcC1taWINCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnUtc29mdHdpcmUtbWFwLW1pYi0wMQ0KRGlmZjogICAg ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWZ1LXNvZnR3 aXJlLW1hcC1taWItMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIG1lbW8gZGVmaW5lcyBhIHBvcnRp b24gb2YgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZQ0KICAgKE1JQikgZm9yIHVzaW5n IHdpdGggbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBpbiB0aGUgSW50ZXJuZXQNCiAgIGNv bW11bml0eS5JbiBwYXJ0aWN1bGFyLCBpdCBkZWZpbmVzIG1hbmFnZWQgb2JqZWN0cyBmb3IgTUFQ DQogICBlbmNhcHN1bGF0aW9uIG1vZGUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From james.huang@huawei.com Mon Jul 16 20:41:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB19421F8530 for ; Mon, 16 Jul 2012 20:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZUXaeEBkeQf for ; Mon, 16 Jul 2012 20:41:12 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C60AB21F852E for ; Mon, 16 Jul 2012 20:41:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIB86420; Mon, 16 Jul 2012 23:41:58 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 20:39:18 -0700 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 20:39:20 -0700 Received: from SZXEML522-MBS.china.huawei.com ([fe80::d63:ad74:b260:1928]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Tue, 17 Jul 2012 11:39:14 +0800 From: Huangjing To: Qiong Thread-Topic: [Softwires] Fwd: New Version Notification for draft-cui-softwire-b4-translated-ds-lite-07.txt Thread-Index: AQHNYRCPOEUzV0Wp20y2dpS3x3LR/5cs0gvA Date: Tue, 17 Jul 2012 03:39:14 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC2A8E45CC@szxeml522-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.115.72] Content-Type: multipart/alternative; boundary="_000_774B240D54DAB844B37EE80C2DD8E8BC2A8E45CCszxeml522mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" , Yong Cui Subject: Re: [Softwires] Fwd: New Version Notification for draft-cui-softwire-b4-translated-ds-lite-07.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 03:41:13 -0000 --_000_774B240D54DAB844B37EE80C2DD8E8BC2A8E45CCszxeml522mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRvIGFkb3B0IHRoaXMgZHJhZnQgYXMgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50 Lg0KDQpKYW1lcw0KDQoNCkZyb206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBRaW9uZw0KU2VudDogRnJp ZGF5LCBKdWx5IDEzLCAyMDEyIDExOjU5IFBNDQpUbzogc29mdHdpcmVzQGlldGYub3JnDQpDYzog WW9uZyBDdWkNClN1YmplY3Q6IFtTb2Z0d2lyZXNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1jdWktc29mdHdpcmUtYjQtdHJhbnNsYXRlZC1kcy1saXRlLTA3LnR4dA0K DQpIaSwgYWxsLA0KDQpXZSBoYXZlIHB1Ymxpc2hlZCBhIC0wNyB2ZXJzaW9uIG9mIGxpZ2h0d2Vp Z2h0IDRvdmVyNi4gVGhpcyBuZXcgdmVyc2lvbiBpbXByb3ZlcyB0aGUgcHJlY2lzZW5lc3Mgb2Yg dGhlIElDTVAgaGFuZGxpbmcgbWVjaGFuaXNtIGRlc2NyaXB0aW9uLg0KDQpVcCB0byBub3csIHRo aXMgZHJhZnQgaGFzIGZpbmlzaGVkIG1lcmdpbmcgd2l0aCBJLUQuemhvdS1zb2Z0d2lyZS1iNC1u YXQgYW5kIEktRC5wZW5uby1zb2Z0d2lyZS1zZG5hdCBhcyByZXF1ZXN0ZWQgYnkgdGhlIFdHIGFu ZCBoYXMgc2V0dGxlZCBhbGwgdGhlIHRlY2huaWNhbCBkZXRhaWxzIGJhc2VkIG9uIGNvbW1lbnRz IGZyb20gdGhlIFdHLiBJdCByZWZsZWN0cyB3aWRlbHkgcmVxdWlyZW1lbnRzIGZyb20gNyBvcGVy YXRvcnMgaW5jbHVkaW5nIENoaW5hIFRlbGVjb20sIFRzaW5naHVhLCBDb21jYXN0LCBGcmFuY2Ug VGVsZWNvbSwgRGV1dHNjaGUgVGVsZWtvbSxCb3V5Z3VlcyBUZWxlY29tIGFuZCBGcmVlYml0cywg YW5kIHZlbmRvcnMgZnJvbSBIdWF3ZWksIEp1bmlwZXIgYW5kIENpc2NvLiBJdCBoYXMgcnVubmlu ZyBjb2RlIGFscmVhZHkgcHVibGlzaGVkIGluIGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVj dHMvbGFmdDYvIGFuZCBoYXMgYSBmaWVsZCB0cmlhbCBpbiBjb21tZXJpYWwgbmV0d29yay4NCg0K RnJvbSB0aGUgYXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50J3MgdmlldywgaXQgaXMgcmVhZHkgdG8g YmUgYWRvcHRlZCBhcyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBXZSB3b3VsZCBiZSBhcHByZWNp YXRlZCB0byBoYXZlIHlvdXIgY29tbWVudHMuDQoNClRoYW5rcyBpbiBhZHZhbmNlICENCg0KQmVz dCB3aXNoZXMNClFpb25nDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0t LQ0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWN1aS1zb2Z0d2lyZS1iNC10cmFuc2xhdGVk LWRzLWxpdGUtMDcudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IElhbiBG YXJyZXIgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICBk cmFmdC1jdWktc29mdHdpcmUtYjQtdHJhbnNsYXRlZC1kcy1saXRlDQpSZXZpc2lvbjogIDA3DQpU aXRsZTogIExpZ2h0d2VpZ2h0IDRvdmVyNjogQW4gRXh0ZW5zaW9uIHRvIHRoZSBEUy1MaXRlIEFy Y2hpdGVjdHVyZQ0KQ3JlYXRpb24gZGF0ZTogIDIwMTItMDctMTMNCldHIElEOiAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE2DQpVUkw6IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWN1aS1zb2Z0d2lyZS1iNC10cmFuc2xhdGVkLWRzLWxp dGUtMDcudHh0DQpTdGF0dXM6IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Y3VpLXNvZnR3aXJlLWI0LXRyYW5zbGF0ZWQtZHMtbGl0ZQ0KSHRtbGl6ZWQ6IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWN1aS1zb2Z0d2lyZS1iNC10cmFuc2xhdGVkLWRzLWxpdGUt MDcNCkRpZmY6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY3VpLXNv ZnR3aXJlLWI0LXRyYW5zbGF0ZWQtZHMtbGl0ZS0wNw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGFuIGV4dGVuc2lvbiB0byBEUy1MaXRlIGNhbGxlZCBMaWdodHdlaWdo dA0KICAgNG92ZXI2LiAgVGhpcyBtZWNoYW5pc20gbW92ZXMgdGhlIHRyYW5zbGF0aW9uIGZ1bmN0 aW9uIGZyb20gdGhlDQogICB0dW5uZWwgY29uY2VudHJhdG9yIChBRlRSKSB0byBpbml0aWF0b3Jz IChCNHMpLCBhbmQgaGVuY2UgcmVkdWNlcyB0aGUNCiAgIG1hcHBpbmcgc2NhbGUgb24gdGhlIGNv bmNlbnRyYXRvciB0byBhIHBlci1zdWJzY3JpYmVyIGxldmVsLiAgVG8NCiAgIGRlbGVnYXRlIHRo ZSBOQVBUIGZ1bmN0aW9uIHRvIHRoZSBpbml0aWF0b3JzLCBwb3J0LXJlc3RyaWN0ZWQgSVB2NA0K ICAgYWRkcmVzc2VzIGFyZSBhbGxvY2F0ZWQgdG8gdGhlIGluaXRpYXRvcnMuDQoNCg0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KLS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NClFpb25nIFN1bg0KQ2hpbmEgVGVsZWNvbSBCZWlqaW5nIFJlc2Vh cmNoIEluc3RpdHVkZQ0KDQoNCk9wZW4gc291cmNlIGNvZGU6DQpsaWdodHdlaWdodCA0b3ZlcjY6 IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYvDQpQQ1AtbmF0Y29vcmQ6IGh0 dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvcGNwcG9ydHNldGRlbW8vDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQo= --_000_774B240D54DAB844B37EE80C2DD8E8BC2A8E45CCszxeml522mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHN1cHBv cnQgdG8gYWRvcHQgdGhpcyBkcmFmdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbWVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UWlvbmc8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKdWx5IDEzLCAyMDEyIDExOjU5IFBNPGJyPg0KPGI+VG86PC9iPiBzb2Z0d2lyZXNAaWV0Zi5v cmc8YnI+DQo8Yj5DYzo8L2I+IFlvbmcgQ3VpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtTb2Z0d2ly ZXNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1jdWktc29mdHdpcmUt YjQtdHJhbnNsYXRlZC1kcy1saXRlLTA3LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGksIGFsbCw8YnI+DQo8YnI+DQpX ZSBoYXZlIHB1Ymxpc2hlZCBhIC0wNyB2ZXJzaW9uIG9mIGxpZ2h0d2VpZ2h0IDRvdmVyNi4gVGhp cyBuZXcgdmVyc2lvbiBpbXByb3ZlcyB0aGUgcHJlY2lzZW5lc3Mgb2YgdGhlIElDTVAgaGFuZGxp bmcgbWVjaGFuaXNtIGRlc2NyaXB0aW9uLjxicj4NCjxicj4NClVwIHRvIG5vdywgdGhpcyBkcmFm dCBoYXMgZmluaXNoZWQgbWVyZ2luZyB3aXRoIEktRC56aG91LXNvZnR3aXJlLWI0LW5hdCBhbmQg SS1ELnBlbm5vLXNvZnR3aXJlLXNkbmF0IGFzIHJlcXVlc3RlZCBieSB0aGUgV0cgYW5kIGhhcyBz ZXR0bGVkIGFsbCB0aGUgdGVjaG5pY2FsIGRldGFpbHMgYmFzZWQgb24gY29tbWVudHMgZnJvbSB0 aGUgV0cuIEl0IHJlZmxlY3RzIHdpZGVseSByZXF1aXJlbWVudHMgZnJvbSA3IG9wZXJhdG9ycyBp bmNsdWRpbmcNCiBDaGluYSBUZWxlY29tLCBUc2luZ2h1YSwgQ29tY2FzdCwgRnJhbmNlIFRlbGVj b20sIERldXRzY2hlIFRlbGVrb20sQm91eWd1ZXMgVGVsZWNvbSBhbmQgRnJlZWJpdHMsIGFuZCB2 ZW5kb3JzIGZyb20gSHVhd2VpLCBKdW5pcGVyIGFuZCBDaXNjby4gSXQgaGFzIHJ1bm5pbmcgY29k ZSBhbHJlYWR5IHB1Ymxpc2hlZCBpbg0KPGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9w cm9qZWN0cy9sYWZ0Ni8iPmh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYvPC9h PiBhbmQgaGFzIGEgZmllbGQgdHJpYWwgaW4gY29tbWVyaWFsIG5ldHdvcmsuDQo8YnI+DQo8YnI+ DQpGcm9tIHRoZSBhdXRob3JzIG9mIHRoaXMgZG9jdW1lbnQncyB2aWV3LCBpdCBpcyByZWFkeSB0 byBiZSBhZG9wdGVkIGFzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFdlIHdvdWxkIGJlIGFwcHJl Y2lhdGVkIHRvIGhhdmUgeW91ciBjb21tZW50cy4NCjxicj4NCjxicj4NClRoYW5rcyBpbiBhZHZh bmNlICE8YnI+DQo8YnI+DQpCZXN0IHdpc2hlczxicj4NClFpb25nPGJyPg0KPGJyPg0KLS0tLS0t LS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BJm5ic3A7bmV3 Jm5ic3A7dmVyc2lvbiZuYnNwO29mJm5ic3A7SS1ELCZuYnNwO2RyYWZ0LWN1aS1zb2Z0d2lyZS1i NC10cmFuc2xhdGVkLWRzLWxpdGUtMDcudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmhhcyZuYnNw O2JlZW4mbmJzcDtzdWNjZXNzZnVsbHkmbmJzcDtzdWJtaXR0ZWQmbmJzcDtieSZuYnNwO0lhbiZu YnNwO0ZhcnJlciZuYnNwO2FuZCZuYnNwO3Bvc3RlZCZuYnNwO3RvJm5ic3A7dGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPklFVEYmbmJzcDtyZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RmlsZW5hbWU6ICZuYnNwO2RyYWZ0LWN1aS1zb2Z0 d2lyZS1iNC10cmFuc2xhdGVkLWRzLWxpdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmV2aXNpb246 ICZuYnNwOzA3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRpdGxlOiAmbmJzcDtMaWdodHdlaWdodCZu YnNwOzRvdmVyNjombmJzcDtBbiZuYnNwO0V4dGVuc2lvbiZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7 RFMtTGl0ZSZuYnNwO0FyY2hpdGVjdHVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DcmVhdGlvbiZu YnNwO2RhdGU6ICZuYnNwOzIwMTItMDctMTM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V0cmbmJzcDtJ RDogJm5ic3A7SW5kaXZpZHVhbCZuYnNwO1N1Ym1pc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ TnVtYmVyJm5ic3A7b2YmbmJzcDtwYWdlczombmJzcDsxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5V Ukw6IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWN1 aS1zb2Z0d2lyZS1iNC10cmFuc2xhdGVkLWRzLWxpdGUtMDcudHh0Ij4NCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWN1aS1zb2Z0d2lyZS1iNC10cmFuc2xhdGVkLWRz LWxpdGUtMDcudHh0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdGF0dXM6IDxhIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY3VpLXNvZnR3aXJlLWI0LXRyYW5z bGF0ZWQtZHMtbGl0ZSI+DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWN1 aS1zb2Z0d2lyZS1iNC10cmFuc2xhdGVkLWRzLWxpdGU8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pkh0bWxpemVkOiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jdWkt c29mdHdpcmUtYjQtdHJhbnNsYXRlZC1kcy1saXRlLTA3Ij4NCmh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWN1aS1zb2Z0d2lyZS1iNC10cmFuc2xhdGVkLWRzLWxpdGUtMDc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkRpZmY6IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtY3VpLXNvZnR3aXJlLWI0LXRyYW5zbGF0ZWQtZHMtbGl0ZS0wNyI+ DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWN1aS1zb2Z0d2lyZS1i NC10cmFuc2xhdGVkLWRzLWxpdGUtMDc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5BYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7c3BlY2lmaWVzJm5ic3A7YW4mbmJz cDtleHRlbnNpb24mbmJzcDt0byZuYnNwO0RTLUxpdGUmbmJzcDtjYWxsZWQmbmJzcDtMaWdodHdl aWdodDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDs0b3ZlcjYuJm5ic3A7 Jm5ic3A7VGhpcyZuYnNwO21lY2hhbmlzbSZuYnNwO21vdmVzJm5ic3A7dGhlJm5ic3A7dHJhbnNs YXRpb24mbmJzcDtmdW5jdGlvbiZuYnNwO2Zyb20mbmJzcDt0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dHVubmVsJm5ic3A7Y29uY2VudHJhdG9yJm5ic3A7KEFGVFIp Jm5ic3A7dG8mbmJzcDtpbml0aWF0b3JzJm5ic3A7KEI0cyksJm5ic3A7YW5kJm5ic3A7aGVuY2Um bmJzcDtyZWR1Y2VzJm5ic3A7dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu YnNwO21hcHBpbmcmbmJzcDtzY2FsZSZuYnNwO29uJm5ic3A7dGhlJm5ic3A7Y29uY2VudHJhdG9y Jm5ic3A7dG8mbmJzcDthJm5ic3A7cGVyLXN1YnNjcmliZXImbmJzcDtsZXZlbC4mbmJzcDsmbmJz cDtUbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDtkZWxlZ2F0ZSZuYnNw O3RoZSZuYnNwO05BUFQmbmJzcDtmdW5jdGlvbiZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7aW5pdGlh dG9ycywmbmJzcDtwb3J0LXJlc3RyaWN0ZWQmbmJzcDtJUHY0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyZuYnNwOyZuYnNwO2FkZHJlc3NlcyZuYnNwO2FyZSZuYnNwO2FsbG9jYXRlZCZuYnNw O3RvJm5ic3A7dGhlJm5ic3A7aW5pdGlhdG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSZuYnNwO0lFVEYmbmJzcDtTZWNyZXRhcmlhdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyIGNsZWFyPSJhbGwiPg0K PGJyPg0KLS0gPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTxicj4NClFpb25nIFN1bjxicj4NCkNoaW5hIFRlbGVjb20gQmVpamluZyBSZXNlYXJjaCBJ bnN0aXR1ZGU8YnI+DQo8YnI+DQo8YnI+DQpPcGVuIHNvdXJjZSBjb2RlOjxicj4NCmxpZ2h0d2Vp Z2h0IDRvdmVyNjogPGk+PGEgaHJlZj0iaHR0cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9s YWZ0Ni8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL2xh ZnQ2LzwvYT48L2k+PGJyPg0KUENQLW5hdGNvb3JkOjxpPiA8YSBocmVmPSJodHRwOi8vc291cmNl Zm9yZ2UubmV0L3Byb2plY3RzL3BjcHBvcnRzZXRkZW1vLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cDovL3NvdXJjZWZvcmdlLm5ldC9wcm9qZWN0cy9wY3Bwb3J0c2V0ZGVtby88L2E+IDwvaT48YnI+ DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_774B240D54DAB844B37EE80C2DD8E8BC2A8E45CCszxeml522mbschi_-- From sarikaya2012@gmail.com Tue Jul 17 08:47:15 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2928321F85D4 for ; Tue, 17 Jul 2012 08:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 o0ljIFBoXt1U for ; Tue, 17 Jul 2012 08:47:14 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C04021F856D for ; Tue, 17 Jul 2012 08:47:14 -0700 (PDT) Received: by ghbg16 with SMTP id g16so613595ghb.31 for ; Tue, 17 Jul 2012 08:48:01 -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=cW9ZIqkJ52STKpVJmG0Ul/KKZX6RcI06R6DOCf2CSak=; b=HA9NtC0+rcR9dBTvXu5Dkf1WnEsJIJnu4/GqIFOf4N3JfORUis937XygpZaN8b/i7e VAo0iBU630BqPqg30rJcRXF3h7Z6S4Dp0O+T2B1QVr3ZaE3jj62JxdoXLKLEg+D2kbCW rKXyD1S4UKtOMUAveC97jTtjfjqcoK5vX/uDUIYuCucYv5c3nHx5mh7qsxMv0z/NtSIQ jDj45BQutnO8CoeMkP/LOgXPBymzsll4plvFZKFQB0TuqYKCHu8CTGZ36gZZv9jZYcqe 8mDuXIIx2LDd8p8xcMlnw+hFNjG6Q8AxVrN8t5zCRigeKyp2pYpcXDLEHD0r7te/Kmlv CVKA== MIME-Version: 1.0 Received: by 10.50.195.234 with SMTP id ih10mr1884466igc.0.1342540081298; Tue, 17 Jul 2012 08:48:01 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Tue, 17 Jul 2012 08:48:01 -0700 (PDT) In-Reply-To: <20120716220345.29082.92028.idtracker@ietfa.amsl.com> References: <20120716220345.29082.92028.idtracker@ietfa.amsl.com> Date: Tue, 17 Jul 2012 10:48:01 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] New Version Notification for draft-sarikaya-softwire-4rdmulticast-03.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, 17 Jul 2012 15:47:15 -0000 A new version of I-D, draft-sarikaya-softwire-4rdmulticast-03.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-softwire-4rdmulticast Revision: 03 Title: Multicast Support for 4rd Creation date: 2012-07-17 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-softwire-4rdmulticast-03.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast Htmlized: http://tools.ietf.org/html/draft-sarikaya-softwire-4rdmulticast-03 Diff: http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-softwire-4rdmulticast-03 Abstract: This memo specifies 4rd technology's multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In 4rd Translation Multicast solution for 4rd and translation variant of MAP, MAP-T, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. 4rd Border Relay does the reverse translation and joins IPv4 multicast group for 4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. In 4rd encapsulation solution for encapsulation variant of MAP, MAP-E, IGMP Proxy at the 4rd Customer Edge router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGMP messages to establish multicast state at MAP Border Relay so that MAP Border Relay can tunnel IPv4 multicast data to IPv4 hosts connected to MAP Customer Edge device. The IETF Secretariat From sarikaya2012@gmail.com Tue Jul 17 08:48:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7335E21F8642 for ; Tue, 17 Jul 2012 08:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 UZvSVIXs7uuW for ; Tue, 17 Jul 2012 08:48:11 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C89CB21F8601 for ; Tue, 17 Jul 2012 08:48:11 -0700 (PDT) Received: by yenq13 with SMTP id q13so616169yen.31 for ; Tue, 17 Jul 2012 08:48:59 -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=VuMVmxodsSQkAfnSwZGAER/kO4msXuoY6wmEKeCLJmk=; b=FJm4H76IaURRxwizSnAwBwI0A3tCj4EAn2U6KA3U5eFwuR4rFqaGa0LESkdvXKQPaI W1FT/P4ZcIdCvX4qCPBQgFGGjEEhvbkx/y5K70l7l6np5Jhkh9lRowHRIf0EUJ4AfvNx YGt17CsGi8VJvMkMzZM58ne9gbD3epIj9c5qN5iRFL+r5v+DFQDQTDf+yIHHJ1L3qc1V 2dOq/UDH6OzWslLp0G7YpkI6faDdTN5xG4MLQP5xnX8btpx6dOlzlCt8oFdwZM9SK0QN Wqp9imfA8xHYEztFsY8PAsQb1Dx9Dwk4ocbRAekNrKRMgX11+Jyx9icc7sPIaua4X4nC pF/w== MIME-Version: 1.0 Received: by 10.50.194.132 with SMTP id hw4mr1830070igc.63.1342540139118; Tue, 17 Jul 2012 08:48:59 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Tue, 17 Jul 2012 08:48:59 -0700 (PDT) In-Reply-To: <20120716164617.28005.78505.idtracker@ietfa.amsl.com> References: <20120716164617.28005.78505.idtracker@ietfa.amsl.com> Date: Tue, 17 Jul 2012 10:48:59 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] New Version Notification for draft-sarikaya-softwire-6rdmulticast-04.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, 17 Jul 2012 15:48:12 -0000 A new version of I-D, draft-sarikaya-softwire-6rdmulticast-04.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Filename: draft-sarikaya-softwire-6rdmulticast Revision: 04 Title: Multicast Support for 6rd Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-softwire-6rdmulticast-04.txt Status: http://datatracker.ietf.org/doc/draft-sarikaya-softwire-6rdmulticast Htmlized: http://tools.ietf.org/html/draft-sarikaya-softwire-6rdmulticast-04 Diff: http://tools.ietf.org/rfcdiff?url2=draft-sarikaya-softwire-6rdmulticast-04 Abstract: This memo specifies 6rd's multicast component so that IPv6 hosts can receive multicast data from IPv6 servers. In 6rd encapsulation solution, multicast communication is completely integrated into 6rd tunnel. 6rd Customer Edge router is extended with Multicast Listener Discovery (MLD) protocol Proxy entity. MLD Proxy receives join requests from 6rd IPv6 hosts and sends them upstream in 6rd's IPv4 in IPv6 tunnel to 6rd Border Relay (BR). This tunnel is used to exchange MLD messages to establish multicast state at 6rd BR so that 6rd BR can use 6rd's IPv4 in IPv6 tunnel to send IPv6 multicast data to 6rd CEs. At the CEs, multicast data is decapsulated and MLD Proxy delivers it to IPv6 hosts based on MLD group membership state. In 6rd Translation Multicast based solution, the protocol is based on proxying MLD at the 6rd Customer Edge router and then translating MLD messages to IGMP messages and sending them upstream to a network which supports IPv4 multicast. 6rd Border Relay is multicast router and IGMP-MLD translator. It translates IGMP join back to MLD join message and sends it to multicast source. IPv6 Multicast data received at 6rd Border Relay is translated into IPv4 multicast data and then sent to IPv4 multicast tree downstream to 6rd Customer Edge which translates back to IPv6 multicast data then delivers to the hosts. The IETF Secretariat From despres.remi@laposte.net Thu Jul 19 06:38:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E649321F8615 for ; Thu, 19 Jul 2012 06:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB3e-LJgFX7F for ; Thu, 19 Jul 2012 06:38:33 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id D07E821F8645 for ; Thu, 19 Jul 2012 06:38:32 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id CDF5A70000F9 for ; Thu, 19 Jul 2012 15:39:20 +0200 (CEST) Received: from [192.168.1.73] (194.204.170.89.rev.sfr.net [89.170.204.194]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id AD00570000F8 for ; Thu, 19 Jul 2012 15:39:20 +0200 (CEST) X-SFR-UUID: 20120719133920708.AD00570000F8@msfrf2416.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jul 2012 15:39:16 +0200 Message-Id: <91C203F1-6783-47F3-BB1E-4C2733F25106@laposte.net> To: "softwires@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] New comparison tables of key features of MAP-T, MAP-E and 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 13:38:34 -0000 Hello, all, tools.ietf.org/html/draft-despres-softwire-stateless-analysis-tool-02 = has been posted. As said in the abstract: "This document proposes a discussion tool for the Softwire meeting at = IETF 84 in Vancouver. Significant differentiating features between the MAP approach (proposed = standards MAP-T and MAP-E) and the unified approach(proposed standard = 4rd) are presented in tabular format. Its purpose is to facilitate decision making, and is therefore = temporary." Please understand that 4rd being listed with all the positive features = is the direct result of its being designed precisely for that. (It isn't = that 4rd would have been first designed and a list of key features = derived afterward.) All comments are welcome, and may influence a version -03 if needed. Thank you, RD =20 =20= From fibrib@gmail.com Thu Jul 19 18:17:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19DA11E80CE for ; Thu, 19 Jul 2012 18:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9ckprNTFptF for ; Thu, 19 Jul 2012 18:16:57 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8974A11E80CA for ; Thu, 19 Jul 2012 18:16:56 -0700 (PDT) Received: by qcsg15 with SMTP id g15so2859450qcs.27 for ; Thu, 19 Jul 2012 18:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bMuu10JfGy+xVSN3WfLTjkP4WQPVOB0gV5YQog522Z0=; b=tBNYFme667Si4H9QRSoQiu2Z+viDgAGxFaPoaVbB44M3jny8J6q9D7mZNjr6twcZfR undSEAmtbkGSeD0LNLSegDNmlvI1vrN2RgNX5LQIDVo4i+/26acjGHo4W4NRcSLfAwHz 9DBUH7pUM6wladnvPiQovs/1/im7HcmFWnj/oE9dRoX+X3CM1a4lsjMdGa5US4JlOC+S UiuctY7mtAbRbDywFeFBMez4UN4uEj4JXVvxhkRZWLeRA5tbZmTM9kiQcjUyWzSUhxCj h4gYuDx+AZstbvSgxXUM17OgWiY5AG6bDyrEZktaYw7X5HnZy8KiEszYdw4jo81cQCde V/vw== MIME-Version: 1.0 Received: by 10.224.191.74 with SMTP id dl10mr7208265qab.14.1342747070812; Thu, 19 Jul 2012 18:17:50 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Thu, 19 Jul 2012 18:17:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Jul 2012 10:17:50 +0900 Message-ID: From: Maoke To: Wojciech Dec Content-Type: multipart/alternative; boundary=20cf3005dcb22dd02004c538aaf4 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 01:17:00 -0000 --20cf3005dcb22dd02004c538aaf4 Content-Type: text/plain; charset=ISO-8859-1 hi Woj, let me truncate the old text that makes this message too long. focusing on the recent replies. 2012/7/19 Wojciech Dec > Hello Maoke, > > okay, if your "MAP algorithm" refers to the GMA, it is fine to state GMA >> is usable to address/port-set assignment and/or stateless IPv4-mapped IPv6 >> address generation. however, only the GMA doesn't make MAP as a "mapping of >> address and port". the purpose of mapping is making a stateless packet >> transform at the IPv4/IPv6 boundary and vise versa. >> > > The mapping still happens, in the lower 64 bits. > clarified. thanks. > > >> if you argue GMA is generic for universal cases of A+P ( i actually agree >> that ), i suggest to submit GMA separately as a standard or as an update of >> A+P, so that stateful/stateless solutions are able to cite it easily. >> > > That's what it was, but it was said to be "too many drafts". > >> >> >>> In addition, the IPv4+PSID are still mapped to IID as per MAP. Thus >>> there is no "algorithm is abandoned" case, as you put it. >>> >> >> this a little differs from my early reading on the MAP draft stating 1:1. >> you clarify here that in any cases IPv4+PSID is embedded in the mapped IPv6 >> address. >> >> >>> The PSID is intended to be passed as part of the Optional Port >>> Parameters, which the draft already has as part of the FMRs, and what has >>> also been discussed in the DT. >>> >> >> yes we have the optional port parameters. but i didn't remember what DT >> discussed included the topic of having the value of PSID in the FMR. >> > > Please refer to Satoru-san's emails on the topic. > >> >> on the other hand, i think current talk is going on at the WG stage >> rather than the DT. even if i didn't show objection to that issue in the >> DT, i don't think i would have been disabled to show it in the WG. >> >> >>> This is another type of 1:1 rules, which I agree is an item of >>> clarification in the draft, but eminently possible under the current spec >>> as the the MAP architecture is agnostic to how the IPv6+IPv4+Rules get to >>> the device >>> >> >> sorry i cannot catch the meaning of the "agnostic to"... :P i understand >> "how the IPv6+IPv4+Rules get to the device" is the mission of MAP-DHCP >> rather than the MAP architecture. >> > > Agnostic to means, that the working of the MAP architecture doesn't rely > on any specific MAP rule or address provisioning method. Should be noted > that IPv6 addresses are also provisioned, and can be so by multiple methods. > "any specific MAP rule" or any specific rule-making algorithm? if the former, no objection here. if the latter, i don't see anything essential other than a rule-making algorithm in the "MAP architecture". and this rule-making algorithm is what i support through the MDT and the WG. > >> >> if the multiple-CE domain and the single-CE domain should have different >> attributes, i don't think this is not a novelty. and i am against this >> configuration parameter no matter if it is *stated* as a non-novelty or >> not. >> > > And what is the reason for this objection? > does MAP intend to support mesh topology with the PSID value included in the rule? if so, i doubt any CE device (especially those having limited resources) can do with that. if it is not, the architecture happens with 2 configurations not orthogonal: if PSID, no mesh -- it confuses that the highest priority design goal of MAP is not statelessness and simplicity but the PSID. therefore i am objective of introducing PSID into the rule and making the architecture stateless only in wording. - maoke > > Regards, > Woj. > >> >> >> --20cf3005dcb22dd02004c538aaf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Woj,

let me truncate the old text that= makes this message too long. focusing on the recent replies.=A0

<= div class=3D"gmail_quote">2012/7/19 Wojciech Dec <wdec.ietf@gmail.com>
Hello Maoke,

okay, if your "MAP algorithm" ref= ers to the GMA, it is fine to state GMA is usable to address/port-set assig= nment and/or stateless IPv4-mapped IPv6 address generation. however, only t= he GMA doesn't make MAP as a "mapping of address and port". t= he purpose of mapping is making a stateless packet transform at the IPv4/IP= v6 boundary and vise versa.

The mapping still ha= ppens, in the lower 64 bits.

cl= arified. thanks.
=A0


if you argue GMA is generic for universal cases of A+P = ( i actually agree that ), i suggest to submit GMA separately as a standard= or as an update of A+P, so that stateful/stateless solutions are able to c= ite it easily.=A0

That's what it was, but it was said t= o be "too many drafts".
=A0
In addition, the IPv4+PSID are still mapped to IID as per MAP. Thus there= is no "algorithm is abandoned" case, as you put it.

this a little differs fr= om my early reading on the MAP draft stating 1:1. you clarify here that in = any cases IPv4+PSID is embedded in the mapped IPv6 address.=A0
=A0
The PSID is intended to be passed as part of the Optional Port Parameters, = which the draft already has as part of the FMRs, and what has also been dis= cussed in the DT.

yes we = have the optional port parameters. but i didn't remember what DT discus= sed included the topic of having the value of PSID in the FMR.=A0

Please refer to Satoru-san's emails o= n the topic.

on the other hand, i think current talk is going on at = the WG stage rather than the DT. even if i didn't show objection to tha= t issue in the DT, i don't think i would have been disabled to show it = in the WG.=A0
=A0
This is another type of 1:1 rules, which I agree is an item of clarifica= tion in the draft, but eminently possible under the current spec as the the= MAP architecture is=A0 agnostic to how the IPv6+IPv4+Rules get to the devi= ce

sorry i cannot catch the= meaning of the "agnostic to"... :P i understand "how the IP= v6+IPv4+Rules get to the device" is the mission of MAP-DHCP rather tha= n the MAP architecture.=A0

Agnostic to means, that the working of th= e MAP architecture doesn't rely on any specific MAP rule or address pro= visioning method. Should be noted that IPv6 addresses are also provisioned,= and can be so by multiple methods.

"any specific MAP rule&qu= ot; or any specific rule-making algorithm? if the former, no objection here= . if the latter, i don't see anything essential other than a rule-makin= g algorithm in the "MAP architecture". and this rule-making algor= ithm is what i support through the MDT and the WG.=A0
=A0
=A0

if the multiple-CE domain = and the single-CE domain should have different attributes, i don't thin= k this is not a novelty. and i am against this configuration parameter no m= atter if it is *stated* as a non-novelty or not.=A0

And what is the reason for this obj= ection?

does MAP intend to = support mesh topology with the PSID value included in the rule? if so, i do= ubt any CE device (especially those having limited resources) can do with t= hat. if it is not, the architecture happens with 2 configurations not ortho= gonal: if PSID, no mesh -- it confuses that the highest priority design goa= l of MAP is not statelessness and simplicity but the PSID.=A0

therefore i am objective of introducing PSID into the r= ule and making the architecture stateless only in wording.=A0
- maoke
=A0

Regards,
Woj.


--20cf3005dcb22dd02004c538aaf4-- From leaf.y.yeh@huawei.com Fri Jul 20 02:22:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AF621F8585 for ; Fri, 20 Jul 2012 02:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 Vwf14ZnXKdWR for ; Fri, 20 Jul 2012 02:22:40 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 76DC821F856D for ; Fri, 20 Jul 2012 02:22:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX64242; Fri, 20 Jul 2012 05:23:35 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jul 2012 02:21:17 -0700 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jul 2012 02:21:23 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 20 Jul 2012 17:21:19 +0800 From: Leaf yeh To: Xing Li , Suresh Krishnan Thread-Topic: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 as wg draft Thread-Index: AQHNW7z+vlFgVEutvka773zIjcB73JchSw4AgBB7A9A= Date: Fri, 20 Jul 2012 09:21:18 +0000 Message-ID: References: <4FF7563E.2000101@ericsson.com> <4FFB945C.2000704@cernet.edu.cn> In-Reply-To: <4FFB945C.2000704@cernet.edu.cn> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.160] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Fri, 20 Jul 2012 09:22:41 -0000 KzENCg0KQmVzdCBSZWdhcmRzLA0KTGVhZg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNvZnR3aXJlcy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWGluZyBMaQ0KU2VudDogVHVlc2RheSwgSnVseSAx MCwgMjAxMiAxMDozMyBBTQ0KVG86IFN1cmVzaCBLcmlzaG5hbg0KQ2M6IFNvZnR3aXJlcyBXRzsg WW9uZyBDdWkNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBDYWxsIGZvciBhZG9wdGlvbiBvZiBk cmFmdC1tZHQtc29mdHdpcmUtbWFwLWRlcGxveW1lbnQtMDIgYXMgd2cgZHJhZnQNCg0KU3VwcG9y dCBhZG9wdGlvbi4NCg0KeGluZw0KDQpTdXJlc2ggS3Jpc2huYW4g5YaZ6YGTOg0KPiBIaSBhbGws DQo+ICAgVGhpcyBjYWxsIGlzIGJlaW5nIGluaXRpYXRlZCB0byBkZXRlcm1pbmUgd2hldGhlciB0 aGVyZSBpcyBXRw0KPiBjb25zZW5zdXMgdG93YXJkcyBhZG9wdGlvbiBvZiBkcmFmdC1tZHQtc29m dHdpcmUtbWFwLWRlcGxveW1lbnQtMDIgYXMgYQ0KPiBzb2Z0d2lyZSBXRyBkcmFmdC4gUGxlYXNl IHN0YXRlIHdoZXRoZXIgb3Igbm90IHlvdSdyZSBpbiBmYXZvciBvZiB0aGUNCj4gYWRvcHRpb24g YnkgcmVwbHlpbmcgdG8gdGhpcyBlbWFpbC4gSWYgeW91IGFyZSBub3QgaW4gZmF2b3IsIHBsZWFz ZSBhbHNvDQo+IHN0YXRlIHlvdXIgb2JqZWN0aW9ucyBpbiB5b3VyIHJlc3BvbnNlLiBUaGUgY2Fs bCB3aWxsIGNvbXBsZXRlIGF0DQo+IG1pZG5pZ2h0IFBEVCBvbiAyMDEyLTA3LTIwLg0KPg0KPiBS ZWdhcmRzDQo+IFN1cmVzaCAmIFlvbmcNCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiBTb2Z0 d2lyZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z b2Z0d2lyZXMNCj4NCj4NCj4gICANCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo= From satoru.matsushima@gmail.com Fri Jul 20 03:10:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAF421F851C for ; Fri, 20 Jul 2012 03:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 ElgxNg+8ccf0 for ; Fri, 20 Jul 2012 03:10:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08221F84D6 for ; Fri, 20 Jul 2012 03:10:53 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5489152obb.31 for ; Fri, 20 Jul 2012 03:11:49 -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=ju6hXq1Swrf09tzSfMrLbby71T2ixtcV58FjTzjpwFY=; b=mL7ECt0jO6SmC7moNbrR+iYmIMw1wUJ66aomPL322+eAOly92pH0cNS+DgAxhkx59y hNW/rUbSOtdi5bCm4eupRs5OMvcgXYyLvX4S6bMk6++LJTEkmnFdZm2zkR/Du7Pp45Cn gDzm6P3YMkHdE/EsfW9kfL8g7EnOrmrKOqDgV5XtX0RlaEdMItE+YdKNzV8qiODkF93V cLjdUXXLkUoroRoTlVCCIn3oCaqgvM4er7IxVE5KavxzpClgfRF4Rn2or5deyjJN6N+F DLNfbM//e9NxVbsMTJPZ4EoLro4BFp1UaL5cXSsBLv96bzs41m9B24RWTvsTunPfgcS2 2Xvg== MIME-Version: 1.0 Received: by 10.182.136.66 with SMTP id py2mr34418obb.9.1342779108929; Fri, 20 Jul 2012 03:11:48 -0700 (PDT) Received: by 10.182.60.34 with HTTP; Fri, 20 Jul 2012 03:11:48 -0700 (PDT) In-Reply-To: <4FF66AB7.4090808@ericsson.com> References: <4FF66AB7.4090808@ericsson.com> Date: Fri, 20 Jul 2012 19:11:48 +0900 Message-ID: From: Satoru Matsushima To: Suresh Krishnan Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 20 Jul 2012 10:10:54 -0000 Support. --satoru On Fri, Jul 6, 2012 at 1:33 PM, Suresh Krishnan wrote: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. > > Regards > Suresh & Yong > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From eleven.fuyu@huawei.com Fri Jul 20 03:34:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F38821F855A for ; Fri, 20 Jul 2012 03:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbmJkVRxun6x for ; Fri, 20 Jul 2012 03:34:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2A72021F8577 for ; Fri, 20 Jul 2012 03:34:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX68614; Fri, 20 Jul 2012 06:35:17 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jul 2012 03:33:30 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jul 2012 03:33:37 -0700 Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.26]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 20 Jul 2012 18:33:34 +0800 From: "Fuyu (Eleven)" To: "suresh.krishnan@ericsson.com" , Yong Cui Thread-Topic: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 as wg draft Thread-Index: AQHNXerWdCnfRjpZwUaFIyvhpHG2D5cyCJ2g Date: Fri, 20 Jul 2012 10:33:33 +0000 Message-ID: References: <4FF7563E.2000101@ericsson.com> 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.99.39] Content-Type: multipart/alternative; boundary="_000_EF6A204047BD994A860EE26D5F23BF582B8C44D6SZXEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-deployment-02 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: Fri, 20 Jul 2012 10:34:25 -0000 --_000_EF6A204047BD994A860EE26D5F23BF582B8C44D6SZXEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCBpdCB0byBiZSBXRyBkcmFmdA0KDQpDaGVlcnMNCll1DQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJvbTogU3VyZXNo IEtyaXNobmFuIDxzdXJlc2gua3Jpc2huYW5AZXJpY3Nzb24uY29tPG1haWx0bzpzdXJlc2gua3Jp c2huYW5AZXJpY3Nzb24uY29tPj4NCkRhdGU6IFNhdCwgSnVsIDcsIDIwMTIgYXQgNToxOCBBTQ0K U3ViamVjdDogW1NvZnR3aXJlc10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtbWR0LXNvZnR3 aXJlLW1hcC1kZXBsb3ltZW50LTAyIGFzIHdnIGRyYWZ0DQpUbzogU29mdHdpcmVzIFdHIDxzb2Z0 d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZz4+DQpDYzogWW9uZyBDdWkg PGN1aXlvbmdAdHNpbmdodWEuZWR1LmNuPG1haWx0bzpjdWl5b25nQHRzaW5naHVhLmVkdS5jbj4+ DQoNCg0KSGkgYWxsLA0KICBUaGlzIGNhbGwgaXMgYmVpbmcgaW5pdGlhdGVkIHRvIGRldGVybWlu ZSB3aGV0aGVyIHRoZXJlIGlzIFdHDQpjb25zZW5zdXMgdG93YXJkcyBhZG9wdGlvbiBvZiBkcmFm dC1tZHQtc29mdHdpcmUtbWFwLWRlcGxveW1lbnQtMDIgYXMgYQ0Kc29mdHdpcmUgV0cgZHJhZnQu IFBsZWFzZSBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2YgdGhlDQphZG9w dGlvbiBieSByZXBseWluZyB0byB0aGlzIGVtYWlsLiBJZiB5b3UgYXJlIG5vdCBpbiBmYXZvciwg cGxlYXNlIGFsc28NCnN0YXRlIHlvdXIgb2JqZWN0aW9ucyBpbiB5b3VyIHJlc3BvbnNlLiBUaGUg Y2FsbCB3aWxsIGNvbXBsZXRlIGF0DQptaWRuaWdodCBQRFQgb24gMjAxMi0wNy0yMC4NCg0KUmVn YXJkcw0KU3VyZXNoICYgWW9uZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2lyZXNAaWV0Zi5v cmc8bWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc29mdHdpcmVzDQoNCg0KDQoNCg== --_000_EF6A204047BD994A860EE26D5F23BF582B8C44D6SZXEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdXBwb3J0IGl0IHRvIGJlIFdH IGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WXU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOiA8Yj5TdXJlc2ggS3Jpc2huYW48L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86c3VyZXNo LmtyaXNobmFuQGVyaWNzc29uLmNvbSI+c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbTwvYT4m Z3Q7PGJyPg0KRGF0ZTogU2F0LCBKdWwgNywgMjAxMiBhdCA1OjE4IEFNPGJyPg0KU3ViamVjdDog W1NvZnR3aXJlc10gQ2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtbWR0LXNvZnR3aXJlLW1hcC1k ZXBsb3ltZW50LTAyIGFzIHdnIGRyYWZ0PGJyPg0KVG86IFNvZnR3aXJlcyBXRyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZyI+c29mdHdpcmVzQGlldGYub3JnPC9hPiZndDs8 YnI+DQpDYzogWW9uZyBDdWkgJmx0OzxhIGhyZWY9Im1haWx0bzpjdWl5b25nQHRzaW5naHVhLmVk dS5jbiI+Y3VpeW9uZ0B0c2luZ2h1YS5lZHUuY248L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCkhp IGFsbCw8YnI+DQombmJzcDsgVGhpcyBjYWxsIGlzIGJlaW5nIGluaXRpYXRlZCB0byBkZXRlcm1p bmUgd2hldGhlciB0aGVyZSBpcyBXRzxicj4NCmNvbnNlbnN1cyB0b3dhcmRzIGFkb3B0aW9uIG9m IGRyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAtZGVwbG95bWVudC0wMiBhcyBhPGJyPg0Kc29mdHdpcmUg V0cgZHJhZnQuIFBsZWFzZSBzdGF0ZSB3aGV0aGVyIG9yIG5vdCB5b3UncmUgaW4gZmF2b3Igb2Yg dGhlPGJyPg0KYWRvcHRpb24gYnkgcmVwbHlpbmcgdG8gdGhpcyBlbWFpbC4gSWYgeW91IGFyZSBu b3QgaW4gZmF2b3IsIHBsZWFzZSBhbHNvPGJyPg0Kc3RhdGUgeW91ciBvYmplY3Rpb25zIGluIHlv dXIgcmVzcG9uc2UuIFRoZSBjYWxsIHdpbGwgY29tcGxldGUgYXQ8YnI+DQptaWRuaWdodCBQRFQg b24gMjAxMi0wNy0yMC48YnI+DQo8YnI+DQpSZWdhcmRzPGJyPg0KU3VyZXNoICZhbXA7IFlvbmc8 YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 U29mdHdpcmVzQGlldGYub3JnIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxiciBj bGVhcj0iYWxsIj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_EF6A204047BD994A860EE26D5F23BF582B8C44D6SZXEML512MBSchi_-- From wdec.ietf@gmail.com Fri Jul 20 03:55:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0322B21F84F5 for ; Fri, 20 Jul 2012 03:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-Dglhvaewi9 for ; Fri, 20 Jul 2012 03:55:25 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA01C21F84EF for ; Fri, 20 Jul 2012 03:55:24 -0700 (PDT) Received: by qcac10 with SMTP id c10so2431486qca.31 for ; Fri, 20 Jul 2012 03:56: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=q067rJt9A3Dfbv1bq3llz2SLVwv4i7j7TVQ5hjJ0Wk8=; b=fv8AON/Xe22ejo9V1sG8DiSzvDvXMlbJi926Md5bxcQmLc1w/H0goe2ynpN+y7NFrQ +5oR/iUo35G4tvuptKssV3mQW4a/TkPBTMwueF5RTtzAoTdxqtGllGhxVLTxb0gIgB0R OhLIRrin7X8Fdpbthc9M5M8VoLaUjjq0S6MvK23bEUsnsRKKgoS87+EHKCP2ARoOBSM0 zBVVWvs43mKpE4p9wJdEoag8tEh0CFeGGbwhgraQZ7AYewFQBsGVLBe6PP1/OYoumJCz HUVBeTKaQCPzKcbeXEe5VnkNtYrJHgL6OQWGr0oW3GsW2MCDxKLN+Vx8nbcPNy1PGRld MktQ== MIME-Version: 1.0 Received: by 10.229.135.149 with SMTP id n21mr2439987qct.131.1342781780051; Fri, 20 Jul 2012 03:56:20 -0700 (PDT) Received: by 10.229.94.196 with HTTP; Fri, 20 Jul 2012 03:56:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Jul 2012 12:56:19 +0200 Message-ID: From: Wojciech Dec To: Maoke Content-Type: multipart/alternative; boundary=00248c768d8602c94504c540bf33 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 10:55:26 -0000 --00248c768d8602c94504c540bf33 Content-Type: text/plain; charset=ISO-8859-1 Hi Maoke, On 20 July 2012 03:17, Maoke wrote: > hi Woj, > > let me truncate the old text that makes this message too long. focusing on > the recent replies. > > 2012/7/19 Wojciech Dec > >> Hello Maoke, >> >> okay, if your "MAP algorithm" refers to the GMA, it is fine to state GMA >>> is usable to address/port-set assignment and/or stateless IPv4-mapped IPv6 >>> address generation. however, only the GMA doesn't make MAP as a "mapping of >>> address and port". the purpose of mapping is making a stateless packet >>> transform at the IPv4/IPv6 boundary and vise versa. >>> >> >> The mapping still happens, in the lower 64 bits. >> > > clarified. thanks. > > >> >> >>> if you argue GMA is generic for universal cases of A+P ( i actually >>> agree that ), i suggest to submit GMA separately as a standard or as an >>> update of A+P, so that stateful/stateless solutions are able to cite it >>> easily. >>> >> >> That's what it was, but it was said to be "too many drafts". >> >>> >>> >>>> In addition, the IPv4+PSID are still mapped to IID as per MAP. Thus >>>> there is no "algorithm is abandoned" case, as you put it. >>>> >>> >>> this a little differs from my early reading on the MAP draft stating >>> 1:1. you clarify here that in any cases IPv4+PSID is embedded in the mapped >>> IPv6 address. >>> >>> >>>> The PSID is intended to be passed as part of the Optional Port >>>> Parameters, which the draft already has as part of the FMRs, and what has >>>> also been discussed in the DT. >>>> >>> >>> yes we have the optional port parameters. but i didn't remember what DT >>> discussed included the topic of having the value of PSID in the FMR. >>> >> >> Please refer to Satoru-san's emails on the topic. >> >>> >>> on the other hand, i think current talk is going on at the WG stage >>> rather than the DT. even if i didn't show objection to that issue in the >>> DT, i don't think i would have been disabled to show it in the WG. >>> >>> >>>> This is another type of 1:1 rules, which I agree is an item of >>>> clarification in the draft, but eminently possible under the current spec >>>> as the the MAP architecture is agnostic to how the IPv6+IPv4+Rules get to >>>> the device >>>> >>> >>> sorry i cannot catch the meaning of the "agnostic to"... :P i understand >>> "how the IPv6+IPv4+Rules get to the device" is the mission of MAP-DHCP >>> rather than the MAP architecture. >>> >> >> Agnostic to means, that the working of the MAP architecture doesn't rely >> on any specific MAP rule or address provisioning method. Should be noted >> that IPv6 addresses are also provisioned, and can be so by multiple methods. >> > > "any specific MAP rule" or any specific rule-making algorithm? if the > former, no objection here. if the latter, i don't see anything essential > other than a rule-making algorithm in the "MAP architecture". and this > rule-making algorithm is what i support through the MDT and the WG. > No, I said, "any specific MAP rule provisioning method". In other words, the MAP architecture is not tied to *how* the MAP info gets to the CPE, be that ipv6 addressing, dhcpv6 or a combination of the two. > > >> >>> >>> if the multiple-CE domain and the single-CE domain should have different >>> attributes, i don't think this is not a novelty. and i am against this >>> configuration parameter no matter if it is *stated* as a non-novelty or >>> not. >>> >> >> And what is the reason for this objection? >> > > does MAP intend to support mesh topology with the PSID value included in > the rule? if so, i doubt any CE device (especially those having limited > resources) can do with that. if it is not, the architecture happens with 2 > configurations not orthogonal: if PSID, no mesh -- it confuses that the > highest priority design goal of MAP is not statelessness and simplicity but > the PSID. > The mesh topology is, and never was, a goal above all others. MAP supports hub&spoke and mesh. Even without an explictly provisioned PSID, there will be practical implementation limits to how many MAP rules a CE can have. The DMR *always* takes traffic not matching a more specific rule to the BR. > > therefore i am objective of introducing PSID into the rule and making the > architecture stateless only in wording. > If you mean that by having PSID as part of the rule, moves MAP from being stateless to "stateful", then that's a misstatement. As per one of the earlier posts, stateless does NOT mean configuration less, and MAP always required configuration, with PSID as part of rules or not. How much configuration one wants to deal with is subject to specific deployment considerations, and MAP allows that amount of configuration to be optimized if a good deal of cases. The working of MAP is unchanged with the use of the PSID as part of the ruleset, given a tradeoff with resepcet to more rules. The main point here though is another: If the use of PSIDs in rules is useful, as it appears to be, then there seems to be no reason not to allow that. Regards, Woj. > > - maoke > > >> >> Regards, >> Woj. >> >>> >>> >>> --00248c768d8602c94504c540bf33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Maoke,

On 20 July 2012 03:17, Maoke <f= ibrib@gmail.com> wrote:
hi Woj,

let me truncate the old text that= makes this message too long. focusing on the recent replies.=A0

<= div class=3D"gmail_quote">2012/7/19 Wojciech Dec <wdec.ietf@gmail.com>
Hello Maoke,

okay, if your "MAP algorithm" ref= ers to the GMA, it is fine to state GMA is usable to address/port-set assig= nment and/or stateless IPv4-mapped IPv6 address generation. however, only t= he GMA doesn't make MAP as a "mapping of address and port". t= he purpose of mapping is making a stateless packet transform at the IPv4/IP= v6 boundary and vise versa.

The mapping still ha= ppens, in the lower 64 bits.

<= div>clarified. thanks.
=A0


if you argue GMA is generic for universal cases of A+P = ( i actually agree that ), i suggest to submit GMA separately as a standard= or as an update of A+P, so that stateful/stateless solutions are able to c= ite it easily.=A0

That's what it was, but it was said t= o be "too many drafts".
=A0
In addition, the IPv4+PSID are still mapped to IID as per MAP. Thus there= is no "algorithm is abandoned" case, as you put it.

this a little differs fr= om my early reading on the MAP draft stating 1:1. you clarify here that in = any cases IPv4+PSID is embedded in the mapped IPv6 address.=A0
=A0
The PSID is intended to be passed as part of the Optional Port Parameters, = which the draft already has as part of the FMRs, and what has also been dis= cussed in the DT.

yes we = have the optional port parameters. but i didn't remember what DT discus= sed included the topic of having the value of PSID in the FMR.=A0

Please refer to Satoru-san's emails o= n the topic.

on the other hand, i think current talk is going on at = the WG stage rather than the DT. even if i didn't show objection to tha= t issue in the DT, i don't think i would have been disabled to show it = in the WG.=A0
=A0
This is another type of 1:1 rules, which I agree is an item of clarifica= tion in the draft, but eminently possible under the current spec as the the= MAP architecture is=A0 agnostic to how the IPv6+IPv4+Rules get to the devi= ce

sorry i cannot catch the= meaning of the "agnostic to"... :P i understand "how the IP= v6+IPv4+Rules get to the device" is the mission of MAP-DHCP rather tha= n the MAP architecture.=A0

Agnostic to means, that the working of th= e MAP architecture doesn't rely on any specific MAP rule or address pro= visioning method. Should be noted that IPv6 addresses are also provisioned,= and can be so by multiple methods.

"any specific MAP r= ule" or any specific rule-making algorithm? if the former, no objectio= n here. if the latter, i don't see anything essential other than a rule= -making algorithm in the "MAP architecture". and this rule-making= algorithm is what i support through the MDT and the WG.=A0


No, I said, "any specific MAP rule pro= visioning method". In other=20 words, the MAP architecture is not tied to *how* the MAP info gets to=20 the CPE, be that ipv6 addressing, dhcpv6 or a combination of the two.
= =A0
=A0
<= div>
=A0

if the multiple-CE domain = and the single-CE domain should have different attributes, i don't thin= k this is not a novelty. and i am against this configuration parameter no m= atter if it is *stated* as a non-novelty or not.=A0

And what is the reason for this obj= ection?

does MAP inte= nd to support mesh topology with the PSID value included in the rule? if so= , i doubt any CE device (especially those having limited resources) can do = with that. if it is not, the architecture happens with 2 configurations not= orthogonal: if PSID, no mesh -- it confuses that the highest priority desi= gn goal of MAP is not statelessness and simplicity but the PSID.=A0

The mesh topology is, and never was, a goal abo= ve all others. MAP=20 supports hub&spoke and mesh. Even without an explictly provisioned=20 PSID, there will be practical implementation limits to how many MAP=20 rules a CE can have. The DMR *always* takes traffic not matching a more=20 specific rule to the BR.
=A0

therefore i am objective of introducing PSID into the r= ule and making the architecture stateless only in wording.=A0

If you mean that by having PSID as part of the rule, mo= ves MAP from being stateless to "stateful", then that's a mis= statement.
As per one of the earlier posts, stateless does NOT mean configuration=20 less, and MAP always required configuration, with PSID as part of rules=20 or not. How much configuration one wants to deal with is subject to=20 specific deployment considerations, and MAP allows that amount of=20 configuration to be optimized if a good deal of cases. The working of=20 MAP is unchanged with the use of the PSID as part of the ruleset, given a tradeoff with resepcet to more rules.
The main point here though is another: If the use of PSIDs in rules is=20 useful, as it appears to be, then there seems to be no reason not to=20 allow that.

Regards,
Woj.
=A0

- maoke
= =A0

Regards,
Woj.



--00248c768d8602c94504c540bf33-- From wdec.ietf@gmail.com Fri Jul 20 03:56:07 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D2921F85CC for ; Fri, 20 Jul 2012 03:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVwUkDuHvbZ2 for ; Fri, 20 Jul 2012 03:56:07 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4316521F84EF for ; Fri, 20 Jul 2012 03:56:07 -0700 (PDT) Received: by qadz3 with SMTP id z3so125284qad.10 for ; Fri, 20 Jul 2012 03:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YrJyC9ff4BvrVtHi8Lx8tLXFarSgv/wHgmrLE4a6a5M=; b=sRwAU36F5BWFdxWINygnmOi52963ztNEuj8oGzOrQOtQ0AMH6CdWWz81OE86XzIs/i orVHl4/7fHrUvyuuqAgZ74qOHYaZb4eceTt5QRWlfLP/qGcSO9mBArwlJjj36RD9hE9B +7mp+bt2k4z2YZ2miRv5nsc4pzuNgyBc/zE5hclbKTu5bMo4oXZJP4liMMCw9a2ohRXA 02OnAI1FhXLyKh+F15YQvu5eljbhWwzz1SR27EEUELj5RFhyvoeYHGgFjZr5cb7NjpiL 7W2m9mpatYZwYzAJnKeJABzF5am0MHt2Sg8BaG3u0gJkaD0z3HlvJTgptBijVWgnke9I 4bBg== MIME-Version: 1.0 Received: by 10.224.101.193 with SMTP id d1mr9170998qao.20.1342781822539; Fri, 20 Jul 2012 03:57:02 -0700 (PDT) Received: by 10.229.94.196 with HTTP; Fri, 20 Jul 2012 03:57:02 -0700 (PDT) In-Reply-To: <4FF66AB7.4090808@ericsson.com> References: <4FF66AB7.4090808@ericsson.com> Date: Fri, 20 Jul 2012 12:57:02 +0200 Message-ID: From: Wojciech Dec To: Suresh Krishnan Content-Type: multipart/alternative; boundary=20cf306681578b16f104c540c186 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 20 Jul 2012 10:56:08 -0000 --20cf306681578b16f104c540c186 Content-Type: text/plain; charset=ISO-8859-1 Support On 6 July 2012 06:33, Suresh Krishnan wrote: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. > > Regards > Suresh & Yong > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf306681578b16f104c540c186 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support

On 6 July 2012 06:33, Suresh Kris= hnan <suresh.krishnan@ericsson.com> wrote:
Hi all,
=A0 This call is being initiated to determine whether there is WG
consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20.

Regards
Suresh & Yong

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

--20cf306681578b16f104c540c186-- From tom.taylor.stds@gmail.com Fri Jul 20 06:42:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA3021F8608 for ; Fri, 20 Jul 2012 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 PRKednlvzcmI for ; Fri, 20 Jul 2012 06:42:28 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA47121F85F6 for ; Fri, 20 Jul 2012 06:42:21 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so5568555lbb.31 for ; Fri, 20 Jul 2012 06:43:17 -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 :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=/gvGEzm9lQnQZyqDypX1j/3HYdD4zB6lkRcRNw/TVbs=; b=HGJccfd8fFVKiUnVtxzCfQfLXtZHZlaWk9WpVmQkDjQhvNMGI1kczLXMSHSK4tQBox Voeg3xQi7uI/61QLlX3cyX1DYqXhNQyZksCNCyCLu3SpnrqMe0Mp+nJdFoZXyxfV9NZi rfWDO3VdHmE9eBKNV1QeAjZauw3pV2lWcVLpN1fFEypGoeBu2WZR8jW/WXahd3qruYA8 iMYzIXkYpD82NTNWD81vEDiW+c4sJbKZ0I8DJ8wTCCP3MHNjtdUdB+ya25AsfB9GYBI/ z4/sJEg5PsxoHTn7AaihCNxlsmWzujr0flDLDUkjuzDNGPfvRCx/GerrPUMehcCiWb8w /oew== Received: by 10.112.82.165 with SMTP id j5mr3083985lby.50.1342791796582; Fri, 20 Jul 2012 06:43:16 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-32-179.tor.primus.ca. [173.206.32.179]) by mx.google.com with ESMTPS id sm7sm4963534lab.5.2012.07.20.06.43.12 (version=SSLv3 cipher=OTHER); Fri, 20 Jul 2012 06:43:16 -0700 (PDT) Message-ID: <50096068.5090007@gmail.com> Date: Fri, 20 Jul 2012 09:43:04 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: suresh.krishnan@ericsson.com, Yong Cui Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120720-0, 20/07/2012), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: [Softwires] 6rd Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 13:42:30 -0000 Chairs: if draft-ietf-softwire-dslite-multicast is not to be generalized, could a charter item be added for 6rd multicast? draft-tsou-softwire-6rd-multicast seems to be a reasobale candidate. Tom Taylor From despres.remi@laposte.net Fri Jul 20 08:02:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAA321F8653 for ; Fri, 20 Jul 2012 08:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gop2M5TVGSal for ; Fri, 20 Jul 2012 08:02:43 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6174F21F8637 for ; Fri, 20 Jul 2012 08:02:42 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 0FC19700005B; Fri, 20 Jul 2012 17:03:38 +0200 (CEST) Received: from [192.168.1.73] (194.204.170.89.rev.sfr.net [89.170.204.194]) by msfrf2208.sfr.fr (SMTP Server) with ESMTP id 7E6FF70000A2; Fri, 20 Jul 2012 17:03:37 +0200 (CEST) X-SFR-UUID: 20120720150337517.7E6FF70000A2@msfrf2208.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--582802990 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 20 Jul 2012 17:03:36 +0200 Message-Id: <41C34D15-F814-455A-9F66-06A6FD393E51@laposte.net> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 15:02:44 -0000 --Apple-Mail-6--582802990 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Wojciech, 2012-07-20 12:56, Wojciech Dec: > Hi Maoke, ... > therefore i am objective of introducing PSID into the rule and making = the architecture stateless only in wording.=20 >=20 > If you mean that by having PSID as part of the rule, moves MAP from = being stateless to "stateful", then that's a misstatement. I share Maoke's understanding here. Independently of other reasons to prefer 4rd to MAP-T+E, documented = elsewhere, I think that, in order to clarify what you mean, it would be = useful to describe a MAP use case where PSID-in-a-rule is needed. > As per one of the earlier posts, stateless does NOT mean configuration = less, and MAP always required configuration, with PSID as part of rules = or not. How much configuration one wants to deal with is subject to = specific deployment considerations, and MAP allows that amount of = configuration to be optimized if a good deal of cases. The working of = MAP is unchanged with the use of the PSID as part of the ruleset, given = a tradeoff with resepcet to more rules.=20 > The main point here though is another: > If the use of PSIDs in rules is useful, as it appears to be, This is the point that needs to be explained. Thanks. RD =20 > then there seems to be no reason not to allow that. >=20 > Regards, > Woj. > =20 >=20 > - maoke > =20 >=20 > Regards, > Woj.=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-6--582802990 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, = Wojciech,

2012-07-20 12:56, Wojciech Dec:

Hi = Maoke,
...
therefore i am objective of introducing PSID = into the rule and making the architecture stateless only in = wording. 

If you mean that by = having PSID as part of the rule, moves MAP from being stateless to = "stateful", then that's a = misstatement.

I share Maoke's = understanding here.
Independently of other reasons to prefer = 4rd to MAP-T+E, documented elsewhere, I think that, in order = to clarify what you mean, it would be useful to describe a MAP = use case where PSID-in-a-rule is = needed.

As per one of the earlier posts, stateless does NOT mean configuration=20= less, and MAP always required configuration, with PSID as part of rules=20= or not. How much configuration one wants to deal with is subject to=20 specific deployment considerations, and MAP allows that amount of=20 configuration to be optimized if a good deal of cases. The working of=20 MAP is unchanged with the use of the PSID as part of the ruleset, given = a tradeoff with resepcet to more rules.
The main point here though is another: =

If the use of PSIDs in rules is=20 useful, as it appears to be, =

This is the point that = needs to be = explained.
Thanks.
RD
 
then there seems to be = no reason not to=20 allow that.

Regards,
Woj.
 

- = maoke
 

Regards,
Woj. =
=



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

= = --Apple-Mail-6--582802990-- From sarikaya2012@gmail.com Fri Jul 20 08:09:59 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306EE21F85A0 for ; Fri, 20 Jul 2012 08:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 9YHZWKLoS2uY for ; Fri, 20 Jul 2012 08:09:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABBF21F8599 for ; Fri, 20 Jul 2012 08:09:53 -0700 (PDT) Received: by yhq56 with SMTP id 56so4469678yhq.31 for ; Fri, 20 Jul 2012 08:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8tP5IuV60rQXBosF1V5TLD6/hdHN1T+HPn6Y+wIQmA0=; b=B3p3obJ/2xu8Qm8AsZe26i6ITsnh/KvK1aWUWorgUeUNRzT05J3brtulg4GNPIk6tz pCvKg1Kbok/MWyK8N0rD3ecfEFioNPmvlF7xB0dS3CaD1FA0Zcc8/g3yegMst3mifHY9 GtPtXgcpI6NC2Oa4AVf1kr//xSRMAjv9TPJf4GbSUWnFZaS8MazUdhdIlYkzf1u4jWLI +3MKM6RkuAI0/HffQ5dszTHNCxXR2vjd4mG/giL3Kkzoc8Kj19AGL0hZEkbDRS7FqrBU 7nxWhm3Z24dwZnJ147pqiLZe9EHUp0gTK/HM2HDoGuz052oPBdrRSJwfedVYUGlMg9sn 8ipg== MIME-Version: 1.0 Received: by 10.50.195.234 with SMTP id ih10mr4808994igc.0.1342797049788; Fri, 20 Jul 2012 08:10:49 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Fri, 20 Jul 2012 08:10:49 -0700 (PDT) In-Reply-To: <50096068.5090007@gmail.com> References: <50096068.5090007@gmail.com> Date: Fri, 20 Jul 2012 10:10:49 -0500 Message-ID: From: Behcet Sarikaya To: Tom Taylor Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires , Yong Cui Subject: Re: [Softwires] 6rd Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 15:09:59 -0000 On Fri, Jul 20, 2012 at 8:43 AM, Tom Taylor wrote: > Chairs: if draft-ietf-softwire-dslite-multicast is not to be generalized, > could a charter item be added for 6rd multicast? > draft-tsou-softwire-6rd-multicast seems to be a reasobale candidate. There is already a charter item for 6rd multicast extensions. Behcet From Tina.Tsou.Zouting@huawei.com Fri Jul 20 08:51:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4695121F85CE for ; Fri, 20 Jul 2012 08:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.969 X-Spam-Level: X-Spam-Status: No, score=-5.969 tagged_above=-999 required=5 tests=[AWL=0.629, 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 rfxsKHhMCQSg for ; Fri, 20 Jul 2012 08:51:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26621F85C7 for ; Fri, 20 Jul 2012 08:51:41 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIE81678; Fri, 20 Jul 2012 11:52:37 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jul 2012 08:50:48 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 20 Jul 2012 08:50:51 -0700 From: Tina TSOU To: Wojciech Dec Thread-Topic: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 as wg draft Thread-Index: AQHNWzCf2O5YYEZmo02EgzV1xQ7pB5cyi8AA///cvgA= Date: Fri, 20 Jul 2012 15:50:51 +0000 Message-ID: References: <4FF66AB7.4090808@ericsson.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D8B81C9707F04177837FD44E0C4D4385huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 20 Jul 2012 15:51:42 -0000 --_000_D8B81C9707F04177837FD44E0C4D4385huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Tina On Jul 20, 2012, at 3:57 AM, "Wojciech Dec" > wrote: Support On 6 July 2012 06:33, Suresh Krishnan > wrote: Hi all, This call is being initiated to determine whether there is WG consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. Regards Suresh & Yong _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_D8B81C9707F04177837FD44E0C4D4385huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Support.

Tina

On Jul 20, 2012, at 3:57 AM, "Wojciech Dec" <wdec.ietf@gmail.com> wrote:

Support

On 6 July 2012 06:33, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
Hi all,
  This call is being initiated to determine whether there is WG
consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20.

Regards
Suresh & Yong

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

--_000_D8B81C9707F04177837FD44E0C4D4385huaweicom_-- From Tetsuya.Murakami@ipinfusion.com Fri Jul 20 08:52:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D5421F85E3 for ; Fri, 20 Jul 2012 08:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 V0ufxMkrHZ5r for ; Fri, 20 Jul 2012 08:52:14 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id D3DB521F8616 for ; Fri, 20 Jul 2012 08:52:13 -0700 (PDT) Received: from mail46-db3-R.bigfish.com (10.3.81.252) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Jul 2012 15:53:09 +0000 Received: from mail46-db3 (localhost [127.0.0.1]) by mail46-db3-R.bigfish.com (Postfix) with ESMTP id 514EF1403D5; Fri, 20 Jul 2012 15:53:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI1432I14ffIzz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25he5bhf0ah107ah) Received-SPF: pass (mail46-db3: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail46-db3 (localhost.localdomain [127.0.0.1]) by mail46-db3 (MessageSwitch) id 1342799586953678_17962; Fri, 20 Jul 2012 15:53:06 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.247]) by mail46-db3.bigfish.com (Postfix) with ESMTP id E6FA84C00FA; Fri, 20 Jul 2012 15:53:06 +0000 (UTC) Received: from CH1PRD0510HT001.namprd05.prod.outlook.com (157.56.244.213) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Jul 2012 15:53:06 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.7.116]) by CH1PRD0510HT001.namprd05.prod.outlook.com ([10.255.150.36]) with mapi id 14.16.0175.005; Fri, 20 Jul 2012 15:53:01 +0000 From: Tetsuya Murakami To: Suresh Krishnan Thread-Topic: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 as wg draft Thread-Index: AQHNZo+932lrcTw20E6TfSNYizmlyQ== Date: Fri, 20 Jul 2012 15:53:01 +0000 Message-ID: References: <4FF66AB7.4090808@ericsson.com> In-Reply-To: <4FF66AB7.4090808@ericsson.com> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <7185CA61307BD84ABED3B98A56536780@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 20 Jul 2012 15:52:14 -0000 Support. - Tetsuya On 2012/07/05, at 21:33, Suresh Krishnan wrote: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. >=20 > Regards > Suresh & Yong >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 From wwwrun@rfc-editor.org Fri Jul 20 10:12:27 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D84711E80A1; Fri, 20 Jul 2012 10:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_93=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 l6VeJxdgn5n7; Fri, 20 Jul 2012 10:12:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A9B6711E8072; Fri, 20 Jul 2012 10:12:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A1A2EB1E002; Fri, 20 Jul 2012 10:12:40 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120720171240.A1A2EB1E002@rfc-editor.org> Date: Fri, 20 Jul 2012 10:12:40 -0700 (PDT) Cc: softwires@ietf.org, rfc-editor@rfc-editor.org Subject: [Softwires] RFC 6674 on Gateway-Initiated Dual-Stack Lite Deployment X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 20 Jul 2012 17:12:27 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6674 Title: Gateway-Initiated Dual-Stack Lite Deployment Author: F. Brockners, S. Gundavelli, S. Speicher, D. Ward Status: Standards Track Stream: IETF Date: July 2012 Mailbox: fbrockne@cisco.com, sgundave@cisco.com, sebastian.speicher@telekom.de, wardd@cisco.com Pages: 15 Characters: 32731 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-softwire-gateway-init-ds-lite-08.txt URL: http://www.rfc-editor.org/rfc/rfc6674.txt Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual- Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded Context Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. [STANDARDS-TRACK] This document is a product of the Softwires Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wdec.ietf@gmail.com Fri Jul 20 10:50:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CE511E807F for ; Fri, 20 Jul 2012 10:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfA3RrYPL5OB for ; Fri, 20 Jul 2012 10:50:53 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 10ED321F867E for ; Fri, 20 Jul 2012 10:50:49 -0700 (PDT) Received: by qcac10 with SMTP id c10so2643418qca.31 for ; Fri, 20 Jul 2012 10:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sz1re0L4gu7ScXfHnPSgrDf0U59Y1cx+Z9q7Tg6sl50=; b=tLSd4FfGhUspctpQbkw1l79Drza5syLsQPdM8e/v7piMUflZe4USgGRkvVmfYbrq0t LOdDjQqzmfEKVC8KwdfxMUzqgkiEkpZqMIps4xOTyR8zHeYgUyL7hQiYuXmiCZWByq5I LXQ1yTso+mTrLuM3eDj5FnA5m4W4CBjvODFk2u0kL7LMnedIz9MXGmxHYiW0jfcwdnso YobGBGIdir+hMs3wMb8nWs7aTKI0WmAc0Z+KgxxyQkqFQHfl8VDisWwOSowZb3rVcGuJ Ion3yx6P5lYqRZeZZ9ZoOLkzqpoyWvvB0jlc3hKT5INYDN0si5VQlr4mmA8V0B9+aCLX uTYg== MIME-Version: 1.0 Received: by 10.224.101.193 with SMTP id d1mr11335707qao.20.1342806706157; Fri, 20 Jul 2012 10:51:46 -0700 (PDT) Received: by 10.229.94.196 with HTTP; Fri, 20 Jul 2012 10:51:46 -0700 (PDT) In-Reply-To: <41C34D15-F814-455A-9F66-06A6FD393E51@laposte.net> References: <41C34D15-F814-455A-9F66-06A6FD393E51@laposte.net> Date: Fri, 20 Jul 2012 19:51:46 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30668157b8f97a04c5468cb6 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 17:50:55 -0000 --20cf30668157b8f97a04c5468cb6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, On 20 July 2012 17:03, R=E9mi Despr=E9s wrote: > Hi, Wojciech, > > 2012-07-20 12:56, Wojciech Dec: > > If the use of PSIDs in rules is useful, as it appears to be, > > > This is the point that needs to be explained. > The case is straightforward A+P. For a single IPv4 address + port range it is desired to have it correspond to an IPv6 address. MAP and 4rd-u have that as a well established case with the IPv4 address and / or PSID being mapped into the IPv6 prefix, but the IPv4 address not given that it is configured on both sides (implicit). There is nothing in the MAP architecture which restricts the PSID to not be such an implicit parameter given that it can be configured at either side. -Woj. > Thanks. > RD > > > then there seems to be no reason not to allow that. > > Regards, > Woj. > > >> >> - maoke >> >> >>> >>> Regards, >>> Woj. >>> >>>> >>>> >>>> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --20cf30668157b8f97a04c5468cb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi,

On 20 July 2012 17:03, R=E9mi Despr= =E9s <despres.remi@laposte.net> wrote:
Hi, Wojciech,

2012-07-20 12:56, Wojciech Dec:

If the use of PSIDs in rules is=20 useful, as it appears to be,

=
This is the point that needs to be explained.

The case is straightforward A+P.
For a single= IPv4 address + port range it is desired to have it correspond to an IPv6 a= ddress.
MAP and 4rd-u have that as a well established case with the IPv4 address an= d / or PSID being mapped into the IPv6 prefix, but the IPv4 address not giv= en that it is configured on both sides (implicit). There is nothing in the = MAP architecture which restricts the PSID to not be such an implicit parame= ter given that it can be configured at either side.

-Woj.

=A0
Thanks.
RD
=A0
then there seems to be no reason not t= o=20 allow that.

Regards,
Woj.
=A0

- maoke
= =A0

Regards,
Woj.



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


--20cf30668157b8f97a04c5468cb6-- From rajiva@cisco.com Fri Jul 20 10:53:51 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32E021F8505 for ; Fri, 20 Jul 2012 10:53:51 -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 t+Nc5qJ7w96U for ; Fri, 20 Jul 2012 10:53:51 -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 E7EFB21F84FE for ; Fri, 20 Jul 2012 10:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1261; q=dns/txt; s=iport; t=1342806887; x=1344016487; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cPaUJ3CmN0UM3Ysi4G/fmuB+uUtnqIU1sLnm6QvOxoA=; b=iNXAeUBg1F1OCWjlG45gv2QJgmiokOIgqj+PTxS8TLQbkrsiUB1lcbAY z76VTUAaDkzn5DfnNwH+jlh+aO8xJ9sfqTRN85CNZ2pyiUUvy0d4lOd3n qweL1fgh8tvQlu0MCRaylltPKijRig+vHGqZ9zExFGmJdGgO6G+5aasoF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEWaCVCtJV2Z/2dsb2JhbABFuUaBB4IgAQEBBAEBAQ8BCh00CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgah2sLnkqgIQSLToYAYAOjaYFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,623,1336348800"; d="scan'208";a="103876622" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2012 17:54:47 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6KHsl4s029234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Jul 2012 17:54:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.67]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Fri, 20 Jul 2012 12:54:47 -0500 From: "Rajiv Asati (rajiva)" To: Satoru Matsushima , Suresh Krishnan Thread-Topic: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 as wg draft Thread-Index: AQHNZmAYfT1vCZstTk+bdNU9sHitOJcydLig Date: Fri, 20 Jul 2012 17:54:50 +0000 Message-ID: References: <4FF66AB7.4090808@ericsson.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.108] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19052.005 x-tm-as-result: No--49.095600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 20 Jul 2012 17:53:51 -0000 Support. Cheers, Rajiv > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Satoru Matsushima > Sent: Friday, July 20, 2012 6:12 AM > To: Suresh Krishnan > Cc: Softwires WG; Yong Cui > Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp= - > option-03 as wg draft >=20 > Support. > --satoru >=20 > On Fri, Jul 6, 2012 at 1:33 PM, Suresh Krishnan > wrote: > > Hi all, > > This call is being initiated to determine whether there is WG > > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. > > > > 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 From shtsuchi@cisco.com Fri Jul 20 15:19:39 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C6921F847E for ; Fri, 20 Jul 2012 15:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=0.420, 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 I3Ud4K-WTBiV for ; Fri, 20 Jul 2012 15:19:39 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id B52C921F847D for ; Fri, 20 Jul 2012 15:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=674; q=dns/txt; s=iport; t=1342822836; x=1344032436; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bG+kMJaLG4AgNflB1c82xUjQJpDbkoOzaTMUh5xSbJ4=; b=ZJA9BPdtcEilTlyJzgFQqwFwWSk/mudYPAhpaad1Jomduh7tQMRWmKKu PnaRkyNoOPFjE269vp3jGJlFru+yVLhfkR2F2Bg8iPNVX0ywanbKxgRl+ BZqu6UYn6ZCQUWtLeNENVC7V9qY+4EnUTfvp0ulfz5WizQtQKHkzjmHOo 4=; X-IronPort-AV: E=Sophos;i="4.77,626,1336348800"; d="scan'208";a="15211891" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 20 Jul 2012 22:20:34 +0000 Received: from [10.71.44.85] (tky-shtsuchi-8914.cisco.com [10.71.44.85]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6KMKXd2032366; Fri, 20 Jul 2012 22:20:33 GMT Message-ID: <5009D9AE.8070905@cisco.com> Date: Sat, 21 Jul 2012 07:20:30 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: suresh.krishnan@ericsson.com References: <4FF66AB7.4090808@ericsson.com> In-Reply-To: <4FF66AB7.4090808@ericsson.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Fri, 20 Jul 2012 22:19:40 -0000 Support! Regards, -Shishio (2012/07/06 13:33), Suresh Krishnan wrote: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. > > Regards > Suresh & Yong > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From bingxuere@gmail.com Sat Jul 21 02:47:56 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24CE21F8688 for ; Sat, 21 Jul 2012 02:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USvxSwdObir8 for ; Sat, 21 Jul 2012 02:47:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D31B921F85FB for ; Sat, 21 Jul 2012 02:47:55 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so7915923pbc.31 for ; Sat, 21 Jul 2012 02:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:from:to:cc:mime-version:content-type; bh=EKyGPm0AoliWQHOdV0nR4dWS0gI1yyKN2/XGg4ds8R0=; b=Bl3XkPHpduvEUQgbilfeqOz7vGXtP84jYYg3vJjXH6lZD2SI5gHRWucwBRI6bG3gIU ITSqep5kN3aTCOS5qn4OaBaSFaXKQtitXB6d3heH1hb9Q4S63LrVBYKkd8er913cyh4D nGWJ4pQSpQCDQ46/gdMw7iQoHIk09cHIyaCJTlKoBnQ3py9aEqDMjecxk1L2adm10AAu dE11oxlEzv/jWGtw2jOkW6/n8LrNvJxybD1cl3B1UOFNyFanT/EqilXP6Shc1TiIMqOR 8+1cBR0rRh+ZC2QZ0I31Xi0ZLWHD0chBaIxy82sMfCQ3hBhlLRQ4OOtA6vXwCUDdKKPw McDg== Received: by 10.68.226.131 with SMTP id rs3mr20266241pbc.62.1342864134051; Sat, 21 Jul 2012 02:48:54 -0700 (PDT) Received: from [172.21.162.239] ([61.148.244.38]) by mx.google.com with ESMTPS id qp9sm5766901pbc.9.2012.07.21.02.48.48 (version=SSLv3 cipher=OTHER); Sat, 21 Jul 2012 02:48:52 -0700 (PDT) Date: Sat, 21 Jul 2012 17:46:45 +0800 Message-ID: From: Qiong To: Wojciech Dec MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_430471291503900" Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 09:47:56 -0000 ----_com.android.email_430471291503900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIFdvaiwKClRoaXMgaXMgbm90IG9ubHkgYWJvdXQgZGV0ZXJtaW5pbmcgd2hpY2ggcGFyYW1l dGVyIHRvIGV4cGxpY2l0bHkgZXhpc3QgaW4gTUFQIHJ1bGUsIGJ1dCBhbHNvIHRoZSBjb25maWd1 cmF0aW9uIGluIEJSLiBJZiB5b3UgaW5jbHVkZSBQU0lEIGV4cGxpY2l0bHksIHRoZW4KMSkgeW91 IG5lZWQgdG8gY29uZmlndXJlIHBlci1zdWJzY3JpYmVyIHJ1bGUgaW4gQlIgc2luY2UgdGhlIHZh bHVlIG9mIFBTSUQgZm9yIGRpZmZlcmVudCBDUEVzIGFyZSBkaWZmZXJlbnQuIFRoaXMgd2lsbCB0 YWtlIGEgbG90IG9mIHdvcmtsb2FkIGZvciBvcGVyYXRvcnMgYW5kIGl0IGlzIG9idmlvdXNseSBu b3QgdGhlIG9iamVjdGl2ZSBvZiBhbnkgc3RhdGVsZXNzIHNvbHV0aW9uLgoyKSBJUHY2IHByZWZp eCBoYXMgYWxyZWFkeSBjYXJyeSB0aGUgUFNJRCBpbXBsaWNpdGx5LCBhbmQgdGhlIFBTSUQgaW4g TUFQIHJ1bGUgaXMgcmVkdW5kYW50LgpUaGVyZWZvcmUsIEkgZG9uJ3Qgc2VlIHRoZSByZWFzb24g dG8gaW5jbHVkZSBQU0lEIGV4cGxpY2l0bHkgaW4gTUFQIGFyY2hpdGVjdHVyZS4KCkJlc3Qgd2lz aGVzClFpb25nCgpXb2pjaWVjaCBEZWMgPHdkZWMuaWV0ZkBnbWFpbC5jb20+57yW5YaZ77yaCgo+ UmVtaSwKPgo+T24gMjAgSnVseSAyMDEyIDE3OjAzLCBSw6ltaSBEZXNwcsOpcyA8ZGVzcHJlcy5y ZW1pQGxhcG9zdGUubmV0PiB3cm90ZToKPgo+PiBIaSwgV29qY2llY2gsCj4+Cj4+IDIwMTItMDct MjAgMTI6NTYsIFdvamNpZWNoIERlYzoKPj4KPj4gSWYgdGhlIHVzZSBvZiBQU0lEcyBpbiBydWxl cyBpcyB1c2VmdWwsIGFzIGl0IGFwcGVhcnMgdG8gYmUsCj4+Cj4+Cj4+IFRoaXMgaXMgdGhlIHBv aW50IHRoYXQgbmVlZHMgdG8gYmUgZXhwbGFpbmVkLgo+Pgo+Cj5UaGUgY2FzZSBpcyBzdHJhaWdo dGZvcndhcmQgQStQLgo+Rm9yIGEgc2luZ2xlIElQdjQgYWRkcmVzcyArIHBvcnQgcmFuZ2UgaXQg aXMgZGVzaXJlZCB0byBoYXZlIGl0IGNvcnJlc3BvbmQKPnRvIGFuIElQdjYgYWRkcmVzcy4KPk1B UCBhbmQgNHJkLXUgaGF2ZSB0aGF0IGFzIGEgd2VsbCBlc3RhYmxpc2hlZCBjYXNlIHdpdGggdGhl IElQdjQgYWRkcmVzcwo+YW5kIC8gb3IgUFNJRCBiZWluZyBtYXBwZWQgaW50byB0aGUgSVB2NiBw cmVmaXgsIGJ1dCB0aGUgSVB2NCBhZGRyZXNzIG5vdAo+Z2l2ZW4gdGhhdCBpdCBpcyBjb25maWd1 cmVkIG9uIGJvdGggc2lkZXMgKGltcGxpY2l0KS4gVGhlcmUgaXMgbm90aGluZyBpbgo+dGhlIE1B UCBhcmNoaXRlY3R1cmUgd2hpY2ggcmVzdHJpY3RzIHRoZSBQU0lEIHRvIG5vdCBiZSBzdWNoIGFu IGltcGxpY2l0Cj5wYXJhbWV0ZXIgZ2l2ZW4gdGhhdCBpdCBjYW4gYmUgY29uZmlndXJlZCBhdCBl aXRoZXIgc2lkZS4KPgo+LVdvai4KPgo+Cj4KPj4gVGhhbmtzLgo+PiBSRAo+Pgo+Pgo+PiB0aGVu IHRoZXJlIHNlZW1zIHRvIGJlIG5vIHJlYXNvbiBub3QgdG8gYWxsb3cgdGhhdC4KPj4KPj4gUmVn YXJkcywKPj4gV29qLgo+Pgo+Pgo+Pj4KPj4+IC0gbWFva2UKPj4+Cj4+Pgo+Pj4+Cj4+Pj4gUmVn YXJkcywKPj4+PiBXb2ouCj4+Pj4KPj4+Pj4KPj4+Pj4KPj4+Pj4KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gU29mdHdpcmVzIG1haWxpbmcgbGlz dAo+PiBTb2Z0d2lyZXNAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zb2Z0d2lyZXMKPj4KPj4KPj4KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPlNvZnR3aXJlcyBtYWlsaW5nIGxpc3QKPlNvZnR3aXJlc0Bp ZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMK ----_com.android.email_430471291503900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 SGksIFdvaiw8YnI+PGJyPlRoaXMgaXMgbm90IG9ubHkgYWJvdXQgZGV0ZXJtaW5pbmcgd2hpY2gg cGFyYW1ldGVyIHRvIGV4cGxpY2l0bHkgZXhpc3QgaW4gTUFQIHJ1bGUsIGJ1dCBhbHNvIHRoZSBj b25maWd1cmF0aW9uIGluIEJSLiBJZiB5b3UgaW5jbHVkZSBQU0lEIGV4cGxpY2l0bHksIHRoZW48 YnI+MSkgeW91IG5lZWQgdG8gY29uZmlndXJlIHBlci1zdWJzY3JpYmVyIHJ1bGUgaW4gQlIgc2lu Y2UgdGhlIHZhbHVlIG9mIFBTSUQgZm9yIGRpZmZlcmVudCBDUEVzIGFyZSBkaWZmZXJlbnQuIFRo aXMgd2lsbCB0YWtlIGEgbG90IG9mIHdvcmtsb2FkIGZvciBvcGVyYXRvcnMgYW5kIGl0IGlzIG9i dmlvdXNseSBub3QgdGhlIG9iamVjdGl2ZSBvZiBhbnkgc3RhdGVsZXNzIHNvbHV0aW9uLjxicj4y KSBJUHY2IHByZWZpeCBoYXMgYWxyZWFkeSBjYXJyeSB0aGUgUFNJRCBpbXBsaWNpdGx5LCBhbmQg dGhlIFBTSUQgaW4gTUFQIHJ1bGUgaXMgcmVkdW5kYW50Ljxicj5UaGVyZWZvcmUsIEkgZG9uJiMz OTt0IHNlZSB0aGUgcmVhc29uIHRvIGluY2x1ZGUgUFNJRCBleHBsaWNpdGx5IGluIE1BUCBhcmNo aXRlY3R1cmUuPGJyPjxicj5CZXN0IHdpc2hlczxicj5RaW9uZzxicj48YnI+V29qY2llY2ggRGVj ICZsdDt3ZGVjLmlldGZAZ21haWwuY29tJmd0O+e8luWGme+8mjxicj48YnI+UmVtaSw8YnI+PGJy PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAyMCBKdWx5IDIwMTIgMTc6MDMsIFLDqW1pIERl c3Byw6lzIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmRlc3ByZXMucmVtaUBs YXBvc3RlLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmRlc3ByZXMucmVtaUBsYXBvc3RlLm5ldDwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHls ZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1s ZWZ0OjFleCI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+SGksIFdvamNpZWNo LDxkaXY+PGJyPjxkaXYgY2xhc3M9ImltIj48ZGl2PjIwMTItMDctMjAgMTI6NTYsIFdvamNpZWNo IERlYzo8L2Rpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdiBjbGFzcz0iZ21haWxf cXVvdGUiPjxkaXY+SWYgdGhlIHVzZSBvZiBQU0lEcyBpbiBydWxlcyBpcyANCnVzZWZ1bCwgYXMg aXQgYXBwZWFycyB0byBiZSwgPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdj5UaGlzIGlzIHRoZSBwb2ludCB0aGF0IG5lZWRzIHRvIGJlIGV4cGxh aW5lZC48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+VGhlIGNh c2UgaXMgc3RyYWlnaHRmb3J3YXJkIEErUC4gPGJyPkZvciBhIHNpbmdsZSBJUHY0IGFkZHJlc3Mg KyBwb3J0IHJhbmdlIGl0IGlzIGRlc2lyZWQgdG8gaGF2ZSBpdCBjb3JyZXNwb25kIHRvIGFuIElQ djYgYWRkcmVzcy48YnI+DQpNQVAgYW5kIDRyZC11IGhhdmUgdGhhdCBhcyBhIHdlbGwgZXN0YWJs aXNoZWQgY2FzZSB3aXRoIHRoZSBJUHY0IGFkZHJlc3MgYW5kIC8gb3IgUFNJRCBiZWluZyBtYXBw ZWQgaW50byB0aGUgSVB2NiBwcmVmaXgsIGJ1dCB0aGUgSVB2NCBhZGRyZXNzIG5vdCBnaXZlbiB0 aGF0IGl0IGlzIGNvbmZpZ3VyZWQgb24gYm90aCBzaWRlcyAoaW1wbGljaXQpLiBUaGVyZSBpcyBu b3RoaW5nIGluIHRoZSBNQVAgYXJjaGl0ZWN0dXJlIHdoaWNoIHJlc3RyaWN0cyB0aGUgUFNJRCB0 byBub3QgYmUgc3VjaCBhbiBpbXBsaWNpdCBwYXJhbWV0ZXIgZ2l2ZW4gdGhhdCBpdCBjYW4gYmUg Y29uZmlndXJlZCBhdCBlaXRoZXIgc2lkZS48YnI+DQo8YnI+LVdvai48YnI+PGJyPsKgPC9kaXY+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQiPjxkaXY+PGRpdj48ZGl2PlRoYW5rcy48L2Rpdj48c3BhbiBj bGFzcz0iSE9FblpiIj48Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGRpdj4NClJEPC9kaXY+PGRpdj7C oDwvZGl2PjwvZm9udD48L3NwYW4+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdiBjbGFzcz0i aW0iPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2PnRoZW4gdGhlcmUgc2VlbXMgdG8gYmUg bm8gcmVhc29uIG5vdCB0byANCmFsbG93IHRoYXQuPGJyPjxicj5SZWdhcmRzLDxicj5Xb2ouPGJy PsKgPGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgi PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi0gbWFva2U8L2Rp dj48ZGl2PsKgPC9kaXY+DQoNCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXY+PGJyPlJlZ2FyZHMsPGJyPldv ai4gPGJyPjwvZGl2PjxkaXY+PGRpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQoNCjxkaXY+PGJyPjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2Nr cXVvdGU+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjxkaXYgY2xhc3M9Imlt Ij4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPlNv ZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPlNvZnR3aXJlc0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvYT48 YnI+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90 ZT48L2Rpdj48YnI+DQo= ----_com.android.email_430471291503900-- From wdec.ietf@gmail.com Mon Jul 23 01:06:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61C621F8535 for ; Mon, 23 Jul 2012 01:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNXR3j6fBzB9 for ; Mon, 23 Jul 2012 01:06:41 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8E9621F8505 for ; Mon, 23 Jul 2012 01:06:41 -0700 (PDT) Received: by qcac10 with SMTP id c10so3346429qca.31 for ; Mon, 23 Jul 2012 01:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kc3x46SIcexhBYARc2tJLbDkBxLig3URSJMb+foF6hg=; b=rMDt65+OYxRpcFl7Jas/ZRksQZj+ZPURpDyzJImsb7c4avxUBIdCFnkaRxneSyoVYR 3OAV7LU76LQVWRHHBF6Y1chseWSR0x821/l6qMiOBAdiZml4YfJ+q/atCSrcm1BIjQ8p 35xxUbZldkxTfO1af6Bl0tZlX/hcWAWOuG2B778TkpakYdZOtewXkeCjH2T+gJGfR1qA JwGx8F3R4l94c6dGQWf8GfUi/CcKJ+g1zPyL02y2UCSTA46DXvZGnm/kK9UccZl3X1so AUSarhM6gm9vO8oV53Td0Tz9PWrDPNcHAniORJf/1eADd4SCAmj0PRjjfmq2/Kud1MCd 0cfQ== MIME-Version: 1.0 Received: by 10.224.177.1 with SMTP id bg1mr23156469qab.68.1343030800982; Mon, 23 Jul 2012 01:06:40 -0700 (PDT) Received: by 10.229.144.70 with HTTP; Mon, 23 Jul 2012 01:06:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Jul 2012 10:06:40 +0200 Message-ID: From: Wojciech Dec To: Qiong Content-Type: multipart/alternative; boundary=20cf30334ebbd0a2c304c57ab99f Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:06:43 -0000 --20cf30334ebbd0a2c304c57ab99f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qiong, On 21 July 2012 11:46, Qiong wrote: > Hi, Woj, > > This is not only about determining which parameter to explicitly exist in > MAP rule, but also the configuration in BR. If you include PSID explicitl= y, > then > 1) you need to configure per-subscriber rule in BR since the value of PSI= D > for different CPEs are different. This will take a lot of workload for > operators and it is obviously not the objective of any stateless solution= . > Stateless does not mean configuration less, and never did. Even without an explicit PSID one could have thousands of "rules" configured, if one chooses to deploy it that way. > 2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP > rule is redundant. > Therefore, I don't see the reason to include PSID explicitly in MAP > architecture. > So you don't disagree about the use, which is good. I'm however puzzled by why you see a need for a separate architecture document & specification to address the need for explicit port range, which the explicit PSID is, rather than working on a common solution... Regards, Woj. > > Best wishes > Qiong > > Wojciech Dec =E7=BC=96=E5=86=99=EF=BC=9A > > > Remi, > > On 20 July 2012 17:03, R=C3=A9mi Despr=C3=A9s = wrote: > >> Hi, Wojciech, >> >> 2012-07-20 12:56, Wojciech Dec: >> >> If the use of PSIDs in rules is useful, as it appears to be, >> >> >> This is the point that needs to be explained. >> > > The case is straightforward A+P. > For a single IPv4 address + port range it is desired to have it correspon= d > to an IPv6 address. > MAP and 4rd-u have that as a well established case with the IPv4 address > and / or PSID being mapped into the IPv6 prefix, but the IPv4 address not > given that it is configured on both sides (implicit). There is nothing in > the MAP architecture which restricts the PSID to not be such an implicit > parameter given that it can be configured at either side. > > -Woj. > > > >> Thanks. >> RD >> >> >> then there seems to be no reason not to allow that. >> >> Regards, >> Woj. >> >> >>> >>> - maoke >>> >>> >>>> >>>> Regards, >>>> Woj. >>>> >>>>> >>>>> >>>>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> > --20cf30334ebbd0a2c304c57ab99f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qiong,



On 21 July 2012 11:46, Qio= ng <bingxuere@gmail.com> wrote:
Hi, Woj,

This is not only about determining which parameter to expli= citly exist in MAP rule, but also the configuration in BR. If you include P= SID explicitly, then
1) you need to configure per-subscriber rule in BR = since the value of PSID for different CPEs are different. This will take a = lot of workload for operators and it is obviously not the objective of any = stateless solution.

Stateless does not mean configuration less, and never= did.
Even without an explicit PSID one could have thousands of "r= ules" configured, if one chooses to deploy it that way.
=C2=A0
2) IPv6 prefix has already carry the PSID im= plicitly, and the PSID in MAP rule is redundant.
Therefore, I don't = see the reason to include PSID explicitly in MAP architecture.

So you don't disagree about the use, which is goo= d. I'm however puzzled by why you see a need for a separate architectur= e document & specification to address the need for explicit port range,= which the explicit PSID is, rather than working on a common solution...
Regards,
Woj.
=C2=A0

Best= wishes
Qiong

Wojciech Dec <wdec.ietf@gmail.com>=E7=BC=96=E5=86=99=EF=BC= =9A


Remi,

On 20 Jul= y 2012 17:03, R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net&= gt; wrote:
Hi, Wojciech,

2012-07= -20 12:56, Wojciech Dec:

If the use of PSIDs in rules is=20 useful, as it appears to be,

=
This is the point that needs to be explained.

The case is straightforward A+P.
For a single= IPv4 address + port range it is desired to have it correspond to an IPv6 a= ddress.
MAP and 4rd-u have that as a well established case with the IPv4 address an= d / or PSID being mapped into the IPv6 prefix, but the IPv4 address not giv= en that it is configured on both sides (implicit). There is nothing in the = MAP architecture which restricts the PSID to not be such an implicit parame= ter given that it can be configured at either side.

-Woj.

=C2=A0
Thanks.
RD
=C2=A0
then there seems to be no reason not to=20 allow that.

Regards,
Woj.
=C2=A0

- maoke
=C2=A0

Regards,
Woj.



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



--20cf30334ebbd0a2c304c57ab99f-- From leaf.y.yeh@huawei.com Mon Jul 23 01:07:17 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6742A21F86C3 for ; Mon, 23 Jul 2012 01:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 J6rTqp-38xVb for ; Mon, 23 Jul 2012 01:07:16 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D14B821F8505 for ; Mon, 23 Jul 2012 01:07:16 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIG38055; Mon, 23 Jul 2012 04:07:16 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 01:03:49 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 01:03:49 -0700 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.103]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 23 Jul 2012 16:03:46 +0800 From: Leaf yeh To: Softwires WG Thread-Topic: Test+ Thread-Index: Ac1oqaztxHTVgMsFRh6usely5slgMQ== Date: Mon, 23 Jul 2012 08:03:45 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AXgx CQa4 CRnt C2i3 DM3t ECC3 Fhhe F3S7 GfWj GnOf G4hJ HLN+ IGvl KDZr KSQb K14c; 1; cwBvAGYAdAB3AGkAcgBlAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {817BCC3A-E386-49A8-8712-44AD18B9B78C}; bABlAGEAZgAuAHkALgB5AGUAaABAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Mon, 23 Jul 2012 08:03:42 GMT;VABlAHMAdAArAA== x-cr-puzzleid: {817BCC3A-E386-49A8-8712-44AD18B9B78C} x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] Test+ X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 23 Jul 2012 08:07:17 -0000 > Pls. ignore this mail. Sorry for the disturbance. Best Regards, Leaf From ichiroumakino@gmail.com Mon Jul 23 01:55:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8051B21F8507 for ; Mon, 23 Jul 2012 01:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T9ulus5R40B for ; Mon, 23 Jul 2012 01:55:23 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7B9E21F8505 for ; Mon, 23 Jul 2012 01:55:22 -0700 (PDT) Received: by weyu54 with SMTP id u54so4573578wey.31 for ; Mon, 23 Jul 2012 01:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=R4HF0Okh5yfYqkr5ADISc+VHeobKIQS5feYC7CIxSew=; b=sokutwLJlMCGZb6TYdCVq4K7QI5m/5AAXa426sPHA5BxPBi8Te3+aGgHAwOo5H+BWQ 2CzjNisdWHRKY/HZXtfU9OfhFJKqu+Xiazdadh6XGac8KUDo+znbdv06an51Q5Ee8Hee 1PheRYiZxT2MDj9psrIjiuUEP25VbprlABqECBAESoV/cKATPXzUNuYsWQcvG41/Rsms eQIaQtYhgR3Uaf+f1ijJuOeIpNa+aa/yPT8BZPfmu1IPqft6FQW/YWCjXOH4FHGekT6p Qfdm3VxntO+tdii2n0Zl5fQNCyBa4v4Nug0mEOWFOUrve49ISUGmAWeiL2eY3yfVfp6F SLDw== Received: by 10.180.20.99 with SMTP id m3mr18763199wie.16.1343033721600; Mon, 23 Jul 2012 01:55:21 -0700 (PDT) Received: from dhcp-10-61-110-55.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ex20sm23598911wid.7.2012.07.23.01.55.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Jul 2012 01:55:20 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <082.3a3d9d20a012091bfe99e0821f788183@tools.ietf.org> Date: Mon, 23 Jul 2012 10:55:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067.5f674627aa58992add79d729d7c3e84b@tools.ietf.org> <082.3a3d9d20a012091bfe99e0821f788183@tools.ietf.org> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1278) Cc: Softwires WG , "Wojciech Dec \(wdec\)" , draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 (was: Inapplicability of MAP-T+E to sites that have already assigned subnet ID = 0) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 23 Jul 2012 08:55:23 -0000 Remi, a site already using subnet 0 may require renumbering. would you be = satisfied if the draft said so? cheers, Ole On Jul 23, 2012, at 10:39 , softwire issue tracker wrote: > #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = =3D 0 >=20 > Changes (by remi.despres@=85): >=20 > * status: closed =3D> reopened > * resolution: invalid =3D> >=20 >=20 > Comment: >=20 > Acknowledged: "exclusive use" of subnet 0 is improper since only one = or > several interface IDs are exclusive to MAP (several if the site is > assigned an IPv4 prefix). Yet: > 1. If a site uses subnet 0, and one of its host uses a MAP-exclusive > interface ID (which, although unlikely, is possible), a conflict = appears > when MAP gets activated. > 2. By avoiding any restriction on subnet 0 (e.g. with the V octet of = 4rd), > one avoids to depend on "further operator input" before considering = that > all needs are covered. >=20 > --=20 > = ----------------------------------+---------------------------------------= - > Reporter: despres.remi@=85 | Owner: = draft-ietf-softwire-map@=85 > Type: defect | Status: reopened > Priority: critical | Milestone: > Component: map | Version: > Severity: Active WG Document | Resolution: > Keywords: map-t map-e subnet- | > ID | > = ----------------------------------+---------------------------------------= - >=20 > Ticket URL: = > softwire >=20 From tom.taylor.stds@gmail.com Mon Jul 23 07:13:59 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A94511E8096 for ; Mon, 23 Jul 2012 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 aFNmgp27TdAY for ; Mon, 23 Jul 2012 07:13:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDF011E8093 for ; Mon, 23 Jul 2012 07:13:58 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so11056960obb.31 for ; Mon, 23 Jul 2012 07:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=nTtg2wTk88Jqpo+ns4Dj+oQBI8RKJTSxe1qvgIxarJY=; b=1IASvsmnMLHGyuqyjqDvxqHnBVm8OUAiWyjcvxn4H/2NnjaGRcX21/09m/UI2Qwf9B d/15hTHyWScrkP+UCet8EbGBk4B7eHrL39eh6cgxlb/i3i/UBa7OkIWUxc9bzaKzTSm9 3duJ25cirHNxtVCnOgCFVYAcMOfZxzeCLrQetKcX17PzNZiv8Uo9i7Q7l6xcNmShNmA3 p2qof0QgmrirRnaGseHQFX79HgKVhs7Cz0g19v8e5pprOjuyg/ZDgoVE6Wf1pq09jM9s D4/PmUyhfCZi7a3fLs+sMrf3rqgwRjSRcR6Jpunte3uRgCdCy5CNOqPfuPG2bQmt3JN1 dcug== Received: by 10.60.29.169 with SMTP id l9mr21568253oeh.14.1343052837986; Mon, 23 Jul 2012 07:13:57 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-32-179.tor.primus.ca. [173.206.32.179]) by mx.google.com with ESMTPS id s7sm7574718oec.7.2012.07.23.07.13.55 (version=SSLv3 cipher=OTHER); Mon, 23 Jul 2012 07:13:56 -0700 (PDT) Message-ID: <500D5C1E.4060907@gmail.com> Date: Mon, 23 Jul 2012 10:13:50 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <50096068.5090007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120723-1, 23/07/2012), Outbound message X-Antivirus-Status: Clean Cc: Softwires , Yong Cui , Behcet Sarikaya Subject: Re: [Softwires] 6rd Multicast X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 14:13:59 -0000 So there is. I had forgotten. So: will the WG consider adopting draft-tsou-softwire-6rd-multicast as a WG deliverable? And if the WG so decides, the Sarikaya approach could also be added to the draft with a discussion of the realm of applicability of the respective drafts. Tom Taylor On 20/07/2012 11:10 AM, Behcet Sarikaya wrote: > On Fri, Jul 20, 2012 at 8:43 AM, Tom Taylor wrote: >> Chairs: if draft-ietf-softwire-dslite-multicast is not to be generalized, >> could a charter item be added for 6rd multicast? >> draft-tsou-softwire-6rd-multicast seems to be a reasobale candidate. > > > There is already a charter item for 6rd multicast extensions. > > Behcet > From ichiroumakino@gmail.com Tue Jul 24 03:46:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456D321F8679 for ; Tue, 24 Jul 2012 03:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.005 X-Spam-Level: X-Spam-Status: No, score=-0.005 tagged_above=-999 required=5 tests=[AWL=-3.294, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5gsAgA-pSRS for ; Tue, 24 Jul 2012 03:46:33 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 94B6321F866A for ; Tue, 24 Jul 2012 03:46:33 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so3319009wgb.1 for ; Tue, 24 Jul 2012 03:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6BQjALHbMcDUnq20SALymrbrTEYD54ds6oaCdtmTtlE=; b=lFFj1yvSvUT0mJ8dyDe4VB4PfcISAIOtvemDCAW82aAMaM2JTB3ZVDkajhRrVe/0RD KrGreJYxb+V/3N+9r0lvmCUgLgQqvxpShFyA19Yn+pyc7IE83TaEKm6O+ZjaIgBhnSkE Bc2Oxx2ZU1L9+NEPBBldbvHYQMj8lS/dTZnDrVVhbB4rSScdzA7GIkhq3FO4FGvQ407J Rj18/DRm1uL/E+V2I5TqL0OgcJ/1H6dMmeMbqGuYNbAuZ6yFriEdNXWpEtZCh4Tn8AkB fSPc2bKMRRLtsEOvmqL/pTvEs3Us44ng0Kbf25/Sjh/4VsypDd1FJ6cWeydrr7lG4mxq i16g== Received: by 10.180.90.207 with SMTP id by15mr5757088wib.22.1343126792576; Tue, 24 Jul 2012 03:46:32 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-88.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id y5sm3717257wiw.9.2012.07.24.03.46.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jul 2012 03:46:31 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <082.3d2c457eaa5a83b5a2bfc25348b3ad44@tools.ietf.org> Date: Tue, 24 Jul 2012 12:46:28 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6A31038A-102C-4AB2-AB37-060E62F43FC1@employees.org> References: <067.5f674627aa58992add79d729d7c3e84b@tools.ietf.org> <082.3d2c457eaa5a83b5a2bfc25348b3ad44@tools.ietf.org> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1278) Cc: Softwires WG , "Wojciech Dec \(wdec\)" , draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 24 Jul 2012 10:46:34 -0000 > 1. No, 4rd doesn't have the same problem as MAP concerning sites that use > subnet 0. > Wojciech, if you see a reason why a site should renumber its subnet 0 to > use 4rd, please explain. because no-one will ever do this? gomlefisk: otroan$ sudo ifconfig en1 inet6 2001:db8:0:0:0300::1/64 gomlefisk: otroan$ ifconfig en1 en1: flags=8863 mtu 1400 ether 00:26:bb:1a:77:2e inet6 fe80::226:bbff:fe1a:772e%en1 prefixlen 64 scopeid 0x6 inet 10.147.112.88 netmask 0xfffffc00 broadcast 10.147.115.255 inet6 2001:db8::300:0:0:1 prefixlen 64 media: autoselect status: active gomlefisk: otroan$ cheers, Ole From tomasz.mrugalski@gmail.com Tue Jul 24 05:37:18 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0655121F8627 for ; Tue, 24 Jul 2012 05:37:18 -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 lAlVh26D4mqf for ; Tue, 24 Jul 2012 05:37:17 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 677C721F8628 for ; Tue, 24 Jul 2012 05:37:17 -0700 (PDT) Received: by ggnc4 with SMTP id c4so7205815ggn.31 for ; Tue, 24 Jul 2012 05:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=pe8czU9q7LuLAsWfuOVUY9k21PKJTkcvJeYdfB5hxi8=; b=F2/A5JZNtRBGViycztA184Tgz807WbNjipKSl1RmRzves267PmNXrJA9AHujtcQd7i a7i2q06NhFWOr7ru6oWI4eDNUsbvC0P9519ZsKXIxwdz8QC1ZT4C9sPAzb/55kPErFfK 2/J+htPYXp70XJz+Qi0E7L75MXuXs2oMczPNWFSoaapJWCYUyp73nUbmavA4Y3QxD17J h/rqpu10KEyB51baT+aaP4+KGbGMloY+adqwnkrJ7Dcmf3tOGv9EkKcuAK+RzLztcBsp PJmzDrO3aNUdBLaesWErOA98qVmpCGNyjYRC8G7xvrj160C+HGQ9Nh4n9eRlnrW2QjYv u0bg== Received: by 10.236.72.97 with SMTP id s61mr15684187yhd.52.1343133437027; Tue, 24 Jul 2012 05:37:17 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:7c04:5d8f:25dc:20e8? ([2001:470:6061:1:7c04:5d8f:25dc:20e8]) by mx.google.com with ESMTPS id j39sm15177295ani.3.2012.07.24.05.37.14 (version=SSLv3 cipher=OTHER); Tue, 24 Jul 2012 05:37:15 -0700 (PDT) Message-ID: <500E96F6.9030605@gmail.com> Date: Tue, 24 Jul 2012 14:37:10 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: softwires@ietf.org References: <4FF66AB7.4090808@ericsson.com> In-Reply-To: <4FF66AB7.4090808@ericsson.com> X-TagToolbar-Keys: D20120724143710417 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Call for adoption of draft-mdt-softwire-map-dhcp-option-03 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: Tue, 24 Jul 2012 12:37:18 -0000 On 06.07.2012 06:33, Suresh Krishnan wrote: > Hi all, > This call is being initiated to determine whether there is WG > consensus towards adoption of draft-mdt-softwire-map-dhcp-option-03 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 2012-07-20. Dear chairs, dear group, The deadline for this adoption call has passed. There was around 10 votes of support and none against. Does this mean that the document will be adopted? If that is the case, would it be appropriate to upload it as soon as the submission tool reopens? Cheers, Tomek From despres.remi@laposte.net Tue Jul 24 06:10:59 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6B421F8623 for ; Tue, 24 Jul 2012 06:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJg+xUYiy30a for ; Tue, 24 Jul 2012 06:10:58 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC7221F8620 for ; Tue, 24 Jul 2012 06:10:58 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id 439B470000E4; Tue, 24 Jul 2012 15:10:56 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id 7D45870000E3; Tue, 24 Jul 2012 15:10:55 +0200 (CEST) X-SFR-UUID: 20120724131055513.7D45870000E3@msfrf2502.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jul 2012 15:10:54 +0200 Message-Id: <2771FA9B-6C7F-4BCE-AE79-8B2B158C3F68@laposte.net> To: Tomasz Mrugalski Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org WG" Subject: [Softwires] DHCPv6 section of the 4rd 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: Tue, 24 Jul 2012 13:10:59 -0000 Hi, Tomek, Since you are the known DHCP expert in Softwire concerning stateless = solutions, could you kindly review section 4.8 of the 4rd-03 draft, and = comment on the ML its use of DHCPv6? (Doing so, of course, will not prejudge what the WG will decide = concerning MAP-T+E vs 4rd.) In particular, the map-dhcp draft which will soon be a WG document has a = container which isn't present in 4rd.=20 Would it be recommend to add one (and if yes for which reason(s))? Thanks RD= From wdec.ietf@gmail.com Tue Jul 24 08:51:47 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0BC21F865D for ; Tue, 24 Jul 2012 08:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.243 X-Spam-Level: X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSg9M9mEbDvk for ; Tue, 24 Jul 2012 08:51:47 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F171721F861C for ; Tue, 24 Jul 2012 08:51:46 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so13255803pbc.31 for ; Tue, 24 Jul 2012 08:51:46 -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=zsLJO3p0BXKOTicy63cGWJdIOc3yd77Q4KlDveEFnc4=; b=fTKgPZMdhV7t9/07GPG3FJT3FgEWu0wdGCXRilBPu0+oJTeFJg70Q0iG04j5JjD3+l K6lYQNTsNBnNi4fm2Fhg8WHXnssArBsGo7uZoWhuzjSHTJ0MsbEc4xPIdFIQNNz27tyG fc0NO0r1axbciSvKlvjB+Cxhg4G5uUI+FpZraeyz1eMzL7L3wlKmzcMFHtXUaZUXY0e2 i7imUCUpXj/IZ/OHgnTNd2uma/zB8n+eG62ST4Qml7mWYqMJHLKIdoR9oQAF2X1xCbHM HJvfpJ2io1mP1nzHbZwEWJZNAvUCbZvHHfW7blPmSiq6lcMWCPEBfwikAPSWfjsXzlyT +Y/A== MIME-Version: 1.0 Received: by 10.68.218.101 with SMTP id pf5mr45574662pbc.60.1343145106784; Tue, 24 Jul 2012 08:51:46 -0700 (PDT) Received: by 10.143.165.8 with HTTP; Tue, 24 Jul 2012 08:51:46 -0700 (PDT) Date: Tue, 24 Jul 2012 17:51:46 +0200 Message-ID: From: Wojciech Dec To: Softwires-wg Content-Type: multipart/alternative; boundary=e89a8ff2439ff8c35504c59556b9 Cc: Softwire Chairs Subject: [Softwires] IETF84 - MAP Interop event X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 24 Jul 2012 15:51:47 -0000 --e89a8ff2439ff8c35504c59556b9 Content-Type: text/plain; charset=ISO-8859-1 Hello All, at the upcoming IETF84 meeting we'll be holding a first open MAP Interop event to which we would like to cordially invite any implementers & implementations of MAP, besides of course interested WG members. The goal of the event will be to verify basic MAP CE-BR communication use-cases, covering both -T and -E. We currently anticipate a number of different implementations to participate. The Interop will commence on Tuesday 31, 2012 starting at 1300. The exact room/location will be communicated shortly. An ethernet switch & Internet connectivity will be provided, but for the rest please bring your own MAP device(s) and any end-host devices that can help with the testing. Given that the set-up activities are likely to commence earlier, please let us know (by unicast) if you'd be available to participate or help in such preparations. Regards, Woj. --e89a8ff2439ff8c35504c59556b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All,

at the upcoming IETF84 meeting we'll be holding a fir= st open MAP Interop event to which we would like to cordially invite any im= plementers & implementations of MAP, besides of course interested WG me= mbers. The goal of the event will be to verify basic MAP CE-BR communicatio= n use-cases, covering both -T and -E. We currently anticipate a number of d= ifferent implementations to participate.

The Interop will commence on Tuesday 31, 2012 starting at 1300. The exa= ct room/location will be communicated shortly. An ethernet switch & Int= ernet connectivity will be provided, but for the rest please bring your own= MAP device(s) and any end-host devices that can help with the testing.

Given that the set-up activities are likely to commence earlier, please= let us know (by unicast) if you'd be available to participate or help = in such preparations.

Regards,
Woj.


--e89a8ff2439ff8c35504c59556b9-- From ichiroumakino@gmail.com Wed Jul 25 00:55:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB5021F8547 for ; Wed, 25 Jul 2012 00:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0yNvB30-Mp3 for ; Wed, 25 Jul 2012 00:55:56 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A66921F8543 for ; Wed, 25 Jul 2012 00:55:56 -0700 (PDT) Received: by yenq13 with SMTP id q13so458106yen.31 for ; Wed, 25 Jul 2012 00:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=I9V7Klz4/UUePzIaKaF8EGoeQSVCE7VgT1jJkveaXrM=; b=dp3C34o/X1T/8N83PENisk4gSn8UB4qO/t2RuegbADBblBB8rqKcdxcIJ2XRQF26bX 4E8WFxHUH1PYVnCw7iuhZnjzbM0oOFeWaGg1r8wFdmvKftmqUrFzXSbmrgKvCw+ia4HN 3MFjFkwYEW27mkVh9j7Z4XZshPWX/Ldg3+kaZFRY4eDT/mMzEvqCRzplqPSTCa9wyMgL T36dMH40mcMucqBegv3jM7vR/ns0ay46y0nRiCvYRIYjBNXQdCgqZPp+1lNgc4G8Xqi7 ax05vQjDdqMjQXEf4VYY6tQM+kDcb8vPuTuMJNI4kaQyiUOyR7+38TS86B0TsLXsTav/ w4cg== Received: by 10.101.6.32 with SMTP id j32mr2048380ani.82.1343202956227; Wed, 25 Jul 2012 00:55:56 -0700 (PDT) Received: from ?IPv6:2001:420:44ff:fd17:c488:51e3:4dbd:9244? ([2001:420:44ff:fd17:c488:51e3:4dbd:9244]) by mx.google.com with ESMTPS id o43sm29965455yhm.0.2012.07.25.00.55.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 00:55:55 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <6C2F25BF-C2F4-4CF5-9B03-5E52CBAEEC56@free.fr> Date: Wed, 25 Jul 2012 09:55:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <72801814-0735-45E7-9EC2-5228CF7F01B2@employees.org> References: <067.5f674627aa58992add79d729d7c3e84b@tools.ietf.org> <082.3d2c457eaa5a83b5a2bfc25348b3ad44@tools.ietf.org> <6A31038A-102C-4AB2-AB37-060E62F43FC1@employees.org> <6C2F25BF-C2F4-4CF5-9B03-5E52CBAEEC56@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1278) Cc: Softwires WG , "Wojciech Dec \(wdec\)" , draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 25 Jul 2012 07:55:57 -0000 Remi, >> because no-one will ever do this? >=20 > Assuming that details that follow mean that an expert can configure a = node with an address that isn't unauthorized by any RFC, and in = particular a 4rd-reserved address, that's acknowledged.=20 > But nothing specific needs to be done, in 4rd not more than in any = specification, to make hand-configured unauthorized addresses to work = properly.=20 >=20 > The difference between 4rd and MAP, in this respect, is as you know = that MAP addresses can conflict with *authorized* host addresses. This = is AFAIK the reason for your suggesting that sites that use subnet 0 be = renumbered to support MAP. just like any interface address can conflict with any other. MAP uses a single address out of the first subnet in a delegation. the = probability of collision even if it was shared with native hosts is = reasonably small. your view of the effect of reserving some bits in the middle of the = interface-id for the purpose of 4rd seems quite overstated to me. nor do = I follow your use of "authorized / unauthorized" interface-ids. the solution proposed in MAP may not be perfect. it is a tradeoff. 4rd = suggests another tradeoff that in my view, has much wider consequences. = take it to 6man. cheers, Ole From despres.remi@laposte.net Wed Jul 25 06:47:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4094B21F85B6 for ; Wed, 25 Jul 2012 06:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[AWL=-3.175, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9USC3BHCDDR for ; Wed, 25 Jul 2012 06:47:52 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3E76921F85D1 for ; Wed, 25 Jul 2012 06:47:51 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 4C4337000076; Wed, 25 Jul 2012 15:47:50 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id C3F3C7000074; Wed, 25 Jul 2012 15:47:45 +0200 (CEST) X-SFR-UUID: 20120725134745802.C3F3C7000074@msfrf2413.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6A31038A-102C-4AB2-AB37-060E62F43FC1@employees.org> Date: Wed, 25 Jul 2012 15:47:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <067.5f674627aa58992add79d729d7c3e84b@tools.ietf.org> <082.3d2c457eaa5a83b5a2bfc25348b3ad44@tools.ietf.org> <6A31038A-102C-4AB2-AB37-060E62F43FC1@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , "Wojciech Dec \(wdec\)" , draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 25 Jul 2012 13:47:53 -0000 Le 2012-07-24 =E0 12:46, Ole Tr=F8an a =E9crit : >> 1. No, 4rd doesn't have the same problem as MAP concerning sites that = use >> subnet 0. >> Wojciech, if you see a reason why a site should renumber its subnet 0 = to >> use 4rd, please explain. >=20 > because no-one will ever do this? Assuming that details that follow mean that an expert can configure a = node with an address that isn't unauthorized by any RFC, and in = particular a 4rd-reserved address, that's acknowledged.=20 But nothing specific needs to be done, in 4rd not more than in any = specification, to make hand-configured unauthorized addresses to work = properly.=20 The difference between 4rd and MAP, in this respect, is as you know that = MAP addresses can conflict with *authorized* host addresses. This is = AFAIK the reason for your suggesting that sites that use subnet 0 be = renumbered to support MAP. RD >=20 > gomlefisk: otroan$ sudo ifconfig en1 inet6 2001:db8:0:0:0300::1/64 > gomlefisk: otroan$ ifconfig en1 > en1: flags=3D8863 mtu = 1400 > ether 00:26:bb:1a:77:2e=20 > inet6 fe80::226:bbff:fe1a:772e%en1 prefixlen 64 scopeid 0x6=20 > inet 10.147.112.88 netmask 0xfffffc00 broadcast 10.147.115.255 > inet6 2001:db8::300:0:0:1 prefixlen 64=20 > media: autoselect > status: active > gomlefisk: otroan$=20 >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Jul 25 06:47:57 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A03421F85DB for ; Wed, 25 Jul 2012 06:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ltm+NKFZxuzc for ; Wed, 25 Jul 2012 06:47:56 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id B518A21F85DA for ; Wed, 25 Jul 2012 06:47:56 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 1A569700010C; Wed, 25 Jul 2012 15:47:56 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id C95CC700007B; Wed, 25 Jul 2012 15:47:55 +0200 (CEST) X-SFR-UUID: 20120725134755824.C95CC700007B@msfrf2413.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <72801814-0735-45E7-9EC2-5228CF7F01B2@employees.org> Date: Wed, 25 Jul 2012 15:47:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F5566E1-BBA2-45AB-996D-CD7CF1655656@laposte.net> References: <067.5f674627aa58992add79d729d7c3e84b@tools.ietf.org> <082.3d2c457eaa5a83b5a2bfc25348b3ad44@tools.ietf.org> <6A31038A-102C-4AB2-AB37-060E62F43FC1@employees.org> <6C2F25BF-C2F4-4CF5-9B03-5E52CBAEEC56@free.fr> <72801814-0735-45E7-9EC2-5228CF7F01B2@employees.org> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , "Wojciech Dec \(wdec\)" , draft-ietf-softwire-map@tools.ietf.org Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 25 Jul 2012 13:47:57 -0000 Le 2012-07-25 =E0 09:55, Ole Tr=F8an a =E9crit : > Remi, >=20 >>> because no-one will ever do this? >>=20 >> Assuming that details that follow mean that an expert can configure a = node with an address that isn't unauthorized by any RFC, and in = particular a 4rd-reserved address, that's acknowledged.=20 >> But nothing specific needs to be done, in 4rd not more than in any = specification, to make hand-configured unauthorized addresses to work = properly.=20 >>=20 >> The difference between 4rd and MAP, in this respect, is as you know = that MAP addresses can conflict with *authorized* host addresses. This = is AFAIK the reason for your suggesting that sites that use subnet 0 be = renumbered to support MAP. >=20 > just like any interface address can conflict with any other. > MAP uses a single address out of the first subnet in a delegation. the = probability of collision even if it was shared with native hosts is = reasonably small. >=20 > your view of the effect of reserving some bits in the middle of the = interface-id for the purpose of 4rd seems quite overstated to me. nor do = I follow your use of "authorized / unauthorized" interface-ids. >=20 > the solution proposed in MAP may not be perfect. it is a tradeoff. > 4rd suggests another tradeoff that in my view, has much wider = consequences. Such wider consequences haven't been identified so far, despite the fact = that the subject has been around for quite some time, and despite that = the varied origins of supporters of the design. > take it to 6man. 6man has to be involved, sure, but Softwire should first be clear about = the purpose, and possible drawbacks if any. If you see such drawbacks, please clarify. Thanks, RD >=20 > cheers, > Ole >=20 From wdec@cisco.com Wed Jul 25 06:56:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AE821F85DB for ; Wed, 25 Jul 2012 06:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.948 X-Spam-Level: X-Spam-Status: No, score=-105.948 tagged_above=-999 required=5 tests=[AWL=-4.651, BAYES_40=-0.185, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 eEsOOwDeg75K for ; Wed, 25 Jul 2012 06:56:12 -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 C29BA21F8599 for ; Wed, 25 Jul 2012 06:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=2069; q=dns/txt; s=iport; t=1343224572; x=1344434172; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QIBmPP+m9lUbUklyPUaFCEnffdjmRUSvCKzsUhxEUUc=; b=QWoLGueO2ugUlzwNqxT0cT3LR9TPO1TtyIiVInT51kfUBvtKNs8dYSqO 2w+feKWch2BwRSMUgpIMhupsEbTCTPr1aB/uOZYrph5xm7FroDPsikOiT jHvyjqByVyy1FuvImSQ5rVuqt5DjkEF8UoBnSsNArali/vk/Rie2k9kYS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMP5D1CtJXG+/2dsb2JhbABFuWOBB4IiAQQBAQEPAVgDCxIBCDsyCyUCBAENBSKHXAMMC5p8lmwTiUQEi02GdAOIGY0wjieBZoJf X-IronPort-AV: E=Sophos;i="4.77,653,1336348800"; d="scan'208";a="105201006" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jul 2012 13:56:12 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6PDuC8S010056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 13:56:12 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 08:56:11 -0500 From: "Wojciech Dec (wdec)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 Thread-Index: AQHNaYmUbngkpnOAREuzjFGjmdopCJc6WNwAgAAj5AA= Date: Wed, 25 Jul 2012 13:56:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.55.94.134] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.004 x-tm-as-result: No--43.240400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 25 Jul 2012 13:56:13 -0000 On 25/07/2012 15:47, "R=E9mi Despr=E9s" wrote: > >Le 2012-07-24 =E0 12:46, Ole Tr=F8an a =E9crit : > >>> 1. No, 4rd doesn't have the same problem as MAP concerning sites that >>>use >>> subnet 0. >>> Wojciech, if you see a reason why a site should renumber its subnet 0 >>>to >>> use 4rd, please explain. >>=20 >> because no-one will ever do this? > >Assuming that details that follow mean that an expert can configure a >node with an address that isn't unauthorized by any RFC, and in >particular a 4rd-reserved address, that's acknowledged. >But nothing specific needs to be done, in 4rd not more than in any >specification, to make hand-configured unauthorized addresses to work >properly.=20 > >The difference between 4rd and MAP, in this respect, is as you know that >MAP addresses can conflict with *authorized* host addresses. This is >AFAIK the reason for your suggesting that sites that use subnet 0 be >renumbered to support MAP. There is no such thing as an "authorized" host address. Duplicate address detection is around for a reason, and also applies here. By means of the V-octet, seeking to "appropriate" a part of all v6 address space for 4rd, or any other device class to deal with a remote case of a duplicate, which may still happen, seems overdone. In any case this looks to be a 6man consideration. -Woj. > >RD > > > > > > >>=20 >> gomlefisk: otroan$ sudo ifconfig en1 inet6 2001:db8:0:0:0300::1/64 >> gomlefisk: otroan$ ifconfig en1 >> en1: flags=3D8863 mtu 1400 >> ether 00:26:bb:1a:77:2e >> inet6 fe80::226:bbff:fe1a:772e%en1 prefixlen 64 scopeid 0x6 >> inet 10.147.112.88 netmask 0xfffffc00 broadcast 10.147.115.255 >> inet6 2001:db8::300:0:0:1 prefixlen 64 >> media: autoselect >> status: active >> gomlefisk: otroan$ >>=20 >> cheers, >> Ole >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From wdec@cisco.com Wed Jul 25 06:59:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A42E21F85DD for ; Wed, 25 Jul 2012 06:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.286 X-Spam-Level: X-Spam-Status: No, score=-109.286 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 FJ7mmvc7tqOq for ; Wed, 25 Jul 2012 06:59:38 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A97B621F85DB for ; Wed, 25 Jul 2012 06:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=517; q=dns/txt; s=iport; t=1343224777; x=1344434377; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RkIRPelZa7UhRdWyoy4Uh4aliwCxetesvYJUt8L0wM8=; b=W+hfccrQFz39JcDkA0kiDXDml06ioR7YqUw/idxggDKhjewNxu3onHA1 T3uL4K3WS2Xc9NvF4fIDBJ3PofijsuujQy9YZtuk/5niTPHpKV2EME/Ob f8y8Psh+kxqBPJJHf+W9RepFnT4TchX8OqI8LDFA4ozMBmgK08UFNmpcq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAF76D1CQ/khR/2dsb2JhbABFhS20NoEHgicSAWYSAQg7PSUCBAENBSKHXAMMmwyWbBOJSItNCoZqA4gZjTCOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,653,1336348800"; d="scan'208";a="6884860" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 25 Jul 2012 13:59:36 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6PDxZjV007280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 13:59:36 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.114]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 08:59:34 -0500 From: "Wojciech Dec (wdec)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 Thread-Index: AQHNaYmUbngkpnOAREuzjFGjmdopCJc58maAgAAEKACAAGJfgIAAJMWA Date: Wed, 25 Jul 2012 13:59:34 +0000 Message-ID: In-Reply-To: <3F5566E1-BBA2-45AB-996D-CD7CF1655656@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.55.94.134] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.004 x-tm-as-result: No--35.029900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 25 Jul 2012 13:59:38 -0000 On 25/07/2012 15:47, "R=E9mi Despr=E9s" wrote: > > > >> take it to 6man. > >6man has to be involved, sure, but Softwire should first be clear about >the purpose, and possible drawbacks if any. >If you see such drawbacks, please clarify. Here's one: I'd like my to be guaranteed *never ever* to conflict. Can I also get a V octet for <$my_device_class>? -Woj. > >Thanks, >RD > > > > >>=20 >> cheers, >> Ole >>=20 From despres.remi@laposte.net Wed Jul 25 07:11:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C310821F84E6 for ; Wed, 25 Jul 2012 07:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.634 X-Spam-Level: * X-Spam-Status: No, score=1.634 tagged_above=-999 required=5 tests=[AWL=-3.005, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYvgK0wZ5rP6 for ; Wed, 25 Jul 2012 07:11:23 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2770D21F84DE for ; Wed, 25 Jul 2012 07:11:19 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 594FD7000091; Wed, 25 Jul 2012 16:11:19 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 1E48A7000081; Wed, 25 Jul 2012 16:11:19 +0200 (CEST) X-SFR-UUID: 20120725141119124.1E48A7000081@msfrf2413.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 25 Jul 2012 16:11:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57C77499-BA15-4DEB-9B8A-9B540E68696F@laposte.net> References: To: "Wojciech Dec (wdec)" X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 25 Jul 2012 14:11:23 -0000 Le 2012-07-25 =E0 15:56, Wojciech Dec (wdec) a =E9crit : >=20 >=20 > On 25/07/2012 15:47, "R=E9mi Despr=E9s" = wrote: >=20 >>=20 >> Le 2012-07-24 =E0 12:46, Ole Tr=F8an a =E9crit : >>=20 >>>> 1. No, 4rd doesn't have the same problem as MAP concerning sites = that >>>> use >>>> subnet 0. >>>> Wojciech, if you see a reason why a site should renumber its subnet = 0 >>>> to >>>> use 4rd, please explain. >>>=20 >>> because no-one will ever do this? >>=20 >> Assuming that details that follow mean that an expert can configure a >> node with an address that isn't unauthorized by any RFC, and in >> particular a 4rd-reserved address, that's acknowledged. >> But nothing specific needs to be done, in 4rd not more than in any >> specification, to make hand-configured unauthorized addresses to work >> properly.=20 >>=20 >> The difference between 4rd and MAP, in this respect, is as you know = that >> MAP addresses can conflict with *authorized* host addresses. This is >> AFAIK the reason for your suggesting that sites that use subnet 0 be >> renumbered to support MAP. >=20 > There is no such thing as an "authorized" host address. Duplicate = address > detection is around for a reason, and also applies here. Well, this was to mean conforming to the "IP Version 6 Addressing = Architecture" (RFC 4291). Will try to be even more precise next time! > By means of the V-octet, seeking to "appropriate" a part of all v6 = address > space for 4rd, It seems that, if you did read 4rd-03, you misunderstood the top of page = 20. it explains that nothing more than routing on prefixes as usual is = needed to reach CE functions. If I misunderstood your point about "appropriate a part of all v6 = addresses", thanks for explaining. =20 > or any other device class to deal with a remote case of a > duplicate, which may still happen, seems overdone. > In any case this looks > to be a 6man consideration. Same answer as to Ole: "6man has to be involved, sure, but Softwire should first be clear about = the purpose, and possible drawbacks if any." RD =20 >=20 > -Woj. >=20 >>=20 >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>> gomlefisk: otroan$ sudo ifconfig en1 inet6 2001:db8:0:0:0300::1/64 >>> gomlefisk: otroan$ ifconfig en1 >>> en1: flags=3D8863 mtu = 1400 >>> ether 00:26:bb:1a:77:2e >>> inet6 fe80::226:bbff:fe1a:772e%en1 prefixlen 64 scopeid 0x6 >>> inet 10.147.112.88 netmask 0xfffffc00 broadcast 10.147.115.255 >>> inet6 2001:db8::300:0:0:1 prefixlen 64 >>> media: autoselect >>> status: active >>> gomlefisk: otroan$ >>>=20 >>> cheers, >>> Ole >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >=20 From despres.remi@laposte.net Wed Jul 25 07:13:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E540421F85CE for ; Wed, 25 Jul 2012 07:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0DcL3o3A4xM for ; Wed, 25 Jul 2012 07:13:38 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 595D021F85C7 for ; Wed, 25 Jul 2012 07:13:38 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id B2F9670000B2; Wed, 25 Jul 2012 16:13:37 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 80F8C7000091; Wed, 25 Jul 2012 16:13:37 +0200 (CEST) X-SFR-UUID: 20120725141337528.80F8C7000091@msfrf2413.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 25 Jul 2012 16:13:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01C1D9BA-FEB8-47DD-BC03-25E8A8D5CC50@laposte.net> References: To: "Wojciech Dec (wdec)" X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 25 Jul 2012 14:13:39 -0000 Le 2012-07-25 =E0 15:59, Wojciech Dec (wdec) a =E9crit : >=20 >=20 > On 25/07/2012 15:47, "R=E9mi Despr=E9s" = wrote: >=20 >>=20 >>=20 >>=20 >>> take it to 6man. >>=20 >> 6man has to be involved, sure, but Softwire should first be clear = about >> the purpose, and possible drawbacks if any. >> If you see such drawbacks, please clarify. >=20 > Here's one: > I'd like my to be = guaranteed > *never ever* to conflict. Can I also get a V octet for = <$my_device_class>? Sorry I couldn't decipher this. RD >=20 > -Woj. >>=20 >> Thanks, >> RD >>=20 >>=20 >>=20 >>=20 >>>=20 >>> cheers, >>> Ole >>>=20 >=20 From yiu_lee@cable.comcast.com Wed Jul 25 08:09:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5350A21F84EC for ; Wed, 25 Jul 2012 08:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.078 X-Spam-Level: X-Spam-Status: No, score=-102.078 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reIneu+Owa5Z for ; Wed, 25 Jul 2012 08:09:34 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD0921F84FB for ; Wed, 25 Jul 2012 08:09:34 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.26555498; Wed, 25 Jul 2012 08:50:45 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0309.002; Wed, 25 Jul 2012 11:09:30 -0400 From: "Lee, Yiu" To: Wojciech Dec , Qiong Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNand8gAs4p7b8TUefimYbm2NHTA== Date: Wed, 25 Jul 2012 15:09:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3426059368_582697" MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:09:35 -0000 --B_3426059368_582697 Content-type: multipart/alternative; boundary="B_3426059367_565316" --B_3426059367_565316 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Woj, I got a general question. The current MAP support 1:1 mode where EA-bit is = a full 32-bit address. Why we want to reinvent a wheel to create another 1:1 mode? The only difference is to move the configuration from DHCP server to rules in the BR. Did I miss something? Thanks, Yiu From: Wojciech Dec Date: Monday, July 23, 2012 4:06 AM To: Qiong Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 Qiong, On 21 July 2012 11:46, Qiong wrote: > Hi, Woj, >=20 > This is not only about determining which parameter to explicitly exist in= MAP > rule, but also the configuration in BR. If you include PSID explicitly, t= hen > 1) you need to configure per-subscriber rule in BR since the value of PSI= D for > different CPEs are different. This will take a lot of workload for operat= ors > and it is obviously not the objective of any stateless solution. Stateless does not mean configuration less, and never did. Even without an explicit PSID one could have thousands of "rules" configured, if one chooses to deploy it that way. =20 > 2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP= rule > is redundant. > Therefore, I don't see the reason to include PSID explicitly in MAP > architecture. So you don't disagree about the use, which is good. I'm however puzzled by why you see a need for a separate architecture document & specification to address the need for explicit port range, which the explicit PSID is, rathe= r than working on a common solution... Regards, Woj. =20 >=20 > Best wishes > Qiong >=20 > Wojciech Dec =B1=E0=D0=B4=A3=BA >=20 >=20 > Remi, >=20 > On 20 July 2012 17:03, R=A8=A6mi Despr=A8=A6s wrote: >> Hi, Wojciech,=20 >>=20 >> 2012-07-20 12:56, Wojciech Dec: >>=20 >>> If the use of PSIDs in rules is useful, as it appears to be, >>=20 >> This is the point that needs to be explained. >=20 > The case is straightforward A+P. > For a single IPv4 address + port range it is desired to have it correspon= d to > an IPv6 address. > MAP and 4rd-u have that as a well established case with the IPv4 address = and / > or PSID being mapped into the IPv6 prefix, but the IPv4 address not given= that > it is configured on both sides (implicit). There is nothing in the MAP > architecture which restricts the PSID to not be such an implicit paramete= r > given that it can be configured at either side. >=20 > -Woj. >=20 > =20 >> Thanks. >> RD >> =20 >>> then there seems to be no reason not to allow that. >>>=20 >>> Regards, >>> Woj. >>> =20 >>>>=20 >>>> - maoke >>>> =20 >>>>>=20 >>>>> Regards, >>>>> Woj.=20 >>>>>>=20 >>>>>>=20 >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 --B_3426059367_565316 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Woj,

I got a general question. The current MAP support 1:1 mode where EA-bit is= a full 32-bit address. Why we want to reinvent a wheel to create another 1:= 1 mode? The only difference is to move the configuration from DHCP server to= rules in the BR. Did I miss something?

Thanks,
Yiu

From: Woj= ciech Dec <wdec.ietf@gmail.com&g= t;
Date: Monday, July 23, 2012 4:0= 6 AM
To: Qiong <bingxuere@gmail.com>
Cc: Softwires-wg <sof= twires@ietf.org>
Subject: R= e: [Softwires] map-00: review on the mode 1:1

<= meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
Qiong,



On 21 July 2012 11:46, Qiong= <bi= ngxuere@gmail.com> wrote:
Hi, Woj,

This is not only about determining which parameter to explicitly exist in M= AP rule, but also the configuration in BR. If you include PSID explicitly, t= hen
1) you need to configure per-subscriber rule in BR since the value of PSID = for different CPEs are different. This will take a lot of workload for opera= tors and it is obviously not the objective of any stateless solution.

Stateless does not mean configuration less, and never did.
Even without an explicit PSID one could have thousands of "rules" configure= d, if one chooses to deploy it that way.
 
2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP r= ule is redundant.
Therefore, I don't see the reason to include PSID explicitly in MAP archite= cture.

So you don't disagree about the use, which is good. I'm however puzzled by = why you see a need for a separate architecture document & specification = to address the need for explicit port range, which the explicit PSID is, rat= her than working on a common solution...

Regards,
Woj.
 

Best wishes
Qiong

Wojciech Dec <wdec.= ietf@gmail.com>=B1=E0=D0=B4=A3=BA


Remi,

On 20 July 2012 17:03, R=A8=A6mi Despr=A8=A6s= <despres.remi@laposte.net> wrote:
Hi, Wojciech,

2012-07-20 12:56, Wojciech Dec:

If the use of PSIDs in rules is usefu= l, as it appears to be,

<= div>This is the point that needs to be explained.

The case is straightforward A+P.
For a single IPv4 address + port range it is desired to have it correspond = to an IPv6 address.
MAP and 4rd-u have that as a well established case with the IPv4 address an= d / or PSID being mapped into the IPv6 prefix, but the IPv4 address not give= n that it is configured on both sides (implicit). There is nothing in the MA= P architecture which restricts the PSID to not be such an implicit parameter given that it can be configu= red at either side.

-Woj.

 
Thanks.
RD
 = ;
<= div>then there seems to be no reason not to allow that.

Regards,
Woj.
 
- maoke
 

Regards,
Woj.



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


=

--B_3426059367_565316-- --B_3426059368_582697 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTNmPT6 E3T9beFkxHniQfafauCJDzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA3MjUxNTA5MjdaMA0GCSqGSIb3DQEBAQUABIIBAKRixaC+3djSIVD9f/XaOjkr AESa9NgIeP9tV65SjBEoMjbPj8kD2FX0GIXCqLxdffJ0abun7+e+Q8wSOawQGVzdpBypnHVh eb83qbz3Pv/jAdkeWMcLvzpCNqD8h9Le9/xWnAhPxIrcIk5d1w+w84McE/ZHY19u59W79Zo6 cz874SrrzbmLU71K6zxZGCoy4IpKeSpQs+sv2kLzYFJZNMVIAMpeEVCD3VvDiKpUV6gDqQ/J Pu3T7/n0wAEmDmmWFjNuyRxF42AdZT1ZQsVsskInk/jpxH05M/ay5jMR1ohWgRY0dTF3E8vr 5AQ43oz1PFHZSD3WcuF5uc49VKZJr+k= --B_3426059368_582697-- From sarikaya2012@gmail.com Wed Jul 25 09:05:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D321F8685 for ; Wed, 25 Jul 2012 09:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 KcSR167hCpBn for ; Wed, 25 Jul 2012 09:05:24 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3853221F8683 for ; Wed, 25 Jul 2012 09:05:24 -0700 (PDT) Received: by ggnc4 with SMTP id c4so975803ggn.31 for ; Wed, 25 Jul 2012 09:05:23 -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=j61kvtAE+OEqwUndXy0T4QW3uuh/4Bod4ArR0QgBLHc=; b=Wp6N4jDY7vo61DhV1pTFAOCn44D0xX84E4R1QjDtKZ5Ny39er3CXGBVXnzVUHKMWEz y899hAGpVZxBHB0zfJKuTZtcqQaj3TUwrv/iUS/roWVuQeQf1ikD1LKEKUMS9q3ZfS+x 8kJhIswyxxktXsRzoJA3rwKM+6dTGSJDC9nW2Ju4av+GymOwOoGIC53GzTOaAWj1QhAY +FAlBtDVG5aaNHsoFaWE2fxMoBw+sAMdNcD1LPugaz+McjruRSzesHhCncuiPADtKntM BqSpVp4w64gmA/26HTJY2QygiIuN/SjkL2XceY/rWJymu4JnnE4P35GStsCyis/tnwmb pDcQ== MIME-Version: 1.0 Received: by 10.42.255.68 with SMTP id nh4mr25521765icb.38.1343232323267; Wed, 25 Jul 2012 09:05:23 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Wed, 25 Jul 2012 09:05:23 -0700 (PDT) Date: Wed, 25 Jul 2012 11:05:23 -0500 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: text/plain; charset=ISO-8859-1 Subject: [Softwires] draft-sarikaya-softwire-4rdmulticast-03.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, 25 Jul 2012 16:05:36 -0000 Hi Chairs, It seems that draft-sarikaya-softwire-4rdmulticast-03.txt is the only solution draft on 4rd multicast extensions. I would like to propose the adoption of this draft as WG draft as an addition to 4rd set of WG drafts. Regards, Behcet From ichiroumakino@gmail.com Wed Jul 25 10:04:33 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7B121F86DF for ; Wed, 25 Jul 2012 10:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGMOuysS2w7v for ; Wed, 25 Jul 2012 10:04:33 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D17E721F86E1 for ; Wed, 25 Jul 2012 10:04:32 -0700 (PDT) Received: by lagv3 with SMTP id v3so749949lag.31 for ; Wed, 25 Jul 2012 10:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TuAdPEJ48AErm9i/dxapbanzLFQqExGCuTb/pMQ9i5o=; b=GLF6N2noMxXOHnHbQkKB104q4ru7WRlRyoHQZiF+YfGUTP2s1lFiAjUm0Q8gUleJaU NyBS7Sc/iPOAayr7zACedeNyvivNmWKB7nmp/jnjkiGgaGwTtLUIg0WMKIB4Lf6cSUGX EJNfr0/KnRoY/qxXKfWKw7D+1T+Ez+UTM/KbzgAIj91XRriSzYyaE/aFSCupo8kSyOE1 dIiZmhFtLejVOsu4pkgHwvMt0+U72qAEdPBj36eDTEqaIIcW5OF60CfB5a/lhwzrH3gO PsZhrp5PgVWrxC4ltgWAEWqEjhEkw2F9YUZqGMjebvOJeQJA5v8B2M9Jgd1m7bIdhs46 xWoQ== Received: by 10.152.131.68 with SMTP id ok4mr26456039lab.47.1343235871752; Wed, 25 Jul 2012 10:04:31 -0700 (PDT) Received: from gomlefisk.lan ([84.48.213.97]) by mx.google.com with ESMTPS id gd9sm4679348lbb.15.2012.07.25.10.04.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 10:04:30 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=GB2312 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 25 Jul 2012 19:04:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AAC3A3A-FDED-4E37-8919-3F366BB35555@employees.org> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1278) Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:04:34 -0000 Yiu, > I got a general question. The current MAP support 1:1 mode where = EA-bit is a full 32-bit address. Why we want to reinvent a wheel to = create another 1:1 mode? The only difference is to move the = configuration from DHCP server to rules in the BR. Did I miss something? just the opposite. MAP supports 1:1 mode with no EA bits. all the bits = are encoded in the MAP DHCP option. this is just a logical implications of the fields already in that = option. cheers, Ole From yiu_lee@cable.comcast.com Wed Jul 25 11:12:48 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79021F873A for ; Wed, 25 Jul 2012 11:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.815 X-Spam-Level: X-Spam-Status: No, score=-103.815 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNF9+xzh2XvW for ; Wed, 25 Jul 2012 11:12:47 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0A621F8737 for ; Wed, 25 Jul 2012 11:12:47 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.26597315; Wed, 25 Jul 2012 11:53:57 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0309.002; Wed, 25 Jul 2012 14:12:42 -0400 From: "Lee, Yiu" To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNapEU2Goqw3V+fUilS+tya4mJIA== Date: Wed, 25 Jul 2012 18:12:41 +0000 Message-ID: In-Reply-To: <8AAC3A3A-FDED-4E37-8919-3F366BB35555@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3426070360_1251107" MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 18:12:48 -0000 --B_3426070360_1251107 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ole, I am not asking whether MAP supports 1:1 mode with no EA bits or not. I am asking MAP allows to embed the 32-bit address in the EA bits to achieve 1:1 mode: "The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID)." Why not use this instead? Thanks, Yiu Why we want to=20 On 7/25/12 1:04 PM, "Ole Tr=F8an" wrote: >Yiu, > >> I got a general question. The current MAP support 1:1 mode where EA-bit >>is a full 32-bit address. Why we want to reinvent a wheel to create >>another 1:1 mode? The only difference is to move the configuration from >>DHCP server to rules in the BR. Did I miss something? > >just the opposite. MAP supports 1:1 mode with no EA bits. all the bits >are encoded in the MAP DHCP option. >this is just a logical implications of the fields already in that option. > >cheers, >Ole > --B_3426070360_1251107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRD3Wyd f11MnjkZVYYLQxWoQfVFKzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA3MjUxODEyNDBaMA0GCSqGSIb3DQEBAQUABIIBAMQvnx6R0EDES6Nz6HS2n8It 8YgqTNz8G6lDEV9MBGpKppMVELqZU9x0h5uFU31TKizE41SiJ+NSzNeGzVcukiwycH26+EqE T0zAMBU9pSWfSA/EcxN3FZeLHNVHBYYtfYlJ05E5t8FShugWShgEvpcOeDZc3maqLiEQ4rMH H5cvipPdEdXGACmgKMmBzY9/dAq6vVWzNjh+j/yZONObJ2VAhUmfoHtWhO7QLu9pS3ESStpJ Sqjilt7g0w27WUVglrsc4wJIcZZsmyliU1At12VOTnoLGoGza7AXPEyU8cE5W6oTj72zfuwp oX/azvwc00n6a5skvdD7C2VJ+NTRJGE= --B_3426070360_1251107-- From ichiroumakino@gmail.com Wed Jul 25 11:41:00 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2209821F872A for ; Wed, 25 Jul 2012 11:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neJT6P8knajG for ; Wed, 25 Jul 2012 11:40:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51A9421F8627 for ; Wed, 25 Jul 2012 11:40:59 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so925032lbb.31 for ; Wed, 25 Jul 2012 11:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=f7cY5efFok/6RvrmAQIZ6msdA80lHJ/a5yhUyZLCKsg=; b=KPxVfS5lB5Bew9HgP5O0xA1rR0H8FS63Duqf0fW+ePoreYbho2BvpgSj92oK9s5H+w YLrk1V+NQy7wWv18vTfKY09yF9YHWvTdPjjiRtXbWheVwXDHikiMp9WsmMdHmloQL6NU TLtye7WFvJGlk5WWKjVjcLy8xaA1AJbqOB1xXfme2hd6E5ZCHy6t2+dQfWNCtM68KWgE szDyT8nGWxSux34PtoDliTpczKjtnXeqHpFdwvjicbyXCEN85tGffaJdOCTAyNyhJkN9 AqC/int9BRbJrjFzlXnumBwVMqwkj0OlADXiCajHoESFzNsOwRhwVbrfbIyhY9XU3apP 7L6w== Received: by 10.152.132.233 with SMTP id ox9mr26789558lab.25.1343241658043; Wed, 25 Jul 2012 11:40:58 -0700 (PDT) Received: from gomlefisk.lan ([84.48.213.97]) by mx.google.com with ESMTPS id j5sm4727751lbg.1.2012.07.25.11.40.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 11:40:57 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 25 Jul 2012 20:40:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1278) Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 18:41:00 -0000 Yiu, > I am not asking whether MAP supports 1:1 mode with no EA bits or not. = I am > asking MAP allows to embed the 32-bit address in the EA bits to = achieve > 1:1 mode: >=20 > "The EA bits can contain a full or part > of an IPv4 prefix or address, and in the shared IPv4 address case > contains a Port-Set Identifier (PSID)." >=20 > Why not use this instead? you can do either. embedding a complete IPv4 address and PSID does require a lot of IPv6 = space though. e.g. /56 - 32 - 6 =3D /18 1:1 mode is typically referred to a model where IPv4 and IPv6 addressing = are independent. cheers, Ole From yiu_lee@cable.comcast.com Wed Jul 25 12:08:11 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1E521F8755 for ; Wed, 25 Jul 2012 12:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.871 X-Spam-Level: X-Spam-Status: No, score=-103.871 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSxRCanhpbJ1 for ; Wed, 25 Jul 2012 12:08:11 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id E9BA121F8746 for ; Wed, 25 Jul 2012 12:08:10 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.26609429; Wed, 25 Jul 2012 12:49:19 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0309.002; Wed, 25 Jul 2012 15:08:04 -0400 From: "Lee, Yiu" To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNapjRkchJBUMXmES9ErDYdBAUMw== Date: Wed, 25 Jul 2012 19:08:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3426073683_1419113" MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 19:08:11 -0000 --B_3426073683_1419113 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. Before MAP was accepted as WG item, MAP was proposed to embed IPv4 address information (EA bits > 0) in the CE IPv6 address to achieve stateless. Now there is a new proposal to add a new feature to have the IPv4 information in the BR only. This change requires to provision individual subscriber information to the BR (instead of aggregated information). Benefit are saving bits and breaking v4 and v6 address dependency. Questions to WG: Is it useful feature to be included in MAP? If not, why and alternative? Thanks, Yiu On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >Yiu, > >> I am not asking whether MAP supports 1:1 mode with no EA bits or not. I >>am >> asking MAP allows to embed the 32-bit address in the EA bits to achieve >> 1:1 mode: >>=20 >> "The EA bits can contain a full or part >> of an IPv4 prefix or address, and in the shared IPv4 address case >> contains a Port-Set Identifier (PSID)." >>=20 >> Why not use this instead? > >you can do either. >embedding a complete IPv4 address and PSID does require a lot of IPv6 >space though. >e.g. /56 - 32 - 6 =3D /18 > >1:1 mode is typically referred to a model where IPv4 and IPv6 addressing >are independent. > >cheers, >Ole > --B_3426073683_1419113 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRbkCQ/ y7z52F1B100TJXZAcgf/YzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA3MjUxOTA4MDJaMA0GCSqGSIb3DQEBAQUABIIBAKjQBEV75oVms6F2HxD5Wurn GDUMJkSmrsoT1nnKYFdKRKpKwoCu+6MLPEyaTXpHn7+Xr9fa6MUtZuBGO53djXGfI1mZv1y/ Le5n+j08kfd853gp0gH5ZKoeSSPEPz7otk6N2UWD7hePQnMQoT3m+0BzyqfJKjADHN2GEHOC qKqfRy9QyIOcqd3KDkRd2OFwh5xQEBTaCshGc37yKww3XACAZKyJFE/1ZXBC9WM7QXD3N+VW 23ZkB9wQ8AdMG6BKH/fbl9S52LUkrdAQK5wqr+K4MmFZauo5gD/IR7o/TTB3voNw0LZxSSZE /h1xRCbC9+pB4XsWijB3bYMNC6o/jI0= --B_3426073683_1419113-- From satoru.matsushima@gmail.com Wed Jul 25 18:45:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D721F869F for ; Wed, 25 Jul 2012 18:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 hVHynF+jaH2K for ; Wed, 25 Jul 2012 18:45:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 814DF21F8692 for ; Wed, 25 Jul 2012 18:45:34 -0700 (PDT) Received: by yenq13 with SMTP id q13so1563898yen.31 for ; Wed, 25 Jul 2012 18:45:34 -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=CuYB2OU+03laZlckoaXNw5RLoy7FXl6hXPFsFQxVnrw=; b=GCnDRSYccctvstL69IIBxieH0MDX6fSQ+8wx3MqAJi77z39WeqURICPW1JS8Ut1uoD LUL9QAizSBm17S4tvcMrhOSlCEVxs49emibosB57CAqqGXVSVjFKDu3wibX9c/XZ1FxY fpHxD5qNnaLGu1ECsJFMjW55ed96d2IZtk8gFl4ueOWZ09Zeqbma08BhgszUyOFPe3bm yNVnFCi3OAX/zBSnT3UuaYwyrLiAbVUvpea2AWqKWQCuWaeHHwPGMewKdceU4MRcCepq dTT+DrW8gvMauUwfou9Yh02vhN0LKIFgsZ/RKHW+ehHj+1U0apqC+is6sp2OeuF2XXt6 B7MQ== Received: by 10.66.77.169 with SMTP id t9mr4189488paw.70.1343267133702; Wed, 25 Jul 2012 18:45:33 -0700 (PDT) Received: from [10.201.80.50] ([202.45.12.141]) by mx.google.com with ESMTPS id mr1sm15440806pbb.62.2012.07.25.18.45.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jul 2012 18:45:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Thu, 26 Jul 2012 10:45:29 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9E195AE9-F0E3-485E-B06E-4C6D2ECCC417@gmail.com> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1278) Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 01:45:35 -0000 Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: > Ole, >=20 > Where can I get the formal definition of 1:1 mode? My understanding of = 1:1 > refers to one public IPv4 address per subscriber but you refer very > specific to decoupling IPv4 and IPv6 addresses. >=20 It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 = address in ea-bits is as a result of prefix allocation operation. > Before MAP was accepted as WG item, MAP was proposed to embed IPv4 = address > information (EA bits > 0) in the CE IPv6 address to achieve stateless. No, there was no such definition for EA-bits length restriction. =20 > Now there is a new proposal to add a new feature to have the IPv4 = information > in the BR only. This change requires to provision individual = subscriber > information to the BR (instead of aggregated information). Benefit are > saving bits and breaking v4 and v6 address dependency. There's no change from previous spec, to just clarify MAP, as a = stateless solution, could naturally support most granular mapping rule = in its nature. >=20 > Questions to WG: > Is it useful feature to be included in MAP? If not, why and = alternative? >=20 I believe that it does not make sense to restrict EA-len > 0 for both = MAP and 4rd. It does make sense that you see MAP as framework of = solutions which covers specific 1:1 solution by the mapping algorithm. cheers, --satoru > Thanks, > Yiu >=20 > On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >=20 >> Yiu, >>=20 >>> I am not asking whether MAP supports 1:1 mode with no EA bits or = not. I >>> am >>> asking MAP allows to embed the 32-bit address in the EA bits to = achieve >>> 1:1 mode: >>>=20 >>> "The EA bits can contain a full or part >>> of an IPv4 prefix or address, and in the shared IPv4 address case >>> contains a Port-Set Identifier (PSID)." >>>=20 >>> Why not use this instead? >>=20 >> you can do either. >> embedding a complete IPv4 address and PSID does require a lot of IPv6 >> space though. >> e.g. /56 - 32 - 6 =3D /18 >>=20 >> 1:1 mode is typically referred to a model where IPv4 and IPv6 = addressing >> are independent. >>=20 >> cheers, >> Ole >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From yiu_lee@cable.comcast.com Wed Jul 25 18:51:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09EE11E809A for ; Wed, 25 Jul 2012 18:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.904 X-Spam-Level: X-Spam-Status: No, score=-101.904 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsPPaMlYlHVJ for ; Wed, 25 Jul 2012 18:51:54 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id B3E8711E8079 for ; Wed, 25 Jul 2012 18:51:53 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.20718920; Wed, 25 Jul 2012 21:48:11 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0309.002; Wed, 25 Jul 2012 21:51:48 -0400 From: "Lee, Yiu" To: Satoru Matsushima Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNatE39COJKw9KZUy7+Vq3yGB2Uw== Date: Thu, 26 Jul 2012 01:51:47 +0000 Message-ID: In-Reply-To: <9E195AE9-F0E3-485E-B06E-4C6D2ECCC417@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [24.40.55.71] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3426097907_865080" MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 01:51:55 -0000 --B_3426097907_865080 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Satoru, Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit>0 or =3D0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. Thanks, Yiu On 7/25/12 9:45 PM, "Satoru Matsushima" wrote: >Hi Yiu, > >On 2012/07/26, at 4:08, Lee, Yiu wrote: > >> Ole, >>=20 >> Where can I get the formal definition of 1:1 mode? My understanding of >>1:1 >> refers to one public IPv4 address per subscriber but you refer very >> specific to decoupling IPv4 and IPv6 addresses. >>=20 > >It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >address in ea-bits is as a result of prefix allocation operation. > >> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >>address >> information (EA bits > 0) in the CE IPv6 address to achieve stateless. > >No, there was no such definition for EA-bits length restriction. > >> Now there is a new proposal to add a new feature to have the IPv4 >>information >> in the BR only. This change requires to provision individual subscriber >> information to the BR (instead of aggregated information). Benefit are >> saving bits and breaking v4 and v6 address dependency. > >There's no change from previous spec, to just clarify MAP, as a stateless >solution, could naturally support most granular mapping rule in its >nature. > >>=20 >> Questions to WG: >> Is it useful feature to be included in MAP? If not, why and alternative? >>=20 > >I believe that it does not make sense to restrict EA-len > 0 for both MAP >and 4rd. It does make sense that you see MAP as framework of solutions >which covers specific 1:1 solution by the mapping algorithm. > >cheers, >--satoru > > >> Thanks, >> Yiu >>=20 >> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >>=20 >>> Yiu, >>>=20 >>>> I am not asking whether MAP supports 1:1 mode with no EA bits or not. >>>>I >>>> am >>>> asking MAP allows to embed the 32-bit address in the EA bits to >>>>achieve >>>> 1:1 mode: >>>>=20 >>>> "The EA bits can contain a full or part >>>> of an IPv4 prefix or address, and in the shared IPv4 address case >>>> contains a Port-Set Identifier (PSID)." >>>>=20 >>>> Why not use this instead? >>>=20 >>> you can do either. >>> embedding a complete IPv4 address and PSID does require a lot of IPv6 >>> space though. >>> e.g. /56 - 32 - 6 =3D /18 >>>=20 >>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>addressing >>> are independent. >>>=20 >>> cheers, >>> Ole >>>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > --B_3426097907_865080 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTu2dpg cR+uhKYHmjSrG0NMtcrrUTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA3MjYwMTUxNDZaMA0GCSqGSIb3DQEBAQUABIIBAKTkhrBq4CKCAo71oBKG5VXI NEcLfcRu5pQlI8jRoXnTAU1KuaS4MzdsbjhfzRnqUGltQezBNp8dCW1InyLXrfHQRQK1Zj3D O5KFfK41TLcwtxk2hNXBZME421AcDPIwbwD6r0+q7szDX4iNKlVBxqU8m2NADapVxEkXfs75 EL63M418I3HYdqXOQHXiz51B/uDBsI6JdNiPbFtUXQuxJn4rnCv3Rb6+zR8LbO2hGF5HtTqx Sk4npk5zIDC06vR7MWr/Mp5sSicU2tpWNuKKZOxUNoV7C3MUd69UxOmhxYG3nNnppDN7pAoE AJS5WCPo8YDSkGiVzrIpWdgE0WXoW/E= --B_3426097907_865080-- From ichiroumakino@gmail.com Thu Jul 26 03:22:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DA021F8715 for ; Thu, 26 Jul 2012 03:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.828 X-Spam-Level: X-Spam-Status: No, score=-2.828 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zxDvKL9TrWR for ; Thu, 26 Jul 2012 03:22:52 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18A3C21F8720 for ; Thu, 26 Jul 2012 03:22:51 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1104606wgb.13 for ; Thu, 26 Jul 2012 03:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=q6UpzyMpJXZTHI8eUHPXL2j30Et8/FEAaN0E4/dTqKY=; b=j6xz4/m/qEguOPsOew4sCjuBOpdqfbtL38wwjgAkG1csqC62H0Nb5urywJvz265ni9 2+vuuHihq0UZ8JO7MvBlPcqQaVvck7JoFNT7vpVImTf9dV/wZ/mpM+F29tdZp0I+y7V6 55K/nEue2z26q0NM7pVncaJ18em9y3TDV9zntQ/ffbfwP23wPkiqn6MEjUYTAOgL4mG7 AvEiaM+A+OKCqvDVdGqxedo/ndjf9rfV9h+LYx3F9/h7O10D3+HGLO0Iv+bqooBdHTWD 4B0CXgXol+kkCyGjilVepSuJxb3M50ah2q0WKfK3fDGKHgsOmTlERx0oAASSmuEgeAPg CjRw== Received: by 10.217.4.193 with SMTP id u43mr5636998wes.129.1343298171122; Thu, 26 Jul 2012 03:22:51 -0700 (PDT) Received: from dhcp-10-61-97-123.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id cl8sm7513576wib.10.2012.07.26.03.22.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jul 2012 03:22:50 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Thu, 26 Jul 2012 12:22:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1278) Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 10:22:53 -0000 Yiu, > Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 = address > dependency. It doesn't bring any new function compared to embedding = full > v4 address in the EA-bit. However, the operation models of EA-bit>0 or = =3D0 > are very different. By the way, this works only for MAP-E. I fail to = see > why we want to include this in the base spec. what do you say in the spec if EA=3D0 and provisioned IPv4 prefix length = =3D 32. the spec has to say something about this to be complete. cheers, Ole >=20 > Thanks, > Yiu >=20 >=20 > On 7/25/12 9:45 PM, "Satoru Matsushima" > wrote: >=20 >> Hi Yiu, >>=20 >> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>=20 >>> Ole, >>>=20 >>> Where can I get the formal definition of 1:1 mode? My understanding = of >>> 1:1 >>> refers to one public IPv4 address per subscriber but you refer very >>> specific to decoupling IPv4 and IPv6 addresses. >>>=20 >>=20 >> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >> address in ea-bits is as a result of prefix allocation operation. >>=20 >>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >>> address >>> information (EA bits > 0) in the CE IPv6 address to achieve = stateless. >>=20 >> No, there was no such definition for EA-bits length restriction. >>=20 >>> Now there is a new proposal to add a new feature to have the IPv4 >>> information >>> in the BR only. This change requires to provision individual = subscriber >>> information to the BR (instead of aggregated information). Benefit = are >>> saving bits and breaking v4 and v6 address dependency. >>=20 >> There's no change from previous spec, to just clarify MAP, as a = stateless >> solution, could naturally support most granular mapping rule in its >> nature. >>=20 >>>=20 >>> Questions to WG: >>> Is it useful feature to be included in MAP? If not, why and = alternative? >>>=20 >>=20 >> I believe that it does not make sense to restrict EA-len > 0 for both = MAP >> and 4rd. It does make sense that you see MAP as framework of = solutions >> which covers specific 1:1 solution by the mapping algorithm. >>=20 >> cheers, >> --satoru >>=20 >>=20 >>> Thanks, >>> Yiu >>>=20 >>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >>>=20 >>>> Yiu, >>>>=20 >>>>> I am not asking whether MAP supports 1:1 mode with no EA bits or = not. >>>>> I >>>>> am >>>>> asking MAP allows to embed the 32-bit address in the EA bits to >>>>> achieve >>>>> 1:1 mode: >>>>>=20 >>>>> "The EA bits can contain a full or part >>>>> of an IPv4 prefix or address, and in the shared IPv4 address case >>>>> contains a Port-Set Identifier (PSID)." >>>>>=20 >>>>> Why not use this instead? >>>>=20 >>>> you can do either. >>>> embedding a complete IPv4 address and PSID does require a lot of = IPv6 >>>> space though. >>>> e.g. /56 - 32 - 6 =3D /18 >>>>=20 >>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>> addressing >>>> are independent. >>>>=20 >>>> cheers, >>>> Ole >>>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 From pengwu.thu@gmail.com Thu Jul 26 04:17:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A8021F8589 for ; Thu, 26 Jul 2012 04:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLhyb+sxSKnu for ; Thu, 26 Jul 2012 04:17:23 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5939321F8565 for ; Thu, 26 Jul 2012 04:17:23 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2002649ghb.31 for ; Thu, 26 Jul 2012 04:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1qhM7MSABi+kF3V2imclHLU6jJ8bFKnKURwhQ/o2uwk=; b=Yb/8lfvbYNtUqqJ8mHp7xs/L+I0BmOJAZKy7ARGsy8ppRMcEuZxoBdE439S3gj9nK8 56ny1voohNdf9KWf+ow93lmzJ07Ub2FcRJ0n8tznWkBLF+7WWO0XtswtQMYe1PGk4KKl ZySzdt26eDAt/5lqno+lF/sIEmsdjXyWcYFzVmz5AXuFQnICcFnzpYLd/hDd5m231uS9 Vy4aiT3WgvigSM5+xe9gpnDmz4jDKYkwTvBGQJquYQPCQq2xrtWRq+MmGnLTaJ8mSR8O 5i3NA/hdSSzMS1SpWNrmWkG0vt2rGP/sMc3SYuG8e3mh7Jj09sDeFvH4RlU9oGpo69dC TsYA== MIME-Version: 1.0 Received: by 10.68.197.202 with SMTP id iw10mr3960464pbc.161.1343301442424; Thu, 26 Jul 2012 04:17:22 -0700 (PDT) Received: by 10.143.16.11 with HTTP; Thu, 26 Jul 2012 04:17:22 -0700 (PDT) In-Reply-To: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> References: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> Date: Thu, 26 Jul 2012 19:17:22 +0800 Message-ID: From: Peng Wu To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 11:17:25 -0000 Ole, As I suggested earlier, you could simply say that the WHOLE ARCHITECTURE is based on IPv4-IPv6 address embedding and because setting EA bits=3D0 changes this very basic assumption, it's not allowed/supported in MAP. IMHO it's the best way to keep MAP clean and clear. And I don't think it'll cause problems: you want statelessness, you couple v4-v6 addressing and use MAP; you want v4-v6 addressing independency rather than statelessness, then that's another story. On Thu, Jul 26, 2012 at 6:22 PM, Ole Tr=F8an wrote: > Yiu, > >> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 addres= s >> dependency. It doesn't bring any new function compared to embedding full >> v4 address in the EA-bit. However, the operation models of EA-bit>0 or = =3D0 >> are very different. By the way, this works only for MAP-E. I fail to see >> why we want to include this in the base spec. > > what do you say in the spec if EA=3D0 and provisioned IPv4 prefix length = =3D 32. > the spec has to say something about this to be complete. > > cheers, > Ole > > >> >> Thanks, >> Yiu >> >> >> On 7/25/12 9:45 PM, "Satoru Matsushima" >> wrote: >> >>> Hi Yiu, >>> >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>> >>>> Ole, >>>> >>>> Where can I get the formal definition of 1:1 mode? My understanding of >>>> 1:1 >>>> refers to one public IPv4 address per subscriber but you refer very >>>> specific to decoupling IPv4 and IPv6 addresses. >>>> >>> >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >>> address in ea-bits is as a result of prefix allocation operation. >>> >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >>>> address >>>> information (EA bits > 0) in the CE IPv6 address to achieve stateless. >>> >>> No, there was no such definition for EA-bits length restriction. >>> >>>> Now there is a new proposal to add a new feature to have the IPv4 >>>> information >>>> in the BR only. This change requires to provision individual subscribe= r >>>> information to the BR (instead of aggregated information). Benefit are >>>> saving bits and breaking v4 and v6 address dependency. >>> >>> There's no change from previous spec, to just clarify MAP, as a statele= ss >>> solution, could naturally support most granular mapping rule in its >>> nature. >>> >>>> >>>> Questions to WG: >>>> Is it useful feature to be included in MAP? If not, why and alternativ= e? >>>> >>> >>> I believe that it does not make sense to restrict EA-len > 0 for both M= AP >>> and 4rd. It does make sense that you see MAP as framework of solutions >>> which covers specific 1:1 solution by the mapping algorithm. >>> >>> cheers, >>> --satoru >>> >>> >>>> Thanks, >>>> Yiu >>>> >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >>>> >>>>> Yiu, >>>>> >>>>>> I am not asking whether MAP supports 1:1 mode with no EA bits or not= . >>>>>> I >>>>>> am >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >>>>>> achieve >>>>>> 1:1 mode: >>>>>> >>>>>> "The EA bits can contain a full or part >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address case >>>>>> contains a Port-Set Identifier (PSID)." >>>>>> >>>>>> Why not use this instead? >>>>> >>>>> you can do either. >>>>> embedding a complete IPv4 address and PSID does require a lot of IPv6 >>>>> space though. >>>>> e.g. /56 - 32 - 6 =3D /18 >>>>> >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>>> addressing >>>>> are independent. >>>>> >>>>> cheers, >>>>> Ole >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From mohamed.boucadair@orange.com Thu Jul 26 05:06:09 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB68C21F873B for ; Thu, 26 Jul 2012 05:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY2ELIApIHWl for ; Thu, 26 Jul 2012 05:06: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 21E4521F872A for ; Thu, 26 Jul 2012 05:06:08 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 57A3C18C489; Thu, 26 Jul 2012 14:06:07 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 3C09735C045; Thu, 26 Jul 2012 14:06:07 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Thu, 26 Jul 2012 14:06:01 +0200 From: To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Lee, Yiu" Date: Thu, 26 Jul 2012 14:06:00 +0200 Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: Ac1rGJ1qaoEgFNEiRnykUHbXyUXitAADFf7w Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E397@PUEXCB1B.nanterre.francetelecom.fr> References: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> In-Reply-To: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.26.112414 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 12:06:09 -0000 Dear Ole, all, For sure MAP spec can be updated to cover 1:1 mode but this brings more con= fusion for some people as this contradicts the "no state in ISP network" pa= radigm. I personally vote for limiting MAP to its initial scope rather than= trying to cover other deployment options. I see three main flavours which justifies having standalone specification d= ocuments: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP/4rd (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translate= d-ds-lite) These three flavours have been already sketched in Figure 7 of RFC6346 (see= http://tools.ietf.org/html/rfc6346#section-3.3.4). Having standalone specifications for each of these flavours helps operators= to better target their suitable deployment model without being disturbed w= ith parameters and details not pertinent for their deployment context. Cheers, Med=20 >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Ole Tr=F8an >Envoy=E9 : jeudi 26 juillet 2012 12:23 >=C0 : Lee, Yiu >Cc : Softwires-wg >Objet : Re: [Softwires] map-00: review on the mode 1:1 > >Yiu, > >> Set EA bits=3D0 only saves bits in v6 address and decouples=20 >v4/v6 address >> dependency. It doesn't bring any new function compared to=20 >embedding full >> v4 address in the EA-bit. However, the operation models of=20 >EA-bit>0 or =3D0 >> are very different. By the way, this works only for MAP-E. I=20 >fail to see >> why we want to include this in the base spec. > >what do you say in the spec if EA=3D0 and provisioned IPv4=20 >prefix length =3D 32. >the spec has to say something about this to be complete. > >cheers, >Ole > > >>=20 >> Thanks, >> Yiu >>=20 >>=20 >> On 7/25/12 9:45 PM, "Satoru Matsushima" >> wrote: >>=20 >>> Hi Yiu, >>>=20 >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>>=20 >>>> Ole, >>>>=20 >>>> Where can I get the formal definition of 1:1 mode? My=20 >understanding of >>>> 1:1 >>>> refers to one public IPv4 address per subscriber but you refer very >>>> specific to decoupling IPv4 and IPv6 addresses. >>>>=20 >>>=20 >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >>> address in ea-bits is as a result of prefix allocation operation. >>>=20 >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >>>> address >>>> information (EA bits > 0) in the CE IPv6 address to=20 >achieve stateless. >>>=20 >>> No, there was no such definition for EA-bits length restriction. >>>=20 >>>> Now there is a new proposal to add a new feature to have the IPv4 >>>> information >>>> in the BR only. This change requires to provision=20 >individual subscriber >>>> information to the BR (instead of aggregated information).=20 >Benefit are >>>> saving bits and breaking v4 and v6 address dependency. >>>=20 >>> There's no change from previous spec, to just clarify MAP,=20 >as a stateless >>> solution, could naturally support most granular mapping rule in its >>> nature. >>>=20 >>>>=20 >>>> Questions to WG: >>>> Is it useful feature to be included in MAP? If not, why=20 >and alternative? >>>>=20 >>>=20 >>> I believe that it does not make sense to restrict EA-len >=20 >0 for both MAP >>> and 4rd. It does make sense that you see MAP as framework=20 >of solutions >>> which covers specific 1:1 solution by the mapping algorithm. >>>=20 >>> cheers, >>> --satoru >>>=20 >>>=20 >>>> Thanks, >>>> Yiu >>>>=20 >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >>>>=20 >>>>> Yiu, >>>>>=20 >>>>>> I am not asking whether MAP supports 1:1 mode with no EA=20 >bits or not. >>>>>> I >>>>>> am >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >>>>>> achieve >>>>>> 1:1 mode: >>>>>>=20 >>>>>> "The EA bits can contain a full or part >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address case >>>>>> contains a Port-Set Identifier (PSID)." >>>>>>=20 >>>>>> Why not use this instead? >>>>>=20 >>>>> you can do either. >>>>> embedding a complete IPv4 address and PSID does require a=20 >lot of IPv6 >>>>> space though. >>>>> e.g. /56 - 32 - 6 =3D /18 >>>>>=20 >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>>> addressing >>>>> are independent. >>>>>=20 >>>>> cheers, >>>>> Ole >>>>>=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 despres.remi@laposte.net Thu Jul 26 05:10:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0774521F85C7 for ; Thu, 26 Jul 2012 05:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfvfgdcUlyTo for ; Thu, 26 Jul 2012 05:10:12 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E0E4121F8530 for ; Thu, 26 Jul 2012 05:10:10 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 235CD9400B2; Thu, 26 Jul 2012 14:10:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E397@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 26 Jul 2012 14:09:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> <94C682931C08B048B7A8645303FDC9F36E4A17E397@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 12:10:13 -0000 2012-07-26 14:06, = : > Dear Ole, all, >=20 > For sure MAP spec can be updated to cover 1:1 mode but this brings = more confusion for some people as this contradicts the "no state in ISP = network" paradigm. I personally vote for limiting MAP to its initial = scope rather than trying to cover other deployment options. >=20 > I see three main flavours which justifies having standalone = specification documents: >=20 > (1) Full stateful mode: DS-Lite > (2) Full stateless mode: MAP/4rd > (3) Per-customer state/binding mode: lw4o6 = (draft-cui-softwire-b4-translated-ds-lite) Same view. RD >=20 > These three flavours have been already sketched in Figure 7 of RFC6346 = (see http://tools.ietf.org/html/rfc6346#section-3.3.4). >=20 > Having standalone specifications for each of these flavours helps = operators to better target their suitable deployment model without being = disturbed with parameters and details not pertinent for their deployment = context. >=20 > Cheers, > Med=20 >=20 >> -----Message d'origine----- >> De : softwires-bounces@ietf.org=20 >> [mailto:softwires-bounces@ietf.org] De la part de Ole Tr=F8an >> Envoy=E9 : jeudi 26 juillet 2012 12:23 >> =C0 : Lee, Yiu >> Cc : Softwires-wg >> Objet : Re: [Softwires] map-00: review on the mode 1:1 >>=20 >> Yiu, >>=20 >>> Set EA bits=3D0 only saves bits in v6 address and decouples=20 >> v4/v6 address >>> dependency. It doesn't bring any new function compared to=20 >> embedding full >>> v4 address in the EA-bit. However, the operation models of=20 >> EA-bit>0 or =3D0 >>> are very different. By the way, this works only for MAP-E. I=20 >> fail to see >>> why we want to include this in the base spec. >>=20 >> what do you say in the spec if EA=3D0 and provisioned IPv4=20 >> prefix length =3D 32. >> the spec has to say something about this to be complete. >>=20 >> cheers, >> Ole >>=20 >>=20 >>>=20 >>> Thanks, >>> Yiu >>>=20 >>>=20 >>> On 7/25/12 9:45 PM, "Satoru Matsushima" = >>> wrote: >>>=20 >>>> Hi Yiu, >>>>=20 >>>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>>>=20 >>>>> Ole, >>>>>=20 >>>>> Where can I get the formal definition of 1:1 mode? My=20 >> understanding of >>>>> 1:1 >>>>> refers to one public IPv4 address per subscriber but you refer = very >>>>> specific to decoupling IPv4 and IPv6 addresses. >>>>>=20 >>>>=20 >>>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >>>> address in ea-bits is as a result of prefix allocation operation. >>>>=20 >>>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >>>>> address >>>>> information (EA bits > 0) in the CE IPv6 address to=20 >> achieve stateless. >>>>=20 >>>> No, there was no such definition for EA-bits length restriction. >>>>=20 >>>>> Now there is a new proposal to add a new feature to have the IPv4 >>>>> information >>>>> in the BR only. This change requires to provision=20 >> individual subscriber >>>>> information to the BR (instead of aggregated information).=20 >> Benefit are >>>>> saving bits and breaking v4 and v6 address dependency. >>>>=20 >>>> There's no change from previous spec, to just clarify MAP,=20 >> as a stateless >>>> solution, could naturally support most granular mapping rule in its >>>> nature. >>>>=20 >>>>>=20 >>>>> Questions to WG: >>>>> Is it useful feature to be included in MAP? If not, why=20 >> and alternative? >>>>>=20 >>>>=20 >>>> I believe that it does not make sense to restrict EA-len >=20 >> 0 for both MAP >>>> and 4rd. It does make sense that you see MAP as framework=20 >> of solutions >>>> which covers specific 1:1 solution by the mapping algorithm. >>>>=20 >>>> cheers, >>>> --satoru >>>>=20 >>>>=20 >>>>> Thanks, >>>>> Yiu >>>>>=20 >>>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >>>>>=20 >>>>>> Yiu, >>>>>>=20 >>>>>>> I am not asking whether MAP supports 1:1 mode with no EA=20 >> bits or not. >>>>>>> I >>>>>>> am >>>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >>>>>>> achieve >>>>>>> 1:1 mode: >>>>>>>=20 >>>>>>> "The EA bits can contain a full or part >>>>>>> of an IPv4 prefix or address, and in the shared IPv4 address = case >>>>>>> contains a Port-Set Identifier (PSID)." >>>>>>>=20 >>>>>>> Why not use this instead? >>>>>>=20 >>>>>> you can do either. >>>>>> embedding a complete IPv4 address and PSID does require a=20 >> lot of IPv6 >>>>>> space though. >>>>>> e.g. /56 - 32 - 6 =3D /18 >>>>>>=20 >>>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>>>> addressing >>>>>> are independent. >>>>>>=20 >>>>>> cheers, >>>>>> Ole >>>>>>=20 >>>>> _______________________________________________ >>>>> Softwires mailing list >>>>> Softwires@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From fibrib@gmail.com Thu Jul 26 07:34:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7628421F877F for ; Thu, 26 Jul 2012 07:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBui6kfLNH4t for ; Thu, 26 Jul 2012 07:34:12 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD5221F8777 for ; Thu, 26 Jul 2012 07:34:12 -0700 (PDT) Received: by qcac10 with SMTP id c10so1291629qca.31 for ; Thu, 26 Jul 2012 07:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KC1tOFHGqJqyq3Tn6zWPFktfSrYzx981Pp7+oBZWN38=; b=lDmZIrNIIvWJQIMjiIy7NcCbtc97wc6KBOD51F7w1rWX9YjYNs15jvf7x2Vin6M5oz sq0uQQuctnm4+IMj1qy3D4EccFh25opfTLcgo35d4v1XoVZNjm3sOeLSWCDczl2wyxjy Sqx5x+TPCnNJ7TNAUsB0HBY7ULP+K7nbPnSo2zC6Y1M6AD+u6RCrjte/5KEQZJg6jwhV M4FfRAQ8rSwujgVNUdoKAi3V/rRfzXoKnp+1S03TsDyfwYQGzX/O0D3dE57jc0u7CoKC 5aPCKQArYPG7UbporPyozWsACTz/ejVDnVQ2ZPqHCmFN9L3ipuWh9uVXEUvdEtA5gsbH 7hXw== MIME-Version: 1.0 Received: by 10.224.179.13 with SMTP id bo13mr3291056qab.42.1343313251578; Thu, 26 Jul 2012 07:34:11 -0700 (PDT) Received: by 10.229.26.66 with HTTP; Thu, 26 Jul 2012 07:34:11 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E397@PUEXCB1B.nanterre.francetelecom.fr> References: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> <94C682931C08B048B7A8645303FDC9F36E4A17E397@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 26 Jul 2012 23:34:11 +0900 Message-ID: From: Maoke To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=20cf302ef93c2eb33904c5bc7de7 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 14:34:13 -0000 --20cf302ef93c2eb33904c5bc7de7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/7/26 > Dear Ole, all, > > For sure MAP spec can be updated to cover 1:1 mode but this brings more > confusion for some people as this contradicts the "no state in ISP networ= k" > paradigm. I personally vote for limiting MAP to its initial scope rather > than trying to cover other deployment options. > > I see three main flavours which justifies having standalone specification > documents: > > (1) Full stateful mode: DS-Lite > (2) Full stateless mode: MAP/4rd > (3) Per-customer state/binding mode: lw4o6 > (draft-cui-softwire-b4-translated-ds-lite) > > These three flavours have been already sketched in Figure 7 of RFC6346 > (see http://tools.ietf.org/html/rfc6346#section-3.3.4). > > yes. i share this point. thanks, Med, for the clear explanation on the big picture. - maoke > Having standalone specifications for each of these flavours helps > operators to better target their suitable deployment model without being > disturbed with parameters and details not pertinent for their deployment > context. > > Cheers, > Med > > >-----Message d'origine----- > >De : softwires-bounces@ietf.org > >[mailto:softwires-bounces@ietf.org] De la part de Ole Tr=F8an > >Envoy=E9 : jeudi 26 juillet 2012 12:23 > >=C0 : Lee, Yiu > >Cc : Softwires-wg > >Objet : Re: [Softwires] map-00: review on the mode 1:1 > > > >Yiu, > > > >> Set EA bits=3D0 only saves bits in v6 address and decouples > >v4/v6 address > >> dependency. It doesn't bring any new function compared to > >embedding full > >> v4 address in the EA-bit. However, the operation models of > >EA-bit>0 or =3D0 > >> are very different. By the way, this works only for MAP-E. I > >fail to see > >> why we want to include this in the base spec. > > > >what do you say in the spec if EA=3D0 and provisioned IPv4 > >prefix length =3D 32. > >the spec has to say something about this to be complete. > > > >cheers, > >Ole > > > > > >> > >> Thanks, > >> Yiu > >> > >> > >> On 7/25/12 9:45 PM, "Satoru Matsushima" > >> wrote: > >> > >>> Hi Yiu, > >>> > >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: > >>> > >>>> Ole, > >>>> > >>>> Where can I get the formal definition of 1:1 mode? My > >understanding of > >>>> 1:1 > >>>> refers to one public IPv4 address per subscriber but you refer very > >>>> specific to decoupling IPv4 and IPv6 addresses. > >>>> > >>> > >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 > >>> address in ea-bits is as a result of prefix allocation operation. > >>> > >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 > >>>> address > >>>> information (EA bits > 0) in the CE IPv6 address to > >achieve stateless. > >>> > >>> No, there was no such definition for EA-bits length restriction. > >>> > >>>> Now there is a new proposal to add a new feature to have the IPv4 > >>>> information > >>>> in the BR only. This change requires to provision > >individual subscriber > >>>> information to the BR (instead of aggregated information). > >Benefit are > >>>> saving bits and breaking v4 and v6 address dependency. > >>> > >>> There's no change from previous spec, to just clarify MAP, > >as a stateless > >>> solution, could naturally support most granular mapping rule in its > >>> nature. > >>> > >>>> > >>>> Questions to WG: > >>>> Is it useful feature to be included in MAP? If not, why > >and alternative? > >>>> > >>> > >>> I believe that it does not make sense to restrict EA-len > > >0 for both MAP > >>> and 4rd. It does make sense that you see MAP as framework > >of solutions > >>> which covers specific 1:1 solution by the mapping algorithm. > >>> > >>> cheers, > >>> --satoru > >>> > >>> > >>>> Thanks, > >>>> Yiu > >>>> > >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: > >>>> > >>>>> Yiu, > >>>>> > >>>>>> I am not asking whether MAP supports 1:1 mode with no EA > >bits or not. > >>>>>> I > >>>>>> am > >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to > >>>>>> achieve > >>>>>> 1:1 mode: > >>>>>> > >>>>>> "The EA bits can contain a full or part > >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address case > >>>>>> contains a Port-Set Identifier (PSID)." > >>>>>> > >>>>>> Why not use this instead? > >>>>> > >>>>> you can do either. > >>>>> embedding a complete IPv4 address and PSID does require a > >lot of IPv6 > >>>>> space though. > >>>>> e.g. /56 - 32 - 6 =3D /18 > >>>>> > >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 > >>>>> addressing > >>>>> are independent. > >>>>> > >>>>> cheers, > >>>>> Ole > >>>>> > >>>> _______________________________________________ > >>>> Softwires mailing list > >>>> Softwires@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/softwires > >>> > > > >_______________________________________________ > >Softwires mailing list > >Softwires@ietf.org > >https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf302ef93c2eb33904c5bc7de7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/7/26 <mohamed.boucadai= r@orange.com>
Dear Ole, all,

For sure MAP spec can be updated to cover 1:1 mode but this brings more con= fusion for some people as this contradicts the "no state in ISP networ= k" paradigm. I personally vote for limiting MAP to its initial scope r= ather than trying to cover other deployment options.

I see three main flavours which justifies having standalone specification d= ocuments:

(1) Full stateful mode: DS-Lite
(2) Full stateless mode: MAP/4rd
(3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translate= d-ds-lite)

These three flavours have been already sketched in Figure 7 of RFC6346 (see= http://tools.ietf.org/html/rfc6346#section-3.3.4).

=A0
yes. i share this point. thanks, Med, f= or the clear explanation on the big picture. - maoke
=A0
Having standalone specifications for each of these flavours helps operators= to better target their suitable deployment model without being disturbed w= ith parameters and details not pertinent for their deployment context.

Cheers,
Med

>-----Message d'origine-----
>De : softwires-bounces@ie= tf.org
>[mailto:softwires-bounces= @ietf.org] De la part de Ole Tr=F8an
>Envoy=E9 : jeudi 26 juillet 2012 12:23
>=C0 : Lee, Yiu
>Cc : Softwires-wg
>Objet : Re: [Softwires] map-00: review on the mode 1:1
>
>Yiu,
>
>> Set EA bits=3D0 only saves bits in v6 address and decouples
>v4/v6 address
>> dependency. It doesn't bring any new function compared to
>embedding full
>> v4 address in the EA-bit. However, the operation models of
>EA-bit>0 or =3D0
>> are very different. By the way, this works only for MAP-E. I
>fail to see
>> why we want to include this in the base spec.
>
>what do you say in the spec if EA=3D0 and provisioned IPv4
>prefix length =3D 32.
>the spec has to say something about this to be complete.
>
>cheers,
>Ole
>
>
>>
>> Thanks,
>> Yiu
>>
>>
>> On 7/25/12 9:45 PM, "Satoru Matsushima" <satoru.matsushima@gmail.com>
>> wrote:
>>
>>> Hi Yiu,
>>>
>>> On 2012/07/26, at 4:08, Lee, Yiu wrote:
>>>
>>>> Ole,
>>>>
>>>> Where can I get the formal definition of 1:1 mode? My
>understanding of
>>>> 1:1
>>>> refers to one public IPv4 address per subscriber but you r= efer very
>>>> specific to decoupling IPv4 and IPv6 addresses.
>>>>
>>>
>>> It doesn't 1:1 in MAP and 4rd context, because embedding f= ull ipv4
>>> address in ea-bits is as a result of prefix allocation operati= on.
>>>
>>>> Before MAP was accepted as WG item, MAP was proposed to em= bed IPv4
>>>> address
>>>> information (EA bits > 0) in the CE IPv6 address to
>achieve stateless.
>>>
>>> No, there was no such definition for EA-bits length restrictio= n.
>>>
>>>> Now there is a new proposal to add a new feature to have t= he IPv4
>>>> information
>>>> in the BR only. This change requires to provision
>individual subscriber
>>>> information to the BR (instead of aggregated information).=
>Benefit are
>>>> saving bits and breaking v4 and v6 address dependency.
>>>
>>> There's no change from previous spec, to just clarify MAP,=
>as a stateless
>>> solution, could naturally support most granular mapping rule i= n its
>>> nature.
>>>
>>>>
>>>> Questions to WG:
>>>> Is it useful feature to be included in MAP? If not, why >and alternative?
>>>>
>>>
>>> I believe that it does not make sense to restrict EA-len ><= br> >0 for both MAP
>>> and 4rd. It does make sense that you see MAP as framework
>of solutions
>>> which covers specific 1:1 solution by the mapping algorithm. >>>
>>> cheers,
>>> --satoru
>>>
>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>>>>
>>>>> Yiu,
>>>>>
>>>>>> I am not asking whether MAP supports 1:1 mode with= no EA
>bits or not.
>>>>>> I
>>>>>> am
>>>>>> asking MAP allows to embed the 32-bit address in t= he EA bits to
>>>>>> achieve
>>>>>> 1:1 mode:
>>>>>>
>>>>>> "The EA bits can contain a full or part
>>>>>> of an IPv4 prefix or address, and in the shared IP= v4 address case
>>>>>> contains a Port-Set Identifier (PSID)."
>>>>>>
>>>>>> Why not use this instead?
>>>>>
>>>>> you can do either.
>>>>> embedding a complete IPv4 address and PSID does requir= e a
>lot of IPv6
>>>>> space though.
>>>>> e.g. /56 - 32 - 6 =3D /18
>>>>>
>>>>> 1:1 mode is typically referred to a model where IPv4 a= nd IPv6
>>>>> addressing
>>>>> are independent.
>>>>>
>>>>> cheers,
>>>>> Ole
>>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf302ef93c2eb33904c5bc7de7-- From yiu_lee@cable.comcast.com Thu Jul 26 07:59:08 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D570F21F8768 for ; Thu, 26 Jul 2012 07:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.178 X-Spam-Level: X-Spam-Status: No, score=-103.178 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx-yy2NwUWEZ for ; Thu, 26 Jul 2012 07:59:08 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id F31EF21F864C for ; Thu, 26 Jul 2012 07:59:07 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.26717836; Thu, 26 Jul 2012 08:40:11 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0309.002; Thu, 26 Jul 2012 10:59:01 -0400 From: "Lee, Yiu" To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNaz8wzxsmgWx6FE+4lrF4/QPzfw== Date: Thu, 26 Jul 2012 14:59:00 +0000 Message-ID: In-Reply-To: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3426145140_3717523" MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 14:59:08 -0000 --B_3426145140_3717523 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ole, IMHO the WG will need to decide whether EA=3D0 should be covered at all. If not, then the draft could explicitly mention EA must be > 0 and must contain v4 information in the CE address. If the WG decided this needed to be cover, I would recommend to have a new draft to cover it and leave EA=3D0 undefined in the base draft. Thanks, Yiu=20 On 7/26/12 6:22 AM, "Ole Tr=F8an" wrote: >Yiu, > >> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 address >> dependency. It doesn't bring any new function compared to embedding full >> v4 address in the EA-bit. However, the operation models of EA-bit>0 or >>=3D0 >> are very different. By the way, this works only for MAP-E. I fail to see >> why we want to include this in the base spec. > >what do you say in the spec if EA=3D0 and provisioned IPv4 prefix length =3D >32. >the spec has to say something about this to be complete. > >cheers, >Ole > > >>=20 >> Thanks, >> Yiu >>=20 >>=20 >> On 7/25/12 9:45 PM, "Satoru Matsushima" >> wrote: >>=20 >>> Hi Yiu, >>>=20 >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>>=20 >>>> Ole, >>>>=20 >>>> Where can I get the formal definition of 1:1 mode? My understanding of >>>> 1:1 >>>> refers to one public IPv4 address per subscriber but you refer very >>>> specific to decoupling IPv4 and IPv6 addresses. >>>>=20 >>>=20 >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >>> address in ea-bits is as a result of prefix allocation operation. >>>=20 >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >>>> address >>>> information (EA bits > 0) in the CE IPv6 address to achieve stateless. >>>=20 >>> No, there was no such definition for EA-bits length restriction. >>>=20 >>>> Now there is a new proposal to add a new feature to have the IPv4 >>>> information >>>> in the BR only. This change requires to provision individual >>>>subscriber >>>> information to the BR (instead of aggregated information). Benefit are >>>> saving bits and breaking v4 and v6 address dependency. >>>=20 >>> There's no change from previous spec, to just clarify MAP, as a >>>stateless >>> solution, could naturally support most granular mapping rule in its >>> nature. >>>=20 >>>>=20 >>>> Questions to WG: >>>> Is it useful feature to be included in MAP? If not, why and >>>>alternative? >>>>=20 >>>=20 >>> I believe that it does not make sense to restrict EA-len > 0 for both >>>MAP >>> and 4rd. It does make sense that you see MAP as framework of solutions >>> which covers specific 1:1 solution by the mapping algorithm. >>>=20 >>> cheers, >>> --satoru >>>=20 >>>=20 >>>> Thanks, >>>> Yiu >>>>=20 >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >>>>=20 >>>>> Yiu, >>>>>=20 >>>>>> I am not asking whether MAP supports 1:1 mode with no EA bits or >>>>>>not. >>>>>> I >>>>>> am >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >>>>>> achieve >>>>>> 1:1 mode: >>>>>>=20 >>>>>> "The EA bits can contain a full or part >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address case >>>>>> contains a Port-Set Identifier (PSID)." >>>>>>=20 >>>>>> Why not use this instead? >>>>>=20 >>>>> you can do either. >>>>> embedding a complete IPv4 address and PSID does require a lot of IPv6 >>>>> space though. >>>>> e.g. /56 - 32 - 6 =3D /18 >>>>>=20 >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>>> addressing >>>>> are independent. >>>>>=20 >>>>> cheers, >>>>> Ole >>>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 > --B_3426145140_3717523 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQBEVaQ VUqqABbzPIl86z6v5lpdoTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA3MjYxNDU4NTdaMA0GCSqGSIb3DQEBAQUABIIBAETnYqnJIFnvrFHBP+Akuz+k 42I/Psj0hGSoQK+G8qvOz33TQlnQI30pOuXzPDMMQpNNxaynwlExpiqd60qMOwYv1bzqMm+i 2Z2H1avCeoznDOpiYYNK+auc7tm1CbJ5EUd3MSTDm/9lKcovaos2bWzfzGTLLrV3Noxe9UdX H+P0GYhxD64EVoTj15yCjFifOckVpuNd0VaGv3wrzkJ62uYGnQRS/xrJKWA6Dx1N8ISzNrmA o3qOYfquEF44z6zWSH5JWNOFq4Ef/R3STCVRIpAt6g4bqFTM71qewHSmmV8fZRtd5T46pRes kX2dDCI8aYEAfbnkhJF91UfyjCYh3r4= --B_3426145140_3717523-- From mohamed.boucadair@orange.com Fri Jul 27 04:48:43 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C3C21F8647 for ; Fri, 27 Jul 2012 04:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.050, 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 t4hY5kiJ9gNd for ; Fri, 27 Jul 2012 04:48:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7529D21F8629 for ; Fri, 27 Jul 2012 04:48:42 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id D93F83B417A; Fri, 27 Jul 2012 13:48:41 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BC2C335C055; Fri, 27 Jul 2012 13:48:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 27 Jul 2012 13:48:35 +0200 From: To: softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" , "sarikaya@ieee.org" Date: Fri, 27 Jul 2012 13:48:34 +0200 Thread-Topic: [softwire] #10: Nothing in common with DS-Lite Thread-Index: Ac1hQiF0u/+Lu5rRQNa4JseUbrjjUQKl0H0Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> In-Reply-To: <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.27.110315 Cc: "softwires@ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 27 Jul 2012 11:48:43 -0000 Dear all, I really don't understand this issue.=20 It is even misplaced to have this comment at this stage, since this is a do= cument which has been adopted by the WG and the solution it specifies is th= e same as the one reviewed by the WG prior to its adoption (i.e., since Apr= il 2011).=20 Anyway, below a tentative to explain the overall rationale:=20 DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be = first seen as an IP connectivity service. This service can be defined as fo= llows: =20 * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 addr= ess. The unicast portion of the service is defined in RFC6333 and is implemented= using a tunnel + CGN. =20 The multicast portion of the service is defined in draft-ietf-softwire-dsli= te-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabiliti= es * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed t= o allow DS-Lite serviced customers be delivered IPv4 multicast services. A side note, I agree with Stig and Woj the proposed solution can be general= ized to cover any 4-6-4 scenario. This can be done easily by updating the d= raft (abstract and introduction) to reflect the change of scope of use case= s. We didn't had the ambition to define a generic solution when we wrote th= is draft, we focused mainly on the DS-Lite context. If there is no objectio= n from the WG, we can implement that change.=20 Cheers, Med >-----Message d'origine----- >De : softwire issue tracker [mailto:trac+softwire@tools.ietf.org]=20 >Envoy=E9 : vendredi 13 juillet 2012 23:55 >=C0 : draft-ietf-softwire-dslite-multicast@tools.ietf.org;=20 >sarikaya@ieee.org >Cc : softwires@ietf.org >Objet : Re: [softwire] #10: Nothing in common with DS-Lite > >#10: Nothing in common with DS-Lite > >Changes (by sarikaya@.): > > * owner: sarikaya@. =3D> draft-ietf-softwire-dslite-multicast@. > > >--=20 >-------------------------+------------------------------------- >------------ > Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- > Type: defect | multicast@. > Priority: major | Status: new >Component: dslite- | Milestone: milestone1 > multicast | Version: 2.0 > Severity: In WG Last | Resolution: > Call | > Keywords: tunneling | >-------------------------+------------------------------------- >------------ > >Ticket URL:=20 > >softwire > >= From wdec.ietf@gmail.com Fri Jul 27 04:59:53 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6EC21F8659 for ; Fri, 27 Jul 2012 04:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmv9xDfjlAQ4 for ; Fri, 27 Jul 2012 04:59:52 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2161221F861B for ; Fri, 27 Jul 2012 04:59:52 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2735366vcb.31 for ; Fri, 27 Jul 2012 04:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x6L4wEwnM2J5gXGl0B28SAvhM5CAiOIc6dS2uu4Ds34=; b=BXw5mP3cTsxNyODolpE8CaFj8LUJg+SZsu6JgsZlxi0nv+mObReIgSdtPHecHQnnrm Pjnq0wN541vdzzYDvXSKPnNf8iymQ4UaejtgoYb/qxFolNa6OwIiDufPYvAaB+vKDLqn k2WYk3bC3HPsyuaD6bqntQNkiEXjSC39mXW1igk3i5E3gh6yNtJ+LfwboRaosmrJmCSg QNZo2ZfO5NvQdmpbQ3TDPHRhiRytlEiaW7dmHYduwjNA/xt6a/VO2ViuHsAeSLa1L8ym 3C20WC/JejkNla7jbV31PbgJbQeNB+B0a8WV1WWyVhSyVYORibgPmJRF3iqTRcJpMKLd 7XSw== MIME-Version: 1.0 Received: by 10.52.97.196 with SMTP id ec4mr1854111vdb.96.1343390391560; Fri, 27 Jul 2012 04:59:51 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Fri, 27 Jul 2012 04:59:51 -0700 (PDT) In-Reply-To: References: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> <94C682931C08B048B7A8645303FDC9F36E4A17E397@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 27 Jul 2012 13:59:51 +0200 Message-ID: From: Wojciech Dec To: Maoke Content-Type: multipart/alternative; boundary=20cf307f3798156ad604c5ce7328 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 11:59:53 -0000 --20cf307f3798156ad604c5ce7328 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Med, 2) and 3) both require configuration and as has been amply discussed technically there is no issue with per subscriber rules in 2) or optimization applying to 3). As such, justifying three different solutions out of which two can technically have the same amount of configuration state and are almost the same appears illogical. >From another perspective, defining a solution that by definition requires per subscriber configuration state and does not allow its optimization is highly questionable technically. Regards, Woj. On 26 July 2012 16:34, Maoke wrote: > > > 2012/7/26 > > Dear Ole, all, >> >> For sure MAP spec can be updated to cover 1:1 mode but this brings more >> confusion for some people as this contradicts the "no state in ISP netwo= rk" >> paradigm. I personally vote for limiting MAP to its initial scope rather >> than trying to cover other deployment options. >> >> I see three main flavours which justifies having standalone specificatio= n >> documents: >> >> (1) Full stateful mode: DS-Lite >> (2) Full stateless mode: MAP/4rd >> (3) Per-customer state/binding mode: lw4o6 >> (draft-cui-softwire-b4-translated-ds-lite) >> >> These three flavours have been already sketched in Figure 7 of RFC6346 >> (see http://tools.ietf.org/html/rfc6346#section-3.3.4). >> >> > yes. i share this point. thanks, Med, for the clear explanation on the bi= g > picture. - maoke > > >> Having standalone specifications for each of these flavours helps >> operators to better target their suitable deployment model without being >> disturbed with parameters and details not pertinent for their deployment >> context. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De : softwires-bounces@ietf.org >> >[mailto:softwires-bounces@ietf.org] De la part de Ole Tr=F8an >> >Envoy=E9 : jeudi 26 juillet 2012 12:23 >> >=C0 : Lee, Yiu >> >Cc : Softwires-wg >> >Objet : Re: [Softwires] map-00: review on the mode 1:1 >> > >> >Yiu, >> > >> >> Set EA bits=3D0 only saves bits in v6 address and decouples >> >v4/v6 address >> >> dependency. It doesn't bring any new function compared to >> >embedding full >> >> v4 address in the EA-bit. However, the operation models of >> >EA-bit>0 or =3D0 >> >> are very different. By the way, this works only for MAP-E. I >> >fail to see >> >> why we want to include this in the base spec. >> > >> >what do you say in the spec if EA=3D0 and provisioned IPv4 >> >prefix length =3D 32. >> >the spec has to say something about this to be complete. >> > >> >cheers, >> >Ole >> > >> > >> >> >> >> Thanks, >> >> Yiu >> >> >> >> >> >> On 7/25/12 9:45 PM, "Satoru Matsushima" >> >> wrote: >> >> >> >>> Hi Yiu, >> >>> >> >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >> >>> >> >>>> Ole, >> >>>> >> >>>> Where can I get the formal definition of 1:1 mode? My >> >understanding of >> >>>> 1:1 >> >>>> refers to one public IPv4 address per subscriber but you refer very >> >>>> specific to decoupling IPv4 and IPv6 addresses. >> >>>> >> >>> >> >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >> >>> address in ea-bits is as a result of prefix allocation operation. >> >>> >> >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >> >>>> address >> >>>> information (EA bits > 0) in the CE IPv6 address to >> >achieve stateless. >> >>> >> >>> No, there was no such definition for EA-bits length restriction. >> >>> >> >>>> Now there is a new proposal to add a new feature to have the IPv4 >> >>>> information >> >>>> in the BR only. This change requires to provision >> >individual subscriber >> >>>> information to the BR (instead of aggregated information). >> >Benefit are >> >>>> saving bits and breaking v4 and v6 address dependency. >> >>> >> >>> There's no change from previous spec, to just clarify MAP, >> >as a stateless >> >>> solution, could naturally support most granular mapping rule in its >> >>> nature. >> >>> >> >>>> >> >>>> Questions to WG: >> >>>> Is it useful feature to be included in MAP? If not, why >> >and alternative? >> >>>> >> >>> >> >>> I believe that it does not make sense to restrict EA-len > >> >0 for both MAP >> >>> and 4rd. It does make sense that you see MAP as framework >> >of solutions >> >>> which covers specific 1:1 solution by the mapping algorithm. >> >>> >> >>> cheers, >> >>> --satoru >> >>> >> >>> >> >>>> Thanks, >> >>>> Yiu >> >>>> >> >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >> >>>> >> >>>>> Yiu, >> >>>>> >> >>>>>> I am not asking whether MAP supports 1:1 mode with no EA >> >bits or not. >> >>>>>> I >> >>>>>> am >> >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >> >>>>>> achieve >> >>>>>> 1:1 mode: >> >>>>>> >> >>>>>> "The EA bits can contain a full or part >> >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address case >> >>>>>> contains a Port-Set Identifier (PSID)." >> >>>>>> >> >>>>>> Why not use this instead? >> >>>>> >> >>>>> you can do either. >> >>>>> embedding a complete IPv4 address and PSID does require a >> >lot of IPv6 >> >>>>> space though. >> >>>>> e.g. /56 - 32 - 6 =3D /18 >> >>>>> >> >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >> >>>>> addressing >> >>>>> are independent. >> >>>>> >> >>>>> cheers, >> >>>>> Ole >> >>>>> >> >>>> _______________________________________________ >> >>>> Softwires mailing list >> >>>> Softwires@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/softwires >> >>> >> > >> >_______________________________________________ >> >Softwires mailing list >> >Softwires@ietf.org >> >https://www.ietf.org/mailman/listinfo/softwires >> > >> _______________________________________________ >> 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 > > --20cf307f3798156ad604c5ce7328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Med,

=A02) and 3) both require configuration and as has been amply d= iscussed technically there is no issue with per subscriber rules in 2) or o= ptimization applying to 3). As such, justifying three different solutions o= ut of which two can technically have the same amount of configuration state= and are almost the same appears illogical.
>From another perspective, defining a solution that by definition requires p= er subscriber configuration state and does not allow its optimization is hi= ghly questionable technically.

Regards,
Woj.

On 26 July 2012 16:34, Maoke <fibrib@gmail.com> wrote:


2012/7/26 <mohamed.boucadai= r@orange.com>

Dear Ole, all,

For sure MAP spec can be updated to cover 1:1 mode but this brings more con= fusion for some people as this contradicts the "no state in ISP networ= k" paradigm. I personally vote for limiting MAP to its initial scope r= ather than trying to cover other deployment options.

I see three main flavours which justifies having standalone specification d= ocuments:

(1) Full stateful mode: DS-Lite
(2) Full stateless mode: MAP/4rd
(3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translate= d-ds-lite)

These three flavours have been already sketched in Figure 7 of RFC6346 (see= http://tools.ietf.org/html/rfc6346#section-3.3.4).

=A0
yes. i share this point. thanks, = Med, for the clear explanation on the big picture. - maoke
=A0
Having standalone specifications for each of these flavours helps operators= to better target their suitable deployment model without being disturbed w= ith parameters and details not pertinent for their deployment context.

Cheers,
Med

>-----Message d'origine-----
>De : so= ftwires-bounces@ietf.org
>[mailto:softwires-bounces@ietf.org] De la part de Ole Tr=F8an
>Envoy=E9 : jeudi 26 juillet 2012 12:23
>=C0 : Lee, Yiu
>Cc : Softwires-wg
>Objet : Re: [Softwires] map-00: review on the mode 1:1
>
>Yiu,
>
>> Set EA bits=3D0 only saves bits in v6 address and decouples
>v4/v6 address
>> dependency. It doesn't bring any new function compared to
>embedding full
>> v4 address in the EA-bit. However, the operation models of
>EA-bit>0 or =3D0
>> are very different. By the way, this works only for MAP-E. I
>fail to see
>> why we want to include this in the base spec.
>
>what do you say in the spec if EA=3D0 and provisioned IPv4
>prefix length =3D 32.
>the spec has to say something about this to be complete.
>
>cheers,
>Ole
>
>
>>
>> Thanks,
>> Yiu
>>
>>
>> On 7/25/12 9:45 PM, "Satoru Matsushima" <satoru.matsushima@gmai= l.com>
>> wrote:
>>
>>> Hi Yiu,
>>>
>>> On 2012/07/26, at 4:08, Lee, Yiu wrote:
>>>
>>>> Ole,
>>>>
>>>> Where can I get the formal definition of 1:1 mode? My
>understanding of
>>>> 1:1
>>>> refers to one public IPv4 address per subscriber but you r= efer very
>>>> specific to decoupling IPv4 and IPv6 addresses.
>>>>
>>>
>>> It doesn't 1:1 in MAP and 4rd context, because embedding f= ull ipv4
>>> address in ea-bits is as a result of prefix allocation operati= on.
>>>
>>>> Before MAP was accepted as WG item, MAP was proposed to em= bed IPv4
>>>> address
>>>> information (EA bits > 0) in the CE IPv6 address to
>achieve stateless.
>>>
>>> No, there was no such definition for EA-bits length restrictio= n.
>>>
>>>> Now there is a new proposal to add a new feature to have t= he IPv4
>>>> information
>>>> in the BR only. This change requires to provision
>individual subscriber
>>>> information to the BR (instead of aggregated information).=
>Benefit are
>>>> saving bits and breaking v4 and v6 address dependency.
>>>
>>> There's no change from previous spec, to just clarify MAP,=
>as a stateless
>>> solution, could naturally support most granular mapping rule i= n its
>>> nature.
>>>
>>>>
>>>> Questions to WG:
>>>> Is it useful feature to be included in MAP? If not, why >and alternative?
>>>>
>>>
>>> I believe that it does not make sense to restrict EA-len ><= br> >0 for both MAP
>>> and 4rd. It does make sense that you see MAP as framework
>of solutions
>>> which covers specific 1:1 solution by the mapping algorithm. >>>
>>> cheers,
>>> --satoru
>>>
>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" <otroan@employees.org>= ; wrote:
>>>>
>>>>> Yiu,
>>>>>
>>>>>> I am not asking whether MAP supports 1:1 mode with= no EA
>bits or not.
>>>>>> I
>>>>>> am
>>>>>> asking MAP allows to embed the 32-bit address in t= he EA bits to
>>>>>> achieve
>>>>>> 1:1 mode:
>>>>>>
>>>>>> "The EA bits can contain a full or part
>>>>>> of an IPv4 prefix or address, and in the shared IP= v4 address case
>>>>>> contains a Port-Set Identifier (PSID)."
>>>>>>
>>>>>> Why not use this instead?
>>>>>
>>>>> you can do either.
>>>>> embedding a complete IPv4 address and PSID does requir= e a
>lot of IPv6
>>>>> space though.
>>>>> e.g. /56 - 32 - 6 =3D /18
>>>>>
>>>>> 1:1 mode is typically referred to a model where IPv4 a= nd IPv6
>>>>> addressing
>>>>> are independent.
>>>>>
>>>>> cheers,
>>>>> Ole
>>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> So= ftwires@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<= /a>
https://www.ietf.org/mailman/listinfo/softwires


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


--20cf307f3798156ad604c5ce7328-- From wdec.ietf@gmail.com Fri Jul 27 05:06:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A1F21F864E for ; Fri, 27 Jul 2012 05:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5gzM-D8XsmJ for ; Fri, 27 Jul 2012 05:06:09 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A65B21F8647 for ; Fri, 27 Jul 2012 05:06:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2778576vbb.31 for ; Fri, 27 Jul 2012 05:06:09 -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=BVE8Khh4zsLWYJvZIPiZ75Tco8uwRlXhMaChPTTg6G8=; b=zTWWisGQd8s6pQObjqm8vqqnxxnZHRDZjmh0lpa0jQ2d07SlCyYRG98wlHIeNelrvp etY9CKljs32singIA6ASf+spVd0bDL78JwqbTDf4+Cbsrn5KJIbhIF1CNyZ2FQW76KS3 JyjEdSeIid8NGxDuJPkt1gCwlhbRte4rWj3mOdfbYn0YoumkKvZXzbcJS24jFfh9yzGr dvkIlhO2nDwpVZL0O1SOan2hIAXYp42H2DEXYfCKBJmXOs0dPHz7d7oHkWMAHF5phGhG XsCepnn6wEvpgg8yAWGYlUqiRqDrwqzTgk+oWv5h0gz6tq0masG3NUZSQtN1o9f8xuwk R0+g== MIME-Version: 1.0 Received: by 10.52.16.212 with SMTP id i20mr1871026vdd.118.1343390769044; Fri, 27 Jul 2012 05:06:09 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Fri, 27 Jul 2012 05:06:08 -0700 (PDT) In-Reply-To: References: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> Date: Fri, 27 Jul 2012 14:06:08 +0200 Message-ID: From: Wojciech Dec To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=bcaec502d770955d2504c5ce890f Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 12:06:10 -0000 --bcaec502d770955d2504c5ce890f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 26 July 2012 16:59, Lee, Yiu wrote: > Ole, > > IMHO the WG will need to decide whether EA=3D0 should be covered at all. = If > not, then the draft could explicitly mention EA must be > 0 and must > contain v4 information in the CE address. If the WG decided this needed t= o > be cover, I would recommend to have a new draft to cover it and leave EA= =3D0 > undefined in the base draft. > What are the technical arguments for making such a decision? Furthermore, given that EA=3D0 is already covered (eg embedding of full IPv= 4 address, no address sharing, if not the other case) you appear to be calling out for a "remove that part of the spec & complicate it" case, even though not disputing the use-fullness of the use-case. Seems a sure way to get us from 1 solution to N solutions just for the sake of it. Thanks, Woj. > > Thanks, > Yiu > > On 7/26/12 6:22 AM, "Ole Tr=F8an" wrote: > > >Yiu, > > > >> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 addr= ess > >> dependency. It doesn't bring any new function compared to embedding fu= ll > >> v4 address in the EA-bit. However, the operation models of EA-bit>0 or > >>=3D0 > >> are very different. By the way, this works only for MAP-E. I fail to s= ee > >> why we want to include this in the base spec. > > > >what do you say in the spec if EA=3D0 and provisioned IPv4 prefix length= =3D > >32. > >the spec has to say something about this to be complete. > > > >cheers, > >Ole > > > > > >> > >> Thanks, > >> Yiu > >> > >> > >> On 7/25/12 9:45 PM, "Satoru Matsushima" > >> wrote: > >> > >>> Hi Yiu, > >>> > >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: > >>> > >>>> Ole, > >>>> > >>>> Where can I get the formal definition of 1:1 mode? My understanding = of > >>>> 1:1 > >>>> refers to one public IPv4 address per subscriber but you refer very > >>>> specific to decoupling IPv4 and IPv6 addresses. > >>>> > >>> > >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 > >>> address in ea-bits is as a result of prefix allocation operation. > >>> > >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 > >>>> address > >>>> information (EA bits > 0) in the CE IPv6 address to achieve stateles= s. > >>> > >>> No, there was no such definition for EA-bits length restriction. > >>> > >>>> Now there is a new proposal to add a new feature to have the IPv4 > >>>> information > >>>> in the BR only. This change requires to provision individual > >>>>subscriber > >>>> information to the BR (instead of aggregated information). Benefit a= re > >>>> saving bits and breaking v4 and v6 address dependency. > >>> > >>> There's no change from previous spec, to just clarify MAP, as a > >>>stateless > >>> solution, could naturally support most granular mapping rule in its > >>> nature. > >>> > >>>> > >>>> Questions to WG: > >>>> Is it useful feature to be included in MAP? If not, why and > >>>>alternative? > >>>> > >>> > >>> I believe that it does not make sense to restrict EA-len > 0 for both > >>>MAP > >>> and 4rd. It does make sense that you see MAP as framework of solution= s > >>> which covers specific 1:1 solution by the mapping algorithm. > >>> > >>> cheers, > >>> --satoru > >>> > >>> > >>>> Thanks, > >>>> Yiu > >>>> > >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: > >>>> > >>>>> Yiu, > >>>>> > >>>>>> I am not asking whether MAP supports 1:1 mode with no EA bits or > >>>>>>not. > >>>>>> I > >>>>>> am > >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to > >>>>>> achieve > >>>>>> 1:1 mode: > >>>>>> > >>>>>> "The EA bits can contain a full or part > >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address case > >>>>>> contains a Port-Set Identifier (PSID)." > >>>>>> > >>>>>> Why not use this instead? > >>>>> > >>>>> you can do either. > >>>>> embedding a complete IPv4 address and PSID does require a lot of IP= v6 > >>>>> space though. > >>>>> e.g. /56 - 32 - 6 =3D /18 > >>>>> > >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 > >>>>> addressing > >>>>> are independent. > >>>>> > >>>>> cheers, > >>>>> Ole > >>>>> > >>>> _______________________________________________ > >>>> Softwires mailing list > >>>> Softwires@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/softwires > >>> > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --bcaec502d770955d2504c5ce890f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 26 July 2012 16:59, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Ole,

IMHO the WG will need to decide whether EA=3D0 should be covered at all. If=
not, then the draft could explicitly mention EA must be > 0 and must
contain v4 information in the CE address. If the WG decided this needed to<= br> be cover, I would recommend to have a new draft to cover it and leave EA=3D= 0
undefined in the base draft.

What are the technica= l arguments for making such a decision?
Furthermore, given that EA=3D0 i= s already covered (eg embedding of full IPv4 address, no address sharing, i= f not the other case) you appear to be calling out for a "remove that = part of the spec & complicate it" case, even though not disputing = the use-fullness of the use-case.=A0 Seems a sure way to get us from 1 solu= tion to N solutions just for the sake of it.

Thanks,
Woj.

Thanks,
Yiu

On 7/26/12 6:22 AM, "Ole Tr=F8an" <otroan@employees.org> wrote:

>Yiu,
>
>> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 = address
>> dependency. It doesn't bring any new function compared to embe= dding full
>> v4 address in the EA-bit. However, the operation models of EA-bit&= gt;0 or
>>=3D0
>> are very different. By the way, this works only for MAP-E. I fail = to see
>> why we want to include this in the base spec.
>
>what do you say in the spec if EA=3D0 and provisioned IPv4 prefix lengt= h =3D
>32.
>the spec has to say something about this to be complete.
>
>cheers,
>Ole
>
>
>>
>> Thanks,
>> Yiu
>>
>>
>> On 7/25/12 9:45 PM, "Satoru Matsushima" <satoru.matsushima@gmail.com>
>> wrote:
>>
>>> Hi Yiu,
>>>
>>> On 2012/07/26, at 4:08, Lee, Yiu wrote:
>>>
>>>> Ole,
>>>>
>>>> Where can I get the formal definition of 1:1 mode? My unde= rstanding of
>>>> 1:1
>>>> refers to one public IPv4 address per subscriber but you r= efer very
>>>> specific to decoupling IPv4 and IPv6 addresses.
>>>>
>>>
>>> It doesn't 1:1 in MAP and 4rd context, because embedding f= ull ipv4
>>> address in ea-bits is as a result of prefix allocation operati= on.
>>>
>>>> Before MAP was accepted as WG item, MAP was proposed to em= bed IPv4
>>>> address
>>>> information (EA bits > 0) in the CE IPv6 address to ach= ieve stateless.
>>>
>>> No, there was no such definition for EA-bits length restrictio= n.
>>>
>>>> Now there is a new proposal to add a new feature to have t= he IPv4
>>>> information
>>>> in the BR only. This change requires to provision individu= al
>>>>subscriber
>>>> information to the BR (instead of aggregated information).= Benefit are
>>>> saving bits and breaking v4 and v6 address dependency.
>>>
>>> There's no change from previous spec, to just clarify MAP,= as a
>>>stateless
>>> solution, could naturally support most granular mapping rule i= n its
>>> nature.
>>>
>>>>
>>>> Questions to WG:
>>>> Is it useful feature to be included in MAP? If not, why an= d
>>>>alternative?
>>>>
>>>
>>> I believe that it does not make sense to restrict EA-len > = 0 for both
>>>MAP
>>> and 4rd. It does make sense that you see MAP as framework of s= olutions
>>> which covers specific 1:1 solution by the mapping algorithm. >>>
>>> cheers,
>>> --satoru
>>>
>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>>>>
>>>>> Yiu,
>>>>>
>>>>>> I am not asking whether MAP supports 1:1 mode with= no EA bits or
>>>>>>not.
>>>>>> I
>>>>>> am
>>>>>> asking MAP allows to embed the 32-bit address in t= he EA bits to
>>>>>> achieve
>>>>>> 1:1 mode:
>>>>>>
>>>>>> "The EA bits can contain a full or part
>>>>>> of an IPv4 prefix or address, and in the shared IP= v4 address case
>>>>>> contains a Port-Set Identifier (PSID)."
>>>>>>
>>>>>> Why not use this instead?
>>>>>
>>>>> you can do either.
>>>>> embedding a complete IPv4 address and PSID does requir= e a lot of IPv6
>>>>> space though.
>>>>> e.g. /56 - 32 - 6 =3D /18
>>>>>
>>>>> 1:1 mode is typically referred to a model where IPv4 a= nd IPv6
>>>>> addressing
>>>>> are independent.
>>>>>
>>>>> cheers,
>>>>> Ole
>>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>

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


--bcaec502d770955d2504c5ce890f-- From yiu_lee@cable.comcast.com Fri Jul 27 05:39:40 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9653D21F8674 for ; Fri, 27 Jul 2012 05:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGKIqRgEgQf8 for ; Fri, 27 Jul 2012 05:39:39 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5679E21F8671 for ; Fri, 27 Jul 2012 05:39:39 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.26859226; Fri, 27 Jul 2012 06:20:32 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0309.002; Fri, 27 Jul 2012 08:39:31 -0400 From: "Lee, Yiu" To: Wojciech Dec Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: AQHNa/TdA9kpWrCn10SVvwbn78KB1A== Date: Fri, 27 Jul 2012 12:39:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [24.40.55.72] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3426223170_3099904" MIME-Version: 1.0 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 12:39:40 -0000 --B_3426223170_3099904 Content-type: multipart/alternative; boundary="B_3426223165_3108161" --B_3426223165_3108161 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Woj, I am confused. You said "given that EA=3D0 is already covered (eg embedding o= f full IPv4 address, no address sharing, if not the other case)". If I read the spec right, this is my understanding: If I want to embed full v4 addres= s in the CE v6 address, the v4 address will be embedded in the EA. If so, how would EA=3D0?=20 "The EA bits encode the CE specific IPv4 address and port information. The EA bits can contain a full or part of an IPv4 prefix or address, and in the shared IPv4 address case contains a Port-Set Identifier (PSID)." I prefer one solution vs. N solutions given that the one solution can logically solve all problems and doesn't cause confusion. Consider we agree= d on including 1:1 MAP. When an operator deployed it, he had to ask if I want to share v4 addresses, should I put the v4 info in the EA or set EA=3D0 and provision PSID? It will create unnecessary confusion. Simply put I am not "calling out for a "remove that part of the spec & complicate it" case". My position is quite an opposite. I am calling out for "not adding confusion t= o complicate a spec". In the end, it is up to WG to decide. Thanks, Yiu From: Wojciech Dec Date: Friday, July 27, 2012 8:06 AM To: "Yiu L. LEE" Cc: Ole Tr=F8an , Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 On 26 July 2012 16:59, Lee, Yiu wrote: > Ole, >=20 > IMHO the WG will need to decide whether EA=3D0 should be covered at all. If > not, then the draft could explicitly mention EA must be > 0 and must > contain v4 information in the CE address. If the WG decided this needed t= o > be cover, I would recommend to have a new draft to cover it and leave EA=3D= 0 > undefined in the base draft. What are the technical arguments for making such a decision? Furthermore, given that EA=3D0 is already covered (eg embedding of full IPv4 address, no address sharing, if not the other case) you appear to be callin= g out for a "remove that part of the spec & complicate it" case, even though not disputing the use-fullness of the use-case. Seems a sure way to get us from 1 solution to N solutions just for the sake of it. Thanks, Woj. >=20 > Thanks, > Yiu >=20 > On 7/26/12 6:22 AM, "Ole Tr=F8an" wrote: >=20 >> >Yiu, >> > >>> >> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 addr= ess >>> >> dependency. It doesn't bring any new function compared to embedding = full >>> >> v4 address in the EA-bit. However, the operation models of EA-bit>0 = or >>> >>=3D0 >>> >> are very different. By the way, this works only for MAP-E. I fail to= see >>> >> why we want to include this in the base spec. >> > >> >what do you say in the spec if EA=3D0 and provisioned IPv4 prefix length = =3D >> >32. >> >the spec has to say something about this to be complete. >> > >> >cheers, >> >Ole >> > >> > >>> >> >>> >> Thanks, >>> >> Yiu >>> >> >>> >> >>> >> On 7/25/12 9:45 PM, "Satoru Matsushima" >>> >> wrote: >>> >> >>>> >>> Hi Yiu, >>>> >>> >>>> >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>>> >>> >>>>> >>>> Ole, >>>>> >>>> >>>>> >>>> Where can I get the formal definition of 1:1 mode? My understand= ing of >>>>> >>>> 1:1 >>>>> >>>> refers to one public IPv4 address per subscriber but you refer v= ery >>>>> >>>> specific to decoupling IPv4 and IPv6 addresses. >>>>> >>>> >>>> >>> >>>> >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >>>> >>> address in ea-bits is as a result of prefix allocation operation. >>>> >>> >>>>> >>>> Before MAP was accepted as WG item, MAP was proposed to embed IP= v4 >>>>> >>>> address >>>>> >>>> information (EA bits > 0) in the CE IPv6 address to achieve >>>>> stateless. >>>> >>> >>>> >>> No, there was no such definition for EA-bits length restriction. >>>> >>> >>>>> >>>> Now there is a new proposal to add a new feature to have the IPv= 4 >>>>> >>>> information >>>>> >>>> in the BR only. This change requires to provision individual >>>>> >>>>subscriber >>>>> >>>> information to the BR (instead of aggregated information). Benef= it are >>>>> >>>> saving bits and breaking v4 and v6 address dependency. >>>> >>> >>>> >>> There's no change from previous spec, to just clarify MAP, as a >>>> >>>stateless >>>> >>> solution, could naturally support most granular mapping rule in it= s >>>> >>> nature. >>>> >>> >>>>> >>>> >>>>> >>>> Questions to WG: >>>>> >>>> Is it useful feature to be included in MAP? If not, why and >>>>> >>>>alternative? >>>>> >>>> >>>> >>> >>>> >>> I believe that it does not make sense to restrict EA-len > 0 for b= oth >>>> >>>MAP >>>> >>> and 4rd. It does make sense that you see MAP as framework of solut= ions >>>> >>> which covers specific 1:1 solution by the mapping algorithm. >>>> >>> >>>> >>> cheers, >>>> >>> --satoru >>>> >>> >>>> >>> >>>>> >>>> Thanks, >>>>> >>>> Yiu >>>>> >>>> >>>>> >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >>>>> >>>> >>>>>> >>>>> Yiu, >>>>>> >>>>> >>>>>>> >>>>>> I am not asking whether MAP supports 1:1 mode with no EA bit= s or >>>>>>> >>>>>>not. >>>>>>> >>>>>> I >>>>>>> >>>>>> am >>>>>>> >>>>>> asking MAP allows to embed the 32-bit address in the EA bits= to >>>>>>> >>>>>> achieve >>>>>>> >>>>>> 1:1 mode: >>>>>>> >>>>>> >>>>>>> >>>>>> "The EA bits can contain a full or part >>>>>>> >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address= case >>>>>>> >>>>>> contains a Port-Set Identifier (PSID)." >>>>>>> >>>>>> >>>>>>> >>>>>> Why not use this instead? >>>>>> >>>>> >>>>>> >>>>> you can do either. >>>>>> >>>>> embedding a complete IPv4 address and PSID does require a lot = of IPv6 >>>>>> >>>>> space though. >>>>>> >>>>> e.g. /56 - 32 - 6 =3D /18 >>>>>> >>>>> >>>>>> >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>>>> >>>>> addressing >>>>>> >>>>> are independent. >>>>>> >>>>> >>>>>> >>>>> cheers, >>>>>> >>>>> Ole >>>>>> >>>>> >>>>> >>>> _______________________________________________ >>>>> >>>> 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 --B_3426223165_3108161 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Woj,

I am co= nfused. You said "given that EA=3D0 is already covered (eg embedding of full I= Pv4 address, no address sharing, if not the other case)". If I read the spec= right, this is my understanding: If I want to embed full v4 address in= the CE v6 address, the v4 address will be embedded in the EA. If so, how wo= uld EA=3D0? 

"The EA bits encode the CE sp= ecific IPv4
   address and port information=
.  The EA bits can contain a full or part
   of an IPv4 prefix or address, and in the shared IPv4 address case
   contains a Port-Set Identifier (PSID)."

I prefe= r one solution vs. N solutions given that the one solution can logically sol= ve all problems and doesn't cause confusion. Consider we agreed on including= 1:1 MAP. When an operator deployed it, he had to ask if I want to share v4 = addresses, should I put the v4 info in the EA or set EA=3D0 and provision PSID= ? It will create unnecessary confusion. Simply put I am not "calling out for= a "remove that part of the spec & complicate it" case". My position is = quite an opposite. I am calling out for "not adding confusion to complicate = a spec".

In the end, it is up to WG to decide.

Thanks,
Yiu

From: Wojciech Dec <wdec.ietf@gmail.com>
Date: <= /span> Friday, July 27, 2012 8:06 AM
To: <= /span> "Yiu L. LEE" <yiu_lee@c= able.comcast.com>
Cc: Ole T= r=F8an <otroan@employees.org>,= Softwires-wg <softwires@ietf.org= >
Subject: Re: [Softwires] map-= 00: review on the mode 1:1



On 26 July 2012 16:59, Lee, Yiu <Yiu_Lee@cable.comcast.com>= ; wrote:
Ole,

IMHO the WG will need to decide whether EA=3D0 should be covered at all. If not, then the draft could explicitly mention EA must be > 0 and must
= contain v4 information in the CE address. If the WG decided this needed to<= br> be cover, I would recommend to have a new draft to cover it and leave EA=3D0<= br> undefined in the base draft.

What are the technical arguments for making such a decision?
Furthermore, given that EA=3D0 is already covered (eg embedding of full IPv4 = address, no address sharing, if not the other case) you appear to be calling= out for a "remove that part of the spec & complicate it" case, even tho= ugh not disputing the use-fullness of the use-case.  Seems a sure way to get us from 1 solution to N sol= utions just for the sake of it.

Thanks,
Woj.

Thanks,
Yiu

On 7/26/12 6:22 AM, "Ole Tr=F8an" <o= troan@employees.org> wrote:

>Yiu,
>
>> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 ad= dress
>> dependency. It doesn't bring any new function compared to embeddin= g full
>> v4 address in the EA-bit. However, the operation models of EA-bit&= gt;0 or
>>=3D0
>> are very different. By the way, this works only for MAP-E. I fail = to see
>> why we want to include this in the base spec.
>
>what do you say in the spec if EA=3D0 and provisioned IPv4 prefix length = =3D
>32.
>the spec has to say something about this to be complete.
>
>cheers,
>Ole
>
>
>>
>> Thanks,
>> Yiu
>>
>>
>> On 7/25/12 9:45 PM, "Satoru Matsushima" <satoru.matsushima@gmail.com>
>> wrote:
>>
>>> Hi Yiu,
>>>
>>> On 2012/07/26, at 4:08, Lee, Yiu wrote:
>>>
>>>> Ole,
>>>>
>>>> Where can I get the formal definition of 1:1 mode? My unde= rstanding of
>>>> 1:1
>>>> refers to one public IPv4 address per subscriber but you r= efer very
>>>> specific to decoupling IPv4 and IPv6 addresses.
>>>>
>>>
>>> It doesn't 1:1 in MAP and 4rd context, because embedding full = ipv4
>>> address in ea-bits is as a result of prefix allocation operati= on.
>>>
>>>> Before MAP was accepted as WG item, MAP was proposed to em= bed IPv4
>>>> address
>>>> information (EA bits > 0) in the CE IPv6 address to ach= ieve stateless.
>>>
>>> No, there was no such definition for EA-bits length restrictio= n.
>>>
>>>> Now there is a new proposal to add a new feature to have t= he IPv4
>>>> information
>>>> in the BR only. This change requires to provision individu= al
>>>>subscriber
>>>> information to the BR (instead of aggregated information).= Benefit are
>>>> saving bits and breaking v4 and v6 address dependency.
= >>>
>>> There's no change from previous spec, to just clarify MAP, as = a
>>>stateless
>>> solution, could naturally support most granular mapping rule i= n its
>>> nature.
>>>
>>>>
>>>> Questions to WG:
>>>> Is it useful feature to be included in MAP? If not, why an= d
>>>>alternative?
>>>>
>>>
>>> I believe that it does not make sense to restrict EA-len > = 0 for both
>>>MAP
>>> and 4rd. It does make sense that you see MAP as framework of s= olutions
>>> which covers specific 1:1 solution by the mapping algorithm. >>>
>>> cheers,
>>> --satoru
>>>
>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" <otroan@employees.org> wrote:
>>>>
>>>>> Yiu,
>>>>>
>>>>>> I am not asking whether MAP supports 1:1 mode with= no EA bits or
>>>>>>not.
>>>>>> I
>>>>>> am
>>>>>> asking MAP allows to embed the 32-bit address in t= he EA bits to
>>>>>> achieve
>>>>>> 1:1 mode:
>>>>>>
>>>>>> "The EA bits can contain a full or part
>>>>>> of an IPv4 prefix or address, and in the shared IP= v4 address case
>>>>>> contains a Port-Set Identifier (PSID)."
>>>>>>
>>>>>> Why not use this instead?
>>>>>
>>>>> you can do either.
>>>>> embedding a complete IPv4 address and PSID does requir= e a lot of IPv6
>>>>> space though.
>>>>> e.g. /56 - 32 - 6 =3D /18
>>>>>
>>>>> 1:1 mode is typically referred to a model where IPv4 a= nd IPv6
>>>>> addressing
>>>>> are independent.
>>>>>
>>>>> cheers,
>>>>> Ole
>>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> Softwires@ietf.org=
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>

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


 --B_3426223165_3108161-- --B_3426223170_3099904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQcYUoL UO7sKxeenBjeToHSrpzlYjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA3MjcxMjM5MjVaMA0GCSqGSIb3DQEBAQUABIIBAGXJ6xVD/rJPEaR2BSCgTyXx 54KtFEiZA60UYzf3yXmX/eOAq1MZcMcnDxVWNJZMZmeoFH1JNri6c02gCk3EDLYos215tDFg sb3LXjvCXaBfh2n1vkdRv/TyfuWxcnStXCKDHAnm9Ox1R3Xn6CEoAhHeBpM1ZTeudmI8Ttwn tRatB15hwAYFZk26M8Gqimt7e0GUAS0lhsD/GfItzOVJimJZMTqsI2cgFSUR+mbzN66EvP5m 7bPzSq1mDj2ldxwjlRLqvauuzwml24RDR4poqfY95sEtQrDrVcG29WzR+O4/ETmvajiL5lSC S2vPyx1tenvc/s8SPHLVM4a6mWnCPgM= --B_3426223170_3099904-- From mohamed.boucadair@orange.com Fri Jul 27 05:40:13 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8EC21F84FE for ; Fri, 27 Jul 2012 05:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HcS9H89f-9Y for ; Fri, 27 Jul 2012 05:40:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3C68321F84AF for ; Fri, 27 Jul 2012 05:40:12 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6C7EF22C46B; Fri, 27 Jul 2012 14:40:11 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4E82E4C024; Fri, 27 Jul 2012 14:40:11 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 27 Jul 2012 14:40:05 +0200 From: To: Wojciech Dec , Maoke Date: Fri, 27 Jul 2012 14:40:03 +0200 Thread-Topic: [Softwires] map-00: review on the mode 1:1 Thread-Index: Ac1r71G6HNMgiOVFQvuMM9yK/WD2bAAASCyA Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E679@PUEXCB1B.nanterre.francetelecom.fr> References: <1E83C752-9536-4409-B497-21C921CA8971@employees.org> <94C682931C08B048B7A8645303FDC9F36E4A17E397@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E4A17E679PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.27.113318 Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 12:40:14 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E4A17E679PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Woj, The argument you are raising applies also for (1) and (3): one can argue th= is justifies editing an RFC6333-bis to cover the per-subscriber state case = ;-) As I mentioned in my first message, MAP can be extended to cover the per-su= bscriber case at the cost of adding confusion by abandoning the "no state i= n the ISP network paradigm" not to mention the incompatibility with the tra= nslation mode (part of the MAP suite), etc. IMO, the issue is not technical. It is more a matter of rationalizing the s= olution space. Having the three deployment options listed below is IMHO a g= ood direction to take by the WG. Cheers, Med ________________________________ De : Wojciech Dec [mailto:wdec.ietf@gmail.com] Envoy=E9 : vendredi 27 juillet 2012 14:00 =C0 : Maoke Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires-wg Objet : Re: [Softwires] map-00: review on the mode 1:1 Med, 2) and 3) both require configuration and as has been amply discussed techn= ically there is no issue with per subscriber rules in 2) or optimization ap= plying to 3). As such, justifying three different solutions out of which tw= o can technically have the same amount of configuration state and are almos= t the same appears illogical. >From another perspective, defining a solution that by definition requires p= er subscriber configuration state and does not allow its optimization is hi= ghly questionable technically. Regards, Woj. On 26 July 2012 16:34, Maoke > wr= ote: 2012/7/26 > Dear Ole, all, For sure MAP spec can be updated to cover 1:1 mode but this brings more con= fusion for some people as this contradicts the "no state in ISP network" pa= radigm. I personally vote for limiting MAP to its initial scope rather than= trying to cover other deployment options. I see three main flavours which justifies having standalone specification d= ocuments: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP/4rd (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translate= d-ds-lite) These three flavours have been already sketched in Figure 7 of RFC6346 (see= http://tools.ietf.org/html/rfc6346#section-3.3.4). yes. i share this point. thanks, Med, for the clear explanation on the big = picture. - maoke Having standalone specifications for each of these flavours helps operators= to better target their suitable deployment model without being disturbed w= ith parameters and details not pertinent for their deployment context. Cheers, Med >-----Message d'origine----- >De : softwires-bounces@ietf.org >[mailto:softwires-bounces@ietf.org] De = la part de Ole Tr=F8an >Envoy=E9 : jeudi 26 juillet 2012 12:23 >=C0 : Lee, Yiu >Cc : Softwires-wg >Objet : Re: [Softwires] map-00: review on the mode 1:1 > >Yiu, > >> Set EA bits=3D0 only saves bits in v6 address and decouples >v4/v6 address >> dependency. It doesn't bring any new function compared to >embedding full >> v4 address in the EA-bit. However, the operation models of >EA-bit>0 or =3D0 >> are very different. By the way, this works only for MAP-E. I >fail to see >> why we want to include this in the base spec. > >what do you say in the spec if EA=3D0 and provisioned IPv4 >prefix length =3D 32. >the spec has to say something about this to be complete. > >cheers, >Ole > > >> >> Thanks, >> Yiu >> >> >> On 7/25/12 9:45 PM, "Satoru Matsushima" > >> wrote: >> >>> Hi Yiu, >>> >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>> >>>> Ole, >>>> >>>> Where can I get the formal definition of 1:1 mode? My >understanding of >>>> 1:1 >>>> refers to one public IPv4 address per subscriber but you refer very >>>> specific to decoupling IPv4 and IPv6 addresses. >>>> >>> >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >>> address in ea-bits is as a result of prefix allocation operation. >>> >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >>>> address >>>> information (EA bits > 0) in the CE IPv6 address to >achieve stateless. >>> >>> No, there was no such definition for EA-bits length restriction. >>> >>>> Now there is a new proposal to add a new feature to have the IPv4 >>>> information >>>> in the BR only. This change requires to provision >individual subscriber >>>> information to the BR (instead of aggregated information). >Benefit are >>>> saving bits and breaking v4 and v6 address dependency. >>> >>> There's no change from previous spec, to just clarify MAP, >as a stateless >>> solution, could naturally support most granular mapping rule in its >>> nature. >>> >>>> >>>> Questions to WG: >>>> Is it useful feature to be included in MAP? If not, why >and alternative? >>>> >>> >>> I believe that it does not make sense to restrict EA-len > >0 for both MAP >>> and 4rd. It does make sense that you see MAP as framework >of solutions >>> which covers specific 1:1 solution by the mapping algorithm. >>> >>> cheers, >>> --satoru >>> >>> >>>> Thanks, >>>> Yiu >>>> >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" > wrote: >>>> >>>>> Yiu, >>>>> >>>>>> I am not asking whether MAP supports 1:1 mode with no EA >bits or not. >>>>>> I >>>>>> am >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >>>>>> achieve >>>>>> 1:1 mode: >>>>>> >>>>>> "The EA bits can contain a full or part >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address case >>>>>> contains a Port-Set Identifier (PSID)." >>>>>> >>>>>> Why not use this instead? >>>>> >>>>> you can do either. >>>>> embedding a complete IPv4 address and PSID does require a >lot of IPv6 >>>>> space though. >>>>> e.g. /56 - 32 - 6 =3D /18 >>>>> >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>>> addressing >>>>> are independent. >>>>> >>>>> cheers, >>>>> Ole >>>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>> > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_94C682931C08B048B7A8645303FDC9F36E4A17E679PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Woj,
 
The argument you are raising applies also for= (1) and=20 (3): one can argue this justifies editing an RFC6333-bis to cover the=20 per-subscriber state case ;-)
 
As I mentioned in my first message, MAP can b= e=20 extended to cover the per-subscriber case at the cost of adding confusion=20 by abandoning the "no state in the ISP network paradigm" not to mentio= n the=20 incompatibility with the translation mode (part of the MAP suite),=20 etc.
 
IMO, the issue is not technical. It is more a= matter=20 of rationalizing the solution space. Having the three deployment o= ptions=20 listed below is IMHO a good direction to take by the=20 WG.
 
Cheers,
Med

De : Wojciech Dec=20 [mailto:wdec.ietf@gmail.com]
Envoy=E9 : vendredi 27 juill= et 2012=20 14:00
=C0 : Maoke
Cc : BOUCADAIR Mohamed=20 OLNC/NAD/TIP; Softwires-wg
Objet : Re: [Softwires] map-00:= =20 review on the mode 1:1

Med,

 2) and 3) both require configuration and as = has=20 been amply discussed technically there is no issue with per subscriber ru= les=20 in 2) or optimization applying to 3). As such, justifying three different= =20 solutions out of which two can technically have the same amount of=20 configuration state and are almost the same appears illogical.
From an= other=20 perspective, defining a solution that by definition requires per subscrib= er=20 configuration state and does not allow its optimization is highly questio= nable=20 technically.

Regards,
Woj.

On 26 July 2012 16:34, Maoke <= ;fibrib@gmail.com>= =20 wrote:


2012/7/26 <mohamed.boucadair@orange.com>

Dear Ole, all,

For sure MAP spec can be upda= ted=20 to cover 1:1 mode but this brings more confusion for some people as t= his=20 contradicts the "no state in ISP network" paradigm. I personally vote= for=20 limiting MAP to its initial scope rather than trying to cover other=20 deployment options.

I see three main flavours which justifies= =20 having standalone specification documents:

(1) Full stateful m= ode:=20 DS-Lite
(2) Full stateless mode: MAP/4rd
(3) Per-customer=20 state/binding mode: lw4o6=20 (draft-cui-softwire-b4-translated-ds-lite)

These three flavour= s=20 have been already sketched in Figure 7 of RFC6346 (see http://tools.ietf.org/html/rfc6346#section-3.3.4)= .

 
yes. i share this point. thanks, Med, for the clear explanation on= the=20 big picture. - maoke
 
Having standalone specifications for each of these= =20 flavours helps operators to better target their suitable deployment m= odel=20 without being disturbed with parameters and details not pertinent for= =20 their deployment context.

Cheers,
Med

>-----Messa= ge=20 d'origine-----
>De : softwires-bounces@ietf.org
>[mailto:softwires-bounces@ietf.org] De la part de Ole=20 Tr=F8an
>Envoy=E9 : jeudi 26 juillet 2012 12:23
>=C0 : Le= e,=20 Yiu
>Cc : Softwires-wg
>Objet : Re: [Softwires] map-00: r= eview=20 on the mode 1:1
>
>Yiu,
>
>> Set EA bits=3D0 only saves = bits in=20 v6 address and decouples
>v4/v6 address
>> dependency.= It=20 doesn't bring any new function compared to
>embedding=20 full
>> v4 address in the EA-bit. However, the operation mod= els=20 of
>EA-bit>0 or =3D0
>> are very different. By the = way,=20 this works only for MAP-E. I
>fail to see
>> why we wa= nt to=20 include this in the base spec.
>
>what do you say in the = spec=20 if EA=3D0 and provisioned IPv4
>prefix length =3D 32.
>th= e spec=20 has to say something about this to be=20 complete.
>
>cheers,
>Ole
>
>
>&g= t;
>>=20 Thanks,
>> Yiu
>>
>>
>> On 7/25/1= 2=20 9:45 PM, "Satoru Matsushima" <satoru.matsushima@gmail.com>
>>=20 wrote:
>>
>>> Hi Yiu,
>>>
>>= ;>=20 On 2012/07/26, at 4:08, Lee, Yiu=20 wrote:
>>>
>>>>=20 Ole,
>>>>
>>>> Where can I get the form= al=20 definition of 1:1 mode? My
>understanding of
>>>>= ;=20 1:1
>>>> refers to one public IPv4 address per subscri= ber=20 but you refer very
>>>> specific to decoupling IPv4 an= d=20 IPv6 addresses.
>>>>
>>>
>>> I= t=20 doesn't 1:1 in MAP and 4rd context, because embedding full=20 ipv4
>>> address in ea-bits is as a result of prefix=20 allocation operation.
>>>
>>>> Before MAP = was=20 accepted as WG item, MAP was proposed to embed IPv4
>>>&g= t;=20 address
>>>> information (EA bits > 0) in the CE IP= v6=20 address to
>achieve stateless.
>>>
>>> = No,=20 there was no such definition for EA-bits length=20 restriction.
>>>
>>>> Now there is a new=20 proposal to add a new feature to have the IPv4
>>>>=20 information
>>>> in the BR only. This change requires = to=20 provision
>individual subscriber
>>>> informatio= n to=20 the BR (instead of aggregated information).
>Benefit=20 are
>>>> saving bits and breaking v4 and v6 address=20 dependency.
>>>
>>> There's no change from=20 previous spec, to just clarify MAP,
>as a stateless
>>= >=20 solution, could naturally support most granular mapping rule in=20 its
>>>=20 nature.
>>>
>>>>
>>>> Quest= ions=20 to WG:
>>>> Is it useful feature to be included in MAP= ? If=20 not, why
>and=20 alternative?
>>>>
>>>
>>> I be= lieve=20 that it does not make sense to restrict EA-len >
>0 for both= =20 MAP
>>> and 4rd. It does make sense that you see MAP as=20 framework
>of solutions
>>> which covers specific 1= :1=20 solution by the mapping algorithm.
>>>
>>>=20 cheers,
>>>=20 --satoru
>>>
>>>
>>>>=20 Thanks,
>>>> Yiu
>>>>
>>>&g= t; On=20 7/25/12 2:40 PM, "Ole Tr=F8an" <otroan@employees.org>=20 wrote:
>>>>
>>>>>=20 Yiu,
>>>>>
>>>>>> I am not ask= ing=20 whether MAP supports 1:1 mode with no EA
>bits or=20 not.
>>>>>> I
>>>>>>=20 am
>>>>>> asking MAP allows to embed the 32-bit= =20 address in the EA bits to
>>>>>>=20 achieve
>>>>>> 1:1=20 mode:
>>>>>>
>>>>>> "The EA= bits=20 can contain a full or part
>>>>>> of an IPv4 pre= fix=20 or address, and in the shared IPv4 address=20 case
>>>>>> contains a Port-Set Identifier=20 (PSID)."
>>>>>>
>>>>>> Why = not=20 use this instead?
>>>>>
>>>>> you= can=20 do either.
>>>>> embedding a complete IPv4 address = and=20 PSID does require a
>lot of IPv6
>>>>> space= =20 though.
>>>>> e.g. /56 - 32 - 6 =3D=20 /18
>>>>>
>>>>> 1:1 mode is typic= ally=20 referred to a model where IPv4 and IPv6
>>>>>=20 addressing
>>>>> are=20 independent.
>>>>>
>>>>>=20 cheers,
>>>>>=20 Ole
>>>>>
>>>>=20 _______________________________________________
>>>>=20 Softwires mailing list
>>>> Softwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires>>>
>
>_____________________________________________= __
>Softwires=20 mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires>
_______________________________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


______________________= _________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
=

--_000_94C682931C08B048B7A8645303FDC9F36E4A17E679PUEXCB1Bnante_-- From wdec.ietf@gmail.com Fri Jul 27 05:44:03 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2866C21F8667 for ; Fri, 27 Jul 2012 05:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l83jR3fxQzzG for ; Fri, 27 Jul 2012 05:44:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 361C321F865A for ; Fri, 27 Jul 2012 05:44:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2814246vbb.31 for ; Fri, 27 Jul 2012 05:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tm5KEGLqh+PY5uXmmG3VtLosIf6QNPzEhMnfh4NSGlE=; b=X/fdkSbsM76GjWl/yCqKRziVd47sEag1FimcSD4TDl2YfO933rEhg9CCRxa2yUp7yc ztNxPV36aFe0MPDfLP8kezTOMOdGpyB6WSXpkDNjHfE0gFzuHVviQf7cN+VJYL+k2Lr3 /K1XZTWAP3Va1fUnsGJ1BnBRdZNHqq6kucY24dkdWUJ77xpo34VuCL80H/xC2D/np6eM wN2u3IKKTSEfp4KJOFxkk0+59ni9a+NSBKuqOcSJuVc/Xx6GkLFci12/OK9CMQ+Q2qLK G6Plb3nsZ3y8zIKVhL2bdX6M0dxvZ0BoxoDq1ueLuZ1oB1xh6V58lDUZSRM55iY6frQa a0Rw== MIME-Version: 1.0 Received: by 10.52.16.212 with SMTP id i20mr1971160vdd.118.1343393041689; Fri, 27 Jul 2012 05:44:01 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Fri, 27 Jul 2012 05:44:01 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 27 Jul 2012 14:44:01 +0200 Message-ID: From: Wojciech Dec To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=bcaec502d7700b2e0904c5cf118d Cc: "softwires@ietf.org" , softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 27 Jul 2012 12:44:03 -0000 --bcaec502d7700b2e0904c5cf118d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Med, the point is that the DS-Lite (CGN AFTR) solution is not necessary to be deployed for the multicast solution described here to work. As to how this ended up being charterd in Softwire I don't know and IMO it doesn't make much sense. Regards, Woj. On 27 July 2012 13:48, wrote: > Dear all, > > I really don't understand this issue. > It is even misplaced to have this comment at this stage, since this is a > document which has been adopted by the WG and the solution it specifies i= s > the same as the one reviewed by the WG prior to its adoption (i.e., since > April 2011). > > Anyway, below a tentative to explain the overall rationale: > > DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should b= e > first seen as an IP connectivity service. This service can be defined as > follows: > > * delivery of IPv4 connectivity over an IPv6-capable network. > * delivery of native IPv6 connectivity > * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 > address. > > The unicast portion of the service is defined in RFC6333 and is > implemented using a tunnel + CGN. > > The multicast portion of the service is defined in > draft-ietf-softwire-dslite-multicast. This portion of the service can be > defined as follows: > > * delivery of IPv4 multicast content using native IPv6 multicast > capabilities > * delivery of native IPv6 multicast content > > The solution proposed in draft-ietf-softwire-dslite-multicast is designed > to allow DS-Lite serviced customers be delivered IPv4 multicast services. > > A side note, I agree with Stig and Woj the proposed solution can be > generalized to cover any 4-6-4 scenario. This can be done easily by > updating the draft (abstract and introduction) to reflect the change of > scope of use cases. We didn't had the ambition to define a generic soluti= on > when we wrote this draft, we focused mainly on the DS-Lite context. If > there is no objection from the WG, we can implement that change. > > Cheers, > Med > > >-----Message d'origine----- > >De : softwire issue tracker [mailto:trac+softwire@tools.ietf.org] > >Envoy=E9 : vendredi 13 juillet 2012 23:55 > >=C0 : draft-ietf-softwire-dslite-multicast@tools.ietf.org; > >sarikaya@ieee.org > >Cc : softwires@ietf.org > >Objet : Re: [softwire] #10: Nothing in common with DS-Lite > > > >#10: Nothing in common with DS-Lite > > > >Changes (by sarikaya@.): > > > > * owner: sarikaya@. =3D> draft-ietf-softwire-dslite-multicast@. > > > > > >-- > >-------------------------+------------------------------------- > >------------ > > Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- > > Type: defect | multicast@. > > Priority: major | Status: new > >Component: dslite- | Milestone: milestone1 > > multicast | Version: 2.0 > > Severity: In WG Last | Resolution: > > Call | > > Keywords: tunneling | > >-------------------------+------------------------------------- > >------------ > > > >Ticket URL: > > > >softwire > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --bcaec502d7700b2e0904c5cf118d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Med,

the point is that the DS-Lite (CGN AFTR) solution is not necess= ary to be deployed for the multicast solution described here to work.
As= to how this ended up being charterd in Softwire I don't know and IMO i= t doesn't make much sense.

Regards,
Woj.

On 27 July 2012 13:4= 8, <mohamed.boucadair@orange.com> wrote:
Dear all,

I really don't understand this issue.
It is even misplaced to have this comment at this stage, since this is a do= cument which has been adopted by the WG and the solution it specifies is th= e same as the one reviewed by the WG prior to its adoption (i.e., since Apr= il 2011).

Anyway, below a tentative to explain the overall rationale:

DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be = first seen as an IP connectivity service. This service can be defined as fo= llows:

* delivery of IPv4 connectivity over an IPv6-capable network.
* delivery of native IPv6 connectivity
* DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 addr= ess.

The unicast portion of the service is defined in RFC6333 and is implemented= using a tunnel + CGN.

The multicast portion of the service is defined in draft-ietf-softwire-dsli= te-multicast. This portion of the service can be defined as follows:

* delivery of IPv4 multicast content using native IPv6 multicast capabiliti= es
* delivery of native IPv6 multicast content

The solution proposed in draft-ietf-softwire-dslite-multicast is designed t= o allow DS-Lite serviced customers be delivered IPv4 multicast services.
A side note, I agree with Stig and Woj the proposed solution can be general= ized to cover any 4-6-4 scenario. This can be done easily by updating the d= raft (abstract and introduction) to reflect the change of scope of use case= s. We didn't had the ambition to define a generic solution when we wrot= e this draft, we focused mainly on the DS-Lite context. If there is no obje= ction from the WG, we can implement that change.

Cheers,
Med

>-----Message d'origine-----
>De : softwire issue tracker [mailto:trac+softwire@tools.ietf.org]
>Envoy=E9 : vendredi 13 juillet 2012 23:55
>=C0 : draft-ietf-softwire-dslite-multicast@tools.ietf.org;
>sarikaya@ieee.org
>Cc : softwires@ietf.org
>Objet : Re: [softwire] #10: Nothing in common with DS-Lite
>
>#10: Nothing in common with DS-Lite
>
>Changes (by sarikaya@.):
>
> * owner: =A0sarikaya@. =3D> draft-ietf-softwire-dslite-multicast@.<= br> >
>
>--
>-------------------------+-------------------------------------
>------------
> Reporter: =A0sarikaya@. =A0 | =A0 =A0 =A0 Owner: =A0draft-ietf-softwir= e-dslite-
> =A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0multicast@.
> Priority: =A0major =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
>Component: =A0dslite- =A0 =A0 =A0| =A0 Milestone: =A0milestone1
> =A0multicast =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: =A02.0
> Severity: =A0In WG Last =A0 | =A0Resolution:
> =A0Call =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> Keywords: =A0tunneling =A0 =A0|
>-------------------------+-------------------------------------
>------------
>
>Ticket URL:
><http://trac.tools.ietf.org/wg/softwire/trac/tick= et/10#comment:1>
>softwire <http://tools.ietf.org/softwire/>
>
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--bcaec502d7700b2e0904c5cf118d-- From wdec.ietf@gmail.com Fri Jul 27 06:03:21 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B983421F869C for ; Fri, 27 Jul 2012 06:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS5CT9bzxGNS for ; Fri, 27 Jul 2012 06:03:20 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 555DC21F869A for ; Fri, 27 Jul 2012 06:03:20 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2795025vcb.31 for ; Fri, 27 Jul 2012 06:03: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=GxpkND3aukeJmq9ceLPoYpbmpp3/s8A5oX4T3AyLIAs=; b=tIEWrYjgvXo7x89xEUfqmtqhbZ/gyNRhF9JXRjaSCKtJ053dOfS7vktNBzAbbVXrR3 AAZNPXQtGUdxMQ0ZmXXVEXyxfc2M239YlWxw96D7838AVI+28yDfVQNBv6BsXdzaJq5H v19A8mIzW3oZ1mZcZ8JbsP9QVIovXYD5WE2twQuotomiUvKabFyiLv26jh6VG3dto7Pb wb+tC1fZVYwWsURJj3wSf6oqWasesSxV2qUHiCI/gIfPU5RqhIkiwJKwXfrc8ntHWmzH ++lixAPKoZGrCEqxpWKI7B2mci0bF2ZdW1b/ELm8/2elojHxk64kgmtZV+nrqLH+GoVm 6sSQ== MIME-Version: 1.0 Received: by 10.52.97.230 with SMTP id ed6mr2053473vdb.65.1343394198227; Fri, 27 Jul 2012 06:03:18 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Fri, 27 Jul 2012 06:03:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Jul 2012 15:03:18 +0200 Message-ID: From: Wojciech Dec To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=20cf307ac437fa8b5104c5cf55ac Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:03:21 -0000 --20cf307ac437fa8b5104c5cf55ac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ole's and Satoru's eaerlier replies on this thread described the "how", and even Maoke's earlier post on this thread acknowledged EA=3D0 with full IPv4 to be a " naturally established case of the MAP". EA=3D0 simply means that there isn't IPv4 (or PSID) info in the IPv6 prefix. In terms of your question: When the EA=3D0, the full v4 address is derived via DHCP (or other) configuration. If the operator wants to configure address sharing, then a PSID is also required to be configured. This is saying , " you have to have an IPv4 address, and besides that if you want address sharing, you have to configure a port range via a PSID", which is unlikely to be confusing to any operator who is interested in doing any of this. That said, even if it the draft can better articulate this use, (which draft-00 actually sought to do), that not being so is hardly grounds for having yet another solution and draft to deal with this use-case. In terms of causing operator confusion, that by far is more confusing. Thanks, Woj. On 27 July 2012 14:39, Lee, Yiu wrote: > Woj, > > I am confused. You said "given that EA=3D0 is already covered (eg embeddi= ng > of full IPv4 address, no address sharing, if not the other case)". If I > read the spec right, this is my understanding: If I want to embed full v4 > address in the CE v6 address, the v4 address will be embedded in the EA. = If > so, how would EA=3D0? > > "The EA bits encode the CE specific IPv4 > > address and port information. The EA bits can contain a full or part > of an IPv4 prefix or address, and in the shared IPv4 address case > contains a Port-Set Identifier (PSID)." > > > I prefer one solution vs. N solutions given that the one solution can > logically solve all problems and doesn't cause confusion. Consider we > agreed on including 1:1 MAP. When an operator deployed it, he had to ask = if > I want to share v4 addresses, should I put the v4 info in the EA or set > EA=3D0 and provision PSID? It will create unnecessary confusion. Simply p= ut I > am not "calling out for a "remove that part of the spec & complicate it" > case". My position is quite an opposite. I am calling out for "not adding > confusion to complicate a spec". > > In the end, it is up to WG to decide. > > Thanks, > Yiu > > From: Wojciech Dec > Date: Friday, July 27, 2012 8:06 AM > To: "Yiu L. LEE" > Cc: Ole Tr=F8an , Softwires-wg > > Subject: Re: [Softwires] map-00: review on the mode 1:1 > > > > On 26 July 2012 16:59, Lee, Yiu wrote: > >> Ole, >> >> IMHO the WG will need to decide whether EA=3D0 should be covered at all.= If >> not, then the draft could explicitly mention EA must be > 0 and must >> contain v4 information in the CE address. If the WG decided this needed = to >> be cover, I would recommend to have a new draft to cover it and leave EA= =3D0 >> undefined in the base draft. >> > > What are the technical arguments for making such a decision? > Furthermore, given that EA=3D0 is already covered (eg embedding of full I= Pv4 > address, no address sharing, if not the other case) you appear to be > calling out for a "remove that part of the spec & complicate it" case, ev= en > though not disputing the use-fullness of the use-case. Seems a sure way = to > get us from 1 solution to N solutions just for the sake of it. > > Thanks, > Woj. > >> >> Thanks, >> Yiu >> >> On 7/26/12 6:22 AM, "Ole Tr=F8an" wrote: >> >> >Yiu, >> > >> >> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 add= ress >> >> dependency. It doesn't bring any new function compared to embedding >> full >> >> v4 address in the EA-bit. However, the operation models of EA-bit>0 o= r >> >>=3D0 >> >> are very different. By the way, this works only for MAP-E. I fail to >> see >> >> why we want to include this in the base spec. >> > >> >what do you say in the spec if EA=3D0 and provisioned IPv4 prefix lengt= h =3D >> >32. >> >the spec has to say something about this to be complete. >> > >> >cheers, >> >Ole >> > >> > >> >> >> >> Thanks, >> >> Yiu >> >> >> >> >> >> On 7/25/12 9:45 PM, "Satoru Matsushima" >> >> wrote: >> >> >> >>> Hi Yiu, >> >>> >> >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >> >>> >> >>>> Ole, >> >>>> >> >>>> Where can I get the formal definition of 1:1 mode? My understanding >> of >> >>>> 1:1 >> >>>> refers to one public IPv4 address per subscriber but you refer very >> >>>> specific to decoupling IPv4 and IPv6 addresses. >> >>>> >> >>> >> >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >> >>> address in ea-bits is as a result of prefix allocation operation. >> >>> >> >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >> >>>> address >> >>>> information (EA bits > 0) in the CE IPv6 address to achieve >> stateless. >> >>> >> >>> No, there was no such definition for EA-bits length restriction. >> >>> >> >>>> Now there is a new proposal to add a new feature to have the IPv4 >> >>>> information >> >>>> in the BR only. This change requires to provision individual >> >>>>subscriber >> >>>> information to the BR (instead of aggregated information). Benefit >> are >> >>>> saving bits and breaking v4 and v6 address dependency. >> >>> >> >>> There's no change from previous spec, to just clarify MAP, as a >> >>>stateless >> >>> solution, could naturally support most granular mapping rule in its >> >>> nature. >> >>> >> >>>> >> >>>> Questions to WG: >> >>>> Is it useful feature to be included in MAP? If not, why and >> >>>>alternative? >> >>>> >> >>> >> >>> I believe that it does not make sense to restrict EA-len > 0 for bot= h >> >>>MAP >> >>> and 4rd. It does make sense that you see MAP as framework of solutio= ns >> >>> which covers specific 1:1 solution by the mapping algorithm. >> >>> >> >>> cheers, >> >>> --satoru >> >>> >> >>> >> >>>> Thanks, >> >>>> Yiu >> >>>> >> >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >> >>>> >> >>>>> Yiu, >> >>>>> >> >>>>>> I am not asking whether MAP supports 1:1 mode with no EA bits or >> >>>>>>not. >> >>>>>> I >> >>>>>> am >> >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >> >>>>>> achieve >> >>>>>> 1:1 mode: >> >>>>>> >> >>>>>> "The EA bits can contain a full or part >> >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address case >> >>>>>> contains a Port-Set Identifier (PSID)." >> >>>>>> >> >>>>>> Why not use this instead? >> >>>>> >> >>>>> you can do either. >> >>>>> embedding a complete IPv4 address and PSID does require a lot of >> IPv6 >> >>>>> space though. >> >>>>> e.g. /56 - 32 - 6 =3D /18 >> >>>>> >> >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >> >>>>> addressing >> >>>>> are independent. >> >>>>> >> >>>>> cheers, >> >>>>> Ole >> >>>>> >> >>>> _______________________________________________ >> >>>> Softwires mailing list >> >>>> Softwires@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/softwires >> >>> >> > >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --20cf307ac437fa8b5104c5cf55ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ole's and Satoru's eaerlier replies on this thread described the &q= uot;how", and even Maoke's earlier post on this thread acknowledge= d EA=3D0 with full IPv4 to be a " naturally established case of the MA= P". EA=3D0 simply means that there isn't IPv4 (or PSID)=A0 info in= the IPv6 prefix.

In terms of your question: When the EA=3D0, the full v4 address is deri= ved via DHCP (or other) configuration. If the operator wants to configure a= ddress sharing, then a PSID is also required to be configured. This is sayi= ng , " you have to have an IPv4 address, and besides that if you want = address sharing, you have to configure a port range via a PSID", which= is unlikely to be confusing to any operator who is interested in doing any= of this.

That said, even if it the draft can better articulate this use, (which = draft-00 actually sought to do), that not being so is hardly grounds for ha= ving yet another solution and draft to deal with this use-case. In terms of= causing operator confusion, that by far is more confusing.

Thanks,
Woj.


On 27 July 2012 1= 4:39, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Woj,

I am confused. You said "giv= en that EA=3D0 is already covered (eg embedding of full IPv4 address, no ad= dress sharing, if not the other case)". If I read the spec right, this= is my understanding:=A0If I want to embed full v4 address in the CE v6 add= ress, the v4 address will be embedded in the EA. If so, how would EA=3D0?= =A0

"The EA bits encode the CE specific IPv4
   addre=
ss and port information.  The EA bits can contain a full or part
   of an IPv4 prefix or address, and in the shared IPv4 address case
   contains a Port-Set Identifier (PSID)."

I = prefer one solution vs. N solutions given that the one solution can logical= ly solve all problems and doesn't cause confusion. Consider we agreed o= n including 1:1 MAP. When an operator deployed it, he had to ask if I want = to share v4 addresses, should I put the v4 info in the EA or set EA=3D0 and= provision PSID? It will create unnecessary confusion. Simply put I am not = "calling out for a "remove that part of the spec & complicate= it" case". My position is quite an opposite. I am calling out fo= r "not adding confusion to complicate a spec".

In the end, it is up to WG to decide.

Thanks,
Yiu

From: Wojciech Dec <wdec.ietf@gmail.com>Date: Friday, July 27, 2012 8:06= AM
To: "Yiu L. LEE" <yiu_lee@cable.c= omcast.com>
Cc: Ole Tr= =F8an <otroan@= employees.org>, Softwires-wg <softwires@ietf.org>

Subject: Re: [Softwires] map-0= 0: review on the mode 1:1


=

On 26 July 2012 16:59, Lee= , Yiu <Yiu_Lee@cable.comcast.com> wrote:
Ole,

IMHO the WG will need to decide whether EA=3D0 should be covered at all. If=
not, then the draft could explicitly mention EA must be > 0 and must
= contain v4 information in the CE address. If the WG decided this needed to<= br> be cover, I would recommend to have a new draft to cover it and leave EA=3D= 0
undefined in the base draft.

What are the technical arguments for making such a decision?
Furthermore, given that EA=3D0 is already covered (eg embedding of full IPv= 4 address, no address sharing, if not the other case) you appear to be call= ing out for a "remove that part of the spec & complicate it" = case, even though not disputing the use-fullness of the use-case.=A0 Seems a sure way to get us from 1 solution to N soluti= ons just for the sake of it.

Thanks,
Woj.

Thanks,
Yiu

On 7/26/12 6:22 AM, "Ole Tr=F8an" <otroan@employees.org> wrote:

>Yiu,
>
>> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 = address
>> dependency. It doesn't bring any new function compared to embe= dding full
>> v4 address in the EA-bit. However, the operation models of EA-bit&= gt;0 or
>>=3D0
>> are very different. By the way, this works only for MAP-E. I fail = to see
>> why we want to include this in the base spec.
>
>what do you say in the spec if EA=3D0 and provisioned IPv4 prefix lengt= h =3D
>32.
>the spec has to say something about this to be complete.
>
>cheers,
>Ole
>
>
>>
>> Thanks,
>> Yiu
>>
>>
>> On 7/25/12 9:45 PM, "Satoru Matsushima" <satoru.matsushima@gmai= l.com>
>> wrote:
>>
>>> Hi Yiu,
>>>
>>> On 2012/07/26, at 4:08, Lee, Yiu wrote:
>>>
>>>> Ole,
>>>>
>>>> Where can I get the formal definition of 1:1 mode? My unde= rstanding of
>>>> 1:1
>>>> refers to one public IPv4 address per subscriber but you r= efer very
>>>> specific to decoupling IPv4 and IPv6 addresses.
>>>>
>>>
>>> It doesn't 1:1 in MAP and 4rd context, because embedding f= ull ipv4
>>> address in ea-bits is as a result of prefix allocation operati= on.
>>>
>>>> Before MAP was accepted as WG item, MAP was proposed to em= bed IPv4
>>>> address
>>>> information (EA bits > 0) in the CE IPv6 address to ach= ieve stateless.
>>>
>>> No, there was no such definition for EA-bits length restrictio= n.
>>>
>>>> Now there is a new proposal to add a new feature to have t= he IPv4
>>>> information
>>>> in the BR only. This change requires to provision individu= al
>>>>subscriber
>>>> information to the BR (instead of aggregated information).= Benefit are
>>>> saving bits and breaking v4 and v6 address dependency.
= >>>
>>> There's no change from previous spec, to just clarify MAP,= as a
>>>stateless
>>> solution, could naturally support most granular mapping rule i= n its
>>> nature.
>>>
>>>>
>>>> Questions to WG:
>>>> Is it useful feature to be included in MAP? If not, why an= d
>>>>alternative?
>>>>
>>>
>>> I believe that it does not make sense to restrict EA-len > = 0 for both
>>>MAP
>>> and 4rd. It does make sense that you see MAP as framework of s= olutions
>>> which covers specific 1:1 solution by the mapping algorithm. >>>
>>> cheers,
>>> --satoru
>>>
>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" <otroan@employees.org>= ; wrote:
>>>>
>>>>> Yiu,
>>>>>
>>>>>> I am not asking whether MAP supports 1:1 mode with= no EA bits or
>>>>>>not.
>>>>>> I
>>>>>> am
>>>>>> asking MAP allows to embed the 32-bit address in t= he EA bits to
>>>>>> achieve
>>>>>> 1:1 mode:
>>>>>>
>>>>>> "The EA bits can contain a full or part
>>>>>> of an IPv4 prefix or address, and in the shared IP= v4 address case
>>>>>> contains a Port-Set Identifier (PSID)."
>>>>>>
>>>>>> Why not use this instead?
>>>>>
>>>>> you can do either.
>>>>> embedding a complete IPv4 address and PSID does requir= e a lot of IPv6
>>>>> space though.
>>>>> e.g. /56 - 32 - 6 =3D /18
>>>>>
>>>>> 1:1 mode is typically referred to a model where IPv4 a= nd IPv6
>>>>> addressing
>>>>> are independent.
>>>>>
>>>>> cheers,
>>>>> Ole
>>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> So= ftwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>

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



--20cf307ac437fa8b5104c5cf55ac-- From mohamed.boucadair@orange.com Fri Jul 27 06:15:06 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342B021F84F1 for ; Fri, 27 Jul 2012 06:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fI1SRhkipMs for ; Fri, 27 Jul 2012 06:15:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D240121F84E1 for ; Fri, 27 Jul 2012 06:15:04 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 147862641C1; Fri, 27 Jul 2012 15:15:04 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id DFD5727C057; Fri, 27 Jul 2012 15:15:03 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 27 Jul 2012 15:14:57 +0200 From: To: Wojciech Dec Date: Fri, 27 Jul 2012 15:14:56 +0200 Thread-Topic: [Softwires] [softwire] #10: Nothing in common with DS-Lite Thread-Index: Ac1r9Xy6BKATFcJGS4mrIWlRaStEQwAA3f/w Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E6A1@PUEXCB1B.nanterre.francetelecom.fr> References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E4A17E6A1PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.27.113318 Cc: "softwires@ietf.org" , softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 27 Jul 2012 13:15:06 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E4A17E6A1PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Yes, the CGN is not required. This design choice is motivated in the draft = (read the Introduction text). What is the issue then? If you are saying this is a generic solution and it does not apply only to = ds-lite, this point is taken (see the note below). Cheers, Med ________________________________ De : Wojciech Dec [mailto:wdec.ietf@gmail.com] Envoy=E9 : vendredi 27 juillet 2012 14:44 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multicast@tools.iet= f.org; sarikaya@ieee.org; softwires@ietf.org Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite Med, the point is that the DS-Lite (CGN AFTR) solution is not necessary to be de= ployed for the multicast solution described here to work. As to how this ended up being charterd in Softwire I don't know and IMO it = doesn't make much sense. Regards, Woj. On 27 July 2012 13:48, > wrote: Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a do= cument which has been adopted by the WG and the solution it specifies is th= e same as the one reviewed by the WG prior to its adoption (i.e., since Apr= il 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be = first seen as an IP connectivity service. This service can be defined as fo= llows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 addr= ess. The unicast portion of the service is defined in RFC6333 and is implemented= using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dsli= te-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabiliti= es * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed t= o allow DS-Lite serviced customers be delivered IPv4 multicast services. A side note, I agree with Stig and Woj the proposed solution can be general= ized to cover any 4-6-4 scenario. This can be done easily by updating the d= raft (abstract and introduction) to reflect the change of scope of use case= s. We didn't had the ambition to define a generic solution when we wrote th= is draft, we focused mainly on the DS-Lite context. If there is no objectio= n from the WG, we can implement that change. Cheers, Med >-----Message d'origine----- >De : softwire issue tracker [mailto:trac+softwire@tools.ietf.org] >Envoy=E9 : vendredi 13 juillet 2012 23:55 >=C0 : draft-ietf-softwire-dslite-multicast@tools.ietf.org; >sarikaya@ieee.org >Cc : softwires@ietf.org >Objet : Re: [softwire] #10: Nothing in common with DS-Lite > >#10: Nothing in common with DS-Lite > >Changes (by sarikaya@.): > > * owner: sarikaya@. =3D> draft-ietf-softwire-dslite-multicast@. > > >-- >-------------------------+------------------------------------- >------------ > Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- > Type: defect | multicast@. > Priority: major | Status: new >Component: dslite- | Milestone: milestone1 > multicast | Version: 2.0 > Severity: In WG Last | Resolution: > Call | > Keywords: tunneling | >-------------------------+------------------------------------- >------------ > >Ticket URL: > >softwire > > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_94C682931C08B048B7A8645303FDC9F36E4A17E6A1PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Re-,
 
Yes, the CGN is not required. This design cho= ice is=20 motivated in the draft (read the Introduction text).
 
What is the issue then?
 
If you are saying this is a generic solution = and it=20 does not apply only to ds-lite, this point is taken (see the note below).=20
 
Cheers,
Med

De : Wojciech Dec=20 [mailto:wdec.ietf@gmail.com]
Envoy=E9 : vendredi 27 juill= et 2012=20 14:44
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc := =20 softwire issue tracker; draft-ietf-softwire-dslite-multicast@tools.ietf.o= rg;=20 sarikaya@ieee.org; softwires@ietf.org
Objet : Re: [Softwir= es]=20 [softwire] #10: Nothing in common with DS-Lite

Med,

the point is that the DS-Lite (CGN AFTR) solution = is=20 not necessary to be deployed for the multicast solution described here to= =20 work.
As to how this ended up being charterd in Softwire I don't know = and=20 IMO it doesn't make much sense.

Regards,
Woj.

On 27 July 2012 13:48, <mohamed.boucadair@orange.com> wrote:
Dear all,

I really don't understand this=20 issue.
It is even misplaced to have this comment at this stage, sinc= e=20 this is a document which has been adopted by the WG and the solution it= =20 specifies is the same as the one reviewed by the WG prior to its adopti= on=20 (i.e., since April 2011).

Anyway, below a tentative to explain t= he=20 overall rationale:

DS-Lite model can not be reduced to a CGN/AFT= R +=20 tunnel. DS-Lite should be first seen as an IP connectivity service. Thi= s=20 service can be defined as follows:

* delivery of IPv4 connectivi= ty=20 over an IPv6-capable network.
* delivery of native IPv6 connectivity=
*=20 DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4=20 address.

The unicast portion of the service is defined in RFC633= 3 and=20 is implemented using a tunnel + CGN.

The multicast portion of th= e=20 service is defined in draft-ietf-softwire-dslite-multicast. This portio= n of=20 the service can be defined as follows:

* delivery of IPv4 multic= ast=20 content using native IPv6 multicast capabilities
* delivery of nativ= e=20 IPv6 multicast content

The solution proposed in=20 draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite servi= ced=20 customers be delivered IPv4 multicast services.

A side note, I a= gree=20 with Stig and Woj the proposed solution can be generalized to cover any= =20 4-6-4 scenario. This can be done easily by updating the draft (abstract= and=20 introduction) to reflect the change of scope of use cases. We didn't ha= d the=20 ambition to define a generic solution when we wrote this draft, we focu= sed=20 mainly on the DS-Lite context. If there is no objection from the WG, we= can=20 implement that change.

Cheers,
Med

>-----Message=20 d'origine-----
>De : softwire issue tracker [mailto:trac+softwire@tools.ietf= .org]
>Envoy=E9=20 : vendredi 13 juillet 2012 23:55
>=C0 : dra= ft-ietf-softwire-dslite-multicast@tools.ietf.org;
>sarikaya@ieee.org
>Cc : softwires@ietf.org
>Objet = : Re:=20 [softwire] #10: Nothing in common with DS-Lite
>
>#10: Noth= ing=20 in common with DS-Lite
>
>Changes (by=20 sarikaya@.):
>
> * owner:  sarikaya@. =3D>=20 draft-ietf-softwire-dslite-multicast@.
>
>
>--
>= ;-------------------------+-------------------------------------
>---= ---------
>=20 Reporter:  sarikaya@.   |       Owner:=20  draft-ietf-softwire-dslite-
>     Type:  def= ect=20       |  multicast@.
> Priority:  major= =20        |      Status:=20  new
>Component:  dslite-      |  = =20 Milestone:  milestone1
>  multicast      = ;=20        |     Version:  2.0
>=20 Severity:  In WG Last   |  Resolution:
>  Cal= l=20                   |
>= ;=20 Keywords:  tunneling  =20  |
>-------------------------+------------------------------= -------
>------------
>
>Ticket=20 URL:
><http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#c= omment:1>
>softwire=20 <http://tools.ietf.org/softwire/>
>
>=
_______________________________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
=

--_000_94C682931C08B048B7A8645303FDC9F36E4A17E6A1PUEXCB1Bnante_-- From wdec.ietf@gmail.com Fri Jul 27 06:19:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB3421F869A for ; Fri, 27 Jul 2012 06:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6hUs+2Dz6Tk for ; Fri, 27 Jul 2012 06:19:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56CEF21F8694 for ; Fri, 27 Jul 2012 06:19:33 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2850467vbb.31 for ; Fri, 27 Jul 2012 06:19:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iJ0hh32tSVHgfeMUXZ9/Iq8BNpcgaQY3h07VSM6fHq0=; b=uVOIROvysyzIfSxMrfgu577rfZi4Gi+rO/PBt/D6W0AVIZ60PIEhHFQZdusEJircjm eVKys3APDvdE6sDASNqFTfHK/jCUOtsSbKNpdrD7VR6ghbT7inXdLIoXhadjMp++1Ns1 OhJGxfUPkuvAd6K3brTTDS+BUp1GSL8LNWPIgtZXSjx8W8Je1ePjLUKy+larKoerXRVN iWxTnJW2cVAqXrAUoo5+fgq9mgi1p7sLSDtP6A02letovirOl+YA2arDvhBHQH/3CRae 2ZQY6Es8t9967BqOUeKyEFQJABUPfYib72r27TyID6T4Gp4YRlhPjYRB4q6hVB6KAhUx P/Cg== MIME-Version: 1.0 Received: by 10.220.115.81 with SMTP id h17mr2317620vcq.66.1343395170194; Fri, 27 Jul 2012 06:19:30 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Fri, 27 Jul 2012 06:19:30 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E6A1@PUEXCB1B.nanterre.francetelecom.fr> References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E4A17E6A1@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 27 Jul 2012 15:19:30 +0200 Message-ID: From: Wojciech Dec To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=f46d0438944de996e504c5cf8feb Cc: "softwires@ietf.org" , softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 27 Jul 2012 13:19:34 -0000 --f46d0438944de996e504c5cf8feb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27 July 2012 15:14, wrote: > ** > Re-, > > Yes, the CGN is not required. This design choice is motivated in the draf= t > (read the Introduction text). > > What is the issue then? > > If you are saying this is a generic solution and it does not apply only t= o > ds-lite, this point is taken (see the note below > Well, so what's not clear about the issue? You appear to recognize it. -Woj. > ). > > Cheers, > Med > > ------------------------------ > *De :* Wojciech Dec [mailto:wdec.ietf@gmail.com] > *Envoy=E9 :* vendredi 27 juillet 2012 14:44 > *=C0 :* BOUCADAIR Mohamed OLNC/NAD/TIP > *Cc :* softwire issue tracker; > draft-ietf-softwire-dslite-multicast@tools.ietf.org; sarikaya@ieee.org; > softwires@ietf.org > *Objet :* Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite > > Med, > > the point is that the DS-Lite (CGN AFTR) solution is not necessary to be > deployed for the multicast solution described here to work. > As to how this ended up being charterd in Softwire I don't know and IMO i= t > doesn't make much sense. > > Regards, > Woj. > > On 27 July 2012 13:48, wrote: > >> Dear all, >> >> I really don't understand this issue. >> It is even misplaced to have this comment at this stage, since this is a >> document which has been adopted by the WG and the solution it specifies = is >> the same as the one reviewed by the WG prior to its adoption (i.e., sinc= e >> April 2011). >> >> Anyway, below a tentative to explain the overall rationale: >> >> DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should >> be first seen as an IP connectivity service. This service can be defined= as >> follows: >> >> * delivery of IPv4 connectivity over an IPv6-capable network. >> * delivery of native IPv6 connectivity >> * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 >> address. >> >> The unicast portion of the service is defined in RFC6333 and is >> implemented using a tunnel + CGN. >> >> The multicast portion of the service is defined in >> draft-ietf-softwire-dslite-multicast. This portion of the service can be >> defined as follows: >> >> * delivery of IPv4 multicast content using native IPv6 multicast >> capabilities >> * delivery of native IPv6 multicast content >> >> The solution proposed in draft-ietf-softwire-dslite-multicast is designe= d >> to allow DS-Lite serviced customers be delivered IPv4 multicast services= . >> >> A side note, I agree with Stig and Woj the proposed solution can be >> generalized to cover any 4-6-4 scenario. This can be done easily by >> updating the draft (abstract and introduction) to reflect the change of >> scope of use cases. We didn't had the ambition to define a generic solut= ion >> when we wrote this draft, we focused mainly on the DS-Lite context. If >> there is no objection from the WG, we can implement that change. >> >> Cheers, >> Med >> >> >-----Message d'origine----- >> >De : softwire issue tracker [mailto:trac+softwire@tools.ietf.org] >> >Envoy=E9 : vendredi 13 juillet 2012 23:55 >> >=C0 : draft-ietf-softwire-dslite-multicast@tools.ietf.org; >> >sarikaya@ieee.org >> >Cc : softwires@ietf.org >> >Objet : Re: [softwire] #10: Nothing in common with DS-Lite >> > >> >#10: Nothing in common with DS-Lite >> > >> >Changes (by sarikaya@.): >> > >> > * owner: sarikaya@. =3D> draft-ietf-softwire-dslite-multicast@. >> > >> > >> >-- >> >-------------------------+------------------------------------- >> >------------ >> > Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- >> > Type: defect | multicast@. >> > Priority: major | Status: new >> >Component: dslite- | Milestone: milestone1 >> > multicast | Version: 2.0 >> > Severity: In WG Last | Resolution: >> > Call | >> > Keywords: tunneling | >> >-------------------------+------------------------------------- >> >------------ >> > >> >Ticket URL: >> > >> >softwire >> > >> > >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > --f46d0438944de996e504c5cf8feb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 27 July 2012 15:14, <moh= amed.boucadair@orange.com> wrote:
Re-,
=A0
Yes, the CGN is not required. This design choice is=20 motivated in the draft (read the Introduction text).
=A0
What is the issue then?
=A0
If you are saying this is a generic solution and it=20 does not apply only to ds-lite, this point is taken (see the note below

Well, so what's not clear a= bout the issue? You appear to recognize it.

-Woj.
).=20
=A0
Cheers,
Med

De=A0: Wojciech Dec=20 [mailto:wdec.iet= f@gmail.com]
Envoy=E9=A0: vendredi 27 juillet 2012=20 14:44
=C0=A0: BOUCADAIR Mohamed OLNC/NAD/TIP
Cc=A0:= =20 softwire issue tracker; draft-ietf-softwire-dslite-multicas= t@tools.ietf.org;=20 sarikaya@ieee.org<= /a>; softwires@ietf= .org
Objet=A0: Re: [Softwires]=20 [softwire] #10: Nothing in common with DS-Lite

<= div class=3D"h5">
Med,

the point is that the DS-Lite (CGN AFTR) solution = is=20 not necessary to be deployed for the multicast solution described here to= =20 work.
As to how this ended up being charterd in Softwire I don't k= now and=20 IMO it doesn't make much sense.

Regards,
Woj.

On 27 July 2012 13:48, <<= a href=3D"mailto:mohamed.boucadair@orange.com" target=3D"_blank">mohamed.bo= ucadair@orange.com> wrote:
Dear all,

I really don't= understand this=20 issue.
It is even misplaced to have this comment at this stage, sinc= e=20 this is a document which has been adopted by the WG and the solution it= =20 specifies is the same as the one reviewed by the WG prior to its adopti= on=20 (i.e., since April 2011).

Anyway, below a tentative to explain t= he=20 overall rationale:

DS-Lite model can not be reduced to a CGN/AFT= R +=20 tunnel. DS-Lite should be first seen as an IP connectivity service. Thi= s=20 service can be defined as follows:

* delivery of IPv4 connectivi= ty=20 over an IPv6-capable network.
* delivery of native IPv6 connectivity=
*=20 DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4=20 address.

The unicast portion of the service is defined in RFC633= 3 and=20 is implemented using a tunnel + CGN.

The multicast portion of th= e=20 service is defined in draft-ietf-softwire-dslite-multicast. This portio= n of=20 the service can be defined as follows:

* delivery of IPv4 multic= ast=20 content using native IPv6 multicast capabilities
* delivery of nativ= e=20 IPv6 multicast content

The solution proposed in=20 draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite servi= ced=20 customers be delivered IPv4 multicast services.

A side note, I a= gree=20 with Stig and Woj the proposed solution can be generalized to cover any= =20 4-6-4 scenario. This can be done easily by updating the draft (abstract= and=20 introduction) to reflect the change of scope of use cases. We didn'= t had the=20 ambition to define a generic solution when we wrote this draft, we focu= sed=20 mainly on the DS-Lite context. If there is no objection from the WG, we= can=20 implement that change.

Cheers,
Med

>-----Message=20 d'origine-----
>De : softwire issue tracker [mailto:trac+softwire@= tools.ietf.org]
>Envoy=E9=20 : vendredi 13 juillet 2012 23:55
>=C0 : draft-ietf-= softwire-dslite-multicast@tools.ietf.org;
>sarikaya@ieee.org
>Cc : softwires@= ietf.org
>Objet : Re:=20 [softwire] #10: Nothing in common with DS-Lite
>
>#10: Noth= ing=20 in common with DS-Lite
>
>Changes (by=20 sarikaya@.):
>
> * owner: =A0sarikaya@. =3D>=20 draft-ietf-softwire-dslite-multicast@.
>
>
>--
>= ;-------------------------+-------------------------------------
>---= ---------
>=20 Reporter: =A0sarikaya@. =A0 | =A0 =A0 =A0 Owner:=20 =A0draft-ietf-softwire-dslite-
> =A0 =A0 Type: =A0defect=20 =A0 =A0 =A0 | =A0multicast@.
> Priority: =A0major=20 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status:=20 =A0new
>Component: =A0dslite- =A0 =A0 =A0| =A0=20 Milestone: =A0milestone1
> =A0multicast =A0 =A0 =A0=20 =A0 =A0 =A0 =A0| =A0 =A0 Version: =A02.0
>=20 Severity: =A0In WG Last =A0 | =A0Resolution:
> =A0Call=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>=20 Keywords: =A0tunneling =A0=20 =A0|
>-------------------------+---------------------------------= ----
>------------
>
>Ticket=20 URL:
><http://trac.tools.ietf.org/wg/softwi= re/trac/ticket/10#comment:1>
>softwire=20 <http:= //tools.ietf.org/softwire/>
>
>
_____________________= __________________________
Softwires=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwir= es


--f46d0438944de996e504c5cf8feb-- From bingxuere@gmail.com Fri Jul 27 06:29:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7682A21F8691 for ; Fri, 27 Jul 2012 06:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9VI2B5esRcy for ; Fri, 27 Jul 2012 06:29:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E727621F8688 for ; Fri, 27 Jul 2012 06:29:27 -0700 (PDT) Received: by yhq56 with SMTP id 56so3456394yhq.31 for ; Fri, 27 Jul 2012 06:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vhmUwe9Tm4tJFA4vLmY2LdaTl79nH401Kn3RuihA0fQ=; b=yZTdsFOABwAQa/bJ8PN62vw0xw4NfYHangm5vV/kVVo5tlIyyaGKVaNyqsrfRld4Tx aGZkxpcLlq/u9KO0qw3aaAWgK4TnTdrF6ZGaogAG5k05qSfsmiyo41zJxQViRrfc1XSZ kuIvhqnGxWMECFTAQsVSX9OqVddTqbP9S3XjzP+ExfpKG5LVZKl00BAbSN7I/hS/kVu/ u+ok4qSXsPGAb5Rrr01r/fZJXyerxBLhrsbd8sVeBoIk8lsHHFBmFB3+y3Ts8Svqmuxo az88rTBQ1d98482ySxSUl6p9T857ZfuYsHXorslXjRoUqelD2AabnxFs+SpraIWnweBd Uwcg== Received: by 10.42.146.6 with SMTP id h6mr1506147icv.53.1343395766768; Fri, 27 Jul 2012 06:29:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Fri, 27 Jul 2012 06:28:46 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Fri, 27 Jul 2012 21:28:46 +0800 Message-ID: To: Wojciech Dec Content-Type: multipart/alternative; boundary=90e6ba6e871678941604c5cfb35b Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:29:29 -0000 --90e6ba6e871678941604c5cfb35b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Woj, According to your description, it is clear that the way to deal with EA=3D0 is quite different with EA>0. Mixing them together will not only make MAP losing the initial "no state in the ISP network paradigm" spirit, but also make MAP a lot more complex and confusing. Actually, the use case for EA=3D0 and EA>0 stems from different requirement= s, it is nature to treat them with seperately. Best wishes Qiong On Fri, Jul 27, 2012 at 9:03 PM, Wojciech Dec wrote: > Ole's and Satoru's eaerlier replies on this thread described the "how", > and even Maoke's earlier post on this thread acknowledged EA=3D0 with ful= l > IPv4 to be a " naturally established case of the MAP". EA=3D0 simply mean= s > that there isn't IPv4 (or PSID) info in the IPv6 prefix. > > In terms of your question: When the EA=3D0, the full v4 address is derive= d > via DHCP (or other) configuration. If the operator wants to configure > address sharing, then a PSID is also required to be configured. This is > saying , " you have to have an IPv4 address, and besides that if you want > address sharing, you have to configure a port range via a PSID", which is > unlikely to be confusing to any operator who is interested in doing any o= f > this. > > That said, even if it the draft can better articulate this use, (which > draft-00 actually sought to do), that not being so is hardly grounds for > having yet another solution and draft to deal with this use-case. In term= s > of causing operator confusion, that by far is more confusing. > > Thanks, > Woj. > > > > On 27 July 2012 14:39, Lee, Yiu wrote: > >> Woj, >> >> I am confused. You said "given that EA=3D0 is already covered (eg embedd= ing >> of full IPv4 address, no address sharing, if not the other case)". If I >> read the spec right, this is my understanding: If I want to embed full v= 4 >> address in the CE v6 address, the v4 address will be embedded in the EA.= If >> so, how would EA=3D0? >> >> "The EA bits encode the CE specific IPv4 >> >> address and port information. The EA bits can contain a full or part >> of an IPv4 prefix or address, and in the shared IPv4 address case >> contains a Port-Set Identifier (PSID)." >> >> >> I prefer one solution vs. N solutions given that the one solution can >> logically solve all problems and doesn't cause confusion. Consider we >> agreed on including 1:1 MAP. When an operator deployed it, he had to ask= if >> I want to share v4 addresses, should I put the v4 info in the EA or set >> EA=3D0 and provision PSID? It will create unnecessary confusion. Simply = put I >> am not "calling out for a "remove that part of the spec & complicate it" >> case". My position is quite an opposite. I am calling out for "not addin= g >> confusion to complicate a spec". >> >> In the end, it is up to WG to decide. >> >> Thanks, >> Yiu >> >> From: Wojciech Dec >> Date: Friday, July 27, 2012 8:06 AM >> To: "Yiu L. LEE" >> Cc: Ole Tr=C3=B8an , Softwires-wg >> >> Subject: Re: [Softwires] map-00: review on the mode 1:1 >> >> >> >> On 26 July 2012 16:59, Lee, Yiu wrote: >> >>> Ole, >>> >>> IMHO the WG will need to decide whether EA=3D0 should be covered at all= . If >>> not, then the draft could explicitly mention EA must be > 0 and must >>> contain v4 information in the CE address. If the WG decided this needed >>> to >>> be cover, I would recommend to have a new draft to cover it and leave >>> EA=3D0 >>> undefined in the base draft. >>> >> >> What are the technical arguments for making such a decision? >> Furthermore, given that EA=3D0 is already covered (eg embedding of full >> IPv4 address, no address sharing, if not the other case) you appear to b= e >> calling out for a "remove that part of the spec & complicate it" case, e= ven >> though not disputing the use-fullness of the use-case. Seems a sure way= to >> get us from 1 solution to N solutions just for the sake of it. >> >> Thanks, >> Woj. >> >>> >>> Thanks, >>> Yiu >>> >>> On 7/26/12 6:22 AM, "Ole Tr=C3=B8an" wrote: >>> >>> >Yiu, >>> > >>> >> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 >>> address >>> >> dependency. It doesn't bring any new function compared to embedding >>> full >>> >> v4 address in the EA-bit. However, the operation models of EA-bit>0 = or >>> >>=3D0 >>> >> are very different. By the way, this works only for MAP-E. I fail to >>> see >>> >> why we want to include this in the base spec. >>> > >>> >what do you say in the spec if EA=3D0 and provisioned IPv4 prefix leng= th =3D >>> >32. >>> >the spec has to say something about this to be complete. >>> > >>> >cheers, >>> >Ole >>> > >>> > >>> >> >>> >> Thanks, >>> >> Yiu >>> >> >>> >> >>> >> On 7/25/12 9:45 PM, "Satoru Matsushima" >>> >> wrote: >>> >> >>> >>> Hi Yiu, >>> >>> >>> >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>> >>> >>> >>>> Ole, >>> >>>> >>> >>>> Where can I get the formal definition of 1:1 mode? My understandin= g >>> of >>> >>>> 1:1 >>> >>>> refers to one public IPv4 address per subscriber but you refer ver= y >>> >>>> specific to decoupling IPv4 and IPv6 addresses. >>> >>>> >>> >>> >>> >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >>> >>> address in ea-bits is as a result of prefix allocation operation. >>> >>> >>> >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv4 >>> >>>> address >>> >>>> information (EA bits > 0) in the CE IPv6 address to achieve >>> stateless. >>> >>> >>> >>> No, there was no such definition for EA-bits length restriction. >>> >>> >>> >>>> Now there is a new proposal to add a new feature to have the IPv4 >>> >>>> information >>> >>>> in the BR only. This change requires to provision individual >>> >>>>subscriber >>> >>>> information to the BR (instead of aggregated information). Benefit >>> are >>> >>>> saving bits and breaking v4 and v6 address dependency. >>> >>> >>> >>> There's no change from previous spec, to just clarify MAP, as a >>> >>>stateless >>> >>> solution, could naturally support most granular mapping rule in its >>> >>> nature. >>> >>> >>> >>>> >>> >>>> Questions to WG: >>> >>>> Is it useful feature to be included in MAP? If not, why and >>> >>>>alternative? >>> >>>> >>> >>> >>> >>> I believe that it does not make sense to restrict EA-len > 0 for bo= th >>> >>>MAP >>> >>> and 4rd. It does make sense that you see MAP as framework of >>> solutions >>> >>> which covers specific 1:1 solution by the mapping algorithm. >>> >>> >>> >>> cheers, >>> >>> --satoru >>> >>> >>> >>> >>> >>>> Thanks, >>> >>>> Yiu >>> >>>> >>> >>>> On 7/25/12 2:40 PM, "Ole Tr=C3=B8an" wrote: >>> >>>> >>> >>>>> Yiu, >>> >>>>> >>> >>>>>> I am not asking whether MAP supports 1:1 mode with no EA bits or >>> >>>>>>not. >>> >>>>>> I >>> >>>>>> am >>> >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >>> >>>>>> achieve >>> >>>>>> 1:1 mode: >>> >>>>>> >>> >>>>>> "The EA bits can contain a full or part >>> >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address cas= e >>> >>>>>> contains a Port-Set Identifier (PSID)." >>> >>>>>> >>> >>>>>> Why not use this instead? >>> >>>>> >>> >>>>> you can do either. >>> >>>>> embedding a complete IPv4 address and PSID does require a lot of >>> IPv6 >>> >>>>> space though. >>> >>>>> e.g. /56 - 32 - 6 =3D /18 >>> >>>>> >>> >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>> >>>>> addressing >>> >>>>> are independent. >>> >>>>> >>> >>>>> cheers, >>> >>>>> Ole >>> >>>>> >>> >>>> _______________________________________________ >>> >>>> Softwires mailing list >>> >>>> Softwires@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> > >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --90e6ba6e871678941604c5cfb35b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Woj,

According to your description, it is clear that the way to deal= with EA=3D0 is quite different with EA>0. Mixing them together will not= only make MAP losing the initial "no state in the ISP network paradig= m" spirit, but also make MAP a lot more complex and confusing.

Actually, the use case for EA=3D0 and EA>0 stems from different requ= irements, it is nature to treat them with seperately.

Best wishesQiong

On Fri, Jul 27, 2012 at 9:03 PM, W= ojciech Dec <wdec.ietf@gmail.com> wrote:
Ole's and Satoru's eaerlier replies = on this thread described the "how", and even Maoke's earlier = post on this thread acknowledged EA=3D0 with full IPv4 to be a " natur= ally established case of the MAP". EA=3D0 simply means that there isn&= #39;t IPv4 (or PSID)=C2=A0 info in the IPv6 prefix.

In terms of your question: When the EA=3D0, the full v4 address is deri= ved via DHCP (or other) configuration. If the operator wants to configure a= ddress sharing, then a PSID is also required to be configured. This is sayi= ng , " you have to have an IPv4 address, and besides that if you want = address sharing, you have to configure a port range via a PSID", which= is unlikely to be confusing to any operator who is interested in doing any= of this.

That said, even if it the draft can better articulate this use, (which = draft-00 actually sought to do), that not being so is hardly grounds for ha= ving yet another solution and draft to deal with this use-case. In terms of= causing operator confusion, that by far is more confusing.

Thanks,
Woj.



On 27 July 2012 14:39, Lee, Yiu &l= t;Yiu_Lee@ca= ble.comcast.com> wrote:
Woj,

I am confused. You said "giv= en that EA=3D0 is already covered (eg embedding of full IPv4 address, no ad= dress sharing, if not the other case)". If I read the spec right, this= is my understanding:=C2=A0If I want to embed full v4 address in the CE v6 = address, the v4 address will be embedded in the EA. If so, how would EA=3D0= ?=C2=A0

"The EA bits encode the CE specific IPv4
   addre=
ss and port information.  The EA bits can contain a full or part
   of an IPv4 prefix or address, and in the shared IPv4 address case
   contains a Port-Set Identifier (PSID)."

I = prefer one solution vs. N solutions given that the one solution can logical= ly solve all problems and doesn't cause confusion. Consider we agreed o= n including 1:1 MAP. When an operator deployed it, he had to ask if I want = to share v4 addresses, should I put the v4 info in the EA or set EA=3D0 and= provision PSID? It will create unnecessary confusion. Simply put I am not = "calling out for a "remove that part of the spec & complicate= it" case". My position is quite an opposite. I am calling out fo= r "not adding confusion to complicate a spec".

In the end, it is up to WG to decide.

Thanks,
Yiu

From: Wojciech Dec <wdec.ietf@gmail.com>Date: Friday, July 27, 2012 8:06= AM
To: "Yiu L. LEE" <yiu_lee@cable.c= omcast.com>
Cc: Ole Tr= =C3=B8an <otro= an@employees.org>, Softwires-wg <softwires@ietf.org>

Subject: Re: [Softwires] map-0= 0: review on the mode 1:1


=

On 26 July 2012 16:59, Lee, Yiu <Yiu_Lee@cable.comcast.com> wrote:
Ole,

IMHO the WG will need to decide whether EA=3D0 should be covered at all. If=
not, then the draft could explicitly mention EA must be > 0 and must
= contain v4 information in the CE address. If the WG decided this needed to<= br> be cover, I would recommend to have a new draft to cover it and leave EA=3D= 0
undefined in the base draft.

What are the technical arguments for making such a decision?
Furthermore, given that EA=3D0 is already covered (eg embedding of full IPv= 4 address, no address sharing, if not the other case) you appear to be call= ing out for a "remove that part of the spec & complicate it" = case, even though not disputing the use-fullness of the use-case.=C2=A0 Seems a sure way to get us from 1 solution to N sol= utions just for the sake of it.

Thanks,
Woj.

Thanks,
Yiu

On 7/26/12 6:22 AM, "Ole Tr=C3=B8an" <otroan@employees.org> wrote:
>Yiu,
>
>> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 = address
>> dependency. It doesn't bring any new function compared to embe= dding full
>> v4 address in the EA-bit. However, the operation models of EA-bit&= gt;0 or
>>=3D0
>> are very different. By the way, this works only for MAP-E. I fail = to see
>> why we want to include this in the base spec.
>
>what do you say in the spec if EA=3D0 and provisioned IPv4 prefix lengt= h =3D
>32.
>the spec has to say something about this to be complete.
>
>cheers,
>Ole
>
>
>>
>> Thanks,
>> Yiu
>>
>>
>> On 7/25/12 9:45 PM, "Satoru Matsushima" <satoru.matsushima@gmai= l.com>
>> wrote:
>>
>>> Hi Yiu,
>>>
>>> On 2012/07/26, at 4:08, Lee, Yiu wrote:
>>>
>>>> Ole,
>>>>
>>>> Where can I get the formal definition of 1:1 mode? My unde= rstanding of
>>>> 1:1
>>>> refers to one public IPv4 address per subscriber but you r= efer very
>>>> specific to decoupling IPv4 and IPv6 addresses.
>>>>
>>>
>>> It doesn't 1:1 in MAP and 4rd context, because embedding f= ull ipv4
>>> address in ea-bits is as a result of prefix allocation operati= on.
>>>
>>>> Before MAP was accepted as WG item, MAP was proposed to em= bed IPv4
>>>> address
>>>> information (EA bits > 0) in the CE IPv6 address to ach= ieve stateless.
>>>
>>> No, there was no such definition for EA-bits length restrictio= n.
>>>
>>>> Now there is a new proposal to add a new feature to have t= he IPv4
>>>> information
>>>> in the BR only. This change requires to provision individu= al
>>>>subscriber
>>>> information to the BR (instead of aggregated information).= Benefit are
>>>> saving bits and breaking v4 and v6 address dependency.
= >>>
>>> There's no change from previous spec, to just clarify MAP,= as a
>>>stateless
>>> solution, could naturally support most granular mapping rule i= n its
>>> nature.
>>>
>>>>
>>>> Questions to WG:
>>>> Is it useful feature to be included in MAP? If not, why an= d
>>>>alternative?
>>>>
>>>
>>> I believe that it does not make sense to restrict EA-len > = 0 for both
>>>MAP
>>> and 4rd. It does make sense that you see MAP as framework of s= olutions
>>> which covers specific 1:1 solution by the mapping algorithm. >>>
>>> cheers,
>>> --satoru
>>>
>>>
>>>> Thanks,
>>>> Yiu
>>>>
>>>> On 7/25/12 2:40 PM, "Ole Tr=C3=B8an" <otroan@employees.org= > wrote:
>>>>
>>>>> Yiu,
>>>>>
>>>>>> I am not asking whether MAP supports 1:1 mode with= no EA bits or
>>>>>>not.
>>>>>> I
>>>>>> am
>>>>>> asking MAP allows to embed the 32-bit address in t= he EA bits to
>>>>>> achieve
>>>>>> 1:1 mode:
>>>>>>
>>>>>> "The EA bits can contain a full or part
>>>>>> of an IPv4 prefix or address, and in the shared IP= v4 address case
>>>>>> contains a Port-Set Identifier (PSID)."
>>>>>>
>>>>>> Why not use this instead?
>>>>>
>>>>> you can do either.
>>>>> embedding a complete IPv4 address and PSID does requir= e a lot of IPv6
>>>>> space though.
>>>>> e.g. /56 - 32 - 6 =3D /18
>>>>>
>>>>> 1:1 mode is typically referred to a model where IPv4 a= nd IPv6
>>>>> addressing
>>>>> are independent.
>>>>>
>>>>> cheers,
>>>>> Ole
>>>>>
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> So= ftwires@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>

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




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




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


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

--90e6ba6e871678941604c5cfb35b-- From pengwu.thu@gmail.com Fri Jul 27 06:43:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDD221F86B3 for ; Fri, 27 Jul 2012 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.068, 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 18jlmUjct15y for ; Fri, 27 Jul 2012 06:43:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBA221F86A4 for ; Fri, 27 Jul 2012 06:43:41 -0700 (PDT) Received: by yhq56 with SMTP id 56so3475120yhq.31 for ; Fri, 27 Jul 2012 06:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7DeRQfmBACRZiMcfrYsNboxBQ5y4/5bGH5KKr0vnsTw=; b=pE0mcDPypBK2OIbKBrcOn2y9Fl8GNKFLlA9/P0cCqjKpZt6IDk0gCnLx4uMiu28jHV hzISMtskQJNmbS/1ZEYTsgDSGEjw6l1/qg6GWlCWl8J7jp4ak+jogChSXDI/TzCP26Bu BoTLIPwDPCZbvd0HLyZRLF4eB09BCCpXfTxyaYW3g+4B+N7ccXkPds49e8iF6X04CZQ6 /VWkh/5MsmPCt1OsHuBJ/U3i/AdWb82SG+HDOVcMJXAuX+hrNFDEg8XHm+OR/oCx3r8i h81e1LWbVu/54BmyBPzoZDyDPq4qvvjZQOVkpX+MnUBxcgI5UxMmCZ6XUGiAx4LXtqJe khcQ== MIME-Version: 1.0 Received: by 10.68.223.138 with SMTP id qu10mr14732333pbc.50.1343396620740; Fri, 27 Jul 2012 06:43:40 -0700 (PDT) Received: by 10.143.16.11 with HTTP; Fri, 27 Jul 2012 06:43:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Jul 2012 21:43:40 +0800 Message-ID: From: Peng Wu To: Qiong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires-wg Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:43:42 -0000 On Fri, Jul 27, 2012 at 9:28 PM, Qiong wrote: > Woj, > > According to your description, it is clear that the way to deal with EA= =3D0 is > quite different with EA>0. Mixing them together will not only make MAP > losing the initial "no state in the ISP network paradigm" spirit, but als= o > make MAP a lot more complex and confusing. > > Actually, the use case for EA=3D0 and EA>0 stems from different requireme= nts, > it is nature to treat them with seperately. And for the case of EA bits=3D0, 90% of the MAP specification is not needed= . (v4 addr, PSID) provisioning, BR v6 addr provisioning and (v4 addr, PSID, v6 addr) binding on BR, that's all. No one needs to learn any thing about "mapping rules" what so ever. > > Best wishes > Qiong > > > On Fri, Jul 27, 2012 at 9:03 PM, Wojciech Dec wrote= : >> >> Ole's and Satoru's eaerlier replies on this thread described the "how", >> and even Maoke's earlier post on this thread acknowledged EA=3D0 with fu= ll >> IPv4 to be a " naturally established case of the MAP". EA=3D0 simply mea= ns >> that there isn't IPv4 (or PSID) info in the IPv6 prefix. >> >> In terms of your question: When the EA=3D0, the full v4 address is deriv= ed >> via DHCP (or other) configuration. If the operator wants to configure >> address sharing, then a PSID is also required to be configured. This is >> saying , " you have to have an IPv4 address, and besides that if you wan= t >> address sharing, you have to configure a port range via a PSID", which i= s >> unlikely to be confusing to any operator who is interested in doing any = of >> this. >> >> That said, even if it the draft can better articulate this use, (which >> draft-00 actually sought to do), that not being so is hardly grounds for >> having yet another solution and draft to deal with this use-case. In ter= ms >> of causing operator confusion, that by far is more confusing. >> >> Thanks, >> Woj. >> >> >> >> On 27 July 2012 14:39, Lee, Yiu wrote: >>> >>> Woj, >>> >>> I am confused. You said "given that EA=3D0 is already covered (eg embed= ding >>> of full IPv4 address, no address sharing, if not the other case)". If I= read >>> the spec right, this is my understanding: If I want to embed full v4 ad= dress >>> in the CE v6 address, the v4 address will be embedded in the EA. If so,= how >>> would EA=3D0? >>> >>> "The EA bits encode the CE specific IPv4 >>> >>> address and port information. The EA bits can contain a full or par= t >>> of an IPv4 prefix or address, and in the shared IPv4 address case >>> contains a Port-Set Identifier (PSID)." >>> >>> >>> I prefer one solution vs. N solutions given that the one solution can >>> logically solve all problems and doesn't cause confusion. Consider we a= greed >>> on including 1:1 MAP. When an operator deployed it, he had to ask if I = want >>> to share v4 addresses, should I put the v4 info in the EA or set EA=3D0= and >>> provision PSID? It will create unnecessary confusion. Simply put I am n= ot >>> "calling out for a "remove that part of the spec & complicate it" case"= . My >>> position is quite an opposite. I am calling out for "not adding confusi= on to >>> complicate a spec". >>> >>> In the end, it is up to WG to decide. >>> >>> Thanks, >>> Yiu >>> >>> From: Wojciech Dec >>> Date: Friday, July 27, 2012 8:06 AM >>> To: "Yiu L. LEE" >>> Cc: Ole Tr=F8an , Softwires-wg >>> >>> Subject: Re: [Softwires] map-00: review on the mode 1:1 >>> >>> >>> >>> On 26 July 2012 16:59, Lee, Yiu wrote: >>>> >>>> Ole, >>>> >>>> IMHO the WG will need to decide whether EA=3D0 should be covered at al= l. >>>> If >>>> not, then the draft could explicitly mention EA must be > 0 and must >>>> contain v4 information in the CE address. If the WG decided this neede= d >>>> to >>>> be cover, I would recommend to have a new draft to cover it and leave >>>> EA=3D0 >>>> undefined in the base draft. >>> >>> >>> What are the technical arguments for making such a decision? >>> Furthermore, given that EA=3D0 is already covered (eg embedding of full >>> IPv4 address, no address sharing, if not the other case) you appear to = be >>> calling out for a "remove that part of the spec & complicate it" case, = even >>> though not disputing the use-fullness of the use-case. Seems a sure wa= y to >>> get us from 1 solution to N solutions just for the sake of it. >>> >>> Thanks, >>> Woj. >>>> >>>> >>>> Thanks, >>>> Yiu >>>> >>>> On 7/26/12 6:22 AM, "Ole Tr=F8an" wrote: >>>> >>>> >Yiu, >>>> > >>>> >> Set EA bits=3D0 only saves bits in v6 address and decouples v4/v6 >>>> >> address >>>> >> dependency. It doesn't bring any new function compared to embedding >>>> >> full >>>> >> v4 address in the EA-bit. However, the operation models of EA-bit>0 >>>> >> or >>>> >>=3D0 >>>> >> are very different. By the way, this works only for MAP-E. I fail t= o >>>> >> see >>>> >> why we want to include this in the base spec. >>>> > >>>> >what do you say in the spec if EA=3D0 and provisioned IPv4 prefix len= gth >>>> > =3D >>>> >32. >>>> >the spec has to say something about this to be complete. >>>> > >>>> >cheers, >>>> >Ole >>>> > >>>> > >>>> >> >>>> >> Thanks, >>>> >> Yiu >>>> >> >>>> >> >>>> >> On 7/25/12 9:45 PM, "Satoru Matsushima" >>>> >> wrote: >>>> >> >>>> >>> Hi Yiu, >>>> >>> >>>> >>> On 2012/07/26, at 4:08, Lee, Yiu wrote: >>>> >>> >>>> >>>> Ole, >>>> >>>> >>>> >>>> Where can I get the formal definition of 1:1 mode? My understandi= ng >>>> >>>> of >>>> >>>> 1:1 >>>> >>>> refers to one public IPv4 address per subscriber but you refer ve= ry >>>> >>>> specific to decoupling IPv4 and IPv6 addresses. >>>> >>>> >>>> >>> >>>> >>> It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 >>>> >>> address in ea-bits is as a result of prefix allocation operation. >>>> >>> >>>> >>>> Before MAP was accepted as WG item, MAP was proposed to embed IPv= 4 >>>> >>>> address >>>> >>>> information (EA bits > 0) in the CE IPv6 address to achieve >>>> >>>> stateless. >>>> >>> >>>> >>> No, there was no such definition for EA-bits length restriction. >>>> >>> >>>> >>>> Now there is a new proposal to add a new feature to have the IPv4 >>>> >>>> information >>>> >>>> in the BR only. This change requires to provision individual >>>> >>>>subscriber >>>> >>>> information to the BR (instead of aggregated information). Benefi= t >>>> >>>> are >>>> >>>> saving bits and breaking v4 and v6 address dependency. >>>> >>> >>>> >>> There's no change from previous spec, to just clarify MAP, as a >>>> >>>stateless >>>> >>> solution, could naturally support most granular mapping rule in it= s >>>> >>> nature. >>>> >>> >>>> >>>> >>>> >>>> Questions to WG: >>>> >>>> Is it useful feature to be included in MAP? If not, why and >>>> >>>>alternative? >>>> >>>> >>>> >>> >>>> >>> I believe that it does not make sense to restrict EA-len > 0 for >>>> >>> both >>>> >>>MAP >>>> >>> and 4rd. It does make sense that you see MAP as framework of >>>> >>> solutions >>>> >>> which covers specific 1:1 solution by the mapping algorithm. >>>> >>> >>>> >>> cheers, >>>> >>> --satoru >>>> >>> >>>> >>> >>>> >>>> Thanks, >>>> >>>> Yiu >>>> >>>> >>>> >>>> On 7/25/12 2:40 PM, "Ole Tr=F8an" wrote: >>>> >>>> >>>> >>>>> Yiu, >>>> >>>>> >>>> >>>>>> I am not asking whether MAP supports 1:1 mode with no EA bits o= r >>>> >>>>>>not. >>>> >>>>>> I >>>> >>>>>> am >>>> >>>>>> asking MAP allows to embed the 32-bit address in the EA bits to >>>> >>>>>> achieve >>>> >>>>>> 1:1 mode: >>>> >>>>>> >>>> >>>>>> "The EA bits can contain a full or part >>>> >>>>>> of an IPv4 prefix or address, and in the shared IPv4 address ca= se >>>> >>>>>> contains a Port-Set Identifier (PSID)." >>>> >>>>>> >>>> >>>>>> Why not use this instead? >>>> >>>>> >>>> >>>>> you can do either. >>>> >>>>> embedding a complete IPv4 address and PSID does require a lot of >>>> >>>>> IPv6 >>>> >>>>> space though. >>>> >>>>> e.g. /56 - 32 - 6 =3D /18 >>>> >>>>> >>>> >>>>> 1:1 mode is typically referred to a model where IPv4 and IPv6 >>>> >>>>> addressing >>>> >>>>> are independent. >>>> >>>>> >>>> >>>>> cheers, >>>> >>>>> Ole >>>> >>>>> >>>> >>>> _______________________________________________ >>>> >>>> Softwires mailing list >>>> >>>> Softwires@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >>>> > >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From jan@go6.si Fri Jul 27 06:48:34 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5642921F86C6 for ; Fri, 27 Jul 2012 06:48:34 -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 tX+qtDTu-Fua for ; Fri, 27 Jul 2012 06:48:33 -0700 (PDT) Received: from ipv6.go6.si (unknown [IPv6:2a02:e8:0:1::babe:face]) by ietfa.amsl.com (Postfix) with ESMTP id 72BE321F86AA for ; Fri, 27 Jul 2012 06:48:33 -0700 (PDT) Received: from [IPv6:2001:67c:27e4:2000:4914:2bde:4893:2680] (unknown [IPv6:2001:67c:27e4:2000:4914:2bde:4893:2680]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jan) by ipv6.go6.si (Postfix) with ESMTP id A743C2378001 for ; Fri, 27 Jul 2012 15:48:31 +0200 (CEST) Message-ID: <50129C33.6070200@go6.si> Date: Fri, 27 Jul 2012 15:48:35 +0200 From: "Jan Zorz @ go6.si" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 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: 7bit Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 13:48:34 -0000 On 7/27/12 2:39 PM, Lee, Yiu wrote: > "The EA bits encode the CE specific IPv4 > > address and port information. The EA bits can contain a full or part > of an IPv4 prefix or address, and in the shared IPv4 address case > contains a Port-Set Identifier (PSID)." > > > I prefer one solution vs. N solutions given that the one solution can > logically solve all problems and doesn't cause confusion. Consider we > agreed on including 1:1 MAP. When an operator deployed it, he had to ask > if I want to share v4 addresses, should I put the v4 info in the EA or > set EA=0 and provision PSID? It will create unnecessary confusion. > Simply put I am not "calling out for a "remove that part of the spec & > complicate it" case". My position is quite an opposite. I am calling out > for "not adding confusion to complicate a spec". Hi, I'm just admiring how the WG (usual suspects) manages to talk about the intention to simplify things and at the end everything ends up three times more complex than at the beginning. In the RFC6346 we specified the architecture and the idea of A+P way of sharing resources. The idea was simple, clean and understandable. Now even I don't understand completely A+P anymore and that's probably a bad sign - and adding also a 4RD flavor with all the header hacks did not help either. So, on 1:1 - Idea of having 1:1 is simply to be able to do gradual deployment of A+P. In ideal world, ISP today would be able to buy from his favorite vendor A+P solution, started sending out new CPEs that are A+P capable/aware and connect them to PRR with full IP address assigned - so no change for a user as for now. Operator would be also able to change the CPE-base with sending new CPEs to old customers when they break. When operator starts getting short on IPv4 supplies, he simply introduces address sharing and changes the customers communication behaviour with a flick of the switch on services configuration page - or even better, customer applies for sharing because less price of the deal or something similar. In this case CPE gets port-restricted address next time it reconnects. So, from operational point of view, it is very important that the switch from 1:1 to sharing model is smooth, easy and a matter of one checkbox in services webpage - and it should be done on per-customer granularity. That's it. Very simple. That was how the idea should work in ideal world. But we are not there. A+P was delayed for years because of some people here - but finally even those people understood that this is the only alternative to CGN rubbish, that is currently taking over the Internet infrastructure. Please stop complicating things and fighting whose flavor is better or who's ***** is longer and loosing time. We need solid standard asap and I really don't care whose name is on the top of the RFC(s). Med correctly pointed to the skech in RFC6346 and I hope just options 1 and 2 will be used in real world. Cheers, Jan P.S: Unfortunately I cannot make it to Vancouver, but I encourage you all to go into that room, lock the door and don't leave it without a result and a clear idea, how to move forward quickly. From bingxuere@gmail.com Fri Jul 27 07:12:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD28721F87F9 for ; Fri, 27 Jul 2012 07:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydX5p6-jWPp0 for ; Fri, 27 Jul 2012 07:12:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77421F87F5 for ; Fri, 27 Jul 2012 07:12:30 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4964070obb.31 for ; Fri, 27 Jul 2012 07:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mA0dAi38PhQ1ISXAoth52mFQ9eOjGc1Ypwi+QMgoWIk=; b=Hgg0Ggz15kGirDtaJ4yW30gPpLpRWj0uBtXVwRx2qIMbatc5fHfgkGEAO3uFYvsD3L wPXxBlfi+o5A/eJIxYsxRP5fzli88emBfP3iXEMZbsz8I8NspmUhcdztYuB3eW4y0qMw In40ZgSgseIu694BVXxj7FKyizCVYObc1knvlpb/3GXExKcVIrq8YQZpJS4kedXHQ/n2 7cJdJ/27a1+3aiP1IvCqfq9+1rVCn5jLsvM2QQQHvM1fpcJUnNbEF6z7Tx2Zmq//mkek 0UrxtR9m0Qyar6HuELvuiNR0u5iYiFDakOJF2Khcx50mx5yGBnItDylcrXVhpunjsVLO FVEA== Received: by 10.182.111.39 with SMTP id if7mr3707396obb.56.1343398349950; Fri, 27 Jul 2012 07:12:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.169.38 with HTTP; Fri, 27 Jul 2012 07:11:49 -0700 (PDT) In-Reply-To: <50129C33.6070200@go6.si> References: <50129C33.6070200@go6.si> From: Qiong Date: Fri, 27 Jul 2012 22:11:49 +0800 Message-ID: To: "Jan Zorz @ go6.si" Content-Type: multipart/alternative; boundary=14dae939908770d01d04c5d04da8 Cc: softwires@ietf.org Subject: Re: [Softwires] map-00: review on the mode 1:1 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 14:12:31 -0000 --14dae939908770d01d04c5d04da8 Content-Type: text/plain; charset=UTF-8 Hi Jan, Thanks to bring this point out. (sorry to re-send it to the wg) What you described is exactly in draft-cui-softwire-b4- translated-ds-lite, a per-subscriber level solution which solved the requirements on: 1) NAT offloading from CGN to CPE 2) Flexibility on IPv6 address planning 3) IPv4/IPv6 decoupling 4) reduced logging 5) hub&spoke 6) support address sharing 7) very very very simple, clean and understandable Of course, it does not solve the mesh scenario. Best wishes On Fri, Jul 27, 2012 at 9:48 PM, Jan Zorz @ go6.si wrote: > On 7/27/12 2:39 PM, Lee, Yiu wrote: > >> "The EA bits encode the CE specific IPv4 >> >> address and port information. The EA bits can contain a full or part >> of an IPv4 prefix or address, and in the shared IPv4 address case >> contains a Port-Set Identifier (PSID)." >> >> >> I prefer one solution vs. N solutions given that the one solution can >> logically solve all problems and doesn't cause confusion. Consider we >> agreed on including 1:1 MAP. When an operator deployed it, he had to ask >> if I want to share v4 addresses, should I put the v4 info in the EA or >> set EA=0 and provision PSID? It will create unnecessary confusion. >> Simply put I am not "calling out for a "remove that part of the spec & >> complicate it" case". My position is quite an opposite. I am calling out >> for "not adding confusion to complicate a spec". >> > > Hi, > > I'm just admiring how the WG (usual suspects) manages to talk about the > intention to simplify things and at the end everything ends up three times > more complex than at the beginning. > > In the RFC6346 we specified the architecture and the idea of A+P way of > sharing resources. The idea was simple, clean and understandable. > > Now even I don't understand completely A+P anymore and that's probably a > bad sign - and adding also a 4RD flavor with all the header hacks did not > help either. > > So, on 1:1 - Idea of having 1:1 is simply to be able to do gradual > deployment of A+P. In ideal world, ISP today would be able to buy from his > favorite vendor A+P solution, started sending out new CPEs that are A+P > capable/aware and connect them to PRR with full IP address assigned - so no > change for a user as for now. Operator would be also able to change the > CPE-base with sending new CPEs to old customers when they break. > > When operator starts getting short on IPv4 supplies, he simply introduces > address sharing and changes the customers communication behaviour with a > flick of the switch on services configuration page - or even better, > customer applies for sharing because less price of the deal or something > similar. In this case CPE gets port-restricted address next time it > reconnects. > > So, from operational point of view, it is very important that the switch > from 1:1 to sharing model is smooth, easy and a matter of one checkbox in > services webpage - and it should be done on per-customer granularity. > > That's it. Very simple. That was how the idea should work in ideal world. > > But we are not there. A+P was delayed for years because of some people > here - but finally even those people understood that this is the only > alternative to CGN rubbish, that is currently taking over the Internet > infrastructure. > > Please stop complicating things and fighting whose flavor is better or > who's ***** is longer and loosing time. > > We need solid standard asap and I really don't care whose name is on the > top of the RFC(s). > > Med correctly pointed to the skech in RFC6346 and I hope just options 1 > and 2 will be used in real world. > > Cheers, Jan > > P.S: Unfortunately I cannot make it to Vancouver, but I encourage you all > to go into that room, lock the door and don't leave it without a result and > a clear idea, how to move forward quickly. > > ______________________________**_________________ > 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/ * =============================================== --14dae939908770d01d04c5d04da8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jan,

Thanks to bring this point out.=C2=A0 (sorry to re-send it t= o the wg)

What you described is exactly in draft-cui-softwire-b4-translated-ds-lite, a per-subscriber level solution which sol= ved the requirements on:
1) NAT offloading from CGN to CPE
2) Flexibility on IPv6 address planning
3) IPv4/IPv6 decoupling
4) re= duced logging
5) hub&spoke
6) support address sharing
7) very = very very simple, clean and understandable

Of course, it does not so= lve the mesh scenario.

Best wishes

On Fri, Jul 27, 201= 2 at 9:48 PM, Jan Zorz @ go6.si <jan@go6.si>= wrote:
On 7/27/12 2:39 PM, Lee, Y= iu wrote:
"The EA bits encode the CE specific IPv4

=C2=A0 =C2=A0 address and port information. =C2=A0The EA bits can contain a= full or part
=C2=A0 =C2=A0 of an IPv4 prefix or address, and in the shared IPv4 address = case
=C2=A0 =C2=A0 contains a Port-Set Identifier (PSID)."


I prefer one solution vs. N solutions given that the one solution can
logically solve all problems and doesn't cause confusion. Consider we agreed on including 1:1 MAP. When an operator deployed it, he had to ask if I want to share v4 addresses, should I put the v4 info in the EA or
set EA=3D0 and provision PSID? It will create unnecessary confusion.
Simply put I am not "calling out for a "remove that part of the s= pec &
complicate it" case". My position is quite an opposite. I am call= ing out
for "not adding confusion to complicate a spec".

Hi,

I'm just admiring how the WG (usual suspects) manages to talk about the= intention to simplify things and at the end everything ends up three times= more complex than at the beginning.

In the RFC6346 we specified the architecture and the idea of A+P way of sha= ring resources. The idea was simple, clean and understandable.

Now even I don't understand completely A+P anymore and that's proba= bly a bad sign - and adding also a 4RD flavor with all the header hacks did= not help either.

So, on 1:1 - Idea of having 1:1 is simply to be able to do gradual deployme= nt of A+P. In ideal world, ISP today would be able to buy from his favorite= vendor A+P solution, started sending out new CPEs that are A+P capable/awa= re and connect them to PRR with full IP address assigned - so no change for= a user as for now. Operator would be also able to change the CPE-base with= sending new CPEs to old customers when they break.

When operator starts getting short on IPv4 supplies, he simply introduces a= ddress sharing and changes the customers communication behaviour with a fli= ck of the switch on services configuration page - or even better, customer = applies for sharing because less price of the deal or something similar. In= this case CPE gets port-restricted address next time it reconnects.

So, from operational point of view, it is very important that the switch fr= om 1:1 to sharing model is smooth, easy and a matter of one checkbox in ser= vices webpage - and it should be done on per-customer granularity.

That's it. Very simple. That was how the idea should work in ideal worl= d.

But we are not there. A+P was delayed for years because of some people here= - but finally even those people understood that this is the only alternati= ve to CGN rubbish, that is currently taking over the Internet infrastructur= e.

Please stop complicating things and fighting whose flavor is better or who&= #39;s ***** is longer and loosing time.

We need solid standard asap and I really don't care whose name is on th= e top of the RFC(s).

Med correctly pointed to the skech in RFC6346 and I hope just options 1 and= 2 will be used in real world.

Cheers, Jan

P.S: Unfortunately I cannot make it to Vancouver, but I encourage you all t= o go into that room, lock the door and don't leave it without a result = and a clear idea, how to move forward quickly.

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



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


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

--14dae939908770d01d04c5d04da8-- From wdec.ietf@gmail.com Fri Jul 27 07:20:46 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB35D21F866D for ; Fri, 27 Jul 2012 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.16 X-Spam-Level: X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYLCDiiDkQpx for ; Fri, 27 Jul 2012 07:20:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E33B21F866A for ; Fri, 27 Jul 2012 07:20:46 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2879761vcb.31 for ; Fri, 27 Jul 2012 07:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tvlOEC+RihmIGPn94RAqnJUjnbCWaIjAXUDCiKcujD0=; b=WvmqB0kU8Qc1RbLf9LyULbH5spL7kR2JotXHJHW6qCWpughm2yWpo/i0mQ/dOnWJFa E5QhC/mWWsbTTxI8N80giByjF0whsFs+JWGS8/e4dO7iH8Ia4DA45jO8wt7Z63VOFLY/ vO/9Jk/I5ziRmNrXiOsm+fOqeiRe95SKiXlsDjVibBfi3rIBbm/Y4Hvx6PpDkvGbuAVd jfphsrGa/5Rv2fF9mUtmH7SJhw2UUtzsuJgHM8N/qZERjpP1GbsH/e/pU0Bf9w5UB1nd 9/UlMk6TdbwRT9SXOQG47RGLo3ciJSxpVdmPf/SH0IC+AZszjJQWVV8WEgESn80xqwE0 BzmQ== MIME-Version: 1.0 Received: by 10.52.93.202 with SMTP id cw10mr2369682vdb.1.1343398845698; Fri, 27 Jul 2012 07:20:45 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Fri, 27 Jul 2012 07:20:45 -0700 (PDT) In-Reply-To: <01C1D9BA-FEB8-47DD-BC03-25E8A8D5CC50@laposte.net> References: <01C1D9BA-FEB8-47DD-BC03-25E8A8D5CC50@laposte.net> Date: Fri, 27 Jul 2012 16:20:45 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf307cfe7cfd52b904c5d06ad0 Cc: Softwires WG , "Wojciech Dec \(wdec\)" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 27 Jul 2012 14:20:46 -0000 --20cf307cfe7cfd52b904c5d06ad0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 25 July 2012 16:13, R=E9mi Despr=E9s wrote: > > Le 2012-07-25 =E0 15:59, Wojciech Dec (wdec) a =E9crit : > > > > > > > On 25/07/2012 15:47, "R=E9mi Despr=E9s" wrot= e: > > > >> > >> > >> > >>> take it to 6man. > >> > >> 6man has to be involved, sure, but Softwire should first be clear abou= t > >> the purpose, and possible drawbacks if any. > >> If you see such drawbacks, please clarify. > > > > Here's one: > > I'd like my to be guarantee= d > > *never ever* to conflict. Can I also get a V octet for > <$my_device_class>? > > Sorry I couldn't decipher this. > How many V-octets do you think the IETF should assign, and why should the V-octed belong to your proposed device/use-category? One may want the V-octet to be used for "Next gen TVs", etc. This is a problem & discussion for 6man, which has been said before... -Woj. > > RD > > > > > -Woj. > >> > >> Thanks, > >> RD > >> > >> > >> > >> > >>> > >>> cheers, > >>> Ole > >>> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf307cfe7cfd52b904c5d06ad0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 25 July 2012 16:13, R=E9mi Despr=E9s = <despres.remi@laposte.net> wrote:

Le 2012-07-25 =E0 15:59, Wojciech Dec (wdec) a =E9crit :

>
>
> On 25/07/2012 15:47, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
>>
>>
>>
>>> take it to 6man.
>>
>> 6man has to be involved, sure, but Softwire should first be clear = about
>> the purpose, and possible drawbacks if any.
>> If you see such drawbacks, please clarify.
>
> Here's one:
> I'd like my <insert name of your favorite device class> to b= e guaranteed
> *never ever* to conflict. Can I also get a V octet for <$my_device_= class>?

Sorry I couldn't decipher this.

How many= V-octets do you think the IETF should assign, and why should the V-octed b= elong to your proposed device/use-category? One may want the V-octet to be = used for "Next gen TVs", etc.
This is a problem & discussion for 6man, which has been said before...<= br>
-Woj.

RD

>
> -Woj.
>>
>> Thanks,
>> RD
>>
>>
>>
>>
>>>
>>> cheers,
>>> Ole
>>>
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf307cfe7cfd52b904c5d06ad0-- From tomasz.mrugalski@gmail.com Fri Jul 27 07:55:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AB121F8741 for ; Fri, 27 Jul 2012 07:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1Xv23eupsYl for ; Fri, 27 Jul 2012 07:55:25 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDC0521F8718 for ; Fri, 27 Jul 2012 07:55:15 -0700 (PDT) Received: by eaaa11 with SMTP id a11so589093eaa.31 for ; Fri, 27 Jul 2012 07:55:15 -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-tagtoolbar-keys:content-type :content-transfer-encoding; bh=jvjUwP1MDjygXtOEJWqZwHjANCA10WVAZtzzSCN+H2U=; b=Zosx+dBtNG8dHEc/6lnzHHpuj+FEYTF5RDRCLvZB3fCMF9RyDy6v99tQvaXgKKktD8 MDl0EdZOfpZpNW9cN7DlD7cb3mDJ/kPUvJmx5QSCnxUuwtLf5DwQ7lEy4ho9/1h0f2iA nxQ2S7ZPiDN7FztJQKLQFSOkOmQzuDzVWZ+pcuxrMrwWq4PPxG7FfMn6rs/s+9kFpyNg m05nskjWxeqEGH2YiFkI4R3mygxTWhkes6IaDrqFspzL4DwBJruortNx1t7xyadMo01q TCrtdtW3adCUtAuukJ+KLtZKXKZ1sbPqzgof1+rFqbS1/8R9rJmVFMVCToTQ2vZ/OPQN /SPQ== Received: by 10.14.207.137 with SMTP id n9mr2983733eeo.34.1343400915088; Fri, 27 Jul 2012 07:55:15 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:e449:be74:d84d:7b43? ([2001:470:6061:1:e449:be74:d84d:7b43]) by mx.google.com with ESMTPS id g46sm6812956eep.15.2012.07.27.07.55.13 (version=SSLv3 cipher=OTHER); Fri, 27 Jul 2012 07:55:14 -0700 (PDT) Message-ID: <5012ABCE.6080100@gmail.com> Date: Fri, 27 Jul 2012 16:55:10 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <2771FA9B-6C7F-4BCE-AE79-8B2B158C3F68@laposte.net> In-Reply-To: <2771FA9B-6C7F-4BCE-AE79-8B2B158C3F68@laposte.net> X-TagToolbar-Keys: D20120727165510224 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] DHCPv6 section of the 4rd 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, 27 Jul 2012 14:55:26 -0000 On 24.07.2012 15:10, Rmi Desprs wrote: > Hi, Tomek, Hi Remi. hi all, > Since you are the known DHCP expert in Softwire concerning stateless Thank you for your kind words. I just know DHCPv6 a bit, but I definitely don't consider myself an expert in stateless solutions. > solutions, could you kindly review section 4.8 of the 4rd-03 draft, > and comment on the ML its use of DHCPv6? I must admit that I haven't read 4rd draft in a long time. Unfortunately, I won't be able to review it before DHC meeting. Actually, it makes sense to do the 4rd review after DHC WG meeting. MAP options are going to be presented there, so I will hopefully be able to take advantage of other comments from DHC WG as MAP and 4rd options are quite similar. I haven't read 4rd-03 yet, just briefly looked at Section 4.8. Having said that, I've got a question to 4rd authors. I see there are significant similarities between MAP and 4rd options. Would you consider merging them a viable option? If all other MAP-4rd unification attempts fail, perhaps at least provisioning method could be common? > (Doing so, of course, will not prejudge what the WG will decide > concerning MAP-T+E vs 4rd.) You definitely overestimate my capabilities. I have very serious doubts that the whole WG would make a decision based on my comments. :-) > In particular, the map-dhcp draft which will soon be a WG document > has a container which isn't present in 4rd. Would it be recommend to > add one (and if yes for which reason(s))? Here are some arguments why I think such a container make sense: 1. Some parameters may apply to all rules. Currently there is only one such parameter defined (transport mode), but others may appear once MAP evolves. 2. Easier client-server interaction. With a single container, client just signals support for MAP by requesting MAP_FLAGS option in ORO and server responds with MAP_FLAGS option with whatever sub-options are appropriate for a given client. Without container, client would be expected to request several options (MAP_FLAGS, MAP_RULE, ...) in ORO. But how is server is supposed to behave if a (misimplemented) client requests only MAP_FLAGS for example? Or only asks for basic rules? Such approach makes sanity checking and error recovery more difficult. 3. Multiple MAP domains. Sometimes there are discussions about multiple MAP domains. I haven't followed it closely, so I don't know if the latest conclusion is that they make sense or not. However, even if MAP authors (and the whole Softwires WG in general) decides that they are not valid, there may be cases when one server will provide more than one domain anyway. Look at discussion in homenet and the problem with multiple provisioning domains (like th concept of having a single home router connected to multiple ISPs). Put it simply, a container option makes multiple domains doable, if we ever decide that such a thing is useful. 4. It's easier for clients that don't support MAP. That is really a minor point, but clients that don't support MAP will complain about just a single unknown option, not many. Sure, in a perfect world, client is not expected to receive an option that it never requested. But there are people who configure their servers to force some options, regardless requested or not. 5. There's no actual bandwidth waste with container. There would be a minimal overhead of 4 octets if it was just a container. However, since MAP and 4rd both require an option with some information, there's no waste. 6. Forward compatibility. Let's assume that 4rd is standardized. What would you do if the next day after its publication someone comes with cool new idea for improvement or optimization that requires passing extra parameter to client? You would have to define a new option and it wouldn't work with old implementations. With a container, you have at least some chances to make it work. One may say that this is a weak argument, as old implementations will not know what to do with an unknown option. However, many implementations handle contents of the option be calling external script. So extending support for such extra sub-option would require updating just a script, not the whole client software. If you take those arguments one by one, each of them can be considered not important enough to warrant such a container, but if you add them all up, it is just much easier do go with a container. At least that is my opinion on that subject. Cheers, Tomek From despres.remi@laposte.net Fri Jul 27 08:01:26 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C377721F87B1 for ; Fri, 27 Jul 2012 08:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVJkyUkDYf3U for ; Fri, 27 Jul 2012 08:01:26 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id B3AC821F87AE for ; Fri, 27 Jul 2012 08:01:23 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 4BD7A940181; Fri, 27 Jul 2012 17:01:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18-21853046 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 27 Jul 2012 17:01:13 +0200 Message-Id: <15B867A3-1842-44F7-83CF-5E54624577BC@laposte.net> References: <01C1D9BA-FEB8-47DD-BC03-25E8A8D5CC50@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , "Wojciech Dec \(wdec\)" , "draft-ietf-softwire-map@tools.ietf.org" Subject: Re: [Softwires] [softwire] #5: Problems of MAP-T and MAP-E with sites that already use subnet ID = 0 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 27 Jul 2012 15:01:26 -0000 --Apple-Mail-18-21853046 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-07-27 =E0 16:20, Wojciech Dec a =E9crit : >=20 >=20 > On 25 July 2012 16:13, R=E9mi Despr=E9s = wrote: >=20 > Le 2012-07-25 =E0 15:59, Wojciech Dec (wdec) a =E9crit : >=20 > > > > > > On 25/07/2012 15:47, "R=E9mi Despr=E9s" = wrote: > > > >> > >> > >> > >>> take it to 6man. > >> > >> 6man has to be involved, sure, but Softwire should first be clear = about > >> the purpose, and possible drawbacks if any. > >> If you see such drawbacks, please clarify. > > > > Here's one: > > I'd like my to be = guaranteed > > *never ever* to conflict. Can I also get a V octet for = <$my_device_class>? >=20 > Sorry I couldn't decipher this. >=20 > How many V-octets do you think the IETF should assign, and why should = the V-octed belong to your proposed device/use-category? One may want = the V-octet to be used for "Next gen TVs", etc. > This is a problem & discussion for 6man, which has been said before... 1. Well, the term "V octet" only identifies a particular value of the = interface ID first octet. "u" octet identifies another value of this same octet (but a value that, = contrary to the V-octet value, can be found in local-scope addresses, = and therefore isn't reserved). What name NNN will be given to this field in general (independently of = its reserved values) remains open.=20 I agree that this is is a 6man matter. 2. You ask how many values of the NNN field the IETF should assign in the = future.=20 This is is obviously uncertain. OTOH, What is sure is that, with 6 free = bits and only assigned value for V, there is plenty room for future = uses, especially since: - no other use has been identified in 14 years - one future value can be reserved to identify an extended format, thus = largely increasing the number of reservable patterns. 3. If no WG would be allowed to propose using the extension mechanism of = RFC2373/4291, what, in your understanding, would be its purpose? RD >=20 > -Woj. >=20 > RD >=20 > > > > -Woj. > >> > >> Thanks, > >> RD > >> > >> > >> > >> > >>> > >>> cheers, > >>> Ole > >>> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-18-21853046 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On 25 July 2012 16:13, = R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:

Le 2012-07-25 =E0 15:59, Wojciech Dec (wdec) a =E9crit :

>
>
> On 25/07/2012 15:47, "R=E9mi Despr=E9s" <despres.remi@laposte.net> = wrote:
>
>>
>>
>>
>>> take it to 6man.
>>
>> 6man has to be involved, sure, but Softwire should first be = clear about
>> the purpose, and possible drawbacks if any.
>> If you see such drawbacks, please clarify.
>
> Here's one:
> I'd like my <insert name of your favorite device class> to be = guaranteed
> *never ever* to conflict. Can I also get a V octet for = <$my_device_class>?

Sorry I couldn't decipher this.

How many = V-octets do you think the IETF should assign, and why should the V-octed = belong to your proposed device/use-category? One may want the V-octet to = be used for "Next gen TVs", etc.
This is a problem & discussion for 6man, which has been said = before...

1.
Well, the term "V octet" only identifies a particular value of the = interface ID first octet.
"u" octet identifies another value = of this same octet (but a value that, contrary to the V-octet = value, can be found in local-scope addresses, and therefore isn't = reserved).
What name NNN will be given to this field in = general (independently of its reserved values) remains = open. 
I agree that this is is a 6man = matter.

2.
You ask how many values of = the NNN field the IETF should assign in the future. 
This = is is obviously uncertain. OTOH, What is sure is that, with 6 free = bits and only assigned value for V, there is plenty room for future = uses, especially since:
- no other use has been identified in = 14 years
- one future value can be reserved to identify an = extended format, thus largely increasing the number of reservable = patterns.

3.
If no WG would be = allowed to propose using the extension mechanism of RFC2373/4291, what, = in your understanding,  would be its = purpose?

RD




-Woj.

RD

>
> -Woj.
>>
>> Thanks,
>> RD
>>
>>
>>
>>
>>>
>>> cheers,
>>> Ole
>>>
>
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-18-21853046-- From despres.remi@laposte.net Fri Jul 27 09:10:36 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913AD21F87A5 for ; Fri, 27 Jul 2012 09:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.112 X-Spam-Level: X-Spam-Status: No, score=-1.112 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW-XpTbvAcFb for ; Fri, 27 Jul 2012 09:10:35 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB3B21F8731 for ; Fri, 27 Jul 2012 09:10:33 -0700 (PDT) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5081282267; Fri, 27 Jul 2012 18:10:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5012ABCE.6080100@gmail.com> Date: Fri, 27 Jul 2012 18:10:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11EE9D8E-EF1C-4F4E-AC19-D7F5CD3D1D24@laposte.net> References: <2771FA9B-6C7F-4BCE-AE79-8B2B158C3F68@laposte.net> <5012ABCE.6080100@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] DHCPv6 section of the 4rd 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, 27 Jul 2012 16:10:36 -0000 Le 2012-07-27 =E0 16:55, Tomek Mrugalski a =E9crit : > On 24.07.2012 15:10, R=E9mi Despr=E9s wrote: >> Hi, Tomek, > Hi Remi. hi all, >=20 >> Since you are the known DHCP expert in Softwire concerning stateless > Thank you for your kind words. I just know DHCPv6 a bit, but I > definitely don't consider myself an expert in stateless solutions. >=20 >> solutions, could you kindly review section 4.8 of the 4rd-03 draft, >> and comment on the ML its use of DHCPv6? > I must admit that I haven't read 4rd draft in a long time. > Unfortunately, I won't be able to review it before DHC meeting. > Actually, it makes sense to do the 4rd review after DHC WG meeting. = MAP > options are going to be presented there, so I will hopefully be able = to > take advantage of other comments from DHC WG as MAP and 4rd options = are > quite similar. >=20 > I haven't read 4rd-03 yet, just briefly looked at Section 4.8. Having > said that, I've got a question to 4rd authors. I see there are > significant similarities between MAP and 4rd options. Would you = consider > merging them a viable option? > If all other MAP-4rd unification attempts > fail, perhaps at least provisioning method could be common? Well, the WG objective before the Paris meeting was clearly to have only = one standard, MAP-T, MAP-E or 4rd. 4rd has been carefully designed satisfy requirements of both MAP-T and = MAP-E in a single design, and abundantly checked concerning this = objective. With it, operators don't need to make a choice, and get = operational advantages of T and E. (This is clearly challenged by some = participants, but so far without arguments that have been convincing.) If IETF would prefer 3 forwarding variants instead of one, right, the = provisioning method should at least be aligned. >=20 >> (Doing so, of course, will not prejudge what the WG will decide >> concerning MAP-T+E vs 4rd.) > You definitely overestimate my capabilities. I have very serious = doubts > that the whole WG would make a decision based on my comments. :-) Just meaning that by working a little on 4rd, you shouldn't be = considered by anyone as unfaithful to a group for which you did = important work. >> In particular, the map-dhcp draft which will soon be a WG document >> has a container which isn't present in 4rd. Would it be recommend to >> add one (and if yes for which reason(s))? > Here are some arguments why I think such a container make sense: > 1. Some parameters may apply to all rules. Currently there is only one > such parameter defined (transport mode), but others may appear once = MAP > evolves. > 2. Easier client-server interaction. With a single container, client > just signals support for MAP by requesting MAP_FLAGS option in ORO and > server responds with MAP_FLAGS option with whatever sub-options are > appropriate for a given client. Without container, client would be > expected to request several options (MAP_FLAGS, MAP_RULE, ...) in ORO. > But how is server is supposed to behave if a (misimplemented) client > requests only MAP_FLAGS for example? Or only asks for basic rules? = Such > approach makes sanity checking and error recovery more difficult. Point 2 understood, and in my understanding sufficient a justification. > 3. Multiple MAP domains. Sometimes there are discussions about = multiple > MAP domains. I haven't followed it closely, so I don't know if the > latest conclusion is that they make sense or not. However, even if MAP > authors (and the whole Softwires WG in general) decides that they are > not valid, there may be cases when one server will provide more than = one > domain anyway. Look at discussion in homenet and the problem with > multiple provisioning domains (like th concept of having a single home > router connected to multiple ISPs). Put it simply, a container option > makes multiple domains doable, if we ever decide that such a thing is > useful. > 4. It's easier for clients that don't support MAP. That is really a > minor point, but clients that don't support MAP will complain about = just > a single unknown option, not many. Sure, in a perfect world, client is > not expected to receive an option that it never requested. But there = are > people who configure their servers to force some options, regardless > requested or not. > 5. There's no actual bandwidth waste with container. There would be a > minimal overhead of 4 octets if it was just a container. However, = since > MAP and 4rd both require an option with some information, there's no = waste. > 6. Forward compatibility. Let's assume that 4rd is standardized. What > would you do if the next day after its publication someone comes with > cool new idea for improvement or optimization that requires passing > extra parameter to client? You would have to define a new option and = it > wouldn't work with old implementations. With a container, you have at > least some chances to make it work. One may say that this is a weak > argument, as old implementations will not know what to do with an > unknown option. However, many implementations handle contents of the > option be calling external script. So extending support for such extra > sub-option would require updating just a script, not the whole client > software. Related to point 2 in my understanding, and understood too. > If you take those arguments one by one, each of them can be considered > not important enough to warrant such a container, but if you add them > all up, it is just much easier do go with a container. At least that = is > my opinion on that subject. With the above, I am now convinced that the container is worth adding to = the 4rd specification. Thanks a lot. RD =20 >=20 > Cheers, > Tomek From stig@venaas.com Fri Jul 27 09:29:32 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67A321F8809 for ; Fri, 27 Jul 2012 09:29:32 -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 FFCU0ASq1g91 for ; Fri, 27 Jul 2012 09:29:32 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id BA29421F8808 for ; Fri, 27 Jul 2012 09:29:31 -0700 (PDT) Received: from [10.21.147.26] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D6FE07FD8; Fri, 27 Jul 2012 18:29:28 +0200 (CEST) Message-ID: <5012C1E6.8090005@venaas.com> Date: Fri, 27 Jul 2012 09:29:26 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" , softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 27 Jul 2012 16:29:32 -0000 Hi On 7/27/2012 4:48 AM, mohamed.boucadair@orange.com wrote: > Dear all, > > I really don't understand this issue. > It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). > > Anyway, below a tentative to explain the overall rationale: > > DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: > > * delivery of IPv4 connectivity over an IPv6-capable network. > * delivery of native IPv6 connectivity > * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. > > The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. > > The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: > > * delivery of IPv4 multicast content using native IPv6 multicast capabilities > * delivery of native IPv6 multicast content > > The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. I think I agree with the above. > A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. This is all I've been asking for. An update to abstract/introduction to indicate that it is a generic solution. And then say that DS-Lite is one of the use-cases. You can even say that the solution was developed to solve the problem for DS-Lite. All I want is to make it clear that it is a generic solution. Stig > Cheers, > Med > >> -----Message d'origine----- >> De : softwire issue tracker [mailto:trac+softwire@tools.ietf.org] >> Envoy : vendredi 13 juillet 2012 23:55 >> : draft-ietf-softwire-dslite-multicast@tools.ietf.org; >> sarikaya@ieee.org >> Cc : softwires@ietf.org >> Objet : Re: [softwire] #10: Nothing in common with DS-Lite >> >> #10: Nothing in common with DS-Lite >> >> Changes (by sarikaya@.): >> >> * owner: sarikaya@. => draft-ietf-softwire-dslite-multicast@. >> >> >> -- >> -------------------------+------------------------------------- >> ------------ >> Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- >> Type: defect | multicast@. >> Priority: major | Status: new >> Component: dslite- | Milestone: milestone1 >> multicast | Version: 2.0 >> Severity: In WG Last | Resolution: >> Call | >> Keywords: tunneling | >> -------------------------+------------------------------------- >> ------------ >> >> Ticket URL: >> >> softwire >> >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From sarikaya2012@gmail.com Fri Jul 27 09:48:20 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D0B21F877A for ; Fri, 27 Jul 2012 09:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 0a2golyc+BU1 for ; Fri, 27 Jul 2012 09:48:20 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59EAB21F8760 for ; Fri, 27 Jul 2012 09:48:20 -0700 (PDT) Received: by yenq13 with SMTP id q13so3716111yen.31 for ; Fri, 27 Jul 2012 09:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=373Umh1tz8BZwigiRpaXuUyNDGkYbh0z2yoxEpPHJBs=; b=GGjWnUpRxioCZRf5ggWvcKrjso7BEe9UFKM08lrdEHmd7V+egjZNn/NPn6qDeCGyaf JZkqRo/ZoF15pnpBTEM/ENVbkbDVdVG3XGR94mnT1SRJO+qqqJb8YVehDQz1aNwl+SML yuHOI6G2hjD29qBkXlmFrDFjIAs6je7G+EEByDZ1KUsTyv5pRI3LVRwfdRyRWIO8+oOL IyYf6pyi2EP5cKnVpkt+4U1zSV4Jz9zYC9mJEWehykwCHDprnq+a4AfHdmir282APCqj 0uT62JNLM9LdZtDS16kcw4yJCSk6sf8NnTcoORFxRAvSk9853nHBCQ6PJP0Id0JzPnjz zM9w== MIME-Version: 1.0 Received: by 10.50.17.230 with SMTP id r6mr2640840igd.63.1343407699524; Fri, 27 Jul 2012 09:48:19 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Fri, 27 Jul 2012 09:48:19 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 27 Jul 2012 11:48:19 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 16:48:21 -0000 Hi Med, My comments below. Please do not take them personal. No offense. Please, please. On Fri, Jul 27, 2012 at 6:48 AM, wrote: > Dear all, > > I really don't understand this issue. > It is even misplaced to have this comment at this stage, since this is a = document which has been adopted by the WG and the solution it specifies is = the same as the one reviewed by the WG prior to its adoption (i.e., since A= pril 2011). > > Anyway, below a tentative to explain the overall rationale: > > DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should b= e first seen as an IP connectivity service. This service can be defined as = follows: > > * delivery of IPv4 connectivity over an IPv6-capable network. > * delivery of native IPv6 connectivity > * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 ad= dress. > > The unicast portion of the service is defined in RFC6333 and is implement= ed using a tunnel + CGN. > > The multicast portion of the service is defined in draft-ietf-softwire-ds= lite-multicast. This portion of the service can be defined as follows: > > * delivery of IPv4 multicast content using native IPv6 multicast capabili= ties > * delivery of native IPv6 multicast content > > The solution proposed in draft-ietf-softwire-dslite-multicast is designed= to allow DS-Lite serviced customers be delivered IPv4 multicast services. > These are religious arguments. Translation multicast integrates well with several IPv6 transition technologies. MAP-T is one. NAT64 is another, 4rd also. But not MAP-E. Let's use translation multicast with those technologies. No matter what you want to believe, DS-Lite is a tunneling technology. Why do you think DS-Lite was standardized in Softwires WG? Same thing with 6rd. Remember softwire means tunnel. Translation has only been added to Softwires WG recently after Behave WG stopped working on it. > A side note, I agree with Stig and Woj the proposed solution can be gener= alized to cover any 4-6-4 scenario. This can be done easily by updating the= draft (abstract and introduction) to reflect the change of scope of use ca= ses. We didn't had the ambition to define a generic solution when we wrote = this draft, we focused mainly on the DS-Lite context. If there is no object= ion from the WG, we can implement that change. > So you agree that it is a generic solution and nothing in common with DS-Li= te. Regards, Behcet From wdec.ietf@gmail.com Sun Jul 29 02:38:25 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9275B21F86B8 for ; Sun, 29 Jul 2012 02:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.314 X-Spam-Level: X-Spam-Status: No, score=-3.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn2YKFSOjSay for ; Sun, 29 Jul 2012 02:38:25 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC22C21F86B2 for ; Sun, 29 Jul 2012 02:38:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4084295vbb.31 for ; Sun, 29 Jul 2012 02:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=puFPqpUr/lfbOD4K3TifhUyZcWDjvVukEgusGRYPfFs=; b=zvra4kGZ++aPPdnAigD9HIt9iN7a+Bu7xQuu+bM61fYJiHAB60jFFpajwxqZLl168+ SQpjsEiDCWMq2ZjA3/Dn3SpW5fJLTDqJM1i3Rij2/YY91pw7QiQ3TRDxYm6o363eCgLs FYvOG43+Pz3mF93S1Sd3ShDhGWt5sLMcU/lw3fyWZYfMNclo3cVtcLTpzEv3DwMl9ln3 xh1mD0Lk48YQfD+6b3071jIDZ2DE5sT+HD6FIUew8BBC1l62DazFAm166eiEmIMJxVTW U8h3W6+McJx1b5s6/CeAEUdWjRFdQoIlPReckAWk924kBITiwxZ5k5DkujlOJ/lSATmb AmLA== MIME-Version: 1.0 Received: by 10.52.97.230 with SMTP id ed6mr6683473vdb.65.1343554704452; Sun, 29 Jul 2012 02:38:24 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Sun, 29 Jul 2012 02:38:24 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 Jul 2012 11:38:24 +0200 Message-ID: From: Wojciech Dec To: Softwires-wg Content-Type: multipart/alternative; boundary=20cf307ac437e52bc704c5f4b438 Cc: Softwire Chairs Subject: Re: [Softwires] IETF84 - MAP Interop event X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 29 Jul 2012 09:38:25 -0000 --20cf307ac437e52bc704c5f4b438 Content-Type: text/plain; charset=ISO-8859-1 Hi All, small update regarding the location of the MAP Interop event: We'll be making use of the IETF Terminal room. We're have indication that 5 implementations will be tested. We'll be documenting the results. Regards, Woj. On 24 July 2012 17:51, Wojciech Dec wrote: > Hello All, > > at the upcoming IETF84 meeting we'll be holding a first open MAP Interop > event to which we would like to cordially invite any implementers & > implementations of MAP, besides of course interested WG members. The goal > of the event will be to verify basic MAP CE-BR communication use-cases, > covering both -T and -E. We currently anticipate a number of different > implementations to participate. > > The Interop will commence on Tuesday 31, 2012 starting at 1300. The exact > room/location will be communicated shortly. An ethernet switch & Internet > connectivity will be provided, but for the rest please bring your own MAP > device(s) and any end-host devices that can help with the testing. > > Given that the set-up activities are likely to commence earlier, please > let us know (by unicast) if you'd be available to participate or help in > such preparations. > > Regards, > Woj. > > > --20cf307ac437e52bc704c5f4b438 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

small update regarding the location of the MAP Interop event= : We'll be making use of the IETF Terminal room. We're have indicat= ion that 5 implementations will be tested.

We'll be documenting = the results.

Regards,
Woj.


On 24 July 2012 = 17:51, Wojciech Dec <wdec.ietf@gmail.com> wrote:
Hello All,

at the upcoming IETF84 meeting we'll be holding a fir= st open MAP Interop event to which we would like to cordially invite any im= plementers & implementations of MAP, besides of course interested WG me= mbers. The goal of the event will be to verify basic MAP CE-BR communicatio= n use-cases, covering both -T and -E. We currently anticipate a number of d= ifferent implementations to participate.

The Interop will commence on Tuesday 31, 2012 starting at 1300. The exa= ct room/location will be communicated shortly. An ethernet switch & Int= ernet connectivity will be provided, but for the rest please bring your own= MAP device(s) and any end-host devices that can help with the testing.

Given that the set-up activities are likely to commence earlier, please= let us know (by unicast) if you'd be available to participate or help = in such preparations.

Regards,
Woj.



--20cf307ac437e52bc704c5f4b438-- From mohamed.boucadair@orange.com Mon Jul 30 00:06:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D03C21F8562 for ; Mon, 30 Jul 2012 00:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.044, 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 KHvI0xG-C7ls for ; Mon, 30 Jul 2012 00:06:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1941821F8568 for ; Mon, 30 Jul 2012 00:06:26 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B737B2640D8; Mon, 30 Jul 2012 09:06:25 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 9769D27C066; Mon, 30 Jul 2012 09:06:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 30 Jul 2012 09:06:17 +0200 From: To: Stig Venaas Date: Mon, 30 Jul 2012 09:06:16 +0200 Thread-Topic: [Softwires] [softwire] #10: Nothing in common with DS-Lite Thread-Index: Ac1sFP0AoWTYX4JwS82ZCJxIFNF54gCDGxtg Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E801@PUEXCB1B.nanterre.francetelecom.fr> References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> <5012C1E6.8090005@venaas.com> In-Reply-To: <5012C1E6.8090005@venaas.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "softwires@ietf.org" , softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2012 07:06:29 -0000 Hi Stig, Wouldn't be sufficient enough to add this sentence to the abstract and the = Introduction: "The proposed solution can be deployed for other 4-6-4 use cases." Thanks.=20 Cheers, Med=20 >-----Message d'origine----- >De : Stig Venaas [mailto:stig@venaas.com]=20 >Envoy=E9 : vendredi 27 juillet 2012 18:29 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : softwire issue tracker;=20 >draft-ietf-softwire-dslite-multicast@tools.ietf.org;=20 >sarikaya@ieee.org; softwires@ietf.org >Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite > >Hi > >On 7/27/2012 4:48 AM, mohamed.boucadair@orange.com wrote: >> Dear all, >> >> I really don't understand this issue. >> It is even misplaced to have this comment at this stage,=20 >since this is a document which has been adopted by the WG and=20 >the solution it specifies is the same as the one reviewed by=20 >the WG prior to its adoption (i.e., since April 2011). >> >> Anyway, below a tentative to explain the overall rationale: >> >> DS-Lite model can not be reduced to a CGN/AFTR + tunnel.=20 >DS-Lite should be first seen as an IP connectivity service.=20 >This service can be defined as follows: >> >> * delivery of IPv4 connectivity over an IPv6-capable network. >> * delivery of native IPv6 connectivity >> * DS-Lite serviced customers are assigned with IPv6 prefix=20 >and no IPv4 address. >> >> The unicast portion of the service is defined in RFC6333 and=20 >is implemented using a tunnel + CGN. >> >> The multicast portion of the service is defined in=20 >draft-ietf-softwire-dslite-multicast. This portion of the=20 >service can be defined as follows: >> >> * delivery of IPv4 multicast content using native IPv6=20 >multicast capabilities >> * delivery of native IPv6 multicast content >> >> The solution proposed in=20 >draft-ietf-softwire-dslite-multicast is designed to allow=20 >DS-Lite serviced customers be delivered IPv4 multicast services. > >I think I agree with the above. > >> A side note, I agree with Stig and Woj the proposed solution=20 >can be generalized to cover any 4-6-4 scenario. This can be=20 >done easily by updating the draft (abstract and introduction)=20 >to reflect the change of scope of use cases. We didn't had the=20 >ambition to define a generic solution when we wrote this=20 >draft, we focused mainly on the DS-Lite context. If there is=20 >no objection from the WG, we can implement that change. > >This is all I've been asking for. An update to abstract/introduction to >indicate that it is a generic solution. And then say that=20 >DS-Lite is one >of the use-cases. You can even say that the solution was developed to >solve the problem for DS-Lite. All I want is to make it clear=20 >that it is >a generic solution. > >Stig > >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : softwire issue tracker [mailto:trac+softwire@tools.ietf.org] >>> Envoy=E9 : vendredi 13 juillet 2012 23:55 >>> =C0 : draft-ietf-softwire-dslite-multicast@tools.ietf.org; >>> sarikaya@ieee.org >>> Cc : softwires@ietf.org >>> Objet : Re: [softwire] #10: Nothing in common with DS-Lite >>> >>> #10: Nothing in common with DS-Lite >>> >>> Changes (by sarikaya@.): >>> >>> * owner: sarikaya@. =3D> draft-ietf-softwire-dslite-multicast@. >>> >>> >>> -- >>> -------------------------+------------------------------------- >>> ------------ >>> Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- >>> Type: defect | multicast@. >>> Priority: major | Status: new >>> Component: dslite- | Milestone: milestone1 >>> multicast | Version: 2.0 >>> Severity: In WG Last | Resolution: >>> Call | >>> Keywords: tunneling | >>> -------------------------+------------------------------------- >>> ------------ >>> >>> Ticket URL: >>> >>> softwire >>> >>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > >= From mohamed.boucadair@orange.com Mon Jul 30 05:04:42 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E6521F874C for ; Mon, 30 Jul 2012 05:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Z2G3b5NAAdtk for ; Mon, 30 Jul 2012 05:04:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id D1FEC21F86FF for ; Mon, 30 Jul 2012 05:04:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 21E2A2DC1DA; Mon, 30 Jul 2012 14:04:41 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0494E23804B; Mon, 30 Jul 2012 14:04:41 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.11]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Mon, 30 Jul 2012 14:04:32 +0200 From: To: "sarikaya@ieee.org" Date: Mon, 30 Jul 2012 14:04:32 +0200 Thread-Topic: [softwire] #10: Nothing in common with DS-Lite Thread-Index: Ac1sF55VzUxiFMQgSWC8Rtki7v7akACMxBNA Message-ID: <94C682931C08B048B7A8645303FDC9F36E4A17E928@PUEXCB1B.nanterre.francetelecom.fr> References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: "softwires@ietf.org" , softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2012 12:04:42 -0000 Hi Behcet, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : vendredi 27 juillet 2012 18:48 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : softwire issue tracker;=20 >draft-ietf-softwire-dslite-multicast@tools.ietf.org; softwires@ietf.org >Objet : Re: [softwire] #10: Nothing in common with DS-Lite > >Hi Med, > >My comments below. Please do not take them personal. No offense. >Please, please. > >On Fri, Jul 27, 2012 at 6:48 AM, wrote: >> Dear all, >> >> I really don't understand this issue. >> It is even misplaced to have this comment at this stage,=20 >since this is a document which has been adopted by the WG and=20 >the solution it specifies is the same as the one reviewed by=20 >the WG prior to its adoption (i.e., since April 2011). >> >> Anyway, below a tentative to explain the overall rationale: >> >> DS-Lite model can not be reduced to a CGN/AFTR + tunnel.=20 >DS-Lite should be first seen as an IP connectivity service.=20 >This service can be defined as follows: >> >> * delivery of IPv4 connectivity over an IPv6-capable network. >> * delivery of native IPv6 connectivity >> * DS-Lite serviced customers are assigned with IPv6 prefix=20 >and no IPv4 address. >> >> The unicast portion of the service is defined in RFC6333 and=20 >is implemented using a tunnel + CGN. >> >> The multicast portion of the service is defined in=20 >draft-ietf-softwire-dslite-multicast. This portion of the=20 >service can be defined as follows: >> >> * delivery of IPv4 multicast content using native IPv6=20 >multicast capabilities >> * delivery of native IPv6 multicast content >> >> The solution proposed in=20 >draft-ietf-softwire-dslite-multicast is designed to allow=20 >DS-Lite serviced customers be delivered IPv4 multicast services. >> > >These are religious arguments. >Translation multicast integrates well with several IPv6 transition >technologies. MAP-T is one. NAT64 is another, 4rd also. But not MAP-E. >Let's use translation multicast with those technologies. > >No matter what you want to believe, DS-Lite is a tunneling technology. >Why do you think DS-Lite was standardized in Softwires WG? Same thing >with 6rd. >Remember softwire means tunnel. >Translation has only been added to Softwires WG recently after Behave >WG stopped working on it. Med: I failed to get the point you are trying to make. Do you want draft-ie= tf-softwire-dslite-multicast to cover the translation case also? Let me remind that draft-ietf-softwire-dslite-multicast covers only the enc= apsulation scheme: IPv4 multicast packets are encapsulated in IPv6 ones. From wdec.ietf@gmail.com Mon Jul 30 12:36:01 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CABC11E81C9 for ; Mon, 30 Jul 2012 12:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEBVfvJq2EIJ for ; Mon, 30 Jul 2012 12:36:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F91B11E81C7 for ; Mon, 30 Jul 2012 12:36:00 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5357747vbb.31 for ; Mon, 30 Jul 2012 12:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8HmQldwNytRgXsvBNXcZREk0LIor5UzgJpcrxnrl/0=; b=JhrCQayz5CFOALjDYeoVCJfoZdoV5VgAquRiHG34X+c3QbqaKvV4AYnWe1d9s1Iwfr nZl5f4mC2n9A0M1R3DpLe/DUnwQ7u06/Apy7RROnxwNEWRkKCJmm/BB+1S1BmpBIz/QF VXSRHAMya9AT8gpbhcpk+8WSEFVJiOq+kFWNdzW/YxrYnDWNn1UTfMIZbCb9MqoS8Krc E2rGNc4xFUgIqglBHkac7UoEEt+MHrPeuGbYwdXbY50mzTzG58tngDagRtLknSvVjQzw gRVKHbtzUVNN53bI/8lu62kpXU2c260aGdIZO8pUcxhH2N4AG8AbZD6u5OYiuOFyd83e m27Q== MIME-Version: 1.0 Received: by 10.58.133.48 with SMTP id oz16mr273402veb.1.1343676959798; Mon, 30 Jul 2012 12:35:59 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Mon, 30 Jul 2012 12:35:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 21:35:59 +0200 Message-ID: From: Wojciech Dec To: Softwires-wg Content-Type: multipart/alternative; boundary=047d7b6d7f42e1b65f04c6112b90 Cc: Softwire Chairs Subject: Re: [Softwires] IETF84 - MAP Interop event X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 30 Jul 2012 19:36:01 -0000 --047d7b6d7f42e1b65f04c6112b90 Content-Type: text/plain; charset=ISO-8859-1 Hi All, small update: After an on0site visit it's been determined that we'll relocate the MAP interop to room Plaza-C Regards, Woj. On 29 July 2012 11:38, Wojciech Dec wrote: > Hi All, > > small update regarding the location of the MAP Interop event: We'll be > making use of the IETF Terminal room. We're have indication that 5 > implementations will be tested. > > We'll be documenting the results. > > Regards, > Woj. > > > > On 24 July 2012 17:51, Wojciech Dec wrote: > >> Hello All, >> >> at the upcoming IETF84 meeting we'll be holding a first open MAP Interop >> event to which we would like to cordially invite any implementers & >> implementations of MAP, besides of course interested WG members. The goal >> of the event will be to verify basic MAP CE-BR communication use-cases, >> covering both -T and -E. We currently anticipate a number of different >> implementations to participate. >> >> The Interop will commence on Tuesday 31, 2012 starting at 1300. The exact >> room/location will be communicated shortly. An ethernet switch & Internet >> connectivity will be provided, but for the rest please bring your own MAP >> device(s) and any end-host devices that can help with the testing. >> >> Given that the set-up activities are likely to commence earlier, please >> let us know (by unicast) if you'd be available to participate or help in >> such preparations. >> >> Regards, >> Woj. >> >> >> > --047d7b6d7f42e1b65f04c6112b90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

small update: After an on0site visit it's been determine= d that we'll relocate the MAP interop to room Plaza-C

Regards,Woj.

On 29 July 2012 11:38, Wojciech De= c <wdec.ietf@gmail.com> wrote:
Hi All,

small update regarding the lo= cation of the MAP Interop event: We'll be making use of the IETF Termin= al room. We're have indication that 5 implementations will be tested.
We'll be documenting the results.

Regards,
Woj.



On 24 July 2012 17:51, Wojciech Dec <wdec.ietf@g= mail.com> wrote:
Hello All,

at the upcoming IETF84 meeting we'll be holding a fir= st open MAP Interop event to which we would like to cordially invite any im= plementers & implementations of MAP, besides of course interested WG me= mbers. The goal of the event will be to verify basic MAP CE-BR communicatio= n use-cases, covering both -T and -E. We currently anticipate a number of d= ifferent implementations to participate.

The Interop will commence on Tuesday 31, 2012 starting at 1300. The exa= ct room/location will be communicated shortly. An ethernet switch & Int= ernet connectivity will be provided, but for the rest please bring your own= MAP device(s) and any end-host devices that can help with the testing.

Given that the set-up activities are likely to commence earlier, please= let us know (by unicast) if you'd be available to participate or help = in such preparations.

Regards,
Woj.




--047d7b6d7f42e1b65f04c6112b90-- From sarikaya2012@gmail.com Mon Jul 30 16:26:22 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6E911E80DF for ; Mon, 30 Jul 2012 16:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 svUw8EDIljj8 for ; Mon, 30 Jul 2012 16:26:21 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8349F11E80C5 for ; Mon, 30 Jul 2012 16:26:21 -0700 (PDT) Received: by yhq56 with SMTP id 56so5892635yhq.31 for ; Mon, 30 Jul 2012 16:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=eyhEX36Qu6enw+fJbzPDXtB8LHBuLlLS2ef4Ms/YigA=; b=SzjUZGs2uPWbm4kVY/HRAiHKfiR010EJWUyN2dUOuGQx5RilNZEqM8EhwStcQMF/17 mqDvZTPxttB/+JDb3EtfFWb0pOQYpP3C3n8HcCFWF0rJDLm8/X/NmzLNCrqPicyj4kLM S29aI8SDQAIXbfg6pgUKaN4c/zl/+7k/KEPJJ8+ILQeDBGqkAXBnYuzqkiQ67F8QCamn P2QO790XbWlxbKB2EGAnE8up4X8cQUOVcZIqiEsSkNg8HZJ1i+Fw76w1DpYaq/3BXCCi rNNW5YGC6WUwa8Y+qBUE6q8Aqi9lxjd8Dhjp/AqDspUebfNzm3BjLshkjYmwvSTeZOD1 3h7w== MIME-Version: 1.0 Received: by 10.50.194.132 with SMTP id hw4mr251401igc.63.1343690780641; Mon, 30 Jul 2012 16:26:20 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Mon, 30 Jul 2012 16:26:20 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E4A17E928@PUEXCB1B.nanterre.francetelecom.fr> References: <060.03db91f96d17fb6834f0bc0ce34fe6b1@tools.ietf.org> <075.791032c8f7af939e50f982ec7f6190e2@tools.ietf.org> <94C682931C08B048B7A8645303FDC9F36E4A17E625@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E4A17E928@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 30 Jul 2012 18:26:20 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" , softwire issue tracker , "draft-ietf-softwire-dslite-multicast@tools.ietf.org" Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite 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, 30 Jul 2012 23:26:22 -0000 On Mon, Jul 30, 2012 at 7:04 AM, wrote: > Hi Behcet, > > Please see inline. > > Cheers, > Med > >>-----Message d'origine----- >>De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com] >>Envoy=E9 : vendredi 27 juillet 2012 18:48 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : softwire issue tracker; >>draft-ietf-softwire-dslite-multicast@tools.ietf.org; softwires@ietf.org >>Objet : Re: [softwire] #10: Nothing in common with DS-Lite >> >>Hi Med, >> >>My comments below. Please do not take them personal. No offense. >>Please, please. >> >>On Fri, Jul 27, 2012 at 6:48 AM, wrote: >>> Dear all, >>> >>> I really don't understand this issue. >>> It is even misplaced to have this comment at this stage, >>since this is a document which has been adopted by the WG and >>the solution it specifies is the same as the one reviewed by >>the WG prior to its adoption (i.e., since April 2011). >>> >>> Anyway, below a tentative to explain the overall rationale: >>> >>> DS-Lite model can not be reduced to a CGN/AFTR + tunnel. >>DS-Lite should be first seen as an IP connectivity service. >>This service can be defined as follows: >>> >>> * delivery of IPv4 connectivity over an IPv6-capable network. >>> * delivery of native IPv6 connectivity >>> * DS-Lite serviced customers are assigned with IPv6 prefix >>and no IPv4 address. >>> >>> The unicast portion of the service is defined in RFC6333 and >>is implemented using a tunnel + CGN. >>> >>> The multicast portion of the service is defined in >>draft-ietf-softwire-dslite-multicast. This portion of the >>service can be defined as follows: >>> >>> * delivery of IPv4 multicast content using native IPv6 >>multicast capabilities >>> * delivery of native IPv6 multicast content >>> >>> The solution proposed in >>draft-ietf-softwire-dslite-multicast is designed to allow >>DS-Lite serviced customers be delivered IPv4 multicast services. >>> >> >>These are religious arguments. >>Translation multicast integrates well with several IPv6 transition >>technologies. MAP-T is one. NAT64 is another, 4rd also. But not MAP-E. >>Let's use translation multicast with those technologies. >> >>No matter what you want to believe, DS-Lite is a tunneling technology. >>Why do you think DS-Lite was standardized in Softwires WG? Same thing >>with 6rd. >>Remember softwire means tunnel. >>Translation has only been added to Softwires WG recently after Behave >>WG stopped working on it. > > Med: I failed to get the point you are trying to make. Do you >want draft= -ietf-softwire-dslite-multicast to cover the translation >case also? Really? Take a look at Fig. 1, IGMP Report (join) received at so-called mB4 becomes MLD Report sent upstre= am. How is this encapsulation? > Let me remind that draft-ietf-softwire-dslite-multicast covers only the e= ncapsulation scheme: IPv4 multicast packets are encapsulated in IPv6 ones. > You are talking about multicast data, and it is curious why you are doing i= t? Anyway, what I want is clear: draft-sarikaya-softwire-dslitemulticast-01.txt is the solution that integrates with DS-Lite and that is the solution we need :-). Regards, Behcet From wang.cui1@zte.com.cn Mon Jul 30 19:25:38 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DA411E80A4 for ; Mon, 30 Jul 2012 19:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.343 X-Spam-Level: X-Spam-Status: No, score=-99.343 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 9a3fXwvum8xq for ; Mon, 30 Jul 2012 19:25:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA111E809A for ; Mon, 30 Jul 2012 19:25:36 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 10723271095904; Tue, 31 Jul 2012 10:14:29 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 228.271095904; Tue, 31 Jul 2012 10:25:28 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q6V2PSO1006840 for ; Tue, 31 Jul 2012 10:25:28 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) To: Softwires WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Tue, 31 Jul 2012 10:25:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-31 10:25:24, Serialize complete at 2012-07-31 10:25:24 Content-Type: multipart/alternative; boundary="=_alternative 000D2FDD48257A4C_=" X-MAIL: mse01.zte.com.cn q6V2PSO1006840 Subject: [Softwires] draft-hu-softwire-multicast-radius-ext-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:25:38 -0000 This is a multipart message in MIME format. --=_alternative 000D2FDD48257A4C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIEFsbA0KDQogIEhlcmUsIHdlJ3ZlIHVwZGF0ZWQgdGhlIG11bHRpY2FzdCByYWRpdXMgYXR0 cmlidXRlIGRyYWZ0cy4gDQogDQogIEluIHRoZSBkcmFmdCwgd2UgdXNlIG1hbnkgdGVybWlub2xv Z3kgobBEUy1MaXRlIE11bHRpY2FzdKGxLCBhZnRlciANCltJLUQuaWV0Zi1zb2Z0d2lyZS1kc2xp dGUtbXVsdGljYXN0XSB1cGRhdGVzIGFjY29yZGluZyB0byB0aGUgbWFpbGluZyBsaXN0IA0KLCB3 ZSdsbCB1cGRhdGUgdGhlIGFic3RyYWN0IGFuZCBpbnRyb2R1Y3Rpb24gaW4gb3VyIGRyYWZ0LiAN Cg0KICBBbnkgY29tbWVudCBpcyB3ZWxjb21lICwgdGhhbmtzLg0KDQpXYW5nLg0KDQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWh1LXNvZnR3aXJlLW11bHRpY2FzdC1yYWRpdXMtZXh0 LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDdWkgV2FuZyBhbmQg cG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgICAgICAg ICAgIGRyYWZ0LWh1LXNvZnR3aXJlLW11bHRpY2FzdC1yYWRpdXMtZXh0DQpSZXZpc2lvbjogICAg ICAgICAgICAgICAgIDAxDQpUaXRsZTogICAgICAgICAgICAgICAgICAgICAgICAgICAgUkFESVVT IEV4dGVuc2lvbnMgZm9yIERTLUxpdGUgTXVsdGljYXN0DQpDcmVhdGlvbiBkYXRlOiAgICAgICAg ICAgIDIwMTItMDctMTMNCldHIElEOiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTMNClVSTDogICAgICAgICAgICAgDQpo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odS1zb2Z0d2lyZS1tdWx0 aWNhc3QtcmFkaXVzLWV4dC0wMS50eHQNCg0KU3RhdHVzOiAgICAgICAgICANCmh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHUtc29mdHdpcmUtbXVsdGljYXN0LXJhZGl1cy1l eHQNCkh0bWxpemVkOiAgICAgICAgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o dS1zb2Z0d2lyZS1tdWx0aWNhc3QtcmFkaXVzLWV4dC0wMQ0KRGlmZjogICAgICAgICAgICANCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaHUtc29mdHdpcmUtbXVsdGlj YXN0LXJhZGl1cy1leHQtMDENCg0KDQpBYnN0cmFjdDoNCiAgIERTLUxpdGUgTXVsdGljYXN0IFtJ LUQuaWV0Zi1zb2Z0d2lyZS1kc2xpdGUtbXVsdGljYXN0XSBpcyBhIHNvbHV0aW9uDQogICB0byBv ZmZlciBtdWx0aWNhc3Qgc2VydmljZSBvbiBEUy1saXRlIGNpcmN1bXN0YW5jZS4gIERTLUxpdGUN CiAgIE11bHRpY2FzdCByZXF1aXJlcyBwcmUtY29uZmlndXJhdGlvbiBvZiB0aGUgSVB2NC1lbWJl ZGRlZCBJUHY2DQogICBwcmVmaXhlcyBpbmZvcm1hdGlvbiBvbiB0aGUgbXVsdGljYXN0IEJhc2lj IEJyaWRnaW5nIEJyb2FkQmFuZCAobUI0KQ0KICAgZWxlbWVudCBhbmQgbXVsdGljYXN0IEFkZHJl c3MgRmFtaWx5IFRyYW5zbGF0aW9uIFJvdXRlcihtQUZUUikuICBUaGlzDQogICBkb2N1bWVudCBz cGVjaWZpZXMgYSBuZXcgUmVtb3RlIEF1dGhlbnRpY2F0aW9uIERpYWwtSW4gVXNlciBTZXJ2aWNl DQogICAoUkFESVVTKSBhdHRyaWJ1dGUgdG8gY2FycnkgdGhlIERTLUxpdGUgbXVsdGljYXN0IHBy ZWZpeGVzDQogICBpbmZvcm1hdGlvbjsgdGhlIFJBRElVUyBhdHRyaWJ1dGUgaXMgZGVmaW5lZCBi YXNlZCBvbiB0aGUgZXF1aXZhbGVudA0KICAgREhDUHY2IE9QVElPTl9QUkVGSVg2NCBvcHRpb24u DQoNCiAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0 aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1h aWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdl ZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ug b2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVu dCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRp c3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwg cGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo= --=_alternative 000D2FDD48257A4C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBBbGw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyA8L2ZvbnQ+PHR0Pjxm b250IHNpemU9Mj5IZXJlLA0Kd2UndmUgdXBkYXRlZCB0aGUgbXVsdGljYXN0IHJhZGl1cyBhdHRy aWJ1dGUgZHJhZnRzLiA8YnI+DQogPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m bmJzcDsgSW4gdGhlIGRyYWZ0LCB3ZSB1c2UgbWFueSB0ZXJtaW5vbG9neSChsERTLUxpdGUNCk11 bHRpY2FzdKGxLCBhZnRlciBbSS1ELmlldGYtc29mdHdpcmUtZHNsaXRlLW11bHRpY2FzdF0gdXBk YXRlcyBhY2NvcmRpbmcNCnRvIHRoZSBtYWlsaW5nIGxpc3QgLCB3ZSdsbCB1cGRhdGUgdGhlIGFi c3RyYWN0IGFuZCBpbnRyb2R1Y3Rpb24gaW4gb3VyDQpkcmFmdC4gJm5ic3A7ICZuYnNwOzxicj4N Cjxicj4NCiAmbmJzcDtBbnkgY29tbWVudCBpcyB3ZWxjb21lICwgdGhhbmtzLjxicj4NCjxicj4N CldhbmcuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+ DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHUtc29mdHdpcmUtbXVsdGljYXN0LXJhZGl1 cy1leHQtMDEudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDdWkg V2FuZyBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpG aWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ZHJhZnQtaHUtc29mdHdpcmUtbXVsdGljYXN0LXJhZGl1cy1leHQ8YnI+ DQpSZXZpc2lvbjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7MDE8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClJBRElVUyBFeHRlbnNpb25z IGZvciBEUy1MaXRlIE11bHRpY2FzdDxicj4NCkNyZWF0aW9uIGRhdGU6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzIwMTItMDct MTM8YnI+DQpXRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCkluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCk51bWJlciBv ZiBwYWdlczogMTM8YnI+DQpVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1LXNvZnR3 aXJlLW11bHRpY2FzdC1yYWRpdXMtZXh0LTAxLnR4dDxicj4NClN0YXR1czogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaHUtc29mdHdpcmUtbXVsdGljYXN0LXJhZGl1cy1leHQ8YnI+DQpIdG1saXplZDogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHUt c29mdHdpcmUtbXVsdGljYXN0LXJhZGl1cy1leHQtMDE8YnI+DQpEaWZmOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaHUtc29mdHdpcmUtbXVsdGljYXN0LXJhZGl1cy1leHQtMDE8YnI+DQo8YnI+ DQpBYnN0cmFjdDo8YnI+DQogJm5ic3A7IERTLUxpdGUgTXVsdGljYXN0IFtJLUQuaWV0Zi1zb2Z0 d2lyZS1kc2xpdGUtbXVsdGljYXN0XSBpcyBhIHNvbHV0aW9uPGJyPg0KICZuYnNwOyB0byBvZmZl ciBtdWx0aWNhc3Qgc2VydmljZSBvbiBEUy1saXRlIGNpcmN1bXN0YW5jZS4gJm5ic3A7RFMtTGl0 ZTxicj4NCiAmbmJzcDsgTXVsdGljYXN0IHJlcXVpcmVzIHByZS1jb25maWd1cmF0aW9uIG9mIHRo ZSBJUHY0LWVtYmVkZGVkIElQdjY8YnI+DQogJm5ic3A7IHByZWZpeGVzIGluZm9ybWF0aW9uIG9u IHRoZSBtdWx0aWNhc3QgQmFzaWMgQnJpZGdpbmcgQnJvYWRCYW5kDQoobUI0KTxicj4NCiAmbmJz cDsgZWxlbWVudCBhbmQgbXVsdGljYXN0IEFkZHJlc3MgRmFtaWx5IFRyYW5zbGF0aW9uIFJvdXRl cihtQUZUUikuDQombmJzcDtUaGlzPGJyPg0KICZuYnNwOyBkb2N1bWVudCBzcGVjaWZpZXMgYSBu ZXcgUmVtb3RlIEF1dGhlbnRpY2F0aW9uIERpYWwtSW4gVXNlciBTZXJ2aWNlPGJyPg0KICZuYnNw OyAoUkFESVVTKSBhdHRyaWJ1dGUgdG8gY2FycnkgdGhlIERTLUxpdGUgbXVsdGljYXN0IHByZWZp eGVzPGJyPg0KICZuYnNwOyBpbmZvcm1hdGlvbjsgdGhlIFJBRElVUyBhdHRyaWJ1dGUgaXMgZGVm aW5lZCBiYXNlZCBvbiB0aGUgZXF1aXZhbGVudDxicj4NCiAmbmJzcDsgREhDUHY2IE9QVElPTl9Q UkVGSVg2NCBvcHRpb24uPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVU RiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUm bmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21h aWwmbmJzcDsoYW5kJm5ic3A7YW55Jm5ic3A7YXR0YWNobWVudCZuYnNwO3RyYW5zbWl0dGVkJm5i c3A7aGVyZXdpdGgpJm5ic3A7aXMmbmJzcDtwcml2aWxlZ2VkJm5ic3A7YW5kJm5ic3A7Y29uZmlk ZW50aWFsJm5ic3A7YW5kJm5ic3A7aXMmbmJzcDtpbnRlbmRlZCZuYnNwO2ZvciZuYnNwO3RoZSZu YnNwO2V4Y2x1c2l2ZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7YWRkcmVzc2VlKHMp LiZuYnNwOyZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7YW4mbmJzcDtp bnRlbmRlZCZuYnNwO3JlY2lwaWVudCwmbmJzcDthbnkmbmJzcDtkaXNjbG9zdXJlLCZuYnNwO3Jl cHJvZHVjdGlvbiwmbmJzcDtkaXN0cmlidXRpb24mbmJzcDtvciZuYnNwO290aGVyJm5ic3A7ZGlz c2VtaW5hdGlvbiZuYnNwO29yJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmZvcm1h dGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lzJm5ic3A7c3RyaWN0bHkmbmJzcDtwcm9oaWJpdGVk LiZuYnNwOyZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhp cyZuYnNwO21haWwmbmJzcDtpbiZuYnNwO2Vycm9yLCZuYnNwO3BsZWFzZSZuYnNwO2RlbGV0ZSZu YnNwO2l0Jm5ic3A7YW5kJm5ic3A7bm90aWZ5Jm5ic3A7dXMmbmJzcDtpbW1lZGlhdGVseS4NCg0K PC9wcmU+ --=_alternative 000D2FDD48257A4C_=-- From simon.perreault@viagenie.ca Tue Jul 31 13:03:32 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4B921F889C for ; Tue, 31 Jul 2012 13:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, 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 LjBolbPd-5w6 for ; Tue, 31 Jul 2012 13:03:31 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6DC21F8868 for ; Tue, 31 Jul 2012 13:03:31 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:80:1981:90e9:930:311d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1C23A41364 for ; Tue, 31 Jul 2012 16:03:31 -0400 (EDT) Message-ID: <50183A12.4040301@viagenie.ca> Date: Tue, 31 Jul 2012 13:03:30 -0700 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 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] IETF84 - MAP Interop event X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 20:03:32 -0000 We're in Plaza C waiting for implementers. Are we in the right place? Simon Le 2012-07-30 12:35, Wojciech Dec a crit : > Hi All, > > small update: After an on0site visit it's been determined that we'll > relocate the MAP interop to room Plaza-C > > Regards, > Woj. > > On 29 July 2012 11:38, Wojciech Dec > wrote: > > Hi All, > > small update regarding the location of the MAP Interop event: We'll > be making use of the IETF Terminal room. We're have indication that > 5 implementations will be tested. > > We'll be documenting the results. > > Regards, > Woj. > > > > On 24 July 2012 17:51, Wojciech Dec > wrote: > > Hello All, > > at the upcoming IETF84 meeting we'll be holding a first open MAP > Interop event to which we would like to cordially invite any > implementers & implementations of MAP, besides of course > interested WG members. The goal of the event will be to verify > basic MAP CE-BR communication use-cases, covering both -T and > -E. We currently anticipate a number of different > implementations to participate. > > The Interop will commence on Tuesday 31, 2012 starting at 1300. > The exact room/location will be communicated shortly. An > ethernet switch & Internet connectivity will be provided, but > for the rest please bring your own MAP device(s) and any > end-host devices that can help with the testing. > > Given that the set-up activities are likely to commence earlier, > please let us know (by unicast) if you'd be available to > participate or help in such preparations. > > Regards, > Woj. > > > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From wdec.ietf@gmail.com Tue Jul 31 15:52:19 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A78911E8129 for ; Tue, 31 Jul 2012 15:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F46i5cLQhfIV for ; Tue, 31 Jul 2012 15:52:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA3B711E80D1 for ; Tue, 31 Jul 2012 15:52:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6881745vbb.31 for ; Tue, 31 Jul 2012 15:52: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=HbEIFLe1ugZjur4WPL+tQZaJ5sIJPerMqryHtOR54D8=; b=KqsozhDHb76h3EdXgtDfgTtgq+4vNXyhLStrorTgWlVWNRQ3QQvC5UE5UImzaPDEzI fZk0uEaYktrUXdkA75Cc7L6yt1OzM0by0scJY1/pbOgZ+pA9RjkZTv7VZ+1rV1h8sStb 6munGp+shtN0sZK4P8Pbya/0Z5orgu1mNAAEWDLlZL3MGbh2gYMSPZmA/Glcp9FnAUSw PSmQsCKzrmDQZkwAAv+poxpXvf26DdWImRruPvFdSj8usfe7AYpTT6mfpOl0eF7St1TU Ooz/C09td3exqaWKH5BPb/k4y6BQRl6esf4rPU/gOWnZOcBzUDq+ixWkchvOO/f0r1xY LvxA== MIME-Version: 1.0 Received: by 10.58.151.197 with SMTP id us5mr4003234veb.14.1343775138157; Tue, 31 Jul 2012 15:52:18 -0700 (PDT) Received: by 10.52.183.42 with HTTP; Tue, 31 Jul 2012 15:52:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Jul 2012 15:52:18 -0700 Message-ID: From: Wojciech Dec To: Softwires-wg Content-Type: multipart/alternative; boundary=047d7b6d8354c493e504c6280717 Cc: Softwire Chairs Subject: Re: [Softwires] IETF84 - MAP Interop event X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 31 Jul 2012 22:52:19 -0000 --047d7b6d8354c493e504c6280717 Content-Type: text/plain; charset=ISO-8859-1 All, we're please to report that we have successfully achieved our first public MAP interop. Proceeding with the next tests. If anyone wants to visit we're still in Plaza C. Sending this mail from behind a MAP CE. Regards, MAP Team. On 30 July 2012 12:35, Wojciech Dec wrote: > Hi All, > > small update: After an on0site visit it's been determined that we'll > relocate the MAP interop to room Plaza-C > > Regards, > Woj. > > > On 29 July 2012 11:38, Wojciech Dec wrote: > >> Hi All, >> >> small update regarding the location of the MAP Interop event: We'll be >> making use of the IETF Terminal room. We're have indication that 5 >> implementations will be tested. >> >> We'll be documenting the results. >> >> Regards, >> Woj. >> >> >> >> On 24 July 2012 17:51, Wojciech Dec wrote: >> >>> Hello All, >>> >>> at the upcoming IETF84 meeting we'll be holding a first open MAP Interop >>> event to which we would like to cordially invite any implementers & >>> implementations of MAP, besides of course interested WG members. The goal >>> of the event will be to verify basic MAP CE-BR communication use-cases, >>> covering both -T and -E. We currently anticipate a number of different >>> implementations to participate. >>> >>> The Interop will commence on Tuesday 31, 2012 starting at 1300. The >>> exact room/location will be communicated shortly. An ethernet switch & >>> Internet connectivity will be provided, but for the rest please bring your >>> own MAP device(s) and any end-host devices that can help with the testing. >>> >>> Given that the set-up activities are likely to commence earlier, please >>> let us know (by unicast) if you'd be available to participate or help in >>> such preparations. >>> >>> Regards, >>> Woj. >>> >>> >>> >> > --047d7b6d8354c493e504c6280717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

we're please to report that we have successfully achieved o= ur first public MAP interop.

Proceeding with the next tests. If any= one wants to visit we're still in Plaza C.

Sending this mail fro= m behind a MAP CE.

Regards,
MAP Team.

On 30 July 2012= 12:35, Wojciech Dec <wdec.ietf@gmail.com> wrote:
Hi All,

small update: After an on0sit= e visit it's been determined that we'll relocate the MAP interop to= room Plaza-C

Regards,
Woj.


On 29 July= 2012 11:38, Wojciech Dec <wdec.ietf@gmail.com> wrote:
Hi All,

small update regarding the lo= cation of the MAP Interop event: We'll be making use of the IETF Termin= al room. We're have indication that 5 implementations will be tested.
We'll be documenting the results.

Regards,
Woj.



On 24 = July 2012 17:51, Wojciech Dec <wdec.ietf@gmail.com> wrote:=
Hello All,

at the upcoming IETF84 meeting we'll be holding a fir= st open MAP Interop event to which we would like to cordially invite any im= plementers & implementations of MAP, besides of course interested WG me= mbers. The goal of the event will be to verify basic MAP CE-BR communicatio= n use-cases, covering both -T and -E. We currently anticipate a number of d= ifferent implementations to participate.

The Interop will commence on Tuesday 31, 2012 starting at 1300. The exa= ct room/location will be communicated shortly. An ethernet switch & Int= ernet connectivity will be provided, but for the rest please bring your own= MAP device(s) and any end-host devices that can help with the testing.

Given that the set-up activities are likely to commence earlier, please= let us know (by unicast) if you'd be available to participate or help = in such preparations.

Regards,
Woj.





--047d7b6d8354c493e504c6280717-- From cuiyong@tsinghua.edu.cn Tue Jul 31 22:07:46 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFAB21F8750 for ; Tue, 31 Jul 2012 22:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.496 X-Spam-Level: * X-Spam-Status: No, score=1.496 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSEh9BrO8too for ; Tue, 31 Jul 2012 22:07:46 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A95321F8755 for ; Tue, 31 Jul 2012 22:07:41 -0700 (PDT) Received: from dhcp-44b4.meeting.ietf.org ([130.129.68.180]) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1SwR9k-0006yw-LH; Wed, 01 Aug 2012 13:07:37 +0800 User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 01 Aug 2012 13:07:30 +0800 From: Yong Cui To: Message-ID: Thread-Topic: Slides for Softwire in IETF 84 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Softwires] Slides for Softwire in IETF 84 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.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, 01 Aug 2012 05:07:47 -0000 Hi folks, Our agenda was published at: https://datatracker.ietf.org/meeting/84/agenda/softwire/ Please send your slides to Suresh and me by 4pm on Wed. (Vancouver time). Thanks, Yong