+1 support. I respect what the MAP authors have worked on. But besides what Peng has said, could you clarify where the so called "ietf"-map-00 achieves consensus?
Qi Sun On Tue, Jun 26, 2012 at 12:07 PM, Peng Wu <[email protected]> wrote: > Woj, > > On Mon, Jun 25, 2012 at 10:24 PM, Wojciech Dec <[email protected]> > 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. > Yes from the theoretical view you could. But that's not the exact 1:1 > mode the "ietf-map-00" described. You have to change the specification > and twist the mechanism definiation to particularly support the 1:1 > mode. > > > 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. > If you have per-user specific configuration, that definitely changes > the operation model. > > > 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. > That's not what is discussed in this thread at all... > > > > 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. > I think you only mean per-session stateful. For per-user stateful > mechanisms, you run the provisioning process to avoid state creating > from the data plane. That's one of the essential design goals and > benifits of the per-user stateful mechanisms and reflected in > lw4over6. > > > > > 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. > Sorry, no. You need to change specifications, and you need to twist > the definations of the terminology. > For example, you need to explicitly provisio the port set information, > which is not the usual case at all. > > > > > 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? > The problem is that there are apparently three types of solutions with > perspective application scenarios, while the MAP solution, originally > strongly customized for the pure stateless scenario, is now twisting > itself in a somehow weired way, dropping the essential feature of > statelessness, to include the per-user state/mapping scenario which > can be solved by a more pure and clear solution. > > > 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. > No objection to MAP at all, AS LONG AS it follows the original, > suitable problem space which it is expected to developed for. >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
