EVPN Mac Dampening Back-off

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 March 2022.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Important Terms

DF: Designated Forwarder as defined in [RFC7432].¶

VTEP: Virtual Tunnel End Point or Vxlan Tunnel End Point¶

2. Introduction

The Designated forwarder concept is leveraged to prevent looping of BUM traffic into tenant network sourced across NVO fabric for multihoming deployments. [RFC7432] defines a prelimn approach to select the DF for an ES,VLAN or ES,Vlan Group panning across multiple NVE's. [RFC8584] makes the election logic more robust and fine grained inculcating fair election of DF handling most of the prevalent use-cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolve by rules mentioned in [RFC7432] and [RFC8584].¶

3. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶

When used in lowercase, these words convey their typical use in common language, and they are not to be interpreted as described in [RFC2119].¶

4. Problem Description

It's a typical case of Firewall devices also configured as default gateway for the NVO fabric or default gateways inturn redirect traffic to firewalls over shared vlan. This example for simplicity assumes the former case wherein firewall is also configured as default gateway for all VLANs in the site (SITE-1 and SITE-2).¶

All PEs(Vtep1 and Vtep2 in below example) in the diagram are attached to same ES and both intend to act act as DF for the broadcast domain (BD-1) for their respective sites. As already mentioned, this is a typical case of firewall-gatewaus (active/active) across fabrics (sites), Where in, the preferred firewall-gateway 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 a scenario of firewall devices hosting same(IP and 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
       \                                 /
        \                               /
Vtep_host1                             Vtep_host2
         |                             |
         |       [ EVPN-fabric ]       |
         |                             |
     Vtep1============WAN==============Vtep2
        /                                 \
       /                                   \
Firewall _1                           Firewall_2
  (MAC_F)                              (MAC_F)

5. Solution(s)

The control plane part of the solution can be leveraged from the 'DF Election Extended Community' described in [RFC8584]. Since the requirement is to ensure all the PEs attached to ESI forward the BUM traffic arriving from NVO fabric towards the Attachment circuits (ACs) configured over the ES for a BD (broadcast domain) mapped to Vlan or bundle of Vlans. As explained in the above section that this is a case where PEs are in disparate networks and the ACs behind them are not connected to each other to a common physical device.¶

This document proposes a new mode of DF-election, ALL-PEs-DF where-in all of the pariticipating PEs intend to play DF role for a vlan(s) enabled on an ESI. This requires "DF Election Extended Community" to carry this information with the ES route to indicate it to remote PEs. This ensures all PEs receiving BUM traffic over NVO fabric destined to ESI, BD, SHOULD flood it on the associated ES on the access/tenant side. PE MAY be explicitly configured to choose the ALL-PEs-DF mode.¶

6. Interoperability with other Algos

Since All-DF-algo is special mode and not exactly an algorithm, which requires the participation of all PEs for an ESI, VLAN. Hence, even if one PE publishes an algo which is NOT "All-DF-mode", other PEs SHOULD revert back to default algorithm. The reason being that, if there are PE1, PE2, PE3 and PE4 in contention. PE1 and PE2 publishes DF Algo 'ALL-PEs-DF', PE3 publishes '0' and PE4 publishes '1'. Once this mismatch is perceived, all PEs SHOULD try and converge towards the default mode. An admin intervention may be required to achieve the same or to converge on any other supported 'DF Algo'.¶

7. Backward Compatibility

As prescribed in [RFC8584], PEs not supporting (hence not publishing) 'ALL-PEs-DF', SHOULD ignore the processing of the 'DF Election Extended Community' and SHOULD indulge in DF-election using the default aglorithm mentioned in [RFC7432]. The PEs configured with this new alogrithm (hence publishing it), if receive Route Type 4 without 'DF Election Extended Community', SHOULD also revert back to default algorithm. If PEs receive Route Type 4 with another algorithm published in 'DF Election Extended Community', then it should follow procedures prescribed in Section 6.¶

8. Impact on Local Bias

There is no impact on the local-bias handling, as the PE receiving the BUM from access side over {ESI, VLAN} and relays it to other PEs that published {ESI, VLAN} in Route Type 4; the receiving side PEs will not relay it to EVPN fabric nor will they redirect it to same ESI configured with same VLAN on the access/tenant side.¶

9. Security Considerations

This document inherits all the security considerations discussed in [RFC7432] and [RFC8584].¶

10. IANA Considerations

This document inherits all the IANA considerations discussed in [RFC7432] and [RFC8584].¶

11. Acknowledgements

Authors' Addresses