idnits 2.17.1 draft-andersson-mpls-eh-label-stack-operations-01.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 (March 11, 2021) is 1141 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 503 == Missing Reference: 'GAL' is mentioned on line 486, but not defined == Missing Reference: 'ACH' is mentioned on line 486, but not defined == Missing Reference: 'HEH' is mentioned on line 486, but not defined == Missing Reference: 'EH' is mentioned on line 486, but not defined == Missing Reference: 'IP' is mentioned on line 527, but not defined -- Looks like a reference, but probably isn't: '103' on line 350 -- Looks like a reference, but probably isn't: '102' on line 506 -- Looks like a reference, but probably isn't: '101' on line 484 -- Looks like a reference, but probably isn't: '201' on line 523 == Missing Reference: 'VPN' is mentioned on line 529, but not defined == Missing Reference: 'F' is mentioned on line 414, but not defined == Missing Reference: 'RSVP' is mentioned on line 511, but not defined == Outdated reference: A later version (-03) exists of draft-andersson-mpls-eh-architecture-00 ** 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-00 ** 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-02 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: September 12, 2021 H. Song 6 S. Bryant 7 Futurewei Technologies 8 March 11, 2021 10 MPLS Label Operations in MPLS EH capable networks 11 draft-andersson-mpls-eh-label-stack-operations-01 13 Abstract 15 Extension Headers (EH) carry information on in-network services and 16 functions in an MPLS network. This document describes the operations 17 on the MPLS label stack when an EH is found in the packet. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 12, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 55 2. Operations on an MPLS Label Stack in an EH capable network . 3 56 2.1. Physical Topology . . . . . . . . . . . . . . . . . . . . 3 57 2.2. A day in the life of a packet . . . . . . . . . . . . . . 5 58 2.2.1. Non-VPN Case . . . . . . . . . . . . . . . . . . . . 6 59 2.2.1.1. Non-VPN with the EH in the packet . . . . . . . . 6 60 2.2.1.2. Non-VPN without an EH in the packet . . . . . . . 7 61 2.3. The VPN case . . . . . . . . . . . . . . . . . . . . . . 8 62 2.3.1. VPN with EH in the packet . . . . . . . . . . . . . . 8 63 2.3.2. VPN without EH in the packet . . . . . . . . . . . . 9 64 2.4. RSVP-TE Tunnel case . . . . . . . . . . . . . . . . . . . 10 65 2.4.1. RSVP Tunnel and EH present in the packet . . . . . . 11 66 2.4.2. RSVP Tunnel and no EH present in the packet . . . . . 12 67 2.4.3. EH capable RSVP-TE tunnel . . . . . . . . . . . . . . 13 68 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 6.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 This document provides the operating procedures for EH-capable and 79 non-EH-capable LSRs where MPLS Extension Headers (EH) are carried 80 below the MPLS label stack. Further we show that MPLS EHs can be 81 gradually introduced into an existing MPLS network. The capability 82 to handle EHs is announced throughout the MPLS network, and LSRs that 83 don't understand this information simply ignore it. 85 The extension headers are carried after the MPLS Label Stack, and the 86 presence of EHs are indicate in the label stack by a Extetended 87 Spewcial Purpose label called Extention Headder Indicator (EHI) in 88 the label stack. 90 Extension headers may for example be used when it is required that 91 the packet carry some metadata, more details will be found in 92 [I-D.song-mpls-extension-header]. Examples of such cases are In-situ 93 OAM, Network Telemetry and Measurement and Network Security. 95 Only EH capable LSRs will process EHs, LSRs that are EH non-capable 96 will ignore the EH and forward the packet as if the information was 97 not there. 99 1.1. Requirement Language 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. Operations on an MPLS Label Stack in an EH capable network 109 This document provides a set of examples to show the operations 110 performed on MPLS encapsulated packets in a network where MPLS EHs 111 are used. The document does also illustrated the procedures for 112 processing of the information carried within the MPLS label stack to 113 indicate the presence of EHs below the label stack. For the purpose 114 of illustration, we will assume that the indicator used to point to 115 EHs is a G-ACh Generic Associated Channel Label (GAL) [RFC5586] + 116 G-Ach Associated Channel Header (ACH)[RFC5586] with a set of new ACH 117 types to indicate the EH types carried below the MPLS label stack. 119 As discussed in [I-D.andersson-mpls-eh-architecture], 120 [I-D.song-mpls-extension-header] and [I-D.song-mpls-eh-indicator] 121 there are alternatives to the use of GAL as the indicator; for 122 example an Extension Label (XL) [RFC7274] + one or more Extended 123 Special Purpose Labels (eSPLs) [RFC7274] could also be used. 125 2.1. Physical Topology 127 Assume a physical topology that includes both EH capable LSRs and 128 non-EH capable LSRs. The topology is intentionall kept quite simple. 130 +---+ +---+ +---+ +---+ +---+ +---+ 131 | | | | | | | | | | | | 132 | A +------+ b +------+ c +------+ D +------+ E +------+ F + 133 | | | | | | | | | | | | 134 +---+ +---+ +---+ +---+ +---+ +---+ 136 Legend: 137 A, D, E, and F are EH capable LSRs 139 b and c are non-EH capable LSRs. 141 Figure 1: EH topology 143 LDP Downstream on Demand (DoD) or Downstream Unsolicited (DU), RSVP- 144 TE, an IGP or a centralized controller could be used to create the 145 label mappings between the LSRs in an EH capable network. Referring 146 to Figure 1, and using LDP DU for illustration, creation of an EH 147 path used by A to send MPLS encapsulated packets with MPLS EHs to F 148 is as show below. 150 For prefix F reachable at LSR F: 152 o F advertises labels F:[ldp: implicit-null, EH-FEC: implicit-null] 153 to E 155 o E advertises labels F:[ldp: 101, EH-FEC: 201] to D 157 o D advertises label F:[ldp: 102] to c 159 o c advertises label F:[ldp: 103] to b 161 o b advertises label F:[ldp: 104] to A 163 This will result in installed labels as shown in Figure 2. 165 +---+ +---+ +---+ +---+ +---+ +---+ 166 | |..104..| |..103..| |..102..| |..101..| |..php..| | 167 | A +-------+ b +-------+ c +-------+ D +-------+ E +-------+ F + 168 | | | | | | | |..201..| |..php..| | 169 +---+ +---+ +---+ +---+ +---+ +---+ 171 Legend: 172 A, D, E and F are EH capable nodes. 173 b and are non-EH capable nodes. 175 Figure 2: EH topology 177 2.2. A day in the life of a packet 179 This section provides examples of forwarding for some common 180 scenarios in networks with a mix of EH-capable and non-EH-capable 181 LSRs and packets with and without EHs following the MPLS label stack. 183 All the information processed in the examples below is not strictly a 184 part of the "label stack"; ACH, EHL, HEH, EH and Payload are carried 185 after the last entry in the label stack. 187 For reference the following shows the full MPLS EH stack, i.e. 188 including also the EH specific information and the payload. 189 0 31 190 +--------+--------+--------+--------+ 191 | MPLS Label Stack | 192 +--------+--------+--------+--------+ 193 | GAL (s-bit = 1) | * If eSPL then replace GAL 194 +--------+--------+--------+--------+ with XL+EHL 195 | ACH Type = (EH E2E/HBH/BOTH) | * If SPL then ACH not required; 196 +--------+--------+--------+--------+ HEH follows XL+EHL directly 197 | Header of Extension Headers (HEH) | 198 +--------+--------+--------+--------+ 199 | | 200 ~ Extension Header (EH) 1 ~ 201 | | 202 +--------+--------+--------+--------+ 203 | | 204 ~ Extension Header (EH) N ~ 205 | | 206 +--------+--------+--------+--------+ 207 | | 208 ~ Upper Layer Protocols/Payload ~ 209 | | 210 +--------+--------+--------+--------+ 212 Figure 3: MPLS Extension Header (EH) Stack 214 2.2.1. Non-VPN Case 216 For non-VPN there are two variants, either the EH is present or it is 217 not. 219 2.2.1.1. Non-VPN with the EH in the packet 221 o A sends packet to b 223 * stack = [104, GAL, ACH, HEH, EH, IP] 225 o b is a legacy router so just swaps [104] to [103], and sends the 226 packet to c 228 * stack = [103, GAL, ACH, HEH, EH, IP] 230 o c is a legacy router so just swaps [103] to [102], and sends the 231 packet to D 232 * stack = [102, GAL, ACH, HEH, EH, IP] 234 o D is an EH capable LSR and receives the packet with [102] on top 235 of the stack; D scans the packet for an EH; D finds EH and 236 processes and then swaps the top label to [101] and then sends the 237 packet on to E 239 i Note: this goes on the standard FEC because we only announce 240 in the packet there is NO EH. In this case EH is present. 242 * stack = [101, GAL, ACH, HEH, EH, IP] 244 o E receives [101] and scans the packet for EH; finds EH and 245 processes and then pops the top lael and send the packet to F 247 * stack = [GAL, ACH, HEH, EH, IP] 249 + Note: E is the penultimate hop router so it pops the 250 standard LDP label, and send on the standard FEC to F. 252 o F receives the packet and scans the packet for EH; finds EH and 253 processes it. As F is the ultimate hop it pops GAL, and removes 254 ACH, HEH and EH, processes IP and forwards the packet. 256 2.2.1.2. Non-VPN without an EH in the packet 258 In this example there is no EH present in the packet. 260 o A sends packet to b 262 * stack = [104, IP] 264 o b receives the packet, b is a legacy router so it just swaps [104] 265 to [103] and sends the packet to c 267 * stack = [103, IP] 269 o c receives the packet, c is a legacy router so it just swaps [103] 270 to [102], and sends the packet to D 272 * stack = [102, IP] 274 o D receives the packet, D is an EH capable router, D searches the 275 packet for an EH but finds no EH, D swaps [102] to [201], and 276 sends the packet to E 278 * stack = [201, IP] 279 + Note: in this case D sends the packet using the EH-FEC as EH 280 is *not* present. 282 + Note: If downstream is not EH capable then D sends the 283 packet on the standard FEC. 285 o E receives the packet [201] and bypasses EH processing (received 286 on the "no EH present" FEC; E is penultimate node so it pops EH- 287 FEC label; and send the packet to F. 289 * stack = [IP]; not exactly a "label stack", but listed here for 290 symmetry 292 o F receives [IP] and routes the packet 294 2.3. The VPN case 296 In these two examples there is VPN information in the label stack, in 297 the first there also EHs in the packet. 299 2.3.1. VPN with EH in the packet 301 o A sends packet to b 303 * stack = [104, VPN, GAL, ACH, HEH, EH, IP] 305 o b receives the packet; b is a legacy router and just swaps [104] 306 to [103] and sends the packet to c 308 * stack = [103, VPN, GAL, ACH, HEH, EH, IP] 310 o c receives the packet; c is a legacy router and just swaps [103] 311 to [102] and sends the packet to D 313 * stack = [102, VPN, GAL, ACH, HEH, EH, IP] 315 o D receives the packet; D is EH capable LSR; D will search the 316 packet for EH and will find and process the EH; D will then swap 317 [102] to [101] and sends the packet to E 319 * stack = [101, VPN, GAL, ACH, HEH, EH, IP] 321 + Note: This packet will be sent normal IP standard FEC; only 322 packets that does not include an EH will be sent on the "no 323 EH present" FEC. 325 o E receives the packet; E is EH capable LSR; E will search the 326 packet for EH and will find and process the EH; E will then pop 327 [101] and sends the packet to F 329 * stack = VPN, GAL, ACH, HEH, EH, IP] 331 + Note: E is penultimate hop so pops the LDP label and send 332 the packet on normal IP standard FEC; only packets that does 333 not include an EH will be sent on the "no EH present" FEC. 335 o F receives and scans the packet for EH; finds EH and processes it. 336 As F is the ultimate hop it pops the GAL, and removes ACH, HEH and 337 EH, processes the VPN label and forwards the packet. 339 2.3.2. VPN without EH in the packet 341 o A sends packet to b 343 * stack = [104, VPN, IP] 345 o b receives the packet; b is a legacy router and just swaps [104] 346 to [103] and sends the packet to c 348 * stack = [103, VPN, IP] 350 o c receives the packet; c is a legacy router and just swaps [103] 351 to [102] and sends the packet to D 353 * stack = [102, VPN, IP] 355 o D receives the packet; D is EH capable LSR; D will search the 356 packet for EH; D will not find an EH; D will then swap [102] to 357 [201] and sends the packet to E on the "no EH present" FEC. Loa 359 * stack = [101, VPN, IP] 361 + Note: This packet will be sent on the "no EH pesent" FEC; 363 o E receives the packet [201] and bypasses EH processing (received 364 on the "no EH present" FEC; E is the penultimate node so it pops 365 EH- FEC label; and send the packet to F on the "no EH present" 366 FEC. 368 * stack = [VPN, IP] 370 + Note: E is penultimate hop so E pops the "no FEC present" 371 label and send the packet to F. 373 o F receives and scans the packet for EH; finds no EH and bypasses 374 EH processing. As F is the ultimate hop it processes the VPN 375 label and forwards the packet. 377 2.4. RSVP-TE Tunnel case 379 The RSVP-TE tunnel is not EH capable or the capability has been 380 disabled. 382 Assume a physical topology that includes both EH capable LSRs and 383 non-EH capable LSRs, as in the earlier examples. This topology also 384 includes a low cost RSVP-TE tunnel between b and D. 386 +---+ +---+ +---+ +---+ +---+ +---+ 387 | | | | | | | | | | | | 388 | A +------+ b +------+ c +------+ D +------+ E +------+ F + 389 | | | | | | | | | | | | 390 +---+ +---+ +---+ +---+ +---+ +---+ 391 | | | | 392 | |___________________| | 393 |_______________________| 395 Legend: 396 A, D, E, and F are EH capable LSRs 398 b and c are non-EH capable LSRs. 400 Nodes that transport the RSVP-TE tunnel are not EH capable, or the EH 401 capability is disabled. 403 Figure 4: EH topology 405 For this example the following assumptions are made: 407 o An RSVP-TE tunnel has been established between b and D (packets 408 will bypass c) 410 o F is reachable at b through RSVP-TE tunnel 412 o LDP is enabled on the RSVP-TE tunnel 414 For prefix [F]: The following label mappings are sent by the LSRs in 415 the network. 417 o F advertises labels F: [ldp: implicit-null, EH-FEC: implicit-null] 418 to E 420 o E advertises labels F: [ldp: 101, EH-FEC: 201] to D 422 o D advertises label F: [ldp: 102] to c and F:[ldp: 102] to b 424 o c advertises label F: [ldp: 103] to b 426 o b advertises label F: [ldp: 104] to A 428 This will result in label mappings like this. 430 +---+ +---+ +---+ +---+ +---+ +---+ 431 | |--104..| |..103..| |..102..| |..101..| |..php..| | 432 | A +-------+ b +-------+ c +-------+ D +-- ----+ E +-------+ F + 433 | | | | | | | |..201..| |..php..| | 434 +---+ - +---+ +---+ +---+ +---+ +---+ 435 | | | | 436 | +---------------------+ | 437 | [RSVP, 102] | 438 +-------------------------+ 440 Legend: 441 A, D, E, and F are EH capable LSRs 443 b and c are non-EH capable LSRs. 445 Nodes that transport the RSVP-TE tunnel are not EH capable, or the EH 446 capability is disabled. [RSVP] represents the series of tunnel top 447 lables. 449 Figure 5: EH topology 451 To describe the label stack operations in this case the VPN label 452 stack is used, starting with the case where an EH is present in the 453 packet. 455 2.4.1. RSVP Tunnel and EH present in the packet 457 o A sends packet to b 459 stack = [104, VPN, GAL, ACH, HEH, EH, IP] 461 o b receives the packet, since b is a legacy router it swaps [104] 462 to [102], the next-hop reachable through the RSVP-TE tunnel; push 463 the ingress RSVP-TE tunnel label and send it via the tunnel to the 464 tunnel endpoint D 466 stack = [RSVP, 102, VPN, GAL, ACH, HEH, EH, IP] 468 o Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE 469 label. 471 o D receives the packet, D will pop the last RSVP-TE label; since D 472 is a EH capable router it will search the stack and find the EH, 473 after processing the EH it will swap [102] to [101], and send the 474 packet to E over the normal FEC 476 stack = [101, VPN, GAL, ACH, HEH, EH, IP] 478 Note: this will be forwarded on the standard FEC because 479 since the EH is present in the packet, only packet without 480 an EH is forwarded on the "no EH present" FEC. 482 o E receives the packet [101]; since E is a EH capable router it 483 will search the stack and find the EH; after processing the EH it 484 will pop [101], and send the packet to E over the normal FEC 486 stack = [VPN, GAL, ACH, HEH, EH, IP] 488 Note: As E is the penultimate hop it will pop the standard 489 LDP label. 491 o F receives the packet with the VPN label on top [VPN]; E scans the 492 packet for EH; finds EH and processes. As F is the ultimate hop 493 it pops GAL, and removes ACH, HEH and EH, processes VPN label and 494 forwards the packet. 496 2.4.2. RSVP Tunnel and no EH present in the packet 498 o A sends packet to b 500 * stack = [104, VPN, IP] 502 o b receives the packet [104]; be is legacy router and will not 503 search for an EH; b swaps [104] to [102]; pushes [RSVP] sends 504 packet to D over the RSVP-TE tunnel. 506 * stack = [RSVP, 102, VPN, IP] 508 o Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE 509 label. 511 o D receives pops the tunnel label [RSVP], D is EH capable and scans 512 the packet for EH; D finds no EH is present; pops RSVP-TE label, 513 and then swaps LDP label [102 ]to [201] and sends the packet to E 515 * stack = [201, VPN, IP] 517 + Note: in this case D sends the packet using the "no EH 518 present" FEC, since there is no EH in the packet. 520 + Note: If the downstream LSR is not EH capable then D will 521 sends the packet on the standard FEC. 523 o E receives [201] and bypasses EH processing since the packet is 524 received on the "no EH present" FEC; E is the pen-ultimate hop so 525 it EH-FEC label and forward the packet to F 527 * stack = [VPN, IP] 529 o F receives the packet [VPN]; and scans the packet for EH; does not 530 find EH, processes VPN label and forwards the packet. 532 2.4.3. EH capable RSVP-TE tunnel 534 The case where an RSVP-TE tunnel is both EH capable and EH enabled is 535 for further study. 537 3. Security Considerations 539 TBA 541 4. IANA Considerations 543 There are no requests for IANA actions in this document. 545 Note to the RFC Editor - this section can be removed before 546 publication. 548 5. Acknowledgements 550 TBA 552 - 554 6. References 556 6.1. Normative References 558 [I-D.andersson-mpls-eh-architecture] 559 Andersson, L., Guichard, J., Song, H., and S. Bryant, 560 "MPLS Extension Header Architecture", draft-andersson- 561 mpls-eh-architecture-00 (work in progress), February 2019. 563 [I-D.song-mpls-eh-indicator] 564 Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for 565 MPLS Extension Header Indicator", draft-song-mpls-eh- 566 indicator-00 (work in progress), February 2019. 568 [I-D.song-mpls-extension-header] 569 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 570 Extension Header", draft-song-mpls-extension-header-02 571 (work in progress), February 2019. 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, 575 DOI 10.17487/RFC2119, March 1997, 576 . 578 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 579 "MPLS Generic Associated Channel", RFC 5586, 580 DOI 10.17487/RFC5586, June 2009, 581 . 583 6.2. Informative References 585 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 586 and Retiring Special-Purpose MPLS Labels", RFC 7274, 587 DOI 10.17487/RFC7274, June 2014, 588 . 590 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 591 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 592 May 2017, . 594 Authors' Addresses 596 Loa Andersson 597 Bronze Dragon Consulting 599 Email: loa@pi.nu 600 James N Guichard 601 Futurewei Technologies 603 Email: james.n.guichard@futurewei.com 605 Haoyu Song 606 Futurewei Technologies 608 Email: haoyu.song@futurewei.com 610 Stewart Bryant 611 Futurewei Technologies 613 Email: stewart.bryant@gmail.com