Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Dear Qiong, Yes, port ranges can be used in a CGN-based architecture too to reduce log file volume as discussed in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02#section-3.1.3 but then you should be aware you loose a feature offered by the CGN which is: * The possibility to log the destination IP address for legal storage purposes in case the server does not implement RFC6302. If RFC6302 is largely deployed, then this feature is not needed. There are a lot of trade-offs and there is no universal answers to these trade-offs. Cheers, Med De : Qiong [mailto:bingxu...@gmail.com] Envoyé : mardi 16 août 2011 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc Škoberne; softwires@ietf.org; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi, Med, and Nejc, Please see inline. You indeed loose agressive sharnig ratio, but you have somewhat more flexible addressing. Also, the CPEs can be then really simple devices, excluding any of the NAPT functionality, doing only stateless encapsulation. However, what you loose/gain is irrelevant for my point. I think this section should be modified in a way like the logging section or any other appropriate way, which explains, that this is not the benefit of the stateless nature, but rather the benefit of the static port allocation. [Qiong]: +1 Agree. Med: Your point is valid and the text should be updated accordingly. My comment aims to show that the comparison is not so that trivial. We can claim the stateful with port ranges can provide similar features as the stateless or the binding mode but we always forget to mention this lead to loose one of the characteristics of the stateful. We captured a similar discussion in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-01#section-4.2: [Qiong]: In our situation, we do not regard aggressive sharing ratio as a vital important feature since the static port multiplex ratio is already enough for us. Besides, even for session-based CGN like ds-lite, we would still prefer to pre-define port-range for customers because our centralized log server can not deal with massive session-based log events. So it seems more reasonable for us to adopt static port arrangement which can largely reduce the log volume. Best regards Qiong Sun 5.2. Port Utilisation Efficiency CGN-based solutions, because they can dynamically assign ports, provide better IPv4 address sharing ratio than stateless solutions (i.e., can share the same IP address among a larger number of customers). For Service Providers who desire an aggressive IPv4 address sharing, a CGN-based solution is more suitable than the stateless. If a Service Provider adopts an aggressive address sharing ratio, it is likely to be attempted by enforcing a NAT port overloading mode and as a consequence some applications will break. However, as more and more hosts become dual-stack enabled, the need for ports in IPv4 is likely to decrease. The insurance to have the full set of 64K ports per host will be one of the incentives to have them IPv6 capable. Moreover, Service Providers should offload some services to IPv6 (e.g., DNS, VoIP). ___ 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] draft-operators-softwire-stateless-4v6-motivation
From: Qiong [mailto:bingxu...@gmail.com] Sent: Wednesday, August 17, 2011 12:29 AM To: BOUCADAIR Mohamed OLNC-NAD-TIP Cc: softwires@ietf.org; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi, Med, and Nejc, Please see inline. You indeed loose agressive sharnig ratio, but you have somewhat more flexible addressing. Also, the CPEs can be then really simple devices, excluding any of the NAPT functionality, doing only stateless encapsulation. However, what you loose/gain is irrelevant for my point. I think this section should be modified in a way like the logging section or any other appropriate way, which explains, that this is not the benefit of the stateless nature, but rather the benefit of the static port allocation. Xiaohong: It's a trade-off between efficiency of log and address sharing ratio for stateful solution. I do agree it's a good trade-off for stateful, but one more good option for stateful doesn't make stateless less valuable, so neither see it is too much to do with stateless motivation, nor think it is necessary to document too much in the stateless motivation draft, as long as the stateless motivation is more focused on the requirement of stateless other than comparisons between the two. [Qiong]: +1 Agree. Med: Your point is valid and the text should be updated accordingly. My comment aims to show that the comparison is not so that trivial. We can claim the stateful with port ranges can provide similar features as the stateless or the binding mode but we always forget to mention this lead to loose one of the characteristics of the stateful. We captured a similar discussion in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-01#section-4.2: [Qiong]: In our situation, we do not regard aggressive sharing ratio as a vital important feature since the static port multiplex ratio is already enough for us. Besides, even for session-based CGN like ds-lite, we would still prefer to pre-define port-range for customers because our centralized log server can not deal with massive session-based log events. So it seems more reasonable for us to adopt static port arrangement which can largely reduce the log volume. Xiaohong: I suppose you're saying it is valuable to you to have this trade-off for stateful. Personally, I do see its value too, but again it is not too much to do with stateless motivation. Cheers, Xiaohong Best regards Qiong Sun 5.2. Port Utilisation Efficiency CGN-based solutions, because they can dynamically assign ports, provide better IPv4 address sharing ratio than stateless solutions (i.e., can share the same IP address among a larger number of customers). For Service Providers who desire an aggressive IPv4 address sharing, a CGN-based solution is more suitable than the stateless. If a Service Provider adopts an aggressive address sharing ratio, it is likely to be attempted by enforcing a NAT port overloading mode and as a consequence some applications will break. However, as more and more hosts become dual-stack enabled, the need for ports in IPv4 is likely to decrease. The insurance to have the full set of 64K ports per host will be one of the incentives to have them IPv6 capable. Moreover, Service Providers should offload some services to IPv6 (e.g., DNS, VoIP). ___ 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] draft-operators-softwire-stateless-4v6-motivation
Hello, I have some comments on your draft, see inline. Regards, Nejc --- 2. Terminology This document makes use of the following terms: Stateful 4/6 solution (or stateful solution in short): denotes a solution where the network maintains user-session states relying on the activation of a NAT function in the Service Providers' network [I-D.ietf-behave-lsn-requirements]. The NAT function is responsible for sharing the same IPv4 address among several subscribers and to maintain user-session state. Stateless 4/6 solution (or stateless solution in short): denotes a solution which does not require any user-session state (seeSection 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. In an IPv4 address sharing context, dedicated functions are required to be enabled in the CPE router to restrict the source IPv4 port numbers. Within this document, port set and port range terms are used interchangeably. [NS: If we consider a stateful A+P solution, we don't necessarily have a dependency between an IPv6 prefix and IPv4 address. Also, we don't have any user-session state in the Service Provider's network. We do, however, have some user state (in order to do stateful tunneling, for example). Maybe this is included in user-session in your terminology, but then I think it would be appropriate to define the term user-session clearly.] ... 3.1.5. Bandwidth Saving In same particular network scenarios (e.g., wireless network ), spectrum is very valuable and scarce resource. Service providers usually wish to eliminate unnecessary overhead to save bandwidth consumption in such environment. Service providers need to consider optimizing the form of packet processing when encapsulation is used. Since existing header compression techniques are stateful, it is expected that stateless solution minimize overhead introduced by the solution. [NS: I don't understand this section, but that may be just me. Maybe is there a better way to explain the point?] ... 3.3.1. Implicit Host Identification Service Providers do not offer only IP connectivity services but also added value services (a.k.a., internal services). Upgrading these services to be IPv6-enabled is not sufficient because of legacy devices. In some deployments, the delivery of these added-value services relies on implicit identification mechanism based on the source IPv4 address. Due to address sharing, implicit identification will fail [I-D.ietf-intarea-shared-addressing-issues]; replacing implicit identification with explicit authentication will be seen as a non acceptable service regression by the end users (less Quality of Experience (QoE)). When a stateless solution is deployed, implicit identification for internal services is likely to be easier to implement: the implicit identification should be updated to take into account the port range and the IPv4 address. Techniques as those analyzed in [I-D.boucadair-intarea-nat-reveal-analysis] are not required for the delivery of these internal services if a stateless solution is deployed. [NS: I don't think this is true only for stateless solutions. If we have a stateful solution with static port allocation (as you mention in section 3.1.3), then implementing such an implicit host identification which uses also port information, is doable as well.] ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Dear Med, [NS: If we consider a stateful A+P solution, we don't necessarily have a dependency between an IPv6 prefix and IPv4 address. Also, we don't have any user-session state in the Service Provider's network. Med: Fully agree. FWIW, this is what we called Binding Table A+P Mode in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4. This is exactly what I had in mind. We do, however, have some user state (in order to do stateful tunneling, for example). Maybe this is included in user-session in your terminology, but then I think it would be appropriate to define the term user-session clearly.] Med: We assumed the definition of state as mentioned in RFC1958; but I agree the terminology should be much more clearer. Yes, state is implicitly defined there, however user-session is not defined anywhere. [NS: I don't think this is true only for stateless solutions. If we have a stateful solution with static port allocation (as you mention in section 3.1.3), then implementing such an implicit host identification which uses also port information, is doable as well.] Med: I Agree. But then you loose other benefits of the stateful: have an aggressive address sharing ratio. You indeed loose agressive sharnig ratio, but you have somewhat more flexible addressing. Also, the CPEs can be then really simple devices, excluding any of the NAPT functionality, doing only stateless encapsulation. However, what you loose/gain is irrelevant for my point. I think this section should be modified in a way like the logging section or any other appropriate way, which explains, that this is not the benefit of the stateless nature, but rather the benefit of the static port allocation. Thanks, Nejc ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hi Rémi, Yes, there was a vote in favour of adopting this document as a WG document but as you know this vote should be confirmed in the ML. A call for adoption should normally be issued by the chairs according to the IETF procedure. As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 16 août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc Škoberne; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org; softwires@ietf.org Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi Med, At the last meeting, a vote was taken to decide whether this draft should become a WG draft. The answer has been a crystal clear yes, with the common understanding that, as such, it would have to be improved and competed based on WG reactions. IMHO, making it a WG document asap will facilitate discussions like this one: thet will point to the right document. Is there any sort term plan to do what was approved? Kind regards, RD Le 16 août 2011 à 13:48, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear Nejc, Thank you for the comments. Please see my answers inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Nejc Škoberne Envoyé : mardi 16 août 2011 12:25 À : draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Cc : softwires@ietf.org Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation Hello, I have some comments on your draft, see inline. Regards, Nejc --- 2. Terminology This document makes use of the following terms: Stateful 4/6 solution (or stateful solution in short): denotes a solution where the network maintains user-session states relying on the activation of a NAT function in the Service Providers' network [I-D.ietf-behave-lsn-requirements]. The NAT function is responsible for sharing the same IPv4 address among several subscribers and to maintain user-session state. Stateless 4/6 solution (or stateless solution in short): denotes a solution which does not require any user-session state (seeSection 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. In an IPv4 address sharing context, dedicated functions are required to be enabled in the CPE router to restrict the source IPv4 port numbers. Within this document, port set and port range terms are used interchangeably. [NS: If we consider a stateful A+P solution, we don't necessarily have a dependency between an IPv6 prefix and IPv4 address. Also, we don't have any user-session state in the Service Provider's network. Med: Fully agree. FWIW, this is what we called Binding Table A+P Mode in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4. We do, however, have some user state (in order to do stateful tunneling, for example). Maybe this is included in user-session in your terminology, but then I think it would be appropriate to define the term user-session clearly.] Med: We assumed the definition of state as mentioned in RFC1958; but I agree the terminology should be much more clearer. ... 3.1.5. Bandwidth Saving In same particular network scenarios (e.g., wireless network ), spectrum is very valuable and scarce resource. Service providers usually wish to eliminate unnecessary overhead to save bandwidth consumption in such environment
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
mohamed.boucad...@orange-ftgroup.com wrote, on 08/16/2011 11:03 AM: As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed. For me, the first option makes more sense. I also support adoption of this document and am expecting an adoption call soon. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hello all, It appears that confirming on this list the vote made in Quebec would be useful. Please see below. Le 16 août 2011 à 17:03, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... there was a vote in favour of adopting this document as a WG document but as you know this vote should be confirmed in the ML. I have seen drafts becoming WG drafts after votes during meetings but, fair enough, let's see if, after the unanimous vote in the meeting, there are serious objections to it now. A call for adoption should normally be issued by the chairs according to the IETF procedure. As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, Support. Some of them were worth having, IMHO. add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Sure. Doing this while the draft is already a WG draft seems to me normal after the vote result (but no objection to doing it right away if found better. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. Offline discussions are of course completely free, and useful, but a WG consensus can only be built in the open, i.e. on the WG mailing list. I am aware of at least part of the offline discussion you refer to, and therefore suppose you meant dynamic vs static AND stateful vs _stateless_. Several pointed out, in that discussion, that the stateless dynamic combination doesn't really make sense. In any case, this discussion hasn't been pursued on the WG list. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward So do I, = +1 That is IMHO the only acceptable option in view of the vote result. but I'm open to the opinions of the working group members on how to proceed. Let's see then. Regards to all, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 16 août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc Škoberne; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org; softwires@ietf.org Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi Med, At the last meeting, a vote was taken to decide whether this draft should become a WG draft. The answer has been a crystal clear yes, with the common understanding that, as such, it would have to be improved and competed based on WG reactions. IMHO, making it a WG document asap will facilitate discussions like this one: thet will point to the right document. Is there any sort term plan to do what was approved? Kind regards, RD Le 16 août 2011 à 13:48, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear Nejc, Thank you for the comments. Please see my answers inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Nejc Škoberne Envoyé : mardi 16 août 2011 12:25 À : draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Cc : softwires@ietf.org Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation Hello, I have some comments on your draft, see inline. Regards, Nejc --- 2. Terminology This document makes use of the following terms: Stateful 4/6 solution (or stateful solution in short): denotes a solution where the network maintains user-session states relying on the activation of a NAT function in the Service Providers' network [I-D.ietf-behave-lsn-requirements]. The NAT function is responsible for sharing the same IPv4 address among several subscribers and to maintain user-session state. Stateless 4/6 solution (or stateless solution in short): denotes a solution which does not require any user-session state (seeSection 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. In an IPv4 address sharing context, dedicated functions are required
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hi, Med, and Nejc, Please see inline. You indeed loose agressive sharnig ratio, but you have somewhat more flexible addressing. Also, the CPEs can be then really simple devices, excluding any of the NAPT functionality, doing only stateless encapsulation. However, what you loose/gain is irrelevant for my point. I think this section should be modified in a way like the logging section or any other appropriate way, which explains, that this is not the benefit of the stateless nature, but rather the benefit of the static port allocation. [Qiong]: +1 Agree. Med: Your point is valid and the text should be updated accordingly. My comment aims to show that the comparison is not so that trivial. We can claim the stateful with port ranges can provide similar features as the stateless or the binding mode but we always forget to mention this lead to loose one of the characteristics of the stateful. We captured a similar discussion in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-01#section-4.2 : [Qiong]: In our situation, we do not regard aggressive sharing ratio as a vital important feature since the static port multiplex ratio is already enough for us. Besides, even for session-based CGN like ds-lite, we would still prefer to pre-define port-range for customers because our centralized log server can not deal with massive session-based log events. So it seems more reasonable for us to adopt static port arrangement which can largely reduce the log volume. Best regards Qiong Sun 5.2. Port Utilisation Efficiency CGN-based solutions, because they can dynamically assign ports, provide better IPv4 address sharing ratio than stateless solutions (i.e., can share the same IP address among a larger number of customers). For Service Providers who desire an aggressive IPv4 address sharing, a CGN-based solution is more suitable than the stateless. If a Service Provider adopts an aggressive address sharing ratio, it is likely to be attempted by enforcing a NAT port overloading mode and as a consequence some applications will break. However, as more and more hosts become dual-stack enabled, the need for ports in IPv4 is likely to decrease. The insurance to have the full set of 64K ports per host will be one of the incentives to have them IPv6 capable. Moreover, Service Providers should offload some services to IPv6 (e.g., DNS, VoIP). ___ 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] draft-operators-softwire-stateless-4v6-motivation
On 8/16/11 5:03 PM, mohamed.boucad...@orange-ftgroup.com wrote: 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: This sounds like a great idea. Nejc Škoberne, Olaf Maennel, myself and some others are already working on something similar, but more in form of scientific paper (you know, two columns and so...). RFC with similar content would also be great. Cheers, Jan Zorz ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hi, On 8/16/2011 11:03 PM, mohamed.boucad...@orange-ftgroup.com wrote: ... As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed. In favor of the first. Cheers, Jacni ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Hi all, |-Original Message- |From: Rémi Després [mailto:despres.r...@laposte.net] |Sent: Wednesday, August 17, 2011 12:28 AM |To: Softwires-wg |Cc: draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org |Subject: Re: [Softwires] |draft-operators-softwire-stateless-4v6-motivation | |Hello all, | |It appears that confirming on this list the vote made in |Quebec would be useful. Agreed. |Please see below. | |Le 16 août 2011 à 17:03, |mohamed.boucad...@orange-ftgroup.com |mohamed.boucad...@orange-ftgroup.com a écrit : | | ... there was a vote in favour of adopting this document as |a WG document but as you know this vote should be confirmed in the ML. | |I have seen drafts becoming WG drafts after votes during |meetings but, fair enough, let's see if, after the unanimous |vote in the meeting, there are serious objections to it now. | | | A call for adoption should normally be issued by the chairs |according to the IETF procedure. | | As for the content of the next iteration of the document, we |have two options so far: | | (1) Put back some sections which have been removed in -02, | |Support. |Some of them were worth having, IMHO. | | add a new section to discuss dynamic vs. static, | | handle the comments received from J. Arkko, etc. | |Sure. |Doing this while the draft is already a WG draft seems to me |normal after the vote result (but no objection to doing it |right away if found better. | | Or | | 2) An alternative structure has been proposed off-line by A. |Durand: discuss dynamic vs. static and stateful vs. dynamic. | |Offline discussions are of course completely free, and useful, |but a WG consensus can only be built in the open, i.e. on the |WG mailing list. |I am aware of at least part of the offline discussion you |refer to, and therefore suppose you meant dynamic vs static |AND stateful vs _stateless_. |Several pointed out, in that discussion, that the stateless |dynamic combination doesn't really make sense. |In any case, this discussion hasn't been pursued on the WG list. | | The analysis would elaborate the pros and cons of each |solution (static stateless, static stateful, dynamic |stateful,...). This document would be an analysis document and |not a motivation document anymore. This document has no |milestone in the charter IMHO. Note the charter mentions the |following: | | Aug 2011 - Adopt stateless legacy IPv4 solution motivation |document as a Working Group document | | | I personally think the first option is straightforward | |So do I, = +1 |That is IMHO the only acceptable option in view of the vote result. +1 Prefer the first option, as discussion dynamic allocation vs. static allocation in a new section other than discussing on the mailing list sounds to me the more practical and efficient one to meet the Chater milstone. Cheers, Xiaohong | | | but I'm open to the opinions of the working group members on |how to proceed. | |Let's see then. | |Regards to all, |RD | | | | Cheers, | Med | | | -Message d'origine- | De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : |mardi 16 | août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc |Skoberne; | draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org; | softwires@ietf.org Objet : Re: [Softwires] | draft-operators-softwire-stateless-4v6-motivation | | Hi Med, | | At the last meeting, a vote was taken to decide whether this |draft should become a WG draft. | The answer has been a crystal clear yes, with the common |understanding that, as such, it would have to be improved and |competed based on WG reactions. | | IMHO, making it a WG document asap will facilitate |discussions like this one: thet will point to the right document. | | Is there any sort term plan to do what was approved? | | Kind regards, | RD | | | | | Le 16 août 2011 à 13:48, |mohamed.boucad...@orange-ftgroup.com |mohamed.boucad...@orange-ftgroup.com a écrit : | | Dear Nejc, | | Thank you for the comments. Please see my answers inline. | | Cheers, | Med | | | -Message d'origine- | De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] | De la part de Nejc Skoberne Envoyé : mardi 16 août 2011 12:25 À : | draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org | Cc : softwires@ietf.org | Objet : [Softwires] |draft-operators-softwire-stateless-4v6-motivation | | Hello, | | I have some comments on your draft, see inline. | | Regards, | Nejc | | --- | 2. Terminology | | | | This document makes use of the following terms: | | Stateful 4/6 solution (or stateful solution in short): denotes a | solution where the network maintains |user-session | states relying on the activation of a NAT | function in the Service Providers' network | [I-D.ietf-behave-lsn-requirements]. The NAT | function
