Hi all, |-----Original Message----- |From: Rémi Després [mailto:[email protected]] |Sent: Wednesday, August 17, 2011 12:28 AM |To: Softwires-wg |Cc: [email protected] |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, |<[email protected]> |<[email protected]> 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. +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. 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:[email protected]] Envoyé : |mardi 16 |> août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc |Skoberne; |> [email protected]; |> [email protected] 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, |<[email protected]> |<[email protected]> a écrit : |> |>> Dear Nejc, |>> |>> Thank you for the comments. Please see my answers inline. |>> |>> Cheers, |>> Med |>> |>> |>> -----Message d'origine----- |>> De : [email protected] [mailto:[email protected]] |>> De la part de Nejc Skoberne Envoyé : mardi 16 août 2011 12:25 À : |>> [email protected] |>> Cc : [email protected] |>> 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 |>> [email protected] |>> https://www.ietf.org/mailman/listinfo/softwires |> |> | | | | _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
