Internet-Draft AC-DF per EVI May 2021
Wang Expires 8 November 2021 [Page]
Workgroup:
BESS WG
Published:
Intended Status:
Standards Track
Expires:
Author:
Y. Wang
ZTE Corporation

AC-Influenced DF Election per EVI

Abstract

The AC-influenced DF Election (AC-DF) per [RFC8584] is too dependent on EAD/EVI routes. For example, when no failures occured on an ESI, that AC-DF procedures will give incorrect results if no EAD/EVI routes are advertised. But in some light-weighted EVPNs (i.e. PBB EVPNs), no EAD/EVI routes will be advertised at all.

This draft proposes some new extensions to support AC-influenced DF Election without any EAD/EVI routes advertised in advance of any <ESI, EVI> failures.

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 8 November 2021.

Table of Contents

1. Introduction

When the EAD/EVI route is not advertised before the corresponding ESI sub-interface fails, The AC-influenced DF Election procedures should elect the right DF before and after that failure.

Note that according to [RFC8584], the AC-influenced DF Election will be incorrect when no EAD/EVI route is advertised, even if no ESI sub-interface has failed at all.

This draft proposes some extension to DF-Capability negotiation and DF-Election procedures to support AC-influenced DF-election when no EAD/EVI routes are advertised.

1.1. Terminology

Most of the terminology used in this documents comes from [RFC8584] and [RFC7623] except for the following:

  • Light-weighted EVPN: The EVPN solution without EAD/EVI Route advertisedment.
  • EAD/ES: Ethernet A-D route per EVI, or RT-1 per ES route.
  • EAD/EVI: Ethernet A-D route per EVI, or RT-1 per EVI route.

2. AC-DF per EVI

2.1. Use Case

The ethernet segment ES1's ESI is ESI1, AC1/AC2 is two sub-interfaces on ES1, and AC3/AC4 is two sub-interfaces on ES2. AC1 and AC3 are attached to EVPN Instance EVI1, while AC2 and AC4 are attached to EVI2. The redundancy mode of ES1 is all-active.

                                 +----------+
                   PE1           |          |
              +-------------+    |          |
              | AC1         |    |          |         PE3
             /| AC2         |----|          |   +-------------+
            / |             |    |          |   |             |
       LAG /  +-------------+    |          |   |         AC3 |---CE2
   CE1=====                      |   PSN    |   |         AC4 |
           \  +-------------+    |          |---|             |
            \ |             |    |          |   +-------------+
             \| AC2         |----|          |
              | AC1         |    |          |
              +-------------+    |          |
                   PE2           |          |
                                 +----------+
Figure 1: AC-DF per EVI Usecase

EVI1 and EVI2 are two EVPN Instances, and there are no EAD/EVI routes advertised for them. Such EVPN Instances are called Light-weighted EVPNs in this draft. For example, EVI1 and EVI2 can be the I-Components of PBB EVPNs, because no EAD/EVI routes are advertised for these I-Components.

Initially PE1 is the DF for <ESI1, EVI1>, and PE2 is the DF for <ESI1, EVI2>. When the AC1 of PE1 fails (but ESI1 and AC2 of PE1 still works well), the DF for <ESI1, EVI1> should switch to PE2.

The DF-election should be done without any EAD/EVI routes advertised before any ESI sub-interface fails. Otherwise those EAD/EVI routes are advertised just for the adaptation of AC-influenced DF-election procedures per [RFC8584], but will do nothing good for the unicast packet forwarding in data plane (because data plane MAC learning don't use EAD/EVI routes).

2.2. AC-DF per EVI Capability

We introduce a new bit named "AC-DF per EVI" in the "bitmap" field of the DF Election extended community. The "AC-DF per EVI" bit means that the DF-Election for an <ESI, EVI> will not take EAD/EVI routes into considerations untill a Reverse EAD/EVI route for that <ESI, EVI> is received from any of the PEs.

2.2.1. Capability Negotiation Procedures

Only when all RT-4 routes of the same ESI indicate the "AC-DF per EVI" Capability, The DF Election will be executed in "AD-DF per EVI" mode. We can say that the DF Election mode for that ESI is negotiated as "AC-DF per EVI" mode.

Note that when any of the PEs on that ES is an old PE that don't support "AC-DF per EVI" mode, the RT-4 route from that PE will not indicate the "AC-DF per EVI" Capability, So the DF election will not be executed in "AD-DF per EVI" mode. This is for compatibility purpose.

2.2.2. AC-DF Capability vs AC-DF per EVI Capability

When all RT-4 routes of the same ESI indicate both the "AC-DF per EVI" Capability and the old AC-DF Capability, The DF Election will be executed in "AD-DF per EVI" mode.

Note that when any of the PEs on that ES is an old PE that don't support "AC-DF per EVI" mode, the RT-4 route from that PE may indicate the "old AC-DF" Capability only, So the DF election will still be executed in old AD-DF mode per [RFC8584]. This is for compatibility purpose.

2.3. DF Election Procedures

2.3.1. Initiation of AC-DF per EVI Mode

According to [RFC8584], the AC-influenced DF Election will be incorrect when no EAD/EVI route is advertised, even if no ESI sub-interface has failed at all.

But when the DF Election mode for an ESI is negotiated as AC-DF per EVI mode, no normal EAD/EVI routes can impact the DF Election procedures. The DF election will be done following that ESI's RT-4 routes only until at least one reverse EAD/EVI route is received.

2.3.2. Reverse EAD/EVI Route

In order to do AC-influenced DF election after a sub-interface of that ES fails, we introduce the "Reverse EAD/EVI Route". The reverse EAD/EVI Route is a special type of EAD/EVI Route that is advertised on the failure of corresponding <ESI, EVI>, not on the activation of that <ESI, EVI>.

Reverse EAD/EVI routes can use the same format as EAD/EVI Routes except for the following differences:

  • A Reverse EAD/EVI Route carries an EVPN Layer 2 Attributes Extended Community whose "Control Flags" field includes a new flag named "AC Failure". The "AC Failure" flag means that the corresponding AC (for which the Reverse EAD/EVI route is advertised) is in failure.

  • A Reverse EAD/EVI Route carries an ES-Import RT ([RFC7432]) and an EVI-RT ([I-D.ietf-bess-evpn-igmp-mld-proxy]), no traditional Route-Targets have to be carried.

  • A Reverse EAD/EVI Route should make its MPLS label field be set to zero.

2.3.3. DF Election Rules

When a Reverse EAD/EVI Route for an <ESI, EVI> is received from a remote PE X, the RT-4 Route of that PE x are expelled from that <ESI, EVI>'s DF election. Then the DF election for that <ESI, EVI> will be updated according to the corresponding DF Alg.

Note that the DF election for other <ESI, EVI>s will not be affected by that Reverse EAD/EVI Route.

2.3.4. Route Filtering and RT Constraints Mechanism

When PE Y receives a reverse EAD/EVI route from PE X, and the ES-Import RT of that route can't match any local ES of PE Y, PE Y will not import that route into the EVI that is identified by that route's EVI-RT.

When RT Constraints Mechanism is enabled, each reverse EAD/EVI route will be distributed to the adjacent PEs of its ES only. Because that only the ES-Import RT are visible to the RT Constraints Mechanism, The EVI-RT is not visible to the RT Constraints Mechanism.

3. Other considerations

3.1. Why no EAD/EVI Routes Advertised

When no RT-2 Routes advertised, no EAD/EVI routes need to be advertised either. PBB EVPN is an example of that. In PBB EVPN, the C-MACs are learnt in the data plane.

Other light-weighted EVPNs also do data plane C-MAC learning, so they don't have to advertise EAD/EVI routes either. In such EVPNs, AC-DF per EVI will help.

4. Security Considerations

Security considerations will be added in future versions.

5. IANA Considerations

5.1. New DF Election Capability

IANA will be requested to allocate a new DF Election Capability in the "DF Election Capabilities" Registry. This capability is called "AC-DF per EVI Capability".


      Bit         Name                             Reference
      ----        ----------------                 -------------
      0           Unassigned
      1           AC-DF Capability                 [RFC8584]
      4           AC-DF per EVI Capability         This draft

Figure 2: AC-DF per EVI Capability

5.2. New EVPN Layer 2 Attributes Control Flags

IANA will be requested to allocate a new Control Flag in the "EVPN Layer 2 Attributes Control Flags" Registry. This Control Flag is called "F" Flag, where "F" means AC-Failure.


   Bit     Name                                        Reference
   ----    ----------------                            -------------
   P       Advertising PE is the primary PE.           [RFC8214]
   B       Advertising PE is the backup PE.            [RFC8214]
   C       Control word [RFC4448] MUST be present.     [RFC8214]
   F       AC-Failure on Advertising PE                This Draft

Figure 3: AC Failure Flag

6. Acknowledgements

The authors would like to thank the following for their comments and review of this document:

Chunning Dai.

7. Normative References

[I-D.ietf-bess-evpn-igmp-mld-proxy]
Sajassi, A., Thoria, S., Drake, J., and W. Lin, "IGMP and MLD Proxy for EVPN", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-igmp-mld-proxy-06, , <https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-06>.
[I-D.ietf-bess-srv6-services]
Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based Overlay services", Work in Progress, Internet-Draft, draft-ietf-bess-srv6-services-06, , <https://tools.ietf.org/html/draft-ietf-bess-srv6-services-06>.
[RFC7432]
Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, , <https://www.rfc-editor.org/info/rfc7432>.
[RFC7623]
Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, , <https://www.rfc-editor.org/info/rfc7623>.
[RFC8584]
Rabadan, J., Ed., Mohanty, S., Ed., Sajassi, A., Drake, J., Nagaraj, K., and S. Sathappan, "Framework for Ethernet VPN Designated Forwarder Election Extensibility", RFC 8584, DOI 10.17487/RFC8584, , <https://www.rfc-editor.org/info/rfc8584>.

8. Informative References

[RFC7041]
Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging", RFC 7041, DOI 10.17487/RFC7041, , <https://www.rfc-editor.org/info/rfc7041>.
[RFC7348]
Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, , <https://www.rfc-editor.org/info/rfc7348>.
[RFC8365]
Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., Uttaro, J., and W. Henderickx, "A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, DOI 10.17487/RFC8365, , <https://www.rfc-editor.org/info/rfc8365>.

Author's Address

Yubao Wang
ZTE Corporation
No.68 of Zijinghua Road, Yuhuatai Distinct
Nanjing
China