Ole, Thanks for the clarification. More comments inline.
2013-01-29 à 18:14, Ole Troan <[email protected]> : > Remi, > >>>> (c) Once the rule is looked at, getting the PSID is easy (no more magic >>>> needed than to get find the PSID length ;-)). >>> >>> unless you are in 1:1 mode. >> >> There is a point here which AFAIK has never been discussed before. >> (A reference is welcome if there is one I missed). > > this has been covered in the 1:1 discussions. Let's proceed without a reference. (This isn't one.) > >> This point concerns 1:1 mappings (if needed in MAP-E), when combined with >> shared IPv4 addresses: >> - To be assigned a shared address, a CE needs a PSID in addition to its IPv4 >> address. >> - Currently, this PSID cannot be found in the 1:1 rule itself (ref. >> http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01.) > > there is no separate 1:1 rule. PSID is defined in OPTION_MAP_PORTPARAMS. Acknowledged. (I had missed this parameter.) > >> The approach that is in my understanding implied by Ole is that each >> concerned CE will be delegated a MAP-E IPv6 prefix, in addition to that used >> for native IPv6 addressing, with the PSID in it. (The detailed format isn't >> specified yet AFAIK, but specifying one is possible.) > > no, then you have misunderstood. Acknowledged. > >> Another approach, AFAIK much simpler in operations, is to add a rule >> parameter to assign a PSID, present in 1:1 rules. >> This eliminates the need to delegate to each CE an additional IPv6 prefix. >> >> Example: >> . CE delegated prefix: 2001:db8:0:100::/56 >> . BMR for this CE >> Rule IPv6 prefix : 2001:db8:0:100:/56 >> EA-bits length : 0 >> Rule IPv4 prefix : 1.1.1.1/32 >> PSID : 0x11 >> >> Conclusion: if 1:1 mappings are part of MAP-E, add a PSID parameter in 1:1 >> mapping rules. > > yes, that's how I at least have intended it to be. Acknowledged. > >> (Otherwise: (1) specify detailed formats of MAP-E specific delegated >> prefixes > /64; (2) explain why delegated prefixes used for IPV6 aren't >> found sufficient.) > > MAP should not put any restrictions for what prefix length a provider wishes > to delegate to an end user. > it should also allow the use of a separate address (or prefix) for MAP. I > don't see why we want to artificially > restrict the prefix lengths. Conclusion: it is now clarified that, even if 1:1 with shared addresses has to be covered, there is no need for any MAP-E prefix longer than 64 bits. Consequence: the sentence about overwriting "the most significant parts of the interface identifier" in case of such extra-long prefixes, isn't needed. It should be deleted. Regards, RD > > cheers, > Ole > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
