2012/2/29, Rémi Després <despres.r...@laposte.net>: > > Le 2012-02-29 à 10:53, liu dapeng a écrit : > >> 2012/2/28, Rémi Després <despres.r...@laposte.net>: >>> >>> 2012-02-28 15:06, liu dapeng : >>> ... >>>> 2012/2/27, Rémi Després <despres.r...@laposte.net>: >>> ... >>>>> 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”. 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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
