Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

[Satoru Matsushima <[e-mail]>]

Peng,

On 2012/06/25, at 12:06, Peng Wu wrote:

> Satoru,
> 
> Mapping, binding, rule, state,call it whatever you want,  essentially
> it's the same thing: per-user IPv6 address<=>IPv4 address+port-set.
> Or you are saying that this binding is purely static?
> 

Static, right.
--satoru


> On Mon, Jun 25, 2012 at 10:27 AM, Satoru Matsushima
> <[e-mail]> wrote:
>> Hi Yiu,
>> 
>> No, that's a misunderstanding.
>> Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber mapping' in stateless manner, not to introduce 'per-flow NAT binding' or 'per-subscriber state on demand'.
>> 
>> cheers,
>> --satoru
>> 
>> On 2012/06/25, at 2:32, Lee, Yiu wrote:
>> 
>>> Dear Satoru and MAP-DT
>>> 
>>> I echo what Peng and Qiong said. When the WG agreed working on the
>>> stateless solution, it was very clear stated that the solution would not
>>> maintain states in the network. If the 1:1 mode changed this, this no
>>> longer matched the requirements stated in the stateless motivation draft,
>>> thus, it would disqualify MAP as a solution for the motivation draft.
>>> 
>>> AFAIK, the MAP Design Team could propose a change, but such a dramatic
>>> change by introducing states in the network would require WG approval. I
>>> would like the chairs to clarify this.
>>> 
>>> Thanks,
>>> Yiu
>>> 
>>> 
>>> On 6/24/12 12:21 PM, "Peng Wu" <[e-mail]> wrote:
>>> 
>>>> Hi Qiong, Satoru and all,
>>>> 
>>>> I should thank Qiong for pointing this out. I gotta say I'm a bit shocked.
>>>> If I understand the procedures of IETF correctly, a WG document should
>>>> reflect the consensus of the WG. MAP is approved by the WG as a
>>>> stateless solution. As a participator in Softwire, I didn't get the
>>>> information anywhere that the MAP WG document would cover the
>>>> so-called 1:1, in fact per-user stateful mode before it was released,
>>>> not to say discuss in the WG. Don't the WG need to approve such big
>>>> change anymore?
>>>> 
>>>> Now let me provide my impression as an outsider of the MAP DT. You
>>>> guys make great effort to build the solution, The address composition,
>>>> the GMA algorithm, the different types of address mapping rules.
>>>> should be quite difficult to pull together such sophisticated ideas. I
>>>> guess that's what it takes to achieve the benifits of statelessness.
>>>> And I admire that, bravo. Then, all of a sudden, you guys are saying,
>>>> let's apply this sophisticated method to the different problem, by
>>>> dropping quite some comlexity and twistting the mechanism a bit, seems
>>>> it may work. Considering the problem are now solved in a more pure and
>>>> clear way, I'm sorry but I CANNOT follow the logic here.
>>>> 
>>>> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima
>>>> <[e-mail]> wrote:
>>>>> Hi Qiong,
>>>>> 
>>>>> I'm disagree with your opinion.
>>>>> 
>>>>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in
>>>>> the DT.
>>>>> 2. MAP just covers so called '1:1 mode' with most granular mapping rule
>>>>> for CEs provisioning, which is as one of its characteristics.
>>>>> 3. The motivation draft does not restrict that as you stated, just
>>>>> 'assumed', it's neither 'MUST' nor 'SHOULD'.
>>>>> 
>>>>> Best regards,
>>>>> --satoru
>>>>> 
>>>>> 
>>>>> On 2012/06/24, at 14:35, Qiong wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> As we all know, once an individual draft is adopted as a WG draft, it
>>>>>> is owned by the whole WG, rather than just the editors. Just as Remi
>>>>>> said, the normal procedure to follow is to reach WG consensus _before_
>>>>>> posting a newly edited version.
>>>>>> 
>>>>>> From draft-mdt-softwire-mapping-address-and-port-03 to
>>>>>> draft-ietf-softwire-map-00, there are several changes between them. In
>>>>>> particular, the newly introduced "1:1 mode", which decouples IPv4 and
>>>>>> IPv6 addressing, has never been discussed openly in the WG mailing
>>>>>> list, or even in the MAP design team either.
>>>>>> 
>>>>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation
>>>>>> draft. The motivation draft has clearly defines the "Stateless 4/6
>>>>>> solution" as follows:
>>>>>> 
>>>>>> Stateless 4/6 solution denotes a solution which does not require any
>>>>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by any
>>>>>> IP address sharing function in the Service Provider's network. This
>>>>>> category of solutions assumes a dependency between an IPv6 prefix and
>>>>>> IPv4 address.
>>>>>> 
>>>>>> AFAIK what the WG has adopted MAP related draft is
>>>>>> draft-mdt-softwire-mapping-address-and-port-03, NOT
>>>>>> draft-ietf-softwire-map-00. And the stateless solution should ³response
>>>>>> to the solution motivation document² according to the Softwire charter.
>>>>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft.
>>>>>> 
>>>>>> We can all recall that our softwire WG has worked on stateless
>>>>>> solutions for more than one and a half years, and we have achieved a
>>>>>> lot of work which has been documented in charter, stateless motivation,
>>>>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic
>>>>>> "stateless" principle and the MAP design team is also working on it
>>>>>> together to find a better algorithm, address format, etc. So it is
>>>>>> really not appropriate to make such changes when MAP is adopted as a WG
>>>>>> item in such a short time.
>>>>>> 
>>>>>> From this perspective, draft-ietf-softwire-map-00 can only be regarded
>>>>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even the
>>>>>> output of MAP design team.
>>>>>> 
>>>>>> Best wishes
>>>>>> 
>>>>>> ==============================================
>>>>>> Qiong Sun
>>>>>> China Telecom Beijing Research Institude
>>>>>> 
>>>>>> 
>>>>>> Open source code:
>>>>>> lightweight 4over6: http://sourceforge.net/projects/laft6/
>>>>>> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
>>>>>> ===============================================
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Softwires mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>> 
>>>>> _______________________________________________
>>>>> Softwires mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>