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

[Erik Kline <[e-mail]>]

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) <
[e-mail]> 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 <[e-mail]>
> *Date: *Wednesday, September 23, 2020 at 6:15 AM
> *To: *The IESG <[e-mail]>
> *Cc: *[e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, Bocci, Matthew
> (Nokia - GB) <[e-mail]>, Bocci, Matthew (Nokia - GB) <
> [e-mail]>
> *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.
>
>
>
>
>
>
>