Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN)
draft-ietf-bess-evpn-na-flags-09

Thank you for responding to the SECDIR review (and thank you to Mališa Vučinić for performing it).

I support Rob Wilton's DISCUSS.

[ Update: Thank you for addressing my DISCUSS concern. ]

Other than my DISUCSSes, I found this document to be well written and easy to understand - thank you for writing it...

Thank you for the work put into this document. Even if I mainly rely on the int-dir review (see below), I quickly reviewed the document and found it very useful and readable.

Thanks to Ralf Weber who did the INT directory review, at https://datatracker.ietf.org/doc/review-ietf-bess-evpn-na-flags-05-intdir-lc-weber-2020-08-28/

Please find below a couple of non-blocking COMMENT and NIT points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 2  --
For my curiosity sake, why bit 5 of the 'Flags field' is not described? I would have naively assumed that all flags would be contiguous.

== NITS ==

-- Section 2 --
While it is specified that the reserved fields are set to 0, the usual 'and ignored by the receiver' is not present.

When describing the 'Router Flag', I suggest s/belongs to a router. /belongs to an IPv6 router./ even if fairly obvious

I support the DISCUSS positions from Erik, Warren and Rob.

Only minor comments here; please consider them, but there’s no need for a detailed reply.

A number of abbreviations need to be expanded on first use, including EVPN, PE, ND, IRB, and CE.

— Abstract —
The Abstract is exactly, word for word, the same as the first two paragraphs of the Introduction, except that the Introduction helpfully splits it into two paragraphs.  I have comments about the text below, but for the Abstract I suggest shortening it by removing the explanatory stuff and just leaving the summay of what this document is doing — just the final sentence looks fine, I think.

— Section 1 —

   An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or
   IPv6 addresses associated with a MAC address.

Nit: Change “an IPv4” to just “IPv4”, I think, yes?

   the PE would not know if that
   particular IPv6->MAC pair belongs to a host, a router or a host with
   an anycast address

Two things here:  This is a case where a comma after “router” will really help readability.  And isn’t “a host with an anycast address” also “a host”?  Can you rephrase this to make the distinction between the first and third list items clearer?

— Section 1.1 —
Shouldn’t “ND” also have a reference citation (RFC4861)?

— Section 2 —

   Bits 0-3 and 5 are not assigned by this document.

Shouldn’t this have the customary “MUST be set to zero, and ignored on receipt” text?

— Section 4 —

   This will cause all the PEs in the BD
   to reply Neighbor Solicitations for the IPv6 with Neighbor
   Advertisement messages containing the wrong R and O Flags.

There’s a word missing here after “reply”: I presume the missing word is “to”.

Should we say anything about how the ARP/ND Extended Community is
ignored in the absence of a sibling MAC/IP Advertisement Extended
Community?

Should we remind the reader how the recipient knows that a given ARP/ND
Extended Community is associated to the coresponding MAC/IP
Advertisement Extended Community?

There seems to be some latent risk in defining an "immutable" flag with
no defined way of clearing or unsetting it (e.g., having it time out).
We should either document what the operator should do when a formerly
immutable mapping needs to change or document the risk in the security
considerations section.  (This is, I think, related to Rob's Discuss.)

Section 1

   procedure.  However, the information conveyed in the EVPN MAC/IP
   Advertisement route may not be enough for the remote PE to reply to
   local ARP or ND requests.  For example, if a PE learns an IPv6->MAC

This makes it sound like we're rectifying a deficiency of the core spec,
and therefore might want to have an Updates: (or rather, "see also")
relationship to it.

   Advertisement routes.  Similarly, other information relevant to the
   host advertised in the MAC/IP Advertisement route may be needed.

(editorial) either we know what this "other information" is and could
list it explicitly (or by section reference), or we don't, and the
solution is incomplete.

Section 1.1

   Proxy-ARP/ND: function on the EVPN PEs by which received Address
   Resolution Protocol (ARP) Requests or Neighbor Solicitation (NS)
   messages are replied locally by the PE, without the need to flood the

nit: "replied to"

Section 2

Should we explicitly say that this is a transitive extended community?

   O - Override Flag (corresponds to Bit 22 of the Extended Community)
   Bit 6 of the Flags field is defined as the "Override Flag".  An
   egress PE will normally advertise IPv6->MAC pairs with the O Flag
   set, and only when IPv6 "anycast" is enabled in the BD or interface,
   the PE will send an IPv6->MAC pair with the O Flag = 0.  The ingress
   PE will install the ND entry with the received O Flag and will use
   this information when replying to a Neighbor Solicitation for the
   IPv6 address.  [...]

I'm not 100% sure I understand what this is saying.
My current understanding is that: at present (in the absence of this
extended community), a PE has to use heuristics to set the O flag in NA
messages, with the heuristic being "normally set the O flag, but when
the BD/interface has anycast enabled, clear the O flag".  The new
behavior when the information in this extended community is available,
is then to "always send the value received from the extended community".

However, if my understanding (above) is correct, that doesn't seem quite
right, since it's generally not safe to set the O flag in such an
"anycast" scenario.  Am I missing something?

   Community) is a configured ARP/ND entry.  The IP address in the EVPN
   MAC/IP Advertisement route can only be bound together with the MAC
   address specified in the same route.

nit: I'm not sure I understand what "can only be bound together with"
means here.  (What would the other option be?)

Section 3.1

Just to check my understanding: the dynamic learning here only applies
to NA messages received from the CE directly, not those received from
other EVPN routers?  (Do we need to say that explicitly?)

   o  This Extended Community does not change the procedures described
      in [RFC7432].  Specifically the procedures for advertising the MAC
      Mobility Extended Community along with the MAC/IP Advertisement
      route are not changed.

(side note) I'm not entirely sure how one might expect the MAC Mobility
processing to have changed as a result of the addition of the ARP/ND
Extended Community, but there doesn't seem to be any real harm in
mentioning it like this.

Section 3.2

      *  If the EVPN MAC/IP Advertisement route contains an IPv6 address
         and the EVPN ARP/ND Extended Community, the PE MUST add the R
         and O Flags to the ND entry in the ND or proxy-ND table and use
         that information in Neighbor Advertisements when replying to a
         Solicitation for the IPv6 address.

editorial: "add the R and O Flags" could sound like they are always set
to 1; perhaps "propagate the value of the R and O flags from the ARP/ND
Extended Community to the ND entry"?

         move as well.  Even so, if an update for the same IP1->MAC1
         immutable and static, is received from a different PE, one of
         the two routes will be selected, as in the [RFC7432] case where
         two MAC/IP routes with Static bit are received for the same MAC
         from different PEs.

I couldn't find much discussion of this scenario in RFC 7432 by
searching for "static" or "sticky"; could you help point me in the right
direction?

   destination to PE2.  If for some reason, PE3 originates an EVPN MAC/
   IP Advertisement route for IP1->MAC2 (even with a higher sequence
   number), then the EVPN PEs in the BD SHOULD NOT update their
   IP1->MAC1 ARP/ND bindings, since IP1 is bound to MAC1 (MAC2 SHOULD
   still be programmed in the layer-2 BDs).  This is considered a
   misconfiguration in PE3.

I don't really understand the motivation for SHOULD NOT, here.  It seems
like a PE would need to violate some other part of the spec in order to
do so, so just "will not" would be workable.
(I'm also left to assume that the route from PE3 sets I=0, which might
be worth making explicit.)

   The use of the Flag I=1 assumes that a given IP is always bound to
   the same MAC address, and therefore the mobility procedures described
   in [I-D.ietf-bess-evpn-irb-extended-mobility] for "Host IP move to a
   new MAC" will not apply.

Do we want to say anything about how things should behave if the
assumption is violated?

Section 4

It seems like this mechanism (or rather, RFC 7432's MAC/IP
Advertisement) doesn't really affect the spoofability of ND; the same
information (actually the same, now that this mechanism exists to send
the R/O flags) is being conveyed just over a different protocol, and
DAD/mobility should still work the same way.  There's an extra
translation step at the PEs the introduces an opportunity for
translation errors but that's not very noteworthy.

The I flag is somewhat different, as I mentioned at the top of my
comments.

   Similarly, the receiver of a NA message with the wrong R flag, may
   update its Default Router List incorrectly adding or removing an
   entry.

I suggest adding at the end of the sentence ", which could for example
lead to sending traffic to a node that is not a router, causing the
traffic to be dropped".

Section 5

Given the email discussion regarding the use of flag position 5, should
a note be left in the registry about that informal usage?

Thank you for your work on this document and resolving my discuss issue.

Regards,
Rob