idnits 2.17.1 draft-wang-bess-tpe-aided-spe-protection-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 (25 January 2021) is 1187 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: 'M1' is mentioned on line 292, but not defined == Missing Reference: 'M2' is mentioned on line 296, but not defined == Missing Reference: 'M3' is mentioned on line 302, but not defined == Unused Reference: 'I-D.heitz-bess-evpn-option-b' is defined on line 427, but no explicit reference was found in the text == Unused Reference: 'RFC8679' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-prefix-advertisement' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-inter-subnet-forwarding' is defined on line 484, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'C3' -- Possible downref: Non-RFC (?) normative reference: ref. 'C4' -- Possible downref: Non-RFC (?) normative reference: ref. 'C5' == Outdated reference: A later version (-15) exists of draft-ietf-bess-evpn-inter-subnet-forwarding-08 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Y. Wang 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track 25 January 2021 5 Expires: 29 July 2021 7 TPE-aided SPE-Protection 8 draft-wang-bess-tpe-aided-spe-protection-00 10 Abstract 12 MPLS EVPN SPEs cannot make use of anycast MPLS tunnel (whose egress 13 LSRs are two of these SPEs) because that the two SPEs will re-assign 14 different EVPN labels for the same EVPN prefix. It will be 15 complicated to static-configure EVPN label for each EVPN prefix. At 16 the same time, the TPEs should advertise specified signalling to do 17 egress node (TPE) protection. This document specifies a egress node 18 protection signalling from/among TPE nodes, and TPE (whether it is 19 egress-protected or not) can help the SPEs to do egress protection on 20 the basis of that signalling. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 29 July 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 2 57 2. Detailed Problem and Solution Requirement . . . . . . . . . . 4 58 2.1. Scenarios and Basic Settings . . . . . . . . . . . . . . 4 59 2.1.1. Exception Case for Next Hop Validating . . . . . . . 5 60 3. Control Plane Processing . . . . . . . . . . . . . . . . . . 5 61 3.1. Downstream-CLS ID Extended Community . . . . . . . . . . 5 62 3.2. TPE Procedures . . . . . . . . . . . . . . . . . . . . . 6 63 3.3. SPE Procedures . . . . . . . . . . . . . . . . . . . . . 7 64 3.3.1. Context-specific Label Swapping . . . . . . . . . . . 8 65 3.3.2. The Generating of Downstream-CLS ID EC on SPE . . . . 8 66 4. Protection Procedures . . . . . . . . . . . . . . . . . . . . 8 67 4.1. TPE Protection Procedures . . . . . . . . . . . . . . . . 8 68 4.2. SPE Protection Procedures . . . . . . . . . . . . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 8.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 In section 2.5 and section 4.4 of 80 [I-D.wang-bess-evpn-egress-protection], a MPLS egress protection 81 signalling is defined. The section 5.4 of 82 [I-D.wang-bess-evpn-context-label] uses the same signalling to do 83 egress protection for SPEs. This draft put the two scenarios 84 together, and describe all the unified signallings for the MPLS SPEs 85 and TPEs. 87 Note that the "egress" in "egress protection" means the egress LSR of 88 the underlay LSP, not the egress LSR of the overlay LSP. The SPEs 89 are not the egress LSR of the overlay LSP, but they are the egress 90 LSR of the underlay LSP. So the anycast tunnel for SPEs is also 91 egress protection tunnel for SPEs. 93 1.1. Terminology and Acronyms 95 This document uses the following acronyms and terms: 97 * All-Active Redundancy Mode - When a device is multihomed to a 98 group of two or more PEs and when all PEs in such redundancy group 99 can forward traffic to/from the multihomed device or network for a 100 given VLAN. 102 * Backup egress router - Given an egress-protected tunnel and its 103 egress router, this is another router that has connectivity with 104 all or a subset of the destinations of the egress-protected 105 services carried by the egress-protected tunnel. 107 * SPE - Stitching PE, the PEs to do label swapping operation for the 108 EVPN labels. It is similar to the SPE of MS-PWs. 110 * TPE - Target PE, the PEs to do EVPN forwarding for the overlay 111 network. 113 * BUM - Broadcast, Unknown unicast, and Multicast. 115 * CE - Customer Edge equipment. 117 * EELP bypass tunnel - Egress ESI Link Protection bypass tunnel - A 118 tunnel used to reroute service packets upon an egress ESI link 119 failure. 121 * Egress failure - An egress node failure or an egress link failure. 123 * Egress link failure - A failure of the egress link (e.g., PE-CE 124 link, attachment circuit) of a service. 126 * Egress loopback - the loopback interface on the Egress router, 127 whose IP address is the destination of the Egress-protected 128 tunnel. 130 * Egress node failure - A failure of an egress router. 132 * Egress router - A router at the egress endpoint of a tunnel. It 133 hosts service instances for all the services carried by the tunnel 134 and has connectivity with the destinations of the services. 136 * ESI - Ethernet Segment Identifier - A unique non-reserved 137 identifier that identifies an Ethernet segment. 139 * OPE - Originating PE - the original Router of an EVPN route. 141 * PE - Provider Edge equipment. Note that VTEP/NVE are also called 142 as PE in this draft. 144 * PLR - A router at the point of local repair. In egress node 145 protection, it is the penultimate hop router on an egress- 146 protected tunnel. In egress link protection, it is the egress 147 router of the egress- protected tunnel. 149 * Protector - A role acted by a router as an alternate of a 150 protected egress router, to handle service packets in the event of 151 an egress failure. A protector is physically independent of the 152 egress router. 154 * Protector loopback - the loopback interface on the Protector, 155 whose IP address is the destination of the Egress-protected 156 tunnel. 158 * Single-Active Redundancy Mode - When a device or a network is 159 multihomed to a group of two or more PEs and when only a single PE 160 in such a redundancy group can forward traffic to/from the 161 multihomed device or network for a given VLAN. 163 * DF - Designated Forwarder. 165 * NDF - non-DF, non Designated-Forwarder. 167 * NDF-Bias - An exception for filtering bypassed BUM packets. It 168 says that when an outgoing AC is a NDF on its ES, the bypass-BUM 169 filter rules will not be applied for that AC. 171 2. Detailed Problem and Solution Requirement 173 2.1. Scenarios and Basic Settings 175 (PE3) (PE1) 176 ____SPE1____ ____TPE2____ 177 / \ / \ 178 CE1---TPE1---PLR2 PLR1 CE2 179 \____SPE2____/ \____TPE3____/ 180 (PE2) 182 Figure 1: TPE-aided SPE-Protection Scenario 184 The above figure is a combination of 185 [I-D.wang-bess-evpn-egress-protection]'s Figure 1 and 186 [I-D.wang-bess-evpn-context-label]'s Figure 6. The TPE1/SPE1/SPE2/ 187 TPE2 above is the TPE1/SPE1/SPE2/TPE2 of 188 [I-D.wang-bess-evpn-context-label]'s Figure 6, But TPE2 is also the 189 PE1 of [I-D.wang-bess-evpn-egress-protection]'s Figure 1, and TPE3 is 190 the PE2, SPE1 is the PE3. 192 When TPE2 advertises an EVPN route (say R9), the same R9 will be 193 advertised to both the two SPEs and TPE3. When TPE3 receives R9, 194 they will do EVPN egress protection. When SPE1 or SPE2 receives the 195 same R9, SPE1/SPE2 will advertise R9 to TPE1 with the same nexthop 196 (the anycast tunnel address of SPE1 and SPE2) following Section 3.3. 198 Then the requirement here is clear that we want TPE2 use the same 199 route attributes to advertise R9 to both the SPEs and the TPEs. 201 In addition, Note that when the BUM tunnel (T1) from PE1 (TPE2) to 202 PE2 (TPE3) travels through the PLR1, and the PLR1 reroutes these 203 packets (destined to PE2) back to PE1 when PE2 fails, at that moment, 204 PE1 should drop these packets because their EVI label are mirrored 205 EVI labels (in context-specific label space) but their ESI labels are 206 not absent. 208 Note that the Leaf labels (along with mirrored EVI labels) should be 209 distinguished from the ESI labels (along with mirrored EVI labels), 210 because that the former should not be dropped but the latter can be 211 dropped. They can be distinguished by installing mirrored Leaf 212 labels, but the mirrored ESI labels need not be installed. 214 2.1.1. Exception Case for Next Hop Validating 216 When TPE3 receives an EVPN route R0 whose nexthop matches the prefix 217 LOC1, TPE3 may discard the route R0 because its nexthop is considered 218 to be TPE3's own address. Even though TPE3 don't disccard R0, TPE3 219 cannot use its nexthop to send an EVPN data packet to TPE2. 221 Because that a destination IP within prefix LOC1 (in forms of LOC1_P) 222 will be considered to be sent to TPE3 itself. So we should use IP_N1 223 and IP_N2 to establish the bypass path between TPE2 and TPE3 instead 224 of LOC1 and LOC2. 226 3. Control Plane Processing 228 3.1. Downstream-CLS ID Extended Community 230 The downstream-CLS ID Extended Community is a new Transitive Opaque 231 EC with the following structure (Sub-Type value to be assigned by 232 IANA): 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | 0x03 or 0x43 | Sub-Type |M| ID-Type | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | ID-Value | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 2: Downstream-CLS ID Extended Community 244 * ID-Type: A 2-octet field that specifies the type of Label Space 245 ID. In this section, the ID-Type is 0. The ID-Type 0 indicating 246 that the ID-Value field is a MPLS label in DCB, and it has global 247 uniqueness across the EVPN domain. 249 * ID-Value: A 4-octet field that specifies the value of Label Space 250 ID. When it is a label (with ID-Type 0), the most significant 251 20-bit is set to the label value. 253 * M bit: Multi-homing Flag. If the EVPN route is advertised by a 254 TPE of a redundancy group, and the nexthop of that route is the 255 TPE's anycast address, the multi-homing flag should be set to 1. 257 If the EVPN route is advertised by a SPE of no redundancy group, 258 and the nexthop of that route is not an anycast address, the 259 multi-homing flag should be kept unchanged. 261 If the EVPN route is advertised by a SPE of a redundancy group, 262 and the nexthop of that route is the redundancy group's anycast 263 address, the multi-homing flag should be rewritten to 1. 265 Note that although the downstream-CLS ID EC is highly similar to the 266 Context Label Space ID Extended Community (see section 3.1 of 267 [I-D.ietf-bess-mvpn-evpn-aggregation-label]) in their encodings, they 268 have absolutely different behaviors in data-plane. The CLS-ID EC 269 should be treated as an incomming label in data-plane, but the 270 downstream-CLS ID EC should be treated as an outgoing label in data- 271 plane. So they couldn't share the same code-point in the signalling 272 procedures. 274 3.2. TPE Procedures 276 First of all, We reserve a portion of the label space for assignment 277 by a central authority. We refer to this reserved portion as the 278 "Domain-wide Common Block" (DCB) of labels. This is analogous to the 279 DCB that is described in Section 3.1. The DCB is taken from the same 280 label space that is used for downstream-assigned labels, but each PE 281 would know not to allocate local labels from that space. A PE would 282 know by provisioning which label from the DCB corresponds to itself, 283 and each of other labels from the DCB corresponds to each PE of the 284 domain. 286 Note that the PEs don't have to know exactly which label corresponds 287 to a specified PE, They just need know which label is for itself, and 288 other labels is not for itself. 290 The MPLS-specific procedures are defined in the following list: 292 [M1] In "[C3]", when TPE2(PE1) advertise R4/R5/R6, a Downstream-CLS 293 ID EC will be advertised along with R4/R5/R6. And this EC 294 carries the label (in DCB) that identifying TPE2(PE1) itself. 296 [M2] In "[C4]", when TPE3(PE2) receives R4/R5/R6, It install the 297 mirrored ILM entry in a context-specific labels space (say 298 CLS23). The CLS23 is identified by the Downstream-CLS ID EC 299 (say CIL2) of R4/R5/R6. The mirrored ILM entry is called as a 300 CLS-specific ILM entry (CLS-ILM). 302 [M3] In "[C5]", when SPE1(PE3) receives R4/R5/R6, It should impose 303 the context-identifying label (CIL) carried in R4/R5/R6's 304 Downstream-CLS ID EC onto the label stack following 305 Section 4.2. That CIL is the outer label of the EVPN label of 306 R4/R5/R6. In addition, SPE1(PE3) will aplly the procedures of 307 Section 3.3 too. Although these procedures is not of EVPN 308 egress TPE protection schema, they share the same signalling 309 with EVPN protection. This simplifies the signalling 310 procedures, because there no longer will be a requirement to 311 advertise different route attributes to different PEs. 313 3.3. SPE Procedures 315 Now take above use case for example, the two SPEs are the egress 316 nodes of an anycast SR-MPLS tunnel. The anycast SR-MPLS tunnel is 317 used to transport flows from TPE1 to either SPE1 or SPE2 according to 318 load balancing procedures. So SPE1 and SPE2 have to advertise the 319 same EVPN label independently for a given EVPN route. 321 When TPE2 send a MAC/IP advertisement route (say R8) to SPE1 and 322 SPE2, a "Downstream Context-specific Label Space (CLS) ID Extended 323 Community" can be included in R8 along with an EVPN label (say EVL4). 325 3.3.1. Context-specific Label Swapping 327 When SPE1 and SPE2 receive R8 from TPE2, they should advertise R8 to 328 TPE1 independently, and the next-hop of R8 should be changed to the 329 common anycast node address (say IP_12) of SPE1 and SPE2 before the 330 advertisement. But SPE1 and SPE2 can simply keep R8's EVPN label 331 (the EVL4 from TPE2) unchanged. 333 The contex-VC label (say VCL4) in the "downstream-CLS ID EC" is also 334 kept unchanged. 336 Note that although the EVL4 and VCL4 is unchanged, a CLS-specific ILM 337 whose label operation is "label swapping" should also be installed, 338 because that the outgoing PSN tunnel information should be resolved. 340 Note that the two outgoing-labels of the label-swapping have the same 341 value (EVL4 and VCL4) as the two incomming-labels. 343 Note that if there is no TPE3, thus TPE2 is in no redundancy group. 344 The SPEs will receive R8 with M bit = 0, In such case, the SPEs will 345 not push the VCL4 onto the label stack for TPE2. 347 3.3.2. The Generating of Downstream-CLS ID EC on SPE 349 When TPE2 don't advertise the Downstream-CLS ID EC to SPE1 and SPE2, 350 They have to generate that EC by themselves. 352 In such case, TPE2 should advertise the OPE TLV for R8. And a 353 context-VC infrastructure should be established previously. The 354 context-VC infrastructure should assure that the context-VCs from 355 TPE2 to any other TPEs/SPEs have the same VCL value. 357 Then the SPE1 can set the ID-Value of the Downstream-CLS ID EC to the 358 VCL of the contex VC from TPE2 to itself. The ID-Type of the 359 Downstream-CLS ID EC is set to 0. So the same Downstream-CLS ID EC 360 can be generated by the SPEs independently. 362 It is feasible for such context-VC infrastructure to be implemented 363 on the basis of Kompella VPLS signalling or BGP SR signaling. But it 364 will be better for the admin-EVI (as the context-VC infrastructure) 365 and EVPN VPLS to use the same signalling framework. 367 4. Protection Procedures 369 4.1. TPE Protection Procedures 371 Please see section 5 of [I-D.wang-bess-evpn-egress-protection]. 373 4.2. SPE Protection Procedures 375 The label stack on the anycast SR-MPLS tunnel is constructed by TPE1 376 as the following: 378 +---------------------------------+ 379 | underlay ethernet header | 380 +---------------------------------+ 381 | Anycast SR-TL = SR_LSP_to_SPEs | 382 +---------------------------------+ 383 | Context-VC Label = VCL4 | 384 +---------------------------------+ 385 | EVPN label = EVL4 | 386 +---------------------------------+ 387 | overlay ethernet or IP header | 388 +---------------------------------+ 390 Figure 3: Anycast SPE dataplane 392 Note that the SR Tunnel Label (TL) in the label stack is the anycast 393 SR-LSP label from TPE1 to the SPE1 or SPE2. And the VCL4 in the 394 label stack is mandatory (from the viewpoint of TPE1). 396 Note that the context-VC is constructed (on SPE1 and SPE2) in per- 397 platform label space, and VC labels from TPE2 to SPE1 and SPE2 will 398 be the same value (VCL4). so the label stacks (from the viewpoint of 399 TPE1) are the same for SPE1 and SPE2. That's why the anycast tunnel 400 from TPE1 to SPE1 and SPE2 can be used for R8 by TPE1. 402 When SPE1/SPE2 receives that data packet, then SPE1/SPE2 will perform 403 CLS-specific ILM lookup for the EVPN label in the "TPE2-specific 404 label space" which is identified by the context-VC label VCL4. The 405 label operation will be "swapping", and the new outgoing EVPN label 406 will be the same value (as EVL4). 408 5. IANA Considerations 410 This document introduces a new Transitive Opaque Extended Community 411 "Downstream CLS ID Extended Community". An IANA request will be 412 submitted later for the code-point in the BGP Transitive Opaque 413 Extended Community Sub-Types registry. 415 6. Security Considerations 417 This section will be added in future versions. 419 7. Acknowledgements 421 TBD. 423 8. References 425 8.1. Normative References 427 [I-D.heitz-bess-evpn-option-b] 428 Heitz, J., Sajassi, A., Drake, J., and J. Rabadan, "Multi- 429 homing and E-Tree in EVPN with Inter-AS Option B", Work in 430 Progress, Internet-Draft, draft-heitz-bess-evpn-option- 431 b-01, 13 November 2017, . 434 [I-D.wang-bess-evpn-context-label] 435 Wang, Y. and B. Song, "Context Label for MPLS EVPN", Work 436 in Progress, Internet-Draft, draft-wang-bess-evpn-context- 437 label-04, 20 August 2020, . 440 [I-D.wang-bess-evpn-egress-protection] 441 Wang, Y. and R. Chen, "EVPN Egress Protection", Work in 442 Progress, Internet-Draft, draft-wang-bess-evpn-egress- 443 protection-04, 29 October 2020, 444 . 447 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 448 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 449 "MVPN/EVPN Tunnel Aggregation with Common Labels", Work in 450 Progress, Internet-Draft, draft-ietf-bess-mvpn-evpn- 451 aggregation-label-05, 11 January 2021, 452 . 455 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 456 Michel, C., and H. Chen, "MPLS Egress Protection 457 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 458 . 460 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 461 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 462 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 463 2015, . 465 [C3] "[C3]", 29 October 2020, . 468 [C4] "[C4]", 29 October 2020, . 471 [C5] "[C5]", 29 October 2020, . 474 8.2. Informative References 476 [I-D.ietf-bess-evpn-prefix-advertisement] 477 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 478 Sajassi, "IP Prefix Advertisement in EVPN", Work in 479 Progress, Internet-Draft, draft-ietf-bess-evpn-prefix- 480 advertisement-11, 18 May 2018, 481 . 484 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 485 Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 486 Rabadan, "Integrated Routing and Bridging in EVPN", Work 487 in Progress, Internet-Draft, draft-ietf-bess-evpn-inter- 488 subnet-forwarding-08, 5 March 2019, 489 . 492 Author's Address 494 Yubao Wang 495 ZTE Corporation 496 No.68 of Zijinghua Road, Yuhuatai Distinct 497 Nanjing 498 China 500 Email: wang.yubao2@zte.com.cn