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. > >> The use case description includes that the NTT CPE of a /48 site delegates a >> /52 prefix to the CE. >> Isn't this sufficient? > > 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. >> 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)? > > I'll send it you later. Excellent, thank you. Cheers, RD > > cheers, > --satoru > > On 2012/02/16, at 22:16, Rémi Després wrote: > >> >> Le 2012-02-16 à 13:52, Ole Trøan a écrit : >> >>> Remi, >>> >>> [...] >>> >>>>>> 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. >>> >>> 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. >> >> 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? >> >> >>>> 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. >> >> 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. >> >>> >>> 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) >> >> Not understood. >> >>> - how is the mechanism provisioned? there is no DHCPv6 path, unless the 3rd >>> party CPE has a tunnel >>> "home" >> >> 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)? >> >> >> >>> >>> cheers, >>> Ole >>> >>> >> > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
