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

[<[e-mail]>]

Hi all, 

|-----Original Message-----
|From: Rémi Després [mailto:[e-mail]] 
|Sent: Wednesday, August 17, 2011 12:28 AM
|To: Softwires-wg
|Cc: [e-mail]
|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, 
|<[e-mail]> 
|<[e-mail]> 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:[e-mail]] Envoyé : 
|mardi 16 
|> août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc 
|Skoberne; 
|> [e-mail]; 
|> [e-mail] 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, 
|<[e-mail]> 
|<[e-mail]> a écrit :
|> 
|>> Dear Nejc,
|>> 
|>> Thank you for the comments. Please see my answers inline.
|>> 
|>> Cheers,
|>> Med
|>> 
|>> 
|>> -----Message d'origine-----
|>> De : [e-mail] [mailto:[e-mail]] 
|>> De la part de Nejc Skoberne Envoyé : mardi 16 août 2011 12:25 À : 
|>> [e-mail]
|>> Cc : [e-mail]
|>> 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
|>> [e-mail]
|>> https://www.ietf.org/mailman/listinfo/softwires
|> 
|> 
|
|
|
|