Re-, Please see inline/
Cheers, Med >-----Message d'origine----- >De : Wojciech Dec (wdec) [mailto:w...@cisco.com] >Envoyé : vendredi 30 novembre 2012 13:21 >À : BOUCADAIR Mohamed OLNC/OLN; >draft-ietf-softwire-...@tools.ietf.org; >draft-ietf-softwire-map-d...@tools.ietf.org; >draft-ietf-softwire-public-4ov...@tools.ietf.org; >draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno >(repenno); softwires@ietf.org >Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe > >Hi Med., > >On 30/11/2012 12:10, "mohamed.boucad...@orange.com" ><mohamed.boucad...@orange.com> wrote: > >> >>>-----Message d'origine----- >>>De : Wojciech Dec (wdec) [mailto:w...@cisco.com] >>>Envoyé : vendredi 30 novembre 2012 11:42 >>>À : BOUCADAIR Mohamed OLNC/OLN; >>>draft-ietf-softwire-...@tools.ietf.org; >>>draft-ietf-softwire-map-d...@tools.ietf.org; >>>draft-ietf-softwire-public-4ov...@tools.ietf.org; >>>draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno >>>(repenno); softwires@ietf.org >>>Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe >>> >>>Hi, >>> >>>While thanking the authors for their attempt, I need to >>>provide some high >>>level feedback first on key issues: >> >>>The rationale section 1.1 states "co-existance" as the goal - >>>this appears >>>to imply some entirely different solutions for which co-existance is >>>needed", and here are two points: >>>A) I can agree that DS.-lite is an entirely different solution, but I >>>firmly believe that it is entirely outside the agreed scope >which was a >>>"unified solution CPE spec" in the context of MAP and Lw4o6. >>>Thus, I would >>>recommend that ds.-lite be dropped from this draft as it bears no >>>influence on "unifying" MAP and Lw4o6, nor does it bear >anything on the >>>already "defined and shipped" ds.-lite solution. Work on >such themes of >>>"multiple solutions coexisting" is what the v6ops CPE draft >is covering >>>and I would place ds.-lite coexistence there. >> >>Med: We included DS-Lite in the scope because of the following: >> >>* Several WG participants are concerned with optimizing the code and >>re-using existing modules. > >This is an implementation reason. Should we include in this >draft anything >that re-uses IPinIP tunneling, which is presumably the module >in question? > >> >>* Some DS-Lite components are shared with A+P solution: e.g., tunnel >>endpoint > >The tunnel endpoint is "an address", and again, this hardly justfies >ds.-lite inclusion >Most notably the functionality of the regular DS.-lite AFTR is >orthogonal >to the working of the CPE. > >>* A+P may be seen as an exit strategy of the CGN: >optimisation migration >>path and required changes in the CPEs need to be taken into account. > >These topics are fine subject for some CGN-exit draft, rather then >muddying up this one. Med: It is unfortunate to specify a unified CPE and exclude DS-Lite from it. All the solutions we are discussing have the same objectives: offer IPv4 service continuity over IPv6 network. Unlike A+P related solution, * DS-Lite code is already supported by some CPEs * NAT44 code is already supported by CPEs * A standard method to provision the remote IPv4-in-IPv6 tunnel endpoint The draft provides these items as a reminder. Having this big picture view will help in assessing which modules are worth to be re-used and which functions are missing. New solutions is almost a combination of existing modules + new configuration parameters. As I said earlier, all Section 3 can be removed to an appendix. I personally preferred to have in the core text for -00 so the WG is aware of: * solution flavors * subtleties between these solutions >> >> >>> >>>B) I disagree that "co-existance" between Lw4o6 and MAP is a goal; >> >>Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the >>binding mode. > >And the binding mode and duplicate descriptions should be removed IMO. >> >> a >>>unified functional CPE spec for NAT44-less core relays >>>accessed via IPv6 >>>is. As such, describing "modes" as in "solution modes" is not >>>conductive >>>to that and a solution term neutral functional breakdown is >>>essential and >>>IMO possible (further explained below). This will only make the spec >>>better and simpler for implementers. >> >>Med: This is what we tried to do in >>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00# >section-4.3. >> >> >>> >>>In Section 3 the draft coin a new term/class of solution >>>called "Binding >>>approach". >> >>Med: FYI, this is not a new term: please refer to >>http://tools.ietf.org/html/rfc6346#section-4.4. > >The point is that this is effectively configuration state, and >calling it >new terms is not changing things. >> >> >>>This effectively refers to configuration state which *all* >>>solutions need, >>>and is not helpful in providing anything but more verbiage. >>>Removing this >>>classification from all of the text is recommended. >> >>Med: IMHO this is the core of the discussion between MAP and >Lw4o6 teams. >>Having a neutral terminology and a full understand of what >this is about >>is IMHO important to converge. > >You don't need any terminology like "binding mode", especially >in the CPE >spec since the CPE side doesn't care about what configuration is on the >concentrator. It only cares about its own configuration and there is no >difference Med: You may notice, the algo proposed in Section 4.3 does only care about what to do with configuration parameters. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
