Hi, Not completely sure where you are coming from đ
Even without loop protection, suppose you have just normal mac duplication as in RFC7432. When the duplicate mac is flushed, it should be flushed from data and control plane. Removing the mac from the data path bridge-table but keeping the control plane out of synch sounds wrong to me. Thanks. Jorge From: Dikshit, Saumya <[email protected]> Date: Friday, June 17, 2022 at 1:35 PM To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: RE: (Authors of draft-ietf-bess-rfc7432bis) : Query regarding Loop Protection Hi Jorge, Thanks for the response. Does the flushing of M indicates a dataplane bridge-table flushing or the protocol-Rib flushing or implicitly both. The control-plane Rib may still cache it while waiting for the withdraw from remote-vtep. If it implies just the dataplane clearing, then procedures mentioned (count and timer to detect duplicate-MAC) https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04.txt#section-15.1 may still be working over the RIB-learnings from remote-vteps, leading to detection of duplicate MAC again. Whether the process should be restarted for just âloop-protectionâ as the control plane procedures will detect MAC-duplicate ? Or if the all RIBs are also cleared, then obviously the process restart means both âMAC-dup-detectionâ and âloop-protectionâ Regards, Saumya From: Rabadan, Jorge (Nokia - US/Sunnyvale) [mailto:[email protected]] Sent: Friday, June 17, 2022 1:11 PM To: Dikshit, Saumya <[email protected]>; [email protected] Cc: [email protected] Subject: Re: (Authors of draft-ietf-bess-rfc7432bis) : Query regarding Loop Protection Hi, It refers to the fact that the MAC is flushed from the bridge-table and therefore it is no longer duplicate. The router needs to clear the duplicate state and obviously, if the mac keeps moving, the router starts counting the moves again withing the duplication window. The key point is that âthe PE flushes Mâ. With that in mind, I donât think there is any ambiguity, but let us know. Thanks. Jorge From: Dikshit, Saumya <[email protected]<mailto:[email protected]>> Date: Wednesday, June 15, 2022 at 8:31 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: (Authors of draft-ietf-bess-rfc7432bis) : Query regarding Loop Protection Hello Authors of draft-ietf-bess-rfc7432bis, I have a query regarding the section of âLoop Protectionâ https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04.txt#section-15.3 in the document. There is a statement regarding the âprocessâ to be restarted after retry-timer expires. Which âprocessâ is being referred to here ? Is it just ONLY the âloop-protectionâ Or the âcomplete processâ of âMAC Duplication Handling + Loop-protectionâ: implying both sections https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04.txt#section-15.1 and https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04.txt#section-15.3 in that order. The reference text is as follows: â When the retry-timer R for M expires, the PE flushes M from the Bridge Table and the process is restarted.â Regards, Saumya.
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
