idnits 2.17.1 draft-ietf-bess-spbm-evpn-02.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 (October 2015) is 3115 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: May 2016 HP 5 Ali Sajassi 6 Cisco 8 October 2015 10 Shortest Path Bridging, MAC Mode Support over EVPN 11 draft-ietf-bess-spbm-evpn-02 13 Abstract 15 This document describes how Ethernet Shortest Path Bridging MAC mode 16 (802.1aq) can be combined with EVPN to interwork with PBB-PEs as 17 described in the PBB-EVPN solution. This is achieved via 18 operational isolation of each Ethernet network attached an EVPN core 19 while supporting full interworking between the different variations 20 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...................................................2 63 1.1. Requirements Language........................................3 64 2. Conventions used in this document..............................3 65 2.1. Terminology..................................................3 66 3. Solution Overview..............................................4 67 4. Elements of Procedure..........................................5 68 4.1. PE Configuration.............................................5 69 4.2. DF Election..................................................6 70 4.3. Control plane interworking ISIS-SPB to EVPN..................6 71 4.4. Control plane interworking EVPN to ISIS-SPB..................7 72 4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to 73 EVPN..............................................................8 74 4.6. Data plane Interworking EVPN to 802.1aq SPBM island..........8 75 4.7. Data plane interworking EVPN to 802.1ah PBB-PE...............8 76 4.8. Multicast Support............................................8 77 5. Other Aspects..................................................9 78 5.1. Transit......................................................9 79 6. Security Considerations........................................9 80 7. IANA Considerations...........................................10 81 8. Acknowledgments...............................................10 82 9. References....................................................10 83 9.1. Normative References........................................10 84 9.2. Informative References......................................10 85 10. Authors' Addresses...........................................11 87 1. Introduction 89 This document describes how Ethernet Shortest Path Bridging MAC mode 90 (SPBM) along with Provider Backbone Bridging Provider Edges (PBB-PEs) 91 and Provider Backbone Bridged Networks (PBBNs) can be supported by 92 Ethernet VPNs (EVPNs) such that each SPBM island is operationally 93 isolated while providing full L2 connectivity between the different 94 types of PBBNs where desired. Each SPBM island uses its own control 95 plane instance and multi-pathing design, be it multiple equal cost 96 tree sets, or multiple spanning trees. 98 The intention is to permit past, current and emerging future versions 99 of Ethernet to be seamlessly interconnected to permit large scale, 100 geographically diverse numbers of Ethernet end systems to be fully 101 supported with EVPN as the unifying system. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC2119 [RFC2119]. 109 2. Conventions used in this document 111 2.1. Terminology 113 BEB: Backbone Edge Bridge 114 BGP: Border Gateway Protocol 115 B-MAC: Backbone MAC Address 116 B-VID: Backbone VLAN ID 117 CE: Customer Edge 118 DA: Destination Address 119 DF: Designated Forwarder 120 ESI: Ethernet Segment Identifier 121 EVPN: Ethernet VPN 122 IB-BEB: A BEB that has both an I-component (customer layer VLAN 123 aware bridge) and a B-component (backbone layer VLAN aware 124 bridge) 125 ISIS-SPB: IS-IS as extended for SPB 126 I-SID: I-Component Service ID 127 NLRI: Network Layer Reachability Information 128 PBB: Provider Backbone Bridging (802.1ah) 129 PBBN: Provider Backbone Bridged Network 130 PBB-PE: Co located 802.1ah BEB and EVPN PE 131 PE: Provider Edge 132 SPB: Shortest Path Bridging 133 SPBM: Shortest Path Bridging MAC mode 134 SPBM-PE: Co-located 802.1aq SPBM<->EVPN interworking function and 135 EVPN PE 137 3. Solution Overview 139 The EVPN solution for 802.1aq SPBM incorporates control plane 140 interworking in the PE to map ISIS-SPB [RFC6329] information elements 141 into the EVPN Next Layer Reachability Information (NLRI) and vice 142 versa. This requires each PE to act both as an EVPN BGP speaker and 143 as an ISIS-SPB edge node. Associated with this are procedures for 144 configuring the forwarding operations of the PE such that an 145 arbitrary number of EVPN attached SPBM islands can be interconnected 146 without any topological or multi-pathing dependencies. This model 147 also permits PBB-PEs as defined in [PBB-EVPN] to seamlessly 148 communicate with the SPBM islands. 150 +--------------+ +----+ +---+ 151 | | |PBB |---|CE2| 152 | | |PE3 | +---+ 153 +-----+ +----+ | | +----+ 154 | |-----|SPBM| | | 155 |SPBM | |PE1 | | IP/MPLS | 156 +---+ |NTWK1| +----+ | Network | 157 |CE1|-| | | | 158 +---+ | | +----+ | | 159 | |-----|SPBM| | | +----+ +-----+ 160 +-----+ |PE2 | | | |SPBM| |SPBM | +---+ 161 +----+ | | |PE5 |---|NTWK2|-|CE3| 162 +--------------+ +----+ +-----+ +---+ 163 Figure 1: PBB and SPBM EVPN Network 165 Figure 1 illustrates the generalized space addressed by this memo. 166 SPBM networks may be multi-homed onto an IP/MPLS network that 167 implements EVPN for the purpose of interconnect with other SPBM 168 networks, and/or PBB PEs. The multipathing configuration of each SPBM 169 network can be unique as the backbone VLAN ID (B-VID) configuration 170 (how multi-pathing is performed in SPBM) is not propagated across the 171 IP/MPLS network implementing EVPN. As with PBB networking the B-VID 172 is local to the SPBM network so in SPBM a B-MAC associated with B-VID 173 is advertised with the supported I-SIDs at the PBB gateway. 175 Each EVPN is identified by a route target. I-SID Based Load-balancing 176 in [PBB-EVPN] which allows multiple gateways per B-VID (each with 177 different I-SIDs) across the EVPN is supported by the interworking 178 between PBBNs and SPBM networks. However SPBM only allows a single 179 active designated forwarder per B-VID as described below. The route 180 target identifies the set of SPBM islands and PBB-PEs that are 181 allowed to communicate. Each SPBM island is administered to have an 182 associated Ethernet Segment ID (ESI) extended community associated 183 with it. 184 BGP acts as a common repository of the I Component Service ID (I-SID) 185 attachment points for the set of attached PEs/SPBM islands. This is 186 in the form of B-MAC address/I-SID/Tx-Rx-attribute tuples. BGP 187 distributes I-SID information into each SPBM island on the basis of 188 locally registered interest. If an SPBM island has no backbone edge 189 bridges (BEBs) registering interest in a particular I-SID, 190 information about that I-SID from other SPBM islands, PBB-PEs or 191 PBBNs MUST NOT be leaked into the local ISIS-SPB routing system. 192 For each B-VID in an SPBM island, a single SPBM-PE MUST be elected 193 the designated forwarder (DF) for the B-VID. An SPBM-PE can be a DF 194 for more than one B-VID. This is described further in section 4.2. 195 The SPBM-PE originates IS-IS advertisements as if it were an IB-BEB 196 that proxies for the other SPBM islands and PBB PEs in the EVPN 197 defined by the route target, but the PE typically will not actually 198 host any I-components. 199 An SPBM-PE that is a DF for a B-VID MUST strip the B-VID tag 200 information from frames relayed towards the EVPN. The DF MUST also 201 insert the appropriate B-VID tag information into frames relayed 202 towards the SPBM island on the basis of the local I-SID/B-VID 203 bindings advertised in ISIS-SPB. 205 4. Elements of Procedure 207 A PE MUST implement and perform the following procedures: 209 4.1. PE Configuration 211 At SPBM island commissioning a PE is configured with: 213 1) The route target for the service instance. Where a route target 214 is defined as identifying the set of SPBM islands, PBBNs and PBB- 215 PEs to be interconnected by the EVPN. 217 2) The unique ESI for the SPBM island. Mechanisms for deriving a 218 unique ESI for the SPBM island are out of scope. 220 The following is configured as part of commissioning an ISIS-SPB 221 node: 223 1) A Shortest Path Source ID (SPSourceID) used for algorithmic 224 construction of multicast addresses. Note this is required for 225 SPBM BEB operation independent of the EVPN operation. 227 2) The set of B-VIDs used in the SPBM island and multi-pathing 228 algorithm IDs to use for each. The set of B-VIDs and multi- 229 pathing algorithms used can be different in different domains. 230 Therefore the B-VID is local to an SPBM domain and is removed for 231 frames carried over the IP/MPLS network. 233 A type-1 Route Distinguisher for the node can be auto-derived. The 234 actual procedure is out of scope of this document. 236 4.2. DF Election 238 PEs self appoint themselves for the role of DF for a B-VID for a 239 given SPBM island. The procedure used is as per section 8.5 of 240 [RFC7432] "Designated Forwarder election". 241 A PE that assumes the role of DF for a given B-VID is responsible for 242 originating specific information into BGP from ISIS-SPB and vice 243 versa. A PE that ceases to perform the role of DF for a given B-VID 244 is responsible for withdrawing the associated information from BGP 245 and ISIS-SPB respectively. The actual information exchanged is 246 outlined in the following sections. 248 4.3. Control plane interworking ISIS-SPB to EVPN 250 When a PE receives an SPBM service identifier and unicast address 251 sub-TLV as part of an ISIS-SPB MT capability TLV it checks if it is 252 the DF for the B-VID in the sub-TLV. 254 If it is the DF, and there is new or changed information then a 255 MAC/IP advertisement route NLRI is created for each new I-SID in the 256 sub-TLV. Changed information that results in modification to existing 257 NLRI are processed accordingly. 259 - the Route Distinguisher is set to that of the PE. 261 - the ESI is that of the SPBM island. 263 - the Ethernet tag ID contains the I-SID (including the Tx/Rx 264 attributes). The encoding of I-SID information is as per figure 2. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |T|R| Reserved | I-SID | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 2: I-SID encoding in the Ethernet tag-ID field 274 - the MAC address is copied from the sub-TLV 276 - a locally assigned MPLS label 278 Similarly in the scenario where a PE became elected DF for a B-VID in 279 an operating network, the IS-IS database would be processed in order 280 to construct the NLRI information associated with the new role of the 281 PE. 283 If the BGP database has NLRI information for the I-SID, and this is 284 the first instance of registration of interest in the I-SID from the 285 SPBM island, the NLRI information with that tag is processed to 286 construct an updated set of SPBM service identifier and unicast 287 address sub-TLVs to be advertised by the PE. 289 The ISIS-SPB information is also used to keep current a local table 290 indexed by I-SID to indicate the associated B-VID for processing of 291 frames received from EVPN. When an I-SID is associated with more than 292 one B-VID, only one entry is allowed in the table. Rules for 293 preventing this are out of scope of this memo. 295 4.4. Control plane interworking EVPN to ISIS-SPB 297 When a PE receives a BGP NLRI that has new information, it checks if 298 it is the elected DF to communicate this information into ISIS-SPB by 299 checking if the I-SID in the Ethernet Tag ID locally maps to the B- 300 VID it is an elected DF for. Note that if no BEBs in the SPB island 301 have advertised any interest in the I-SID, it will not be associated 302 with any B-VID locally, and therefore not of interest. If the I-SID 303 is of local interest to the SPBM island and the PE is the DF for the 304 B-VID that the I-SID is locally mapped to, a SPBM service identifier 305 and unicast address sub-TLV is constructed/updated for advertisement 306 into ISIS-SPB. 308 The NLRI information advertised into ISIS-SPB is also used to locally 309 populate a forwarding table indexed by B-MAC+I-SID that points to the 310 label stack to impose on the SPBM frame. The bottom label in the 311 stack being that obtained from the NLRI. 313 4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to EVPN 315 When an PE receives a frame from the SPBM island in a B-VID for which 316 it is a DF, it looks up the B-MAC/I-SID information to determine the 317 label stack to be added to the frame for forwarding in the EVPN. The 318 PE strips the B-VID information from the frame, adds the label 319 information to the frame and forwards the resulting MPLS packet. 321 4.6. Data plane Interworking EVPN to 802.1aq SPBM island 323 When a PE receives a packet from the EVPN it can infer the B-VID to 324 overwrite in the SPBM frame from the I-SID or by other means (such as 325 via the bottom label in the MPLS stack). 327 If the frame has a local multicast destination address (DA), it 328 overwrites the SPSourceID in the frame with the local SPSourceID. 330 4.7. Data plane interworking EVPN to 802.1ah PBB-PE 332 A PBB-PE actually has no attached PBBN nor concept of B-VID so no 333 frame processing is required. 335 A PBB-PE is required to accept SPBM encoded multicast DAs as if they 336 were 802.1ah encoded multicast DAs. The only information of interest 337 being that it is a multicast frame, and the I-SID encoded in the 338 lower 24 bits. 340 4.8. Multicast Support 342 Within a PBBN domain Ethernet Unicast and Multicast end services are 343 supported. PBB can tunnel multicast traffic in Unicast PBB frames 344 when using head end replication. This is the only form of multicast 345 traffic interworking supported by this document. Native PBB multicast 346 forwarding over EVPN, PE replication or optimizing PBB multicast 347 across the EVPN is not addressed by this memo. 349 5. Other Aspects 351 5.1. Transit 353 Any PE that does not need to participate in the tandem calculations 354 at the B-MAC layer can use the IS-IS overload bit to exclude SPBM 355 tandem paths and behave as pure interworking platform. 357 6. Security Considerations 359 Security issues associated with incorrect interconnect of customer 360 LANs cannot be directly addressed by implementations of this 361 document, as it requires misconfiguration in the Shortest Path 362 Bridging domains. The identifiers so administered have global 363 significance to the larger system. They are relayed transparently by 364 EVPN and only policed in the SPBM domains. Therefore care is required 365 in synchronization of identifiers that need to be common for inter- 366 domain operation. 368 There are only two identifiers unique to this solution provisioned at 369 an SPBM-PE at service turn up; the route target and the ESI. The ESI 370 needs to be unique and common to all SPBM-PEs connected to a common 371 SPBM network, or PBBN else portions of the overall network will not 372 share reachability (EVPN will assume that separate networks are 373 interconnected by SPBM). Security issues exist when SPBM domains are 374 incorrectly cross connected together via EVPN which will result in 375 back-holing or incorrect delivery of data with associated privacy 376 issues. This could be achieved by provisioning the incorrect RT value 377 at an SPBM-PE or associating the RT with the wrong interface. This 378 can be avoided via care in route target provisioning at SPBM-PEs for 379 service adds and changes. 381 The potentially most destructive behavior of the overall system would 382 be frequent changes to the DF elections for a given ESI. This would 383 require SPBM-PEs to frequently flap in the form of either the node 384 continuously resetting or links flapping in a form that keeps 385 severing and re-connecting the SPBM-PE from either the IP/MPLS 386 network or the attached SPBM-Network. Either of these scenarios would 387 result in significant control plane traffic as DF associated 388 information was advertised and withdrawn from both the SPBM and BGP 389 control planes. Dual homing of SPBM-PEs on both networks would 390 minimize the likelihood of this scenario occurring. 392 The issues associated with securing the BGP control plane 393 (independent of this particular memo) are reflected in the security 394 considerations section of [RFC4761]. 396 7. IANA Considerations 398 No IANA assignments are required by this document. 400 8. Acknowledgments 402 The authors would like to thank Peter Ashwood-Smith, Martin Julien 403 and Janos Farkas for their detailed review of this draft. 405 9. References 407 9.1. Normative References 409 [RFC2119] 410 Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC4761] Kompella (ed.), "Virtual Private LAN Service (VPLS) Using 414 BGP for Auto-Discovery and Signaling", IETF RFC 4761, 415 January 2007 417 [RFC6329] 418 Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq 419 Shortest Path Bridging", IETF RFC 6329, April 2012 421 [RFC7432] 422 Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF RFC 423 7432, February 2015 425 9.2. Informative References 427 [802.1aq] 428 802.1aq (2012), IEEE Standard for Local and 429 Metropolitan Area Networks: Bridges and Virtual Bridged 430 Local Area Networks - Amendment 9: Shortest Path 431 Bridging 433 [PBB-EVPN] Sajassi et.al. "PBB E-VPN", IETF work in progress, 434 draft-ietf-l2vpn-pbb-evpn-10, May 2015 436 [802.1Q] 437 802.1Q (2011), IEEE Standard for Local and metropolitan 438 area networks--Media Access Control (MAC) Bridges and 439 Virtual Bridged Local Area Networks 441 10. Authors' Addresses 443 Dave Allan (editor) 444 Ericsson 445 300 Holger Way 446 San Jose, CA 95134 447 USA 448 Email: david.i.allan@ericsson.com 450 Jeff Tantsura 451 Ericsson 452 300 Holger Way 453 San Jose, CA 95134 454 USA 455 Email: jeff.tantsura@ericsson.com 457 Don Fedyk 458 Hewlett-Packard 459 153 Tayor Street 460 Littleton, MA, 01460 461 USA 462 don.fedyk@hp.com 464 Ali Sajassi 465 Cisco 466 170 West Tasman Drive 467 San Jose, CA 95134, 468 USA 469 Email: sajassi@cisco.com