Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01

Hi Ole and all,

Thank you all for the discussions on this topic, as well as sharing
your opinions during the offline discussions in the last couple of
days. Let me try to summarize.

I understand that we MAY adapt MAP to be 4over6-like, or even DS-lite
with more changes. It's actually a very interesting proposal. However,
in my understanding, the advantage of MAP is built on its
statelessness, with of cost of v4-v6 address coupling. If we mandate
MAP to further include the features of 4over6/DS-lite, we lose its
original generality: it's no longer stateless, the motivation document
won't work; GMA algorithm is no longer needed, no rule provisioning
anymore; we enforce a big bindng table on MAP BR. These are somehow
signifcant changes in implmentaton and deployement.

Now there are actually 3 directions for IPv4-over-IPv6 mechanisms,
they have respective application scenarios, pros and cons.
1)stateless,  4rd, MAP
2)per-flow stateful: DS-Lite
3)per-user stateful: public 4over6, lightweight 4over6
As Ole said, the problem is that, do we want serveral simple
mechanisms, or one super-compatible mechanism with different modes.

Now Given that a) the WG has accomplished DS-lite; b)MAP follows the
stateless motivation all along the way; c)The signifcant changes to
make MAP super-compatible, I vote for we define the third type,
per-user stateful mechanisms independently.

Cheers,
Peng

On Thu, Jun 7, 2012 at 4:48 PM, Ole Trøan <otroan@employees.org> wrote:
> Qiong,
>
>> If public 4over6 is one extreme case of MAP, in which one subscriber represents one MAP domain, then should we also say that DS-Lite is another extreme case of MAP, where one application (session) represents one MAP domain ?
>
> a DS-lite AFTR could be represented by the combination of a MAP BR with per subscriber rules combined with a NAT44. there is a reason we started out calling MAP for "Stateless DS-lite".
>
>> I think we should still keep the initial feature of these solutions.
>
> all the proposed solutions, including DS-lite shares a large set of commonalities. where the differences are more operational considerations and deployment choices than technical differences. do we need a separate protocol specification for each deployment choice?
>
> cheers,
> Ole
>
>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires