Hi Jorge, I was down with covid, hence the delay in response. Though data-plane flushes-off the duped MACs, control plane may need it in the RIB/Cache, to capture the MAC-learning states (MAC Sequence Number and the source vtep) for troubleshooting (for narrowing down on the source of problem), as the clearing may not solve the eventual problem but only alleviate it for some-time.
And that’s what the following draft proposes, it bundles-up the MAC states in each round of MAC-dampening (freezing/unfreezing): https://datatracker.ietf.org/doc/draft-saum-bess-dampening-backoff/ Regards, Saumya. From: Rabadan, Jorge (Nokia - US/Sunnyvale) [mailto:[email protected]] Sent: Friday, June 17, 2022 9:26 PM To: Dikshit, Saumya <[email protected]>; [email protected] Cc: [email protected] Subject: Re: (Authors of draft-ietf-bess-rfc7432bis) : Query regarding Loop Protection 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]<mailto:[email protected]>> Date: Friday, June 17, 2022 at 1:35 PM To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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<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]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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<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<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<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
