Hi Saumya, In addition to Jorge’s comments, even the use of an ESI does not require a new DF capability. You are trying to do Jorge’s items 3-5 below without 1-2... i.e skip only ES discovery and DF part. This is achievable with an ESI-A on both interfaces but setting 2 different ES:Import route-targets on them: peering PEs won’t see each other for DF but remotes will receive all MACs, A-D routes (per ES and per EVI) with ESI-A and perform the resolution and aliasing steps 3-5 ?
I also somehow feel there MAY be a way to (ab-)use the MAC sticky bit with ESI-0 if/where implementation dictates. The wording of 15.2 may be just vague enough that an implementation which receives 2 remote MACs with sticky bit MAY choose to alias? But mismatched ES:import above is definitely more elegant. Regards, Luc André Luc André Burdet | Cisco | [email protected] | Tel: +1 613 254 4814 From: BESS <[email protected]> on behalf of Rabadan, Jorge (Nokia - US/Sunnyvale) <[email protected]> Date: Thursday, March 24, 2022 at 17:53 To: Dikshit, Saumya <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [bess] draft-saumvinayak-bess-all-df-bum Hi Saumya, As mentioned during the session, the default gateway ext community is used today for IRB MAC/IPs and not for your use-case. My proposal was to add an extension to use it for the firewalls MAC/IP routes in your use-case, since they act as default gateways too. EVPN Ethernet Segments are associated to the following procedures: * ES discovery via ES routes * DF Election and programming data path to forward BUM and unicast on DF * A-D per ES route advertisement/processing for mass withdraw and split-horizon filtering * A-D per EVI route advertisement/processing for Aliasing and backup procedures * Non-zero ESI MAC/IP route advertisement/processing Out of all that, I understood you only need the aliasing capabilities to a given firewall MAC, and avoid mobility procedures for such MACs. Is that correct? Wouldn’t be better a method that provides what you need? Sorry if I’m missing something here. Please help me understand why you are using a non-zero ethernet segment here. Thanks! Jorge From: Dikshit, Saumya <[email protected]> Date: Thursday, March 24, 2022 at 11:15 AM To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: RE: draft-saumvinayak-bess-all-df-bum Hi Jorge, The description in https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-04#section-10.1does 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 – 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. 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
