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

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

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