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

[Rémi Després <[e-mail]>]

Ole, Satoru-san,

Le 2012-02-15 à 21:03, Ole Trøan a écrit :

> Remi,
> 
>> 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 --
> 
> 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 such a service, only ISP CE is located at home.
> 
> 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.)

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

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


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


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

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  




> 
> cheers,
> Ole
>