If I recall correctly, the Interim meeting dicussed the rationality of per-subsriber stateful solutions ASIDE FROM the stateless solutions, rather than " 'per-subscriber mapping' could be one characteristic of MAP solution"
On Mon, Jun 25, 2012 at 9:55 AM, Satoru Matsushima <[email protected]> wrote: > 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
