Jorge, Lots of thanks for your response. Can you also please clarify whether the marked means that an EVI that is attached to the misconfigured MH ES in question and is not elected as the DF on this MH ES MUST:
1. Suppress transmission of any traffic via the AC the MH ES in question (and, possibly, redirect it to the "mate: EVI/BD that has been elected as the DF) 2. Discard any traffic received from the AC on the MH ES in question and ignore any results of local DP-based MAC learning? 3. Update its FDB entries for any MAC address that has been locally learned from the MH ES in question to send traffic with this destination MAC address to the local EVI/BD in the elected DF 4. Indicate (by whatever method is used for this purpose) to the locally attached CE that the corresponding AC is not operational? Your feedback would be highly appreciated. Regards, and lots of thanks in advance, Sasha From: Jorge Rabadan (Nokia) <[email protected]> Sent: Sunday, March 1, 2026 3:12 AM To: Alexander Vainshtein <[email protected]>; [email protected] Cc: BESS <[email protected]> Subject: [EXTERNAL] Re: A question about Section 14.1.1 of draft-ietf-bess-rfc7432bis Hi Sasha, It is an error situation, and based on the spec the ES should now behave as single-active. If the all the PEs attached to the ES check for the multihoming mode (based on local and received A-D per ES routes), if they detect inconsistency, they should all fall back to single-active and only the DF would set the P bit to 1. There may be transient situations for PE4, but those should be solved very quickly. My two cents. Jorge From: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Date: Monday, December 22, 2025 at 6:20 AM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[email protected]>> Subject: A question about Section 14.1.1 of draft-ietf-bess-rfc7432bis CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi all, I have a question about Section 14.1.1 of draft-ietf-bess-rfc7432bis<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-13#section-14.1.1>. The first two para of this section say: <quote> For a given ES, if a remote PE has imported the set of Ethernet A‑D per ES routes from at least one PE, where the "Multihoming redundancy mode" in the ESI Label extended community is set to 1, then that remote PE MUST deduce that the ES is operating in Single-Active redundancy mode. This means that for a given <EVI, BD>, a given MAC address is reachable only via the PE announcing the associated MAC/IP Advertisement route - this PE will also have advertised an Ethernet A-D per EVI route for that <EVI, BD> with an L2-Attr extended community in which the P bit is set. I.e., the Primary DF Elected PE is also responsible for sending known unicast frames to the CE and receiving unicast and BUM frames from it. Similarly, the Backup DF Elected PE will have advertised an Ethernet AD per EVI route for <EVI, BD> with an L2-Attr extended community in which the B bit is set. <end quote> Please consider the following misconfiguration scenario depicted in the embedded diagram below: [cid:[email protected]] In this diagram, PE-4: 1. Should treat MH ES in question as if it were operating in Single-Active redundancy mode – with all the implications 2. At the same time, would receive per-EVI RT-1 for a specific EVI with P bit set in the attached L2-Attr Extended Community at least from PE-3 and PE-4 (and possibly also from PE-1 if it was elected as the DF for the EVI in question) 3. Could receive RT-2 for a specific MAC address from at least PE-3 and PE-4 (and possibly also from PE-1 if it was elected as the DF for the EVI in question). Can you please clarify what is the expected behavior of PE-4 regarding forwarding known unicast traffic for such a MAC address? Your response would 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 -- [email protected] To unsubscribe send an email to [email protected]
