idnits 2.17.00 (12 Aug 2021) /tmp/idnits45530/draft-chen-pce-bier-te-ingress-protect-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: ---------------------------------------------------------------------------- == 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 without a BIER-TE_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCC, then the PCE MUST not send the PCC any request for ingress protection of a BIER-TE path/tunnel. -- The document date (10 January 2022) is 124 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 135, but not defined == Unused Reference: 'RFC5440' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC8231' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 685, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-chen-bier-te-frr-01 == Outdated reference: draft-ietf-pce-pcep-extension-for-pce-controller has been published as RFC 9050 == Outdated reference: draft-ietf-pce-pcep-flowspec has been published as RFC 9168 Summary: 0 errors (**), 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: 14 July 2022 G. Mishra 6 Verizon Inc. 7 Y. Liu 8 China Mobile 9 A. Wang 10 China Telecom 11 L. Liu 12 Fujitsu 13 X. Liu 14 Volta Networks 15 10 January 2022 17 PCE for BIER-TE Ingress Protection 18 draft-chen-pce-bier-te-ingress-protect-01 20 Abstract 22 This document describes extensions to Path Computation Element (PCE) 23 communication Protocol (PCEP) for protecting the ingress of a BIER-TE 24 path. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 14 July 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. BIER-TE Path Ingress Protection Example . . . . . . . . . . . 3 68 4. Behavior around Ingress Failure . . . . . . . . . . . . . . . 4 69 4.1. Source Detect . . . . . . . . . . . . . . . . . . . . . . 5 70 4.2. Backup Ingress Detect . . . . . . . . . . . . . . . . . . 5 71 4.3. Both Detect . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Capability for Ingress Protection . . . . . . . . . . . . 6 74 5.1.1. Capability for Ingress Protection with Backup 75 Ingress . . . . . . . . . . . . . . . . . . . . . . . 6 76 5.1.2. Capability for Ingress Protection with Traffic 77 Source . . . . . . . . . . . . . . . . . . . . . . . 7 78 5.2. BIER-TE Path Ingress Protection . . . . . . . . . . . . . 8 79 5.2.1. Extensions for Backup Ingress . . . . . . . . . . . . 9 80 5.2.2. Extensions for Traffic Source . . . . . . . . . . . . 12 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 9.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The fast protection of a transit node of a "Bit Index Explicit 92 Replication" (BIER) Traffic Engineering (BIER-TE) path or tunnel is 93 described in [I-D.chen-bier-te-frr]. [RFC8424] presents extensions 94 to RSVP-TE for the fast protection of the ingress node of a traffic 95 engineering (TE) Label Switching Path (LSP). However, these 96 documents do not discuss any protocol extensions for the fast 97 protection of the ingress node of a BIER-TE path or tunnel. 99 This document fills that gap and specifies protocol extensions to 100 Path Computation Element (PCE) communication Protocol (PCEP) for the 101 fast protection of the ingress node of a BIER-TE path or tunnel. 102 Ingress node and ingress, fast protection and protection as well as 103 BIER-TE path and BIER-TE tunnel will be used exchangeably in the 104 following sections. 106 2. Terminologies 108 The following terminologies are used in this document. 110 PCE: Path Computation Element 112 PCEP: PCE communication Protocol 114 PCC: Path Computation Client 116 BIER: Bit Index Explicit Replication 118 CE: Customer Edge 120 PE: Provider Edge 122 TE: Traffic Engineering 124 3. BIER-TE Path Ingress Protection Example 126 Figure 1 shows an example of protecting ingress PE1 of a BIER-TE 127 path, which is from ingress PE1 to egress nodes PE3 and PE4. This 128 primary BIER-TE path is represented by *** in the figure. The 129 ingress of the primary BIER-TE path is called primary ingress. 131 ******* ******* 132 [PE1]-----[P1]-----[PE3] PE1 Primary Ingress 133 / | #|*\##### | PEx Provider Edge 134 / | #| *\__ | CEx Customer Edge 135 [CE1] | #| ***\ | Px Non Provider Edge 136 \ | #| *\ | *** Primary BIER-TE Path 137 \ | #| *\ | ### Backup BIER-TE Path 138 [PE2]-----[P2]-----[PE4] PE2 Backup Ingress 139 ##### ##### 141 Figure 1: Protecting Ingress PE1 of BIER-TE Path 143 The backup BIER-TE path is from ingress PE2 to egress nodes PE3 and 144 PE4, which is represented by ### in the figure. The ingress of the 145 backup BIER-TE path is called backup ingress. 147 In normal operations, CE1 sends the packets with a multicast group 148 and source to ingress PE1, which imports/encapsulates the packets 149 into the BIER-TE path through adding a BIER-TE header. The header 150 contains the BIER-TE path from ingress PE1 to egress nodes PE3 and 151 PE4. 153 When CE1 detects the failure of ingress PE1 using a failure detection 154 mechanism such as BFD, it switches the traffic to backup ingress PE2, 155 which imports the traffic from CE1 into the backup BIER-TE path. 156 When the traffic is imported into the backup path, it is sent to the 157 egress nodes PE3 and PE4 along the path. 159 Given the traffic source (e.g., CE1), ingress (e.g., PE1) and 160 egresses (e.g., PE3 and PE4) of the primary BIER-TE path, the PCE 161 computes a backup ingress (e.g., PE2), a backup BIER-TE path from the 162 backup ingress to the egresses, and sends the backup BIER-TE path to 163 the PCC of the backup ingress. It also sends the backup ingress, 164 primary ingress and the traffic description to the PCC of the traffic 165 source (e.g., CE1). 167 When the PCC of the traffic source receives the backup ingress, 168 primary ingress and traffic description, it sets up the fast 169 detection of the primary ingress failure and the switch over target 170 backup ingress. This setup lets the traffic source node switch the 171 traffic (to be sent to the primary ingress) to the backup ingress 172 when it detects the failure of the primary ingress. 174 When the PCC of the backup ingress receives the backup BIER-TE path, 175 it adds a forwarding entry into its BIFT. This entry encapsulates 176 the packets from the traffic source in the backup BIER-TE path. This 177 makes the backup ingress send the traffic received from the traffic 178 source to the egress nodes via the backup BIER-TE path. 180 4. Behavior around Ingress Failure 182 This section describes the behavior of some nodes connected to the 183 ingress before and after the ingress fails. These nodes are the 184 traffic source (e.g., CE1) and the backup ingress (e.g., PE2). It 185 presents three ways in which these nodes work together to protect the 186 ingress. The first way is called source detect, where the traffic 187 source is responsible for fast detecting the failure of the ingress. 188 The second way is called backup ingress detect, in which the backup 189 ingress is responsible for fast detecting the failure of the ingress. 190 The third way is called both detect, where both the traffic source 191 and the backup ingress are responsible for fast detecting the failure 192 of the ingress. 194 4.1. Source Detect 196 In normal operations, i.e., before the failure of the ingress, the 197 traffic source sends the traffic to the ingress of the primary BIER- 198 TE path. The backup ingress (e.g., PE2) is ready to import the 199 traffic from the traffic source into the backup BIER-TE path 200 installed. 202 When the traffic source detects the failure of the ingress, it 203 switches the traffic to the backup ingress, which delivers the 204 traffic to the egress nodes of the BIER-TE path via the backup BIER- 205 TE path. 207 4.2. Backup Ingress Detect 209 The traffic source (e.g., CE1) always sends the traffic to both the 210 ingress (e.g., PE1) of the primary BIER-TE path and the backup 211 ingress (e.g., PE2). 213 The backup ingress does not import any traffic from the traffic 214 source into the backup BIER-TE path in normal operations. When it 215 detects the failure of the ingress of the primary BIER-TE path, it 216 imports the traffic from the source into the backup BIER-TE path. 218 For the backup ingress to fast detect the failure of the primary 219 ingress, it SHOULD directly connect to the primary ingress. When a 220 PCE computes a backup ingress and a backup BIER-TE path, it SHOULD 221 consider this. 223 4.3. Both Detect 225 In normal operations, i.e., before the failure of the ingress, the 226 traffic source sends the traffic to the ingress of the primary BIER- 227 TE path. When it detects the failure of the ingress, it switches the 228 traffic to the backup ingress. 230 The backup ingress does not import any traffic from the traffic 231 source into the backup BIER-TE path in normal operations. When it 232 detects the failure of the ingress of the primary BIER-TE path, it 233 imports the traffic from the source into the backup BIER-TE path. 235 5. Extensions to PCEP 237 A PCC runs on each of the edge nodes such as PEs and CEs of a network 238 normally. A PCE runs on a server as a controller to communicate with 239 PCCs. The PCE and the PCCs running on backup ingress PEs and traffic 240 source CEs work together to support protection for the ingress of a 241 BIER-TE path. 243 5.1. Capability for Ingress Protection 245 5.1.1. Capability for Ingress Protection with Backup Ingress 247 When a PCE and a PCC running on a backup ingress establish a PCEP 248 session between them, they exchange their capabilities of supporting 249 protection for the ingress node of a BIER-TE path/tunnel. 251 A new sub-TLV called BIER-TE_INGRESS_PROTECTION_CAPABILITY is 252 defined. It is included in the PATH_SETUP_TYPE_CAPABILITY TLV with 253 PST = TBD1 (suggested value 2 for protecting the ingress of a BIER-TE 254 path/tunnel) in the OPEN object, which is exchanged in Open messages 255 when a PCC and a PCE establish a PCEP session between them. Its 256 format is illustrated below. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type = TBD2 | Length=4 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Reserved | Flags |D|A| 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 2: BIER-TE_INGRESS_PROTECTION_CAPABILITY sub-TLV 268 Type: TBD2 is to be assigned by IANA. 270 Length: 4. 272 Reserved: 2 octets. Must be set to zero in transmission and ignored 273 on reception. 275 Flags: 2 octets. Two flag bits are defined. 277 o D flag bit: A PCC sets this flag to 1 to indicate that it is 278 able to detect its adjacent node's failure quickly. 280 o A flag bit: A PCE sets this flag to 1 to request a PCC to let 281 the forwarding entry for the backup BIER-TE path/tunnel be 282 Active. 284 A PCC, which supports ingress protection for a BIER-TE tunnel/path, 285 sends a PCE an Open message containing BIER- 286 TE_INGRESS_PROTECTION_CAPABILITY sub-TLV. This sub-TLV indicates 287 that the PCC is capable of supporting the ingress protection for a 288 BIER-TE tunnel/path. 290 A PCE, which supports ingress protection for a BIER-TE tunnel/path, 291 sends a PCC an Open message containing BIER- 292 TE_INGRESS_PROTECTION_CAPABILITY sub-TLV. This sub-TLV indicates 293 that the PCE is capable of supporting the ingress protection for a 294 BIER-TE tunnel/path. 296 If both a PCC and a PCE support BIER- 297 TE_INGRESS_PROTECTION_CAPABILITY, each of the Open messages sent by 298 the PCC and PCE contains PATH-SETUP-TYPE-CAPABILITY TLV with a PST 299 list containing PST=TBD1 and a BIER-TE-INGRESS_PROTECTION_CAPABILITY 300 sub-TLV. 302 If a PCE receives an Open message without a BIER- 303 TE_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCC, then the PCE 304 MUST not send the PCC any request for ingress protection of a BIER-TE 305 path/tunnel. 307 If a PCC receives an Open message without a BIER- 308 TE_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCE, then the PCC 309 MUST ignore any request for ingress protection of a BIER-TE path/ 310 tunnel from the PCE. 312 If a PCC sets D flag to zero, then the PCE SHOULD send the PCC an 313 Open message with A flag set to one and the fast detection of the 314 failure of the primary ingress MUST be done by the traffic source. 315 When the PCE sends the PCC a message for initiating a backup BIER-TE 316 path, the PCC MUST let the forwarding entry for the backup BIER-TE 317 path be Active. 319 5.1.2. Capability for Ingress Protection with Traffic Source 321 When a PCE and a PCC running on a traffic source node establish a 322 PCEP session between them, they exchange their capabilities of 323 supporting protection for the ingress node of a BIER-TE path/tunnel. 325 The PCECC-CAPABILITY sub-TLV defined in 326 [I-D.ietf-pce-pcep-extension-for-pce-controller] is included in the 327 OPEN object in the PATH-SETUP-TYPE-CAPABILITY TLV, which is exchanged 328 in Open messages when a PCC and a PCE establish a PCEP session 329 between them. 331 A new flag bit P is defined in the Flags field of the PCECC- 332 CAPABILITY sub-TLV: 334 * P flag (for Ingress Protection): if set to 1 by a PCEP speaker, 335 the P flag indicates that the PCEP speaker supports and is willing 336 to handle the PCECC based central controller instructions for 337 ingress protection. The bit MUST be set to 1 by both a PCC and a 338 PCE for the PCECC ingress protection instruction download/report 339 on a PCEP session. 341 5.2. BIER-TE Path Ingress Protection 343 This section specifies the extensions to PCEP for the backup ingress 344 and the traffic source. The extensions let the traffic source 346 S1: fast detect the failure of the primary ingress and switch the 347 traffic to the backup ingress when the traffic source detects the 348 failure of the primary ingress, or 350 S2: always send the traffic to both the primary ingress and the 351 backup ingress. 353 The extensions let the backup ingress 355 B1: always import the traffic received from the traffic source with 356 possible service ID into the backup BIER-TE path, or 358 B2: import the traffic with possible service ID into the backup 359 BIER-TE path when the backup ingress detects the failure of the 360 primary ingress. 362 The following lists the combinations of Si and Bi (i = 1,2) for 363 different ways of failure detects. 365 Source Detect: S1 and B1. 367 Backup Ingress Detect: S2 and B2. 369 Both Detect: S1 and B2. 371 5.2.1. Extensions for Backup Ingress 373 For the packets from the traffic source, if the primary ingress 374 (i.e., the ingress of the primary BIER-TE path) encapsulates the 375 packets with a service ID or label into the BIER-TE path, the backup 376 ingress MUST have this service ID or label and encapsulates the 377 packets with the service ID or label into the backup BIER-TE path 378 when the primary ingress fails. 380 If the backup ingress is requested to detect the failure of the 381 primary ingress, it MUST have the information about the primary 382 ingress such as the address of the primary ingress. 384 A new TLV called BIER-TE_INGRESS_PROTECTION TLV is defined to 385 transfer the information about the primary ingress and/or the service 386 ID or label. When a PCE sends the PCC of a backup ingress a 387 PCInitiate message for initiating a backup BIER-TE path/tunnel to 388 protect the primary ingress of a primary BIER-TE path/tunnel, the 389 message contains this TLV in the RP/SRP object. Its format is 390 illustrated below. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type = TBD3 | Length (variable) | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Reserved | Flags |A| 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 ~ ~ 400 ~ sub-TLVs (optional) ~ 401 ~ ~ 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 3: BIER-TE_INGRESS_PROTECTION TLV 406 Type: TBD3 is to be assigned by IANA. 408 Length: Variable. 410 Reserved: 2 octets. Must be set to zero in transmission and ignored 411 on reception. 413 Flags: 2 octets. One flag bit is defined. 415 A flag bit: it is set to 1 or 0 by PCE. 417 o 1 is to request the backup ingress to let the forwarding 418 entry for the backup BIER-TE path/tunnel be Active always. 419 In this case, the traffic source detects the failure of the 420 primary ingress and switches the traffic to the backup 421 ingress when it detects the failure. 423 o 0 is to request the backup ingress to detect the failure of 424 the primary ingress and let the forwarding entry for the 425 backup BIER-TE path/tunnel be Active when the primary 426 ingress fails. In this case, the TLV includes the primary 427 ingress address in a Primary-Ingress sub-TLV. The traffic 428 source can send the traffic to both the primary ingress and 429 the backup ingress. It may switch the traffic to the backup 430 ingress from the primary ingress when it detects the failure 431 of the primary ingress. 433 Two optional sub-TLVs are defined. One is Service sub-TLV. The 434 other is Primary-Ingress sub-TLV. The Multicast Flow Specification 435 TLV for IPv4 or IPv6, which is defined in 436 [I-D.ietf-pce-pcep-flowspec], is used as a sub-TLV to indicate the 437 traffic to be imported into the backup BIER-TE path. 439 5.2.1.1. Service sub-TLV 441 A Service sub-TLV contains a service label such as VPN service label 442 or ID to be added into a packet to be carried by a BIER-TE path/ 443 tunnel. It has two formats: one for the service identified by a 444 label and the other for the service identified by a service 445 identifier (ID) of 32 or 128 bits, which are illustrated below. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type = TBD4 | Length (4) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | zero | Service Label (20 bits) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 4: Service Label sub-TLV 457 Type: TBD4 is to be assigned by IANA. 459 Length: 4. 461 Service Label: the least significant 20 bits. It represents a label 462 of 20 bits. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Type = TBD5 | Length (4/16) | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Service ID (4 or 16 octets) | 470 ~ ~ 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 5: Service ID sub-TLV 475 Type: TBD5 is to be assigned by IANA. 477 Length: 4 or 16. 479 Service ID: 4 or 16 octets. It represents Identifier (ID) of a 480 service in 4 or 16 octets. 482 5.2.1.2. Primary-Ingress sub-TLV 484 A Primary-Ingress sub-TLV indicates the IP address of the primary 485 ingress node of a primary BIER-TE path/tunnel. It has two formats: 486 one for primary ingress node IPv4 address and the other for primary 487 ingress node IPv6 address, which are illustrated below. 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type = TBD6 | Length (4) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Primary Ingress IPv4 Address (4 octets) | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 6: Primary Ingress IPv4 Address sub-TLV 499 Type: TBD6 is to be assigned by IANA. 501 Length: 4. 503 Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host 504 address of the primary ingress node of a BIER-TE path/tunnel. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type = TBD7 | Length (16) | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Primary Ingress IPv6 Address (16 octets) | 512 ~ ~ 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 7: Primary Ingress IPv6 Address sub-TLV 517 Type: TBD7 is to be assigned by IANA. 519 Length: 16. 521 Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host 522 address of the primary ingress node of a BIER-TE path/tunnel. 524 5.2.2. Extensions for Traffic Source 526 If the traffic source is requested to detect the failure of the 527 primary ingress and switch the traffic (to be sent to the primary 528 ingress) to the backup ingress when the primary ingress fails, it 529 MUST have the information about the backup ingress, the primary 530 ingress and the traffic. This information may be transferred via a 531 CCI object for BIER-TE-INGRESS-PROTECTION to the PCC of the traffic 532 source node from a PCE. 534 If the traffic source PCC does not accept the request from the PCE or 535 support the extensions, the PCE SHOULD have the information about the 536 behavior of the traffic source configured such as whether it detects 537 the failure of the primary ingress. Based on the information, the 538 PCE instructs the backup ingress accordingly. 540 The Central Control Instructions (CCI) Object is defined in 541 [I-D.ietf-pce-pcep-extension-for-pce-controller] for a PCE as a 542 controller to send instructions for LSPs to a PCC. This document 543 defines a new object-type (TBDt) for BIER-TE ingress protection based 544 on the CCI object. The body of the object with the new object-type 545 is illustrated below. The object may be in PCRpt, PCUpd, or 546 PCInitiate message. 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | CC-ID | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Reserved | Flags |B|D| 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | | 556 // Optional TLV // 557 | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 8: BIER-TE-INGRESS-PROTECTION Object Body 562 CC-ID: It is the same as described in 563 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 565 Flags: Two flag bits D and B are defined as follows: 567 D: D = 1 instructs the PCC of the traffic source to Detect the 568 failure of the primary ingress and switch the traffic to the 569 backup ingress when it detects the failure. 571 B: B = 1 instructs the PCC of the traffic source to send the 572 traffic to Both the primary ingress and the backup ingress. 574 Optional TLV: Primary ingress TLV, backup ingress TLV and/or 575 Multicast Flow Specification TLV. 577 The primary ingress sub-TLV defined above is used as a TLV to contain 578 the information about the primary ingress in the object. The 579 Multicast Flow Specification TLV for IPv4 or IPv6, which is defined 580 in [I-D.ietf-pce-pcep-flowspec], is used to contain the information 581 about the traffic in the object. A new TLV, called backup ingress 582 TLV, is defined to contain the information about the backup ingress 583 in the object. 585 5.2.2.1. Backup-Ingress TLV 587 A Backup-Ingress TLV indicates the IP address of the ingress node of 588 a backup BIER-TE path/tunnel. It has two formats: one for backup 589 ingress node IPv4 address and the other for backup ingress node IPv6 590 address, which are illustrated below. They have the same format as 591 the Primary-Ingress sub-TLVs. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Type = TBD8 | Length (4) | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Backup Ingress IPv4 Address (4 octets) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Figure 9: Backup Ingress IPv4 Address TLV 603 Type: TBD8 is to be assigned by IANA. 605 Length: 4. 607 Backup Ingress IPv4 Address: 4 octets. It represents an IPv4 host 608 address of the backup ingress. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Type = TBD9 | Length (16) | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Backup Ingress IPv6 Address (16 octets) | 616 ~ ~ 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Figure 10: Backup Ingress IPv6 Address TLV 621 Type: TBD9 is to be assigned by IANA. 623 Length: 16. 625 Backup Ingress IPv6 Address: 16 octets. It represents an IPv6 host 626 address of the backup ingress node. 628 6. IANA Considerations 630 TBD 632 7. Security Considerations 634 TBD 636 8. Acknowledgements 638 TBD 640 9. References 642 9.1. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, 646 DOI 10.17487/RFC2119, March 1997, 647 . 649 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 650 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 651 DOI 10.17487/RFC5440, March 2009, 652 . 654 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 655 Computation Element Communication Protocol (PCEP) 656 Extensions for Stateful PCE", RFC 8231, 657 DOI 10.17487/RFC8231, September 2017, 658 . 660 9.2. Informative References 662 [I-D.chen-bier-te-frr] 663 Chen, H., McBride, M., Liu, Y., Wang, A., Mishra, G. S., 664 Fan, Y., Liu, L., and X. Liu, "BIER-TE Fast ReRoute", Work 665 in Progress, Internet-Draft, draft-chen-bier-te-frr-01, 23 666 August 2021, . 669 [I-D.ietf-pce-pcep-extension-for-pce-controller] 670 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 671 "Path Computation Element Communication Protocol (PCEP) 672 Procedures and Extensions for Using the PCE as a Central 673 Controller (PCECC) of LSPs", Work in Progress, Internet- 674 Draft, draft-ietf-pce-pcep-extension-for-pce-controller- 675 14, 5 March 2021, . 678 [I-D.ietf-pce-pcep-flowspec] 679 Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow 680 Specification", Work in Progress, Internet-Draft, draft- 681 ietf-pce-pcep-flowspec-13, 14 October 2021, 682 . 685 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 686 Decraene, B., Litkowski, S., and R. Shakir, "Segment 687 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 688 July 2018, . 690 [RFC8424] Chen, H., Ed. and R. Torvi, Ed., "Extensions to RSVP-TE 691 for Label Switched Path (LSP) Ingress Fast Reroute (FRR) 692 Protection", RFC 8424, DOI 10.17487/RFC8424, August 2018, 693 . 695 Authors' Addresses 697 Huaimo Chen 698 Futurewei 699 Boston, MA, 700 United States of America 702 Email: Huaimo.chen@futurewei.com 704 Mike McBride 705 Futurewei 707 Email: michael.mcbride@futurewei.com 709 Gyan S. Mishra 710 Verizon Inc. 711 13101 Columbia Pike 712 Silver Spring, MD 20904 713 United States of America 715 Phone: 301 502-1347 716 Email: gyan.s.mishra@verizon.com 718 Yisong Liu 719 China Mobile 721 Email: liuyisong@chinamobile.com 722 Aijun Wang 723 China Telecom 724 Beiqijia Town, Changping District 725 Beijing 726 102209 727 China 729 Email: wangaj3@chinatelecom.cn 731 Lei Liu 732 Fujitsu 733 United States of America 735 Email: liulei.kddi@gmail.com 737 Xufeng Liu 738 Volta Networks 739 McLean, VA 740 United States of America 742 Email: xufeng.liu.ietf@gmail.com