Subject: [bess] draft-saumvinayak-bess-all-df-bum

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Mon, 21 Mar 2022 13:16:26 +0000

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.

  1.  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:

     *   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.
     *   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.
     *   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.
     *   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

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Wed, 23 Mar 2022 06:28:58 +0000

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-masked]]
Sent: Monday, March 21, 2022 6:46 PM
To: [email-masked]; [email-masked]
Subject: draft-saumvinayak-bess-all-df-bum

Dear Saumya and authors,

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:

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Thu, 24 Mar 2022 10:15:02 +0000

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-masked]>; [email-masked]; [email-masked]
Subject: RE: draft-saumvinayak-bess-all-df-bum

Hi Jorge,

Thanks for the comments.

Thanks
Saumya.

From: Rabadan, Jorge (Nokia - US/Sunnyvale) [mailto:[email-masked]]
Sent: Monday, March 21, 2022 6:46 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: draft-saumvinayak-bess-all-df-bum

Dear Saumya and authors,

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Thu, 24 Mar 2022 21:53:23 +0000

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-masked]>
Date: Thursday, March 24, 2022 at 11:15 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
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:

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”

c.       It’s an abstraction and should be transparent to the EVPN configuration including Ethernet-Segment

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

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.

Dear Saumya and authors,

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.

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:

---

From: Luc André Burdet <[email-masked]>
Date: Fri, 25 Mar 2022 13:04:12 +0000

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-masked]  |  Tel: +1 613 254 4814

From: BESS <[email-masked]> on behalf of Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]>
Date: Thursday, March 24, 2022 at 17:53
To: Dikshit, Saumya <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [bess] draft-saumvinayak-bess-all-df-bum
Hi Saumya,

Thanks!
Jorge

Regards,
Saumya.

From: Dikshit, Saumya

Hi Jorge,

Thanks for the comments.

Thanks
Saumya.

Dear Saumya and authors,

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Tue, 29 Mar 2022 12:13:30 +0000

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

o   Path to Remote Firewall will be "organically heavy" or can be made heavy (via configurations/route-maps) as per the path calculations.

o   It will be applicable only to the MAC-route in this case, as Border-Vteps are Layer-2 end-points.

·       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

>>>> 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.).

@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:[email-masked]]
Sent: Friday, March 25, 2022 6:34 PM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]>; Dikshit, Saumya <[email-masked]>; [email-masked]; [email-masked]
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 ?

Regards,
Luc André

Luc André Burdet |  Cisco  |  [email-masked]<mailto:[email-masked]>  |  Tel: +1 613 254 4814

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 24, 2022 at 17:53
To: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] draft-saumvinayak-bess-all-df-bum
Hi Saumya,

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.

Thanks!
Jorge

From: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 24, 2022 at 11:15 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-saumvinayak-bess-all-df-bum
Hi Jorge,

Regards,
Saumya.

From: Dikshit, Saumya
Sent: Wednesday, March 23, 2022 11:59 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: draft-saumvinayak-bess-all-df-bum

Hi Jorge,

Thanks for the comments.

Thanks
Saumya.

Dear Saumya and authors,

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Wed, 30 Mar 2022 19:17:34 +0000

Hi Saumya,

From: Dikshit, Saumya <[email-masked]>
Date: Tuesday, March 29, 2022 at 2:13 PM
To: Luc André Burdet <[email-masked]>, Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: draft-saumvinayak-bess-all-df-bum
Hello Jorge, Luc,

@Jorge
<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?

[jorge] yes

§  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.

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

[jorge] yes.
Thank you,
Jorge

@Luc
>>>> You are trying to do Jorge’s items 3-5 below without 1-2
<Saumya>

>>>> 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>

Regards,
Saumya.

Hi Saumya,

Regards,
Luc André

Thanks!
Jorge

Regards,
Saumya.

From: Dikshit, Saumya

Hi Jorge,

Thanks for the comments.

Thanks
Saumya.

Dear Saumya and authors,

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Thu, 31 Mar 2022 06:39:09 +0000

Hi Jorge,

Please see inline. In summary, let me update the draft with more-explicit details.

Thanks
Saumya.

From: Rabadan, Jorge (Nokia - US/Sunnyvale) [mailto:[email-masked]]
Sent: Thursday, March 31, 2022 12:48 AM
To: Dikshit, Saumya <[email-masked]>; Luc André Burdet <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: draft-saumvinayak-bess-all-df-bum

Hi Saumya,

From: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 29, 2022 at 2:13 PM
To: Luc André Burdet <[email-masked]<mailto:[email-masked]>>, Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: draft-saumvinayak-bess-all-df-bum
Hello Jorge, Luc,

@Jorge
<Saumya>

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?
<saumya> Potentially more AS hops, as going over WAN.

§  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.
<saumya> Let me call it out explicitly. Thanks a lot for reviewing it. ☺ So, in summary, are we on the same page for the new ALL-PE-DF mode.

<Saumya>

@Luc
<Saumya>

<Saumya>

Regards,
Saumya.

From: Luc André Burdet [mailto:[email-masked]]
Sent: Friday, March 25, 2022 6:34 PM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]<mailto:[email-masked]>>; Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: draft-saumvinayak-bess-all-df-bum

Hi Saumya,

Regards,
Luc André

Thanks!
Jorge

Regards,
Saumya.

From: Dikshit, Saumya

Hi Jorge,

Thanks for the comments.

Thanks
Saumya.

Dear Saumya and authors,

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.

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: