On Feb 27, 2012 4:48 AM, "Rémi Després" <despres.r...@laposte.net> wrote: > > > Le 2012-02-27 à 12:04, liu dapeng a écrit : > > > Hi Remi, > > > > Please see my reply inline: > > > > 2012/2/27, Rémi Després <despres.r...@laposte.net>: > >> Liu, > >> Please see more clarification in line. > >> > >> Le 2012-02-24 à 13:21, liu dapeng a écrit : > >> > >>> 2012/2/23, mohamed.boucad...@orange.com <mohamed.boucad...@orange.com >: > >>>> Dear Dapeng, > >>>> > >>>> Are you considering the endpoint (host or CPE) as part of the service > >>>> provider's network? > >>>> > >>>> If not, please read the definition again with the answer in mind. > >>> > >>> Hi Med, > >>> > >>> Yes, I am considering CPE. There are two reasons: > >>> > >>> 1. The definition of "stateless" should not be bind to the provider's > >>> network. > >> > >> Agreed. > >> > >>> The document should define "stateless" for the Internet not > >>> only for the operator. > >> > >> Because the document deals only with solutions deployed within individual > >> ISP networks (similar in that to 6rd), it is AFAIK right to limit its > >> stateless concern to individual ISP network. > > > > The solutions currently under study have many requirement&enhancement > > to the CPE. So I think the document does not "deals only with > > soltuions deployed within individual ISP networks" if not considering > > the CPE as part of ISP network. > > Misunderstanding. > Yes the 4/6 function of the CPE is part of the ISP-network solution, even if the CPE isn't provided by the ISP. > I think we agree on this. > > > > > >>> > >>> 2. Even for CPE itself, in many cases, it should be considered as > >>> provider's network since operator need to control/configure the CPE > >>> remotely in that case. > >> > >> Agreed that CPEs, are part of the model. > >> But the important point AFAIK is that, "stateless 4/6 solution" is defined > >> in the document itself as meaning without "per-user state". > >> All under-study solutions that refer to this draft are without "per-user" > >> state" in "active data plane network elements". They are therefore din scope > >> of this draft. > > > >> If a CPE includes a NAT for its IPv4 operation (with states that are per > >> only session states, and only IPv4), the 4/6 solution proper remains without > >> "per-user state". > > > > If having "per-user state" is stateful, why "per session state" is > > not stateful? > > It is stateful too, yes, but differently. > Also, if a CPE includes a NAT44, its states are not IPv4-over-IPv6 related (only IPv4 related). > => Would you be satisfied if, in the terminology section, definition of Stateless 4/6 solution and Stateful 4/6 solution would be clarified as follows: > > Stateless 4/6 solution (or stateless solution in short): denotes in this document a solution which, as far as IPv4 aver IPv6 is concerned, does not require any per-user state ... > > Stateful 4/6 solution (or stateful solution in short): denotes in this document a solution which, as far as IPv4 aver IPv6 is concerned, requires neither per-customer nor per connection state ... > > > > >> Considering that publication of this draft is much expected to pursue the > >> work on solutions themselves, and that it isn't freezing a standard (just > >> clarifying a need that too many wanted to better understand), could you then > >> agree that the draft can proceed as is. > > > > The concern that I have is: If we want to move forward, we need more > > clear and strict definition of "stateless" and also need more > > investigation before we give the conclusion that "stateless is > > superior than stateful". > > 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"). > > Hoping that you will be more open to permit parallel progress on stateless, >
+1. I believe the consensus is that one is not better than the other, or at least it is not possible to quantify. In the end, deployments of transition scenarios will be dependent on operator preference, cost, timeline, features... Cb > RD > > > > > > > Thanks. > > > > Regards, > > Dapeng Liu > > > > > >> Thank you, > >> RD > >> > >> > >>> > >>> regards, > >>> Dapeng Liu > >>> > >>> > >>>> Cheers, > >>>> Med > >>>> > >>>>> -----Message d'origine----- > >>>>> De : liu dapeng [mailto:maxpass...@gmail.com] > >>>>> Envoyé : jeudi 23 février 2012 12:04 > >>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP > >>>>> Cc : Softwire Chairs; softwires@ietf.org > >>>>> Objet : Re: [Softwires] Closing > >>>>> draft-ietf-softwire-stateless-4v6-motivation > >>>>> > >>>>> Hi Med, > >>>>> > >>>>> I think it is still not clear about the definition of "stateless", in > >>>>> current draft, it says: > >>>>> > >>>>> stateless denotes a solution which does not require any per-user state > >>>>> (see Section > >>>>> 2.3 of [RFC1958]) to be maintained by any IP address sharing > >>>>> function in the Service Provider's network. > >>>>> > >>>>> But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain > >>>>> state in CPE. It is obviously contradictory with this definition. We > >>>>> need more discussion regarding the definition of "stateless". > >>>>> > >>>>> regards, > >>>>> Dapeng Liu > >>>>> > >>>>> 2012/2/20, mohamed.boucad...@orange.com > >>>>> <mohamed.boucad...@orange.com>: > >>>>>> Dear chairs, WG members, > >>>>>> > >>>>>> The answers received so far are in favour of initiating a > >>>>> WG LC on this > >>>>>> document. > >>>>>> > >>>>>> As an editor of the document, I would like to progress this > >>>>> document for the > >>>>>> next IETF meeting. Chairs, could you please issue the WG LC? Thanks. > >>>>>> > >>>>>> Cheers, > >>>>>> Med > >>>>>> > >>>>>>> -----Message d'origine----- > >>>>>>> De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] > >>>>>>> Envoyé : samedi 11 février 2012 09:30 > >>>>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP > >>>>>>> Cc : softwires@ietf.org > >>>>>>> Objet : Re: [Softwires] Closing > >>>>>>> draft-ietf-softwire-stateless-4v6-motivation > >>>>>>> > >>>>>>> In your previous mail you wrote: > >>>>>>> > >>>>>>>> (1) Either issue a WG LC, or > >>>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> francis.dup...@fdupont.fr > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Softwires mailing list > >>>>>> Softwires@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/softwires > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> ------ > >>>>> Best Regards, > >>>>> Dapeng Liu > >>>>> > >>> > >>> > >>> -- > >>> > >>> ------ > >>> Best Regards, > >>> Dapeng Liu > >>> _______________________________________________ > >>> Softwires mailing list > >>> Softwires@ietf.org > >>> https://www.ietf.org/mailman/listinfo/softwires > >> > >> > > > > > > -- > > > > ------ > > Best Regards, > > Dapeng Liu > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
