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

[Rémi Després <[e-mail]>]

Peng,

2012-06-07 à 16:04, Peng Wu:

> 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

Thank you for having not forgotten that 4rd and MAP are on equal footing in Softwire, something that seems to be forgotten more than needed on this discussion thread. 

Incidentally, while the WG draft on 4rd has been available since May 16, the MAP specification, which was claimed in Paris to be well stabilized, already tested, and urgent to be published, is still not available as a WG draft. I therefore believe that discussing relationship between MAP and/or 4rd and 4over6 would be more useful when an up-to-date MAP specification is available.

In any case, I renew my support for Public 4over6 to progress autonomously.

Regards,
RD


> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires