Hi Tetsuya, With regard to implementaion, what did you configure in BR ?
In the specification, it says the BR and CE MUST be configured with the following MAP elements. o The End-User IPv6 prefix (Part of the normal IPv6 provisioning). o The Basic Mapping Rule and optionally the Forwarding Mapping Rules o The Default Mapping Rule with the BR IPv6 prefix or address o Hub and spoke mode or Mesh mode. Did you configure PSID explicitly ? If yes, the implementation does not consistent with the specification. If not, it can not been applied to the so-called 1:1 mode. Best wishes Qiong On Tue, Jun 26, 2012 at 6:50 AM, Tetsuya Murakami < [email protected]> wrote: > +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]> 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 <[email protected]> >> *Date:* 2012-06-25 10:27 >> *To:* Lee, Yiu <[email protected]> >> *CC:* [email protected]; Yong Cui <[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]> 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]> 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 >> >>> >> >>> _______________________________________________ >> >>> Softwires mailing list >> >>> [email protected] >> >>> https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> >> Softwires mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> >> > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > > > > _______________________________________________ > 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
