[bess] Re: A questions about Section 5.2.3 of draft-ietf-bess-rfc8317bis

[Alexander Vainshtein <[e-mail]>]

Himanshu,
I see that you have registered for onsite participation in IETF-126 in Vienna.
I also plan to attend this meeting onsite – maybe we discuss this misconfiguration problem there?

Regards,
Sasha

From: Alexander Vainshtein
Sent: Thursday, October 30, 2025 11:48 AM
To: Shah, Himanshu <hshah=[e-mail]>
Cc: BESS <[e-mail]>; [e-mail]
Subject: RE: A questions about Section 5.2.3 of draft-ietf-bess-rfc8317bis
Importance: High

Himanshu,
Very glad to hear from you!

I fully agree with you regarding #2 – this is the only way to reliably prevent all kinds of problematic issues like Leaf-to-Leaf leakage, Ethernet loops etc.

Your proposal on #1 is possible but, IMHO, may be too late (some traffic would pass already before detection occurs). IMHO and FWIW a better way would be for an EVI/BD that is configured with a Leaf AC on a multi-homed Ethernet Segment to announce that immediately - e.g., by advertising a per-EVI Ethernet A-D route with the Leaf Extended Community with the Leaf flag set attached to it.

This would allow immediate detection of AC roles mismatch regardless of any traffic being received from the MH ES in question. Nor should it result in any interoperability issues with SW that follows original RFC 8317.

What do you think?


Regards,
Sasha

From: Shah, Himanshu <hshah=[e-mail]<mailto:hshah=[e-mail]>>
Sent: Monday, October 27, 2025 9:19 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: BESS <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: A questions about Section 5.2.3 of draft-ietf-bess-rfc8317bis

Right question!!
On 1) My thinking was that such misconfigurations can be detected by observing that one node has advertised the RT2 of MAC x with ‘L’ while other has not.
This would probably happen to all the MACs learned on that VLAN and ES. This could be used as indication to alert the operator??
On 2) IMO, disabling the AC with reason code as error of “misconfiguration detected”??

Again, this is assuming that Scenario 2 is used and route targets are not preventing receives of RT2 between the MH peers.

I would like the opinions of the authors on this as well.




Thanks,

Himanshu


From: Alexander Vainshtein <Alexander.Vainshtein=[e-mail]<mailto:Alexander.Vainshtein=[e-mail]>>
Date: Sunday, October 26, 2025 at 3:33 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: BESS <[e-mail]<mailto:[e-mail]>>
Subject: [**EXTERNAL**] [bess] A questions about Section 5.2.3 of draft-ietf-bess-rfc8317bis
Hi all,
Section 5.2.3 of the 8317bis draft [datatracker.ietf.org]<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc8317bis-00*section-5.2.3__;Iw!!OSsGDw!Nf1nWc0-x3Fj4R2stR_NJFuMeMcFRakLg2EsE01SDuzwSf8Fhb8-Lso1bui3lkUQd1HBGz3uD7zEBbxqXaPUWWnAGhk$>  defines handling of BUM traffic received from a Leaf AC on a multi-homed Ethernet Segment.

The text of this section (and the text of its predecessor, Section 4.2.3 of RFC 8317) is based on an assumption that "while different ACs (VLANs) on the same ES could have a different Root/Leaf designation (some being Roots and some being Leaves), the same VLAN does have the same Root/ Leaf designation on all PEs on the same ES".

I wonder what is expected to happen if this assumption is broken – either due to an error, or in a transient state when the operator changes designation of a given VLAN from Root to Leaf on multiple PEs attached to the same MH ES?

Specifically:
1.      Do you think that violation of this assumption should be detected and reported to the operator? If yes, could you possibly suggest how this condition can be detected?
2.      What, if anything, should be done to prevent traffic from returning to the same customer site from which it has originated?

Your feedback 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.