L2VPN Working Group Dave Allan, Jeff Tantsura Internet Draft Ericsson Intended status: Standards Track Don Fedyk Expires: April 2013 Alcatel-Lucent Ali Sajassi Cisco October 2012 802.1aq and 802.1Qbp Support over EVPN draft-allan-l2vpn-spbm-evpn-02 Abstract This document describes how Ethernet Shortest Path Bridging MAC mode (802.1aq) and (802.1Qbp) can be combined with EVPN in a way that interworks with PBB-PEs as described in the PBB-EVPN solution in a way that permits operational isolation of each Ethernet network subtending an EVPN core while supporting full interworking between the 3 variations of Ethernet operation. 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 January 2013. Copyright and License Notice Allan et al., Expires April 2013 [Page 1] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 Copyright (c) 2012 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...................................................3 1.1. Authors......................................................3 1.2. Requirements Language........................................3 2. Conventions used in this document..............................3 2.1. Terminology..................................................3 3. Changes since previous version.................................4 4. Solution Overview..............................................4 5. Elements of Procedure..........................................6 5.1. PE Configuration.............................................6 5.2. DF Election..................................................6 5.3. Control plane interworking ISIS-SPB to EVPN..................6 5.4. Control plane interworking EVPN to ISIS-SPB..................8 5.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to EVPN..............................................................8 5.6. Data plane Interworking EVPN to 802.1aq SPBM island..........9 5.7. Data plane interworking EVPN to 802.1ah PBB-PE...............9 5.8. Dataplane interworking between 802.1Qbp islands and EVPN.....9 5.9. Multicast Stitching..........................................9 6. Other Aspects..................................................9 6.1. Flow Ordering................................................9 6.2. Transit......................................................9 7. Acknowledgements...............................................9 8. Security Considerations.......................................10 9. IANA Considerations...........................................10 10. References...................................................10 10.1. Normative References.......................................10 10.2. Informative References.....................................10 11. Authors' Addresses...........................................11 Allan et al., Expires April 2013 [Page 2] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 1. Introduction This document describes how Ethernet Shortest Path Bridging MAC mode (802.1aq) and (802.1Qbp) along with PBB-PEs and PBBNs (802.1ah) can be supported by EVPN such that each island is operationally isolated while providing full L2 connectivity between them. Each island can use its own control plane instance and multi-pathing design, be it multiple ECT sets, multiple spanning trees, or ECMP. The intention is to permit both past, current and emerging future versions of Ethernet to be seamlessly integrated to permit large scale, geographically diverse numbers of Ethernet end systems to be fully supported with EVPN as the unifying agent. 1.1. Authors David Allan, Jeff Tantsura, Don Fedyk, Ali Sajassi 1.2. 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 [1]. 2. Conventions used in this document 2.1. Terminology BCB: Backbone Core Bridge BEB: Backbone Edge Bridge BU: Broadcast/Unknown B-MAC: Backbone MAC Address B-VID: Backbone VLAN ID CE: Customer Edge C-MAC: Customer/Client MAC Address DF: Designated Forwarder ESI: Ethernet segement identifer EVPN: Ethernet VPN ISIS-SPB: IS-IS as extended for SPB I-SID: I-Component Service ID MP2MP: Multipoint to Multipoint Allan et al., Expires April 2013 [Page 3] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 MVPN: Multicast VPN NLRI: Network layer reachability information PBBN: Provider Backbone Bridged Network PBB-PE: Co located BEB and PE PE: provider edge P2MP: Point to Multipoint P2P: Point to Point RD: Route Distinguisher SPB: Shortest path bridging SPBM: Shortest path bridging MAC mode 3. Changes since previous version 1) Change of term from MES to PE to align with base draft. 2) Introduction of B-MAC advertisement route NLRI to compress B_MAC associated I-SID information. 4. Solution Overview The EPVN solution for 802.1aq SPBM incorporates control plane interworking in the PE to map ISIS-SPB [2] information elements into the EVPN NLRI information 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 subtending SPB islands may be interconnected without any topological or multipathing dependencies. This requires each PE connected to an SPBM island to act both as an EVPN BGP speaker and as an ISIS-SPB edge node. This model also permits PBB- PEs as defined in draft-l2vpn-pbb-evpn-02[6] to be seamlessly communicate with the SPB islands. The next version of this document will add support for 802.1Qbp permitting seamless interworking between 802.1ah, 802.1aq and 802.1Qbp as well as supporting subtending 802.1ad based PBNs. +--------------+ | | | | +-----+ +----+ | | +----+ +---+ | |-----|SPBM| | | |PBB |---|CE2| Allan et al., Expires April 2013 [Page 4] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 |SPBM | |PE1 | | IP/MPLS | |PE1 | +---+ +---+ |NTWK1| +----+ | Network | +----+ |CE1|-| | | | +---+ | | +----+ | | | |-----|SPBM| | | +----+ +-----+ +-----+ |PE2 | | | |SPBM| |SPBM | +---+ +----+ | | |PE3 |---|NTWK2|-|CE3| +--------------+ +----+ +-----+ +---+ Figure 1: PBB and SPBM EVPN Network Each EVPN is identified by a route target. The route target identifies the set of SPB islands and BEB-PEs that are allowed to communicate. This manifests itself as a set of Ethernet segments, where each Ethernet segment ID is unique within the route target. BGP acts as a common repository of the I-SID attachment points for the set of subtending PEs/SPBM islands. This is in the form of B-MAC address/I-SID/Tx-Rx-attribute tuples. BGP filters leaking I-SID information into each SPBM ISLAND on the basis of locally registered interest. If an SPBM ISLAND has no BEBs registering interest in an I- SID, information about that I-SID from other SPBM island, PBB-PEs or PBBNs will not be leaked into the local ISIS-SPB routing system. Each SPBM island is administered to have an associated Ethernet Segment ID (ESI) associated with it. For each B-VID in an SPBM island, a single SPBM-PE is elected the designated forwarder for the B-VID. An SPBM-PE may 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 I-BEB or IB-BEB that proxy for the other SPBM islands and PBB PEs in the VPN 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 strips the B-VID tag information from frames relayed towards the EVPN. The DF also inserts 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. Allan et al., Expires April 2013 [Page 5] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 5. Elements of Procedure 5.1. PE Configuration At SPBM island commissioning a PE is configured with: 1) The route target for the service instance. Where a service instance is defined as 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 common ESI for the SPBM island are for a future version of the document. And 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 DA addresses. Note this is 2) The set of VLANs (identified by B-VIDs Ethernet frames) used in the SPBM island and multipathing algorithm IDs to use. The B-VID may be different in different domains and may be removed as carried over the IP/MPLS network. A type-1 RD for the node can be auto-derived. This will be described in a future version of the document. 5.2. DF Election PEs self appoint in the role of DF for a B-VID for a given SPBM island. The procedure used is as per section 9.5.2 of draft-ietf- l2vpn-evpn-01[4] "DF election with service carving". 5.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 B-MAC advertisement route NLRI is created or updated for each new I-SID in the sub-TLV. The format of the B-MAC advertisement route TLV is: Allan et al., Expires April 2013 [Page 6] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 +---------------------------------------+ | RD (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | B-MAC Address Length (1 octet) | +---------------------------------------+ | B-MAC Address (6 octets) | +---------------------------------------+ | MPLS Label (n * 3 octets) | +---------------------------------------+ | version (4 bits) | 0 0 0 0 | +---------------------------------------+ | Base I-SID (3 octets) | +---------------------------------------+ | I-SID vector length (1 octet) | +---------------------------------------+ | I-SID vector | // // +---------------------------------------+ - the Route Distinguisher (RD) is set to that of the PE - the ESI is that of the SPBM island - B-MAC address length/B-MAC address encode the MAC address of the advertising BEB - The MPLS label encodes the label value to be used (does not have to be unique) - The version identifies how the I-SID information is encoded. This is set to 0000b. - The base I-SID value identifies the I-SID value associated with the start of the I-SID vector. - The I-SID vector is a bit vector which uses 3 bits to define the interest in each I-SID value encoded (from base I-SID to base I- SID plus I-SID vector length-1) The encoding is: Bit 0 =1 if the BEB has registered interest in the I-SID, =0 otherwise. Allan et al., Expires April 2013 [Page 7] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 Bit 1 =1 if the BEB has registered multicast transmit interest, = 0 otherwise, or if Bit 0 =0. Bit 2 =1 if the BEB has registered multicast receive interest, = 0 otherwise or if Bit 0 =0. Similarly in the scenario where a MES 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 SPB 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 this will be in a future version of the document. 5.4. Control plane interworking EVPN to ISIS-SPB When a PE receives a BGP NLRI that is new information, it checks 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 is of local interest to the SPBM island and the PE is the DF for the B-VID that that I-SID is locally mapped to, a SPBM service identifier and unicast address sub-TLV is constructed/updated for advertisement into IS-IS. 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 being that offered in the NLRI. 5.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. Allan et al., Expires April 2013 [Page 8] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 5.6. Data plane Interworking EVPN to 802.1aq SPBM island When a PE receives a packet from the EVPN it may 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 DA, it overwrites the SPsourceID in the frame with the local SPsourceID. 5.7. Data plane interworking EVPN to 802.1ah PBB-PE A PBB-PE actually has no subtending 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. 5.8. Dataplane interworking between 802.1Qbp islands and EVPN For a future version of the document 5.9. Multicast Stitching For a future version of the document 6. Other Aspects 6.1. Flow Ordering When per I-SID multicast is implemented via PE replication, a stable network will preserve frame ordering between known unicast and BU traffic (e.g. race conditions will not exist). This cannot be guaranteed when multicast is used in the EVPN. 6.2. Transit Any PE that does not need to participate in the tandem calculations may use the IS-IS overload bit to exclude SPBM tandem paths and behave as pure interworking platform. 7. Acknowledgements The authors would like to thank Peter Ashwood-Smith and Janos Farkas for their detailed review of this draft. Allan et al., Expires April 2013 [Page 9] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 8. Security Considerations For a future version of this document. 9. IANA Considerations For a future version of this document. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", IETF RFC 6329, April 2012 [3] Rosen et.al., "BGP/MPLS IP Virtual Private Networks (VPNs)", IETF RFC 4364, February 2006 [4] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF work in progress, draft-ietf-l2vpn-evpn-01, July 2012 10.2. Informative References [5] IEEE Standard for Local and Metropolitan Area Networks: Bridges and Virtual Bridged Local Area Networks - Amendment 9: Shortest Path Bridging [6] Draft IEEE Standard for Local and Metropolitan Area Networks---Virtual Bridged Local Area Networks - Amendment: Equal Cost Multiple Paths (ECMP), 802.1Qbp draft 1.0 [7] Sajassi et.al. "PBB E-VPN", IETF work in progress, draft- ietf-l2vpn-pbb-evpn-03, June 2012 [8] 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 April 2013 [Page 10] Internet-Draft draft-allan-l2vpn-spbm-evpn-02 October 2012 11. 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 Email: jeff.tantsura@ericsson.com Don Fedyk Alcatel-Lucent Groton, MA 01450 USA EMail: Donald.Fedyk@alcatel-lucent.com Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134, US Email: sajassi@cisco.com Allan et al., Expires April 2013 [Page 11]