2012/2/27, Rémi Després <[email protected]>: > > Le 2012-02-27 à 12:04, liu dapeng a écrit : > >> Hi Remi, >> >> Please see my reply inline: >> >> 2012/2/27, Rémi Després <[email protected]>: >>> Liu, >>> Please see more clarification in line. >>> >>> Le 2012-02-24 à 13:21, liu dapeng a écrit : >>> >>>> 2012/2/23, [email protected] <[email protected]>: >>>>> 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, > Regards,
Hi Remi, 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? Regards, Dapeng Liu > RD > > > >> >> Thanks. >> >> Regards, >> Dapeng Liu >> >> >>> Thank you, >>> RD >>> >>> >>>> >>>> regards, >>>> Dapeng Liu >>>> >>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : liu dapeng [mailto:[email protected]] >>>>>> Envoyé : jeudi 23 février 2012 12:04 >>>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>> Cc : Softwire Chairs; [email protected] >>>>>> 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, [email protected] >>>>>> <[email protected]>: >>>>>>> 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 : [email protected] [mailto:[email protected]] >>>>>>>> Envoyé : samedi 11 février 2012 09:30 >>>>>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP >>>>>>>> Cc : [email protected] >>>>>>>> Objet : Re: [Softwires] Closing >>>>>>>> draft-ietf-softwire-stateless-4v6-motivation >>>>>>>> >>>>>>>> In your previous mail you wrote: >>>>>>>> >>>>>>>>> (1) Either issue a WG LC, or >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> [email protected] >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Softwires mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> ------ >>>>>> Best Regards, >>>>>> Dapeng Liu >>>>>> >>>> >>>> >>>> -- >>>> >>>> ------ >>>> Best Regards, >>>> Dapeng Liu >>>> _______________________________________________ >>>> Softwires mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu > > -- ------ Best Regards, Dapeng Liu _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
