EVPN Egress Protection
draft-wang-bess-evpn-egress-protection-00

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Author Yubao Wang 
Last updated 2020-04-19
Stream (None)
Formats pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
BESS WG                                                      Yubao. Wang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                          April 20, 2020
Expires: October 22, 2020

                         EVPN Egress Protection
               draft-wang-bess-evpn-egress-protection-00

Abstract

   A fast reroute framework for egress node protection is specified by
   [RFC8679] . But it cannot be applied to VXLAN EVPN directly.  This
   document specifies a mechanism to apply Egress Node Protection to
   VXLAN EVPN nodes and apply Egress Link Protection to EVPN EAD/EVI
   routes.

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 October 22, 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
   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.

Wang                    Expires October 22, 2020                [Page 1]
Internet-Draft           EVPN Egress Protection               April 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology and Acronyms  . . . . . . . . . . . . . . . .   2
   2.  Detailed Problem and Solution Requirement . . . . . . . . . .   4
   3.  Encoding the Originating Router Address . . . . . . . . . . .   6
   4.  Control Plane Processing  . . . . . . . . . . . . . . . . . .   6
   5.  Protection Procedures . . . . . . . . . . . . . . . . . . . .   7
     5.1.  EVPN Egress Node Protection (EENP)  . . . . . . . . . . .   7
       5.1.1.  BUM Forwarding Protection . . . . . . . . . . . . . .   7
       5.1.2.  Unicast Forwarding Protection . . . . . . . . . . . .   7
     5.2.  Egress ESI Link Protection (EELP) . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   A principal feature of EVPN is the ability to support multi-homing
   from a customer equipment (CE) to multiple PE/VTEP with Ethernet
   segment (ES) links.  This draft specifies a VXLAN gateway mechanism
   to simplify VTEP processing in the dual-homed case and enhance EVPN
   convergency on egress failures.

1.1.  Terminology and Acronyms

   This document uses the following acronyms and terms:

   All-Active Redundancy Mode - When a device is multihomed to a group
   of two or more PEs and when all PEs in such redundancy group can
   forward traffic to/from the multihomed device or network for a given
   VLAN.

   Backup egress router - Given an egress-protected tunnel and its
   egress router, this is another router that has connectivity with all
   or a subset of the destinations of the egress-protected services
   carried by the egress-protected tunnel.

   BUM - Broadcast, Unknown unicast, and Multicast.

   CE - Customer Edge equipment.

   DCI - Data Center Interconnect.

Wang                    Expires October 22, 2020                [Page 2]
Internet-Draft           EVPN Egress Protection               April 2020

   EELP bypass tunnel - Egress ESI Link Protection bypass tunnel - A
   tunnel used to reroute service packets upon an egress ESI link
   failure.

   Egress failure - An egress node failure or an egress link failure.

   Egress link failure - A failure of the egress link (e.g., PE-CE link,
   attachment circuit) of a service.

   Egress loopback - the loopback interface on the Egress router, whose
   IP address is the destination of the Egress-protected tunnel.

   Egress node failure - A failure of an egress router.

   Egress router - A router at the egress endpoint of a tunnel.  It
   hosts service instances for all the services carried by the tunnel
   and has connectivity with the destinations of the services.

   Egress-protected tunnel - A tunnel whose egress router is protected
   by a mechanism according to this framework.  The egress router is
   hence called a protected egress router.

   Egress-protected EVI - An EVPN MAC-VRF or IP-VRF that is carried by
   an egress-protected tunnel and hence protected by a mechanism
   according to this framework.

   Egress-protecting tunnel - A VXLAN tunnel whose destination IP
   address is the same value as the Egress-protected tunnel.  The
   Egress-protecting tunnel is constructed on the Protector not on the
   Egress router.  The egress router of the egress-protecting tunnel is
   the protector.  Note that from the view of the ingress router the
   egress-protecting tunnel and the egress-protected tunnel is the same
   tunnel.

   ESI - Ethernet Segment Identifier - A unique non-reserved identifier
   that identifies an Ethernet segment.

   OPE - Originating PE - the original Router of an EVPN route.

   PE - Provider Edge equipment.

   PLR - A router at the point of local repair.  In egress node
   protection, it is the penultimate hop router on an egress-protected
   tunnel.  In egress link protection, it is the egress router of the
   egress- protected tunnel.

Wang                    Expires October 22, 2020                [Page 3]
Internet-Draft           EVPN Egress Protection               April 2020

   Protector - A role acted by a router as an alternate of a protected
   egress router, to handle service packets in the event of an egress
   failure.  A protector is physically independent of the egress router.

   Protector loopback - the loopback interface on the Protector, whose
   IP address is the destination of the Egress-protected tunnel.

   Single-Active Redundancy Mode - When a device or a network is
   multihomed to a group of two or more PEs and when only a single PE in
   such a redundancy group can forward traffic to/from the multihomed
   device or network for a given VLAN.

   VTEP - VXLAN Tunnel End Point.

   VXLAN - Virtual eXtensible Local Area Network [RFC7348].

2.  Detailed Problem and Solution Requirement

   In the scenario illustrated in Figure 1, where an CE1 is dual-homed
   to VTEP1 and VTEP2 to access the VXLAN network, which enhances
   network access reliability.  When one VTEP fails, services can be
   rapidly switched to the other VTEP, minimizing the impact on
   services.

   As shown in Figure 1, the VTEP address of VTEP1 is IP1 and the VTEP
   address of VTEP2 is IP2, the VTEP address of VTEP3 is IP3, they are
   three different IP addresses.  The BGP update-source of VTEP1 is
   IP10, of VTEP2 is IP20, and of VTEP3 is IP30.  Note that IP1 may be
   the same as IP10, IP2 may be the same as IP20, IP3 may be the same as
   IP30.

Wang                    Expires October 22, 2020                [Page 4]
Internet-Draft           EVPN Egress Protection               April 2020

                                +-------+
        ----------------------- | VTEP3 |
           ^                    | (IP3) |
           |                    +-------+
           |                     /     \
           |                    /       \
         VXLAN Tunnels         /         \
           |                  /           \
           |                 /    Egress   \
           |      +----------+  protection  +-----------+
           v      | IP1_E    |              |  IP2_E    |
        --------- |          |--------------|           | VTEP2
                  | IP2_P    |  EELP bypass |  IP1_P    | (IP2)
                  +--+----+--+              +--+-----+--+
              VTEP1  |    |        ES2         |     |
              (IP1)  |    +--------+  +--------+     |
                     | ES1         |  |              | ES3
                     |             |  |              |
                    CE1            CE2              CE3

                Figure 1: Egress Protection for VXLAN EVPN

   From the view of VTEP3, the VXLAN tunnel to IP1 is the tunnel for
   VTEP1, the VXLAN tunnel to IP2 is the tunnel for VTEP2.  But now we
   add a loopback interface on VTEP2 and let its IP address be IP1 too,
   add another loopback interface on VTEP1 and let its IP address be IP2
   too.  Then we call there is an egress loopback for IP1 on VTEP1
   called IP1_E, and there is a protector loopback for IP1 on VTEP2
   called IP1_P, and there is an egress loopback for IP2 on VTEP2 called
   IP2_E, and there is a protector loopback for IP2 on VTEP1 called
   IP2_P.

   Then, for IP1, we make the metric of the IGP route for IP1_P lower
   than that for IP1_E.  Then we do the same for IP2.  Now we call the
   VXLAN tunnel from IP3 to IP1_E as the egress-protected tunnel for
   VTEP1, and we call the VXLAN tunnel from IP3 to IP1_P as the egress-
   protecting tunnel for VTEP1.  The egress-protected tunnel and egress-
   protecting tunnel for VTEP2 are similar to those tunnels for VTEP1.

   Note that from the view of VTEP3 the egress-protected tunnel and
   egress-protecting tunnel for the same VTEP is actually the same
   tunnel.  When the VTEP node is active, the packets to the VTEP are
   forwarded to it by the egress-protected tunnel.  When the VTEP node
   fails, the packets to it are forwarded to its protector by the
   egress-protecting tunnel.

Wang                    Expires October 22, 2020                [Page 5]
Internet-Draft           EVPN Egress Protection               April 2020

   But when VTEP2 receives the EVPN routes from VTEP3, only the egress-
   protected tunnel for VTEP2 itself is constructed.  the egress-
   protecting tunnel for VTEP1 is not constructed by default.  so when
   VTEP1 fails, although the packets to VTEP1 are fast-rerouted to VTEP2
   by underlay network, the VTEP2 may discard these packets because of
   the absent of the corresponding VXLAN tunnel entity for their SIP and
   DIP.

   When VTEP2 receives the EVPN routes from VTEP1, it may discard these
   routes because their nexthop is the IP address of a loopback on VTEP2
   itself.  Even though VTEP2 don't disccard these EVPN routes, it
   cannot use their nexthop to construct a VXLAN tunnel for the same
   reason as above.

3.  Encoding the Originating Router Address

   This sections describe the extensions specified to meeting the
   requirements given in Section 3 and enhance VXLAN EVPN convergency.

   This document reuse the OPE TLV defined in
   [I-D.heitz-bess-evpn-option-b] section 3.  the OPE TLV carries the
   BGP update-source on corresponding VTEP.  The VTEPs with egress
   protection procedures described in this document will add the OPE TLV
   in the EVPN routes they are about to advertise.

   Note that the ESI label or leaf Label is not used in VXLAN packet, so
   the usage for OPE TLV here won't conflict with the usage in
   [I-D.heitz-bess-evpn-option-b].

4.  Control Plane Processing

   Using the topology in Figure 1:

   We assume that the VNI for the same EVI on VTEP1 and VTEP2 must be
   the same.

   1) VTEP3 sends a MAC/IP route and an IMET route to VTEP1 and VTEP2.
   The nexthop of these routes is IP3 (we assume that IP30=IP3).  VTEP3
   won't add the OPE TLV to these routes because it works as normal EVPN
   VTEP.

   2) When VTEP1 receives the IMET route from VTEP3, it constructs the
   VXLAN tunnel (IP3,IP10).  When VTEP1 receives the MAC/IP route from
   VTEP3, it constructs the VXLAN tunnel (IP3,IP1) and (IP3, IP2)
   because it is configured with egress loopback and protector loopback.
   The procedures on VTEP2 is simlar to the above.

Wang                    Expires October 22, 2020                [Page 6]
Internet-Draft           EVPN Egress Protection               April 2020

   3) VTEP1 sends a MAC/IP route, an EAD/EVI route and an IMET route to
   VTEP2 and VTEP3.  The nexthop of the MAC/IP route and the EAD/EVI
   route is IP1 and the nexthop of the IMET route is IP10.  VTEP2 sends
   a MAC/IP route, an EAD/EVI route and an IMET route to VTEP1 and
   VTEP3.  The nexthop of the MAC/IP route and the EAD/EVI route is IP2
   and the nexthop of the IMET route is IP20.  VTEP1 and VTEP2 will both
   add the OPE TLV to these routes because they are configured with
   egress loopback and protector loopback.  The OPE TLV carries their
   BGP update-source IP address (IP10 or IP20).

   4) When VTEP2 receives the MAC/IP or EAD/EVI route from VTEP1, it
   constructs the VXLAN tunnel(IP10,IP20) because that the nexthop is
   the IP address of the protector loopback on VTEP2.  When VTEP2
   receives the IMET route from VTEP1, it constructs the VXLAN
   tunnel(IP10,IP20) too.  The VXLAN tunnel(IP10,IP20) is called Egress
   ESI Link Protection (EELP) bypass tunnel.  and VTEP2 will apply the
   egress link protection procedures to the received EAD/EVI route
   following the second approach of RFC8679 section 6.  The procedures
   on VTEP1 is simlar to the above.

   5) When VTEP3 receives the MAC/IP route from VTEP1/VTEP2, it will
   ignore the OPE TLV because the route's tunnel encapsulation is VXLAN
   and the nexthop is not a local address on VTEP3.

5.  Protection Procedures

   This section describes how Layer 2 unicast and BUM (Broadcast,
   Unknown unicast, and Multicast) packet forwarding are protected.  A
   description of how Layer 3 packet forwarding are protected will be
   provided in a furture version of this document.

5.1.  EVPN Egress Node Protection (EENP)

   The following two subsections discuss EENP procedures for BUM
   forwarding and Unicast Forwarding.

5.1.1.  BUM Forwarding Protection

   VTEP1 and VTEP2 will receive a copy of BUM packet from VTEP3
   separately, and the DF node for the (ESI,EVI) will forward it to the
   CE node.  When either of them fails, the other one will become the DF
   for all (ESI,EVI)s.

5.1.2.  Unicast Forwarding Protection

   When VTEP1 fails, the data packets from VTEP3 to VTEP1 is fast-
   rerouted to VTEP2 by the PLR node in the underlay network, the VTEP2

Wang                    Expires October 22, 2020                [Page 7]
Internet-Draft           EVPN Egress Protection               April 2020

   won't discard these packets because of the existence of VXLAN
   tunnel(IP3, IP1) on itself.  The VTEP2 will forward them to CE.

5.2.  Egress ESI Link Protection (EELP)

   The EELP (ESI,EVI) forwarding entry on VTEP1 will take the ESI link
   as primary forwarding path, and take the EAD/EVI route from VTEP2 as
   backup forwarding path.  This procedure follows the second approach
   of RFC8679 section 6.

   When the ESI link fails, the backup path will be activated on the
   result of a FRR switch.

   Note that even when the ESI is All-Active redundancy mode the EELP
   will follow the FRR behavior.  The EELP behavior is the same for All-
   Active redundancy mode and Single-Active redundancy mode.

   When ESI is All-Active redundancy mode VTEP3 will performing overlay
   ECMP via EAD/EVI routes to VTEP1/VTEP2, When the ESI link on VTEP1
   fails, VTEP1 will forwarding the packets via EELP bypass tunnel
   before VTEP3 delete the EAD/EVI routes.  But the bypass forwarding is
   temporary, when VTEP delete the EAD/EVI routes upon the withdraw of
   the EAD/EVI route from VTEP1, there won't be any bypass forwarding
   again.

   But when ESI is Single-Active redundancy mode, there is no importance
   for VTEP3 to use the EAD/EVI routes from VTEP1/VTEP2.  The EAD/EVI is
   still useful between VTEP1 and VTEP2 for EELP procedures in Single-
   Active redundancy mode.

6.  IANA Considerations

   IANA Considerations for OPE TLV following
   [I-D.heitz-bess-evpn-option-b].

7.  Security Considerations

   This section will be added in future versions.

8.  Acknowledgements

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

   Chunning Dai, Bing Song, Zheng Zhou.

Wang                    Expires October 22, 2020                [Page 8]
Internet-Draft           EVPN Egress Protection               April 2020

9.  Normative References

   [I-D.heitz-bess-evpn-option-b]
              Heitz, J., Sajassi, A., Drake, J., and J. Rabadan, "Multi-
              homing and E-Tree in EVPN with Inter-AS Option B", draft-
              heitz-bess-evpn-option-b-01 (work in progress), November
              2017.

   [I-D.ietf-bess-evpn-inter-subnet-forwarding]
              Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
              Rabadan, "Integrated Routing and Bridging in EVPN", draft-
              ietf-bess-evpn-inter-subnet-forwarding-08 (work in
              progress), March 2019.

   [I-D.ietf-bess-evpn-prefix-advertisement]
              Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A.
              Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf-
              bess-evpn-prefix-advertisement-11 (work in progress), May
              2018.

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

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

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

Author's Address

   Yubao Wang
   ZTE Corporation
   No. 50 Software Ave, Yuhuatai Distinct
   Nanjing
   China

   Email: wang.yubao2@zte.com.cn

Wang                    Expires October 22, 2020                [Page 9]