[bess] Alvaro Retana's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-bess-evpn-proxy-arp-nd-11: No Objection

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-proxy-arp-nd/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As mentioned in the Introduction:

   This document describes the Proxy-ARP/ND function in [RFC7432]
   networks, augmented by the capability of the ARP/ND Extended
   Community [I-D.ietf-bess-evpn-na-flags].  From that perspective this
   document updates [RFC7432].

Even with this statement, the purpose of this document and the relationship
between it, rfc7432 and I-D.ietf-bess-evpn-na-flags is not completely clear to
me.  I would like to understand the following:

- Why isn't this description included in I-D.ietf-bess-evpn-na-flags if the
  functionality is introduced there?

- This document formally Updates rfc7432, but I-D.ietf-bess-evpn-na-flags
  didn't. How can the description of the function Update rfc7432 if the
  functionality doesn't?  What exactly is the update to rfc7432?

- The WG developed this document alongside I-D.ietf-bess-evpn-na-flags, but it
  is not referenced from there.  Why?


Besides those high-level questions, I have a set of comments that are mostly
related to the normative language used.  I would like to see these issues
addressed before publication.


(1) §3.1 recommends this:

   The provisioned static IP->MAC entry SHOULD be advertised in EVPN with an
   ARP/ND Extended Community where the Immutable ARP/ND Binding Flag flag (I)
   is set to 1, as per [I-D.ietf-bess-evpn-na-flags].

...but I-D.ietf-bess-evpn-na-flags requires the behavior, from §3.1:

   o  If an IP->MAC pair is static (it has been configured) the
      corresponding MAC/IP Advertisement route MUST be sent along with
      an ARP/ND Extended Community with the I Flag set.


(2) §3.1: "An entry MAY associate a configured static IP to a list of
potential MACs, i.e. IP1->(MAC1,MAC2..MACN)."   s/MAY/may  This is not a
normative statement, but just a fact.


(3) The phrase "MUST/SHOULD be learned" is used several times, but the
normative action doesn't seem to apply to learning, but to what is required
to learn.  For example, from §3.1:

   a.  Proxy-ARP dynamic entries:

          They SHOULD be learned by snooping any ARP packet (Ethertype
          0x0806) received from the CEs attached to the BD.

A better wording would be something like: "The PE SHOULD snoop all ARP packets
received from the CEs in order to learn dynamic entries."   The normative
action is clear: snoop!

Please review/update other places where this phrase is used.


(4) §3.1: "They SHOULD be learned by snooping any ARP packet..."  Why is this
action only recommended? When would a PE not snoop the ARP packets? IOW, why
is MUST not used?  Note that neither rfc7432/I-D.ietf-bess-evpn-na-flags use
Normative language then talking about snooping.


(5) §3.1: "They SHOULD be learned out of the Target Address and TLLA information
in NA messages (Ethertype 0x86DD, ICMPv6 type 136) received from the CEs
attached to the BD."  Same questions...


(6) §3.1: "A Proxy-ND implementation SHOULD NOT learn IP->MAC entries from NS
messages, since they don't contain the R Flag required by the Proxy-ND reply
function."  If the R flag is required, when is it ok to learn from NS messages?
IOW, why is this action not a requirement?


(7) §3.1.1: "the node MUST remove that router from the Default Router
List...as specified in [RFC4861] section 7.3.3."   This is in fact already
specified in rfc4861, there's no need to specify it here again.  s/MUST/must


(8) §3.1.1: "Static entries SHOULD have the R Flag information added by the
management interface.  The O Flag information MAY also be added by the
management interface."   It sounds as if the action here is to add the flag,
right?   Perhaps: "The R Flag information SHOULD be added...for static
entries. ..."

When is it ok to not configure the flags?  Why is the configuration not
required?  The text in I-D.ietf-bess-evpn-na-flags seems to assume that it is
a requirement (but no normative language is used there): "R and O Flag
values...are...configured in case of static entries." (§3.1)   What if the
value is not configured, what is the default?


(9) §3.2:

   a.  When replying to ARP Request or NS messages, the PE SHOULD use
       the Proxy-ARP/ND entry MAC address as MAC SA.  This is
       RECOMMENDED so that the resolved MAC can be learned in the MAC
       FIB of potential layer-2 switches sitting between the PE and the
       CE requesting the Address Resolution.

It seems to me that the use as MAC SA should be required and not just
recommended "so that the resolved MAC can be learned in...layer-2 switches".
Why is that not the case?


(10) §3.2: "A PE SHOULD NOT reply to ARP probes received from the CEs."  When
is it ok for the PE to reply?  IOW, why is the behavior recommended and not
required?


(11) §3.2: "A PE SHOULD only reply to ARP-Request and NS messages with the
format specified in [RFC0826] and [RFC4861] respectively."  When is it ok to
reply using a different format, and what format would that be?


(12) §3.3: "The operator SHOULD be able to activate this option with one of
the following parameters..."  For the operator to be able to do anything, the
implementation has to support the functionality.  It might be better to
recommend the implementation...


(13) §5.1: "Existing mitigation solutions, such as the ARP-Sponge daemon
[ARP-Sponge] MAY also be used in this scenario."   This seems to just be an
example: s/MAY/may


(14) §6: "IXPs MUST still employ additional security mechanisms that protect the
peering network..."  Which are the required mechanisms?


(15) §6: "IXPs...SHOULD follow established BCPs such as the ones described in
[Euro-IX-BCP]."  When is it ok to not follow "established BCPs"?  Seeing that
you are normatively recommending something, please add specific mechanisms,
not just an example.


(16) The references to ARP-Sponge and Euro-IX-BCP don't include enough
information to access the documents.  Is there a stable link that can be
included?