idnits 2.17.1 draft-chen-pce-bier-te-ingress-protect-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (July 11, 2021) is 1014 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 134, but not defined == Unused Reference: 'RFC5440' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC8231' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 679, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-chen-bier-te-frr-00 == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-flowspec-12 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: January 12, 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 July 11, 2021 17 PCE for BIER-TE Ingress Protection 18 draft-chen-pce-bier-te-ingress-protect-00 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 January 12, 2022. 49 Copyright Notice 51 Copyright (c) 2021 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 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. BIER-TE Path Ingress Protection Example . . . . . . . . . . . 3 69 4. Behavior around Ingress Failure . . . . . . . . . . . . . . . 4 70 4.1. Source Detect . . . . . . . . . . . . . . . . . . . . . . 5 71 4.2. Backup Ingress Detect . . . . . . . . . . . . . . . . . . 5 72 4.3. Both Detect . . . . . . . . . . . . . . . . . . . . . . . 5 73 5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 5 74 5.1. Capability for Ingress Protection . . . . . . . . . . . . 6 75 5.1.1. Capability for Ingress Protection with Backup Ingress 6 76 5.1.2. Capability for Ingress Protection with Traffic Source 7 77 5.2. BIER-TE Path Ingress Protection . . . . . . . . . . . . . 8 78 5.2.1. Extensions for Backup Ingress . . . . . . . . . . . . 8 79 5.2.2. Extensions for Traffic Source . . . . . . . . . . . . 11 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 9.2. Informative References . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 The fast protection of a transit node of a "Bit Index Explicit 91 Replication" (BIER) Traffic Engineering (BIER-TE) path or tunnel is 92 described in [I-D.chen-bier-te-frr]. [RFC8424] presents extensions 93 to RSVP-TE for the fast protection of the ingress node of a traffic 94 engineering (TE) Label Switching Path (LSP). However, these 95 documents do not discuss any protocol extensions for the fast 96 protection of the ingress node of a BIER-TE path or tunnel. 98 This document fills that gap and specifies protocol extensions to 99 Path Computation Element (PCE) communication Protocol (PCEP) for the 100 fast protection of the ingress node of a BIER-TE path or tunnel. 101 Ingress node and ingress, fast protection and protection as well as 102 BIER-TE path and BIER-TE tunnel will be used exchangeably in the 103 following sections. 105 2. Terminologies 107 The following terminologies are used in this document. 109 PCE: Path Computation Element 111 PCEP: PCE communication Protocol 113 PCC: Path Computation Client 115 BIER: Bit Index Explicit Replication 117 CE: Customer Edge 119 PE: Provider Edge 121 TE: Traffic Engineering 123 3. BIER-TE Path Ingress Protection Example 125 Figure 1 shows an example of protecting ingress PE1 of a BIER-TE 126 path, which is from ingress PE1 to egress nodes PE3 and PE4. This 127 primary BIER-TE path is represented by *** in the figure. The 128 ingress of the primary BIER-TE path is called primary ingress. 130 ******* ******* 131 [PE1]-----[P1]-----[PE3] PE1 Primary Ingress 132 / | #|*\##### | PEx Provider Edge 133 / | #| *\__ | CEx Customer Edge 134 [CE1] | #| ***\ | Px Non Provider Edge 135 \ | #| *\ | *** Primary BIER-TE Path 136 \ | #| *\ | ### Backup BIER-TE Path 137 [PE2]-----[P2]-----[PE4] PE2 Backup Ingress 138 ##### ##### 140 Figure 1: Protecting Ingress PE1 of BIER-TE Path 142 The backup BIER-TE path is from ingress PE2 to egress nodes PE3 and 143 PE4, which is represented by ### in the figure. The ingress of the 144 backup BIER-TE path is called backup ingress. 146 In normal operations, CE1 sends the packets with a multicast group 147 and source to ingress PE1, which imports/encapsulates the packets 148 into the BIER-TE path through adding a BIER-TE header. The header 149 contains the BIER-TE path from ingress PE1 to egress nodes PE3 and 150 PE4. 152 When CE1 detects the failure of ingress PE1 using a failure detection 153 mechanism such as BFD, it switches the traffic to backup ingress PE2, 154 which imports the traffic from CE1 into the backup BIER-TE path. 155 When the traffic is imported into the backup path, it is sent to the 156 egress nodes PE3 and PE4 along the path. 158 Given the traffic source (e.g., CE1), ingress (e.g., PE1) and 159 egresses (e.g., PE3 and PE4) of the primary BIER-TE path, the PCE 160 computes a backup ingress (e.g., PE2), a backup BIER-TE path from the 161 backup ingress to the egresses, and sends the backup BIER-TE path to 162 the PCC of the backup ingress. It also sends the backup ingress, 163 primary ingress and the traffic description to the PCC of the traffic 164 source (e.g., CE1). 166 When the PCC of the traffic source receives the backup ingress, 167 primary ingress and traffic description, it sets up the fast 168 detection of the primary ingress failure and the switch over target 169 backup ingress. This setup lets the traffic source node switch the 170 traffic (to be sent to the primary ingress) to the backup ingress 171 when it detects the failure of the primary ingress. 173 When the PCC of the backup ingress receives the backup BIER-TE path, 174 it adds a forwarding entry into its BIFT. This entry encapsulates 175 the packets from the traffic source in the backup BIER-TE path. This 176 makes the backup ingress send the traffic received from the traffic 177 source to the egress nodes via the backup BIER-TE path. 179 4. Behavior around Ingress Failure 181 This section describes the behavior of some nodes connected to the 182 ingress before and after the ingress fails. These nodes are the 183 traffic source (e.g., CE1) and the backup ingress (e.g., PE2). It 184 presents three ways in which these nodes work together to protect the 185 ingress. The first way is called source detect, where the traffic 186 source is responsible for fast detecting the failure of the ingress. 187 The second way is called backup ingress detect, in which the backup 188 ingress is responsible for fast detecting the failure of the ingress. 189 The third way is called both detect, where both the traffic source 190 and the backup ingress are responsible for fast detecting the failure 191 of the ingress. 193 4.1. Source Detect 195 In normal operations, i.e., before the failure of the ingress, the 196 traffic source sends the traffic to the ingress of the primary BIER- 197 TE path. The backup ingress (e.g., PE2) is ready to import the 198 traffic from the traffic source into the backup BIER-TE path 199 installed. 201 When the traffic source detects the failure of the ingress, it 202 switches the traffic to the backup ingress, which delivers the 203 traffic to the egress nodes of the BIER-TE path via the backup BIER- 204 TE path. 206 4.2. Backup Ingress Detect 208 The traffic source (e.g., CE1) always sends the traffic to both the 209 ingress (e.g., PE1) of the primary BIER-TE path and the backup 210 ingress (e.g., PE2). 212 The backup ingress does not import any traffic from the traffic 213 source into the backup BIER-TE path in normal operations. When it 214 detects the failure of the ingress of the primary BIER-TE path, it 215 imports the traffic from the source into the backup BIER-TE path. 217 For the backup ingress to fast detect the failure of the primary 218 ingress, it SHOULD directly connect to the primary ingress. When a 219 PCE computes a backup ingress and a backup BIER-TE path, it SHOULD 220 consider this. 222 4.3. Both Detect 224 In normal operations, i.e., before the failure of the ingress, the 225 traffic source sends the traffic to the ingress of the primary BIER- 226 TE path. When it detects the failure of the ingress, it switches the 227 traffic to the backup ingress. 229 The backup ingress does not import any traffic from the traffic 230 source into the backup BIER-TE path in normal operations. When it 231 detects the failure of the ingress of the primary BIER-TE path, it 232 imports the traffic from the source into the backup BIER-TE path. 234 5. Extensions to PCEP 236 A PCC runs on each of the edge nodes such as PEs and CEs of a network 237 normally. A PCE runs on a server as a controller to communicate with 238 PCCs. The PCE and the PCCs running on backup ingress PEs and traffic 239 source CEs work together to support protection for the ingress of a 240 BIER-TE path. 242 5.1. Capability for Ingress Protection 244 5.1.1. Capability for Ingress Protection with Backup Ingress 246 When a PCE and a PCC running on a backup ingress establish a PCEP 247 session between them, they exchange their capabilities of supporting 248 protection for the ingress node of a BIER-TE path/tunnel. 250 A new sub-TLV called BIER-TE_INGRESS_PROTECTION_CAPABILITY is 251 defined. It is included in the PATH_SETUP_TYPE_CAPABILITY TLV with 252 PST = TBD1 (suggested value 2 for protecting the ingress of a BIER-TE 253 path/tunnel) in the OPEN object, which is exchanged in Open messages 254 when a PCC and a PCE establish a PCEP session between them. Its 255 format is illustrated below. 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type = TBD2 | Length=4 | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Reserved | Flags |D|A| 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: BIER-TE_INGRESS_PROTECTION_CAPABILITY sub-TLV 267 Type: TBD2 is to be assigned by IANA. 269 Length: 4. 271 Reserved: 2 octets. Must be set to zero in transmission and ignored 272 on reception. 274 Flags: 2 octets. Two flag bits are defined. 276 o D flag bit: A PCC sets this flag to 1 to indicate that it is 277 able to detect its adjacent node's failure quickly. 279 o A flag bit: A PCE sets this flag to 1 to request a PCC to let 280 the forwarding entry for the backup BIER-TE path/tunnel be 281 Active. 283 A PCC, which supports ingress protection for a BIER-TE tunnel/path, 284 sends a PCE an Open message containing BIER- 285 TE_INGRESS_PROTECTION_CAPABILITY sub-TLV. This sub-TLV indicates 286 that the PCC is capable of supporting the ingress protection for a 287 BIER-TE tunnel/path. 289 A PCE, which supports ingress protection for a BIER-TE tunnel/path, 290 sends a PCC an Open message containing BIER- 291 TE_INGRESS_PROTECTION_CAPABILITY sub-TLV. This sub-TLV indicates 292 that the PCE is capable of supporting the ingress protection for a 293 BIER-TE tunnel/path. 295 If both a PCC and a PCE support BIER- 296 TE_INGRESS_PROTECTION_CAPABILITY, each of the Open messages sent by 297 the PCC and PCE contains PATH-SETUP-TYPE-CAPABILITY TLV with a PST 298 list containing PST=TBD1 and a BIER-TE-INGRESS_PROTECTION_CAPABILITY 299 sub-TLV. 301 If a PCE receives an Open message without a BIER- 302 TE_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCC, then the PCE 303 MUST not send the PCC any request for ingress protection of a BIER-TE 304 path/tunnel. 306 If a PCC receives an Open message without a BIER- 307 TE_INGRESS_PROTECTION_CAPABILITY sub-TLV from a PCE, then the PCC 308 MUST ignore any request for ingress protection of a BIER-TE path/ 309 tunnel from the PCE. 311 If a PCC sets D flag to zero, then the PCE SHOULD send the PCC an 312 Open message with A flag set to one and the fast detection of the 313 failure of the primary ingress MUST be done by the traffic source. 314 When the PCE sends the PCC a message for initiating a backup BIER-TE 315 path, the PCC MUST let the forwarding entry for the backup BIER-TE 316 path be Active. 318 5.1.2. Capability for Ingress Protection with Traffic Source 320 When a PCE and a PCC running on a traffic source node establish a 321 PCEP session between them, they exchange their capabilities of 322 supporting protection for the ingress node of a BIER-TE path/tunnel. 324 The PCECC-CAPABILITY sub-TLV defined in 325 [I-D.ietf-pce-pcep-extension-for-pce-controller] is included in the 326 OPEN object in the PATH-SETUP-TYPE-CAPABILITY TLV, which is exchanged 327 in Open messages when a PCC and a PCE establish a PCEP session 328 between them. 330 A new flag bit P is defined in the Flags field of the PCECC- 331 CAPABILITY sub-TLV: 333 o P flag (for Ingress Protection): if set to 1 by a PCEP speaker, 334 the P flag indicates that the PCEP speaker supports and is willing 335 to handle the PCECC based central controller instructions for 336 ingress protection. The bit MUST be set to 1 by both a PCC and a 337 PCE for the PCECC ingress protection instruction download/report 338 on a PCEP session. 340 5.2. BIER-TE Path Ingress Protection 342 This section specifies the extensions to PCEP for the backup ingress 343 and the traffic source. The extensions let the traffic source 345 S1: fast detect the failure of the primary ingress and switch the 346 traffic to the backup ingress when the traffic source detects the 347 failure of the primary ingress, or 349 S2: always send the traffic to both the primary ingress and the 350 backup ingress. 352 The extensions let the backup ingress 354 B1: always import the traffic received from the traffic source 355 with possible service ID into the backup BIER-TE path, or 357 B2: import the traffic with possible service ID into the backup 358 BIER-TE path when the backup ingress detects the failure of the 359 primary ingress. 361 The following lists the combinations of Si and Bi (i = 1,2) for 362 different ways of failure detects. 364 Source Detect: S1 and B1. 366 Backup Ingress Detect: S2 and B2. 368 Both Detect: S1 and B2. 370 5.2.1. Extensions for Backup Ingress 372 For the packets from the traffic source, if the primary ingress 373 (i.e., the ingress of the primary BIER-TE path) encapsulates the 374 packets with a service ID or label into the BIER-TE path, the backup 375 ingress MUST have this service ID or label and encapsulates the 376 packets with the service ID or label into the backup BIER-TE path 377 when the primary ingress fails. 379 If the backup ingress is requested to detect the failure of the 380 primary ingress, it MUST have the information about the primary 381 ingress such as the address of the primary ingress. 383 A new TLV called BIER-TE_INGRESS_PROTECTION TLV is defined to 384 transfer the information about the primary ingress and/or the service 385 ID or label. When a PCE sends the PCC of a backup ingress a 386 PCInitiate message for initiating a backup BIER-TE path/tunnel to 387 protect the primary ingress of a primary BIER-TE path/tunnel, the 388 message contains this TLV in the RP/SRP object. Its format is 389 illustrated below. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type = TBD3 | Length (variable) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Reserved | Flags |A| 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 ~ ~ 399 ~ sub-TLVs (optional) ~ 400 ~ ~ 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 3: BIER-TE_INGRESS_PROTECTION TLV 405 Type: TBD3 is to be assigned by IANA. 407 Length: Variable. 409 Reserved: 2 octets. Must be set to zero in transmission and ignored 410 on reception. 412 Flags: 2 octets. One flag bit is defined. 414 A flag bit: it is set to 1 or 0 by PCE. 416 o 1 is to request the backup ingress to let the forwarding 417 entry for the backup BIER-TE path/tunnel be Active always. 418 In this case, the traffic source detects the failure of the 419 primary ingress and switches the traffic to the backup 420 ingress when it detects the failure. 422 o 0 is to request the backup ingress to detect the failure of 423 the primary ingress and let the forwarding entry for the 424 backup BIER-TE path/tunnel be Active when the primary 425 ingress fails. In this case, the TLV includes the primary 426 ingress address in a Primary-Ingress sub-TLV. The traffic 427 source can send the traffic to both the primary ingress and 428 the backup ingress. It may switch the traffic to the backup 429 ingress from the primary ingress when it detects the failure 430 of the primary ingress. 432 Two optional sub-TLVs are defined. One is Service sub-TLV. The 433 other is Primary-Ingress sub-TLV. The Multicast Flow Specification 434 TLV for IPv4 or IPv6, which is defined in 435 [I-D.ietf-pce-pcep-flowspec], is used as a sub-TLV to indicate the 436 traffic to be imported into the backup BIER-TE path. 438 5.2.1.1. Service sub-TLV 440 A Service sub-TLV contains a service label such as VPN service label 441 or ID to be added into a packet to be carried by a BIER-TE path/ 442 tunnel. It has two formats: one for the service identified by a 443 label and the other for the service identified by a service 444 identifier (ID) of 32 or 128 bits, which are illustrated below. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type = TBD4 | Length (4) | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | zero | Service Label (20 bits) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 4: Service Label sub-TLV 456 Type: TBD4 is to be assigned by IANA. 458 Length: 4. 460 Service Label: the least significant 20 bits. It represents a label 461 of 20 bits. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type = TBD5 | Length (4/16) | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Service ID (4 or 16 octets) | 469 ~ ~ 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Figure 5: Service ID sub-TLV 474 Type: TBD5 is to be assigned by IANA. 476 Length: 4 or 16. 478 Service ID: 4 or 16 octets. It represents Identifier (ID) of a 479 service in 4 or 16 octets. 481 5.2.1.2. Primary-Ingress sub-TLV 483 A Primary-Ingress sub-TLV indicates the IP address of the primary 484 ingress node of a primary BIER-TE path/tunnel. It has two formats: 485 one for primary ingress node IPv4 address and the other for primary 486 ingress node IPv6 address, which are illustrated below. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type = TBD6 | Length (4) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Primary Ingress IPv4 Address (4 octets) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Figure 6: Primary Ingress IPv4 Address sub-TLV 498 Type: TBD6 is to be assigned by IANA. 500 Length: 4. 502 Primary Ingress IPv4 Address: 4 octets. It represents an IPv4 host 503 address of the primary ingress node of a BIER-TE path/tunnel. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type = TBD7 | Length (16) | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Primary Ingress IPv6 Address (16 octets) | 511 ~ ~ 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 7: Primary Ingress IPv6 Address sub-TLV 516 Type: TBD7 is to be assigned by IANA. 518 Length: 16. 520 Primary Ingress IPv6 Address: 16 octets. It represents an IPv6 host 521 address of the primary ingress node of a BIER-TE path/tunnel. 523 5.2.2. Extensions for Traffic Source 525 If the traffic source is requested to detect the failure of the 526 primary ingress and switch the traffic (to be sent to the primary 527 ingress) to the backup ingress when the primary ingress fails, it 528 MUST have the information about the backup ingress, the primary 529 ingress and the traffic. This information may be transferred via a 530 CCI object for BIER-TE-INGRESS-PROTECTION to the PCC of the traffic 531 source node from a PCE. 533 If the traffic source PCC does not accept the request from the PCE or 534 support the extensions, the PCE SHOULD have the information about the 535 behavior of the traffic source configured such as whether it detects 536 the failure of the primary ingress. Based on the information, the 537 PCE instructs the backup ingress accordingly. 539 The Central Control Instructions (CCI) Object is defined in 540 [I-D.ietf-pce-pcep-extension-for-pce-controller] for a PCE as a 541 controller to send instructions for LSPs to a PCC. This document 542 defines a new object-type (TBDt) for BIER-TE ingress protection based 543 on the CCI object. The body of the object with the new object-type 544 is illustrated below. The object may be in PCRpt, PCUpd, or 545 PCInitiate message. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | CC-ID | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Reserved | Flags |B|D| 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | | 555 // Optional TLV // 556 | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 8: BIER-TE-INGRESS-PROTECTION Object Body 561 CC-ID: It is the same as described in 562 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 564 Flags: Two flag bits D and B are defined as follows: 566 D: D = 1 instructs the PCC of the traffic source to Detect the 567 failure of the primary ingress and switch the traffic to the 568 backup ingress when it detects the failure. 570 B: B = 1 instructs the PCC of the traffic source to send the 571 traffic to Both the primary ingress and the backup ingress. 573 Optional TLV: Primary ingress TLV, backup ingress TLV and/or 574 Multicast Flow Specification TLV. 576 The primary ingress sub-TLV defined above is used as a TLV to contain 577 the information about the primary ingress in the object. The 578 Multicast Flow Specification TLV for IPv4 or IPv6, which is defined 579 in [I-D.ietf-pce-pcep-flowspec], is used to contain the information 580 about the traffic in the object. A new TLV, called backup ingress 581 TLV, is defined to contain the information about the backup ingress 582 in the object. 584 5.2.2.1. Backup-Ingress TLV 586 A Backup-Ingress TLV indicates the IP address of the ingress node of 587 a backup BIER-TE path/tunnel. It has two formats: one for backup 588 ingress node IPv4 address and the other for backup ingress node IPv6 589 address, which are illustrated below. They have the same format as 590 the Primary-Ingress sub-TLVs. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type = TBD8 | Length (4) | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Backup Ingress IPv4 Address (4 octets) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 9: Backup Ingress IPv4 Address TLV 602 Type: TBD8 is to be assigned by IANA. 604 Length: 4. 606 Backup Ingress IPv4 Address: 4 octets. It represents an IPv4 host 607 address of the backup ingress. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Type = TBD9 | Length (16) | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Backup Ingress IPv6 Address (16 octets) | 615 ~ ~ 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Figure 10: Backup Ingress IPv6 Address TLV 620 Type: TBD9 is to be assigned by IANA. 622 Length: 16. 624 Backup Ingress IPv6 Address: 16 octets. It represents an IPv6 host 625 address of the backup ingress node. 627 6. IANA Considerations 629 TBD 631 7. Security Considerations 633 TBD 635 8. Acknowledgements 637 TBD 639 9. References 641 9.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 649 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 650 DOI 10.17487/RFC5440, March 2009, 651 . 653 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 654 Computation Element Communication Protocol (PCEP) 655 Extensions for Stateful PCE", RFC 8231, 656 DOI 10.17487/RFC8231, September 2017, 657 . 659 9.2. Informative References 661 [I-D.chen-bier-te-frr] 662 Chen, H., McBride, M., Liu, Y., Wang, A., Mishra, G. S., 663 Fan, Y., Liu, L., and X. Liu, "BIER-TE Fast ReRoute", 664 draft-chen-bier-te-frr-00 (work in progress), February 665 2021. 667 [I-D.ietf-pce-pcep-extension-for-pce-controller] 668 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 669 "PCEP Procedures and Protocol Extensions for Using PCE as 670 a Central Controller (PCECC) of LSPs", draft-ietf-pce- 671 pcep-extension-for-pce-controller-14 (work in progress), 672 March 2021. 674 [I-D.ietf-pce-pcep-flowspec] 675 Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow 676 Specification", draft-ietf-pce-pcep-flowspec-12 (work in 677 progress), October 2020. 679 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 680 Decraene, B., Litkowski, S., and R. Shakir, "Segment 681 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 682 July 2018, . 684 [RFC8424] Chen, H., Ed. and R. Torvi, Ed., "Extensions to RSVP-TE 685 for Label Switched Path (LSP) Ingress Fast Reroute (FRR) 686 Protection", RFC 8424, DOI 10.17487/RFC8424, August 2018, 687 . 689 Authors' Addresses 691 Huaimo Chen 692 Futurewei 693 Boston, MA 694 USA 696 Email: Huaimo.chen@futurewei.com 698 Mike McBride 699 Futurewei 701 Email: michael.mcbride@futurewei.com 703 Gyan S. Mishra 704 Verizon Inc. 705 13101 Columbia Pike 706 Silver Spring MD 20904 707 USA 709 Phone: 301 502-1347 710 Email: gyan.s.mishra@verizon.com 711 Yisong Liu 712 China Mobile 714 Email: liuyisong@chinamobile.com 716 Aijun Wang 717 China Telecom 718 Beiqijia Town, Changping District 719 Beijing, 102209 720 China 722 Email: wangaj3@chinatelecom.cn 724 Lei Liu 725 Fujitsu 727 USA 729 Email: liulei.kddi@gmail.com 731 Xufeng Liu 732 Volta Networks 734 McLean, VA 735 USA 737 Email: xufeng.liu.ietf@gmail.com