idnits 2.17.1 draft-chen-pce-bier-09.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 : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-bier-te-arch], [RFC8279]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2021) is 1022 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) == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-09 ** Downref: Normative reference to an Informational RFC: RFC 4657 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group R. Chen 3 Internet-Draft Zh. Zhang 4 Intended status: Standards Track ZTE Corporation 5 Expires: January 10, 2022 H. Chen 6 S. Dhanaraj 7 Futurewei 8 F. Qin 9 China Mobile 10 A. Wang 11 China Telecom 12 July 9, 2021 14 PCEP Extensions for BIER-TE 15 draft-chen-pce-bier-09 17 Abstract 19 Bit Index Explicit Replication (BIER)-TE shares architecture and 20 packet formats with BIER as described in [RFC8279]. BIER-TE forwards 21 and replicates packets based on a BitString in the packet header, but 22 every BitPosition of the BitString of a BIER-TE packet indicates one 23 or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE 24 Path can be derived from a Path Computation Element (PCE). 26 This document specifies extensions to the Path Computation Element 27 Protocol (PCEP) that allow a PCE to compute and initiate the path for 28 the BIER-TE. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 10, 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions used in this document . . . . . . . . . . . . . . 3 66 3. Overview of PCEP Operation in BIER Networks . . . . . . . . . 3 67 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 3 68 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 4 69 4.1.1. The BIER-TE PCE Capability sub-TLV . . . . . . . . . 4 70 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 5 71 4.3. END-POINTS object . . . . . . . . . . . . . . . . . . . . 5 72 4.4. Objective Functions . . . . . . . . . . . . . . . . . . . 5 73 4.5. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.5.1. BIER-TE-ERO Subobject . . . . . . . . . . . . . . . . 5 75 4.6. RRO Object . . . . . . . . . . . . . . . . . . . . . . . 7 76 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 5.1. Exchanging the BIER-TE Capability . . . . . . . . . . . . 7 78 5.2. BIER-TE-ERO Processing . . . . . . . . . . . . . . . . . 8 79 5.3. BIER-TE-RRO Processing . . . . . . . . . . . . . . . . . 8 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 6.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 8 82 6.1.1. BIER-TE-PCE-CAPABILITY Sub-TLV Type Indicators . . . 9 83 6.1.2. New Path Setup Type . . . . . . . . . . . . . . . . . 9 84 6.1.3. Objective Functions . . . . . . . . . . . . . . . . . 9 85 6.1.4. BIER-TE-ERO and RRO Subobjects . . . . . . . . . . . 9 86 6.1.5. PCEP-Error Objects and Types . . . . . . . . . . . . 10 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 89 9. Normative references . . . . . . . . . . . . . . . . . . . . 10 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 Bit Index Explicit Replication (BIER)-TE shares architecture and 95 packet formats with BIER as described in [RFC8279]. BIER-TE forwards 96 and replicates packets based on a BitString in the packet header, but 97 every BitPosition of the BitString of a BIER-TE packet indicates one 98 or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE 99 Path can be derived from a Path Computation Element (PCE). 101 [RFC8231] specifies a set of extensions to PCEP that allow a PCE to 102 compute and recommend network paths in compliance with [RFC4657] and 103 defines objects and TLVs for MPLS-TE LSPs. 105 This document uses a PCE for computing one or more BIER-TE paths 106 taking into account various constraints and objective functions. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC2119. 114 3. Overview of PCEP Operation in BIER Networks 116 BIER-TE forwards and replicates packets based on a BitString in the 117 packet header, and every BitPosition of the BitString of a BIER-TE 118 packet indicates one or more adjacencies as described in 119 [I-D.ietf-bier-te-arch]. In a PCEP session, An ERO object specified 120 in [RFC5440] can be extended to carry a BIER-TE path consists of one 121 or more BIER-TE-ERO subobject(s). BIER-TE computed by a PCE can be 122 represented in the following forms: 124 o An ordered set of adjacencies BitString(s) in which each bit 125 represents that the adjacencies to which the BFR should replicate 126 packets to in the domain. 128 In this document, we define a set of PCEP protocol extensions, 129 including a new PCEP capability,a new Path Setup Type (PST) ,reuse 130 BIER END-POINT Object,a new Objective Functions subobjects,a new ERO 131 subobjects, a new RRO subobjects, a new PCEP error codes and 132 procedures. 134 4. Object Formats 135 4.1. The OPEN Object 137 4.1.1. The BIER-TE PCE Capability sub-TLV 139 [RFC8408]defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the 140 OPEN object. The PATH-SETUP-TYPE-CAPABILITY TLV contains an optional 141 list of sub-TLVs which are intended to convey parameters that are 142 associated with the path setup types supported by a PCEP speaker. 144 This document defines a new Path Setup Type (PST) for BIER-TE as 145 follows: 147 o PST = TBD2: Path is setup using BIER-TE technique. 149 A PCEP speaker MUST indicate its support of the function described in 150 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 151 object with this new PST included in the PST list. 153 This document also defines the BIER-TE-PCE-CAPABILITY sub-TLV. PCEP 154 speakers use this sub-TLV to exchange BIER capability. If a PCEP 155 speaker includes PST=TBD2 in the PST List of the PATH-SETUP-TYPE- 156 CAPABILITY TLV then it MUST also include the BIER-TE-PCE-CAPABILITY 157 sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. 159 The format of the BIER-TE-PCE-CAPABILITY sub-TLV is shown in the 160 following figure: 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Type=TBD1 | Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Reserved | Flags | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1 BIER-TE-PCE-CAPABILITY sub-TLV format 172 The code point for the TLV type is to be defined by IANA. 174 Length: 4 bytes. 176 The "Reserved" (2 octet) and "Flags" (2 octet) fields are currently 177 unused, and MUST be set to zero on transmission and ignored on 178 reception. 180 4.2. The RP/SRP Object 182 In order to setup an BIER-TE, a new PATH-SETUP-TYPE TLV MUST be 183 contained in RP/SRP object. This document defines a new Path Setup 184 Type (PST=TBD2) for BIER-TE. 186 4.3. END-POINTS object 188 The END-POINTS object which is defined in [RFC8306]is used in a PCReq 189 message to specify the BIER information of the path for which a path 190 computation is requested. To represent the end points for a BIER 191 path efficiently, we reuse the P2MP END-POINTS object body for 192 IPv4(Object-Type 3) and END-POINTS object body for IPv6 (Object-Type 193 4) which is defined in [RFC8306]. 195 4.4. Objective Functions 197 [RFC5541] defines a mechanism to specify an objective function (OF) 198 that is used by a PCE when it computes a path. For a BIER-TE path,a 199 new OF is defined. 201 Objective Function Code: TBD3 202 Name: Minimum Bit Sets (MBS) 203 Description: Find a path represented by BitPositions that has 204 the minimum number of bit sets. 206 4.5. ERO Object 208 BIER-TE consists of one or more adjacencies BitStrings where every 209 BitPosition of the BitString indicates one or more adjacencies, as 210 described in([RFC8279]). 212 The ERO object specified in [RFC5440] is used to encode the path of a 213 TE LSP through the network.The ERO is carried within a PCRep message 214 to provide the computed TE LSP if the path computation was 215 successful.In order to carry BIER-TE explicit paths, this document 216 defines a new ERO subobjects referred to as "BIER-TE-ERO subobjects" 217 whose formats are specified in the following section. An BIER-TE-ERO 218 subobjects carrying a adjacencies BitStrings consists of one or more 219 BIER-TE-ERO subobject(s). 221 4.5.1. BIER-TE-ERO Subobject 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |L| Type=TBD4 | Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | BS Length | subdomain-id | SI | Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Adjacency BitString (first 32 bits) ~ 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 ~ ~ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 ~ Adjacency BitString (last 32 bits) | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 3 238 The 'L' Flag: Indicates whether the subobject represents a loose-hop 239 in the LSP[RFC3209]. If the bit is not set, the subobject represents 240 a strict hop in the explicit route. 242 Type: TBD4 244 Length: 1 octet ([RFC3209]). Contains the total length of the 245 subobject in octets. The Length MUST be at least 8, and MUST be a 246 multiple of 4. 248 BS Length: A 1 octet field encodes the length in bits of the 249 BitString as per [RFC8296], the maximum length of the BitString is 5, 250 it indicates the length of BitString is 1024.It is used to refer to 251 the number of bits in the BitString. 253 subdomain-id: Unique value identifying the BIER subdomain. 1 octet. 255 SI: Set Identifier (Section 1 of [RFC8279] used in the encapsulation 256 for this BIER subdomain for this BitString length, 1 octet. 258 The "Reserved" (1 octets) fields are currently unused, and MUST be 259 set to zero on transmission and ignored on reception. 261 Adjacency BitString: a variable length field encoding the Adjacency 262 BitString where every BitPosition of the BitString indicates one or 263 more adjacencies.the length of this field is according the BS length. 264 The minimum value of this field is 64 bits, and the maximum value of 265 this field is 1024 bits. 267 Notice: 269 The maximum value of BS Length is limited to the 1024 bits, in case 270 the BIER-TE-ERO Subobject is too long. 272 4.6. RRO Object 274 An RRO contains one or more subobjects called "BIER-TE-RRO 275 subobjects", whose format is shown below: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type=TBD5 | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | BS Length | subdomain-id | SI | Reserved | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Adjacency BitString (first 32 bits) ~ 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 ~ ~ 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 ~ Adjacency BitString (last 32 bits) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 4 293 The format of the BIER-TE-RRO subobject is the same as that of the 294 BIER-TE-ERO subobject, but without the L-Flag. 296 For the integrity of the protocol, we define a new BIER-TE-RRO 297 object, but its actual value is consistent with ERO. The PCC reports 298 an BIER-TE to a PCE by sending a PCRpt message with RRO object. 300 5. Procedures 302 5.1. Exchanging the BIER-TE Capability 304 A PCC indicates that it is capable of supporting the head-end 305 functions for BIER-TE by including the BIER-TE-PCE-CAPABILITY sub-TLV 306 in the Open message that it sends to a PCE. A PCE indicates that it 307 is capable of computing BIER-TE by including the BIET-TE-PCE- 308 CAPABILITY sub-TLV in the Open message that it sends to a PCC. 310 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 311 PST list containing PST=TBD2, and supports that path setup type, then 312 it checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that 313 sub-TLV is absent, then the PCEP speaker MUST send a PCErr message 314 with Error-Type = 10 ("Reception of an invalid object") and Error- 315 value = TBD6("Missing PCE-BIER-TE-CAPABILITY sub-TLV") and MUST then 316 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 317 TYPE- CAPABILITY TLV with a BIER-TE-PCE-CAPABILITY sub-TLV, but the 318 PST list does not contain PST=TBD2, then the PCEP speaker MUST ignore 319 the BIER-TE-PCE-CAPABILITY sub-TLV. 321 5.2. BIER-TE-ERO Processing 323 If a PCC does not support the BIER-TE PCE Capability and thus cannot 324 recognize the BIER-TE-ERO or BIER-TE-RRO subobjects,The ERO and BIER- 325 TE-ERO subobject processing remains as per [RFC5440]. 327 If a PCC receives an BIER-TE-ERO subobject in which either 328 BitStringLength or Adjacency BitString or SI is absent, it MUST 329 consider the entire BIER-TE-ERO subobject invalid and send a PCErr 330 message with Error-Type = 10 ("Reception of an invalid object"), 331 Error-Value = TBD7 ("BitStringLength is absent ") or Error-Value = 332 TBD8 ("Adjacency BitString is absent")or Error-Value = TBD9("SI is 333 absent"). 335 If a PCC receives an BIER-TE-ERO subobject in which BitStringLength 336 values are not chosen from: 64, 128, 256, 512, 1024, as it described 337 in ( [RFC8279]). The PCC MUST send a PCErr message with Error-Type 338 =10 ("Reception of an invalid object") and Error-Value = TBD10 339 ("Invalid BitStringLength"). 341 When a PCEP speaker detects that all subobjects of ERO are not of 342 type TBD4, and if it does not handle such ERO, it MUST send a PCErr 343 message with Error-Type = 10 ("Reception of an invalid object") and 344 Error-Value = TBD11 ("Non-identical ERO subobjects")as per [RFC8664]. 346 5.3. BIER-TE-RRO Processing 348 The syntax checking rules that apply to the BIER-TE-RRO subobject are 349 identical to those of the BIER-TE-ERO subobject 351 The actual value of BIER-TE-RRO subobject is consistent with ERO. 352 The PCC reports an BIER-TE to a PCE by sending a PCRpt message with 353 RRO object. 355 6. IANA Considerations 357 6.1. PCEP Objects 359 IANA has made the following Object-Type allocations from the "PCEP 360 Objects" sub-registry. 362 6.1.1. BIER-TE-PCE-CAPABILITY Sub-TLV Type Indicators 364 +----------------+------------------------+----------------+ 365 | vlaue | Meaning | Reference | 366 +================+========================+================+ 367 | TBD1 | BIER-TE-PCE-CAPABILITY |This Document | 368 +----------------+------------------------+----------------+ 370 6.1.2. New Path Setup Type 372 +----------------+-------------------------+----------------+ 373 | vlaue | Meaning | Reference | 374 +================+=========================+================+ 375 | TBD2 | Path is setup using BIER| This Document | 376 | | TE technique | | 377 +----------------+-------------------------+----------------+ 379 6.1.3. Objective Functions 381 +----------------+------------------------+----------------+ 382 | vlaue | Meaning | Reference | 383 +================+========================+================+ 384 | TBD3 | Minimum Bit Sets (MBS) |This Document | 385 +----------------+------------------------+----------------+ 387 6.1.4. BIER-TE-ERO and RRO Subobjects 389 This document defines a new subobject type for the PCEP explicit 390 route object (ERO) and a new subobject type for the PCEP RRO.The code 391 points for subobject types of these objects are maintained in the 392 RSVP parameters registry, under the EXPLICIT_ROUTE and ROUTE_RECORD 393 objects, respectively. 395 +----------------+----------------------------+----------------+ 396 | Object | Subobject | Subobject Type | 397 +================+============================+================+ 398 | EXPLICIT_ROUTE | BIER-TE-ERO (PCEP specific)| TBD4 | 399 +----------------+----------------------------+----------------+ 400 | ROUTE_RECORD | BIER-TE-RRO (PCEP specific)| TBD5 | 401 +----------------+----------------------------+----------------+ 403 6.1.5. PCEP-Error Objects and Types 405 IANA is requested to allocate code-points in the "PCEP-ERROR Object 406 Error Types and Values" subregistry for the following new error-types 407 and error-values: 409 +------------+-----------------+---------------------------------------+ 410 | Error-Type | Meaning | Error-value | 411 +============+=================+=======================================+ 412 | 10 | Reception of an | | 413 | | invalid object | | 414 +------------+-----------------+---------------------------------------+ 415 | | | TBD6: Missing PCE-BIER-TE-CAPABILITY | 416 | | | subobjects | 417 +------------+-----------------+---------------------------------------+ 418 | | | TBD7: BitStringLength is absent | 419 +------------+-----------------+---------------------------------------+ 420 | | | TBD8: Adjacency BitString is absent | 421 +------------+-----------------+---------------------------------------+ 422 | | | TBD9: SI is absent | 423 +------------+-----------------+---------------------------------------+ 424 | | | TBD10: Invalid BitStringLength | 425 +------------+-----------------+---------------------------------------+ 426 | | | TBD11: Non-identical ERO subobjects | 427 +------------+-----------------+---------------------------------------+ 429 7. Security Considerations 431 The security considerations described in [RFC5440], [RFC8231], 432 [RFC8281] and[RFC8408]are applicable to this specification. No 433 additional security measures are required. 435 8. Acknowledgements 437 The authors thank Dhruv Dhody, Benchong Xu, Chun Zhu, and Zhaohui 438 Zhang and many others for their suggestions and comments. 440 9. Normative references 442 [I-D.ietf-bier-te-arch] 443 Eckert, T., Cauchie, G., and M. Menth, "Tree Engineering 444 for Bit Index Explicit Replication (BIER-TE)", draft-ietf- 445 bier-te-arch-09 (work in progress), October 2020. 447 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 448 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 449 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 450 . 452 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 453 Element (PCE) Communication Protocol Generic 454 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 455 2006, . 457 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 458 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 459 DOI 10.17487/RFC5440, March 2009, 460 . 462 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 463 Objective Functions in the Path Computation Element 464 Communication Protocol (PCEP)", RFC 5541, 465 DOI 10.17487/RFC5541, June 2009, 466 . 468 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 469 Computation Element Communication Protocol (PCEP) 470 Extensions for Stateful PCE", RFC 8231, 471 DOI 10.17487/RFC8231, September 2017, 472 . 474 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 475 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 476 Explicit Replication (BIER)", RFC 8279, 477 DOI 10.17487/RFC8279, November 2017, 478 . 480 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 481 Computation Element Communication Protocol (PCEP) 482 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 483 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 484 . 486 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 487 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 488 for Bit Index Explicit Replication (BIER) in MPLS and Non- 489 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 490 2018, . 492 [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, 493 "Extensions to the Path Computation Element Communication 494 Protocol (PCEP) for Point-to-Multipoint Traffic 495 Engineering Label Switched Paths", RFC 8306, 496 DOI 10.17487/RFC8306, November 2017, 497 . 499 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 500 Hardwick, "Conveying Path Setup Type in PCE Communication 501 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 502 July 2018, . 504 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 505 and J. Hardwick, "Path Computation Element Communication 506 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 507 DOI 10.17487/RFC8664, December 2019, 508 . 510 Authors' Addresses 512 Ran Chen 513 ZTE Corporation 515 Email: chen.ran@zte.com.cn 517 Zheng Zhang 518 ZTE Corporation 520 Email: zhang.zheng@zte.com.cn 522 Huaimo Chen 523 Futurewei 525 Email: huaimo.chen@futurewei.com 527 Senthil Dhanaraj 528 Futurewei 530 Email: senthil.dhanaraj.ietf@gmail.com 532 Fengwei Qin 533 China Mobile 535 Email: qinfengwei@chinamobile.com 536 Aijun Wang 537 China Telecom 539 Email: wangaj3@chinatelecom.cn