Subject: [Softwires] draft-operators-softwire-stateless-4v6-motivation

From: Nejc Škoberne <[email-masked]>
Date: Tue, 16 Aug 2011 11:24:41 +0100

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.]

---

From: <[email-masked]>
Date: Tue, 16 Aug 2011 13:48:43 +0200

Dear Nejc,

Thank you for the comments. Please see my answers inline.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Nejc Škoberne
Envoyé : mardi 16 août 2011 12:25
À : [email-masked]
Cc : [email-masked]
Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation

Hello,

Regards,
Nejc

---------------
   2. Terminology

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.

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

Med: We have several co-authors who are not either in favour or maintaining this section. This text will be removed.

...

Med: I Agree. But then you loose other benefits of the stateful: have an aggressive address sharing ratio.

---

From: Nejc Škoberne <[email-masked]>
Date: Tue, 16 Aug 2011 13:00:46 +0100

Dear Med,

> 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.

> 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.

> 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

---

From: <[email-masked]>
Date: Tue, 16 Aug 2011 14:51:56 +0200

Re-,

Please see inline.

Cheers
Med 

-----Message d'origine-----
De : Nejc Škoberne [mailto:[email-masked]] 
Envoyé : mardi 16 août 2011 14:01
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]; [email-masked]
Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation

Dear Med,

[SNIP]

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:

"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)."

---

From: Rémi Després <[email-masked]>
Date: Tue, 16 Aug 2011 16:29:47 +0200

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, <[email-masked]> <[email-masked]> a écrit :

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Tue, 16 Aug 2011 17:03:02 +0200

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:[email-masked]] 
Envoyé : mardi 16 août 2011 16:30
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Nejc Škoberne; [email-masked]; [email-masked]
Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation

Hi Med,

Kind regards,
RD

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Aug 2011 11:27:56 -0400

[email-masked] wrote, on 08/16/2011 11:03 AM:
> (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:
> 
> 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

---

From: Rémi Després <[email-masked]>
Date: Tue, 16 Aug 2011 18:28:29 +0200

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, <[email-masked]> <[email-masked]> 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.
> 
> (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: 
> 
> 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

---

From: Qiong <[email-masked]>
Date: Wed, 17 Aug 2011 00:28:51 +0800

Hi, Med, and Nejc,

Please see inline.

> [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

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 16 Aug 2011 22:37:53 +0200

On 8/16/11 5:03 PM, [email-masked] 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

---

From: Jacni Qin <[email-masked]>
Date: Wed, 17 Aug 2011 08:52:09 +0800

Hi,

> 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

---

From: <[email-masked]>
Date: Wed, 17 Aug 2011 12:10:15 +0800

Hi all, 

|-----Original Message-----
|From: Rémi Després [mailto:[email-masked]] 
|Sent: Wednesday, August 17, 2011 12:28 AM
|To: Softwires-wg
|Cc: [email-masked]
|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, 
|<[email-masked]> 
|<[email-masked]> 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:[email-masked]] Envoyé : 
|mardi 16 
|> août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc 
|Skoberne; 
|> [email-masked]; 
|> [email-masked] 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, 
|<[email-masked]> 
|<[email-masked]> a écrit :
|> 
|>> Dear Nejc,
|>> 
|>> Thank you for the comments. Please see my answers inline.
|>> 
|>> Cheers,
|>> Med
|>> 
|>> 
|>> -----Message d'origine-----
|>> De : [email-masked] [mailto:[email-masked]] 
|>> De la part de Nejc Skoberne Envoyé : mardi 16 août 2011 12:25 À : 
|>> [email-masked]
|>> Cc : [email-masked]
|>> 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.  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?]
|>> 
|>> Med: We have several co-authors who are not either in 
|favour or maintaining this section. This text will be removed.
|>> 
|>> ...
|>> 
|>> 
|>>      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.]
|>> 
|>> Med: I Agree. But then you loose other benefits of the 
|stateful: have an aggressive address sharing ratio.
|>> _______________________________________________
|>> Softwires mailing list
|>> [email-masked]
|>> https://www.ietf.org/mailman/listinfo/softwires
|> 
|> 
|
|
|
|

---

From: <[email-masked]>
Date: Wed, 17 Aug 2011 08:46:31 +0200

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:[email-masked]]
Envoyé : mardi 16 août 2011 18:29
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Nejc Škoberne; [email-masked]; [email-masked]
Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation

Hi, Med, and Nejc,

Please see inline.

[Qiong]: +1 Agree.

[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

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: <[email-masked]>
Date: Wed, 17 Aug 2011 15:31:22 +0800

From: Qiong [mailto:[email-masked]] 
	Sent: Wednesday, August 17, 2011 12:29 AM
	To: BOUCADAIR Mohamed OLNC-NAD-TIP
	Cc: [email-masked]; [email-masked]
	Subject: Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation

	Hi, Med, and Nejc, 

	Please see inline.

		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. 

	

	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

---

From: <[email-masked]>
Date: Wed, 17 Aug 2011 15:57:03 +0800

More comments below. 

|-----Original Message-----
|From: DENG Xiaohong ESP/PEK 
|Sent: Wednesday, August 17, 2011 12:10 PM
|To: [email-masked]; [email-masked]
|Cc: [email-masked]
|Subject: Re: [Softwires] 
|draft-operators-softwire-stateless-4v6-motivation
|
|Hi all, 
|
||-----Original Message-----
||From: Rémi Després [mailto:[email-masked]]
||Sent: Wednesday, August 17, 2011 12:28 AM
||To: Softwires-wg
||Cc: [email-masked]
||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,
||<[email-masked]>
||<[email-masked]> 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.

If we look deep into  every combinations of statless/stateful allocations for stateless/stateful 
solutions, first would come up with the stateful allocations with stateful solution that's what we discussed
 in the previous emails of this thread, so no more comments  on this point, and if you want see more,
 please refer to previous notes where there are plenty of it. ;)

One more new production would be stateless allocations with stateless solution, which may make no
 sense at the first glance, but it might also be interesting to  consider it as an option, when stateful port 
allocation doesn't satisfied the port needs. This is something proposed by Satoru Matsushima off-line 
when we're talking about restricted port sets compatibility with  UPnP applications and/or even odd pairs
 requirement for other applications, but hopefully it could also be addressed by statelss address/port mapping 
if it would accept a consensus that past applications compatibility is worth to be addressed - IMHO it is. ;)

Yet, both analysis above do not have too much do with stateless *motivation* draft, IMHO. 

||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. 

Exactly, as the stateless motivation is more focused on the requirement of stateless other than comparisons
between the two, less comparisons and more *motivations* makes more senses to me.

||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.

A slight correction to my previous comment here: It is fair enough
to mention in a new section indicating that  both dynamic allocation 
and static allocation are applicable to stateless and statful approaches, 
but not focus too much on anlysis the combinations of them, as the
reasons above.

Cheers,
Xiaohong

|
|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:[email-masked]] Envoyé : 
||mardi 16
||> août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc
||Skoberne;
||> [email-masked];
||> [email-masked] 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,
||<[email-masked]>
||<[email-masked]> a écrit :
||> 
||>> Dear Nejc,
||>> 
||>> Thank you for the comments. Please see my answers inline.
||>> 
||>> Cheers,
||>> Med
||>> 
||>> 
||>> -----Message d'origine-----
||>> De : [email-masked] [mailto:[email-masked]]
||>> De la part de Nejc Skoberne Envoyé : mardi 16 août 2011 12:25 À : 
||>> [email-masked]
||>> Cc : [email-masked]
||>> 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.  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?]
||>> 
||>> Med: We have several co-authors who are not either in
||favour or maintaining this section. This text will be removed.
||>> 
||>> ...
||>> 
||>> 
||>>      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.]
||>> 
||>> Med: I Agree. But then you loose other benefits of the
||stateful: have an aggressive address sharing ratio.
||>> _______________________________________________
||>> Softwires mailing list
||>> [email-masked]
||>> https://www.ietf.org/mailman/listinfo/softwires
||> 
||> 
||
||
||
||
|
|