idnits 2.17.1 draft-chen-pce-bier-te-path-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 15, 2021) is 1097 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 180 -- Looks like a reference, but probably isn't: '65535' on line 180 == Unused Reference: 'RFC8232' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 1026, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-09 == Outdated reference: A later version (-13) exists of draft-ietf-pce-pcep-flowspec-12 == Outdated reference: A later version (-13) exists of draft-chen-pce-bier-08 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: October 17, 2021 A. Wang 6 China Telecom 7 G. Mishra 8 Verizon Inc. 9 Y. Liu 10 China Mobile 11 Y. Fan 12 Casa Systems 13 L. Liu 14 Fujitsu 15 X. Liu 16 Volta Networks 17 April 15, 2021 19 PCE for BIER-TE Path 20 draft-chen-pce-bier-te-path-01 22 Abstract 24 This document describes extensions to Path Computation Element (PCE) 25 communication Protocol (PCEP) for supporting Bit Index Explicit 26 Replication (BIER) Traffic Engineering (TE) paths. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 17, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminologies . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Overview of PCE for BIER-TE . . . . . . . . . . . . . . . . . 5 70 2.1. Example BIER-TE Topology with PCE . . . . . . . . . . . . 5 71 2.2. A Brief Flow of PCEP Messages for a BIER-TE Path . . . . 6 72 2.3. Procedures on Ingress . . . . . . . . . . . . . . . . . . 8 73 3. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 9 74 3.1. BIER-TE Path Capability . . . . . . . . . . . . . . . . . 9 75 3.2. Extensions to SRP . . . . . . . . . . . . . . . . . . . . 10 76 3.2.1. SRP Object Flag Field . . . . . . . . . . . . . . . . 10 77 3.2.2. Reuse of Multicast Flow Specification TLV . . . . . . 11 78 3.3. Ingress Node Object . . . . . . . . . . . . . . . . . . . 11 79 3.4. Objective Functions . . . . . . . . . . . . . . . . . . . 13 80 3.5. BIER-TE Path Subobject . . . . . . . . . . . . . . . . . 14 81 3.6. BIER-TE Path Subobject in ERO . . . . . . . . . . . . . . 15 82 3.7. BIER-TE Path Subobject in RRO . . . . . . . . . . . . . . 15 83 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 4.1. BIER-TE Path Creation . . . . . . . . . . . . . . . . . . 16 85 4.2. BIER-TE Path Update . . . . . . . . . . . . . . . . . . . 17 86 4.3. BIER-TE Path Deletion . . . . . . . . . . . . . . . . . . 17 87 5. The PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 17 88 5.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 17 89 5.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 18 90 5.3. The PCInitiate Message . . . . . . . . . . . . . . . . . 18 91 5.4. The PCReq Message . . . . . . . . . . . . . . . . . . . . 18 92 5.5. The PCRep Message . . . . . . . . . . . . . . . . . . . . 18 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 94 6.1. PST for BIER-TE Path . . . . . . . . . . . . . . . . . . 19 95 6.2. PCE-BIER-TE-Path Capability sub-TLV . . . . . . . . . . . 19 96 6.3. SRP Object Flag Field . . . . . . . . . . . . . . . . . . 19 97 6.4. Ingress Node Object . . . . . . . . . . . . . . . . . . . 20 98 6.5. OF Code Points . . . . . . . . . . . . . . . . . . . . . 20 99 6.6. PCEP BIER-TE Path Subobjects . . . . . . . . . . . . . . 20 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 104 9.2. Informative References . . . . . . . . . . . . . . . . . 22 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 107 1. Introduction 109 [I-D.ietf-bier-te-arch] introduces Bit Index Explicit Replication 110 (BIER) Traffic/Tree Engineering (BIER-TE). It is an architecture for 111 per-packet stateless explicit point to multipoint (P2MP) multicast 112 path/tree and based on the BIER architecture defined in [RFC8279]. 114 A Bit-Forwarding Ingress Router (BFIR) in a BIER-TE domain receives 115 the information or instructions from a controller such as a stateful 116 PCE about which multicast flows/packets are mapped to which P2MP 117 paths. The multicast flows/packets are indicated by multicast and 118 source addresses. The paths are represented by BitPositions or say 119 BitStrings. After receiving the information or instructions, the 120 ingress node/router encapsulates the multicast packets with the 121 BitPositions for the corresponding P2MP paths, replicates and 122 forwards the packets with the BitPositions along the P2MP paths. 124 [RFC8231] describes a set of extensions to PCEP to provide stateful 125 control. A stateful PCE has access to not only the information 126 carried by the network's Interior Gateway Protocol (IGP) but also the 127 set of active paths and their reserved resources. The additional 128 state allows the PCE to compute constrained paths while considering 129 individual paths and their interactions. 131 To compute and initiate BIER-TE P2MP paths, the stateful PCE needs to 132 be extended. For a BIER-TE P2MP path, some new state information 133 will be stored and maintained, which includes the BitPositions, 134 multicast group and multicast source for the path. The PCE gets the 135 egresses of the path, the same multicast group and source from the 136 egresses when each of the egresses reports to the PCE that it 137 receives a multicast join with the multicast group and source. With 138 this information, the PCE finds an ingress for the path, computes the 139 path from the ingress to the egresses that has the optimal 140 BitPositions and satisfies the constraints, and then initiates the 141 BIER-TE path at the ingress of the path through sending the ingress 142 the BitPositions of the path, multicast group and source in a PCEP 143 message such as PCInitiate. After receiving the message, the ingress 144 creates a forwarding entry that imports the packets with the 145 multicast group/address and source into the BIER-TE path (i.e., 146 encapsulates the packets with a BIER-TE header having the 147 BitPositions of the path), and then reports the status of the path to 148 the PCE in a PCEP message such as PCRpt. 150 [I-D.chen-pce-bier] describes part of the solution for this, which is 151 mainly the BIER-ERO subobject used for P2MP paths. 153 This document proposes a comprehensive solution for computing and 154 establishing BIER-TE P2MP paths. 156 1.1. Terminologies 158 The following terminologies are used in this document. 160 PCE: Path Computation Element 162 PCEP: PCE communication Protocol 164 PCC: Path Computation Client 166 CE: Customer Edge 168 PE: Provider Edge 170 BIER: Bit Index Explicit Replication. 172 BIER-TE: BIER Traffic/Tree Engineering. 174 BFR: Bit-Forwarding Router. 176 BFIR: Bit-Forwarding Ingress Router. 178 BFER: Bit-Forwarding Egress Router. 180 BFR-id: BFR Identifier. It is a number in the range [1,65535]. 182 BFR-NBR: BFR Neighbor. 184 BFR-prefix: An IP address (either IPv4 or IPv6) of a BFR. 186 BIRT: Bit Index Routing Table. It is a table that maps from the BFR- 187 id (in a particular sub-domain) of a BFER to the BFR-prefix of 188 that BFER, and to the BFR-NBR on the path to that BFER. 190 BIFT: Bit Index Forwarding Table. 192 LSP-DB: Label Switching Path DataBase. 194 TED: Traffic/Tree Engineering DataBase. 196 2. Overview of PCE for BIER-TE 198 This section briefly describes PCE for BIER-TE and illustrates some 199 details through a simple example BIER-TE topology. 201 2.1. Example BIER-TE Topology with PCE 203 An example BIER-TE topology for a BIER-TE domain with a PCE is shown 204 in Figure 1. There are 8 nodes/BFRs A, B, C, D, E, F, G and H in the 205 domain. Nodes/BFRs A, H, E, F and D are BFIRs (i.e., ingress nodes) 206 or BFERs (i.e., egress nodes). There is a connection (i.e., PCE 207 session) between the PCE and the PCC running on each of the possible 208 ingress and egress nodes in the domain. Note that some of 209 connections and the PCC on each node are not shown in the figure. 211 +------------------------------------+ 212 | PCE | 213 +------------------------------------+ 214 / ... \ 215 / \ 216 / 4' 17' 18' \ 217 / /-----------( G )----------( H ) 218 / / 19'\_______ 12'/4 219 / / _______)____/ 220 / / / (_____ 221 / /3' / \ 222 / 1' 2' / 5' 6' /11' 13' 20'\ 223 (CE) --- ( A )--------( B )------------( C )------------( D ) 224 5 \7' \15' 14' 1 225 \ \ 226 \8' 9' 10' \16' 227 ( E )------------( F ) 228 3 2 230 Figure 1: Example BIER-TE Topology with PCE 232 Nodes/BFRs D, F, E, H and A are BFERs (or BFIRs) and have local decap 233 adjacency BitPositions 1, 2, 3, 4, and 5 respectively. For 234 simplicity, these BPs are represented by (SI:BitString), where SI = 0 235 and BitString is of 8 bits. BPs 1, 2, 3, 4, and 5 are represented by 236 1 (0:00000001), 2 (0:00000010), 3 (0:00000100), 4 (0:00001000) and 5 237 (0:00010000) respectively. 239 The BitPositions for the forward connected adjacencies are 240 represented by i', where i is from 1 to 20. In one option, they are 241 encoded as (n+i), where n is a power of 2 such as 32768. For 242 simplicity, these BitPositions are represented by (SI:BitString), 243 where SI = (6 + (i-1)/8) and BitString is of 8 bits. BitPositions i' 244 (i from 1 to 20) are represented by 1'(6:00000001), 2'(6:00000010), 245 3'(6:00000100), 4'(6:00001000), 5'(6:00010000), 6'(6:00100000), 246 7'(6:01000000), 8'(6:10000000), 9'(7:00000001), 10'(7:00000010), . . 247 . , 16'(7:10000000), 17'(8:00000001), 18'(8:00000010), . . . , 248 20'(8:00001000). 250 For a link between two nodes X and Y, there are two BitPositions for 251 two forward connected adjacencies. These two forward connected 252 adjacency BitPositions are assigned on nodes X and Y respectively. 253 The BitPosition assigned on X is the forward connected adjacency of 254 Y. The BitPosition assigned on Y is the forward connected adjacency 255 of X. 257 For example, for the link between nodes B and C in the figure, two 258 forward connected adjacency BitPositions 5' and 6' are assigned to 259 two ends of the link. BitPosition 5' is assigned on node B to B's 260 end of the link. It is the forward connected adjacency of node C. 261 BitPosition 6' is assigned on node C to C's end of the link. It is 262 the forward connected adjacency of node B. 264 2.2. A Brief Flow of PCEP Messages for a BIER-TE Path 266 For a BIER-TE Path to transport the packets with a given multicast 267 group/address and source in a BIER-TE domain, a sequence of PCEP 268 messages are exchanged between the PCE for the domain and the PCEs 269 for the domains containing the source, and between the PCE for the 270 domain and the PCCs running on the BFERs/BFIRs of the domain. 272 Suppose that each of nodes H, D and F receives a multicast join with 273 a same multicast group/address and source, which are MGa and MSa 274 respectively. For simplicity, assume that the multicast source MSa 275 is in the left domain containing the CE in Figure 1. The following 276 is a brief flow of PCEP messages for computing and creating a BIER-TE 277 Path to transport the packets to H, D and F. 279 At first, the PCC running on each of nodes H, D and F sends the PCE a 280 PCEP message such as PCRpt. The message contains the multicast group 281 and source (i.e., MGa and MSa), which reports to the PCE that the 282 node receives a multicast join with MGa and MSa. Note that a PCEP 283 message is sent to the PCE from the PCC on a node to report that the 284 node leaves when the node receives a multicast leave with MGa and 285 MSa. 287 After receiving the PCEP messages from nodes H, D and F reporting 288 multicast join with MGa and MSa, the PCE for the domain containing 289 these nodes determines that nodes H, D and F are the egress nodes of 290 a BIER-TE path since they have the same multicast group and source. 292 Second, the PCE for the domain sends a PCEP message such as PCReq to 293 each of the PCEs for the domains that may contain the multicast 294 source. This message requests the PCE (that may contain the source) 295 to find an ingress node for the BIER-TE path having egress nodes H, D 296 and F. The message contains the multicast group and source (i.e., 297 MGa and MSa). For example, the PCE for the BIER-TE domain sends the 298 PCEP message to the PCE (called PCE-L) for the left domain containing 299 CE (note that this PCE is not shown in the figure). 301 After receiving the PCEP message requesting to find an ingress node, 302 the PCE (e.g., PCE-L) for the domain containing the multicast source 303 computes the ingress node that is reachable from the source with 304 minimum cost (e.g., ingress node A). The PCE for the domain without 305 the source can not find any ingress node. 307 Third, the PCE for the domain with the source sends the PCE for the 308 BIER-TE domain a PCEP message such as PCRep with the ingress node. 309 The PCE for the domain without the source sends the PCE for the BIER- 310 TE domain a PCEP message such as PCRep with NO INGRESS FOUND. 312 After receiving the PCEP message with the ingress node, the PCE for 313 the BIER-TE domain computes a P2MP path from the ingress node (e.g., 314 A) to the egress nodes (e.g., H, D and F). The path has the optimal 315 BitPositions and satisfies the constraints. The optimal BitPositions 316 means the BitPositions for the path has the minimum number of bit 317 sets and the minimum bit distance. 319 Fourth, the PCE for the BIER-TE domain sends a PCEP message such as 320 PCInitiate to the PCC on the ingress node (e.g., A) for the ingress 321 to create a BIER-TE path to transport the packets for the given 322 multicast group and source. The message contains the BitPositions 323 for the path, the multicast group and source. 325 After receiving the PCEP message with the path, the PCC on the 326 ingress (e.g., A) creates the BIER-TE path, i.e., a forwarding entry 327 that imports the packets with the multicast group/address and source 328 into the BIER-TE path (i.e., encapsulates the packets with a BIER-TE 329 header having the BitPositions of the path). 331 And then the PCC on the ingress sends the PCE a PCEP message such as 332 PCRpt reporting the status of the path to the PCE. 334 After receiving the PCEP message with the status of the path, the PCE 335 for the domain updates the information about the path accordingly. 337 2.3. Procedures on Ingress 339 This section introduces the procedures for the ingress node of a P2MP 340 path to get the BitPositions representing the explicit P2MP path from 341 the ingress node to its egress nodes from the PCE. 343 Suppose that node A in Figure 1 wants to have an explicit P2MP path 344 from ingress node A to egress nodes H and F. The path satisfies a 345 set of constraints. In one case, the PCC running on ingress node A 346 sends a request for the path to the PCE. The request contains the 347 set of constraints, objective functions, the ingress node and the 348 egress nodes. After receiving the request, the PCE computes an 349 explicit P2MP path, which satisfies the constraints and is from the 350 given ingress node to the egress nodes. While computing the path, 351 the PCE will optimize the BitPositions of the path. That is that, 352 for a given length of BitString, the path computed uses the minimum 353 number of BitStrings (i.e., bit sets) and satisfies the constraints. 354 The length is given by the value in BitStrLen field in the PCE-BIER- 355 TE-Path-Capability sub-TLV. The PCE sends a reply with the path to 356 the PCC. The reply contains the BitPositions representing the 357 explicit P2MP path. 359 For example, assume that the explicit P2MP path computed by the PCE 360 traverses the link/adjacency from A to B (indicated by BP 2'), the 361 link/adjacency from B to G (indicated by BP 4') and the link/ 362 adjacency from B to C (indicated by BP 6'), the link/adjacency from G 363 to H (indicated by BP 18'), and the link/adjacency from C to F 364 (indicated by BP 16'). This path is represented by {2', 4', 6', 16', 365 18', 2, 4}, where BitPositions 2 and 4 indicate egress nodes F and H 366 respectively. The reply sent to the PCC on node A by the PCE 367 contains the path represented by {2', 4', 6', 16', 18', 2, 4}. 369 In another case, a request for a P2MP path is from a user or 370 application. After receiving the request, the PCE finds an ingress 371 node if no ingress is given, and computes an explicit P2MP path from 372 the ingress node to the egress nodes and sends the path to the PCC 373 running on the ingress node. 375 After receiving the P2MP path, for any packet from CE to be 376 transported by the path, such as the packet with the multicast 377 address, the ingress node encapsulates the packet with the 378 BitPositions representing the path and forwards the packet according 379 to its BIFT. 381 For example, when ingress node A receives the path represented by 382 BitPositions {2', 4', 6', 16', 18', 2, 4}, it encapsulates every 383 packet from CE with the multicast address with the BitPositions and 384 then forwards the packet along the P2MP path according to its BIFT. 386 A forwards the packet to B according to the forwarding entry for BP 387 2' in its BIFT. 389 After receiving the packet from A, B forwards the packet to G and C 390 according to the forwarding entries for BPs 4' and 6' in B's BIFT 391 respectively. The packet received by G has path {16', 18', 2, 4}. 392 The packet received by C has path {16', 18', 2, 4}. 394 After receiving the packet from B, G sends the packet to H according 395 to the forwarding entry for BP 18' in G's BIFT. 397 After receiving the packet from B, C sends the packet to F according 398 to the forwarding entry for BP 16' in C's BIFT. 400 Egress node H of the P2MP path receives the packet with BitPosition 401 4. It decapsulates the packet and pass the payload of the packet to 402 the packet's NextProto. 404 Egress node F of the P2MP path receives the packet with BitPosition 405 2. It decapsulates the packet and pass the payload of the packet to 406 the packet's NextProto. 408 3. Extensions to PCEP 410 This section describes extensions to PCEP. 412 3.1. BIER-TE Path Capability 414 During a PCEP session establishment, PCEP Speakers (PCE or PCC) 415 indicate their ability to support BIER-TE paths. The OPEN object in 416 the Open message contains the PATH-SETUP-TYPE-CAPABILITY TLV, which 417 is defined in [RFC8408]. The TLV contains a list of Path Setup Types 418 (PSTs) and optional sub-TLVs associated with the PSTs. The sub-TLVs 419 convey the parameters that are associated with the PSTs supported by 420 a PCEP speaker. 422 This document defines a new PST value: 424 * PST = TBD1: Path is setup using BIER-TE. 426 A new sub-TLV associated with this new PST is defined, which is 427 called PCE-BIER-TE-Path-Capability sub-TLV. The format of this new 428 sub-TLV is illustrated in the figure below. 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type = TBD2 | Length = 4 | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Reserved | SILen | BitStrLen | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Figure 2: PCE-BIER-TE-Path-Capability sub-TLV 440 Type - 16 bits: TBD2 is to be assigned by IANA. 442 Length - 16 bits: 4 is the total length in bytes of the remainder of 443 the TLV, excluding the Type and Length fields. 445 SILen (SI Length) - 5 bits: The length in bits of the SI field. 447 BitStrLen (Bit String Length) - 8 bits: The length in bits of the 448 BitString field according to [RFC8296]. If k is the length of the 449 BitString, the value of BitStrLen is log2(k)-5. For example, 450 BitStrLen = 1 indicates k = 64, BitStrLen = 7 indicates k = 4096. 452 Reserved - 19 bits: MUST be set to zero by the sender and MUST be 453 ignored by the receiver. 455 A PCEP speaker supporting BIER-TE paths includes the new PST and sub- 456 TLV in the PATH-SETUP-TYPE-CAPABILITY TLV. 458 3.2. Extensions to SRP 460 For a PCEP message, when it is used for a BIER-TE path, the SRP 461 (Stateful PCE Request Parameters) object in the message MUST include 462 the PATH-SETUP-TYPE TLV defined in [RFC8408]. The TLV MUST contain 463 the PST = TBD1 for path setup using BIER-TE. 465 Three contiguous bits in SRP Object Flag Field are defined to 466 indicate one of the assistant operations for a BIER-TE path. This 467 three bits field is called AOP (Assistant Operations). In addition, 468 the Multicast Flow Specification TLV defined in 469 [I-D.ietf-pce-pcep-flowspec] is re-used in the SRP object for 470 indicating Multicast Traffic. 472 3.2.1. SRP Object Flag Field 474 The three bits for AOP are bits 27 to 29 (the exact bits to be 475 assigned by IANA) in the SRP Object Flag Field. The values of AOP 476 are defined as follows: 478 AOP Value Meaning (Assistant Operation) 479 0x001 (J): Join with Multicast Group and Source 480 0x010 (L): Leave from Multicast Group and Source 481 0x011 (I): Ingress node computation 483 The value of AOP indicates one of the three operations above. When 484 any of the other values is received, an error MUST be reported. 486 When the PCC running on an edge node of a BIER-TE domain sends the 487 PCE for the domain a PCEP message such as PCRpt to report that the 488 edge node receives a multicast join, the message MUST include a SRP 489 object with AOP == 0x001 (J). 491 When the PCC running on an edge node of a BIER-TE domain sends the 492 PCE for the domain a PCEP message such as PCRpt to report that the 493 edge node receives a multicast leave, the message MUST include a SRP 494 object with AOP == 0x010 (L). 496 When the PCE for the domain sends a PCEP message such as PCReq to 497 another PCE for requesting to find an ingress node for a BIER-TE 498 path, the message MUST include a SRP object with AOP == 0x011 (I). 500 3.2.2. Reuse of Multicast Flow Specification TLV 502 For a PCE-Initiated BIER-TE path, when a PCE sends a PCC a message 503 such as PCInitiate message to create a BIER-TE path in a BIER-TE 504 domain, the message MUST contain a Multicast Flow Specification TLV 505 in the SRP object. The TLV indicates the multicast traffic that the 506 BIER-TE path will carry. 508 When the PCC running on an edge node of a BIER-TE domain sends the 509 PCE for the domain a PCEP message to report that the edge node 510 receives a multicast join or leave with a multicast group/address and 511 source, the message MUST contain a Multicast Flow Specification TLV 512 in the SRP object. The TLV indicates the multicast group by the 513 multicast group adress and/or multicast source address. 515 When the PCE for a BIER-TE domain sends another PCE a PCEP message to 516 request for finding an ingress node of a BIER-TE path, the message 517 MUST contain a Multicast Flow Specification TLV in the SRP object. 518 The TLV indicates the multicast source. 520 3.3. Ingress Node Object 522 To represent an ingress node, a new ingress node object is defined. 523 The format of the new object for IPv4 (OT = 1) is as follows: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |ObjectClass=TBD| OT=1 |Res|P|I| Object Length (bytes) | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Ingress Node IPv4 address | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Cost to Ingress Node | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 ~ Optional TLVs ~ 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 3: Ingress Node Object for IPv4 539 ObjectClass: TBD is to be assigned by IANA. 541 OT: 1 for IPv4. 543 Res, P, I and Object Length: Same as those defined in Common Object 544 Header in [RFC5440]. 546 Ingress Node IPv4 address: Indicates an IPv4 address of an ingress 547 node. 549 Cost to Ingress Node: Indicates the cost from the multicast source 550 to the ingress node. 552 No optional TLV is defined so far. 554 The format of the new object for IPv6 (OT = 2) is as follows: 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |ObjectClass=TBD| OT=2 |Res|P|I| Object Length (bytes) | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Ingress Node IPv6 address | 562 | | 563 | | 564 | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Cost to Ingress Node | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 ~ Optional TLVs ~ 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Figure 4: Ingress Node Object for IPv6 573 TBD, Res, P, I, Object Length, and Cost to Ingress Node: 574 Same as those defined in Ingress Node Object for IPv4. 576 OT: 2 for IPv6. 578 Ingress Node IPv6 address: Indicates an IPv6 address of an ingress 579 node. 581 No optional TLV is defined so far. 583 3.4. Objective Functions 585 [RFC5541] defines a mechanism to specify an objective function (OF) 586 that is used by a PCE when it computes a path. For a BIER-TE path, 587 the following new OF is defined. 589 Objective Function Code: TBD8 590 Name: Minimum Bit Sets (MBS) 591 Description: Find a path represented by BitPositions that has 592 the minimum number of bit sets. 594 Objective Function Code: TBD9 595 Name: Minimum Bits (MB) 596 Description: Find a path represented by BitPositions that has 597 the minimum bit distance. The bit distance of 598 BitPositions is the distance from the lowest bit 599 to the highest bit in BitPositions. 601 3.5. BIER-TE Path Subobject 603 A BIER-TE path is represented by the BitPositions for the adjacencies 604 through which the path traverses. A BitPosition is represented by a 605 SI:BitString or a number. 607 A new subobject, called BIER-TE Path subobject (or BIER-TE-ERO 608 subobject), is defined to contain the information about one or more 609 BitPositions. 611 The format of a BIER-TE Path subobject in a ERO is shown in the 612 figure below. 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 |L| Type = TBDa | Length | sub-domain-id | MT-ID | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 : BitPositions : 620 | | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Figure 5: BIER-TE Path Subobject in ERO 625 L Flag (1 bit): It indicates whether the subobject represents a 626 loose-hop in the path. 628 Type (7 bits): It is to be assigned by IANA. It identifies the BIER 629 subobject type. 631 Length (8 bits): It contains the total length of the subobject in 632 octets. The Length MUST be at least 4. 634 sub-domain-id: Unique value identifying the BIER sub-domain within 635 the BIER domain. 637 MT-ID: Multi-Topology ID identifying the topology that is associated 638 with the BIER sub-domain. 640 BitPositions: It MUST be at least one BitPosition. 642 For the subobject in a message received from a PCEP session, the 643 format of the BitPositions in the subobject is determined by the 644 values of SILen and BitStrLen in the PCE-BIER-TE-Path-Capability sub- 645 TLV exchanged during the establishment of the session. When both 646 SILen and BitStrLen are greater than zero, each of the BitPositions 647 has two parts SI and BitString, where SI occupies SILen bits and 648 BitString occupies BitStrLen bits. When both SILen and BitStrLen are 649 zeros, each of the BitPositions is a number of 16 bits. 651 For example, when SILen = 8 and BitStrLen = 1 (indicating BitString 652 is of 64 bits), each BitPosition has a SI of 8 bits and a BitString 653 of 64 bits. For simplicity, BitString of 8 bits is used below. The 654 BitPositions for a BIER-TE path are sorted in descending order before 655 they are put into a BIER-TE path subobject. For BIER-TE path {2', 656 4', 6', 16', 18', 2, 4}, when its BitPositions are sorted, it is 657 {18', 16', 6', 4', 2', 4, 2}, which is {18'(8:00000010), 658 16'(7:10000000), 6'(6:00100000), 4'(6:00001000), 2'(6:00000010), 4 659 (0:00001000), 2 (0:00000010)}. The BitPositions with the same SI are 660 stored in one BitString. For example, 6'(6:00100000), 4'(6:00001000) 661 and 2'(6:00000010) are stored in (SI:BitString) = (6:00101010), where 662 SI = 6. BIER-TE path {18', 16', 6', 4', 2', 4, 2} is encoded in the 663 BIER-TE path subobject in the figure below. The path uses four 664 BitStrings of 8 bits. 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 |0| Type = TBDa | Length = 10 | 0 | 0 | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | 8 |0 0 0 0 0 0 1 0| 7 |1 0 0 0 0 0 0 0| 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | 6 |0 0 1 0 1 0 1 0| 0 |0 0 0 0 1 0 1 0| 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Figure 6: BIER-TE Path Subobject for a Path 678 3.6. BIER-TE Path Subobject in ERO 680 The ERO defined in [RFC5440] may contain a BIER-TE Path subobject for 681 the BitPositions of a BIER-TE path. The BitPositions in the BIER-TE 682 Path subobject for the BIER-TE path MUST be in descending order. 683 When an ERO contains one or more BIER-TE Path subobjects for a BIER- 684 TE path, the ERO MUST NOT include any other type of subobjects (i.e., 685 it MUST include only BIER-TE Path subobjects). The first one is used 686 and the others are ignored. 688 3.7. BIER-TE Path Subobject in RRO 690 A BIER-TE Path Subobject in a RRO (Record Route Object) has the same 691 format as a BIER-TE Path subobject in a ERO except for L flag. The 692 former does not have L flag. The format of a BIER-TE Path Subobject 693 in a RRO is shown in the firgure below. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type = TBDa | Length | sub-domain-id | MT-ID | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | BitPositions | 701 : : 702 | | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 7: BIER-TE Path Subobject in RRO 707 A PCC may send a PCE a message such as a PCRpt message defined in 708 [RFC8231]. The message contains a RRO with one BIER-TE Path 709 subobject having the BitPositions for the actual BIER-TE path that is 710 used to transport the traffic in the BIER-TE domain. The 711 BitPositions in the BIER-TE Path subobject for the BIER-TE path MUST 712 be in descending order. 714 4. Procedures 716 This section describes the procedures related to a BIER-TE path. 718 4.1. BIER-TE Path Creation 720 For PCC-Initiated BIER-TE path, a PCC MUST delegate the path by 721 sending a path computation report (PCRpt) message with its demanded 722 resources to a stateful PCE. Note the PCC MAY use the PCReq/PCRep 723 before delegating. 725 Upon receiving the delegation via PCRpt message, the stateful PCE 726 MUST compute a path based on the network resource availability stored 727 in the TED. 729 The stateful PCE will send a PCUpd message for the BIER-TE path to 730 the PCC. The stateful PCE MUST update its local LSP-DB and TED and 731 would need to synchronize the information with other PCEs in the 732 domain. 734 For PCE-Initiated BIER-TE path, the stateful PCE MUST compute a BIER- 735 TE path per request from network management systems or applications 736 automatically based on the network resource availability in the TED 737 and send a PCInitiate message with the path information to the PCC. 738 After receiving the PCInitiate message, the PCC creates the BIER-TE 739 path. 741 For both PCC-Initiated and PCE-Initiated BIER-TE paths: 743 o The stateful PCE MUST update its local LSP-DB and TED with the 744 paths. 746 o Upon receiving the PCUpd message or PCInitiate message for the 747 path from the PCE with a found path, the PCC determines that it is 748 a BIER-TE path by the PST = TBD1 for path setup using BIER-TE in 749 the PATH-SETUP-TYPE TLV of the SRP object in the message. 751 4.2. BIER-TE Path Update 753 After a BIER-TE path is created in a BIER-TE domain, when some 754 network events such as a node failure happen on the path (called old 755 path) or a leaf/egress joins/leaves, the PCE computes a new BIER-TE 756 path and replaces the old path with the new path. The new path 757 satisfies the same constraints as the old path. 759 The PCE sends a PCUpd message to the PCC running on the ingress node. 760 The message contains the information about the new BIER-TE path. 761 After receiving the message, the PCC overwrites (or replaces) the 762 BIER-TE path with the new BIER-TE path. 764 4.3. BIER-TE Path Deletion 766 For a BIER-TE path that has been created in a BIER-TE domain, after 767 receiving a request for deleting the path from a user or application, 768 the PCE MUST send a PCInitiate or PCUpd message to the PCC running on 769 the ingress node of the path to remove the path. 771 5. The PCEP Messages 773 5.1. The PCRpt Message 775 The Path Computation State Report (PCRpt) message is a PCEP message 776 sent by a PCC to a PCE to report the status of one or more LSPs, as 777 per [RFC8281]. Each LSP State Report in a PCRpt message contains the 778 actual LSP's path, bandwidth, operational and administrative status, 779 etc. An LSP Status Report carried in a PCRpt message is also used in 780 delegation or revocation of control of an LSP to/from a PCE. 782 In the case of a BIER-TE path, a PATH-SETUP-TYPE TLV with PST = TBD1 783 for path setup using BIER-TE MUST be carried in the SRP object in the 784 PCRpt message. A BIER-TE path in the message is represented by a 785 BIER-TE path subobject. 787 In addition, a PCRpt message is sent from the PCC running on an edge 788 node to the PCE to report that the edge node as leaf/egress joins/ 789 leaves to/from a multicast group and source. 791 5.2. The PCUpd Message 793 The Path Computation Update Request (PCUpd) message is a PCEP message 794 sent by a PCE to a PCC to update LSP parameters on one or more LSPs, 795 as per [RFC8281]. In the case of a BIER-TE path, a PATH-SETUP-TYPE 796 TLV with PST = TBD1 for path setup using BIER-TE MUST be carried in 797 the SRP object in the PCUpd message. Each BIER-TE path Update 798 Request in a PCUpd message contains all parameters that a PCE wishes 799 to be set for a given BIER-TE path. A BIER-TE path in the message is 800 represented by a BIER-TE path subobject. 802 5.3. The PCInitiate Message 804 The LSP Initiate Request (PCInitiate) message is a PCEP message sent 805 by a PCE to a PCC to trigger LSP instantiation or deletion, as per 806 [RFC8281]. In the case of a BIER-TE path, a PATH-SETUP-TYPE TLV with 807 PST = TBD1 for path setup using BIER-TE MUST be carried in the SRP 808 object in the PCInitiate message. A BIER-TE path in the message is 809 represented by a BIER-TE path subobject. The multicast packets to be 810 transported by the BIER-TE path is specified by the Multicast Flow 811 Specification TLV included in the SRP object. 813 5.4. The PCReq Message 815 The Path Computation Request (PCReq) message is a PCEP message sent 816 by a PCC to a PCE to request a path computation [RFC5440], and it may 817 contain the LSP object [RFC8231] to identify the LSP for which the 818 path computation is requested. In the case of a BIER-TE path, a 819 PATH-SETUP-TYPE TLV with PST = TBD1 for path setup using BIER-TE MUST 820 be carried in the SRP object in the PCReq message. 822 In addition, a PCReq message is sent from the PCE (as a PCC) for the 823 BIER-TE domain to another PCE for the domain that may contain the 824 multicast source for a BIER-TE path in order to find an ingress node 825 for the BIER-TE path. 827 5.5. The PCRep Message 829 The Path Computation Reply (PCRep) message is a PCEP message sent by 830 a PCE to a PCC in reply to a path computation request [RFC5440], and 831 it may contain the LSP object [RFC8231] to identify the LSP for which 832 the path is computed. A PCRep message can contain either a set of 833 computed paths if the request can be satisfied or a negative reply if 834 not. A negative reply may indicate the reason why no path could be 835 found. In the case of a BIER-TE path, a PATH-SETUP-TYPE TLV with PST 836 = TBD1 for path setup using BIER-TE MUST be carried in the SRP object 837 in the PCRep message. Each of the computed paths in the message is 838 represented by a BIER-TE path subobject. 840 In addition, a PCRep message is sent from the PCE for the domain that 841 may contain the multicast source for a BIER-TE path to the PCC (i.e., 842 the PCE for the BIER-TE domain) in response to the request for 843 finding an ingress node for the BIER-TE path. A PCRep message can 844 contain either a set of ingress nodes represented by ingress node 845 objects if the request can be satisfied or a negative reply if not. 847 6. IANA Considerations 849 6.1. PST for BIER-TE Path 851 IANA is requested to allocate a new code point within registry "PCEP 852 Path Setup Types" under "Path Computation Element Protocol (PCEP) 853 Numbers" as follows: 855 +==========+=============================+=================+ 856 | Value | Description | Reference | 857 +==========+=============================+=================+ 858 | TBD1 (2) | Path is setup using BIER-TE | This document | 859 +----------+-----------------------------+-----------------+ 861 6.2. PCE-BIER-TE-Path Capability sub-TLV 863 IANA is requested to allocate a new code point within registry "PATH- 864 SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators" under "Path 865 Computation Element Protocol (PCEP) Numbers" as follows: 867 +===========+=============================+=================+ 868 | Value | Meaning | Reference | 869 +===========+=============================+=================+ 870 | TBD2 (1) | PCE-BIER-TE-Path Capability | This document | 871 +-----------+-----------------------------+-----------------+ 873 6.3. SRP Object Flag Field 875 IANA is requested to allocate the following bits in the "SRP Object 876 Flag Field" subregistry under the "Path Computation Element Protocol 877 (PCEP) Numbers" registry: 879 +=========+===============================+=================+ 880 | Value | Description | Reference | 881 +=========+===============================+=================+ 882 | 27-29 | Assistant Operations for Path | This document | 883 +---------+-------------------------------+-----------------+ 885 6.4. Ingress Node Object 887 IANA is requested to allocate the following Object-Class Value in the 888 "PCEP Objects" subregistry under the "Path Computation Element 889 Protocol (PCEP) Numbers" registry: 891 +==================+========+===============+=============+ 892 |Object-Class Value|Name |Object-Type |Reference | 893 +==================+========+===============+=============+ 894 | TBD (45) |INGRESS |0: Reserved |This document| 895 | | |1: IPv4 Address|This document| 896 | | |2: IPv6 Address|This document| 897 | | |3-15:Unassigned| | 898 +------------------+--------+---------------+-------------+ 900 6.5. OF Code Points 902 IANA is requested to allocate the following Objective Function Code 903 Points in the "Objective Function" subregistry under the "Path 904 Computation Element Protocol (PCEP) Numbers" registry: 906 +============+=============================+=================+ 907 | Code Point | Name | Reference | 908 +============+=============================+=================+ 909 | TBD8 (18) | Minimum Bit Sets (MBS) | This document | 910 +------------+-----------------------------+-----------------+ 911 | TBD9 (19) | Minimum Bit Distance (MBD) | This document | 912 +------------+-----------------------------+-----------------+ 914 6.6. PCEP BIER-TE Path Subobjects 916 This document defines a new subobject, called PCE BIER-TE Path (or 917 BIER-TE-ERO) subobject, for PCEP ERO object. It also defines a new 918 subobject, called PCE BIER-TE Path (or BIER-TE-RRO) subobject, for 919 PCEP RRO object. The code points of the subobjects for the objects 920 are maintained under ERO and RRO objects in the RSVP Parameters 921 registry. 923 IANA is requested to allocate a code point under "Subobject type - 20 924 EXPLICIT_ROUTE - Type 1 Explicit Route" within registry "Resource 925 Reservation Protocol (RSVP) Parameters" for PCEP BIER-TE path 926 subobject as follows: 928 +===========+=============================+=================+ 929 | Value | Name | Reference | 930 +===========+=============================+=================+ 931 | TBDa (63) | PCEP BIER-TE Path | This document | 932 +-----------+-----------------------------+-----------------+ 934 IANA is requested to allocate a code point under "Subobject type - 21 935 ROUTE_RECORD - Type 1 Explicit Route" within registry "Resource 936 Reservation Protocol (RSVP) Parameters" for PCEP BIER-TE path 937 subobject as follows: 939 +===========+=============================+=================+ 940 | Value | Name | Reference | 941 +===========+=============================+=================+ 942 | TBDa (63) | PCEP BIER-TE Path | This document | 943 +-----------+-----------------------------+-----------------+ 945 7. Security Considerations 947 TBD 949 8. Acknowledgements 951 The authors would like to thank Dhruv Dhody, and others for their 952 comments to this work. 954 9. References 956 9.1. Normative References 958 [I-D.ietf-bier-te-arch] 959 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 960 for Bit Index Explicit Replication (BIER-TE)", draft-ietf- 961 bier-te-arch-09 (work in progress), October 2020. 963 [I-D.ietf-pce-pcep-flowspec] 964 Dhody, D., Farrel, A., and Z. Li, "PCEP Extension for Flow 965 Specification", draft-ietf-pce-pcep-flowspec-12 (work in 966 progress), October 2020. 968 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 969 Requirement Levels", BCP 14, RFC 2119, 970 DOI 10.17487/RFC2119, March 1997, 971 . 973 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 974 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 975 DOI 10.17487/RFC5440, March 2009, 976 . 978 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 979 Objective Functions in the Path Computation Element 980 Communication Protocol (PCEP)", RFC 5541, 981 DOI 10.17487/RFC5541, June 2009, 982 . 984 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 985 Computation Element Communication Protocol (PCEP) 986 Extensions for Stateful PCE", RFC 8231, 987 DOI 10.17487/RFC8231, September 2017, 988 . 990 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 991 and D. Dhody, "Optimizations of Label Switched Path State 992 Synchronization Procedures for a Stateful PCE", RFC 8232, 993 DOI 10.17487/RFC8232, September 2017, 994 . 996 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 997 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 998 Explicit Replication (BIER)", RFC 8279, 999 DOI 10.17487/RFC8279, November 2017, 1000 . 1002 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1003 Computation Element Communication Protocol (PCEP) 1004 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1005 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1006 . 1008 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 1009 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 1010 for Bit Index Explicit Replication (BIER) in MPLS and Non- 1011 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 1012 2018, . 1014 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1015 Hardwick, "Conveying Path Setup Type in PCE Communication 1016 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1017 July 2018, . 1019 9.2. Informative References 1021 [I-D.chen-pce-bier] 1022 Chen, R., Zhang, Z., Dhanaraj, S., and F. Qin, "PCEP 1023 Extensions for BIER-TE", draft-chen-pce-bier-08 (work in 1024 progress), November 2020. 1026 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1027 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1028 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1029 July 2018, . 1031 Authors' Addresses 1033 Huaimo Chen 1034 Futurewei 1035 Boston, MA 1036 USA 1038 Email: Huaimo.chen@futurewei.com 1040 Mike McBride 1041 Futurewei 1043 Email: michael.mcbride@futurewei.com 1045 Aijun Wang 1046 China Telecom 1047 Beiqijia Town, Changping District 1048 Beijing, 102209 1049 China 1051 Email: wangaj3@chinatelecom.cn 1053 Gyan S. Mishra 1054 Verizon Inc. 1055 13101 Columbia Pike 1056 Silver Spring MD 20904 1057 USA 1059 Phone: 301 502-1347 1060 Email: gyan.s.mishra@verizon.com 1062 Yisong Liu 1063 China Mobile 1065 Email: liuyisong@chinamobile.com 1066 Yanhe Fan 1067 Casa Systems 1068 USA 1070 Email: yfan@casa-systems.com 1072 Lei Liu 1073 Fujitsu 1075 USA 1077 Email: liulei.kddi@gmail.com 1079 Xufeng Liu 1080 Volta Networks 1082 McLean, VA 1083 USA 1085 Email: xufeng.liu.ietf@gmail.com