Subject: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS)

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 22 Sep 2020 21:15:37 -0700

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.