+1. In fact, we have already done the implementation prior to the current MAP draft. But there is no change in our implementation in order to support the current draft. In addition, our implementation has no limitation for the number of mapping rules. It depends on the available memory size only. So, our implementation can allow 1:1 as well as N:1.
Thanks, Tetsuya Murakami On 2012/06/25, at 7:24, Wojciech Dec wrote: Hi, taking a step back to discuss some items in more detail, and hopefully move this discussion forward: 1. Domain size The MAP architecture does not prescribe the size of a domain, and neither does it prescribe the number of rules to be used. There is nothing in the technology, except vendor implementation limits or practical sense (or both), to prevent MAP domains from defining 1 domain = 1 CPE. This was a day 1 characteristic of MAP drafts. Choosing to deploy or implement MAP with a configuration supporting 1 rule, 100 rules or 100k rules or domains is a vendor's and/or operator's choice. Nobody is stating that deployment is to be limited to X rules, nor that a near infinite number of rules is reasonable. These are general points that apply to DS-lite state as well as the "Light Weight 4 over 6" or "stateless deterministic NAT", and pretty much any technology for that matter. 2. Stateless DOES NOT mean configuration-less There appears to be confusion between the concept of stateless and configuration-less. MAP domains are based on configured rules, that are provisioned/applied through means that are currently outside the scope of Softwire drafts - this is configuration state, and this was and continues to be a characteristic of MAP. Further more, unlike some of the other proposals, MAP allows to optimize the amount of configuration needed in cases where this is viable. In other words, MAP does NOT exclusively force 1:1 rule configuration, but also allows N:1. 3. Stateless has no data plane induced state A major difference between stateless (eg MAP) and stateful (eg Carrier Grade NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic core node forwarding state that is directly driven by user data-plane traffic (eg new IP flows). MAP does not rely on such dynamic state, never did. 4. No change of MAP spec The updated MAP draft does not change the MAP architecture nor its technical underpinnings. In fact there are no changes, bar editorial to the normative parts of MAP, something that is proven by existing implementations prior to this draft supporting the current draft. A few individuals appear to object to new descriptive text which highlights the usage of MAP, eg in 1:1. Removing that text will not change the matter that MAP allows such usage. Prohibiting such use by specification would actually require a spec change, besides being unreasonable. 5. What is the problem? We're pleased to see a growing understanding of MAP's applicability to solve problems, incl v4-v6 address independence, when needed. Given that the emails on this thread do not appear to bring forward any technical issues with the MAP solution, could we know WHY we need other solutions to the problem, or what is the problem that remains to be solved? Taking the liberty to speak on behalf of the other MAP authors, I would like to say that we all remain open for collaboration with all WG members in terms of arriving at a minimal set of reasonable solutions that solve problems that the community cares about. We also trust that our renewed WG leadership will finally help us all in getting there. Regards, Woj. On 25 June 2012 08:51, Qi Sun <[email protected]<mailto:[email protected]>> wrote: Hi Satoru, In MAP 1:1 mode, if there are 10000000 subscribers, there would be 10000000 MAP domains which a BR has to manage. I think that will create a huge mapping table on the BR, which is called 'state' that stateful solutions deal with. Best Regards! ________________________________ Qi Sun From: Satoru Matsushima<mailto:[email protected]> Date: 2012-06-25 10<tel:2012-06-25%C2%A010>:27 To: Lee, Yiu<mailto:[email protected]> CC: [email protected]<mailto:[email protected]>; Yong Cui<mailto:[email protected]> Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG 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" > <[email protected]<mailto:[email protected]>> 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 >> <[email protected]<mailto:[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]<mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected]<mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ >> Softwires mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
