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

[<[e-mail]>]

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.