[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits] [IPR]



BESS Working Group                                            J. He, Ed.
Internet-Draft                                                    B. Nie
Intended status: Standards Track                                Ericsson
Expires: December 5, 2020                                   June 3, 2020


                EVPN Split Horizon Filtering Enhancement
           draft-jiang-bess-evpn-split-horizon-enhancement-00

Abstract

   Ethernet Virtual Private Network (EVPN) multi-homing accommodates
   load balance, link/node redundancy and fast convergence.  The split
   horizon filtering in EVPN avoids loop happens on multi-homed CE.
   However, this mechanism brings challenges switching chipsets on data
   plane.  This document describes an approach for the challenges by
   enhancing current split horizon filtering mechanism.  The advantage
   of this approach is that it simplifies data plane behaviors.

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 5, 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



He & Nie                Expires December 5, 2020                [Page 1]


Internet-Draft  EVPN Split Horizon Filtering Enhancement       June 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Approach  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Advertising EVPN VRF Route Import Extended Community  . .   4
     4.2.  Constructing IMET Routes  . . . . . . . . . . . . . . . .   4
     4.3.  Flooding Handling on Data Plane . . . . . . . . . . . . .   5
   5.  EVPN VRF Route Import Extended Community  . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  EVPN VRF Route Import Extended Community  . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Ethernet Virtual Private Network (EVPN) multi-homing accommodates
   load balance, link/node redundancy and fast convergence.  The split
   horizon filtering in EVPN avoids loop happens on multi-homed CE.  In
   particular, there are two split horizon filtering mechanisms to avoid
   looped frames on the multi-homed CE: ESI Label based [RFC7432] for
   MPLS based tunnels and Local Bias[RFC8365] for non-MPLS NVO tunnels,
   E.g.  VXLAN tunnels.

   However, each mechanism introduces challenges for data plane because
   extra logic is introduced but not available on some typical switching
   chipsets.  ESI Label based mechanism requires ingress PE to push ESI
   label into MPLS stack to indicate Ethernet Segment Identifier, and
   requires egress PE to filter out the corresponding port based on ESI
   label before flooding.  Local Bias does not require ingress PE to
   have extra procedure but still requires egress PE to filter out the
   corresponding ports based on source IP address before flooding.

   This document describes an approach towards the challenges, by
   enhancing current Local Bias split horizon filtering mechanism, for
   MPLS based tunnels and non-MPLS NVO tunnels.  The advantage of this
   approach is that it simplifies data plane behaviors.

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



He & Nie                Expires December 5, 2020                [Page 2]


Internet-Draft  EVPN Split Horizon Filtering Enhancement       June 2020


   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

      BUM: Broadcast, Unknown unicast and Multicast

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

      Ethernet Segment Identifier (ESI): A unique non-zero identifier
      that identifies an Ethernet segment is called an 'Ethernet Segment
      Identifier'.

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

      EVPN: Ethernet Virtual Private Network

      NVO: Network Virtualization Overlay

      PE: Provider Edge device.

      VXLAN: Virtual Extensible LAN

      NVGRE: Network Virtualization using Generic Routing Encapsulation

      VNI: VXLAN Network Identifier

      VSID: Virtual Subnet Identifier (for NVGRE)

3.  Approach

   When the PE advertises Inclusive Multicast Ethernet Tag (IMET) Routes
   to PEs which share the same multi-homed CE, it allocates unique label
   for each PE, rather than using the same label for all PEs.  To
   accomplish this, An EVPN VRF Route Import Extended Community is
   introduced.

   When the PE receives BUM packet from ingress PE, based on the BUM
   label encapsulated, it can determine the packet is from PEs which
   share the same multi-homed CE or not.  If yes, the PE can also
   determine which PE the packet is from.  Because the PE has determined
   the ingress PE, Local Bias based mechanism can be implemented for
   split horizon filtering without source IP information, but simply
   based on a single BUM label to determine the flooding scope.




He & Nie                Expires December 5, 2020                [Page 3]


Internet-Draft  EVPN Split Horizon Filtering Enhancement       June 2020


   For NVO solution, this approach requires locally assigned VNIs to be
   used just like downstream-assigned MPLS labels.

   Based on this extended mechanism, for MPLS based tunnels, no ESI
   label encapsulation is required on ingress PE either.

4.  Procedures

   Let's suppose an EVPN network, where CE1 is multi-homed to PE1 and
   PE2 with all-active mode, CE2 and CE3 are single-homed to PE2 and PE3
   separately.

                           +--------------+
               /--- PE1    |              |
           CE1             |     EVPN     |    PE3 --- CE3
               \--- PE2    |              |
                     |     +--------------+
                    CE2

                Figure 1: Sample EVPN Multi-homing Scenario

4.1.  Advertising EVPN VRF Route Import Extended Community

   In order to receive IMET route with unique label assigned by multi-
   homed peer, each VRF on PE1 MUST have an import Route Target Extended
   Community, and communicate the value to all other multi-homed peers.

   We refer to this Route Target as the "EVPN IMET Import RT", as this
   Route Target controls imports of EVPN IMET routes into a particular
   VRF.

   To communicate the value to all other multi-homed peers, PE1 when
   advertising an Ethernet Auto-discovery Route per EVI SHALL carry the
   EVPN VRF Route Import Extended Community (as defined in Section 5)
   that has the value of the EVPN IMET Import RT of the VRF associated
   with the route.

4.2.  Constructing IMET Routes

   Once EVPN routes with EVPN VRF Route Import Extended Community
   received on PE2, PE2 extracts the value of the EVPN VRF Route Import
   Extended Community.  The value of EVPN IMET Import RT is set to this
   value.

   Besides advertising IMET routes to other PEs as usual, PE2 advertises
   IMET route with unique BUM label to each multi-homed peer (here only
   PE1) by using EVPN IMET Import RT as route target.  It is suggested




He & Nie                Expires December 5, 2020                [Page 4]


Internet-Draft  EVPN Split Horizon Filtering Enhancement       June 2020


   to set a higher LOCAL_PREF for this BGP message, if another general
   IMET route is sent to PE1 also.

   Now suppose PE3 receives IMET route with label BUM0 from PE2, and PE1
   receives IMET route with label BUM1 from PE2.

4.3.  Flooding Handling on Data Plane

   Once PE2 advertises all IMET routes, including general and unique
   ones, it sets data plane to handle BUM labels as figure 2 described
   below (Suppose it is the Designated Forwarder).

                        +-----------+-------------+
                        | In Label  |  Out Ports  |
                        +-----------+-------------+
          (from PE3) -> | BUM0      |  CE1, CE2   |
                        +-----------+-------------+
          (from PE1) -> | BUM1      |  CE2        |
                        +-----------+-------------+

               Figure 2: Flooding handling on PE2 Data Plane

   Now BUM traffic is properly handled, no matter from multi-homed peers
   (E.g.  PE1) or other PEs (E.g.  PE3).  Unlike ESI Label based or
   Local Bias which requires two parameters for flooding decision, this
   flooding behavior requires only one parameter, the single BUM label.

5.  EVPN VRF Route Import Extended Community

   This document defines a new BGP Extended Community called "EVPN VRF
   Route Import".

   The EVPN VRF Route Import is an IP-address-specific Extended
   Community, of an extended type, and is transitive across AS
   boundaries [RFC4360].

   The EVPN VRF Route Import Extended Community has following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type=0x06     | Sub-Type=TBD  |    Global Administrator       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Global Administrator (cont.)  |    Local Administrator        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






He & Nie                Expires December 5, 2020                [Page 5]


Internet-Draft  EVPN Split Horizon Filtering Enhancement       June 2020


   This document expands the definition of EVPN Extended Community
   [RFC7153].  This Extended Community has a Type field value of 0x06
   and the Sub-Type TBD.

   The Global Administrator field of the EVPN VRF Route Import EC MUST
   be set to an IP address of the PE.  This address SHOULD be common for
   all the VRFs on the PE (e.g., this address may be the PE's loopback
   address).The Local Administrator field of the EVPN VRF Route Import
   EC associated with a given VRF contains a 2-octet number that
   uniquely identifies that VRF within the PE.

   For procedures and usage of this attribute, please see Section 4

6.  IANA Considerations

6.1.  EVPN VRF Route Import Extended Community

   This document makes the following registrations for EVPN VRF Route
   Import Extended Community.

   Type  Description
   ----  -----------
   TBD   EVPN VRF Route Import Extended Community


7.  Security Considerations

   If BGP is used as a CE-PE routing protocol, then when a PE receives a
   route from a CE, if this route carries the EVPN VRF Route Import
   Extended Community, the PE MUST remove this Community from the route
   before turning it into a VPF.  Routes that a PE advertises to a CE
   MUST NOT carry the EVPN VRF Route Import Extended Community.

8.  Normative References

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

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <https://www.rfc-editor.org/info/rfc4360>.

   [RFC7153]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP
              Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
              March 2014, <https://www.rfc-editor.org/info/rfc7153>.




He & Nie                Expires December 5, 2020                [Page 6]


Internet-Draft  EVPN Split Horizon Filtering Enhancement       June 2020


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

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

Authors' Addresses

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

   Email: jiang.he@ericsson.com


   Bolin Nie
   Ericsson
   No. 5, Lize east street, Chaoyang district
   Beijing  100102
   CN

   Email: zephyr.nie@ericsson.com


















He & Nie                Expires December 5, 2020                [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/