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

Hi Qiong,

Thanks you to carefully express your thought. I understand that.

First point, let me answer for the question, 'Is MAP stateless or stateful', the answer is: "MAP is *not* stateful solution itself". It was discussed in the interim meeting in Beijing about 'per-subscriber mapping' could be one characteristic of MAP solution. It does not introduce 'per-flow NAT binding' or 'per-subscriber state on demand' on network side. As MAP specification, there is a case when ea-bits length indicates zero so that MAP needs explain this case and clearly define specification that's what we did.

Second, I don't have any intention to deprecate those who work hard for that solutions.  I didn't figure out that MAP possibly cover existing solutions untill you rise this point. Now I remember that 'multi-protocol socket v2.0', talked from the chair, which has been deeply engraved in my mind. I believe that it is right direction for the working group.

I agree on that we need discussion. That would be there's another choice to define in the case of ea-bits length indicates zero.

Best regards,
--satoru

On 2012/06/25, at 0:13, Qiong wrote:

> Hi Satoru,
> 
> Every solution has its solution space with respective application scenarios as well as pros and cons. 
> The essence of stateless solution, which follows the stateless motivation approved by the WG, is to achieve efficient address mapping by algorithmic embedding part of IPv4 address+port set into IPv6 address/prefix, while the essence of stateful solution is to maintain the subscriber-based state on-demand. IPv4 address and IPv6 address is not coupled, and there is no requirement on IPv6 addressing format. It is twisty to mix them together in one document as in the current draft-ietf-softwire-map. It is not clear for vendors to implement and for operators to deploy, and will lose the features for both.
> 
> I'm not saying I'm against the work of stateless solutions, but it is really not fair to just extend one solution arbitrarily to cover another one without the permission from the WG and the authors. In particular,  lightweight 4over6 is a collaborative work of 15 co-authors for more than one and a half years, including operators from China Telecom, Tsinghua, Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and  also the vendors from Huawei, Juniper and Cisco.
> 
> Our WG or DT has never reached the consensus to have one unified document for both stateful and stateless sotluion. And the motivation draft has never been extended to include the stateful features as well. So unless we reach the consensus first in the WG, we can then move forward with this document. 
> 
> Best wishes
> 
> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima <satoru.matsushima@gmail.com> 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
> > 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/ 
> ===============================================
> 
> 