Re: [bess] draft-saumvinayak-bess-all-df-bum : All PEs as DF: Distributed firewall-gateways across Overlay fabrics

["Dikshit, Saumya" <[e-mail]>]

Hello Members,
I think this document should be part of the Bess WG as it attends to specific and unattended use-case.

Thanks
Saumya.

From: BESS [mailto:[e-mail]] On Behalf Of Dikshit, Saumya
Sent: Friday, January 21, 2022 10:34 AM
To: [e-mail]
Subject: [bess] draft-saumvinayak-bess-all-df-bum : All PEs as DF: Distributed firewall-gateways across Overlay fabrics

[changing the subject line]

Hello Bess Members, Chairs,

We have covered a use-case which is not handled by any of the existing standard documents in bess.
The details of use-case are also discussed in the email chain below.

Kindly provide you inputs or feedback on the proposed changes in the draft https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/<https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/>

Thanks
Saumya.

From: Dikshit, Saumya
Sent: Tuesday, September 28, 2021 12:46 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; Joshi, Vinayak <[e-mail]<mailto:[e-mail]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

Hi Jorge and Bess member

Can you please go provide your inputs on the use-case and solution described in https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/<https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/>

Thanks
Saumya.

From: BESS [mailto:[e-mail]] On Behalf Of Dikshit, Saumya
Sent: Wednesday, September 15, 2021 4:44 PM
To: Joshi, Vinayak <[e-mail]<mailto:[e-mail]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

Hi Jorge and Members of Bess WG,

Please let us know your views on https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/<https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/>.
We have described the use-case this draft intends to solve, leveraging the existing TLVs.
Please include this as wg draft.

Thanks
Saumya.

From: Dikshit, Saumya
Sent: Friday, September 3, 2021 5:53 PM
To: Joshi, Vinayak <[e-mail]<mailto:[e-mail]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

Hi Jorge and others in Bess WG,

We have come out with a new draft to which proposes a DF-election-mode where in all the PEs intend to play the DF-role.
Please go through the document and provide your comments: https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/<https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/>

Thanks
Saumya.


From: Joshi, Vinayak
Sent: Monday, August 23, 2021 5:22 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

+1 for standard compliance on the control plane to indicate [All Active + All DF].
However, I think local bias is still needed to prevent some scenarios

E.g.:
1)  Host1 sends out ARP request for the Firewall.
2)  It reaches VTEP-1 over VxLAN from Vtep_Host1. Two options at Vtep_1

a)      Proprietary Option:  VTEP 2 does not forward it over the VxLAN DCI tunnel to Vtep2. I.e. VTEP 1 has to match the ARP for Firewall.

b)       Vtep_1 sends it over VTEP 2 on VxLAN DCI. VTEP 2's local bias procedure prevents it from getting into Firewall_2.  This makes it easier to implement on Vtep_2. This is because Vtep_1 need not selectively block BUM over the VxLAN tunnel (ARP from Host1 to resolve Host2's IP has to be forwarded by Vtep_1 to Vtep_2).

Regards,
Vinayak



From: BESS [mailto:[e-mail]] On Behalf Of Dikshit, Saumya
Sent: Thursday, August 19, 2021 11:39 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc


>>>> If you still want to control the unicast and BUM flows to one FW or the other depending on the leaf, you can still do it but that's implementation specific since it relies on the route selection in vtep_host1 and vtep_host2.
+1 on the implementation part. It's good to have few proprietary solutions in place.
On another note, the best way forward could be the standards-support/enabler for EVPN control-plane;
like an option to allow more than one PEs (in active-active) to process the BUM (arp request) traffic.

Thanks
Saumya.

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:[e-mail]]
Sent: Thursday, August 19, 2021 9:40 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

I think you are saying that the FW can fail but it's interface to the leaf is oper-up. I don't think the network can do anything to prevent traffic to that interface then.

And of course, in your new diagram local bias does not play. As I said, local bias works in the previous diagram.
Those new leaf nodes will do aliasing to the remote all-active ES.

If you still want to control the unicast and BUM flows to one FW or the other depending on the leaf, you can still do it but that's implementation specific since it relies on the route selection in vtep_host1 and vtep_host2.

Thx
Jorge


From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 19, 2021 at 8:49 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
>>> the static mac is configured associated to an interface and conditionally active based on the oper-status of the interface
Ack on that and that's pretty organic (tying it to the interface/AC state).
But it may not solve the case where other hosts (other than firewall) are behind the interface/AC (which is live and kicking).
Need to track firewall state and trigger an administrative delete of the static-MAC.


>>>
As I mentioned I should have added first_hop vtep/PE for Host1/2 as well,
to reflect that reachability to firewall from the host(s) is across the Overlay (EVPN fabric).

I have redone the topology to show host1 and host2 behind first hop vteps "Vtep_host1" and "Vtep_host2" respectively.
In this updated topology local-bias will not come into play, as traffic from host1/2 to firewall arrives over the evpn-fabric.
.

    SITE-1                 |                         SITE-2
------------------------------------------------------
      Host1                                          Host2
          \                                              /
Vtep_host1                              Vtep_host2
         |                                                   |
         |       [ EVPN-fabric ]                |
         |                                                   |
     Vtep1  == ==WAN======  Vtep2
       /                                                     \
Firewall _1                              Firewall_2
  (MAC_F)                                  (MAC_F)



From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:[e-mail]]
Sent: Thursday, August 19, 2021 9:04 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

About this:

>>>> the local static MAC disappears
As I have observed in few implementations that static MACs are admin-configured (other than control-plane published with sticky-bit).
So will need a admin intervention to clean them up.


In the implementations I know, the static mac is configured associated to an interface and conditionally active based on the oper-status of the interface. So no admin intervention. IMHO it does not make much sense to keep a static mac installed if the associated attachment circuit is down.

Thanks.
Jorge

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 19, 2021 at 8:28 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
Thanks Again Rabadan and apology for the confusion.

As I mentioned I should have added first_hop vtep/PE for Host1/2 as well,
to reflect that reachability to firewall from the host(s) is across the Overlay (EVPN fabric).

I have redone the topology to show host1 and host2 behind first hop vteps "Vtep_host1" and "Vtep_host2" respectively.
In this updated topology local-bias will not come into play, as traffic from host1/2 to firewall arrives over the evpn-fabric.
.

    SITE-1                 |                         SITE-2
------------------------------------------------------
      Host1                                          Host2
          \                                              /
Vtep_host1                              Vtep_host2
         |                                                   |
         |       [ EVPN-fabric ]                |
         |                                                   |
     Vtep1  == ==WAN======  Vtep2
       /                                                     \
Firewall _1                              Firewall_2
  (MAC_F)                                  (MAC_F)

>>>> the local static MAC disappears
As I have observed in few implementations that static MACs are admin-configured (other than control-plane published with sticky-bit).
So will need a admin intervention to clean them up.

Thanks
Saumya.

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:[e-mail]]
Sent: Thursday, August 19, 2021 8:35 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

For the first case, again, for the local hosts, local bias makes sure the ARP requests go only to the local FW, i.e. host-1 ARP Requests goes to FW-1 only, irrespective of the DF state.

For the second case, I don't understand. When the local FW goes down, the local static MAC disappears and the one from the EVPN route should be installed.

Thx
Jorge

From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 19, 2021 at 7:56 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
Thanks a lot for a prompt reply Jorge.

Well I missed drawing the Host(s) behind the remote Vtep (PE) assuming that it will not make any difference (except aliasing as you mentioned).

>>>> FW1 and FW2 can be attached to the same all-active ES
How to handle the broadcast packets like ARP request for the firewaill credentials ? ARP request (MAC_F) should to sent to the local vtep, which should act as a DF.
The hairpinning of ARP request to remote DF (over WAN), should be avoided. That's the reason it would be good to have two DFs for the {ESI, Bridge-domain} in this scenario.

>>>> In the implementations that I know, the local static MAC will be preferred over the EVPN MAC/IP route with the static bit, hence again you will have the behavior you want
The static-mac approach has an issue, when the local firewall goes down, there is no organic way to prefer/plumb the MAC_F published by remote vtep.

Thanks
Saumya.

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:[e-mail]]
Sent: Thursday, August 19, 2021 7:47 PM
To: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

Hi Saumya,

To be clear, your query has nothing to do with the two documents you refer to. In fact I don't see any issue related to multihoming.
Given that in your example host-1 and FW-1 are directly connected to the same leaf, and host-2 and FW-2 are connected to the same leaf too, I can see your use-case resolved in two ways:

a) FW1 and FW2 can be attached to the same all-active ES, I assume local-bias behavior as in RFC8365 (seems you are using VXLAN as data plane). Host-1 will send unicast and BUM to FW-1. Host-2 will send unicast and BUM to FW-2. In case of failure, the behavior will be as per your description. Note that a third leaf with a local host will do aliasing to both, but since it seems you only have directly connected leaf nodes, you are fine.

b) instead of attaching FW-1 and FW-2 to the same ES, EVPN allows 'static' MACs that are advertised with the sticky bit set. You can configure MAC F as static in the two leaf nodes. There is no mobility procedures for static MACs, hence forwarding comes down to the local selection on each node. In the implementations that I know, the local static MAC will be preferred over the EVPN MAC/IP route with the static bit, hence again you will have the behavior you want.. and again, only in your example with two directly connected leaf nodes.

My 2 cents.
Thx
Jorge


From: Dikshit, Saumya <[e-mail]<mailto:[e-mail]>>
Date: Thursday, August 19, 2021 at 4:51 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
Hello Authors of https://datatracker.ietf.org/doc/rfc8584/<https://datatracker.ietf.org/doc/rfc8584/> and https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery>

I have a query regarding the following use-case which I could not find supported with existing DF-election procedures.

Scenario:
All PE (Vtep1 and Vtep2 in below example) routers attached to same ES and both act as DF.

This is a typical case of distributed firewall (active/active) across fabrics (sites),
Where in, the preferred firewall is the one local to the site, whereas, upon failure,
packets need to be redirected (over WAN, via DCI/VPN) towards the remote site firewall.
The firewall-device is connected to it's first-hop vtep over the same bridge-domain and same ESI.
All in all, it's an emulated multi-homing scenario.

This is scenario of distributed firewall devices host same MAC credentials.

Simplistic example :
There are two sites, SITE-1 and SITE-2 in the below diagram.
Traffic (including BUM) generated by Host1 (in SITE-1) (for a bridge-domain)
 should run through site-local firewall instance (firewall_1) preferably.
Only in case of local-outage, the traffic should be send across over WAN to the remote firewall (firewall_2).
Same should apply to traffic generated by Host2 (in SITE-2), wherein,
it should preferably run through the local firewall (firewall_2) and over a failure should go over the WAN towards firewall_1.

Vtep1/2 learn the firewall MAC (MAC_F) as local learning and also from the remote Vtep2/1.
But since both the learnings are over the same ESI, it should not lead to MAC move.
Cometh the local firewall failure, Vteps (1 or 2) should start redirecting the traffic to remote SITE.

Any ARP request (BUM traffic) for firewall credentials landing at either Vtep1 or Vtep2 should be flooded to network towards the local firewall.

    SITE-1                 |                         SITE-2
------------------------------------------------------
      Host1               |                        Host2
         |                     |                          |
     Vtep1  == ==WAN======  Vtep2
       |                       |                           |
Firewall _1           |                   Firewall_2
  (MAC_F)                                  (MAC_F)

Please let me know if there is a way out (with out) using existing standards.

Thanks
Saumya.

-----Original Message-----
From: BESS [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, July 6, 2021 8:31 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [bess] I-D Action: draft-ietf-bess-evpn-fast-df-recovery-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

        Title           : Fast Recovery for EVPN DF Election
        Authors         : Patrice Brissette
                          Ali Sajassi
                          Luc Andre Burdet
                          John Drake
                          Jorge Rabadan
        Filename        : draft-ietf-bess-evpn-fast-df-recovery-02.txt
        Pages           : 11
        Date            : 2021-07-06

Abstract:
   Ethernet Virtual Private Network (EVPN) solution provides Designated
   Forwarder election procedures for multi-homing Ethernet Segments.
   These procedures have been enhanced further by applying Highest
   Random Weight (HRW) Algorithm for Designated Forwarded election in
   order to avoid unnecessary DF status changes upon a failure.  This
   draft improves these procedures by providing a fast Designated
   Forwarder (DF) election upon recovery of the failed link or node
   associated with the multi-homing Ethernet Segment.  The solution is
   independent of number of EVIs associated with that Ethernet Segment
   and it is performed via a simple signaling between the recovered PE
   and each PEs in the multi-homing group.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery-02<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery-02>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-fast-df-recovery-02<https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-fast-df-recovery-02>


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>


_______________________________________________
BESS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>