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). [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. 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. _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
