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

[<[e-mail]>]

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, 
* 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.