Ali, Lots of thanks for a prompt and unambiguous response. Regards, Sasha
From: Ali Sajassi (sajassi) <saja...@cisco.com> Sent: Thursday, November 14, 2024 8:07 PM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; draft-ietf-bess-rfc7432...@ietf.org Cc: bess@ietf.org Subject: [EXTERNAL] Re: A question about MAC Mobility vs. Duplicate MAC address procedures in draft-ietf-bess-rfc7432bis Hi Sasha, The text as it is written states that: “ “a PE that detects a MAC mobility event via local learning starts an M-second timer (with a default value of M = 180), and if it detects N MAC moves before the timer expires (with a default value of N = 5), it concludes that a duplicate-MAC situation has occurred. The PE MUST alert the operator and stop sending, updating or processing any BGP MAC/IP Advertisement routes for that MAC address until a corrective action is taken by the operator.” This means upon detecting a MAC move (by learning the MAC locally) and incrementing the “move” counter by one and reaching N , it stops sending any new BGP MAC/IP Advertisement and stops updating/processing any remote BGP MAC/IP route for that MAC – i.e., there is no point in sending more BGP messages given that it is a duplicate MAC. The remote PEs will send packets to the PE that has advertised the highest sequence number even though another PE has detected the latest move. But that is OK because it is a duplicate MAC. Cheers, Ali From: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>> Date: Thursday, November 14, 2024 at 2:19 AM To: draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org> <draft-ietf-bess-rfc7432...@ietf.org<mailto:draft-ietf-bess-rfc7432...@ietf.org>> Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: A question about MAC Mobility vs. Duplicate MAC address procedures in draft-ietf-bess-rfc7432bis Hi, I have a question about the relationship between the MAC Mobility procedures in Section 15 of the draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-10#section-15> and the Duplicate MAC address procedures in Section 15.1 of the draft. Please consider the following sequence of events: 1. All PEs are configured with the same number N and the same timer T for detection of duplicate MAC addresses 2. A PE has detected a MAC Move event for a specific MAC address M (based on locally learning M after having received a RT-2 for this MAC address from a remote PE), and started timer T 3. While timer T is running, PE continues detecting local and remote MAC Move events for M and counts them until this count reaches (N-1). Every time this happens: a. If the MAC Move event was due to M being locally learned, PE increments the sequence number and advertises its RT-2 for M b. If the MAC Move even was due to receiving an RT-2 from a remote PE with higher sequence number, PE withdraws RT-2 it has advertised for M (if any) 4. While timer T is still running, the PE receives detects yet another MAC Move event for M, so that it now must declare M as duplicate and must “stop sending, updating or processing any BGP MAC/IP Advertisement routes” for M “until a corrective action is taken”. a. If the last MAC Move event for M has been detected due to local learning, should PE first advertise its RT-2 for M and only then stop sending, updating or processing any RT-2 for it, or should it suppress such advertisement? b. If the last MAC Move event for M has been detected due to receiving an RT-2 from a remote PE with higher sequence number, should the PE first withdraw RT-2 (if any) it has previously advertised for M and only then stop sending, updating or processing any RT-2 for it, or should it retain RT-2 it has previously advertised? 5. What, if any, should be the impact of the corrective action, when initiated in the PE, on the sequence number associated with M? Your timely feedback will be highly appreciated. Regards, and lots of thanks in advance, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
