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

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

Hi Med.,

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

>Hi Woj,
>
>Many thanks for the comments.
>
>Please see inline.
>
>Cheers,
>Med 
>
>>-----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.
> 
>
>>
>>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
> 
>
>>
>>Further in section 3 the draft lists different functional
>>elements, and it
>>is here that major changes are needed.
>
>Med: Section 3 is to be seen as a reminder for the solution flavors we
>have on the table. This section can be moved to an appendix. I would
>expect we focus our discussion on Section 4.
>
> For a unified solution
>>a functional
>>breakdown in a solution neutral text is essential.
>
>Med: We really tried to adopt a neutral terminology in Section 4.
>Suggestions are welcome on how to enhance that section.

Suggestion is to can the myriad of tables and agree to the break down the
basic functionality. This then allows us to focus on how it is expected to
be configured (the mechanism of configuration) and using what external
means (eg IP addresses, DHCP option).

>
>IMO A unified CE has
>>the following basic functionalities, which I propose to be added to the
>>text in place of the existing one:
>
>Med: Could you please point me which text you are referring to? Thanks.
Section 3.1
> 
>
>>- IPv4 NAT whose address and port restrictions are configurable
>>- an IPv6 transport whose source and destination transport address are
>>deterministically derived/configurable
>>
>>- an IPv4 routing capability (also configurable)
>
>Med: What does that mean?

It means IPv4 routing, and the ability to set a default route and more
specific ones.
>
>>
>>In example terms, consider a CPE configured with IPv4 address,
>>restricted
>>Port range X and IPv6 source address Y and transport address Z.
>>There is no difference in these parameters between Lw4o6 and
>>MAP, and it
>>shows the essence of what we need to get at.
>
>Med: Isn't that what is captured in "Table 3: Supported Features" ?

Yes, except you've dumped into this table DS.-lite, and made it replete
with what will be normative solution terms. Get rid of the table and just
state that the CPE has the basic functions of: ... And what these
functions are to be configured with and how.
>
>   +--------------+----------------+-----------------+-----------------+
>   |   Functional |  IPv4-in-IPv6  | Port-restricted | Port-restricted |
>   |      Element |     tunnel     |       IPv4      |      NAT44      |
>   |              |    endpoint    |                 |                 |
>   +--------------+----------------+-----------------+-----------------+
>   |           B4 |       Yes      |       N/A       |        No       |
>   +--------------+----------------+-----------------+-----------------+
>   |         lwB4 |       Yes      |       Yes       |     Optional    |
>   +--------------+----------------+-----------------+-----------------+
>   |     MAP-E CE |       Yes      |       Yes       |     Optional    |
>   +--------------+----------------+-----------------+-----------------+
>
>
>>
>>
>>One can comment further on the details of the draft, but
>>getting the basic
>>functional breakdown is essential (example above) before we
>>get into that.
>> The only thing different between the solutions are not the basic
>>functionalities but rather how this functionality is configured.
>
>Med: I guess you are talking about MAP1:1 and LW4over6.

Correct. Ds.-lite doesn't fit into this draft.

Cheers,
-Woj..
>
>>
>>Regards,
>>Woj..
>>
>>
>>
>>On 29/11/2012 11:16, "[e-mail]"
>><[e-mail]> wrote:
>>
>>>Dear all,
>>>
>>>As agreed in Atlanta, we prepared an I-D describing a
>>proposed approach
>>>for the unified CPE.
>>>
>>>We hope this version is a good starting point to have fruitful
>>>discussion. 
>>>
>>>Your comments, suggestions and contributions are more than welcome.
>>>
>>>Cheers,
>>>Med
>>>
>>>
>>>-----Message d'origine-----
>>>De : [e-mail]
>>[mailto:[e-mail]]
>>>De la part de [e-mail]
>>>Envoyé : jeudi 29 novembre 2012 10:57
>>>À : [e-mail]
>>>Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt
>>>
>>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>>
>>>
>>>	Title           : Unified Softwire CPE
>>>	Author(s)       : Mohamed Boucadair
>>>                          Ian Farrer
>>>                          Suresh Krishnan
>>>	Filename        : draft-bfmk-softwire-unified-cpe-00.txt
>>>	Pages           : 12
>>>	Date            : 2012-11-29
>>>
>>>Abstract:
>>>   Transporting IPv4 packets over IPv6 is a common solution to the
>>>   problem of IPv4 service continuity over IPv6-only provider
>>networks.
>>>   A number of differing functional approaches have been developed for
>>>   this, each having their own specific characteristics.  As these
>>>   approaches share a similar functional architecture and use the same
>>>   data plane mechanisms, this memo describes a specification
>>whereby a
>>>   single CPE can interwork with all of the standardized and proposed
>>>   approaches to providing encapsulated IPv4 in IPv6 services.
>>>
>>>
>>>The IETF datatracker status page for this draft is:
>>>https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe
>>>
>>>There's also a htmlized version available at:
>>>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00
>>>
>>>
>>>Internet-Drafts are also available by anonymous FTP at:
>>>ftp://ftp.ietf.org/internet-drafts/
>>>
>>>_______________________________________________
>>>I-D-Announce mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/i-d-announce
>>>Internet-Draft directories: http://www.ietf.org/shadow.html
>>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>