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

[Rémi Després <[e-mail]>]

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


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