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 > <[email protected]> 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 > > [email protected] > > 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/ > =============================================== > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
