idnits 2.17.1 draft-sajassi-bess-evpn-vpws-fxc-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 112 has weird spacing: '...cluding singl...' == Line 253 has weird spacing: '...ed, the lower...' -- The document date (July 6, 2016) is 2851 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) == Missing Reference: 'EVPN-VPWS' is mentioned on line 415, but not defined == Missing Reference: 'RFC2119' is mentioned on line 123, but not defined == Missing Reference: 'EVPN-Overlay' is mentioned on line 340, but not defined == Unused Reference: 'EVPN-IRB' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'EVPN-PREFIX' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC6718' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'RFC6870' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'BGP-PIC' is defined on line 471, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-00 == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-prefix-advertisement-02 ** Downref: Normative reference to an Informational RFC: RFC 6718 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup A. Sajassi 3 INTERNET-DRAFT P. Brissette 4 Intended Status: Standards Track Cisco 5 J. Uttaro 6 ATT 7 J. Drake 8 W. Lin 9 Juniper 10 S. Boutros 11 VMWare 12 J. Rabadan 13 Nokia 15 Expires: January 6, 2016 July 6, 2016 17 EVPN VPWS Flexible Cross-Connect Service 18 draft-sajassi-bess-evpn-vpws-fxc-00.txt 20 Abstract 22 This document describes a new EVPN VPWS VLAN-aware bundle service 23 type referred to as flexible cross-connect service. It also describes 24 the rational for this new service as well as a solution to deliver 25 such service. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2 Conflicting Requirements . . . . . . . . . . . . . . . . . . . . 4 68 4 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1 VLAN-Unaware Flexible Xconnect - Single-Homing . . . . . . . 7 70 4.2 VLAN-Aware Flexible Xconnect . . . . . . . . . . . . . . . . 8 71 4.3 VLAN-Unaware Flexible Xconnect - Multi-Homing . . . . . . . 8 72 5. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2 EVPN VPWS service Failure . . . . . . . . . . . . . . . . . 10 75 6.2 Attachment Circuit Failure . . . . . . . . . . . . . . . . . 10 76 6.3 PE Port Failure . . . . . . . . . . . . . . . . . . . . . . 10 77 6.4 PE Node Failure . . . . . . . . . . . . . . . . . . . . . . 10 78 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 79 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 80 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9.1 Normative References . . . . . . . . . . . . . . . . . . . 11 82 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1 Introduction 87 [EVPN-VPWS] describes a solution to deliver P2P services using BGP 88 constructs defined in [RFC7432]. It delivers this P2P service between 89 a pair of Attachment Circuits (ACs), where an AC can designate on a 90 PE a port, a VLAN on a port, or a group of VLANs on a port. It also 91 leverages multi-homing and fast convergence capabilities of [RFC7432] 92 in delivering these VPWS services. Multi-homing capabilities include 93 the support of single-active and all-active redundancy mode and fast 94 convergence is provided using "mass withdraw" message in control- 95 plane and fast protection switching using prefix independent 96 convergence in data-plane upon node or link failure. Furthermore, the 97 use of EVPN BGP constructs eliminates the need for multi-segment PW 98 auto-discovery and signaling if the VPWS service need to span across 99 multiple ASes. 101 Some service providers have very large number of ACs (in millions) 102 that require tag manipulation (e.g., VLAN translation) to be back 103 hauled across their MPLS/IP network. These service providers want to 104 multiplex a large number of ACs across several physical interfaces 105 (e.g., several Ethernet Segments) onto a single VPWS service tunnel 106 in order to a) reduce number of EVPN service labels associated with 107 VPWS service tunnels and thus the associated OAM monitoring, and b) 108 reduce EVPN BGP signaling (e.g., not to signal each AC as it is the 109 case in [EVPN-VPWS]). 111 These service provider want the above functionality without 112 scarifying any of the capabilities of [EVPN-VPWS] including single- 113 active and all-active multi-homing, and fast convergence. 115 This document presents a solution based on extensions to [EVPN-VPWS] 116 to meet the above requirements. 118 1.1 Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 MAC: Media Access Control 126 MPLS: Multi Protocol Label Switching 128 OAM: Operations, Administration and Maintenance 130 PE: Provide Edge Node 131 CE: Customer Edge device e.g., host or router or switch 133 EVPL: Ethernet Virtual Private Line 135 EPL: Ethernet Private Line 137 ES: Ethernet Segment 139 VPWS: Virtual private wire service 141 EVI: EVPN Instance 143 VPWS Service Tunnel: It is represented by a pair of EVPN service 144 labels associated with a pair of endpoints. Each label is downstream 145 assigned and advertised by the disposition PE through an Ethernet A-D 146 per-EVI route. The downstream label identifies the endpoint on the 147 disposition PE. A VPWS service tunnel can be associated with many 148 VPWS service identifiers for VLAN-aware VPWS service where each 149 identifier is a normalized VID. 151 Single-Active Mode: When a device or a network is multi-homed to two 152 or more PEs and when only a single PE in such redundancy group can 153 forward traffic to/from the multi-homed device or network for a given 154 VLAN, then such multi-homing or redundancy is referred to as "Single- 155 Active". 157 All-Active: When a device is multi-homed to two or more PEs and when 158 all PEs in such redundancy group can forward traffic to/from the 159 multi-homed device for a given VLAN, then such multi-homing or 160 redundancy is referred to as "All-Active". 162 2 Conflicting Requirements 164 Two of the main motivations for service providers seeking a new 165 solution are: 1) to reduce number of VPWS service tunnels by muxing 166 large number of ACs across different physical interfaces instead of 167 having one VPWS service tunnel per AC, and 2) to reduce the signaling 168 of ACs as much as possible. Besides these two requirements, they also 169 want multi-homing and fast convergence capabilities of [EVPN-VPWS]. 171 In [EVPN-VPWS], a PE signals an AC indirectly by first associating 172 that AC to a VPWS service tunnel (e.g., a VPWS service instance) and 173 then signaling the VPWS service tunnel via a per-EVI Ethernet AD 174 route with Ethernet Tag field set to a 24-bit VPWS service instance 175 identifier (which is unique within the EVI) and ESI field set to a 176 10-octet identifier of the Ethernet Segment corresponding to that AC. 177 Therefore, a PE device that receives such EVPN routes, can associate 178 the VPWS service tunnel to the remote Ethernet Segment, and when the 179 remote ES fails and the PE receives the "mass withdraw" message 180 associated with the failed ES per [RFC7432], it can update its BGP 181 path list for that VPWS service tunnel quickly and achieve fast 182 convergence for multi-homing scenarios. Even if fast convergence were 183 not needed, there would still be a need for signaling each AC failure 184 (via its corresponding VPWS service tunnel) associated with the 185 failed ES, so that the BGP path list for each of them gets updated 186 accordingly and the packets are sent to backup PE (in case of single- 187 active multi-homing) or to other PEs in the redundancy group (in case 188 of all-active multi-homing). In absence of updating the BGP path 189 list, the traffic for that VPWS service tunnel will be black-holed. 191 When a single VPWS service tunnel multiplexes many ACs across number 192 of Ethernet Segments (number of physical interfaces) and the ACs are 193 not signaled via EVPN BGP to remote PE devices, then the remote PE 194 devices neither know the association of the received Ethernet Segment 195 to these ACs (and in turn to their local ACs) nor they know the 196 association of the VPWS service tunnel (e.g., EVPN service label) to 197 the far-end ACs - i.e, the remote PEs only know the association of 198 their local ACs to the VPWS service tunnel but not the far-end ACs. 199 Thus upon a connectivity failure to the ES, they don't know how to 200 redirect traffic via another multi-homing PE to that ES. In other 201 words, even if an ES failure is signaled via EVPN to the remote PE 202 devices, they don't know what to do with such message because they 203 don't know the association among the ES, their ACs, and the VPWS 204 service tunnel. 206 In order to address this issue when multiplexing large number of ACs 207 onto a single VPWS service tunnel, two mechanisms are devised: one to 208 support VPWS services between two single-homed endpoints and another 209 one to support VPWS services where one of the endpoints is multi- 210 homed. An endpoint can be an AC, MAC-VRF, IP-VRF, global table, or 211 etc. 213 For single-homed endpoints, it is OK not to signal each AC in BGP 214 because upon connection failure to the ES, there is no alternative 215 path to that endpoint. However, the ramification for not signaling an 216 AC failure is that the traffic destined to the failed AC, is sent 217 over MPLS/IP core and then gets discarded at the destination PE - 218 i.e., it can waste network resources. However, when there is a 219 connection failure, the application layer will eventually stop 220 sending traffic and thus this wastage of network resources should be 221 transient. Section 4.1 describes a solution for such single-homing 222 VPWS service which is called VLAN-Unaware flexible cross-connect 223 service. 225 For VPWS services where one of the endpoints is multi-homed, there 226 are two options: 228 1) to signal each AC via BGP so that the path list can be updated 229 upon a failure that impacts those ACs. This solution is described in 230 section 4.2 and it is called VLAN-Aware flexible cross-connect 231 service. 233 2) to bundle several ACs on an ES together per destination ES (or PE) 234 and associated such bundle to a single VPWS service tunnel. This is 235 similar to VLAN-bundle service interface described in [EVPN-VPWS]. 236 This solution is described in section 4.3. 238 4 Solution 240 This section describes a solution for providing a new VPWS service 241 between two PE devices where a large number of ACs (e.g., VLANs) that 242 span across many physical interfaces on each PE are multiplex onto a 243 single P2P EVPN LSP tunnel. Since multiplexing is done across several 244 physical interfaces, there can be overlapping VLAN IDs across these 245 interfaces; therefore, in such scenarios, the VLAN IDs (VIDs) MUST be 246 translated into unique VIDs to avoid collision. Furthermore, if the 247 number of VLANs that are getting multiplex onto a single VPWS service 248 tunnel, exceed 4K, then a single tag to double tag translation MUST 249 be performed. This translation of VIDs into unique VIDs (either 250 single or double) is referred to as "VID normalization". When single 251 normalized VID is used, the lower 12-bit of Ethernet tag field in 252 EVPN routes is set to that VID and when double normalized VID is 253 used, the lower 12-bit of Ethernet tag field is set to inner VID and 254 the higher 12-bit is set to the outer VID. 256 Since there is only a single P2P EVPN LSP tunnel associated with many 257 normalized VIDs (either single or double), MPLS lookup at the 258 disposition PE is no longer sufficient to forward the packet to the 259 right egress endpoint/interface. Therefore, in addition to an EVPN 260 label lookup corresponding to the VPWS service tunnel, a VID lookup 261 (either single or double) is also required. On the disposition PE, 262 one can think of the lookup of EVPN label results in identification 263 of a VID table, and the lookup of normalized VID(s) in that table, 264 results in identification of egress endpoint/interface. The tag 265 manipulation (translation from normalized VID(s) to local VID) can be 266 performed either as part of the VID table lookup or at the egress 267 interface itself. 269 Since VID lookup (single or double) needs to be performed at the 270 disposition PE, then VID normalization MUST be performed prior to the 271 MPLS encapsulation on the ingress PE. This requires that both 272 imposition and disposition PE devices be capable of VLAN tag 273 manipulation, such as re-write (single or double), addition, deletion 274 (single or double), at their endpoints (e.g., their physical 275 interfaces). 277 4.1 VLAN-Unaware Flexible Xconnect - Single-Homing 279 In this mode of operation, many ACs across several Ethernet Segments 280 are multiplex into a single P2P EVPN LSP tunnel represented by a 281 single VPWS service ID. VLAN-Unaware mode for this solution means 282 that VLANs (normalized VIDs) are not signaled via EVPN BGP among the 283 PEs. In this solution, there is only a single P2P EVPN LSP tunnel 284 between a pair of PEs for all their ACs that are single-homed. 286 As discussed previously, since the VPWS service tunnel is used to 287 multiplex ACs across different ES's (e.g., physical interfaces), the 288 EVPN label alone is not sufficient for proper forwarding of the 289 received packets (over MPLS/IP network) to egress interfaces. 290 Therefore, normalized VID lookup is required in the disposition 291 direction to forward packets to their proper egress end-points/ 292 interfaces - i.e., the EVPN label lookup identifies a VID table and 293 subsequently, the normalized VID lookup in that table, identifies the 294 egress interface. 296 In this solution, on each PE, the single-homing ACs represented by 297 their normalized VIDs are associated with a single VPWS service 298 tunnel (in a given EVI). The EVPN route that gets generated is an 299 EVPN Ethernet AD per EVI route with ESI=0, Ethernet Tag field set to 300 VPWS service instance ID, MPLS label field set to dynamically 301 generated EVPN service label representing the EVPN VPWS service. This 302 route is sent with an RT representing the EVI. This RT can be auto- 303 generated from the EVI per section 5.1.2.1 of [EVPN-Overlay]. 304 Furthermore, this route is sent with the EVPN Layer-2 Extended 305 Community defined in section 3.1 of [EVPN-VPWS] with two new flags 306 (defined in section 5) that indicate: 1) this VPWS service tunnel is 307 for VLAN-unaware Flexible Cross-Connect, and 2) normalized VID type 308 (single versus double). The receiving PE uses these new flags for 309 consistency check and MAY generate an alarm if it detects 310 inconsistency but doesn't bring down the VPWS service because such 311 inconsistency may be intentional - i.e., one side is configured for 312 VLAN-aware VPWS service and another side is configured for VLAN- 313 unaware VPWS service. 315 It should be noted that in this mode of operation, a single Ethernet 316 AD route is sent upon configuration of the first AC (ie, normalized 317 VID). Later, when additional ACs are configured and associated with 318 this EVPN VPWS service tunnel, the PE does not advertise any 319 additional EVPN BGP routes. The PE only associates locally these ACs 320 with the already created VPWS service tunnel. 322 4.2 VLAN-Aware Flexible Xconnect 324 In this mode of operation, just as the VLAN-unaware mode, many 325 normalized VIDs (ACs) across several different ES's/interfaces are 326 multiplexed into a single P2P EVPN LSP tunnel; however, this single 327 tunnel is represented by many VPWS service IDs (one per normalized 328 VID) and these normalized VIDs are signaled using EVPN BGP. 330 In this solution, on each PE, the multi-homing ACs represented by 331 their normalized VIDs are configured with a single EVI. There is no 332 need to configure VPWS service instance ID in here. A VPWS service 333 instance ID is derived automatically from each normalized VID. For 334 each normalized VID on each ES, the PE generates an EVPN Ethernet AD 335 per EVI route where ESI field represents the ES ID, the Ethernet Tag 336 field is set to the normalized VID, MPLS label field is set to 337 dynamically generated EVPN label representing the P2P EVPN LSP 338 tunnel. This route is sent with an RT representing the EVI. As 339 before, this RT can be auto-generated from the EVI per section 340 5.1.2.1 of [EVPN-Overlay]. Furthermore, this route is sent with the 341 EVPN Layer-2 Extended Community defined in section 3.1 of [EVPN-VPWS] 342 with two new flags (defined in section 5) that indicate: 1) this VPWS 343 service tunnel is for VLAN-aware Flexible Cross-Connect, and 2) 344 normalized VID type (single versus double). The receiving PE uses 345 these new flags for consistency check and MAY generate an alarm if it 346 detects inconsistency but doesn't bring down the VPWS service because 347 such inconsistency may be intentional - i.e., one side is configured 348 for VLAN-aware VPWS service and another side is configured for VLAN- 349 unaware VPWS service. 351 It should be noted that in this mode of operation, the PE sends a 352 single Ethernet AD route for each AC that is configured - i.e., each 353 normalized VID that is configured per ES results in generation of an 354 EVPN Ethernet AD per EVI. 356 This mode of operation provides automatic cross checking of 357 normalized VIDs used for EVPL services because these VIDs are 358 signaled in EVPN BGP. For example, if the same normalized VID is 359 configured on three PE devices (instead of two) for the same EVI, 360 then when a PE receives the second EVPN Eth-AD per EVI route, it 361 generates an error message unless the two EVPN Eth-AD per EVI routes 362 include the same ESI. Such cross-checking is not feasible in VLAN- 363 unaware FXC because the normalized VIDs are not signaled. 365 4.3 VLAN-Unaware Flexible Xconnect - Multi-Homing 366 In this mode of operation, a group of normalized VIDs (ACs) on a 367 single ES that are destined to a single endpoint/interface are 368 multiplexed into a single P2P EVPN LSP tunnel represented by a single 369 VPWS service ID. This mode of operation is the same as VLAN-bundle 370 service interface of [EVPN-VPWS] except for the fact that VIDs on 371 Ethernet frames are normalized before getting sent over the LSP 372 tunnel. 374 In the previous two modes of operation, only a single EVPN VPWS 375 service tunnel is needed per pair of PEs. However, in this mode of 376 operation, there can be lot more service tunnels per pair of PEs - 377 i.e, there is one tunnel per group of VIDs per pair of PEs and there 378 can be many groups between a pair of PEs, thus resulting in many EVPN 379 service tunnels. 381 5. BGP Extensions 383 This draft uses the EVPN Layer-2 attribute extended community defined 384 in [EVPN-VPWS] with two additional flags added to this EC as 385 described below. This EC is to be advertised with Ethernet A-D per 386 EVI route per section 4. 388 +------------------------------------+ 389 | Type(0x06)/Sub-type(TBD)(2 octet) | 390 +------------------------------------+ 391 | Control Flags (2 octets) | 392 +------------------------------------+ 393 | L2 MTU (2 octets) | 394 +------------------------------------+ 395 | Reserved (2 octets) | 396 +------------------------------------+ 398 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | MBZ | V | M |C|P|B| (MBZ = MUST Be Zero) 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 The following bits in the Control Flags are defined; the remaining 404 bits MUST be set to zero when sending and MUST be ignored when 405 receiving this community. 407 Name Meaning 409 B,P,C per definition in [EVPN-VPWS] 411 M 00 mode of operation as defined in [EVPN-VPWS] 412 01 VLAN-aware FXC 413 10 VLAN-unaware FXC 415 V 00 operating per [EVPN-VPWS] 416 01 single-VID normalization 417 10 double-VID normalization 419 The M and V fields are OPTIONAL on transmission and ignored at 420 reception for forwarding purposes. They are used for error 421 notifications. 423 6 Failure Scenarios 425 6.2 EVPN VPWS service Failure 427 The failure detection of an EVPN VPWS service can be performed via 428 OAM mechanisms such as VCCV-BFD and upon such failure detection, the 429 switch over procedure to the backup S-PE is the same as the one 430 described above. 432 6.2 Attachment Circuit Failure 434 6.3 PE Port Failure 436 6.4 PE Node Failure 438 In the case of PE node failure, the operation is similar to the steps 439 described above, albeit that EVPN route withdrawals are performed by 440 the Route Reflector instead of the PE. 442 7 Security Considerations 444 TBD. 446 8 IANA Considerations 447 TBD 449 9 References 451 9.1 Normative References 453 [RFC7432] Sajassi et al., "Ethernet VPN", RFC 7432, February 2015. 455 [EVPN-IRB] Sajassi et al., "Integrated Routing and Bridging in EVPN", 456 draft-ietf-bess-evpn-inter-subnet-forwarding-00, work in 457 progress, November 2014. 459 [EVPN-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", 460 draft-ietf-bess-evpn-prefix-advertisement-02, work in 461 progress, September 2015. 463 [RFC6718] Muley P., et al., "Pseudowire Redundancy", RFC 6718, August 464 2012. 466 [RFC6870] Muley P., et al., "Pseudowire Preferential Forwarding 467 Status Bit", RFC 6870, February 2013. 469 9.2 Informative References 471 [BGP-PIC] Bashandy A. et al., "BGP Prefix Independent Convergence", 472 draft-rtgwg-bgp-pic-02.txt, work in progress, October 473 2013. 475 Authors' Addresses 477 A. Sajassi 478 Cisco 479 EMail: sajassi@cisco.com 481 P. Brissette 482 Cisco 483 EMail: pbrisset@cisco.com 485 J. Uttaro 486 ATT 487 EMail: ju1738@att.com 489 J. Drake 490 Juniper 491 EMail: jdrake@juniper.net 493 S. Boutros 494 ATT 495 EMail: boutros.sami@gmail.com 497 W. Lin 498 Juniper 499 EMail: wlin@juniper.net 501 J. Rabadan 502 jorge.rabadan@nokia.com