idnits 2.17.1 draft-allan-l2vpn-spbm-evpn-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2013) is 3936 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) == Unused Reference: '3' is defined on line 367, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 373, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 379, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 383, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-02 == Outdated reference: A later version (-03) exists of draft-allan-l2vpn-mldp-evpn-01 == Outdated reference: A later version (-10) exists of draft-ietf-l2vpn-pbb-evpn-04 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN Working Group Dave Allan, Jeff Tantsura 2 Internet Draft Ericsson 3 Intended status: Standards Track Don Fedyk 4 Expires: January 2014 Alcatel-Lucent 5 Ali Sajassi 6 Cisco 8 July 2013 10 802.1aq Support over EVPN 11 draft-allan-l2vpn-spbm-evpn-04 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 in a way that permits 18 operational isolation of each Ethernet network subtending an EVPN 19 core while supporting full interworking between the different 20 variations of Ethernet operation. 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 January 2014. 46 Copyright and License Notice 47 Copyright (c) 2013 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. Changes since previous version.................................4 68 4. Solution Overview..............................................4 69 5. Elements of Procedure..........................................5 70 5.1. PE Configuration.............................................5 71 5.2. DF Election..................................................6 72 5.3. Control plane interworking ISIS-SPB to EVPN..................6 73 5.4. Control plane interworking EVPN to ISIS-SPB..................7 74 5.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to 75 EVPN..............................................................8 76 5.6. Data plane Interworking EVPN to 802.1aq SPBM island..........8 77 5.7. Data plane interworking EVPN to 802.1ah PBB-PE...............8 78 5.8. Multicast Support............................................8 79 6. Other Aspects..................................................8 80 6.1. Flow Ordering................................................8 81 6.2. Transit......................................................9 82 7. Acknowledgements...............................................9 83 8. Security Considerations........................................9 84 9. IANA Considerations............................................9 85 10. References....................................................9 86 10.1. Normative References........................................9 87 10.2. Informative References......................................9 88 11. Authors' Addresses...........................................10 90 1. Introduction 92 This document describes how Ethernet Shortest Path Bridging MAC mode 93 (802.1aq) along with PBB-PEs and PBBNs (802.1ah) can be supported by 94 EVPN such that each island is operationally isolated while providing 95 full L2 connectivity between them. Each island can use its own 96 control plane instance and multi-pathing design, be it multiple ECT 97 sets, or multiple spanning trees. 99 The intention is to permit both past, current and emerging future 100 versions of Ethernet to be seamlessly integrated to permit large 101 scale, geographically diverse numbers of Ethernet end systems to be 102 fully supported with EVPN as the unifying agent. 104 1.1. Authors 106 David Allan, Jeff Tantsura, Don Fedyk, Ali Sajassi 108 1.2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC2119 [1]. 114 2. Conventions used in this document 116 2.1. Terminology 118 BCB: Backbone Core Bridge 119 BEB: Backbone Edge Bridge 120 BU: Broadcast/Unknown 121 B-MAC: Backbone MAC Address 122 B-VID: Backbone VLAN ID 123 CE: Customer Edge 124 C-MAC: Customer/Client MAC Address 125 DF: Designated Forwarder 126 ESI: Ethernet Segment Identifier 127 EVPN: Ethernet VPN 128 ISIS-SPB: IS-IS as extended for SPB 129 I-SID: I-Component Service ID 130 MP2MP: Multipoint to Multipoint 131 MVPN: Multicast VPN 132 NLRI: Network Layer Reachability Information 133 PBBN: Provider Backbone Bridged Network 134 PBB-PE: Co located BEB and PE 135 PE: provider edge 136 P2MP: Point to Multipoint 137 P2P: Point to Point 138 RD: Route Distinguisher 139 SPB: Shortest path bridging 140 SPBM: Shortest path bridging MAC mode 142 3. Changes since previous version 144 1) Removal of reference to 802.1Qbp. This will be addressed in 145 separate document. 147 2) Determining ESI value exclusively requires configuration. This was 148 an open item in previous drafts. 150 4. Solution Overview 152 The EVPN solution for 802.1aq SPBM incorporates control plane 153 interworking in the PE to map ISIS-SPB [2] information elements into the 154 EVPN NLRI information and vice versa. This requires each PE to act both 155 as an EVPN BGP speaker and as an ISIS-SPB edge node. Associated with 156 this are procedures for configuring the forwarding operations of the PE 157 such that an arbitrary number of EVPN subtending SPBM islands may be 158 interconnected without any topological or multipathing dependencies. 159 This model also permits PBB-PEs as defined in draft-l2vpn-pbb-evpn-02[8] 160 to seamlessly communicate with the SPB islands. 162 +--------------+ 163 | | 164 | | 165 +-----+ +----+ | | +----+ +---+ 166 | |-----|SPBM| | | |PBB |---|CE2| 167 |SPBM | |PE1 | | IP/MPLS | |PE1 | +---+ 168 +---+ |NTWK1| +----+ | Network | +----+ 169 |CE1|-| | | | 170 +---+ | | +----+ | | 171 | |-----|SPBM| | | +----+ +-----+ 172 +-----+ |PE2 | | | |SPBM| |SPBM | +---+ 173 +----+ | | |PE3 |---|NTWK2|-|CE3| 174 +--------------+ +----+ +-----+ +---+ 175 Figure 1: PBB and SPBM EVPN Network 177 Each EVPN is identified by a route target. The route target identifies 178 the set of SPBM islands and BEB-PEs that are allowed to communicate. 179 Each SPBM island is administered to have an associated Ethernet Segment 180 ID (ESI) associated with it. This manifests itself as a set of Ethernet 181 segments, where each Ethernet segment ID is unique within the route 182 target. 183 BGP acts as a common repository of the I-SID attachment points for the 184 set of subtending PEs/SPBM islands. This is in the form of B-MAC 185 address/I-SID/Tx-Rx-attribute tuples. BGP leaks I-SID information into 186 each SPBM island on the basis of locally registered interest. If an SPBM 187 island has no BEBs registering interest in an I-SID, information about 188 that I-SID from other SPBM islands, PBB-PEs or PBBNs will not be leaked 189 into the local ISIS-SPB routing system. 190 For each B-VID in an SPBM island, a single SPBM-PE is elected the 191 designated forwarder for the B-VID. An SPBM-PE may be a DF for more than 192 one B-VID. This is described further in section 4.2. The SPBM-PE 193 originates IS-IS advertisements as if it were an I-BEB or IB-BEB that 194 proxy for the other SPBM islands and PBB PEs in the EVPN defined by the 195 route target, but the PE typically will not actually host any I- 196 components. 197 An SPBM-PE that is a DF for a B-VID strips the B-VID tag information 198 from frames relayed towards the EVPN. The DF also inserts the 199 appropriate B-VID tag information into frames relayed towards the SPBM 200 island on the basis of the local I-SID/B-VID bindings advertised in 201 ISIS-SPB. 203 5. Elements of Procedure 205 5.1. PE Configuration 207 At SPBM island commissioning a PE is configured with: 209 1) The route target for the service instance. Where a route target 210 is defined as identifying the set of SPBM islands, PBBNs and PBB- 211 PEs to be interconnected by the EVPN. 213 2) The unique ESI for the SPBM island. 215 And the following is configured as part of commissioning an ISIS-SPB 216 node: 218 1) A Shortest Path Source ID (SPSourceID) used for algorithmic 219 construction of multicast DA addresses. Note this is required for 220 SPBM BEBs independent of the EVPN operation. 222 2) The set of VLANs (identified by B-VIDs) used in the SPBM island 223 and multi-pathing algorithm IDs to use. The B-VID may be 224 different in different domains and may be removed as carried over 225 the IP/MPLS network. 227 A type-1 Route Distinguisher (RD) for the node can be auto-derived. 228 This will be described in a future version of the document. 230 5.2. DF Election 232 PEs self appoint in the role of DF for a B-VID for a given SPBM 233 island. The procedure used is as per section 9.5 of draft-ietf-l2vpn- 234 evpn-03[4] "DF election". 236 5.3. Control plane interworking ISIS-SPB to EVPN 238 When a PE receives an SPBM service identifier and unicast address 239 sub-TLV as part of an ISIS-SPB MT capability TLV it checks if it is 240 the DF for the B-VID in the sub-TLV. 242 If it is the DF, and there is new or changed information then a MAC 243 advertisement route NLRI is created for each new I-SID in the sub- 244 TLV. 246 - the Route Distinguisher (RD) is set to that of the PE. 248 - the ESI is that of the SPBM island. 250 - the Ethernet tag ID contains the I-SID (including the Tx/Rx 251 attributes). The encoding of I-SID information is as per figure 2. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |T|R| Reserved | I-SID | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 2: I-SID encoding in the Ethernet tag-ID field 261 - the MAC address from the sub-TLV 263 - an MPLS label 265 Similarly in the scenario where a PE became elected DF for a B-VID in 266 an operating network, the IS-IS database would be processed in order 267 to construct the NLRI information associated with the new role of the 268 PE. 270 If the BGP database has NLRI information for the I-SID, and this is 271 the first instance of registration of interest in the I-SID from the 272 SPB island, the NLRI information with that tag is processed to 273 construct an updated set of SPBM service identifier and unicast 274 address sub-TLVs to be advertised by the PE. 276 The ISIS-SPB information is also used to keep a local table indexed 277 by I-SID current to indicate the associated B-VID for processing of 278 frames received from EVPN. When an I-SID is associated with more than 279 one B-VID, only one entry is allowed in the table. Rules for this 280 will be in a future version of the document. 282 5.4. Control plane interworking EVPN to ISIS-SPB 284 When a PE receives a BGP NLRI that has new information, it checks if 285 the I-SID in the Ethernet Tag ID locally maps to the B-VID that are 286 an elected DF. Note that if no BEBs in the SPB island have advertised 287 any interest in the I-SID, it will not be associated with any B-VID 288 locally, and therefore not of interest. If the I-SID is of local 289 interest to the SPBM island and the PE is the DF for the B-VID that 290 that I-SID is locally mapped to, a SPBM service identifier and 291 unicast address sub-TLV is constructed/updated for advertisement into 292 ISIS-SPB. 294 The NLRI information advertised into ISIS-SPB is also used to locally 295 populate a forwarding table indexed by B-MAC+I-SID that points to the 296 label stack associated with the SPBM frame. The bottom label in the 297 stack being that offered in the NLRI. 299 5.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to EVPN 301 When an PE receives a frame from the SPBM island in a B-VID for which 302 it is a DF, it looks up the B-MAC/I-SID information to determine the 303 label stack to be added to the frame for forwarding in the EVPN. The 304 PE strips the B-VID information from the frame, adds the label 305 information to the frame and forwards the resulting MPLS packet. 307 5.6. Data plane Interworking EVPN to 802.1aq SPBM island 309 When a PE receives a packet from the EVPN it may infer the B-VID to 310 overwrite in the SPBM frame from the I-SID or by other means (such as 311 via the bottom label in the MPLS stack). 313 If the frame has a local multicast DA, it overwrites the SPsourceID 314 in the frame with the local SPsourceID. 316 5.7. Data plane interworking EVPN to 802.1ah PBB-PE 318 A PBB-PE actually has no subtending PBBN nor concept of B-VID so no 319 frame processing is required. 321 A PBB-PE is required to accept SPBM encoded multicast DAs as if they 322 were 802.1ah encoded multicast DAs. The only information of interest 323 being that it is a multicast frame, and the I-SID encoded in the 324 lower 24 bits. 326 5.8. Multicast Support 328 Refer to "mLDP extensions for integrating EVPN and multicast"[5]. 330 6. Other Aspects 332 6.1. Flow Ordering 334 When per I-SID multicast is implemented via PE replication, a stable 335 network will preserve frame ordering between known unicast and BU 336 traffic (e.g. race conditions will not exist). This cannot be 337 guaranteed when multicast is used in the EVPN. 339 6.2. Transit 341 Any PE that does not need to participate in the tandem calculations 342 may use the IS-IS overload bit to exclude SPBM tandem paths and 343 behave as pure interworking platform (I-BEB). 344 7. Acknowledgements 346 The authors would like to thank Peter Ashwood-Smith, Martin Julien 347 and Janos Farkas for their detailed review of this draft. 349 8. Security Considerations 351 For a future version of this document. 353 9. IANA Considerations 355 For a future version of this document. 357 10. References 359 10.1. Normative References 361 [1] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [2] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq 365 Shortest Path Bridging", IETF RFC 6329, April 2012 367 [3] Rosen et.al., "BGP/MPLS IP Virtual Private Networks 368 (VPNs)", IETF RFC 4364, February 2006 370 [4] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF work 371 in progress, draft-ietf-l2vpn-evpn-02, October 2012 373 [5] Allan et.al. "mLDP extensions for integrating EVPN and 374 multicast", IETF work in progress draft-allan-l2vpn-mldp- 375 evpn-01, May 2013 377 10.2. Informative References 379 [6] 802.1aq(2012) IEEE Standard for Local and Metropolitan 380 Area Networks: Bridges and Virtual Bridged Local Area 381 Networks - Amendment 9: Shortest Path Bridging 383 [7] Sajassi et.al. "PBB E-VPN", IETF work in progress, draft- 384 ietf-l2vpn-pbb-evpn-04, February 2013 386 [8] 802.1Q (2011) IEEE Standard for Local and metropolitan 387 area networks--Media Access Control (MAC) Bridges and 388 Virtual Bridged Local Area Networks 390 11. Authors' Addresses 392 Dave Allan (editor) 393 Ericsson 394 300 Holger Way 395 San Jose, CA 95134 396 USA 397 Email: david.i.allan@ericsson.com 399 Jeff Tantsura 400 Ericsson 401 300 Holger Way 402 San Jose, CA 95134 403 Email: jeff.tantsura@ericsson.com 405 Don Fedyk 406 Alcatel-Lucent 407 Groton, MA 01450 408 USA 409 EMail: Donald.Fedyk@alcatel-lucent.com 411 Ali Sajassi 412 Cisco 413 170 West Tasman Drive 414 San Jose, CA 95134, US 415 Email: sajassi@cisco.com