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

["Jiang Dong" <[e-mail]>]

Hi, Peng,

I totally agree with you.

AFAIK, the originally MAP draft is designed to solve the stateless scenarios in a IPv4 info embedded way. Now one day, the 1:1 mode was suddenly added by setting the EA bits to zero without any consent from the WG, which also abandoned the essence of original MAP.

Since I cannot find any words in earlier MAP drafts talking about 1:1 mode, what I can imagine is that the two years hard works by the real 1:1 mapping guys are ignored  in the new MAP draft.

Best Regards!
Jiang Dong

From: Peng Wu
Date: 2012-06-26 12:07
To: Wojciech Dec
CC: softwires WG; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
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.
_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires