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

From: <[email-masked]>
Date: Thu, 29 Nov 2012 11:16:29 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 29 novembre 2012 10:57
À : [email-masked]
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
[email-masked]
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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 29 Nov 2012 13:58:48 +0000

Thanks Med. This is a highly exploratory draft to be used as a strawman to determine if an unified CPE is even possible. Please comment on it so that we can determine if proceeding in this path is worthwhile. Also, if you are interested in being an editor of this draft and are not currently working on any of the current solution drafts please contact the chairs.

Thanks
Suresh

----- Original Message -----
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, draft-cui-softwire-b4-translated-ds-lite <[email-masked]>, "Reinaldo Penno  (repenno)" <[email-masked]>, "[email-masked]" <[email-masked]>
Sent: 11/29/2012 5:16 AM
Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 29 novembre 2012 10:57
À : [email-masked]
Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt

Abstract:

Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Maoke <[email-masked]>
Date: Fri, 30 Nov 2012 11:31:27 +0900

thanks Med for the initialization of the work!

i noticed that:

1. MAP is working in the context of prefix delegation and therefore the LAN
side IPv6 addresses (prefix) is involved in the mapping between the IPv4
and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a
unified CPE is made, the logic of the address assignment to interfaces
should also consider this difference in the behaviour.

2. is the deployment of difference modes able to be overlapped? current
section 4.4 implies the answer is "yes". i agree. but is it the best
behaviour to select one mode at the device-wise according to a certain
preferences? my question is: when the CPE receives multiple
rules/parameter-sets from different sources of provisioning, can it store
and use these pieces of information to adapt packets for corresponding mode
of service, i.e., applying a proper mode on demand and session-specific?

3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency?

4. fragmentation issue is common to all modes and it is also needed to be
clarified/unified for the unified CPE.

only my 2 cents, identifying the problems that i expect this draft to
cover.

- maoke

2012/11/29 Suresh Krishnan <[email-masked]>

> Thanks Med. This is a highly exploratory draft to be used as a strawman to
> determine if an unified CPE is even possible. Please comment on it so that
> we can determine if proceeding in this path is worthwhile. Also, if you are
> interested in being an editor of this draft and are not currently working
> on any of the current solution drafts please contact the chairs.
>
> Thanks
> Suresh
>
>
> To: "[email-masked]" <
> [email-masked]>, "
> [email-masked]" <
> [email-masked]>, "
> [email-masked]" <
> [email-masked]>,
> draft-cui-softwire-b4-translated-ds-lite <
> [email-masked]>, "Reinaldo Penno
>  (repenno)" <[email-masked]>, "[email-masked]" <[email-masked]>
> Sent: 11/29/2012 5:16 AM

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 09:06:48 +0100

Dear Maoke,

Thank you for the review and comments.

Please see inline.

Cheers,
Med

________________________________
De : Maoke [mailto:[email-masked]]
Envoyé : vendredi 30 novembre 2012 03:31
À : Suresh Krishnan
Cc : BOUCADAIR Mohamed OLNC/OLN; draft-cui-softwire-b4-translated-ds-lite; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

i noticed that:

1. MAP is working in the context of prefix delegation and therefore the LAN side IPv6 addresses (prefix) is involved in the mapping between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unified CPE is made, the logic of the address assignment to interfaces should also consider this difference in the behaviour.
[Med] I'm not sure I understand your point. Could you please clarify further the difference between the stateless and binding mode and what you think it should be added to bullet (2.3.2) of Section 3.4? Thanks.

2. is the deployment of difference modes able to be overlapped? current section 4.4 implies the answer is "yes". i agree. but is it the best behaviour to select one mode at the device-wise according to a certain preferences? my question is: when the CPE receives multiple rules/parameter-sets from different sources of provisioning, can it store and use these pieces of information to adapt packets for corresponding mode of service, i.e., applying a proper mode on demand and session-specific?
[Med] The current text says:

   o  For a given network attachment, only one mode MUST be activated.
   o  The CPE MAY be configured by a user or via remote device
      management means (e.g., DHCP, TR-069).
   o  A network which supports one or several modes MUST return valid
      configuration data allowing requesting devices to unambiguously
      select a single mode to use for attachment.

Does this text answer your questions? If not, what you think is needed to be added? Thanks.

4. fragmentation issue is common to all modes and it is also needed to be clarified/unified for the unified CPE.
[Med] Fully agree. We preferred to focus first on the unified logic. If the WG accepts the proposed direction, then the document should be updated to cover items common to all modes.

only my 2 cents, identifying the problems that i expect this draft to cover.

- maoke

2012/11/29 Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
Thanks Med. This is a highly exploratory draft to be used as a strawman to determine if an unified CPE is even possible. Please comment on it so that we can determine if proceeding in this path is worthwhile. Also, if you are interested in being an editor of this draft and are not currently working on any of the current solution drafts please contact the chairs.

Thanks
Suresh

----- Original Message -----
From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, draft-cui-softwire-b4-translated-ds-lite <[email-masked]<mailto:[email-masked]>>, "Reinaldo Penno  (repenno)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: 11/29/2012 5:16 AM
Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Dear all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : jeudi 29 novembre 2012 10:57
À : [email-masked]<mailto:[email-masked]>
Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft> directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Maoke <[email-masked]>
Date: Fri, 30 Nov 2012 18:54:09 +0900

dear Med,

thanks for the response. please see inline.

2012/11/30 <[email-masked]>

> **
>  ------------------------------
> *De :* Maoke [mailto:[email-masked]]
> *Envoyé :* vendredi 30 novembre 2012 03:31
> *À :* Suresh Krishnan
> *Cc :* BOUCADAIR Mohamed OLNC/OLN;
> draft-cui-softwire-b4-translated-ds-lite;
> [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> *Objet :* Re: [Softwires] Unified Softwire CPE:
> draft-bfmk-softwire-unified-cpe
>
> 1. MAP is working in the context of prefix delegation and therefore the
> LAN side IPv6 addresses (prefix) is involved in the mapping between the
> IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a
> [Med] I'm not sure I understand your point. Could you please clarify
> further the difference between the stateless and binding mode and what you
> think it should be added to bullet (2.3.2) of Section 3.4? Thanks.
>
> [maoke] i a little doubt the binding mode is a proper way to unify the MAP
1:1 and lw4over6. because MAP 1:1 is still working in the model of
delegation while lw4over6 applies the WAN IPv6 address for the
encapsulation. what if the CPE has a delegated prefix at LAN and an address
at WAN simultaneously? which address is used for the source address of the
tunnel in the "binding mode"? is the CPE choice fits the reality at the
AFTR/BR? to my understanding, the behaviour of MAP 1:1 is identical with
any MAP but different from lw4over6 to some extent.

> [maoke ] why only ONE mode MUST be activated?

[maoke] we noticed a fact that a domain of softwire, at least MAP,  can be
different from the "domain" in the sense of autonomous system, because the
model of prefix delegation is totally independent of the deployment of the
softwire. this feature makes the softwire domain able to spread over
different AS. therefore it is possible that a CPE is involved in a AS's
lw4over6 domain and meanwhile also involved in a inter-AS MAP domain.
administration of the lw4over6 domain and that of the MAP domain are surely
independent to each other but they impact the CPE simultaneously -- it
could be treated as  a typical case of softwire multi-homing. and we expect
the CPE gets the benefits from the multi-homing: policy-based path
selection, load-balance, fault-tolerance, etc.

> [Med] Fully agree. We preferred to focus first on the unified logic. If
> the WG accepts the proposed direction, then the document should be updated
> to cover items common to all modes.
>
> thanks,
- maoke

P.S. i will be in a  3-nights&2-days trip since tonight so any further
discussion will be responded in the beginning of next week. sorry in
advance for the delay.

>> Thanks Med. This is a highly exploratory draft to be used as a strawman
>> to determine if an unified CPE is even possible. Please comment on it so
>> that we can determine if proceeding in this path is worthwhile. Also, if
>> you are interested in being an editor of this draft and are not currently
>> working on any of the current solution drafts please contact the chairs.
>>
>> Thanks
>> Suresh
>>
>>
>> [email-masked]>, "Reinaldo
>> Penno  (repenno)" <[email-masked]>, "[email-masked]" <
>> [email-masked]>
>> Sent: 11/29/2012 5:16 AM
>> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>directories:
>> http://www.ietf.org/shadow.html

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 30 Nov 2012 10:42:26 +0000

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.

B) I disagree that "co-existance" between Lw4o6 and MAP is a goal; 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.

In Section 3 the draft coin a new term/class of solution called "Binding
approach".
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.

Further in section 3 the draft lists different functional elements, and it
is here that major changes are needed. For a unified solution a functional
breakdown in a solution neutral text is essential. IMO A unified CE has
the following basic functionalities, which I propose to be added to the
text in place of the existing one:
- 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)

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.

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.

Regards,
Woj..

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 12:10:21 +0100

Hi Woj,

Many thanks for the comments. 

Please see inline. 

Cheers,
Med 

>De : Wojciech Dec (wdec) [mailto:[email-masked]] 
>Envoyé : vendredi 30 novembre 2012 11:42
>À : BOUCADAIR Mohamed OLNC/OLN; 
>[email-masked]; 
>[email-masked]; 
>draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno 
>(repenno); [email-masked]
>Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
>
>Hi,
>

>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. 
* Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint
* 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. 

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

 a
>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 

Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4.

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

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

IMO A unified CE has
>text in place of the existing one:

Med: Could you please point me which text you are referring to? Thanks. 

>- an IPv4 routing capability (also configurable)

Med: What does that mean?

>shows the essence of what we need to get at.

Med: Isn't that what is captured in "Table 3: Supported Features" ?

   +--------------+----------------+-----------------+-----------------+
   |   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    |
   +--------------+----------------+-----------------+-----------------+

>functionalities but rather how this functionality is configured.

Med: I guess you are talking about MAP1:1 and LW4over6.

>>As agreed in Atlanta, we prepared an I-D describing a 
>proposed approach
>>for the unified CPE.
>>
>>De : [email-masked] 
>[mailto:[email-masked]]
>>De la part de [email-masked]

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 30 Nov 2012 12:20:45 +0000

Hi Med.,

>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

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: MAP1:1 and lw4o6 are presented in the draft as soltuions for the

And the binding mode and duplicate descriptions should be removed IMO.
>Med: This is what we tried to do in
>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#section-4.3.
> 
>
>>
>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.
>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: 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
>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).

>Med: Could you please point me which text you are referring to? Thanks.
Section 3.1
>Med: What does that mean?

It means IPv4 routing, and the ability to set a default route and more
specific ones.
>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.

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

Cheers,
-Woj..

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Nov 2012 13:59:25 +0100

> Your comments, suggestions and contributions are more than welcome.

Here are some:

- First, I think this is very positive. I like what I'm reading.

- Didn't we also consider public 4o6 as one mode? Any reason why it was 
left out?
   - Is public 4o6 the "minor change to lw4o6" that section 4.1 hints at?

- In section "3.2. Required Provisoning Information", I believe it would 
be possible and beneficial to specify only what each mode requires *in 
addition* to what the previous mode already provides. e.g.
   - DS-Lite requires the remote tunnel endpoint address.
   - In addition to that, lw4o6 requires the CPE's IPv4 address and port 
set.
   - In addition to that, MAP requires mesh routes.
So each mode's provisioning parameters would be a superset of the 
previous one. (DS-Lite < lw4o6 < MAP)

One we have this kind of hierarchical provisioning, we can define CPE 
behaviour in the same way. For example, MAP behaviour would be:
1. Do exactly what a lw4o6 CPE does.
2. In addition to 1, also send and receive packets directly to and from 
other CPEs according to the provisioned mesh routes.

(I will refrain from commenting on section 4.4 until we have the 
higher-level design figured out.)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 14:09:11 +0100

Hi Simon,

Please see inline. 

Cheers,
Med 

>De : [email-masked] 
>[mailto:[email-masked]] De la part de Simon Perreault
>Envoyé : vendredi 30 novembre 2012 13:59
>À : [email-masked]
>proposed approach for the unified CPE.
>>

Med: Thanks.

>   - Is public 4o6 the "minor change to lw4o6" that section 

Med: The rationale we adopted in this draft is as follows:

* there are three major flavors: full stateful, full stateless, and binding mode
* all these modes can support assigning a full or a shared IPv4 address

As such Public4over6 is classified as part of binding mode (see Section 3)

   (2)  Binding approach (e.g., Lightweight 4over6 (Lw4o6)
        [I-D.cui-softwire-b4-translated-ds-lite],
        [I-D.ietf-softwire-public-4over6] or MAP 1:1
        [I-D.ietf-softwire-map] ): Requires a single per-subscriber
        state (or a few) to be maintained in the Service Provider's
        network. 

>previous one. (DS-Lite < lw4o6 < MAP)

Med: The current text of Section 3.2 says:

             +---------+-------------------------------------+
             |    Mode | Provisioning Information            |
             +---------+-------------------------------------+
             | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint |
             |   Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint |
             |         | IPv4 Address                        |
             |         | Port Set                            |
             |   MAP-E | Mapping Rules                       |
             |         | MAP Domain Parameters               |
             +---------+-------------------------------------+

                     Table 4: Provisioning Information

   Note: MAP Mapping Rules are translated into the following
   configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel
   Endpoints, IPv4 Address and Port Set.

Can you please explicit the change you want to see appear in that text? Thanks.

>other CPEs according to the provisioned mesh routes.

Med: Do you think this is different from the approach adopted in Section 4.3?

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 14:17:13 +0100

Re-,

Please see inline/ 

Cheers,
Med 

>Envoyé : vendredi 30 novembre 2012 13:21

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

>concentrator. It only cares about its own configuration and there is no

Med: You may notice, the algo proposed in Section 4.3 does only care about what to do with configuration parameters.

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 14:22:12 +0100

Hi Simon,

One answer in line (I think Med covered off the rest)

Cheers,
Ian

>higher-level design figured out.)

Ian: I broadly agree with what you've said, but one use case that did
cross my mind is if you only needed to provision mesh routes to a client
with no need for a concentrator/default route. A closed machine-to-machine
type service could be an example of this architecture.

I'm not sure if it's a strong enough use case to build the provisioning
model around, however.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Nov 2012 14:24:15 +0100

>          state (or a few) to be maintained in the Service Provider's

Ah, right, I missed that reference. Thanks.

> Med: The current text of Section 3.2 says:

Something like:

DS-Lite:
- Remote IPv4-in-IPv6 Tunnel Endpoint

Lw4o6:
- DS-Lite set of provisioning information
- IPv4 address
- Port set

MAP-E:
- Lw4o6 set of provisioning information
- Forwarding mapping rules

My intuition is that with a unified CPE we don't need MAP to 
differentiate between "basic mapping rule", "forwarding mapping rule", 
and "default mapping rule".
- Basic mapping rule is just a forwarding mapping rule + IPv4 address + 
port set.
- Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint.

So in MAP mode we can just provide forwarding mapping rules in addition 
to the stuff that L4o6 already requires.

> Med: Do you think this is different from the approach adopted in Section 4.3?

Well just from reading I thought it was different. Maybe your intent was 
what I expected, just not formulated the way I expected it.

One thing I expected to see is that if you take a unified CPE that only 
implements up to LW4o6 mode, and provision it with full MAP mode 
parameters, it will still work. It will ignore the forwarding mapping 
rules, and thus will not do mesh networking, but it will still work.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Nov 2012 14:38:26 +0100

> type service could be an example of this architecture.

Ah good point. I always forget about that use case.

> I'm not sure if it's a strong enough use case to build the provisioning

Not sure either.

Simon

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 30 Nov 2012 14:00:10 +0000

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

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

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

---

From: <[email-masked]>
Date: Fri, 30 Nov 2012 15:18:19 +0100

Re-,

>De : Simon Perreault [mailto:[email-masked]] 
>Envoyé : vendredi 30 novembre 2012 14:24
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]

Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP.

>to the stuff that L4o6 already requires.

Med: you need also MAP parameters (offset, EA-...).

>rules, and thus will not do mesh networking, but it will still work.

Med: Isn't this covered by the combination of these two points: 

and

   (1)  If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE
        MUST be configured with the required provisioning information
        listed in Table 4.  If all of the required information is not
        available locally, the CPE MUST use available provisioning means
        (e.g., DHCP) to retrieve the missing configuration data.

If one mode is enabled, the CPE won't ask for more than what it needs. 
If its receives more, it will ignore them. I can add this to text if you think it is missing.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Nov 2012 15:30:37 +0100

> Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP.

I don't follow. A MAP default mapping rule is exactly like a forwarding 
mapping rule, with added semantics saying "this chunk of IPv4 is yours". 
That can be split into a forwarding mapping rule + the usual LW4o6 
parameters, can't you?

> Med: you need also MAP parameters (offset, EA-...).

That stuff is included in a "forwarding mapping rule".

> If its receives more, it will ignore them. I can add this to text if you think it is missing.

I think it would be good, and I would even add a specific example of 
what happens if you plug a LW4o6 CPE in a MAP-enabled network. (What I 
wrote above.)

Thanks,
Simon

---

From: Ole Trøan <[email-masked]>
Date: Fri, 30 Nov 2012 20:36:24 +0100

Med, et al,

> * all these modes can support assigning a full or a shared IPv4 address

now you got me thinking, are these really the right modes from a CPE perspective?

let me try to explain, with my CPE implementor hat on, what "modes" would make sense?

- NAT placement. do I need a NAT on the CPE or not?
  (no NAT && no IPv4 address == DS-lite)
- full IPv4 address assigned.
  I can assign the IPv4 address to the tunnel endpoint interface, and use that address for
  local applications, and as the outbound address of the NAT
  (mechanisms: MAP, Public 4over6)
- IPv4 prefix assigned:
  I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN side DHCPv4 pool
  (mechanism: MAP)
- Shared IPv4 address.
  I must enable a local NAT, I cannot assign the IPv4 address on the "WAN" interface, but only use it
  for the outbound side of the NAT.

then there might be a sub-modes for "tunnel endpoint determination" i.e. how to determine an IPv6 tunnel end point address given an IPv4 destination address and port.
1) algorithmic (MAP)
2) configured (Public 4over6, LW46, DS-lite)

and a sub-mode for IPv4 address configuration:
1) As "native IPv4"
    (Public4over6, LW46)
2) Embedded Address
    (MAP)
3) None
   DS-lite

does this make sense?

cheers,
Ole

---

From: Qiong <[email-masked]>
Date: Sat, 1 Dec 2012 10:38:53 +0800

Hi Ole,

I think there is one more point, see inline ~~

On Sat, Dec 1, 2012 at 3:36 AM, Ole Trøan <[email-masked]> wrote:

> then there might be a sub-modes for "tunnel endpoint determination" i.e.
> how to determine an IPv6 tunnel end point address given an IPv4 destination
> address and port.
> 1) algorithmic (MAP)

[Qiong] and a sub-mode for "source IPv6 address determiniation", how to
determine the encapsulated IPv6 source address.
1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface
Identifier (MAP)
2) WAN IPv6 address (DS-Lite, LW46, Public 4over6)

Right ?

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Simon Perreault <[email-masked]>
Date: Sat, 01 Dec 2012 08:46:15 +0100

>    for the outbound side of the NAT.

Interesting... But note that even just implementing MAP alone would 
generate three of these "implementation modes". I would still like to 
see this list added to an "implementation considerations" section. Stuff 
like "you can't assign a partial address to a tunnel interface" may not 
be obvious to implementers.

> and a sub-mode for IPv4 address configuration:

Totally appropriate for an "implementation considerations" section IMHO.

Simon