On Mar 1, 2012 6:56 AM, "liu dapeng" <[email protected]> wrote: > > 2012/2/29, Rémi Després <[email protected]>: > > > > Le 2012-02-29 à 10:53, liu dapeng a écrit : > > > >> 2012/2/28, Rémi Després <[email protected]>: > >>> > >>> 2012-02-28 15:06, liu dapeng : > >>> ... > >>>> 2012/2/27, Rémi Després <[email protected]>: > >>> ... > >>>>> The draft only reflects the wish of an number of operators to have a > >>>>> stateless solution standardized, acknowledging that this is in addition > >>>>> to > >>>>> the more advanced stateful solutions (it doesn't even include the word > >>>>> "superior"). > >>> ... > >>>> Thanks for the discussion but the fundamental question is: > >>>> > >>>> If we consider [CPE(stateful) + BR(partially stateless maybe)] as a > >>>> stateless solution, > >>>> > >>>> then, why [CPE(stateless) + xlate(stateful)] is not a stateless > >>>> solution? > >>> > >>> > >>> What I see as important is that IPv6-only routing can be deployed ASAP > >>> without sacrificing a good residual IPv4 service, including where ISPs > >>> prefer per-user stateless operation. > >>> > >>> The point has already been made that functions are defined in the draft > >>> as > >>> "stateless" if they don't need (for IPv4 over IPv6) any "per-user" state. > >>> A CE can therefore be considered stateless *in the draft* even if it has > >>> NAT44 (a function that is purely IPv4, and whose statefulness is per > >>> session). > >>> Because of that, the draft is self consistent an doesn't need to be > >>> modified. > >>> > >>> I do hope that, with these additional explanations, and in order to avoid > >>> waste of energy, you can accept to join a consensus that it is time to > >>> close > >>> this discussion and accept the draft. > >>> > >>> > >>> Looking forward to further discussions on solutions themselves, > >>> Regards, > >>> RD > >>> > >> Hello Remi > >> > >> Firstly, this draft will mis-lead other operators thinking that this > >> is a pure stateless solution from the title and the document (maybe > >> terminology such as "Maping" is better). IETF WG should not hurry up > >> without the correct description on what the document is. For my > >> understanding, both of above two solutions are stateful solution. Even > >> in the first case of BR' side there are still stateful information for > >> control plane. > >> > >> Secondly, since this is also stateful solution principally. Then why > >> IETF need to invent a second wheel about the same scenario, > > > > > >> should > >> IETF obsolete previous one such as DS-Lite, then start to work on > >> this? > > > > Surely not. > > This debate has been finished when it was decided that Softwire would work > > ALSO on solutions that are stateless, at least in ISP gateways to the IPv4 > > Internet. > > > > You may have not been personally part of this consensus, which is obviously > > your right, but the consensus remains. > > Since no one prevents you from using stateful solutions of you choice, > > trying to prevent those who want a more stateless solution to have a > > specification isn't, IMHO, fair contribution to standardization. > > > > RD > > It’s really a bad idea to invent two wheels for the same scenario. > This is not IETF’s spirit, It’s a disaster for “One Internet”. >
The internet is a very diverse place. In fact, most networks that make up the internet are very unique. For this reason, there must be multiple solutions. It would be very unfortunate for the ietf to say there will be only one solution to the ipv4 to ipv6 transition. In fact, the ietf tried this for 10 years by saying dual stack is the ONE solution, and it is an embarrassing failure for all involved. Hopefully, the ietf has learned from this failure which has resulted in layers of NAT and other painful side effects....including both stateful and stateless solutions in equal part. The ietf must not slow progress on moving towards ipv6 transition, and this explicitly means vetting all possible solutions that may support the cause of meaningful ipv6 transition. And as always, we believe in running code. Cb > I guess that it has been quite clear that this is not a “stateless”, > whatever state is more or less, the current terminology is > mis-leading.If you want, then maybe “Mapping” is much better. > > IETF consensus has to happen multiple times during the process of the document. > > -Dapeng > > > > >> > >> Thanks > >> > >> -Dapeng > >> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > > > > > > -- > > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
