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
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
