Skip to main content

Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)
draft-ietf-bess-spbm-evpn-02

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7734.
Authors David Allan , Jeff Tantsura , Don Fedyk , Ali Sajassi
Last updated 2016-01-22 (Latest revision 2015-10-05)
Replaces draft-ietf-l2vpn-spbm-evpn
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Martin Vigoureux
Shepherd write-up Show Last changed 2015-07-24
IESG IESG state RFC 7734 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Alvaro Retana
Send notices to aretana@cisco.com
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions
draft-ietf-bess-spbm-evpn-02
BESS Working Group                            Dave Allan, Jeff Tantsura 
Internet Draft                                                 Ericsson 
Intended status: Standards Track                              Don Fedyk         
Expires: May 2016                                                    HP 
                                                            Ali Sajassi 
                                                                  Cisco 
 
                                                           October 2015 
                                    

            Shortest Path Bridging, MAC Mode Support over EVPN 
                       draft-ietf-bess-spbm-evpn-02 

Abstract 

   This document describes how Ethernet Shortest Path Bridging MAC mode 
   (802.1aq) can be combined with EVPN to interwork with PBB-PEs as 
   described in the PBB-EVPN solution. This is achieved via   
   operational isolation of each Ethernet network attached an EVPN core 
   while supporting full interworking between the different variations 
   of Ethernet networks.    

Status of this Memo 

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

   Internet-Drafts are working documents of the Internet 
   Engineering Task Force (IETF), its areas, and its working 
   groups.  Note that other groups may also distribute working 
   documents as Internet-Drafts. 

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

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 

   This Internet-Draft will expire on February 2016. 

Copyright and License Notice 

 
Allan et al.,              Expires May 2016                    [Page 1] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

   Copyright (c) 2015 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 
   (http://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. Introduction...................................................2 
   1.1. Requirements Language........................................3 
   2. Conventions used in this document..............................3 
   2.1. Terminology..................................................3 
   3. Solution Overview..............................................4 
   4. Elements of Procedure..........................................5 
   4.1. PE Configuration.............................................5 
   4.2. DF Election..................................................6 
   4.3. Control plane interworking ISIS-SPB to EVPN..................6 
   4.4. Control plane interworking EVPN to ISIS-SPB..................7 
   4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to 
   EVPN..............................................................8 
   4.6. Data plane Interworking EVPN to 802.1aq SPBM island..........8 
   4.7. Data plane interworking EVPN to 802.1ah PBB-PE...............8 
   4.8. Multicast Support............................................8 
   5. Other Aspects..................................................9 
   5.1. Transit......................................................9 
   6. Security Considerations........................................9 
   7. IANA Considerations...........................................10 
   8. Acknowledgments...............................................10 
   9. References....................................................10 
   9.1. Normative References........................................10 
   9.2. Informative References......................................10 
   10. Authors' Addresses...........................................11 
    

1. Introduction 

   This document describes how Ethernet Shortest Path Bridging MAC mode 
   (SPBM) along with Provider Backbone Bridging Provider Edges (PBB-PEs) 
   and Provider Backbone Bridged Networks (PBBNs) can be supported by 
   Ethernet VPNs (EVPNs) such that each SPBM island is operationally 

 
Allan et al.,              Expires May 2016                    [Page 2] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

   isolated while providing full L2 connectivity between the different 
   types of PBBNs where desired. Each SPBM island uses its own control 
   plane instance and multi-pathing design, be it multiple equal cost 
   tree sets, or multiple spanning trees.  

   The intention is to permit past, current and emerging future versions 
   of Ethernet to be seamlessly interconnected to permit large scale, 
   geographically diverse numbers of Ethernet end systems to be fully 
   supported with EVPN as the unifying system. 

1.1. 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 [RFC2119]. 

    

2. Conventions used in this document 

2.1. Terminology 

      BEB: Backbone Edge Bridge 
      BGP: Border Gateway Protocol 
      B-MAC: Backbone MAC Address 
      B-VID: Backbone VLAN ID 
      CE: Customer Edge 
      DA: Destination Address 
      DF: Designated Forwarder 
      ESI: Ethernet Segment Identifier 
      EVPN: Ethernet VPN  
      IB-BEB: A BEB that has both an I-component (customer layer VLAN 
      aware bridge) and a B-component (backbone layer VLAN aware 
      bridge) 
      ISIS-SPB: IS-IS as extended for SPB 
      I-SID: I-Component Service ID 
      NLRI: Network Layer Reachability Information 
      PBB: Provider Backbone Bridging (802.1ah) 
      PBBN: Provider Backbone Bridged Network 
      PBB-PE: Co located 802.1ah BEB and EVPN PE 
 
Allan et al.,              Expires May 2016                    [Page 3] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

      PE: Provider Edge 
      SPB: Shortest Path Bridging 
      SPBM: Shortest Path Bridging MAC mode  
      SPBM-PE: Co-located 802.1aq SPBM<->EVPN interworking function and 
      EVPN PE 
       
3. Solution Overview 

   The EVPN solution for 802.1aq SPBM incorporates control plane 
   interworking in the PE to map ISIS-SPB [RFC6329] information elements 
   into the EVPN Next Layer Reachability Information (NLRI) and vice 
   versa. This requires each PE to act both as an EVPN BGP speaker and 
   as an ISIS-SPB edge node. Associated with this are procedures for 
   configuring the forwarding operations of the PE such that an 
   arbitrary number of EVPN attached SPBM islands can be interconnected 
   without any topological or multi-pathing dependencies. This model 
   also permits PBB-PEs as defined in [PBB-EVPN] to seamlessly 
   communicate with the SPBM islands.  

                            +--------------+ +----+   +---+ 
                            |              | |PBB |---|CE2| 
                            |              | |PE3 |   +---+ 
         +-----+     +----+ |              | +----+    
         |     |-----|SPBM| |              |  
         |SPBM |     |PE1 | |   IP/MPLS    |  
   +---+ |NTWK1|     +----+ |   Network    |  
   |CE1|-|     |            |              | 
   +---+ |     |     +----+ |              |  
         |     |-----|SPBM| |              | +----+   +-----+              
         +-----+     |PE2 | |              | |SPBM|   |SPBM | +---+ 
                     +----+ |              | |PE5 |---|NTWK2|-|CE3| 
                            +--------------+ +----+   +-----+ +---+  
               Figure 1: PBB and SPBM EVPN Network 
    
   Figure 1 illustrates the generalized space addressed by this memo. 
   SPBM networks may be multi-homed onto an IP/MPLS network that 
   implements EVPN for the purpose of interconnect with other SPBM 

 
Allan et al.,              Expires May 2016                    [Page 4] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

   networks, and/or PBB PEs. The multipathing configuration of each SPBM 
   network can be unique as the backbone VLAN ID (B-VID) configuration 
   (how multi-pathing is performed in SPBM) is not propagated across the 
   IP/MPLS network implementing EVPN. As with PBB networking the B-VID 
   is local to the SPBM network so in SPBM a B-MAC associated with B-VID 
   is advertised with the supported I-SIDs at the PBB gateway.  
    
   Each EVPN is identified by a route target. I-SID Based Load-balancing 
   in [PBB-EVPN] which allows multiple gateways per B-VID (each with 
   different I-SIDs) across the EVPN is supported by the interworking 
   between PBBNs and SPBM networks.  However SPBM only allows a single 
   active designated forwarder per B-VID as described below. The route 
   target identifies the set of SPBM islands and PBB-PEs that are 
   allowed to communicate. Each SPBM island is administered to have an 
   associated Ethernet Segment ID (ESI) extended community associated 
   with it.  
   BGP acts as a common repository of the I Component Service ID (I-SID) 
   attachment points for the set of attached PEs/SPBM islands. This is 
   in the form of B-MAC address/I-SID/Tx-Rx-attribute tuples. BGP 
   distributes I-SID information into each SPBM island on the basis of 
   locally registered interest. If an SPBM island has no backbone edge 
   bridges (BEBs) registering interest in a particular I-SID, 
   information about that I-SID from other SPBM islands, PBB-PEs or 
   PBBNs MUST NOT be leaked into the local ISIS-SPB routing system. 
   For each B-VID in an SPBM island, a single SPBM-PE MUST be elected 
   the designated forwarder (DF) for the B-VID. An SPBM-PE can be a DF 
   for more than one B-VID. This is described further in section 4.2. 
   The SPBM-PE originates IS-IS advertisements as if it were an IB-BEB 
   that proxies for the other SPBM islands and PBB PEs in the EVPN 
   defined by the route target, but the PE typically will not actually 
   host any I-components. 
   An SPBM-PE that is a DF for a B-VID MUST strip the B-VID tag 
   information from frames relayed towards the EVPN. The DF MUST also 
   insert the appropriate B-VID tag information into frames relayed 
   towards the SPBM island on the basis of the local I-SID/B-VID 
   bindings advertised in ISIS-SPB. 
                                   
4. Elements of Procedure 

   A PE MUST implement and perform the following procedures: 

4.1. PE Configuration 

   At SPBM island commissioning a PE is configured with: 
 
Allan et al.,              Expires May 2016                    [Page 5] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

   1) The route target for the service instance. Where a route target 
      is defined as identifying the set of SPBM islands, PBBNs and PBB-
      PEs to be interconnected by the EVPN. 

   2) The unique ESI for the SPBM island. Mechanisms for deriving a 
      unique ESI for the SPBM island are out of scope. 

   The following is configured as part of commissioning an ISIS-SPB 
   node: 

   1) A Shortest Path Source ID (SPSourceID) used for algorithmic 
      construction of multicast addresses. Note this is required for 
      SPBM BEB operation independent of the EVPN operation. 

   2) The set of B-VIDs used in the SPBM island and multi-pathing 
      algorithm IDs to use for each. The set of B-VIDs and multi-
      pathing algorithms used can be different in different domains. 
      Therefore the B-VID is local to an SPBM domain and is removed for 
      frames carried over the IP/MPLS network. 

   A type-1 Route Distinguisher for the node can be auto-derived. The 
   actual procedure is out of scope of this document.  

4.2. DF Election 

   PEs self appoint themselves for the role of DF for a B-VID for a 
   given SPBM island. The procedure used is as per section 8.5 of 
   [RFC7432] "Designated Forwarder election". 
   A PE that assumes the role of DF for a given B-VID is responsible for 
   originating specific information into BGP from ISIS-SPB and vice 
   versa. A PE that ceases to perform the role of DF for a given B-VID 
   is responsible for withdrawing the associated information from BGP 
   and ISIS-SPB respectively. The actual information exchanged is 
   outlined in the following sections. 
    
4.3. Control plane interworking ISIS-SPB to EVPN 

   When a PE receives an SPBM service identifier and unicast address 
   sub-TLV as part of an ISIS-SPB MT capability TLV it checks if it is 
   the DF for the B-VID in the sub-TLV. 

   If it is the DF, and there is new or changed information then a 
   MAC/IP advertisement route NLRI is created for each new I-SID in the 
   sub-TLV. Changed information that results in modification to existing 
   NLRI are processed accordingly. 

 
Allan et al.,              Expires May 2016                    [Page 6] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

   - the Route Distinguisher is set to that of the PE. 

   - the ESI is that of the SPBM island. 

   - the Ethernet tag ID contains the I-SID (including the Tx/Rx 
     attributes). The encoding of I-SID information is as per figure 2. 

 
       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |T|R| Reserved  |                 I-SID                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
         Figure 2: I-SID encoding in the Ethernet tag-ID field 

   - the MAC address is copied from the sub-TLV 

   - a locally assigned MPLS label  

   Similarly in the scenario where a PE became elected DF for a B-VID in 
   an operating network, the IS-IS database would be processed in order 
   to construct the NLRI information associated with the new role of the 
   PE. 

   If the BGP database has NLRI information for the I-SID, and this is 
   the first instance of registration of interest in the I-SID from the 
   SPBM island, the NLRI information with that tag is processed to 
   construct an updated set of SPBM service identifier and unicast 
   address sub-TLVs to be advertised by the PE. 

   The ISIS-SPB information is also used to keep current a local table 
   indexed by I-SID to indicate the associated B-VID for processing of 
   frames received from EVPN. When an I-SID is associated with more than 
   one B-VID, only one entry is allowed in the table. Rules for 
   preventing this are out of scope of this memo.  

4.4. Control plane interworking EVPN to ISIS-SPB 

   When a PE receives a BGP NLRI that has new information, it checks if 
   it is the elected DF to communicate this information into ISIS-SPB by 
   checking if the I-SID in the Ethernet Tag ID locally maps to the B-
   VID it is an elected DF for. Note that if no BEBs in the SPB island 
   have advertised any interest in the I-SID, it will not be associated 
   with any B-VID locally, and therefore not of interest. If the I-SID 
 
Allan et al.,              Expires May 2016                    [Page 7] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

   is of local interest to the SPBM island and the PE is the DF for the 
   B-VID that the I-SID is locally mapped to, a SPBM service identifier 
   and unicast address sub-TLV is constructed/updated for advertisement 
   into ISIS-SPB. 

   The NLRI information advertised into ISIS-SPB is also used to locally 
   populate a forwarding table indexed by B-MAC+I-SID that points to the 
   label stack to impose on the SPBM frame. The bottom label in the 
   stack being that obtained from the NLRI. 

4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to EVPN 

   When an PE receives a frame from the SPBM island in a B-VID for which 
   it is a DF, it looks up the B-MAC/I-SID information to determine the 
   label stack to be added to the frame for forwarding in the EVPN. The 
   PE strips the B-VID information from the frame, adds the label 
   information to the frame and forwards the resulting MPLS packet. 

4.6. Data plane Interworking EVPN to 802.1aq SPBM island 

   When a PE receives a packet from the EVPN it can infer the B-VID to 
   overwrite in the SPBM frame from the I-SID or by other means (such as 
   via the bottom label in the MPLS stack).  

   If the frame has a local multicast destination address (DA), it 
   overwrites the SPSourceID in the frame with the local SPSourceID. 

4.7. Data plane interworking EVPN to 802.1ah PBB-PE 

   A PBB-PE actually has no attached PBBN nor concept of B-VID so no 
   frame processing is required. 

   A PBB-PE is required to accept SPBM encoded multicast DAs as if they 
   were 802.1ah encoded multicast DAs. The only information of interest 
   being that it is a multicast frame, and the I-SID encoded in the 
   lower 24 bits. 

4.8. Multicast Support 

   Within a PBBN domain Ethernet Unicast and Multicast end services are 
   supported. PBB can tunnel multicast traffic in Unicast PBB frames 
   when using head end replication. This is the only form of multicast 
   traffic interworking supported by this document. Native PBB multicast 
   forwarding over EVPN, PE replication or optimizing PBB multicast 
   across the EVPN is not addressed by this memo. 

 
Allan et al.,              Expires May 2016                    [Page 8] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

5. Other Aspects 

5.1. Transit 

   Any PE that does not need to participate in the tandem calculations 
   at the B-MAC layer can use the IS-IS overload bit to exclude SPBM 
   tandem paths and behave as pure interworking platform. 
    
6. Security Considerations 

   Security issues associated with incorrect interconnect of customer 
   LANs cannot be directly addressed by implementations of this 
   document, as it requires misconfiguration in the Shortest Path 
   Bridging domains. The identifiers so administered have global 
   significance to the larger system. They are relayed transparently by 
   EVPN and only policed in the SPBM domains. Therefore care is required 
   in synchronization of identifiers that need to be common for inter-
   domain operation. 

   There are only two identifiers unique to this solution provisioned at 
   an SPBM-PE at service turn up; the route target and the ESI. The ESI 
   needs to be unique and common to all SPBM-PEs connected to a common 
   SPBM network, or PBBN else portions of the overall network will not 
   share reachability (EVPN will assume that separate networks are 
   interconnected by SPBM). Security issues exist when SPBM domains are 
   incorrectly cross connected together via EVPN which will result in 
   back-holing or incorrect delivery of data with associated privacy 
   issues. This could be achieved by provisioning the incorrect RT value 
   at an SPBM-PE or associating the RT with the wrong interface. This 
   can be avoided via care in route target provisioning at SPBM-PEs for 
   service adds and changes. 

   The potentially most destructive behavior of the overall system would 
   be frequent changes to the DF elections for a given ESI. This would 
   require SPBM-PEs to frequently flap in the form of either the node 
   continuously resetting or links flapping in a form that keeps 
   severing and re-connecting the SPBM-PE from either the IP/MPLS 
   network or the attached SPBM-Network. Either of these scenarios would 
   result in significant control plane traffic as DF associated 
   information was advertised and withdrawn from both the SPBM and BGP 
   control planes. Dual homing of SPBM-PEs on both networks would 
   minimize the likelihood of this scenario occurring. 

   The issues associated with securing the BGP control plane 
   (independent of this particular memo) are reflected in the security 
   considerations section of [RFC4761]. 

 
Allan et al.,              Expires May 2016                    [Page 9] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

7. IANA Considerations 

   No IANA assignments are required by this document. 

    

8. Acknowledgments 

   The authors would like to thank Peter Ashwood-Smith, Martin Julien 
   and Janos Farkas for their detailed review of this draft. 

    

9. References  

9.1. Normative References  

[RFC2119]   
                 Bradner, S., "Key words for use in RFCs to Indicate              
           Requirement Levels", BCP 14, RFC 2119, March 1997. 

[RFC4761]  Kompella (ed.), "Virtual Private LAN Service (VPLS) Using 
           BGP for Auto-Discovery and Signaling", IETF RFC 4761, 
           January 2007 

[RFC6329]   
                 Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq 
           Shortest Path Bridging", IETF RFC 6329, April 2012 

[RFC7432]   
                 Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF RFC 
           7432, February 2015 

9.2. Informative References 

[802.1aq]   
                 802.1aq (2012), IEEE Standard for Local and 
           Metropolitan Area Networks: Bridges and Virtual Bridged 
           Local Area Networks - Amendment 9: Shortest Path 
           Bridging 

[PBB-EVPN]  Sajassi et.al. "PBB E-VPN", IETF work in progress,   
            draft-ietf-l2vpn-pbb-evpn-10, May 2015 

[802.1Q]    
                 802.1Q (2011), IEEE Standard for Local and metropolitan 
           area networks--Media Access Control (MAC) Bridges and 
           Virtual Bridged Local Area Networks 

    

 
Allan et al.,              Expires May 2016                   [Page 10] 
 

Internet-Draft       draft-ietf-bess-spbm-evpn-02          October 2015 
 

10. Authors' Addresses 

   Dave Allan (editor) 
   Ericsson 
   300 Holger Way 
   San Jose, CA  95134 
   USA 
   Email: david.i.allan@ericsson.com  
    
   Jeff Tantsura 
   Ericsson 
   300 Holger Way 
   San Jose, CA 95134 
   USA 
   Email: jeff.tantsura@ericsson.com 
    
   Don Fedyk 
   Hewlett-Packard 
   153 Tayor Street 
   Littleton, MA, 01460 
   USA 
   don.fedyk@hp.com 
    
   Ali Sajassi 
   Cisco 
   170 West Tasman Drive 
   San Jose, CA  95134,  
   USA 
   Email: sajassi@cisco.com 
    

 
Allan et al.,              Expires May 2016                   [Page 11]