Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

["Wojciech Dec (wdec)" <[e-mail]>]

On 30/11/2012 14:17, "[e-mail]"
<[e-mail]> wrote:

>Re-,
>
>Please see inline/
>
>Cheers,
>Med 
>
>>-----Message d'origine-----
>>De : Wojciech Dec (wdec) [mailto:[e-mail]]
>>Envoyé : vendredi 30 novembre 2012 13:21
>>À : BOUCADAIR Mohamed OLNC/OLN;
>>[e-mail];
>>[e-mail];
>>[e-mail];
>>draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno
>>(repenno); [e-mail]
>>Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
>>
>>Hi Med.,
>>
>>On 30/11/2012 12:10, "[e-mail]"
>><[e-mail]> wrote:
>>
>>>
>>>>-----Message d'origine-----
>>>>De : Wojciech Dec (wdec) [mailto:[e-mail]]
>>>>Envoyé : vendredi 30 novembre 2012 11:42
>>>>À : BOUCADAIR Mohamed OLNC/OLN;
>>>>[e-mail];
>>>>[e-mail];
>>>>[e-mail];
>>>>draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno
>>>>(repenno); [e-mail]
>>>>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..
>