Internet DRAFT - draft-jiang-bess-evpn-egress-frr

draft-jiang-bess-evpn-egress-frr







BESS Working Group                                            J. He, Ed.
Internet-Draft                                                     X. Li
Intended status: Standards Track                                 Z. Zhou
Expires: December 31, 2020                                         H. Qu
                                                                Ericsson
                                                           June 29, 2020


                        EVPN Egress Fast ReRoute
                  draft-jiang-bess-evpn-egress-frr-00

Abstract

   Ethernet Virtual Private Network (EVPN) multi-homing accommodates
   load balance, link/node redundancy and fast convergence.  Once link
   failure happens, egress traffic can be fast rerouted to multi-homed
   peer(s) to reach CE.  However, this fast reroute brings transient
   loops among multi-homed peers.  This document specifies a fast
   reroute approach with loop prevention.

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 December 31, 2020.

Copyright Notice

   Copyright (c) 2020 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



He, et al.              Expires December 31, 2020               [Page 1]

Internet-Draft               EVPN Egress FRR                   June 2020


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Approach  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Loop Prevention . . . . . . . . . . . . . . . . . . . . .   4
   4.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Constructing EVPN Routes  . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Ethernet Virtual Private Network (EVPN) multi-homing accommodates
   load balance, link/node redundancy and fast convergence.  Upon link
   failure, the PE withdraws the corresponding set of Ethernet A-D per
   ES routes, which triggers all PEs to switchover traffic towards other
   multi-homed peers for the PE.  However, failure propagation still
   consumes much time.  The switchover performance can be improved by
   using local protection at the same time, called egress Fast ReRoute
   (eFRR).

   For example in figure 1, CE1 is multi-homed to PE1 and PE2 with All-
   Active mode, CE2 and CE3 are single-homed to PE2 and PE3 separately.
   EVPN VPLS is provided for CE1, CE2,and CE3.

   In case link failure happens between CE1 and PE2, PE2 withdraws EAD/
   ES route for this link which triggers PE3 to switchover traffic
   towards CE1 from PE2 to PE1.  At the same time, traffic towards CE1
   via PE2 (CE2->CE1 or CE3->CE1) is rerouted to PE1 to reach CE1.  The
   local protection improves the traffic switchover performance.

                               +-----------+
               /-------- PE1   |           |
           CE1(AA mode)        |   EVPN    |   PE3 --- CE3
               \-------- PE2   |           |
                          |    +-----------+
                         CE2

              Figure 1 EVPN All-Active multi-homing scenario



He, et al.              Expires December 31, 2020               [Page 2]

Internet-Draft               EVPN Egress FRR                   June 2020


   [RFC8679] specifies a fast reroute approach for egress traffic
   protection.  It defines roles for routers and also procedures among
   them.  However, it only protect traffic from core and it does not
   define how a unique service label is advertised.  This document
   describes a light weighted approach dedicated for EVPN service, while
   adding protecting traffic from access link and defining the specific
   service label advertisement behavior.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

      CE: Customer Edge device, e.g., a host, router, or switch.

      Ethernet Segment (ES): When a customer site (device or network) is
      connected to one or more PEs via a set of Ethernet links, then
      that set of links is referred to as an 'Ethernet segment'.

      EVI: An EVPN instance spanning the Provider Edge (PE) devices
      participating in that EVPN.

      EVPN: Ethernet Virtual Private Network.

      PE: Provider Edge device.

      NVO: Network Virtualization Overlay.

      VNI: VXLAN Network Identifier.

3.  Approach

   Using figure 1 as an example, when link failure happens between CE1
   and PE2, on PE2 the rerouted traffic from CE (CE2->CE1 via PE2) is
   encapsulated with the EVPN label advertised by PE1.  For rerouted
   traffic from EVPN core (CE3->CE1 via PE2), the EVPN label inside is
   swapped to the one advertised by PE1 also.

   The EVPN label is from the Ethernet Auto-Discovery Route per EVI or
   MAC/IP Advertisement Route advertised by PE1.  Which label to
   encapsulate traffic towards PE1 is a local decision on PE2.

   However, if CE1 fails, PE1 and PE2 try to reroute traffic to each
   other, which leads to transient loop till EAD/ES withdrawal(s)




He, et al.              Expires December 31, 2020               [Page 3]

Internet-Draft               EVPN Egress FRR                   June 2020


   received by PE1 and/or PE2.  This document introduces a loop
   prevention mechanism to solve the problem.

3.1.  Loop Prevention

   When advertise Ethernet Auto-Discovery Route per EVI or MAC/IP
   Advertisement Route, PE1 allocates one dedicated EVPN label for all
   PEs (e.g.  PE2 here) which share the same multi-homed CE, while
   allocates another one for all other PEs not multi-homed (e.g.  PE3
   here).  Please note if EVPN VPWS, only Ethernet Auto-Discovery Route
   per EVI is required.

   When PE2 detects link towards CE1 fails (regardless of CE node
   failure or only link failure), it encapsulates traffic towards CE1
   using the dedicated EVPN label advertised by PE1 and reroutes to PE1.
   On PE1, the multi-homed peer, based on the EVPN label encapsulated,
   the rerouted traffic is identified as from peer.  If PE1 detects link
   towards CE1 fails, the traffic from peer will not be rerouted but
   simply discarded.  Thus loop is avoided.  If no link failure, the
   traffic from PE1 is forwarded to CE1.

   The mechanism also works for NVO scenarios [RFC8365], where the label
   mentioned above will be referred to as the VNI.

4.  Procedures

4.1.  Constructing EVPN Routes

   In order to assign dedicated EVPN label for all PEs which share the
   same multi-homed CE, when advertising Ethernet Auto-Discovery Route
   per EVI or MAC/IP Advertisement Route, the PE MUST carry exactly one
   ES-Import Route Target extended community.  It MUST also carry
   exactly one EVI-RT Extended Community (EC) as defined in
   [I-D.ietf-bess-evpn-igmp-mld-proxy].

   EVI-RT EC is an Extended Community that can be used to identify the
   EVI with which an EVPN route is associated.  But it is not a Route
   Target Extended Community, is not visible to the RT Constrain
   mechanism [RFC4684], and is not intended to influence the propagation
   of EVPN routes by BGP.

   The combination of the ES-Import RT and EVI-RT EC guarantees the EVPN
   routes to be distributed only to PEs that share the same multi-homed
   CE for a specific EVPN instance.  If the EVPN route has no EVI-RT EC,
   or has more than one EVI-RT EC, the PE MUST apply the "treat-as-
   withdraw" procedure of [RFC7606].





He, et al.              Expires December 31, 2020               [Page 4]

Internet-Draft               EVPN Egress FRR                   June 2020


   It is suggested to set a higher LOCAL_PREF value in the BGP message
   for the EVPN routes, considering if another general EVPN route is
   also advertised to all PEs, for example, through BGP Route Reflector.

5.  IANA Considerations

   No requests to the IANA by this document.

6.  Security Considerations

   Same security considerations as [RFC7432].

7.  References

7.1.  Normative References

   [I-D.ietf-bess-evpn-igmp-mld-proxy]
              Sajassi, A., Thoria, S., Patel, K., Drake, J., and W. Lin,
              "IGMP and MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-
              mld-proxy-05 (work in progress), April 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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, February
              2015, <https://www.rfc-editor.org/info/rfc7432>.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <https://www.rfc-editor.org/info/rfc7606>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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, March 2018,
              <https://www.rfc-editor.org/info/rfc8365>.






He, et al.              Expires December 31, 2020               [Page 5]

Internet-Draft               EVPN Egress FRR                   June 2020


7.2.  Informative References

   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
              R., Patel, K., and J. Guichard, "Constrained Route
              Distribution for Border Gateway Protocol/MultiProtocol
              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
              Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
              November 2006, <https://www.rfc-editor.org/info/rfc4684>.

   [RFC8679]  Shen, Y., Jeganathan, M., Decraene, B., Gredler, H.,
              Michel, C., and H. Chen, "MPLS Egress Protection
              Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019,
              <https://www.rfc-editor.org/info/rfc8679>.

Authors' Addresses

   Jiang He (editor)
   Ericsson
   No. 5, Lize east street, Chaoyang district
   Beijing  100102
   CN

   Email: jiang.he@ericsson.com


   Xianmin Li
   Ericsson
   No. 5, Lize east street, Chaoyang district
   Beijing  100102
   CN

   Email: xianmin.li@ericsson.com


   Zhe Zhou
   Ericsson
   No. 5, Lize east street, Chaoyang district
   Beijing  100102
   CN

   Email: zhe.zhou@ericsson.com










He, et al.              Expires December 31, 2020               [Page 6]

Internet-Draft               EVPN Egress FRR                   June 2020


   Haifeng Qu
   Ericsson
   No. 5, Lize east street, Chaoyang district
   Beijing  100102
   CN

   Email: haifeng.qu@ericsson.com












































He, et al.              Expires December 31, 2020               [Page 7]