idnits 2.17.1 draft-ietf-bess-spbm-evpn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2015) is 3179 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 BESS Working Group Dave Allan, Jeff Tantsura 2 Internet Draft Ericsson 3 Intended status: Standards Track Don Fedyk 4 Expires: February 2016 HP 5 Ali Sajassi 6 Cisco 8 July 2015 10 Shortest Path Bridging, MAC Mode Support over EVPN 11 draft-ietf-bess-spbm-evpn-00 13 Abstract 15 This document describes how Ethernet Shortest Path Bridging MAC mode 16 (802.1aq) can be combined with EVPN in a way that interworks with 17 PBB-PEs as described in the PBB-EVPN solution. This is achieved via 18 operational isolation of each Ethernet network subtending an EVPN 19 core while supporting full interworking between the different 20 variations of Ethernet networks. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance 25 with the provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet 28 Engineering Task Force (IETF), its areas, and its working 29 groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet- 35 Drafts as reference material or to cite them other than as "work 36 in progress". 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on February 2016. 46 Copyright and License Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described 57 in Section 4.e of the Trust Legal Provisions and are provided 58 without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................3 63 1.1. Authors......................................................3 64 1.2. Requirements Language........................................3 65 2. Conventions used in this document..............................3 66 2.1. Terminology..................................................3 67 3. Solution Overview..............................................4 68 4. Elements of Procedure..........................................5 69 4.1. PE Configuration.............................................5 70 4.2. DF Election..................................................6 71 4.3. Control plane interworking ISIS-SPB to EVPN..................6 72 4.4. Control plane interworking EVPN to ISIS-SPB..................7 73 4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to 74 EVPN..............................................................8 75 4.6. Data plane Interworking EVPN to 802.1aq SPBM island..........8 76 4.7. Data plane interworking EVPN to 802.1ah PBB-PE...............8 77 4.8. Multicast Support............................................8 78 5. Other Aspects..................................................8 79 5.1. Flow Ordering................................................8 80 5.2. Transit......................................................8 81 6. Acknowledgements...............................................9 82 7. Security Considerations........................................9 83 8. IANA Considerations............................................9 84 9. References.....................................................9 85 9.1. Normative References.........................................9 86 [RFC4761] Kompella (ed.), "Virtual Private LAN Service (VPLS) 87 Using BGP for Auto-Discovery and Signaling", IETF RFC 4761, January 88 2007 9 89 9.2. Informative References......................................10 90 10. Authors' Addresses...........................................10 92 1. Introduction 94 This document describes how Ethernet Shortest Path Bridging MAC mode 95 (802.1aq) along with PBB-PEs and PBBNs (802.1ah) can be supported by 96 EVPN such that each island is operationally isolated while providing 97 full L2 connectivity between them. Each island can use its own 98 control plane instance and multi-pathing design, be it multiple ECT 99 sets, or multiple spanning trees. 101 The intention is to permit both past, current and emerging future 102 versions of Ethernet to be seamlessly integrated to permit large 103 scale, geographically diverse numbers of Ethernet end systems to be 104 fully supported with EVPN as the unifying agent. 106 1.1. Authors 108 David Allan, Jeff Tantsura, Don Fedyk, Ali Sajassi 110 1.2. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC2119 [RFC2119]. 116 2. Conventions used in this document 118 2.1. Terminology 120 BEB: Backbone Edge Bridge 121 B-MAC: Backbone MAC Address 122 B-VID: Backbone VLAN ID 123 CE: Customer Edge 124 DF: Designated Forwarder 125 ESI: Ethernet Segment Identifier 126 EVPN: Ethernet VPN 127 IB-BEB: A BEB that has both an I-component (customer layer VLAN 128 aware bridge) and a B-component (backbone layer VLAN aware 129 bridge) 130 ISIS-SPB: IS-IS as extended for SPB 131 I-SID: I-Component Service ID 132 NLRI: Network Layer Reachability Information 133 PBBN: Provider Backbone Bridged Network 134 PBB-PE: Co located 802.1ah BEB and EVPN PE 135 PE: Provider Edge 136 SPB: Shortest Path Bridging 137 SPBM: Shortest Path Bridging MAC mode 138 SPBM-PE: Co-located 802.1aq SPBM<->EVPN interworking function and 139 EVPN PE 141 3. Solution Overview 143 The EVPN solution for 802.1aq SPBM incorporates control plane 144 interworking in the PE to map ISIS-SPB [RFC6329] information elements 145 into the EVPN NLRI information and vice versa. This requires each PE 146 to act both as an EVPN BGP speaker and as an ISIS-SPB edge node. 147 Associated with this are procedures for configuring the forwarding 148 operations of the PE such that an arbitrary number of EVPN subtending 149 SPBM islands may be interconnected without any topological or 150 multipathing dependencies. This model also permits PBB-PEs as defined 151 in [PBB-EVPN] to be seamlessly communicate with the SPB islands. 153 +--------------+ 154 | | 155 | | 156 +-----+ +----+ | | +----+ +---+ 157 | |-----|SPBM| | | |PBB |---|CE2| 158 |SPBM | |PE1 | | IP/MPLS | |PE1 | +---+ 159 +---+ |NTWK1| +----+ | Network | +----+ 160 |CE1|-| | | | 161 +---+ | | +----+ | | 162 | |-----|SPBM| | | +----+ +-----+ 163 +-----+ |PE2 | | | |SPBM| |SPBM | +---+ 164 +----+ | | |PE3 |---|NTWK2|-|CE3| 165 +--------------+ +----+ +-----+ +---+ 166 Figure 1: PBB and SPBM EVPN Network 168 Each EVPN is identified by a route target. The route target 169 identifies the set of SPBM islands and PBB-PEs that are allowed to 170 communicate. Each SPBM island is administered to have an associated 171 Ethernet Segment ID (ESI) associated with it. This manifests itself 172 as a set of Ethernet segments, where each ESI is unique within the 173 route target. 174 BGP acts as a common repository of the I-SID attachment points for 175 the set of subtending PEs/SPBM islands. This is in the form of B-MAC 176 address/I-SID/Tx-Rx-attribute tuples. BGP filters leaking I-SID 177 information into each SPBM island on the basis of locally registered 178 interest. If an SPBM island has no BEBs registering interest in an I- 179 SID, information about that I-SID from other SPBM islands, PBB-PEs or 180 PBBNs MUST NOT be leaked into the local ISIS-SPB routing system. 181 For each B-VID in an SPBM island, a single SPBM-PE MUST be elected 182 the designated forwarder for the B-VID. An SPBM-PE may be a DF for 183 more than one B-VID. This is described further in section 5.2. The 184 SPBM-PE originates IS-IS advertisements as if it were an IB-BEB that 185 proxies for the other SPBM islands and PBB PEs in the EVPN defined by 186 the route target, but the PE typically will not actually host any I- 187 components. 188 An SPBM-PE that is a DF for a B-VID MUST strip the B-VID tag 189 information from frames relayed towards the EVPN. The DF MUST also 190 insert the appropriate B-VID tag information into frames relayed 191 towards the SPBM island on the basis of the local I-SID/B-VID 192 bindings advertised in ISIS-SPB. 194 4. Elements of Procedure 196 A PE MUST implement the following procedures: 198 4.1. PE Configuration 200 At SPBM island commissioning a PE is configured with: 202 1) The route target for the service instance. Where a route target 203 is defined as identifying the set of SPBM islands, PBBNs and PBB- 204 PEs to be interconnected by the EVPN. 206 2) The unique ESI for the SPBM island. Mechanisms for deriving a 207 unique ESI for the SPBM island are out of scope. 209 And the following is configured as part of commissioning an ISIS-SPB 210 node: 212 1) A Shortest Path Source ID (SPSourceID) used for algorithmic 213 construction of multicast addresses. Note this is required for 214 SPBM BEBs independent of the EVPN operation. 216 2) The set of VLANs (identified by B-VIDs) used in the SPBM island 217 and multi-pathing algorithm IDs to use. The set of B-VIDs and 218 multi-pathing algorithms used may be different in different 219 domains. Therefore the B-VID is local to an SPBM domain and is 220 removed for frames carried over the IP/MPLS network. 222 A type-1 Route Distinguisher for the node can be auto-derived. The 223 actual procedure is out of scope of this document. 225 4.2. DF Election 227 PEs self appoint in the role of DF for a B-VID for a given SPBM 228 island. The procedure used is as per section 8.5 of [RFC7432] 229 "Designated Forwarder election". 230 A PE that assumes the role of DF for a given B-VID is responsible for 231 originating specific information into BGP from ISIS-SPB and vice 232 versa. A PE that ceases to perform the role of DF for a given B-VID 233 is responsible for withdrawing the associated information from BGP 234 and ISIS-SPB respectively. The actual information exchanged is 235 outlined in the following sections. 237 4.3. Control plane interworking ISIS-SPB to EVPN 239 When a PE receives an SPBM service identifier and unicast address 240 sub-TLV as part of an ISIS-SPB MT capability TLV it checks if it is 241 the DF for the B-VID in the sub-TLV. 243 If it is the DF, and there is new or changed information then a 244 MAC/IP advertisement route NLRI is created for each new I-SID in the 245 sub-TLV. Changed information that results in modification to existing 246 NLRI are processed accordingly. 248 - the Route Distinguisher is set to that of the PE. 250 - the ESI is that of the SPBM island. 252 - the Ethernet tag ID contains the I-SID (including the Tx/Rx 253 attributes). The encoding of I-SID information is as per figure 2. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |T|R| Reserved | I-SID | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 2: I-SID encoding in the Ethernet tag-ID field 263 - the MAC address is copied from the sub-TLV 265 - a locally assigned MPLS label 267 Similarly in the scenario where a PE became elected DF for a B-VID in 268 an operating network, the IS-IS database would be processed in order 269 to construct the NLRI information associated with the new role of the 270 PE. 272 If the BGP database has NLRI information for the I-SID, and this is 273 the first instance of registration of interest in the I-SID from the 274 SPB island, the NLRI information with that tag is processed to 275 construct an updated set of SPBM service identifier and unicast 276 address sub-TLVs to be advertised by the PE. 278 The ISIS-SPB information is also used to keep current a local table 279 indexed by I-SID to indicate the associated B-VID for processing of 280 frames received from EVPN. When an I-SID is associated with more than 281 one B-VID, only one entry is allowed in the table. Rules for 282 preventing this are out of scope of this memo. 284 4.4. Control plane interworking EVPN to ISIS-SPB 286 When a PE receives a BGP NLRI that has new information, it checks if 287 it is the elected DF to communicate this information into ISIS-SPB by 288 checking if the I-SID in the Ethernet Tag ID locally maps to the B- 289 VID it is an elected DF for. Note that if no BEBs in the SPB island 290 have advertised any interest in the I-SID, it will not be associated 291 with any B-VID locally, and therefore not of interest. If the I-SID 292 is of local interest to the SPBM island and the PE is the DF for the 293 B-VID that the I-SID is locally mapped to, a SPBM service identifier 294 and unicast address sub-TLV is constructed/updated for advertisement 295 into ISIS-SPB. 297 The NLRI information advertised into ISIS-SPB is also used to locally 298 populate a forwarding table indexed by B-MAC+I-SID that points to the 299 label stack to impose on the SPBM frame. The bottom label in the 300 stack being that obtained from the NLRI. 302 4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to EVPN 304 When an PE receives a frame from the SPBM island in a B-VID for which 305 it is a DF, it looks up the B-MAC/I-SID information to determine the 306 label stack to be added to the frame for forwarding in the EVPN. The 307 PE strips the B-VID information from the frame, adds the label 308 information to the frame and forwards the resulting MPLS packet. 310 4.6. Data plane Interworking EVPN to 802.1aq SPBM island 312 When a PE receives a packet from the EVPN it may infer the B-VID to 313 overwrite in the SPBM frame from the I-SID or by other means (such as 314 via the bottom label in the MPLS stack). 316 If the frame has a local multicast DA, it overwrites the SPsourceID 317 in the frame with the local SPsourceID. 319 4.7. Data plane interworking EVPN to 802.1ah PBB-PE 321 A PBB-PE actually has no subtending PBBN nor concept of B-VID so no 322 frame processing is required. 324 A PBB-PE is required to accept SPBM encoded multicast DAs as if they 325 were 802.1ah encoded multicast DAs. The only information of interest 326 being that it is a multicast frame, and the I-SID encoded in the 327 lower 24 bits. 329 4.8. Multicast Support 331 Not addressed by this memo. 333 5. Other Aspects 335 5.1. Flow Ordering 337 When per I-SID multicast is implemented via PE replication, a stable 338 network will preserve frame ordering between known unicast and 339 broadcast/unknown/multicast traffic (e.g. race conditions will not 340 exist). This cannot be guaranteed when multicast is used in the EVPN. 342 5.2. Transit 344 Any PE that does not need to participate in the tandem calculations 345 at the B-MAC layer may use the IS-IS overload bit to exclude SPBM 346 tandem paths and behave as pure interworking platform. 348 6. Acknowledgements 350 The authors would like to thank Peter Ashwood-Smith, Martin Julien 351 and Janos Farkas for their detailed review of this draft. 353 7. Security Considerations 355 Security issues associated with incorrect interconnect of customer 356 LANs cannot be directly addressed by implementations of this 357 document, as it requires misconfiguration in the Shortest Path 358 Bridging domains. The identifiers so administered have global 359 significance to the larger system. They are relayed transparently by 360 EVPN and only policed in the SPBM domains. 362 Security issues exist when SPBM domains are incorrectly cross 363 connected together via EVPN which will result in back-holing or 364 incorrect delivery of data with associated privacy issues. This would 365 be a consequence of conflicting administration of SPBM LAN 366 identifiers. 368 Most of the issues associated with securing the BGP control plane are 369 reflected in the security considerations section of [RFC4761]. 371 8. IANA Considerations 373 No IANA assignments are required by this document. 375 9. References 377 9.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC4761] Kompella (ed.), "Virtual Private LAN Service (VPLS) Using 383 BGP for Auto-Discovery and Signaling", IETF RFC 4761, 384 January 2007 386 [RFC6329] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq 387 Shortest Path Bridging", IETF RFC 6329, April 2012 389 [RFC7432] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF work 390 in progress, IETF RFC 7432, February 2015 392 9.2. Informative References 394 [802.1aq] 395 802.1aq(2012) IEEE Standard for Local and Metropolitan 396 Area Networks: Bridges and Virtual Bridged Local Area 397 Networks - Amendment 9: Shortest Path Bridging 399 [PBB-EVPN] Sajassi et.al. "PBB E-VPN", IETF work in progress, 400 draft-ietf-l2vpn-pbb-evpn-10, May 2015 402 [802.1Q] 403 802.1Q (2011) IEEE Standard for Local and metropolitan 404 area networks--Media Access Control (MAC) Bridges and 405 Virtual Bridged Local Area Networks 407 10. Authors' Addresses 409 Dave Allan (editor) 410 Ericsson 411 300 Holger Way 412 San Jose, CA 95134 413 USA 414 Email: david.i.allan@ericsson.com 416 Jeff Tantsura 417 Ericsson 418 300 Holger Way 419 San Jose, CA 95134 420 Email: jeff.tantsura@ericsson.com 422 Don Fedyk 423 Hewlett-Packard 424 153 Tayor Street 425 Littleton, MA, 01460 426 don.fedyk@hp.com 428 Ali Sajassi 429 Cisco 430 170 West Tasman Drive 431 San Jose, CA 95134, US 432 Email: sajassi@cisco.com