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

[<[e-mail]>]

On 13/05/2013 15:36, "Ole Troan" <[e-mail]> wrote:

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

[ian] It could be one way of doing it, but having just looked at what a
'composite' set of sub-options would look like for this, it's going to get
pretty ugly.

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

[ian] I agree, but the way that the draft is at the moment, there is a
direct line between v4 provisioning with BMR/FMR, the parameters that
BMRs/FMRs contain and then (in the MAP DHCP draft) the format and
interpretation of the BMR/FMR.

If you remove the BMR/FMR provisioning in Ex. 4 and also sec 5.2 para 3,
then you've opened it up so that you don't force (or strongly imply) 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