Subject: [Softwires] Support of CEs behind third party CPEs - need for a Suffix parameter

From: Rémi Després <[email-masked]>
Date: Wed, 15 Feb 2012 18:12:55 +0100

Hi Ole,

1.
Your comments about the following feature-comparison item have been:
- "possible with MAP-{E,T} too, but may require coordination of subnet numbering."
- "I don't see the point of having text in the specification for this use case. it is a deployment option."

 +----+--------------------------------------+-----+-----+-----+-----+
 |    | Feature (based on CURRENT drafts)    | MAP | MAP | 4rd | 4rd |
 |    |                                      |  -T |  -E |  -H |  -E |
 +----+--------------------------------------+-----+-----+-----+-----+
...
 |    |                                      |     |     |     |     |
 |  3 | Possible support of CEs behind       |  N  |  N  |  Y  |  Y  |
 |    | third-party CPEs                     |     |     |     |     |

But, AFAIK, it is not possible to configure a MAP domain for CEs attached to third-party CPEs (ref. use case 5.2.2 of the 4rd-U draft).

2.
To deal with some similar use cases, we had an optional Suffix parameter of Mapping rules in draft draft-despres-intarea-4rd-01 (of which co-authors were R. Després, S. Matsushima, T. Murakami, ... and yourself).

Having not seen in the WG that the need had disappeared, nor that another way to satisfy the need had been discussed, I did include the Suffix parameter in 4rd-U.

3.
A somewhat detailed explanation about this need, received in the past and IMHO clarifying, was something like this:

"For the instance, in Japan, NTT provides the access line to the end-users and ISPs provides the internet service over this access line. Sometimes, NTT CPE is located in front of the ISP's 4rd CE. Sometimes, only the ISP's 4rd CE is located at home as shown below.

--<ipv6>-- NTT CPE ---- ISP CE ----

--<ipv6>-- ISP CE --

It depends on the end-users' contract. If the end-user is getting some services from NTT, the NTT CPE is located at home and the ISP CE is located behind the NTT CE. If the end-user is not getting such a service, only ISP CE is located at home.

In both cases, the IPv6 network infrastructure assigns an IPv6 prefix to the customer site. If present, the NTT CPE receives an IPv6 prefix and then delegates a longer IPv6 prefix to the ISP CE. For example, a /48 IPv6 prefix is assigned to the NTT CPE, and the NTT CPE delegates a /52 after adding a 4bit suffix to the ISP CE. But in other cases, if the ISP CE is directly connected to the IPv6 network infrastructure, the ISP CE can get an IPv6 prefix without any suffix.

So, in one 4rd domain, some ISP CEs get shorter IPv6 prefixes directly from the IPv6 network (say /48) and some other ISP CEs get longer IPv6 prefixes from NTT CPEs (say /52). This means that the delegated IPv6 prefix consists of the Domain IPv6 prefix followed by EA bits, if the ISP CE is directly connected to the IPv6 network, and that the delegated prefix consists of the Domain IPv6 prefix, followed by EA bits, and followed by the added suffix if the ISP CE is connected to another CE."

4.
Without a suffix parameter in mapping rules that applies to CEs behind a third-party CPEs, CPE added suffixes would be included in EA bits. They would therefore be present as lower parts of PSIDs of CE that have shared IPv4 addresses. 
I don't see how this could work. 

5.
Of course, the suffix parameter can be added to MAP if decided (no problem with that), but the feature comparison table remains based on existing drafts.

Hoping this clarifies this issue, I welcome questions and comments from anyone in the WG, in particular from the MAP design team.
Regards,
RD

---

From: Ole Trøan <[email-masked]>
Date: Wed, 15 Feb 2012 21:03:34 +0100

Remi,

> - "I don't see the point of having text in the specification for this use case. it is a deployment option."

I would not expect those two cases would be in the same MAP domain. even though they could.

> It depends on the end-users' contract. If the end-user is getting some services from NTT, the NTT CPE is located at home and the ISP CE is located behind the NTT CE. If the end-user is not getting…

not quite. see Satoru-san's presentation from the Paris last week for details.

> So, in one 4rd domain, some ISP CEs get shorter IPv6 prefixes directly from the IPv6 network (say /48) and some other ISP CEs get longer IPv6 prefixes from NTT CPEs (say /52). This means that the d…

the End-user IPv6 prefix must be of the same length for all CEs using the same mapping rule.

> I don't see how this could work. 

incorrect, MAP includes an EA-bits length parameter. the EA-bits are included in the topmost End-user IPv6 prefix (in your example above).

> Of course, the suffix parameter can be added to MAP if decided (no problem with that), but the feature comparison table remains based on existing drafts.

not, needed. the MAP subnet-id is defined to be 0.

> Hoping this clarifies this issue, I welcome questions and comments from anyone in the WG, in particular from the MAP design team.

MAP supports "3rd party CPEs". (assuming all the other problems associated with provisioning are resolved.)
it also solves the case of directly connected and 3rd party CPEs within the same MAP domain. albeit I've never ever heard that as a real use case.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Feb 2012 12:28:12 +0100

Ole, Satoru-san,

> not quite. see Satoru-san's presentation from the Paris last week for details.

Where can I get it, or at least the relevant part?
(If the problem has changed, I will of course acknowledge and adapt.)

> the End-user IPv6 prefix must be of the same length for all CEs using the same mapping rule.

Indeed.
However, if needed, there can be several mapping rules.

> incorrect, MAP includes an EA-bits length parameter. the EA-bits are included in the topmost End-user IPv6 prefix (in your example above).

Not sure, Ole, what you find "incorrect". 
Are you making some assumptions that you don't express (see below)?

> not, needed. the MAP subnet-id is defined to be 0.

AFAIK, this statement makes sense only if you assume that the 4-bit NTT suffix is set to 0 in all customer sites.
If this is assumed, it is a great simplification of the problem.
It deserves to be clearly stated.
 
With this assumption, the suffix parameter is indeed no longer needed (not more for 4rd-U than for MAP).

> MAP supports "3rd party CPEs".

> (assuming all the other problems associated with provisioning are resolved.)

Which problem?
Being explicit would help.

> it also solves the case of directly connected and 3rd party CPEs within the same MAP domain.

Based on the assumption of CPE prefixes routed to CEs are always 0?

> albeit I've never ever heard that as a real use case.

Conclusion: 
Unless the need to support arbitrary-value suffixes in third-party CPEs, which was expressed as a firm requirement in the past, is confirmed in the WG, I will delete the suffix parameter in the next 4rd-U draft (a nice simplification :-)).

I added you, Satoru-san, as destination of this mail, in order to have your direct view what remains useful and what has ceased to be needed.

Thanks,
RD

---

From: Ole Trøan <[email-masked]>
Date: Thu, 16 Feb 2012 13:52:45 +0100

Remi,

[...]

> It deserves to be clearly stated.

MAP specifies a subnet-id of 0. those are the bits between the End-user IPv6 prefix length and the interface-id.
e.g. if a /56 is delegated there will be 8 bits of 0. we have discussed if this needs to be configurable.

> With this assumption, the suffix parameter is indeed no longer needed (not more for 4rd-U than for MAP).

regardless of what the suffix parameter is. 0xF or 0x0. it has to be the same across the domain.
in the 3rd party CPE use case, which prefixes are available to the 3rd party CPE may be outside of your control.

the 3rd party model has the following issues:
 - how to get routing for the MAP prefix
 - how does prefix assignment work at all (general IPv6 problem)
 - how is the mechanism provisioned? there is no DHCPv6 path, unless the 3rd party CPE has a tunnel
   "home"

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Feb 2012 14:16:07 +0100

> e.g. if a /56 is delegated there will be 8 bits of 0. we have discussed if this needs to be configurable.

Discussed, OK, but concluded what?
BTW, if the MAP team debates would be on a list having ITEF archives, contributions by members of the WG would be easier, IMHO.
Could you ask the WG chair to open such a mailing list?

> regardless of what the suffix parameter is. 0xF or 0x0. it has to be the same across the domain.

Having it the same for CEs whose IPv6 prefixes match the same mapping rule could be more flexible, but agreed, imposing that it is the same for each domain should be sufficient (this is the choice made for 4rd-U). 

> in the 3rd party CPE use case, which prefixes are available to the 3rd party CPE may be outside of your control.

In this case, a Domain IPv6 suffix is needed.
The question therefore  remains: is there a need or not to support this use case.

Without a response from Satoru-san, it might be assumed, by default, that the NTT CPE example is no longer of interest.
But, if the need is confirmed, a Domain IPv6 suffix is AFAIK needed. 
 
> - how does prefix assignment work at all (general IPv6 problem)

Not understood.

> - how is the mechanism provisioned? there is no DHCPv6 path, unless the 3rd party CPE has a tunnel

The use case description includes that the NTT CPE of a /48 site delegates a /52 prefix to the CE.
Isn't this sufficient?

RD

BTW, you asked me, to understand one of your points to "see Satoru-san's presentation from the Paris last week for details" .
Can you provide what I should see (or replace it in some way)?

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 16 Feb 2012 23:29:48 +0900

Hi Remi-san, Ole-san,

I still think that configurable suffix would help a case where a MAP CE cascaded another IPv6 CPE. On the other hand, it is true that second issue, which Ole-san pointed out that there's difficulty to predict stable prefix for MAP in that case, which mean MAP wouldn't work because the suffix would be varied through the MAP domain. IMO it isn't an issue to be solved by MAP specification, the issue is in IPv6 home networking. When the issue is solved, to be able to configurable suffix in MAP specification will be discussed. Until then it might be possible that I can assume that MAP CE always get stable suffix value for MAP in a specific case even in Japan. 

> The use case description includes that the NTT CPE of a /48 site delegates a /52 prefix to the CE.

It is one of variation. There's another case where you get just a /64 through RA. Which prefix length you get isn't related to Internet service. 

> Can you provide what I should see (or replace it in some way)?

I'll send it you later.

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Feb 2012 16:43:39 +0100

Thank you, Satoru-san, for the bringing more information on this issue.
More comments in line.

Le 2012-02-16 à 15:29, Satoru Matsushima a écrit :

> Hi Remi-san, Ole-san,
> 
> I still think that configurable suffix would help a case where a MAP CE cascaded another IPv6 CPE.

OK.
What there is today in 4rd-U may not be sufficient, but we can work to complete it if possible.
Actually, I now doubt that it is the right choice to have the suffix as Domain parameter instead of a per-rule parameter. (We had it as a per-rule parameter in the intarea-4rd draft.)

If there can be a Suffix per mapping rule, it seems to me we can configure mapping rules for all practical situations you have in mind.
In order to validate or invalidate this belief, would it be possible to have more details about some reference configurations that need to be supported? 

> On the other hand, it is true that second issue, which Ole-san pointed out that there's difficulty to predict stable prefix for MAP in that case, which mean MAP wouldn't work because the suffix would be varied through the MAP domain.

Configuring several mapping rules, each one with its own IPv6 prefix, IPv4 prefix, and Rule IPv6 suffix, looks like a viable approach.

> IMO it isn't an issue to be solved by MAP specification, the issue is in IPv6 home networking. When the issue is solved, to be able to configurable suffix in MAP specification will be discussed. Until then it might be possible that I can assume that MAP CE always get stable suffix value for MAP in a specific case even in Japan. 

If in addition this stable suffix can always be 0, that could indeed a short term solution.
But I don't understand why it would be needed to wait for IPv6 home networking to evolve before providing a satisfactory solution.

> It is one of variation. There's another case where you get just a /64 through RA. Which prefix length you get isn't related to Internet service. 

Understood.
Remarks above still apply.

>> Can you provide what I should see (or replace it in some way)?

Excellent, thank you.

Cheers,
RD