On 30/11/2012 14:17, "mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com> wrote:
>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, There are/were many unfortunate things in softwires, but keeping ds.-lite-isms out of this spec would certainly not be one of them. I sympathize with your POV that a way to "co-exist" is desired, and a CGN-exit draft needed, but that is simply *outside* the scope of this spec. The ds.-lite ship has sailed, and there is nothing common between this spec and ds.-lite other than RFC2473. Anything with RFC2473 "heritage" should be included otherwise. > >* 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. Yes, and I remain hopeful of distilling things down along that path. :-) Cheers, Woj.. > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
