Hi Saumya, From: Dikshit, Saumya <saumya.diks...@hpe.com> Date: Tuesday, March 29, 2022 at 2:13 PM To: Luc André Burdet <laburdet.i...@gmail.com>, Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com>, draft-saumvinayak-bess-all-df-...@ietf.org <draft-saumvinayak-bess-all-df-...@ietf.org>, bess@ietf.org <bess@ietf.org> Subject: RE: draft-saumvinayak-bess-all-df-bum Hello Jorge, Luc,
Thanks a lot, for suggesting potential solution(s). I am not keep well, hence delay in response. @Jorge >>>> 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. <Saumya> · I completely missed that hint. And that would help for sure in providing redundant (Active/backup) reachability [jorge] I was suggesting to use the def-gw indication to do aliasing to the firewall MAC advertised from those two VTEPs. So active/active. But sure, you can also do best path selection and have active/backup. o Path to Remote Firewall will be “organically heavy” or can be made heavy (via configurations/route-maps) as per the path calculations. [jorge] I don’t understand the above statement, why is it heavy? o It will be applicable only to the MAC-route in this case, as Border-Vteps are Layer-2 end-points. [jorge] yes · How about ARP-request (or BUM traffic) for the gateway/firewall IP ? o It would be non-optimal, to spray ARP-request (or any other BUM for known On-SITE presence) over WAN, § even though there is an Active Instance (or destination) in the local-site. o Thus, the relaying of BUM over WAN should be nipped. o Hence, both Border-Vteps should be DFs to restrict the flooding to access network § And disallowing flooding back to the fabric due to split horizon [jorge] I’m really confused about the above text 😊. I think you wanted to flood BUM to the two firewalls, and not sending BUM to only one of them. So my proposal, i.e. no ES, would give you that. If you don’t want firewall-1 to send BUM to firewall-2, then putting both on the same ES works, but I didn’t see that in the draft.. IMHO you will need to clarify the text quite a bit. >>>> I understood you only need the aliasing capabilities to a given firewall >>>> MAC, and avoid mobility procedures for such MACs. <Saumya> · That’s not entirely correct. Aliasing equivalent to “single-active” is required. Effectively, for each fabric/site, local firewall should act as single-active. o MAC-aliasing via default-GW may work out well, as path calculation should make reachability to local-path preferable · And mobility indicators should be suppressed (sequence no.). [jorge] yes. Thank you, Jorge @Luc >>>> You are trying to do Jorge’s items 3-5 below without 1-2 <Saumya> As I mentioned earlier, split-horizon is needed for the ensuring all BUM enters the access segment,EVI via SITE local Border-Vtep >>>> 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 ? <Saumya> ES:Import route-targets could have been a good choice, if there is one EVI (Firewall specific) on the segment. In case there are more, then DF election needs to be done differently for Firewall EVI differently than other EVIs hosted on the same ESI. Regards, Saumya. From: Luc André Burdet [mailto:laburdet.i...@gmail.com] Sent: Friday, March 25, 2022 6:34 PM To: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com>; Dikshit, Saumya <saumya.diks...@hpe.com>; draft-saumvinayak-bess-all-df-...@ietf.org; bess@ietf.org Subject: Re: draft-saumvinayak-bess-all-df-bum 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 | laburdet.i...@gmail.com<mailto:laburdet.i...@gmail.com> | Tel: +1 613 254 4814 From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Date: Thursday, March 24, 2022 at 17:53 To: Dikshit, Saumya <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>>, draft-saumvinayak-bess-all-df-...@ietf.org<mailto:draft-saumvinayak-bess-all-df-...@ietf.org> <draft-saumvinayak-bess-all-df-...@ietf.org<mailto:draft-saumvinayak-bess-all-df-...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> 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 <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>> Date: Thursday, March 24, 2022 at 11:15 AM To: Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, draft-saumvinayak-bess-all-df-...@ietf.org<mailto:draft-saumvinayak-bess-all-df-...@ietf.org> <draft-saumvinayak-bess-all-df-...@ietf.org<mailto:draft-saumvinayak-bess-all-df-...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> 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) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>; draft-saumvinayak-bess-all-df-...@ietf.org<mailto:draft-saumvinayak-bess-all-df-...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> 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:jorge.raba...@nokia.com] Sent: Monday, March 21, 2022 6:46 PM To: draft-saumvinayak-bess-all-df-...@ietf.org<mailto:draft-saumvinayak-bess-all-df-...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
