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) <jorge.raba...@nokia.com>
Sent: jeudi 11 novembre 2021 19:59
To: draft-thubert-bess-secure-evpn-mac-signal...@ietf.org; bess@ietf.org
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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
