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