Hi Jorge, The description in https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04#section-10.1<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04#section-10.1>does not applies to the problem at-hand. Reason being:
1. PEs (first hop Vteps for Firewalls) in contention are Layer-2 Vteps and not configured with IRB. 2. If I may call them as fabric bridge to reach the eventual gateway hosted on the firewall devices 3. Thus, the firewall-MAC is only a local host learning, and published by the PE without the "default gateway extended community". a. It's treated at par with any other host learning. 4. Standards don't stop to configure Segment(s) across fabrics. a. Essentially, it's about emulating connection to same "logical device" b. Realized by two physical devices underneath c. It's an abstraction and should be transparent to the EVPN configuration including Ethernet-Segment Hence the DF-capability on the first hop Vtep is needed. Let me know you thoughts about the same. May be I did not think enough in the "solution-direction" you are referring to. But above is the topology constraint, which needs a solution. Regards, Saumya. From: Dikshit, Saumya Sent: Wednesday, March 23, 2022 11:59 AM To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email protected]>; [email protected]; [email protected] Subject: RE: draft-saumvinayak-bess-all-df-bum Hi Jorge, Thanks for the comments. I will bump-up the mode value in the next-version, while, I am in middle of assessing the usage of "Default Gateway extended community" in the use-case mentioned in this draft. Thanks Saumya. From: Rabadan, Jorge (Nokia - US/Sunnyvale) [mailto:[email protected]] Sent: Monday, March 21, 2022 6:46 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: draft-saumvinayak-bess-all-df-bum Dear Saumya and authors, I wanted to follow up on what I mentioned at the mic this morning during the BESS session: 1) You are requesting DF Alg codepoint 2 for this draft, which clashes with https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-08#section-6<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-pref-df-08#section-6> - a Working Group draft with multiple implementations, so please remove that from the draft. 2) The use of an Ethernet Segment in this application is weird, and IMHO there are better ways to approach the issue. This is the rationale behind that statement: a. Eth Segment is defined as a group of links, multi-homed to the same network or CE. I don't think that fits the use-case. b. If I understood the use-case, the only part of the multi-homing procedures you are interested in is the advertisement of the Firewall MAC/IPs in a MAC/IP route that is not subject to mobility, and you want to apply aliasing on the remote PEs. BUM traffic is forwarded by all the PEs. c. If (b) is true, I don't think Ethernet Segments are the correct way to address this. As I mentioned, we use the Default Gateway extended community to indicate a MAC/IP route belongs to a default gateway that is not subject to mobility procedures - https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04#section-10.1<https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04#section-10.1>. Note that this section even talks about MAC aliasing. d. So if I may, my suggestion would be: i. do not use Eth Segments ii. Use the default-gateway ext community for the firewall MAC/IP routes. That naturally excludes these MACs from the mobility procedures iii. Based on the reception on the MAC/IP routes with the def gateway ext community, do MAC aliasing on the remote nodes Let me know if you have comments. Thank you. Jorge
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
