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.

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

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

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

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

cheers,
Ole

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to