idnits 2.17.1 draft-sivabalan-pce-binding-label-sid-05.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 (October 19, 2018) is 2009 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 (-16) exists of draft-ietf-pce-segment-routing-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 == Outdated reference: A later version (-08) exists of draft-li-pce-sr-path-segment-02 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Sivabalan 3 Internet-Draft C. Filsfils 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: April 22, 2019 J. Tantsura 6 Apstra, Inc. 7 J. Hardwick 8 Metaswitch Networks 9 S. Previdi 10 D. Dhody 11 Huawei Technologies 12 October 19, 2018 14 Carrying Binding Label/Segment-ID in PCE-based Networks. 15 draft-sivabalan-pce-binding-label-sid-05 17 Abstract 19 In order to provide greater scalability, network opacity, and service 20 independence, SR utilizes a Binding Segment Identifier (BSID). It is 21 possible to associate a BSID to RSVP-TE signaled Traffic Engineering 22 Label Switching Path or binding Segment-ID (SID) to Segment Routed 23 (SR) Traffic Engineering path. Such a binding label/SID can be used 24 by an upstream node for steering traffic into the appropriate TE path 25 to enforce SR policies. This document proposes an approach for 26 reporting binding label/SID to Path Computation Element (PCE) for 27 supporting PCE-based Traffic Engineering policies. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 22, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Path Binding TLV . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 8 78 6.1.1. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . . 8 79 6.2. PCEP Error Type and Value . . . . . . . . . . . . . . . . 8 80 7. Manageability Considerations . . . . . . . . . . . . . . . . 8 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 9.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Appendix A. PCE based Central Controller . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 A PCE can compute Traffic Engineering paths (TE paths) through a 91 network that are subject to various constraints. Currently, TE paths 92 are either set up using the RSVP-TE signaling protocol or Segment 93 Routing (SR). We refer to such paths as RSVP-TE paths and SR-TE 94 paths respectively in this document. 96 As per [RFC8402] SR allows a headend node to steer a packet flow 97 along any path. The headend node is said to steer a flow into an 98 Segment Routing Policy (SR Policy). Further, as per 99 [I-D.ietf-spring-segment-routing-policy], an SR Policy is a framework 100 that enables instantiation of an ordered list of segments on a node 101 for implementing a source routing policy with a specific intent for 102 traffic steering from that node. 104 As described in [RFC8402], Binding Segment Identifier (BSID) is bound 105 to an Segment Routed (SR) Policy, instantiation of which may involve 106 a list of SIDs. Any packets received with an active segment equal to 107 BSID are steered onto the bound SR Policy. A BSID may be either a 108 local (SRLB) or a global (SRGB) SID. As per 109 [I-D.ietf-spring-segment-routing-policy] a BSID can also be 110 associated with any type of interfaces or tunnel to enable the use of 111 a non-SR interface or tunnels as segments in a SID-list. 113 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 114 communication between a Path Computation Client (PCC) and a PCE or 115 between a pair of PCEs. [RFC8231] specifies extension to PCEP that 116 allows a PCC to delegate its LSPs to a stateful PCE. A stateful PCE 117 can then update the state of LSPs delegated to it. [RFC8281] 118 specifies a mechanism allowing a PCE to dynamically instantiate an 119 LSP on a PCC by sending the path and characteristics. The PCEP 120 extension to setup and maintain SR-TE paths is specified in 121 [I-D.ietf-pce-segment-routing]. 123 [I-D.ietf-pce-segment-routing] provides a mechanism for a network 124 controller (acting as a PCE) to instantiate candidate paths for an SR 125 Policy onto a head-end node (acting as a PCC) using PCEP. For more 126 information on the SR Policy Architecture, see 127 [I-D.ietf-spring-segment-routing-policy]. 129 Binding label/SID has local significance to the ingress node of the 130 corresponding TE path. When a stateful PCE is deployed for setting 131 up TE paths, it may be desirable to report the binding label or SID 132 to the stateful PCE for the purpose of enforcing end-to-end TE/SR 133 policy. A sample Data Center (DC) use-case is illustrated in the 134 following diagram. In the MPLS DC network, an SR LSP (without 135 traffic engineering) is established using a prefix SID advertised by 136 BGP (see [I-D.ietf-idr-bgp-prefix-sid]). In IP/MPLS WAN, an SR-TE 137 LSP is setup using the PCE. The list of SIDs of the SR-TE LSP is {A, 138 B, C, D}. The gateway node 1 (which is the PCC) allocates a binding 139 SID X and reports it to the PCE. In order for the access node to 140 steer the traffic over the SR-TE LSP, the PCE passes the SID stack 141 {Y, X} where Y is the prefix SID of the gateway node-1 to the access 142 node. In the absence of the binding SID X, the PCE should pass the 143 SID stack {Y, A, B, C, D} to the access node. This example also 144 illustrates the additional benefit of using the binding SID to reduce 145 the number of SIDs imposed on the access nodes with a limited 146 forwarding capacity. 148 SID stack 149 {Y, X} +-----+ 150 _ _ _ _ _ _ _ _ _ _ _ _ _ _| PCE | 151 | +-----+ 152 | ^ 153 | | Binding 154 | .-----. | SID (X) .-----. 155 | ( ) | ( ) 156 V .--( )--. | .--( )--. 157 +------+ ( ) +-------+ ( ) +-------+ 158 |Access|_( MPLS DC Network )_|Gateway|_( IP/MPLS WAN )_|Gateway| 159 | Node | ( ==============> ) |Node-1 | ( ================> ) |Node-2 | 160 +------+ ( SR path ) +-------+ ( SR-TE path ) +-------+ 161 '--( )--' Prefix '--( )--' 162 ( ) SID of ( ) 163 '-----' Node-1 '-----' 164 is Y SIDs for SR-TE LSP: 165 {A, B, C, D} 167 Figure 1: A sample Use-case of Binding SID 169 A PCC could report the binding label/SID allocated by it to the 170 stateful PCE via Path Computation State Report (PCRpt) message. It 171 is also possible for a stateful PCE to request a PCC to allocate a 172 specific binding label/SID by sending an Path Computation Update 173 Request (PCUpd) message. If the PCC can successfully allocate the 174 specified binding value, it reports the binding value to the PCE. 175 Otherwise, the PCC sends an error message to the PCE indicating the 176 cause of the failure. A local policy or configuration at the PCC 177 SHOULD dictate if the binding label/SID needs to be assigned. 179 In this document, we introduce a new OPTIONAL TLV that a PCC can use 180 in order to report the binding label/SID associated with a TE LSP, or 181 a PCE to request a PCC to allocate a specific binding label/SID 182 value. This TLV is intended for TE LSPs established using RSVP-TE, 183 SR, or any other future method. Also, in the case of SR-TE LSPs, the 184 TLV can carry a binding MPLS label (for SR-TE path with MPLS data- 185 plane) or a binding IPv6 SID (e.g., IPv6 address for SR-TE paths with 186 IPv6 data-plane). However, use of this TLV for carrying non-MPLS 187 binding SID will be described in separate document(s). Binding value 188 means either MPLS label or SID throughout this document. 190 2. Terminology 192 The following terminologies are used in this document: 194 BSID: Binding Segment Identifier. 196 LER: Label Edge Router. 198 LSP: Label Switched Path. 200 LSR: Label Switching Router. 202 PCC: Path Computation Client. 204 PCE: Path Computation Element 206 PCEP: Path Computation Element Protocol. 208 RSVP-TE: Resource ReserVation Protocol-Traffic Engineering. 210 SID: Segment Identifier. 212 SR: Segment Routing. 214 SRGB: Segment Routing Global Block. 216 SRLB: Segment Routing Local Block. 218 TLV: Type, Length, and Value. 220 3. Path Binding TLV 222 The new optional TLV is called "TE-PATH-BINDING TLV" whose format is 223 shown in the diagram below is defined to carry binding label or SID 224 for a TE path. This TLV is associated with the LSP object specified 225 in ([RFC8231]). The type of this TLV is to be allocated by IANA. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Length | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Binding Type (BT) | Binding Value | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 ~ Binding Value (continued) (variable length) ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: TE-PATH-BINDING TLV 239 TE-PATH-BINDING TLV is a generic TLV such that it is able to carry 240 MPLS label binding as well as other types of future bindings (e.g., 241 SRv6 path). It is formatted according to the rules specified in 242 [RFC5440]. The two byte Binding Type (BT) field identifies the type 243 of binding included in the TLV. This document specifies the 244 following BT values: 246 o BT = 0: The binding value is an MPLS label carried in the format 247 specified in [RFC5462] where only the label value is valid, and 248 other fields (TC, S, and TTL) fields MUST be considered invalid. 249 The Length MUST be set to 6. 251 o BT = 1: Similar to the case where BT is 0 except that all the 252 fields on the MPLS label entry are set on transmission. However, 253 the receiver MAY choose to override TC, S, and TTL values 254 according its local policy. 256 Binding Value: A variable length field, padded with trailing zeros to 257 a 4-byte boundary. For the BT as 0, the 20 bits represents the MPLS 258 label. For the BT as 1, the 32-bits represents the label stack entry 259 as per [RFC5462]. 261 4. Operation 263 The binding value is allocated by the PCC and reported to a PCE via 264 PCRpt message. If a PCE does not recognize the TE-PATH-BINDING TLV, 265 it MUST ignore the TLV in accordance with ([RFC5440]). If a PCE 266 recognizes the TLV but does not support the TLV, it MUST send PCErr 267 with Error-Type = 2 (Capability not supported). 269 If a TE-PATH-BINDING TLV is absent in PCRpt message, PCE MUST assume 270 that the corresponding LSP does not have any binding. If there are 271 more than one TE-PATH-BINDING TLVs, only the first TLV MUST be 272 processed and the rest MUST be silently ignored. If a PCE recognizes 273 an invalid binding value (e.g., label value from the reserved label 274 space when MPLS label binding is used), it MUST send the PCErr 275 message with Error-Type = 10 ("Reception of an invalid object") and 276 Error Value = TBD ("Bad label value") as specified in 277 [I-D.ietf-pce-segment-routing]. 279 If a PCE requires a PCC to allocate a specific binding value, it may 280 do so by sending a PCUpd or PCInitiate message containing a TE-PATH- 281 BINDING TLV. If the value can be successfully allocated, the PCC 282 reports the binding value to the PCE. If the PCC considers the 283 binding value specified by the PCE invalid, it MUST send a PCErr 284 message with Error-Type = TBD ("Binding label/SID failure") and Error 285 Value = TBD ("Invalid SID"). If the binding value is valid, but the 286 PCC is unable to allocate the binding value, it MUST send a PCErr 287 message with Error-Type = TBD ("Binding label/SID failure") and Error 288 Value = TBD ("Unable to allocate the specified label/SID"). 290 If a PCC receives TE-PATH-BINDING TLV in any message other than PCUpd 291 or PCInitiate, it MUST close the corresponding PCEP session with the 292 reason "Reception of a malformed PCEP message" (according to 293 [RFC5440]). Similarly, if a PCE receives a TE-PATH-BINDING TLV in 294 any message other than a PCRpt or if the TE-PATH-BINDING TLV is 295 associated with any object other than LSP object, the PCE MUST close 296 the corresponding PCEP session with the reason "Reception of a 297 malformed PCEP message" (according to [RFC5440]). 299 If a PCC wishes to withdraw or modify a previously reported binding 300 value, it MUST send a PCRpt message without any TE-PATH-BINDING TLV 301 or with the TE-PATH-BINDING TLV containing the new binding value 302 respectively. 304 If a PCE wishes to modify a previously requested binding value, it 305 MUST send a PCUpd message with TE-PATH-BINDING TLV containing the new 306 binding value. Absence of TE-PATH-BINDING TLV in PCUpd message means 307 that the PCE does not specify a binding value in which case the 308 binding value allocation is governed by the PCC's local policy. 310 If a PCC receives a valid binding value from a PCE which is different 311 than the current binding value, it MUST try to allocate the new 312 value. If the new binding value is successfully allocated, the PCC 313 MUST report the new value to the PCE. Otherwise, it MUST send a 314 PCErr message with Error-Type = TBD ("Binding label/SID failure") and 315 Error Value = TBD ("Unable to allocate the specified label/SID"). 317 In some cases, a stateful PCE can request the PCC to allocate a 318 binding value. It may do so by sending a PCUpd message containing an 319 empty TE-PATH-BINDING TLV, i.e., no binding value is specified 320 (making the length field of the TLV as 2). A PCE can also make the 321 request PCC to allocate a binding at the time of initiation by 322 sending a PCInitiate message with an empty TE-PATH-BINDING TLV. 324 5. Security Considerations 326 The security considerations described in [RFC5440], [RFC8231], 327 [RFC8281] and [I-D.ietf-pce-segment-routing] are applicable to this 328 specification. No additional security measure is required. 330 As described [I-D.ietf-pce-segment-routing], SR allows a network 331 controller to instantiate and control paths in the network. Note 332 that if the security mechanisms of [RFC5440] and [RFC8281] are not 333 used, then the protocol described in this document could be attacked 334 via manipulation of BSID. 336 6. IANA Considerations 338 6.1. PCEP TLV Type Indicators 340 This document defines a new PCEP TLV; IANA is requested to make the 341 following allocations from the "PCEP TLV Type Indicators" sub- 342 registry of the PCEP Numbers registry, as follows: 344 Value Name Reference 346 TBD TE-PATH-BINDING This document 348 6.1.1. TE-PATH-BINDING TLV 350 IANA is requested to create a sub-registry to manage the value of the 351 Binding Type field in the TE-PATH-BINDING TLV. 353 Value Description Reference 355 0 MPLS Label This document 356 1 MPLS Label Stack This document 357 Entry 359 6.2. PCEP Error Type and Value 361 This document defines a new Error-type and Error-Values for the PCErr 362 message. IANA is requested to allocate new error-type and error- 363 values within the "PCEP-ERROR Object Error Types and Values" 364 subregistry of the PCEP Numbers registry, as follows: 366 Error-Type Meaning 367 ---------- ------- 368 TBD Binding label/SID failure: 370 Error-value = TBD: Invalid SID 371 Error-value = TBD: Unable to allocate 372 the specified 373 label/SID 375 7. Manageability Considerations 377 TBD 379 8. Acknowledgements 381 We like to thank Milos Fabian for his valuable comments. 383 9. References 385 9.1. Normative References 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, 389 DOI 10.17487/RFC2119, March 1997, 390 . 392 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 393 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 394 DOI 10.17487/RFC5440, March 2009, 395 . 397 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 398 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 399 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 400 2009, . 402 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 403 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 404 May 2017, . 406 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 407 Computation Element Communication Protocol (PCEP) 408 Extensions for Stateful PCE", RFC 8231, 409 DOI 10.17487/RFC8231, September 2017, 410 . 412 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 413 Computation Element Communication Protocol (PCEP) 414 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 415 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 416 . 418 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 419 Decraene, B., Litkowski, S., and R. Shakir, "Segment 420 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 421 July 2018, . 423 [I-D.ietf-pce-segment-routing] 424 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 425 and J. Hardwick, "PCEP Extensions for Segment Routing", 426 draft-ietf-pce-segment-routing-14 (work in progress), 427 October 2018. 429 9.2. Informative References 431 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 432 Element (PCE)-Based Architecture", RFC 4655, 433 DOI 10.17487/RFC4655, August 2006, 434 . 436 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 437 Architecture for Use of PCE and the PCE Communication 438 Protocol (PCEP) in a Network with Central Control", 439 RFC 8283, DOI 10.17487/RFC8283, December 2017, 440 . 442 [I-D.ietf-spring-segment-routing-policy] 443 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 444 bogdanov@google.com, b., and P. Mattes, "Segment Routing 445 Policy Architecture", draft-ietf-spring-segment-routing- 446 policy-01 (work in progress), June 2018. 448 [I-D.ietf-idr-bgp-prefix-sid] 449 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 450 and H. Gredler, "Segment Routing Prefix SID extensions for 451 BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), 452 June 2018. 454 [I-D.li-pce-sr-path-segment] 455 Li, C., Chen, M., Dhody, D., Cheng, W., Dong, J., Li, Z., 456 and R. Gandhi, "Path Computation Element Communication 457 Protocol (PCEP) Extension for Path Identification in 458 Segment Routing (SR)", draft-li-pce-sr-path-segment-02 459 (work in progress), September 2018. 461 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 462 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 463 and C. Zhou, "PCEP Procedures and Protocol Extensions for 464 Using PCE as a Central Controller (PCECC) of SR-LSPs", 465 draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work 466 in progress), June 2018. 468 Appendix A. PCE based Central Controller 470 [RFC8283] introduces the architecture for PCE as a central controller 471 as an extension of the architecture described in [RFC4655] and 472 assumes the continued use of PCEP as the protocol used between PCE 473 and PCC. [RFC8283] further examines the motivations and 474 applicability for PCEP as a Southbound Interface (SBI), and 475 introduces the implications for the protocol. 477 As per [RFC8283], PCE as a central controller can allocate and 478 provision the node/prefix/adjacency label (SID) via PCEP. It can 479 also be used to allocate the binding SID as described in this 480 section. 482 The PCECC Capability as per 483 [I-D.zhao-pce-pcep-extension-pce-controller-sr] should also be 484 advertised on the PCEP session, along with the SR sub-TLVs before 485 using this procedure. 487 A P flag in LSP object is introduced in [I-D.li-pce-sr-path-segment] 488 to indicate the allocation needs to be made by the PCE. The same 489 flag is also set for the binding SID allocation request. A PCC would 490 set this bit to 1 to request for allocation of the binding label/SID 491 by the PCE in the PCReq or PCRpt message. A PCE would also set this 492 bit to 1 to indicate that the binding label/SID is allocated by PCE 493 and encoded in the PCRep, PCUpd or PCInitiate message (the TE-PATH- 494 BINDING TLV is present in LSP object). Further, a PCE would set this 495 bit to 0 to indicate that the path identifier is allocated by the PCC 496 as described above. 498 The ingress PCC could request the binding label/SID to be allocated 499 by the PCE via PCRpt message as per [RFC8231]. The delegate flag 500 (D-flag) MUST also be set for this LSP. The TE-PATH-BINDING TLV MAY 501 be included with no Binding Value. The PCECC would allocated the 502 binding label/SID and further respond to Ingress PCC with PCUpd 503 message as per [RFC8231] and MUST include the TE-PATH-BINDING TLV in 504 a LSP object. The P flag in the LSP object would be set to 1 to 505 indicate that the allocation is made by the PCE. 507 The PCE could allocate the binding label/SID on its own accord for a 508 PCE- Initiated (or delegated LSP). The allocated binding label/SID 509 needs to be informed to the PCC. The PCE would use the PCInitiate 510 message [RFC8281] or PCUpd message [RFC8231] towards the PCC and MUST 511 include the TE-PATH-BINDING TLV in the LSP object. The P flag in the 512 LSP object would be set to 1 to indicate that the allocation is made 513 by the PCE. 515 Authors' Addresses 517 Siva Sivabalan 518 Cisco Systems, Inc. 519 2000 Innovation Drive 520 Kanata, Ontario K2K 3E8 521 Canada 523 EMail: msiva@cisco.com 525 Clarence Filsfils 526 Cisco Systems, Inc. 527 Pegasus Parc 528 De kleetlaan 6a, DIEGEM BRABANT 1831 529 BELGIUM 531 EMail: cfilsfil@cisco.com 533 Jeff Tantsura 534 Apstra, Inc. 536 EMail: jefftant.ietf@gmail.com 538 Jonathan Hardwick 539 Metaswitch Networks 540 100 Church Street 541 Enfield, Middlesex 542 UK 544 EMail: Jonathan.Hardwick@metaswitch.com 546 Stefano Previdi 547 Huawei Technologies 549 EMail: stefano@previdi.net 551 Dhruv Dhody 552 Huawei Technologies 553 Divyashree Techno Park, Whitefield 554 Bangalore, Karnataka 560066 555 India 557 EMail: dhruv.ietf@gmail.com