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