Hi Satoru, Would you please point out in which presentation in the Beijing Interim meeting illustrated "per-subscriber mapping" as one characteristic of MAP solution? I recall which xiaohong presented was a stateful one.
Best wishes 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/ > > =============================================== > > > > > > -- ============================================== 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
