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.
would think so. >>> 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. many functions in MAP are based on the BMR/FMR those cannot be removed from the specification. the mapping rules imply what needs to be provisioned, but it doesn't force a particular layout. perhaps we should circle back and look at the provisioning options again, and see if that will resolve this. if we end up with two provisioning options for the same thing, then there is no unification at that level. of course a MAP implementation might take something like an OPTION_MAP_BIND and "map" it into a BMR. btw, with LW46/OPTION_MAP_BIND, how would an AFTR know which IPv6 source address the B4 uses? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
