Thank you Ole.  I was hoping my interpretation was correct as it allows for the 
provisioning strategies I've been considering.

Sincerely,

Jordan
________________________________________
From: [email protected] [[email protected]]
Sent: Tuesday, October 27, 2015 7:20 PM
To: Gottlieb, Jordan J
Cc: [email protected]
Subject: Re: [Softwires] Multiple MAP E/T Mapping Rules per Domain

Jordan,

> I’m looking to get clarification on a couple of items as they relate to 
> mapping rules.  Could not find any threads on the softwires WG mailing list 
> archive.
>
> Section 3 of RFC7597 defines a map rule as “A set of parameters describing 
> the mapping between an IPv4 prefix, IPv4 address, or shared IPv4 address and 
> an IPv6 prefix or address.  Each domain uses a different mapping rule set.”  
> Section 7.2 goes on to state that “The MAP BR MUST be configured with 
> corresponding mapping rules for each MAP domain for which it is acting as a 
> BR.”  That being said, a MAP domain definition on a BR should be able to 
> support multiple mapping rules.  Is this interpretation correct?  I want to 
> make sure that “Each domain uses a different mapping rule set” defines a list 
> of MAP rules and not the parameters that make up the rule.

yes.

> Building on the assertion above…What is the expected behavior for a MAP CE  
> when it is RFC7598 DHCPv6 provisioned with multiple Rule Options (single 
> container/domain),  F-flag not set on any rule, and a single End-user IPv6 
> prefix?  Is it acceptable for a MAP CE implementation to derive the BMR by 
> matching the End-user IPv6 prefix to the appropriate mapping rule (as 
> explicitly defined) while ignoring the non-matching rules given the F-flag 
> value 0?

yes.

if the F-flag was set, you'd end with multiple A+P routes for forwarding, but 
would only generate an IPv4 address from the End-user IPv6 prefix that matched.

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

Reply via email to