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

[<[e-mail]>]

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:[e-mail]] 
Envoyé : mardi 16 août 2011 16:30
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Nejc Škoberne; [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 Škoberne
> 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