Hi Pascal, 3: Sounds good. About the highly mobile host, I see what you are saying, although it might not be a real life issue:
* The sequence number is 4 bytes, so 4,294,967,295 moves! * And the sequence number ‘should’ be reset if the MAC is flushed for some reason 4: No objection 😊 Thanks. Jorge From: Pascal Thubert (pthubert) <pthub...@cisco.com> Date: Monday, November 15, 2021 at 12:11 PM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>, draft-thubert-bess-secure-evpn-mac-signal...@ietf.org <draft-thubert-bess-secure-evpn-mac-signal...@ietf.org>, bess@ietf.org <bess@ietf.org> Subject: RE: draft-thubert-bess-secure-evpn-mac-signaling and RFC9047 ARP/ND extended community Hello Jorge Many thanks for all! 1 and 2: will do 3: Ideally we’d move both the flags and the ROVR hash to the ARP/ND community since it is really a proof of ownership (akin to identity as opposed to sequence number), and keep only the TID in the sequence counter. The idea is that when present the TID always wins vs a legacy sequence. On paper that’s not doable if the node is highly mobile and roams for a very very long time. I’m open t suggestion on the best thing to do. 4: very cool. Not that we can now register multicast addresses with https://www.ietf.org/archive/id/draft-thubert-6lo-multicast-registration-02.html. Would you agree to have a new M flag, that would serve as a MLD snooping replacement? 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”. 2. 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. 3. 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. o 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. o 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. 4. 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
