Hi Tomek, Thank you for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Tomek > Mrugalski > Envoyé : mardi 10 janvier 2017 17:57 > À : Softwires-wg > Objet : [Softwires] Review of draft-ietf-softwire-multicast-prefix-option- > 11 > > I have reviewed draft-ietf-softwire-multicast-prefix-option-11 and have > one significant and several minor comments. > > Major issues: > > 1. The DHCPv6 option format. The format used (3 prefixes stuffed in a > single option) are not the preferred way to convey this kind of > information. This format is against the recommendation of DHCPv6 Option > Guidelines (RFC7227). See section 5.3 of that RFC. This is not a > nit-pick. There are a number of strong arguments for favouring 3 simple > options over one complex one. Here they are: > [Med] I'm aware of RFC7227 but the design of one single option is on purpose as recorded in the document: Note that it was tempting to define three distinct DHCPv6 options, but that approach was not adopted because it has a side effect: the specification of a DHCPv6 option that could be used to discover unicast PREFIX64s in environments where multicast is not enabled. Such side effect conflicts with the recommendation documented in Section 6 of [RFC7051]. We don't want to interfere with unicast-only recommendation in RFC7051. This DHCPv6 option is only used for multicast IPv4 service continuity. Note, the encoding of the IPv6 prefix follows the one in https://tools.ietf.org/html/rfc7227#section-5.3. It would be easy to define those as standalone options, but we are not doing that for the reason I mentioned above and for another technical reason that I'm discussing below. > - implementing simple option is trivial as this format is already > supported by most DHCPv6 implementations, so it's a matter of extending > existing code to cover additional option codes. > > - deploying is easier. Many implementations allow to define this kind of > option with configuration change and no need for software change. > > - better handling of optional prefixes. Section 3 says that the > asm-length, ssm-length and unicast-length can be 0. This means that > depending on the deployment, all of those fields are optional. This > would be better handled with separate options that are simply not > configured on the server when not needed. > > - better failure recovery. The text in section 2 says that some of the > prefixes are supposed to belong to well known prefixes. What the client > is supposed to do when the server sends a value that does not meet that > criteria? With a single option you'd have some sort of unclear decision > tree to ignore part of the option content. With 3 separate options, it's > simple - ignore the whole option. > > Now, there's one complication here: scope preservation. I'm not familiar > with the multicast technologies you're configuring, so I won't make any > specific recommendations here. If you send multiple instances of the > ASM, SSM and prefix64, are they logically grouped together? [Med] The scope is encoded in the multicast prefix itself. My > understanding is that the scope is encoded on the second octet of the > multicast address, right? So when you send multiple instances, it should > be possible to preserve the scope by matching whatever scope you have in > IPv4 with the IPv6 prefix with the same scope. I don't claim to know > much about multicast, though. I may be wrong on this. [Med] The problem is that distinct IPv4 prefixes may be used for each of these scopes: the issue then is how to associate each multicast prefix and unicast prefix. With the current encoding, this is not an issue. > > Now, if you considered all of the above, read RFC7227 and still believe > that having a single option rather than 3 is better way to go, I won't > insist. [Med] Ok, thanks. But you should add an explanation of the benefits of having a > single complex option that outweigh the simplicity proposed by 7227. [Med] There is already the text I quoted above that calls out this point. Please let me know if you think that more text is needed. > > Minor issues: > > 2. The explanation in last paragraph in Section 3 doesn't work for me. > It says one option rather than three are easier to detect environments > where multicastis not enabled. Not configuring 3 options is as simple as > not configuring 1 option. Also, the text references Section 6 of > RFC7051, which only says nothing about one complex vs three simple > options. It just says the DHCPv6 server and client code has to be > modified. If you want to follow that recommendation, using 3 options is > actually easier, because you can configure most clients and server with > custom options. That's a big plus for easier deployment when you can > just tweak the config file and be done rather than needing a new version > of the software. [Med] Actually, I'm not trying to argue in favor or against the text in Section 6 of RFC7051. The key point from that section is: it is recommended to use the Well-Known DNS Name heuristic discovery-based method for unicast-only environments. I changed the text to make this clear: OLD: Such side effect conflicts with the recommendation documented in Section 6 of [RFC7051]. NEW: Such side effect conflicts with the recommendation to support the Well-Known DNS Name heuristic discovery-based method for unicast-only environments (Section 6 of [RFC7051]). > > 3. Failure recovery. The text doesn't say what the client is supposed to > do when the server is misconfigured. In particular, if the prefixes are > supposed to belong to well known pools (e.g. a supposedly multicast > prefix that does not start with ff), what to do when they aren't. Should > just that prefix be discarded or the whole option? [Med] The checks whether the received prefix is a multicast prefix + (it is in ASM range for ASM, it is in the SSM range for SSM) is up to the multicast library not the DHCP client. We didn't want to overload the client with such processing that is done anyway by the multicast client that will make use of these prefixes. > > 4. What's the allowed prefix length is for ASM_PREFIX64 and SSM_PREFIX64 > is? Section 4, 2nd paragraph says it must be /96, but section 3 says > allowed values are from 0 to 128. As a DHCPv6 client and server > implementor, I'm confused what sanity checks I'm supposed to implement > here. Those two paragraphs seem to contradict each other. [Med] ASM_PREFIX64 and SSM_PREFIX64 must be /96. I fixed the text in Section 3. > > 5. Nit: I would add "DHCPv6" in the title of section 4. > > 6. Nit: Section 5: "DHCPv6 client MUST include OPTION_V6_PREFIX64 in its > OPTION_ORO." => "DHCPv6 client MUST include OPTION_V6_PREFIX64 code in > its OPTION_ORO". [Med] Fixed. > > That's it. IANA asked me to formulate my opinion on this draft no later > than Jan. 17th, so I'd appreciate authors' response before that date. > > Tomek > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
