idnits 2.17.1 draft-zhao-pce-pcep-extension-pce-controller-sr-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2017) is 2373 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-01 == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-04 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-05 == Outdated reference: A later version (-08) exists of draft-zhao-pce-pcep-extension-for-pce-controller-05 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-10 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-13 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-21 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-02 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-08 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-10 == Outdated reference: A later version (-03) exists of draft-palle-pce-controller-labeldb-sync-01 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft Z. Li 4 Intended status: Standards Track D. Dhody 5 Expires: April 29, 2018 S. Karunanithi 6 Huawei Technologies 7 A. Farrel 8 Juniper Networks, Inc 9 C. Zhou 10 Cisco Systems 11 October 26, 2017 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of SR-LSPs 15 draft-zhao-pce-pcep-extension-pce-controller-sr-01 17 Abstract 19 In certain networks deployment scenarios, service providers would 20 like to keep all the existing MPLS functionalities in both MPLS and 21 GMPLS while removing the complexity of existing signaling protocols 22 such as LDP and RSVP-TE. PCE has been proposed to be used as a 23 central controller (PCECC) so that LSP can be calculated/setup/ 24 initiated and label forwarding entries are downloaded through a 25 centralized PCE server to each network devices along the path while 26 leveraging the existing PCE technologies as much as possible. 28 This document specifies the procedures and PCEP protocol extensions 29 when the PCE functions as one of the central controller components in 30 Segment Routing(SR). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 29, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. PCECC SR . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Procedures for Using the PCE as the Central Controller 72 (PCECC) in Segment Routing . . . . . . . . . . . . . . . . . 6 73 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 74 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 75 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 6 76 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 7 77 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 7 78 5.5.1. PCECC Segment Routing (SR) . . . . . . . . . . . . . 7 79 5.5.1.1. PCECC SR Node/Prefix Label allocation . . . . . . 8 80 5.5.1.2. PCECC SR Adjacency Label allocation . . . . . . . 9 81 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 10 82 5.5.1.4. Session Termination . . . . . . . . . . . . . . . 10 83 5.5.1.5. LABEL-DB Synchronization . . . . . . . . . . . . 10 84 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 11 85 6.1. Label Operations . . . . . . . . . . . . . . . . . . . . 11 86 6.1.1. The PCLabelUpd message . . . . . . . . . . . . . . . 11 87 6.1.2. The PCLabelRpt message . . . . . . . . . . . . . . . 12 88 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 12 89 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 12 90 7.1.1. PCECC Capability TLV . . . . . . . . . . . . . . . . 12 91 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 13 92 7.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 13 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 94 9. Manageability Considerations . . . . . . . . . . . . . . . . 15 95 9.1. Control of Function and Policy . . . . . . . . . . . . . 15 96 9.2. Information and Data Models . . . . . . . . . . . . . . . 15 97 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 15 98 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 16 99 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 16 100 9.6. Impact On Network Operations . . . . . . . . . . . . . . 16 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 102 10.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 16 103 10.2. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 16 104 10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 16 105 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 108 12.2. Informative References . . . . . . . . . . . . . . . . . 18 109 Appendix A. Using existing PCEP message . . . . . . . . . . . . 21 110 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 22 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 113 1. Introduction 115 The Path Computation Element communication Protocol (PCEP) provides 116 mechanisms for Path Computation Elements (PCEs) to perform route 117 computations in response to Path Computation Clients (PCCs) requests. 118 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 119 [RFC8231] describes a set of extensions to PCEP to enable active 120 control of MPLS-TE and GMPLS tunnels. 122 [I-D.ietf-pce-pce-initiated-lsp] describes the setup and tear down of 123 PCE-initiated LSPs under the active stateful PCE model, without the 124 need for local configuration on the PCC, thus allowing for a dynamic 125 MPLS network that is centrally controlled and deployed. 127 [I-D.ietf-teas-pce-central-control] introduces the architecture for 128 PCE as a central controller, examines the motivations and 129 applicability for PCEP as a southbound interface, and introduces the 130 implications for the protocol. [I-D.ietf-teas-pcecc-use-cases] 131 describes the use cases for the PCECC architecture. 133 [I-D.zhao-pce-pcep-extension-for-pce-controller] specify the PCEP 134 extension for the PCE as the central controller (PCECC). This 135 document extends the PCECC procedures for Segment Routing (SR). 137 Segment Routing (SR) technology leverage the source routing and 138 tunneling paradigms. A source node can choose a path without relying 139 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 140 is specified as a set of "segments" advertised by link- state routing 141 protocols (IS-IS or OSPF). 143 [I-D.ietf-spring-segment-routing] provides an introduction to SR 144 technology. The corresponding IS-IS and OSPF extensions are 145 specified in [I-D.ietf-isis-segment-routing-extensions] and 146 [I-D.ietf-ospf-segment-routing-extensions] , respectively. 148 A Segment Routed path (SR path) can be derived from an IGP Shortest 149 Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE 150 paths) may not follow IGP SPT. Such paths may be chosen by a 151 suitable network planning tool and provisioned on the source node of 152 the SR-TE path. 154 It is possible to use a stateful PCE for computing one or more SR-TE 155 paths taking into account various constraints and objective 156 functions. Once a path is chosen, the stateful PCE can instantiate 157 an SR-TE path on a PCC using PCEP extensions specified in 158 [I-D.ietf-pce-pce-initiated-lsp] using the SR specific PCEP 159 extensions described in [I-D.ietf-pce-segment-routing]. 161 PCECC may further use PCEP protocol for SR label distribution instead 162 of IGP extensions with some benefits. 164 The [I-D.zhao-pce-pcep-extension-for-pce-controller], specifies the 165 procedures and PCEP protocol extensions for using the PCE as one of 166 the the central controller components and user cases where LSPs are 167 calculated/setup/initiated and label forwarding entries are 168 downloaded on each hop along the path, through extending the existing 169 PCE architectures and PCEP. 171 This draft specify the procedures and PCEP protocol extensions for 172 using the PCE as the central controller for SR label distribution and 173 user cases where SR LSPs are calculated/setup/initiated/downloaded 174 through extending the existing PCE architectures and PCEP. 176 1.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 2. Terminology 186 Terminologies used in this document is same as described in the draft 187 [I-D.ietf-teas-pcecc-use-cases]. 189 3. PCECC SR 191 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 192 allow a stateful PCE to compute, update or initiate SR-TE paths. An 193 ingress node of an SR-TE path appends all outgoing packets with a 194 list of MPLS labels (SIDs). This is encoded in SR-ERO subobject, 195 capable of carrying a label (SID) as well as the identity of the 196 node/adjacency label (SID). 198 The notion of segment and SID is defined in 199 [I-D.ietf-spring-segment-routing], which fits the MPLS architecture 200 [RFC3031] as the label which is managed by a local allocation process 201 of LSR (similarly to other MPLS signaling protocols) 202 [I-D.ietf-spring-segment-routing-mpls]. The SR information such as 203 node/adjacency label (SID) is flooded via IGP as specified in 204 [I-D.ietf-isis-segment-routing-extensions] and 205 [I-D.ietf-ospf-segment-routing-extensions]. 207 As per [I-D.ietf-teas-pce-central-control], PCE as a central 208 controller can allocate and provision the node/adjacency label (SID) 209 via PCEP. 211 Rest of the processing is similar to existing stateful PCE with SR 212 mechanism. 214 For the purpose of this document, it is assumed that label range to 215 be used by a PCE is set on both PCEP peers. Further, a global label 216 range is assumed to be set on all PCEP peers in the SR domain. 218 4. PCEP Requirements 220 Following key requirements for PCECC-SR should be considered when` 221 designing the PCECC based solution: 223 o PCEP speaker supporting this draft MUST have the capability to 224 advertise its PCECC-SR capability to its peers. 226 o PCEP speaker not supporting this draft MUST be able to reject 227 PCECC-SR related message with a reason code that indicates no 228 support for PCECC. 230 o PCEP SHOULD provide a means to update (or cleanup) the label- map 231 entry to the PCC. 233 o PCEP SHOULD provide a means to synchronize the SR labels between 234 PCE to PCC in PCEP messages. 236 5. Procedures for Using the PCE as the Central Controller (PCECC) in 237 Segment Routing 239 5.1. Stateful PCE Model 241 Active stateful PCE is described in [RFC8231]. PCE as a central 242 controller (PCECC) reuses existing Active stateful PCE mechanism as 243 much as possible to control the LSP. 245 5.2. New LSP Functions 247 This document uses the same PCEP messages and its extenstions which 248 are described in [I-D.zhao-pce-pcep-extension-for-pce-controller] for 249 PCECC-SR as well. 251 PCEP messages PCRpt, PCInitiate, PCUpd are also used to send PCECC-SR 252 Reports, LSP setup and LSP update respectively. 254 PCLabelUpd message described in 255 [I-D.zhao-pce-pcep-extension-for-pce-controller] is used to download 256 or cleanup SR Label entry. 258 PCLabelRpt message described in 259 [I-D.zhao-pce-pcep-extension-for-pce-controller] is also used to 260 report the set of SR Label entries from PCC to PCE for which explicit 261 action is required from PCE (update or cleanup or do nothing for 262 these Label entries). 264 [Editor's Note: [I-D.zhao-pce-pcep-extension-for-pce-controller] 265 defines new messages PCLabelUpd and PCLabelRpt. Questions where 266 raised on the need for the new messages. Further the document also 267 includes an appendix on how the existing messages can be extended to 268 add this functionality. WG needs to decide the final direction i.e. 269 new specific messages are needed or existing PCEP messages can be 270 extended. See See Appendix A to see the extension of existing 271 message for PCECC-SR functionality.] 273 5.3. PCECC Capability Advertisement 275 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 276 advertise their support of PCECC extensions. A PCEP Speaker includes 277 the "PCECC Capability" TLV, described in 278 [I-D.zhao-pce-pcep-extension-for-pce-controller]. 280 A new S-bit is added in PCECC-CAPABILITY TLV to indicate support for 281 PCECC-SR. A PCC MUST set S-bit in PCECC-CAPABILITY TLV and include 282 SR-PCE-CAPABILITY TLV ([I-D.ietf-pce-segment-routing]) in OPEN Object 283 to support the PCECC SR extensions defined in this document. If 284 S-bit is set in PCECC-CAPABILITY TLV and SR-PCE-CAPABILITY TLV is not 285 advertised in OPEN Object, PCE SHOULD send a PCErr message with 286 Error-Type=19 (Invalid Operation) and Error-value=TBD(SR capability 287 was not advertised) and terminate the session. 289 5.4. PCEP session IP address and TEDB Router ID 291 PCE may construct its TEDB by participating in the IGP ([RFC3630] and 292 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 293 alternative is offered by BGP-LS [RFC7752] and 294 [I-D.dhodylee-pce-pcep-ls]. 296 PCEP [RFC5440] speaker MAY use any IP address while creating a TCP 297 session. It is important to link the session IP address with the 298 Router ID in TEDB for successful PCECC operations. 300 During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping 301 information. Thus a PCC includes the "Node Attributes TLV" 302 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 303 in the OPEN Object for this purpose. [RFC7752] describes the usage 304 as auxiliary Router-IDs that the IGP might be using, e.g., for TE 305 purposes. If there are more than one auxiliary Router-ID of a given 306 type, then multiple TLVs are used to encode them. 308 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 309 address is directly used for the mapping purpose. 311 5.5. LSP Operations 313 The PCEP messages pertaining to PCECC-SR MUST include PATH-SETUP-TYPE 314 TLV [I-D.ietf-pce-lsp-setup-type] in the SRP object to clearly 315 identify the PCECC-SR LSP is intended. 317 5.5.1. PCECC Segment Routing (SR) 319 Segment Routing (SR) as described in 320 [I-D.ietf-spring-segment-routing] depends on "segments" that are 321 advertised by Interior Gateway Protocols (IGPs). The SR-node 322 allocates and advertises the SID (node, adj etc) and flood via the 323 IGP. This document proposes a new mechanism where PCE allocates the 324 SID (label) centrally and uses PCEP to advertise the SID. In some 325 deployments PCE (and PCEP) are better suited than IGP because of 326 centralized nature of PCE and direct TCP based PCEP session to the 327 node. 329 5.5.1.1. PCECC SR Node/Prefix Label allocation 331 Each node (PCC) is allocated a node-SID (label) by the PCECC. The 332 PCECC sends PCLabelUpd to update the label map of each node to all 333 the nodes in the domain. The TE router ID is determined from the 334 TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV 335 [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. 337 It is RECOMMENDED that PCEP session with PCECC SR capability to use a 338 different session IP address during TCP session establishment than 339 the node Router ID in TEDB, to make sure that the PCEP session does 340 not get impacted by the SR Node/Prefix Label maps (Section 5.4). 342 If a node (PCC) receives a PCLabelUpd message with a Label, out of 343 the range set aside for the global label, it MUST send a PCErr 344 message with Error-type=TBD (label download failure) and Error- 345 value=TBD (Label out of range) and MUST include the SRP object to 346 specify the error is for the corresponding label update 347 [I-D.zhao-pce-pcep-extension-for-pce-controller]. 349 On receiving the label map, each node (PCC) uses the local 350 information to determine the next-hop and download the label 351 forwarding instructions accordingly. The PCLabelUpd message in this 352 case MUST NOT have LSP object but uses new FEC object. 354 +---------+ +-------+ 355 |PCC | | PCE | 356 |192.0.2.3| +-------+ 357 +------| | | 358 | PCC +---------+ | 359 | 192.0.2.2| | | 360 +------| | | | 361 |PCC +----------+ | | 362 |192.0.2.1| | | | 363 +---------+ | | | 364 | | | | 365 |<------- PCLabelUpd, FEC=192.0.2.1---------------- | Label Map 366 | | | Label=X | update 367 |Find | | | 368 |Nexthop|<------- PCLabelUpd, FEC=192.0.2.1-------- | Label Map 369 |locally| | Label=X | update 370 | | | | 371 | | |<--- PCLabelUpd, FEC=192.0.2.1---- | Label Map 372 | | | Label=X | update 373 | | | | 375 The forwarding behaviour and the end result is similar to IGP based 376 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 377 ECMP-aware shortest-path forwarding of the packet towards the related 378 node. 380 PCE relies on the Node/Prefix Label cleanup using the same PCLabelUpd 381 message. 383 5.5.1.2. PCECC SR Adjacency Label allocation 385 [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE 386 to compute and initiate SR-TE paths, as well as a PCC to request a 387 path subject to certain constraint(s) and optimization criteria in SR 388 networks. 390 For PCECC SR, apart from node-SID, Adj-SID is used where each 391 adjacency is allocated an Adj-SID (label) by the PCECC. The PCECC 392 sends PCLabelUpd to update the label map of each Adj to the 393 corresponding nodes in the domain. Each node (PCC) download the 394 label forwarding instructions accordingly. Similar to SR Node/Prefix 395 Label allocation, the PCLabelUpd message in this case MUST NOT have 396 LSP object but uses new FEC object. 398 +---------+ +-------+ 399 |PCC | | PCE | 400 |192.0.2.3| +-------+ 401 +------| | | 402 | PCC +---------+ | 403 | 192.0.2.2| | | 404 +------| | | | 405 |PCC +----------+ | | 406 |192.0.2.1| | | | 407 +---------+ | | | 408 | | | | 409 |<------ PCLabelUpd, FEC=192.0.2.1 / ------------ | Label Map 410 | | | 192.0.2.2 | update 411 | | | Label=A | 412 | | | | 413 | |<----- PCLabelUpd, FEC=192.0.2.2------- | Label Map 414 | | | 192.0.2.1 | update 415 | | | Label=B | 416 | | | | 418 The forwarding behavior and the end result is similar to IGP based 419 "Adj-SID" in SR. 421 The Path Setup Type for segment routing MUST be set for PCECC SR (see 422 Section 7.2). All PCEP procedures and mechanism are similar to 423 [I-D.ietf-pce-segment-routing]. 425 PCE relies on the Adj label cleanup using the same PCLabelUpd 426 message. 428 5.5.1.3. Redundant PCEs 430 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 431 between the stateful PCEs. The SR Labels allocated by a PCE should 432 also be synchronized among PCEs for PCECC SR state synchronization. 433 Note that the SR labels are downloaded independent to the PCECC LSP, 434 and remains intact till any topology change. The redundant PCEs MUST 435 have a common view of all SR labels allocated in the domain. 437 Incase the session to the PCE that allocated the SR labels is down, 438 similar to the LSP re-delegation mechanims, the SR labels are re- 439 delegated to a redundant PCE using the PCLabelRpt message. This is 440 done so that the SR labels remains intact and cosntant in case of 441 session disconnect. 443 5.5.1.4. Session Termination 445 [I-D.zhao-pce-pcep-extension-for-pce-controller] describes the action 446 needed for label provisioned for the Basic PCECC LSP on this 447 terminated session. Similarly actions should be applied for SR 448 Labels as well. 450 Additionally, if PCC has any alternate PCEP session with another PCE, 451 then PCC MUST deligate the SR labels of this session to this 452 alternate PCE in a sequence of PCLabelRpt message. PCE can accept it 453 and can send PCLabelUpd message to update or clean the label. 455 Extensions for PCLabelUpd and PCLabelRpt message for SR label are 456 described in Section 6.1. 458 5.5.1.5. LABEL-DB Synchronization 460 [I-D.zhao-pce-pcep-extension-for-pce-controller] describes LABEL-DB 461 Synchronization procedures needed for the labels provisioned for the 462 Basic PCECC LSP. Same procedures should be applied for SR labels as 463 well. 465 See [I-D.palle-pce-controller-labeldb-sync] for the optimizations for 466 LABEL-DB synchronization procedure. 468 6. PCEP messages 470 As defined in [RFC5440], a PCEP message consists of a common header 471 followed by a variable-length body made of a set of objects that can 472 be either mandatory or optional. An object is said to be mandatory 473 in a PCEP message when the object must be included for the message to 474 be considered valid. For each PCEP message type, a set of rules is 475 defined that specify the set of objects that the message can carry. 476 An implementation MUST form the PCEP messages using the object 477 ordering specified in this document. 479 6.1. Label Operations 481 [Editor's Note: [I-D.zhao-pce-pcep-extension-for-pce-controller] 482 defines new messages PCLabelUpd and PCLabelRpt. Questions where 483 raised on the need for the new messages. Further the document also 484 includes an appendix on how the existing messages can be extended to 485 add this functionality. WG needs to decide the final direction i.e. 486 new specific messages are needed or existing PCEP messages can be 487 extended. See See Appendix A to see the extension of existing 488 message for PCECC-SR functionality.] 490 6.1.1. The PCLabelUpd message 492 Label Update Message (PCLabelUpd) defined in 493 [I-D.zhao-pce-pcep-extension-for-pce-controller] is extended to 494 update the label map at the PCC. 496 The format of the extended PCLabelUpd message is as follows: 498 ::= 499 500 Where: 501 ::= 502 [] 504 ::= (|) 506 Where: 508 ::= 509