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

[<[e-mail]>]

More comments below. 

|-----Original Message-----
|From: DENG Xiaohong ESP/PEK 
|Sent: Wednesday, August 17, 2011 12:10 PM
|To: [e-mail]; [e-mail]
|Cc: [e-mail]
|Subject: Re: [Softwires] 
|draft-operators-softwire-stateless-4v6-motivation
|
|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.



If we look deep into  every combinations of statless/stateful allocations for stateless/stateful 
solutions, first would come up with the stateful allocations with stateful solution that's what we discussed
 in the previous emails of this thread, so no more comments  on this point, and if you want see more,
 please refer to previous notes where there are plenty of it. ;)

One more new production would be stateless allocations with stateless solution, which may make no
 sense at the first glance, but it might also be interesting to  consider it as an option, when stateful port 
allocation doesn't satisfied the port needs. This is something proposed by Satoru Matsushima off-line 
when we're talking about restricted port sets compatibility with  UPnP applications and/or even odd pairs
 requirement for other applications, but hopefully it could also be addressed by statelss address/port mapping 
if it would accept a consensus that past applications compatibility is worth to be addressed - IMHO it is. ;)


Yet, both analysis above do not have too much do with stateless *motivation* draft, IMHO. 


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

Exactly, as the stateless motivation is more focused on the requirement of stateless other than comparisons
between the two, less comparisons and more *motivations* makes more senses to me.


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

A slight correction to my previous comment here: It is fair enough
to mention in a new section indicating that  both dynamic allocation 
and static allocation are applicable to stateless and statful approaches, 
but not focus too much on anlysis the combinations of them, as the
reasons above.

Cheers,
Xiaohong



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