Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

[Qi Sun <[e-mail]>]

+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 <[e-mail]> wrote:

> Woj,
>
> On Mon, Jun 25, 2012 at 10:24 PM, Wojciech Dec <[e-mail]>
> 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.
>