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