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