idnits 2.17.1 draft-chen-pce-sr-ingress-protection-07.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If a PCE receives an Open message from a PCC without a INGRESS_PROTECTION_CAPABILITY sub-TLV indicating PCC's support for the ingress protection of a type of paths, then the PCE MUST not send the PCC any request for ingress protection of the type of paths. -- The document date (13 November 2021) is 866 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'CE1' is mentioned on line 204, but not defined == Missing Reference: 'CE2' is mentioned on line 176, but not defined == Unused Reference: 'RFC7356' is defined on line 862, but no explicit reference was found in the text == Unused Reference: 'RFC5462' is defined on line 903, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 8424 == Outdated reference: A later version (-06) exists of draft-chen-bier-te-frr-01 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-07 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Chen 3 Internet-Draft M. McBride 4 Intended status: Standards Track Futurewei 5 Expires: 17 May 2022 M. Toy 6 G. Mishra 7 Verizon Inc. 8 A. Wang 9 China Telecom 10 Z. Li 11 Y. Liu 12 China Mobile 13 B. Khasanov 14 Yandex LLC 15 L. Liu 16 Fujitsu 17 X. Liu 18 Volta Networks 19 13 November 2021 21 Path Ingress Protections 22 draft-chen-pce-sr-ingress-protection-07 24 Abstract 26 This document describes extensions to Path Computation Element (PCE) 27 communication Protocol (PCEP) for fast protecting the ingress nodes 28 of two types of paths or tunnels, which are Segment Routing (SR) 29 paths and Bit Index Explicit Replication Tree/Traffic Engineering 30 (BIER-TE) paths. The extensions comprise a foundation for protecting 31 the ingress nodes of different types of paths. Based on this, the 32 ingress protection of a new type of paths can be easily supported. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 38 document are to be interpreted as described in RFC 2119 [RFC2119]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 17 May 2022. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Path Ingress Protection Examples . . . . . . . . . . . . . . 4 76 2.1. SR Path Ingress Protection Example . . . . . . . . . . . 4 77 2.2. BIER-TE Path Ingress Protection Example . . . . . . . . . 5 78 3. Behavior around Ingress Failure . . . . . . . . . . . . . . . 6 79 3.1. Source Detect . . . . . . . . . . . . . . . . . . . . . . 6 80 3.2. Backup Ingress Detect . . . . . . . . . . . . . . . . . . 6 81 3.3. Both Detect . . . . . . . . . . . . . . . . . . . . . . . 7 82 4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 7 83 4.1. Capabilities for Ingress Protection . . . . . . . . . . . 7 84 4.1.1. Capability for Ingress Protection with Backup 85 Ingress . . . . . . . . . . . . . . . . . . . . . . . 7 86 4.1.2. Capability for Ingress Protection with Traffic 87 Source . . . . . . . . . . . . . . . . . . . . . . . 9 88 4.2. Extensions for Backup Ingress and Traffic Source . . . . 10 89 4.2.1. Extensions for Backup Ingress . . . . . . . . . . . . 10 90 4.2.2. Extensions for Traffic Source . . . . . . . . . . . . 16 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 96 8.2. Informative References . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 The fast protection of a transit node in each type of paths or 102 tunnels have been proposed. For example, the fast protection of a 103 transit node in a Segment Routing (SR) path or tunnel is described in 104 [I-D.ietf-rtgwg-segment-routing-ti-lfa]. The fast protection of a 105 transit node of a "Bit Index Explicit Replication" (BIER) Traffic 106 Engineering (BIER-TE) path or tunnel is described in 107 [I-D.chen-bier-te-frr]. [RFC8424] presents extensions to RSVP-TE for 108 the fast protection of the ingress node of a traffic engineering (TE) 109 Label Switching Path (LSP). However, these documents do not discuss 110 any protocol extensions for the fast protection of the ingress node 111 of an SR path/tunnel, a BIER-TE path/tunnel, or other type of paths/ 112 tunnels. 114 This document fills that void and specifies protocol extensions to 115 Path Computation Element (PCE) communication Protocol (PCEP) 116 [RFC5440] and [RFC9050] for fast protecting the ingress nodes of two 117 types of paths: SR paths and BIER-TE paths. The extensions comprise 118 a foundation for protecting the ingress nodes of different types of 119 paths. Based on this, the ingress protection of a new type of paths 120 can be easily supported. 122 Ingress node and ingress, fast protection and protection, path 123 ingress protection and ingress protection, SR path and SR tunnel, as 124 well as BIER-TE path and BIER-TE tunnel will be used exchangeably in 125 the following sections. 127 1.1. Terminologies 129 The following terminologies are used in this document. 131 PCE: Path Computation Element or Path Computation Element server 133 PCEP: PCE communication Protocol 135 PCC: Path Computation Client 137 BIER: Bit Index Explicit Replication 139 BIFT: Bit Index Forwarding Table 141 CE: Customer Edge 143 PE: Provider Edge 145 TE: Traffic Engineering 146 SR: Segment Routing 148 LFA: Loop-Free Alternate 150 TI-LFA: Topology Independent LFA 152 BFD: Bidirectional Forwarding Detection 154 VPN: Virtual Private Network 156 L3VPN: Layer 3 VPN 158 FIB: Forwarding Information Base 160 2. Path Ingress Protection Examples 162 This section shows two examples of path ingress protection. One is 163 SR path ingress protection, and the other is BIER-TE path ingress 164 protection. 166 2.1. SR Path Ingress Protection Example 168 Figure 1 shows an example of protecting ingress PE1 of a SR path, 169 which is from ingress PE1 to egress PE3 and represented by *** in the 170 figure. 172 ******* ******* 173 [PE1]-----[P1]-----[PE3] PE1 Ingress 174 / | |# ##### | \ PEx Provider Edge 175 / | |# | \ CEx Customer Edge 176 [CE1] | |# | [CE2] Px Non Provider Edge 177 \ | |# | / *** SR Path 178 \ | ##### |# | / ### Backup SR Path 179 [PE2]-----[P2]-----[PE4] PE2 Backup Ingress 181 Figure 1: Protecting Ingress PE1 of SR Path 183 In normal operations, CE1 sends the traffic with destination PE3 to 184 ingress PE1, which imports the traffic into the SR path. 186 When CE1 detects the failure of ingress PE1, it switches the traffic 187 to backup ingress PE2, which imports the traffic from CE1 into a 188 backup SR path. The backup path is from the backup ingress PE2 to 189 the egress PE3 and represented by ### in the figure. When the 190 traffic is imported into the backup path, it is sent to the egress 191 PE3 along the path. 193 2.2. BIER-TE Path Ingress Protection Example 195 Figure 2 shows an example of protecting ingress PE1 of a BIER-TE 196 path, which is from ingress PE1 to egress nodes PE3 and PE4. This 197 primary BIER-TE path is represented by *** in the figure. The 198 ingress of the primary BIER-TE path is called primary ingress. 200 ******* ******* 201 [PE1]-----[P1]-----[PE3] PE1 Primary Ingress 202 / | #|*\##### | PEx Provider Edge 203 / | #| *\__ | CEx Customer Edge 204 [CE1] | #| ***\ | Px Non Provider Edge 205 \ | #| *\ | *** Primary BIER-TE Path 206 \ | #| *\ | ### Backup BIER-TE Path 207 [PE2]-----[P2]-----[PE4] PE2 Backup Ingress 208 ##### ##### 210 Figure 2: Protecting Ingress PE1 of BIER-TE Path 212 The backup BIER-TE path is from ingress PE2 to egress nodes PE3 and 213 PE4, which is represented by ### in the figure. The ingress of the 214 backup BIER-TE path is called backup ingress. 216 In normal operations, CE1 sends the packets with a multicast group 217 and source to ingress PE1, which imports/encapsulates the packets 218 into the BIER-TE path through adding a BIER-TE header. The header 219 contains the BIER-TE path from ingress PE1 to egress nodes PE3 and 220 PE4. 222 When CE1 detects the failure of ingress PE1 using a failure detection 223 mechanism such as BFD, it switches the traffic to backup ingress PE2, 224 which imports the traffic from CE1 into the backup BIER-TE path. 225 When the traffic is imported into the backup path, it is sent to the 226 egress nodes PE3 and PE4 along the path. 228 Given the traffic source (e.g., CE1), ingress (e.g., PE1) and 229 egresses (e.g., PE3 and PE4) of the primary BIER-TE path, the PCE 230 computes a backup ingress (e.g., PE2), a backup BIER-TE path from the 231 backup ingress to the egresses, and sends the backup BIER-TE path to 232 the PCC of the backup ingress. It also sends the information about 233 the backup ingress, the primary ingress and the traffic to the PCC of 234 the traffic source (e.g., CE1). 236 When the PCC of the traffic source receives the information about the 237 backup ingress, the primary ingress and the traffic, it sets up the 238 fast detection of the primary ingress failure and the switch over 239 target backup ingress. This setup lets the traffic source node 240 switch the traffic (to be sent to the primary ingress) to the backup 241 ingress when it detects the failure of the primary ingress. 243 When the PCC of the backup ingress receives the backup BIER-TE path, 244 it adds a forwarding entry into its BIFT. This entry encapsulates 245 the packets from the traffic source in the backup BIER-TE path. This 246 makes the backup ingress send the traffic received from the traffic 247 source to the egress nodes via the backup BIER-TE path. 249 3. Behavior around Ingress Failure 251 This section describes the behavior of some nodes connected to the 252 ingress before and after the ingress fails. These nodes are the 253 traffic source (e.g., CE1) and the backup ingress (e.g., PE2). It 254 presents three ways in which these nodes work together to protect the 255 ingress. The first way is called source detect, where the traffic 256 source is responsible for fast detecting the failure of the ingress. 257 The second way is called backup ingress detect, in which the backup 258 ingress is responsible for fast detecting the failure of the ingress. 259 The third way is called both detect, where both the traffic source 260 and the backup ingress are responsible for fast detecting the failure 261 of the ingress. 263 3.1. Source Detect 265 In normal operations, i.e., before the failure of the ingress of a 266 primary path such as a primary BIER-TE path, the traffic source sends 267 the traffic to the ingress of the primary path. The backup ingress 268 (e.g., PE2) is ready to import the traffic from the traffic source 269 into the backup path such as the backup BIER-TE path installed. 271 When the traffic source detects the failure of the ingress, it 272 switches the traffic to the backup ingress, which delivers the 273 traffic to the egress nodes of the path via the backup path. 275 3.2. Backup Ingress Detect 277 The traffic source (e.g., CE1) always sends the traffic to both the 278 ingress (e.g., PE1) of the primary path such as the primary BIER-TE 279 path and the backup ingress (e.g., PE2). 281 The backup ingress does not import any traffic from the traffic 282 source into the backup path such as the backup BIER-TE path in normal 283 operations. When it detects the failure of the ingress of the 284 primary path, it imports the traffic from the source into the backup 285 path. 287 For the backup ingress to fast detect the failure of the primary 288 ingress, it SHOULD directly connect to the primary ingress. When a 289 PCE computes a backup ingress and a backup path, it SHOULD consider 290 this. 292 3.3. Both Detect 294 In normal operations, i.e., before the failure of the ingress, the 295 traffic source sends the traffic to the ingress of the primary path 296 such as the primary BIER-TE path. When it detects the failure of the 297 ingress, it switches the traffic to the backup ingress. 299 The backup ingress does not import any traffic from the traffic 300 source into the backup path such as the backup BIER-TE path in normal 301 operations. When it detects the failure of the ingress of the 302 primary path, it imports the traffic from the source into the backup 303 path. 305 4. Extensions to PCEP 307 A PCC runs on each of the edge nodes such as PEs of a network 308 normally. A PCE runs on a server as a controller to communicate with 309 PCCs. PCE and PCCs work together to support protection for the 310 ingress of a path. The path is a SR path, a BIER-TE path, or a path 311 of another type. 313 4.1. Capabilities for Ingress Protection 315 4.1.1. Capability for Ingress Protection with Backup Ingress 317 When a PCE and a PCC running on a backup ingress establish a PCEP 318 session between them, they exchange their capabilities of supporting 319 protection for the ingress node of each of different types of paths. 321 A new sub-TLV called INGRESS_PROTECTION_CAPABILITY is defined. It is 322 included in the PATH_SETUP_TYPE_CAPABILITY TLV with PST = TBD1 323 (suggested value 2 for path ingress protection) in the OPEN object, 324 which is exchanged in Open messages when a PCC and a PCE establish a 325 PCEP session between them. Its format is illustrated below. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type = TBD2 | Length=4 | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Reserved | PathInd |S|B| Flags |D|A| 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Figure 3: INGRESS_PROTECTION_CAPABILITY sub-TLV 337 Type: TBD2 is to be assigned by IANA. 339 Length: 4. 341 Reserved: 2 octets. MUST be set to zero in transmission and ignored 342 on reception. 344 PathInd: 1 octet. Indicators for the types of paths whose ingress 345 protections are supported. Two indicators are defined. 347 o S : S = 1 indicating that the ingress protection of a SR path 348 is supported. 350 o B : B = 1 indicating that the ingress protection of a BIER-TE 351 path is supported. 353 Flags: 1 octet. Two flags are defined. 355 o D flag: A PCC sets this flag to 1 to indicate that it is able 356 to detect its adjacent node's failure quickly. 358 o A flag: A PCE sets this flag to 1 to request a PCC to let the 359 forwarding entry for the backup path/tunnel be Active. 361 A PCC, which supports ingress protection for different types of 362 paths, sends a PCE an Open message containing 363 INGRESS_PROTECTION_CAPABILITY sub-TLV. This sub-TLV indicates that 364 the PCC is capable of supporting the ingress protection for the types 365 of paths. 367 For example, if a PCC supports ingress protection for SR path and 368 BIER-TE path, the PCC sends a PCE an Open message containing 369 INGRESS_PROTECTION_CAPABILITY sub-TLV with S = 1 and B = 1. 371 A PCE, which supports ingress protection for different types of 372 paths, sends a PCC an Open message containing 373 INGRESS_PROTECTION_CAPABILITY sub-TLV. This sub-TLV indicates that 374 the PCE is capable of supporting the ingress protection for the types 375 of paths. 377 If both a PCC and a PCE support INGRESS_PROTECTION_CAPABILITY, each 378 of the Open messages sent by the PCC and PCE contains PATH-SETUP- 379 TYPE-CAPABILITY TLV with a PST list containing PST=TBD1 and an 380 INGRESS_PROTECTION_CAPABILITY sub-TLV. 382 If a PCE receives an Open message from a PCC without a 383 INGRESS_PROTECTION_CAPABILITY sub-TLV indicating PCC's support for 384 the ingress protection of a type of paths, then the PCE MUST not send 385 the PCC any request for ingress protection of the type of paths. 387 If a PCC receives an Open message from a PCE without a 388 INGRESS_PROTECTION_CAPABILITY sub-TLV indicating PCE's support for 389 the ingress protection of a type of paths, then the PCC MUST ignore 390 any request for ingress protection of the type of paths from the PCE. 392 If a PCC sets D flag to zero, then the PCE SHOULD send the PCC an 393 Open message with A flag set to one and the fast detection of the 394 failure of the primary ingress MUST be done by the traffic source. 395 When the PCE sends the PCC a message for initiating a backup path, 396 the PCC MUST let the forwarding entry for the backup path be Active. 398 4.1.2. Capability for Ingress Protection with Traffic Source 400 When a PCE and a PCC running on a traffic source node establish a 401 PCEP session between them, they exchange their capabilities of 402 supporting ingress protection. 404 The PCECC-CAPABILITY sub-TLV defined in [RFC9050] is included in the 405 OPEN object in the PATH-SETUP-TYPE-CAPABILITY TLV, which is exchanged 406 in Open messages when a PCC and a PCE establish a PCEP session 407 between them. 409 A new flag bit P is defined in the Flags field of the PCECC- 410 CAPABILITY sub-TLV: 412 * P flag (for Ingress Protection): if set to 1 by a PCEP speaker, 413 the P flag indicates that the PCEP speaker supports and is willing 414 to handle the PCECC based central controller instructions for 415 ingress protection. The bit MUST be set to 1 by both a PCC and a 416 PCE for the PCECC ingress protection instruction download/report 417 on a PCEP session. 419 4.2. Extensions for Backup Ingress and Traffic Source 421 This section specifies the extensions to PCEP for the backup ingress 422 and the traffic source. The extensions let the traffic source 424 S1: fast detect the failure of the primary ingress and switch the 425 traffic to the backup ingress when the traffic source detects the 426 failure of the primary ingress, or 428 S2: always send the traffic to both the primary ingress and the 429 backup ingress. 431 The extensions let the backup ingress 433 B1: always import the traffic received from the traffic source with 434 possible service ID into the backup path, or 436 B2: import the traffic with possible service ID into the backup path 437 when the backup ingress detects the failure of the primary 438 ingress. 440 The following lists the combinations of Si and Bi (i = 1,2) for 441 different ways of failure detects. 443 Source Detect: S1 and B1. 445 Backup Ingress Detect: S2 and B2. 447 Both Detect: S1 and B2. 449 4.2.1. Extensions for Backup Ingress 451 For the packets from the traffic source, if the primary ingress 452 (i.e., the ingress of the primary path) encapsulates the packets with 453 a service ID or label into the path, the backup ingress MUST have 454 this service ID or label and encapsulates the packets with the 455 service ID or label into the backup path when the primary ingress 456 fails. 458 If the backup ingress is requested to detect the failure of the 459 primary ingress, it MUST have the information about the primary 460 ingress such as the address of the primary ingress. 462 A new sub-TLV called INGRESS_PROTECTION is defined. When a PCE sends 463 a PCC a PCInitiate message for initiating a backup path to protect 464 the primary ingress node of a primary path, the message contains this 465 TLV in the RP/SRP object. Its format is illustrated below. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Type = TBD3 | Length (variable) | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Reserved | Flags |A| 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 ~ ~ 475 ~ sub-TLVs (optional) ~ 476 ~ ~ 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 4: INGRESS_PROTECTION sub-TLV 481 Type: TBD3 is to be assigned by IANA. 483 Length: Variable. 485 Reserved: 2 octets. MUST be set to zero in transmission and ignored 486 on reception. 488 Flags: 2 octets. One flag is defined. 490 A flag bit: it is set to 1 or 0 by PCE. 492 o 1 is to request the backup ingress to let the forwarding 493 entry for the backup path be Active always. In this case, 494 the traffic source detects the failure of the primary 495 ingress and switches the traffic to the backup ingress when 496 it detects the failure. 498 o 0 is to request the backup ingress to detect the failure of 499 the primary ingress and let the forwarding entry for the 500 backup path be Active when the primary ingress fails. In 501 this case, the TLV includes the primary ingress address in a 502 Primary-Ingress sub-TLV. The traffic source can send the 503 traffic to both the primary ingress and the backup ingress. 504 It may switch the traffic to the backup ingress from the 505 primary ingress when it detects the failure of the primary 506 ingress. 508 Three optional sub-TLVs are defined: Primary-Ingress sub-TLV, Service 509 sub-TLV, and Traffic-Description sub-TLV. The Traffic-Description 510 sub-TLV describes the traffic to be imported into the backup SR path. 511 The Multicast Flow Specification TLV for IPv4 or IPv6, which is 512 defined in [I-D.ietf-pce-pcep-flowspec], is used as a sub-TLV to 513 indicate the traffic to be imported into the backup BIER-TE path. 515 4.2.1.1. Primary-Ingress sub-TLV 517 A Primary-Ingress sub-TLV indicates the IP address of the primary 518 ingress node of a primary path. It has two formats: one for primary 519 ingress node IPv4 address and the other for primary ingress node IPv6 520 address, which are illustrated below. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type = TBD4 | Length (4) | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Primary Ingress IPv4 Address (4 octets) | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 5: Primary Ingress IPv4 Address sub-TLV 532 Type: TBD4 is to be assigned by IANA. 534 Length: 4. 536 Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host 537 address of the primary ingress node of a path. 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Type = TBD5 | Length (16) | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Primary Ingress IPv6 Address (16 octets) | 545 ~ ~ 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 6: Primary Ingress IPv6 Address sub-TLV 550 Type: TBD5 is to be assigned by IANA. 552 Length: 16. 554 Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host 555 address of the primary ingress node of a path. 557 4.2.1.2. Service sub-TLV 559 A Service sub-TLV contains a service ID or label to be added into a 560 packet to be carried by a path. It has two formats: one for the 561 service identified by a label and the other for the service 562 identified by a service identifier (ID) of 32 or 128 bits, which are 563 illustrated below. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type = TBD6 | Length (4) | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | zero | Service Label (20 bits) | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Figure 7: Service Label sub-TLV 575 Type: TBD6 is to be assigned by IANA. 577 Length: 4. 579 Service Label: the least significant 20 bits. It represents a label 580 of 20 bits. 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type = TBD7 | Length (4/16) | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Service ID (4 or 16 octets) | 588 ~ ~ 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 Figure 8: Service ID sub-TLV 593 Type: TBD7 is to be assigned by IANA. 595 Length: 4 or 16. 597 Service ID: 4 or 16 octets. It represents Identifier (ID) of a 598 service in 4 or 16 octets. 600 4.2.1.3. Traffic-Description sub-TLV 602 A Traffic-Description sub-TLV describes the traffic to be imported 603 into a backup SR path. Its format is illustrated below. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type = TBD8 | Length (variable) | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 ~ ~ 611 ~ sub-TLVs (optional) ~ 612 ~ ~ 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 9: Traffic-Description sub-TLV 617 Type: TBD8 is to be assigned by IANA. 619 Length: Variable. 621 Two optional sub-TLVs are defined. One is FEC sub-TLV and the other 622 interface sub-TLV. 624 A FEC sub-TLV describes the traffic to be imported into the backup 625 path. It is an IP prefix with an optional virtual network ID. It 626 has two formats: one for IPv4 and the other for IPv6, which are 627 illustrated below. 629 0 1 2 3 630 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 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Type = TBD9 | Length (variable) | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 |IPv4 Prefix Len| IPv4 Prefix ~ 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 ~ (Optional) Virtual Network ID (2 octets) ~ 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Figure 10: IPv4 FEC sub-TLV 641 Type: TBD9 is to be assigned by IANA. 643 Length: Variable. 645 IPv4 Prefix Len: Indicates the length of the IPv4 Prefix. 647 IPv4 Prefix: IPv4 Prefix rounded to octets. 649 Virtual Network ID: 2 octets. This is optional. It indicates the 650 ID of a virtual network. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type = TBDa | Length (variable) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 |IPv6 Prefix Len| IPv6 Prefix ~ 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 ~ Optional Virtual Network ID (2 octets) ~ 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Figure 11: IPv6 FEC sub-TLV 664 Type: TBDa is to be assigned by IANA. 666 Length: Variable. 668 IPv6 Prefix Len: Indicates the length of the IPv6 Prefix. 670 IPv6 Prefix: IPv6 Prefix rounded to octets. 672 Virtual Network ID: 2 octets. This is optional. It indicates the 673 ID of a virtual network. 675 An Interface sub-TLV indicates the interface from which the traffic 676 is received and imported into the backup path. It has three formats: 677 one for interface index, the other two for IPv4 and IPv6 address, 678 which are illustrated below. 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type = TBDb | Length (4) | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Interface Index (4 octets) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure 12: Interface Index sub-TLV 690 Type: TBDb is to be assigned by IANA. 692 Length: 4. 694 Interface Index: 4 octets. It indicates the index of an interface. 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Type = TBDc | Length (4) | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Interface IPv4 Address (4 octets) | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Figure 13: Interface IPv4 Address sub-TLV 706 Type: TBDc is to be assigned by IANA. 708 Length: 4. 710 Interface IPv4 Address: 4 octets. It represents the IPv4 address of 711 an interface. 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Type = TBDd | Length (16) | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Interface IPv6 Address (16 octets) | 719 ~ ~ 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Figure 14: Interface IPv6 Address sub-TLV 724 Type: TBDd is to be assigned by IANA. 726 Length: 16. 728 Interface IPv6 Address: 16 octets. It represents the IPv6 address 729 of an interface. 731 4.2.2. Extensions for Traffic Source 733 If the traffic source is requested to detect the failure of the 734 primary ingress and switch the traffic (to be sent to the primary 735 ingress) to the backup ingress when the primary ingress fails, it 736 MUST have the information about the backup ingress, the primary 737 ingress and the traffic. This information may be transferred via a 738 CCI object for INGRESS-PROTECTION to the PCC of the traffic source 739 node from a PCE. 741 If the traffic source PCC does not accept the request from the PCE or 742 support the extensions, the PCE SHOULD have the information about the 743 behavior of the traffic source configured such as whether it detects 744 the failure of the primary ingress. Based on the information, the 745 PCE instructs the backup ingress accordingly. 747 The Central Control Instructions (CCI) Object is defined in [RFC9050] 748 for a PCE as a controller to send instructions for LSPs to a PCC. 749 This document defines a new object-type (TBDt) for ingress protection 750 based on the CCI object. The body of the object with the new object- 751 type is illustrated below. The object may be in PCRpt, PCUpd, or 752 PCInitiate message. 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | CC-ID | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Reserved | Flags |B|D| 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | | 762 // Optional TLV // 763 | | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 Figure 15: INGRESS-PROTECTION Object Body 768 CC-ID: It is the same as described in [RFC9050]. 770 Flags: Two flag bits D and B are defined as follows: 772 D: D = 1 instructs the PCC of the traffic source to Detect the 773 failure of the primary ingress and switch the traffic to the 774 backup ingress when it detects the failure. 776 B: B = 1 instructs the PCC of the traffic source to send the 777 traffic to Both the primary ingress and the backup ingress. 779 Optional TLV: Primary ingress TLV, backup ingress TLV, Traffic- 780 Description TLV or Multicast Flow Specification TLV. 782 The primary ingress sub-TLV defined above is used as a TLV to contain 783 the information about the primary ingress in the object. The 784 Traffic-Description sub-TLV defined above is used as a TLV to contain 785 the information about the traffic for a SR path in the object. The 786 Multicast Flow Specification TLV for IPv4 or IPv6, which is defined 787 in [I-D.ietf-pce-pcep-flowspec], is used to contain the information 788 about the traffic for a BIER-TE path in the object. A new TLV, 789 called backup ingress TLV, is defined to contain the information 790 about the backup ingress in the object. 792 4.2.2.1. Backup-Ingress TLV 794 A Backup-Ingress TLV indicates the IP address of the ingress node of 795 a backup path. It has two formats: one for backup ingress node IPv4 796 address and the other for backup ingress node IPv6 address, which are 797 illustrated below. They have the same format as the Primary-Ingress 798 sub-TLVs. 800 0 1 2 3 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Type = TBDe | Length (4) | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Backup Ingress IPv4 Address (4 octets) | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Figure 16: Backup Ingress IPv4 Address TLV 810 Type: TBDe is to be assigned by IANA. 812 Length: 4. 814 Backup Ingress IPv4 Address: 4 octets. It represents an IPv4 host 815 address of the backup ingress. 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Type = TBDf | Length (16) | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Backup Ingress IPv6 Address (16 octets) | 823 ~ ~ 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 Figure 17: Backup Ingress IPv6 Address TLV 828 Type: TBDf is to be assigned by IANA. 830 Length: 16. 832 Backup Ingress IPv6 Address: 16 octets. It represents an IPv6 host 833 address of the backup ingress node. 835 5. Security Considerations 837 TBD 839 6. Acknowledgements 841 The authors of this document would like to thank Dhruv Dhody and 842 Robin Li for their reviews and comments. 844 7. IANA Considerations 846 TBD 848 8. References 850 8.1. Normative References 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, 854 DOI 10.17487/RFC2119, March 1997, 855 . 857 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 858 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 859 DOI 10.17487/RFC5440, March 2009, 860 . 862 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 863 Scope Link State PDUs (LSPs)", RFC 7356, 864 DOI 10.17487/RFC7356, September 2014, 865 . 867 [RFC8424] Chen, H., Ed. and R. Torvi, Ed., "Extensions to RSVP-TE 868 for Label Switched Path (LSP) Ingress Fast Reroute (FRR) 869 Protection", RFC 8424, DOI 10.17487/RFC8424, August 2018, 870 . 872 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 873 Computation Element Communication Protocol (PCEP) 874 Procedures and Extensions for Using the PCE as a Central 875 Controller (PCECC) of LSPs", RFC 9050, 876 DOI 10.17487/RFC9050, July 2021, 877 . 879 8.2. Informative References 881 [I-D.chen-bier-te-frr] 882 Chen, H., McBride, M., Liu, Y., Wang, A., Mishra, G. S., 883 Fan, Y., Liu, L., and X. Liu, "BIER-TE Fast ReRoute", Work 884 in Progress, Internet-Draft, draft-chen-bier-te-frr-01, 23 885 August 2021, . 888 [I-D.ietf-pce-pcep-flowspec] 889 Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow 890 Specification", Work in Progress, Internet-Draft, draft- 891 ietf-pce-pcep-flowspec-13, 14 October 2021, 892 . 895 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 896 Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., 897 Decraene, B., and D. Voyer, "Topology Independent Fast 898 Reroute using Segment Routing", Work in Progress, 899 Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 900 07, 29 June 2021, . 903 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 904 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 905 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 906 2009, . 908 Authors' Addresses 910 Huaimo Chen 911 Futurewei 912 Boston, MA, 913 United States of America 915 Email: Huaimo.chen@futurewei.com 917 Mike McBride 918 Futurewei 920 Email: michael.mcbride@futurewei.com 922 Mehmet Toy 923 Verizon Inc. 924 United States of America 926 Email: mehmet.toy@verizon.com 927 Gyan S. Mishra 928 Verizon Inc. 929 13101 Columbia Pike 930 Silver Spring, MD 20904 931 United States of America 933 Phone: 301 502-1347 934 Email: gyan.s.mishra@verizon.com 936 Aijun Wang 937 China Telecom 938 Beiqijia Town, Changping District 939 Beijing 940 102209 941 China 943 Email: wangaj3@chinatelecom.cn 945 Zhenqiang Li 946 China Mobile 947 32 Xuanwumen West Ave, Xicheng District 948 Beijing 949 100053 950 China 952 Email: lizhengqiang@chinamobile.com 954 Yisong Liu 955 China Mobile 957 Email: liuyisong@chinamobile.com 959 Boris Khasanov 960 Yandex LLC 961 Moscow 963 Email: bhassanov@yahoo.com 965 Lei Liu 966 Fujitsu 967 United States of America 969 Email: liulei.kddi@gmail.com 970 Xufeng Liu 971 Volta Networks 972 McLean, VA 973 United States of America 975 Email: xufeng.liu.ietf@gmail.com