Understood. I agree that my concerns are probably better discussed over in draft-ietf-bess-evpn-proxy-arp-nd, as you suggest.
On Fri, Oct 9, 2020 at 4:25 AM Rabadan, Jorge (Nokia - US/Mountain View) < [email protected]> wrote: > 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
