idnits 2.17.1 draft-andersson-mpls-eh-label-stack-operations-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 6, 2021) is 931 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) -- Looks like a reference, but probably isn't: '104' on line 504 == Missing Reference: 'GAL' is mentioned on line 487, but not defined == Missing Reference: 'ACH' is mentioned on line 487, but not defined == Missing Reference: 'HEH' is mentioned on line 487, but not defined == Missing Reference: 'EH' is mentioned on line 487, but not defined == Missing Reference: 'IP' is mentioned on line 528, but not defined -- Looks like a reference, but probably isn't: '103' on line 351 -- Looks like a reference, but probably isn't: '102' on line 507 -- Looks like a reference, but probably isn't: '101' on line 485 -- Looks like a reference, but probably isn't: '201' on line 524 == Missing Reference: 'VPN' is mentioned on line 530, but not defined == Missing Reference: 'F' is mentioned on line 415, but not defined == Missing Reference: 'RSVP' is mentioned on line 512, but not defined == Outdated reference: A later version (-03) exists of draft-andersson-mpls-eh-architecture-02 ** Downref: Normative reference to an Informational draft: draft-andersson-mpls-eh-architecture (ref. 'I-D.andersson-mpls-eh-architecture') == Outdated reference: A later version (-06) exists of draft-song-mpls-eh-indicator-03 ** Downref: Normative reference to an Informational draft: draft-song-mpls-eh-indicator (ref. 'I-D.song-mpls-eh-indicator') == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-05 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Andersson 3 Internet-Draft Bronze Dragon Consulting 4 Intended status: Standards Track J. Guichard 5 Expires: April 9, 2022 H. Song 6 Futurewei Technologies 7 S. Bryant 8 University of Surrey 9 October 6, 2021 11 MPLS Label Operations in MPLS EH capable networks 12 draft-andersson-mpls-eh-label-stack-operations-02 14 Abstract 16 Extension Headers (EH) carry information on in-network services and 17 functions in an MPLS network. This document describes the operations 18 on the MPLS label stack when an EH is found in the packet. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 9, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 56 2. Operations on an MPLS Label Stack in an EH capable network . 3 57 2.1. Physical Topology . . . . . . . . . . . . . . . . . . . . 3 58 2.2. A day in the life of a packet . . . . . . . . . . . . . . 5 59 2.2.1. Non-VPN Case . . . . . . . . . . . . . . . . . . . . 6 60 2.2.1.1. Non-VPN with the EH in the packet . . . . . . . . 6 61 2.2.1.2. Non-VPN without an EH in the packet . . . . . . . 7 62 2.3. The VPN case . . . . . . . . . . . . . . . . . . . . . . 8 63 2.3.1. VPN with EH in the packet . . . . . . . . . . . . . . 8 64 2.3.2. VPN without EH in the packet . . . . . . . . . . . . 9 65 2.4. RSVP-TE Tunnel case . . . . . . . . . . . . . . . . . . . 10 66 2.4.1. RSVP Tunnel and EH present in the packet . . . . . . 11 67 2.4.2. RSVP Tunnel and no EH present in the packet . . . . . 12 68 2.4.3. EH capable RSVP-TE tunnel . . . . . . . . . . . . . . 13 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 6.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 This document provides the operating procedures for EH-capable and 80 non-EH-capable LSRs where MPLS Extension Headers (EH) are carried 81 below the MPLS label stack. Further we show that MPLS EHs can be 82 gradually introduced into an existing MPLS network. The capability 83 to handle EHs is announced throughout the MPLS network, and LSRs that 84 don't understand this information simply ignore it. 86 The extension headers are carried after the MPLS Label Stack, and the 87 presence of EHs are indicate in the label stack by a Extetended 88 Spewcial Purpose label called Extention Headder Indicator (EHI) in 89 the label stack. 91 Extension headers may for example be used when it is required that 92 the packet carry some metadata, more details will be found in 93 [I-D.song-mpls-extension-header]. Examples of such cases are In-situ 94 OAM, Network Telemetry and Measurement and Network Security. 96 Only EH capable LSRs will process EHs, LSRs that are EH non-capable 97 will ignore the EH and forward the packet as if the information was 98 not there. 100 1.1. Requirement Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 2. Operations on an MPLS Label Stack in an EH capable network 110 This document provides a set of examples to show the operations 111 performed on MPLS encapsulated packets in a network where MPLS EHs 112 are used. The document does also illustrated the procedures for 113 processing of the information carried within the MPLS label stack to 114 indicate the presence of EHs below the label stack. For the purpose 115 of illustration, we will assume that the indicator used to point to 116 EHs is a G-ACh Generic Associated Channel Label (GAL) [RFC5586] + 117 G-Ach Associated Channel Header (ACH)[RFC5586] with a set of new ACH 118 types to indicate the EH types carried below the MPLS label stack. 120 As discussed in [I-D.andersson-mpls-eh-architecture], 121 [I-D.song-mpls-extension-header] and [I-D.song-mpls-eh-indicator] 122 there are alternatives to the use of GAL as the indicator; for 123 example an Extension Label (XL) [RFC7274] + one or more Extended 124 Special Purpose Labels (eSPLs) [RFC7274] could also be used. 126 2.1. Physical Topology 128 Assume a physical topology that includes both EH capable LSRs and 129 non-EH capable LSRs. The topology is intentionall kept quite simple. 131 +---+ +---+ +---+ +---+ +---+ +---+ 132 | | | | | | | | | | | | 133 | A +------+ b +------+ c +------+ D +------+ E +------+ F + 134 | | | | | | | | | | | | 135 +---+ +---+ +---+ +---+ +---+ +---+ 137 Legend: 138 A, D, E, and F are EH capable LSRs 140 b and c are non-EH capable LSRs. 142 Figure 1: EH topology 144 LDP Downstream on Demand (DoD) or Downstream Unsolicited (DU), RSVP- 145 TE, an IGP or a centralized controller could be used to create the 146 label mappings between the LSRs in an EH capable network. Referring 147 to Figure 1, and using LDP DU for illustration, creation of an EH 148 path used by A to send MPLS encapsulated packets with MPLS EHs to F 149 is as show below. 151 For prefix F reachable at LSR F: 153 o F advertises labels F:[ldp: implicit-null, EH-FEC: implicit-null] 154 to E 156 o E advertises labels F:[ldp: 101, EH-FEC: 201] to D 158 o D advertises label F:[ldp: 102] to c 160 o c advertises label F:[ldp: 103] to b 162 o b advertises label F:[ldp: 104] to A 164 This will result in installed labels as shown in Figure 2. 166 +---+ +---+ +---+ +---+ +---+ +---+ 167 | |..104..| |..103..| |..102..| |..101..| |..php..| | 168 | A +-------+ b +-------+ c +-------+ D +-------+ E +-------+ F + 169 | | | | | | | |..201..| |..php..| | 170 +---+ +---+ +---+ +---+ +---+ +---+ 172 Legend: 173 A, D, E and F are EH capable nodes. 174 b and are non-EH capable nodes. 176 Figure 2: EH topology 178 2.2. A day in the life of a packet 180 This section provides examples of forwarding for some common 181 scenarios in networks with a mix of EH-capable and non-EH-capable 182 LSRs and packets with and without EHs following the MPLS label stack. 184 All the information processed in the examples below is not strictly a 185 part of the "label stack"; ACH, EHL, HEH, EH and Payload are carried 186 after the last entry in the label stack. 188 For reference the following shows the full MPLS EH stack, i.e. 189 including also the EH specific information and the payload. 190 0 31 191 +--------+--------+--------+--------+ 192 | MPLS Label Stack | 193 +--------+--------+--------+--------+ 194 | GAL (s-bit = 1) | * If eSPL then replace GAL 195 +--------+--------+--------+--------+ with XL+EHL 196 | ACH Type = (EH E2E/HBH/BOTH) | * If SPL then ACH not required; 197 +--------+--------+--------+--------+ HEH follows XL+EHL directly 198 | Header of Extension Headers (HEH) | 199 +--------+--------+--------+--------+ 200 | | 201 ~ Extension Header (EH) 1 ~ 202 | | 203 +--------+--------+--------+--------+ 204 | | 205 ~ Extension Header (EH) N ~ 206 | | 207 +--------+--------+--------+--------+ 208 | | 209 ~ Upper Layer Protocols/Payload ~ 210 | | 211 +--------+--------+--------+--------+ 213 Figure 3: MPLS Extension Header (EH) Stack 215 2.2.1. Non-VPN Case 217 For non-VPN there are two variants, either the EH is present or it is 218 not. 220 2.2.1.1. Non-VPN with the EH in the packet 222 o A sends packet to b 224 * stack = [104, GAL, ACH, HEH, EH, IP] 226 o b is a legacy router so just swaps [104] to [103], and sends the 227 packet to c 229 * stack = [103, GAL, ACH, HEH, EH, IP] 231 o c is a legacy router so just swaps [103] to [102], and sends the 232 packet to D 233 * stack = [102, GAL, ACH, HEH, EH, IP] 235 o D is an EH capable LSR and receives the packet with [102] on top 236 of the stack; D scans the packet for an EH; D finds EH and 237 processes and then swaps the top label to [101] and then sends the 238 packet on to E 240 i Note: this goes on the standard FEC because we only announce 241 in the packet there is NO EH. In this case EH is present. 243 * stack = [101, GAL, ACH, HEH, EH, IP] 245 o E receives [101] and scans the packet for EH; finds EH and 246 processes and then pops the top lael and send the packet to F 248 * stack = [GAL, ACH, HEH, EH, IP] 250 + Note: E is the penultimate hop router so it pops the 251 standard LDP label, and send on the standard FEC to F. 253 o F receives the packet and scans the packet for EH; finds EH and 254 processes it. As F is the ultimate hop it pops GAL, and removes 255 ACH, HEH and EH, processes IP and forwards the packet. 257 2.2.1.2. Non-VPN without an EH in the packet 259 In this example there is no EH present in the packet. 261 o A sends packet to b 263 * stack = [104, IP] 265 o b receives the packet, b is a legacy router so it just swaps [104] 266 to [103] and sends the packet to c 268 * stack = [103, IP] 270 o c receives the packet, c is a legacy router so it just swaps [103] 271 to [102], and sends the packet to D 273 * stack = [102, IP] 275 o D receives the packet, D is an EH capable router, D searches the 276 packet for an EH but finds no EH, D swaps [102] to [201], and 277 sends the packet to E 279 * stack = [201, IP] 280 + Note: in this case D sends the packet using the EH-FEC as EH 281 is *not* present. 283 + Note: If downstream is not EH capable then D sends the 284 packet on the standard FEC. 286 o E receives the packet [201] and bypasses EH processing (received 287 on the "no EH present" FEC; E is penultimate node so it pops EH- 288 FEC label; and send the packet to F. 290 * stack = [IP]; not exactly a "label stack", but listed here for 291 symmetry 293 o F receives [IP] and routes the packet 295 2.3. The VPN case 297 In these two examples there is VPN information in the label stack, in 298 the first there also EHs in the packet. 300 2.3.1. VPN with EH in the packet 302 o A sends packet to b 304 * stack = [104, VPN, GAL, ACH, HEH, EH, IP] 306 o b receives the packet; b is a legacy router and just swaps [104] 307 to [103] and sends the packet to c 309 * stack = [103, VPN, GAL, ACH, HEH, EH, IP] 311 o c receives the packet; c is a legacy router and just swaps [103] 312 to [102] and sends the packet to D 314 * stack = [102, VPN, GAL, ACH, HEH, EH, IP] 316 o D receives the packet; D is EH capable LSR; D will search the 317 packet for EH and will find and process the EH; D will then swap 318 [102] to [101] and sends the packet to E 320 * stack = [101, VPN, GAL, ACH, HEH, EH, IP] 322 + Note: This packet will be sent normal IP standard FEC; only 323 packets that does not include an EH will be sent on the "no 324 EH present" FEC. 326 o E receives the packet; E is EH capable LSR; E will search the 327 packet for EH and will find and process the EH; E will then pop 328 [101] and sends the packet to F 330 * stack = VPN, GAL, ACH, HEH, EH, IP] 332 + Note: E is penultimate hop so pops the LDP label and send 333 the packet on normal IP standard FEC; only packets that does 334 not include an EH will be sent on the "no EH present" FEC. 336 o F receives and scans the packet for EH; finds EH and processes it. 337 As F is the ultimate hop it pops the GAL, and removes ACH, HEH and 338 EH, processes the VPN label and forwards the packet. 340 2.3.2. VPN without EH in the packet 342 o A sends packet to b 344 * stack = [104, VPN, IP] 346 o b receives the packet; b is a legacy router and just swaps [104] 347 to [103] and sends the packet to c 349 * stack = [103, VPN, IP] 351 o c receives the packet; c is a legacy router and just swaps [103] 352 to [102] and sends the packet to D 354 * stack = [102, VPN, IP] 356 o D receives the packet; D is EH capable LSR; D will search the 357 packet for EH; D will not find an EH; D will then swap [102] to 358 [201] and sends the packet to E on the "no EH present" FEC. Loa 360 * stack = [101, VPN, IP] 362 + Note: This packet will be sent on the "no EH pesent" FEC; 364 o E receives the packet [201] and bypasses EH processing (received 365 on the "no EH present" FEC; E is the penultimate node so it pops 366 EH- FEC label; and send the packet to F on the "no EH present" 367 FEC. 369 * stack = [VPN, IP] 371 + Note: E is penultimate hop so E pops the "no FEC present" 372 label and send the packet to F. 374 o F receives and scans the packet for EH; finds no EH and bypasses 375 EH processing. As F is the ultimate hop it processes the VPN 376 label and forwards the packet. 378 2.4. RSVP-TE Tunnel case 380 The RSVP-TE tunnel is not EH capable or the capability has been 381 disabled. 383 Assume a physical topology that includes both EH capable LSRs and 384 non-EH capable LSRs, as in the earlier examples. This topology also 385 includes a low cost RSVP-TE tunnel between b and D. 387 +---+ +---+ +---+ +---+ +---+ +---+ 388 | | | | | | | | | | | | 389 | A +------+ b +------+ c +------+ D +------+ E +------+ F + 390 | | | | | | | | | | | | 391 +---+ +---+ +---+ +---+ +---+ +---+ 392 | | | | 393 | |___________________| | 394 |_______________________| 396 Legend: 397 A, D, E, and F are EH capable LSRs 399 b and c are non-EH capable LSRs. 401 Nodes that transport the RSVP-TE tunnel are not EH capable, or the EH 402 capability is disabled. 404 Figure 4: EH topology 406 For this example the following assumptions are made: 408 o An RSVP-TE tunnel has been established between b and D (packets 409 will bypass c) 411 o F is reachable at b through RSVP-TE tunnel 413 o LDP is enabled on the RSVP-TE tunnel 415 For prefix [F]: The following label mappings are sent by the LSRs in 416 the network. 418 o F advertises labels F: [ldp: implicit-null, EH-FEC: implicit-null] 419 to E 421 o E advertises labels F: [ldp: 101, EH-FEC: 201] to D 423 o D advertises label F: [ldp: 102] to c and F:[ldp: 102] to b 425 o c advertises label F: [ldp: 103] to b 427 o b advertises label F: [ldp: 104] to A 429 This will result in label mappings like this. 431 +---+ +---+ +---+ +---+ +---+ +---+ 432 | |--104..| |..103..| |..102..| |..101..| |..php..| | 433 | A +-------+ b +-------+ c +-------+ D +-- ----+ E +-------+ F + 434 | | | | | | | |..201..| |..php..| | 435 +---+ - +---+ +---+ +---+ +---+ +---+ 436 | | | | 437 | +---------------------+ | 438 | [RSVP, 102] | 439 +-------------------------+ 441 Legend: 442 A, D, E, and F are EH capable LSRs 444 b and c are non-EH capable LSRs. 446 Nodes that transport the RSVP-TE tunnel are not EH capable, or the EH 447 capability is disabled. [RSVP] represents the series of tunnel top 448 lables. 450 Figure 5: EH topology 452 To describe the label stack operations in this case the VPN label 453 stack is used, starting with the case where an EH is present in the 454 packet. 456 2.4.1. RSVP Tunnel and EH present in the packet 458 o A sends packet to b 460 stack = [104, VPN, GAL, ACH, HEH, EH, IP] 462 o b receives the packet, since b is a legacy router it swaps [104] 463 to [102], the next-hop reachable through the RSVP-TE tunnel; push 464 the ingress RSVP-TE tunnel label and send it via the tunnel to the 465 tunnel endpoint D 467 stack = [RSVP, 102, VPN, GAL, ACH, HEH, EH, IP] 469 o Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE 470 label. 472 o D receives the packet, D will pop the last RSVP-TE label; since D 473 is a EH capable router it will search the stack and find the EH, 474 after processing the EH it will swap [102] to [101], and send the 475 packet to E over the normal FEC 477 stack = [101, VPN, GAL, ACH, HEH, EH, IP] 479 Note: this will be forwarded on the standard FEC because 480 since the EH is present in the packet, only packet without 481 an EH is forwarded on the "no EH present" FEC. 483 o E receives the packet [101]; since E is a EH capable router it 484 will search the stack and find the EH; after processing the EH it 485 will pop [101], and send the packet to E over the normal FEC 487 stack = [VPN, GAL, ACH, HEH, EH, IP] 489 Note: As E is the penultimate hop it will pop the standard 490 LDP label. 492 o F receives the packet with the VPN label on top [VPN]; E scans the 493 packet for EH; finds EH and processes. As F is the ultimate hop 494 it pops GAL, and removes ACH, HEH and EH, processes VPN label and 495 forwards the packet. 497 2.4.2. RSVP Tunnel and no EH present in the packet 499 o A sends packet to b 501 * stack = [104, VPN, IP] 503 o b receives the packet [104]; be is legacy router and will not 504 search for an EH; b swaps [104] to [102]; pushes [RSVP] sends 505 packet to D over the RSVP-TE tunnel. 507 * stack = [RSVP, 102, VPN, IP] 509 o Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE 510 label. 512 o D receives pops the tunnel label [RSVP], D is EH capable and scans 513 the packet for EH; D finds no EH is present; pops RSVP-TE label, 514 and then swaps LDP label [102 ]to [201] and sends the packet to E 516 * stack = [201, VPN, IP] 518 + Note: in this case D sends the packet using the "no EH 519 present" FEC, since there is no EH in the packet. 521 + Note: If the downstream LSR is not EH capable then D will 522 sends the packet on the standard FEC. 524 o E receives [201] and bypasses EH processing since the packet is 525 received on the "no EH present" FEC; E is the pen-ultimate hop so 526 it EH-FEC label and forward the packet to F 528 * stack = [VPN, IP] 530 o F receives the packet [VPN]; and scans the packet for EH; does not 531 find EH, processes VPN label and forwards the packet. 533 2.4.3. EH capable RSVP-TE tunnel 535 The case where an RSVP-TE tunnel is both EH capable and EH enabled is 536 for further study. 538 3. Security Considerations 540 TBA 542 4. IANA Considerations 544 There are no requests for IANA actions in this document. 546 Note to the RFC Editor - this section can be removed before 547 publication. 549 5. Acknowledgements 551 TBA 553 - 555 6. References 557 6.1. Normative References 559 [I-D.andersson-mpls-eh-architecture] 560 Andersson, L., Guichard, J. N., Song, H., and S. Bryant, 561 "MPLS Extension Header Architecture", draft-andersson- 562 mpls-eh-architecture-02 (work in progress), October 2021. 564 [I-D.song-mpls-eh-indicator] 565 Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for 566 MPLS Extension Header Indicator", draft-song-mpls-eh- 567 indicator-03 (work in progress), July 2021. 569 [I-D.song-mpls-extension-header] 570 Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, 571 "MPLS Extension Header", draft-song-mpls-extension- 572 header-05 (work in progress), July 2021. 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 580 "MPLS Generic Associated Channel", RFC 5586, 581 DOI 10.17487/RFC5586, June 2009, 582 . 584 6.2. Informative References 586 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 587 and Retiring Special-Purpose MPLS Labels", RFC 7274, 588 DOI 10.17487/RFC7274, June 2014, 589 . 591 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 592 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 593 May 2017, . 595 Authors' Addresses 597 Loa Andersson 598 Bronze Dragon Consulting 600 Email: loa@pi.nu 601 James N Guichard 602 Futurewei Technologies 604 Email: james.n.guichard@futurewei.com 606 Haoyu Song 607 Futurewei Technologies 609 Email: haoyu.song@futurewei.com 611 Stewart Bryant 612 University of Surrey 614 Email: stewart.bryant@gmail.com