Hi Erik, Thank you for the review. Please see in-line and let us know your thoughts.
Thanks! Jorge From: Erik Kline via Datatracker <[email protected]> Date: Wednesday, September 23, 2020 at 6:15 AM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Bocci, Matthew (Nokia - GB) <[email protected]>, Bocci, Matthew (Nokia - GB) <[email protected]> Subject: Erik Kline's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS) Erik Kline has entered the following ballot position for draft-ietf-bess-evpn-na-flags-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-na-flags/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [ general ] * ND in IPv6 is more than just its analogous ARP function (as immediately evidenced by the need to support passing the NA flags). I'm concerned that this approach isn't actually satisfactory for IPv6, and could end up constraining existing and future ND extensions and uses. [1] New flags As new flags are defined in the NA message, they will not be deployable in these environments until this standard (and possibly others) is updated. A more forward-compatible option might be to just include the whole NA "flags plus reserved" word (there is room for it in the format in section 2). [jorge] that could have been an option, however the authors made a decision to have the flags that were used for the required use cases. Also there are flags specific to the EVPN proxy-ARP/ND and IRB use cases that are not present in the NA messages, however they are needed on the PEs to make the right EVPN MAC/IP route selection (i.e. I flag). Also, there are already implementations so I’m afraid we can’t change the format of the extended community. IMHO if new NA flags are defined in the future, they may or may not be relevant to the EVPN MAC/IP route. And if they are, a new document should be needed to register a new flag in the ext community and explain the procedures. [2] Current and new NA ND Options This approach doesn't support sending additional ND Options in the NA, and therefore things like Secure Neighbor Discovery (SeND, RFC 3971) cannot be supported (nor can any future NA option). Arguably, ND proxying might best be disabled when a node is attempting to use SeND and/or whenever a Nonce Option is present an NA. Nevertheless, new ND options might be specified that can be carried in NS/NA messages. [jorge] I agree with you proxying might be best disabled if options are used (at least some). Note that this spec just defines an ARP/ND extended community that is not only used for proxy functions in EVPN networks. I think the issues related to the use of ND options in EVPN proxy-ND should be discussed in draft-ietf-bess-evpn-proxy-arp-nd. Actually section 4.3 in that spec is an attempt to address that. RFC 4861 sections 4.2 and 4.3 say that "[f]uture versions of this protocol may define new option types", and while it also says that "[r]eceivers MUST silently ignore any options they do not recognize and continue processing the message", in this case it would be the infrastructure that would prevent two nodes from attempting to use a newer ND option on either side of this PE/CE proxying boundary and not necessarily a limitation of the nodes themselves. There is no space for these options in the current section 2 format. Can it be extended to optionally carry the ND options that a PE has observed to be sent by the node? Alternatively, I think we'll need some text that ND proxying MUST be disabled if NSes contain any options other things like TLLAO or if NAs are observed to have anything other than SLLAO. Basically, I think we should take care to not impede the deployment of any extensions to ND. [jorge] these are all very good points, however, as I said earlier, all issues related to proxy-ND in EVPN networks should be addressed in draft-ietf-bess-evpn-proxy-arp-nd. It would be great if you can provide feedback about that document so that we make sure we address all your concerns.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
