Re: [Softwires] Working group last call for draft-ietf-softwire-map-05

[Ole Troan <[e-mail]>]

Ian,

>> my previous comment was to the provisioning document, where I think it
>> would be ambiguous to have two options
>> to do the same thing.
>> 
>> do you have any proposed changes to MAP base, or is this for the
>> provisioning document?
> 
> [ian] I think that the simplest way to make all this work is together is
> to separate out the BMR for mesh mode and the 1:1 mapping rule. As long as
> the BMR is described as the mechanism for provisioning 1:1 mode, then the
> additional configuration parameters of the BMR must also be conveyed (I.e.
> all of the things that are detailed in section 5.2), even though many of
> them are only relevant for mesh.

a BMR consists of 3 elements, a Rule IPv6 prefix, a Rule IPv4 prefix and the
EA bits length. only the Rule IPv6 prefix isn't relevant for 1:1.
if _that_ is a problem then each element could be suboptions in DHCP, but I'm not
sure that's worth the complexity either.

> So, the change in the MAP base draft would be: if EA=0, then the IPv4
> configuration / port set is not provisioned within the BMR and is conveyed
> through another means (static, OPTION_MAP_BIND, DHCPv4 over DHCPv6 or
> whatever). This gives us the single method of configuring MAP 1:1/lw4o6.

creating another corner case that an implementation must take into regard.

a MAP node provisioned with no BMR and only OPTION_MAP_BIND could just map (sic)
the information in the OPTION_MAP_BIND into a BMR.

my argument is that this is a detail that can be taken care of in the MAP DHCP draft,
and that MAP base can still make the assumption that all its functions are done
based on the specified BMR/FMRs. there shouldn't be anything in MAP base
that forces a particular layout of the provisioning information.

> The MAP DHCP option draft then needs to be brought in line with this.

yes, the MAP DHCP draft must be updated no matter what.

cheers,
Ole