Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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? Thanks -Dapeng ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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 Thanks -Dapeng ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
2012/2/27, Rémi Després despres.r...@laposte.net: 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 requirementenhancement 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: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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
The fundamental issue is total cost to the operator. Different operators have different cost structures, hence need different engineering solutions. This isn't a matter of using precise language -- stateless is a term of convenience fitting the perceptions of the particular group of persons interested in the MAP and 4rd work. Rather than argue over the use of the term, perhaps you could describe the engineering solution that interests you (though I suppose the question below gives a hint). Tom Taylor On 28/02/2012 9:06 AM, liu dapeng wrote: ... 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 ... ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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. 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. 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. 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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 requirementenhancement 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. 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? 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. 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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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 requirementenhancement 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, 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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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 requirementenhancement 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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
2012/2/23, Rémi Després despres.r...@laposte.net: Le 2012-02-23 à 12:03, liu dapeng a écrit : 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. Hi Liu, Even in mesh topologies, these solutions don't require CPEs to maintain states about other CPEs to communicate directly with them. In this sense, they are stateless, including with the given definition. OK? CPE have to maintain NAT44 state in all the cases. Is that a state or not? regards, Liu regards, RD 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 ___ 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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
The stateless sounds only regard to BR, the border router, in the case of MAP-T/MAP-E/4rd-U, or even CGN ( or AFTR) in the case of Juniper SD-NAT. Best Regards, Leaf -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of liu dapeng Sent: Thursday, February 23, 2012 7:04 PM To: mohamed.boucad...@orange.com Cc: softwires@ietf.org; Softwire Chairs Subject: 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 ___ 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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
On Feb 23, 2012 8:10 AM, Cameron Byrne cb.li...@gmail.com wrote: On Feb 23, 2012 5:05 AM, Rémi Després despres.r...@laposte.net wrote: Le 2012-02-23 à 12:03, liu dapeng a écrit : 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. Hi Liu, Even in mesh topologies, these solutions don't require CPEs to maintain states about other CPEs to communicate directly with them. In this sense, they are stateless, including with the given definition. OK? Correct me if I am wrong, but at leas map-t requires stateful nat44 at the cpe Never mind. Please excuse me not reading enough about the definition before sending. Cb Cb regards, RD 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 ___ 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Dear Cameron, Yes, I know it is tempting to have such section but it won't help in making a decision and, furthermore, it may maintain a tension between stateless and stateful camps. We tried in the document to be neutral as much as possible and avoid claiming stateless is superior to stateful or stateful is superior to stateless. I personally think both stateful and stateless solutions are needed. It is up to each service provider, taking into account its own environment and constraint, to select the flavour of solutions which fit its needs. The selection may even be complex given the diversity of networks and services managed by (large) service providers. Cheers, Med De : Cameron Byrne [mailto:cb.li...@gmail.com] Envoyé : samedi 11 février 2012 15:31 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation On Feb 10, 2012 2:20 AM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere. It seems all this stateless work hinges on this assumption without any quantification. Honestly, the omission makes me believe the case of stateless being superior is dubious. Cb As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
2012/2/13, Ole Trøan otr...@employees.org: Cameron, RFC1958 gives the fundamental principles. search for state. Yes. But do you think it is achievable for pure stateless? BR, Dapeng cheers, Ole On Feb 13, 2012, at 5:02 , Cameron Byrne wrote: On Feb 12, 2012 7:14 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: On 2012/02/11, at 15:30, Cameron Byrne wrote: --snip-- I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere. It seems all this stateless work hinges on this assumption without any quantification. Honestly, the omission makes me believe the case of stateless being superior is dubious. Cb Do you think that it is productive productive analysis that comparison of stateless between stateful? Current motivation draft stands not to beat other solutions, it stands for justifying to start stateless solution work on the WG so some proponents of stateless solution took a pen. My question is that if the comparison is productive for something, who should work for it, and who should read it. I assumed this explanation and comparison would be easy for the stateless experts. I looked to this as a learning opportunity for me. I agree with you and RD, there are many good solutions that fit this problem space and I do not intend to slow progress. If it is difficult and the differences in merit cannot be easily quantified between stateful and stateless , I accept that as an answer. I suggested they be compared since opposites frequently help define each other. Black helps define white just as cold helps define hot. I had assumed this was true for this case as well. Perhaps I was wrong. Thanks again for your contribution. Cb cheers, --satoru ___ 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 -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
2012/2/11, Cameron Byrne cb.li...@gmail.com: On Feb 10, 2012 2:20 AM, mohamed.boucad...@orange.com wrote: Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere. It seems all this stateless work hinges on this assumption without any quantification. Honestly, the omission makes me believe the case of stateless being superior is dubious. Agree. Stateless and stateful may both have their own use cases.Saying that stateless is superior than stateful may not be appropriate considering that there is no comprehensive and quantitative comparation between them. BR, Dapeng Cb As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ 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
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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
+1 Cheers, Rajiv Sent from my Phone On Feb 11, 2012, at 3:30 AM, Francis Dupont francis.dup...@fdupont.fr wrote: 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Le 2012-02-11 à 12:43, Rajiv Asati (rajiva) a écrit : +1 +1 RD Cheers, Rajiv Sent from my Phone On Feb 11, 2012, at 3:30 AM, Francis Dupont francis.dup...@fdupont.fr wrote: 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 ___ 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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
On Feb 10, 2012 2:20 AM, mohamed.boucad...@orange.com wrote: Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere. It seems all this stateless work hinges on this assumption without any quantification. Honestly, the omission makes me believe the case of stateless being superior is dubious. Cb As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ 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
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Le 2012-02-11 à 15:30, Cameron Byrne a écrit : On Feb 10, 2012 2:20 AM, mohamed.boucad...@orange.com wrote: Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere. It seems all this stateless work hinges on this assumption without any quantification. Honestly, the omission makes me believe the case of stateless being superior is dubious. Both stateful AND stateless have their use cases. This motivation draft shouldn't be taken as advocating that Stateful should be abandoned! (Both NAT64 and DS-lite are here to stay. There also have their use cases where they are superior). Delaying this document would only be IMHO a waste of energy. Regards, RD Cb As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
