Subject: [bess] FW: draft-thubert-bess-secure-evpn-mac-signaling and RFC9047 ARP/ND extended community

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Dec 2021 15:19:05 +0000

Hello Jorge

Again many thanks for your review and comments.
I submitted 01 to cover this. Please have a look at the diffs in https://www.ietf.org/rfcdiff?url2=draft-thubert-bess-secure-evpn-mac-signaling-01.txt

Keep safe;

Pascal

From: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Sent: jeudi 11 novembre 2021 19:59
To: [email-masked]; [email-masked]
Subject: draft-thubert-bess-secure-evpn-mac-signaling and RFC9047 ARP/ND extended community

Dear authors,

As requested by Pascal, this is an email mostly to suggest the use of the ARP/ND ext community.
Also some additional comments about this draft:

  1.  Minor one: the acronym that we are using in all the EVPN specs is "EVPN" and not "eVPN" - it seems the document is using both, it would be good to just use "EVPN".

  1.  About this sentence - "Nevertheless, primary key of NRLI is still the IP/MAC/ESI combination" -> I think this is a mistake, the ESI is not part of the route key. The Ethernet Tag ID is, in addition to the MAC/IP and lengths.

  1.  As I suggested during the BESS session, the ARP/ND extended community might be a better fit for the some of the extensions, as opposed to the MAC mobility extended community. The ARP/ND extended community is defined in RFC9047.
     *   One of the reasons why I think the ARP/ND is a better fit is because the MAC Mobility ext community is used also with MAC/IP routes with IP=0, whereas the ARP/ND ext community is only used in MAC/IP routes with non-zero IP. Many times, a leaf will advertise first a MAC/IP route with IP=0 and later a MAC/IP route with a non-zero IP, both for the same MAC.
     *   An option could be to keep the TID+hash in the Mobility ext community sequence number, since from an EVPN perspective those two are really a sequence number, and move the rest of the flags defined in this document to the ARP/ND ext community.

  1.  Related to (3), the ARP/ND extended community already defines a way to signal that an IP->MAC binding belongs to an anycast IP (the O flag). Based on what I understood in your document, I think it would be ok to reuse that bit in your procedures, as opposed to define a new flag "A"

Thank you.
Jorge