idnits 2.17.1 draft-zhao-pce-pcep-extension-pce-controller-sr-04.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 (February 5, 2019) is 1906 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-02 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-00 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-14 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-22 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-04 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-12 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-18 == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-05 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). 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 M. Negi 5 Expires: August 9, 2019 Huawei Technologies 6 C. Zhou 7 Cisco Systems 8 February 5, 2019 10 PCEP Procedures and Protocol Extensions for Using PCE as a Central 11 Controller (PCECC) of SR-LSPs 12 draft-zhao-pce-pcep-extension-pce-controller-sr-04 14 Abstract 16 The Path Computation Element (PCE) is a core component of Software- 17 Defined Networking (SDN) systems. It can compute optimal paths for 18 traffic across a network and can also update the paths to reflect 19 changes in the network or traffic demands. 21 PCE was developed to derive paths for MPLS Label Switched Paths 22 (LSPs), which are supplied to the head end of the LSP using the Path 23 Computation Element Communication Protocol (PCEP). But SDN has a 24 broader applicability than signaled (G)MPLS traffic-engineered (TE) 25 networks, and the PCE may be used to determine paths in a range of 26 use cases. PCEP has been proposed as a control protocol for use in 27 these environments to allow the PCE to be fully enabled as a central 28 controller. 30 A PCE-based central controller (PCECC) can simplify the processing of 31 a distributed control plane by blending it with elements of SDN and 32 without necessarily completely replacing it. Thus, the LSP can be 33 calculated/setup/initiated and the label forwarding entries can also 34 be downloaded through a centralized PCE server to each network 35 devices along the path while leveraging the existing PCE technologies 36 as much as possible. 38 This document specifies the procedures and PCEP protocol extensions 39 when a PCE-based controller is also responsible for configuring the 40 forwarding actions on the routers, in addition to computing the paths 41 for packet flows in a segment routing network and telling the edge 42 routers what instructions to attach to packets as they enter the 43 network. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on August 9, 2019. 62 Copyright Notice 64 Copyright (c) 2019 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 81 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 3. PCECC SR . . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 84 5. Procedures for Using the PCE as the Central Controller 85 (PCECC) in Segment Routing . . . . . . . . . . . . . . . . . 6 86 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 87 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 88 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 89 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 7 90 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 91 5.5.1. PCECC Segment Routing (SR) . . . . . . . . . . . . . 8 92 5.5.1.1. PCECC SR Node/Prefix SID allocation . . . . . . . 8 93 5.5.1.2. PCECC SR Adjacency Label allocation . . . . . . . 10 94 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 12 95 5.5.1.4. Re Delegation and Cleanup . . . . . . . . . . . . 12 96 5.5.1.5. Synchronization of Label Allocations . . . . . . 13 97 5.5.1.6. PCC Based Allocations . . . . . . . . . . . . . . 13 98 5.5.1.7. Binding SID . . . . . . . . . . . . . . . . . . . 13 99 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 14 100 6.1. Central Control Instructions . . . . . . . . . . . . . . 14 101 6.1.1. The PCInitiate message . . . . . . . . . . . . . . . 14 102 6.1.2. The PCRpt message . . . . . . . . . . . . . . . . . . 15 103 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 16 104 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 16 105 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 16 106 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 17 107 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 17 108 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 19 109 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 110 9. Manageability Considerations . . . . . . . . . . . . . . . . 21 111 9.1. Control of Function and Policy . . . . . . . . . . . . . 21 112 9.2. Information and Data Models . . . . . . . . . . . . . . . 21 113 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 114 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 21 115 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 21 116 9.6. Impact On Network Operations . . . . . . . . . . . . . . 21 117 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 118 10.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 21 119 10.2. New Path Setup Type Registry . . . . . . . . . . . . . . 22 120 10.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 22 121 10.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 22 122 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 123 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 124 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 125 12.2. Informative References . . . . . . . . . . . . . . . . . 24 126 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 27 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 129 1. Introduction 131 The Path Computation Element (PCE) [RFC4655] was developed to offload 132 path computation function from routers in an MPLS traffic-engineered 133 network. Since then, the role and function of the PCE has grown to 134 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 135 delegated control [RFC8231] and PCE-initiated use of network 136 resources [RFC8281]. 138 According to [RFC7399], Software-Defined Networking (SDN) refers to a 139 separation between the control elements and the forwarding components 140 so that software running in a centralized system, called a 141 controller, can act to program the devices in the network to behave 142 in specific ways. A required element in an SDN architecture is a 143 component that plans how the network resources will be used and how 144 the devices will be programmed. It is possible to view this 145 component as performing specific computations to place traffic flows 146 within the network given knowledge of the availability of network 147 resources, how other forwarding devices are programmed, and the way 148 that other flows are routed. This is the function and purpose of a 149 PCE, and the way that a PCE integrates into a wider network control 150 system (including an SDN system) is presented in [RFC7491]. 152 In early PCE implementations, where the PCE was used to derive paths 153 for MPLS Label Switched Paths (LSPs), paths were requested by network 154 elements (known as Path Computation Clients (PCCs)), and the results 155 of the path computations were supplied to network elements using the 156 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 157 This protocol was later extended to allow a PCE to send unsolicited 158 requests to the network for LSP establishment [RFC8281]. 160 [RFC8283] introduces the architecture for PCE as a central controller 161 as an extension of the architecture described in [RFC4655] and 162 assumes the continued use of PCEP as the protocol used between PCE 163 and PCC. [RFC8283] further examines the motivations and 164 applicability for PCEP as a Southbound Interface (SBI), and 165 introduces the implications for the protocol. 166 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 167 architecture. 169 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 170 procedures and PCEP protocol extensions for using the PCE as the 171 central controller for static LSPs, where LSPs can be provisioned as 172 explicit label instructions at each hop on the end-to-end path. 174 Segment Routing (SR) technology leverages the source routing and 175 tunneling paradigms. A source node can choose a path without relying 176 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 177 is specified as a set of "segments" advertised by link-state routing 178 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to SR 179 architecture. The corresponding IS-IS and OSPF extensions are 180 specified in [I-D.ietf-isis-segment-routing-extensions] and 181 [I-D.ietf-ospf-segment-routing-extensions] , respectively. It relies 182 on a series of forwarding instructions being placed in the header of 183 a packet. The segment routing architecture supports operations that 184 can be used to steer packet flows in a network, thus providing a form 185 of traffic engineering. [I-D.ietf-pce-segment-routing] specify the 186 SR specific PCEP extensions. 188 PCECC may further use PCEP protocol for SR SID (Segment Identifier) 189 distribution on the SR nodes with some benefits. 191 This document specifies the procedures and PCEP protocol extensions 192 when a PCE-based controller is also responsible for configuring the 193 forwarding actions on the routers (SR SID distribution in this case), 194 in addition to computing the paths for packet flows in a segment 195 routing network and telling the edge routers what instructions to 196 attach to packets as they enter the network. 198 1.1. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in BCP 203 14 [RFC2119] [RFC8174] when, and only when, they appear in all 204 capitals, as shown here. 206 2. Terminology 208 Terminologies used in this document is same as described in the draft 209 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 211 3. PCECC SR 213 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 214 allow a stateful PCE to compute, update or initiate SR-TE paths. An 215 ingress node of an SR-TE path appends all outgoing packets with a 216 list of MPLS labels (SIDs). This is encoded in SR-ERO subobject, 217 capable of carrying a label (SID) as well as the identity of the 218 node/adjacency label (SID). 220 The notion of segment and SID is defined in [RFC8402], which fits the 221 MPLS architecture [RFC3031] as the label which is managed by a local 222 allocation process of LSR (similarly to other MPLS signaling 223 protocols) [I-D.ietf-spring-segment-routing-mpls]. The SR 224 information such as node/adjacency label (SID) is flooded via IGP as 225 specified in [I-D.ietf-isis-segment-routing-extensions] and 226 [I-D.ietf-ospf-segment-routing-extensions]. 228 As per [RFC8283], PCE as a central controller can allocate and 229 provision the node/prefix/adjacency label (SID) via PCEP. 231 Rest of the processing is similar to existing stateful PCE with SR 232 mechanism. 234 For the purpose of this document, it is assumed that label range to 235 be used by a PCE is set on both PCEP peers. Further, a global label 236 range is assumed to be set on all PCEP peers in the SR domain. This 237 document also allow a case where the label space is maintained by PCC 238 itself, and the labels are allocated by the PCC, in this case, the 239 PCE should request the allocation from PCC as described in 240 Section 5.5.1.6. 242 4. PCEP Requirements 244 Following key requirements for PCECC-SR should be considered when` 245 designing the PCECC based solution: 247 o PCEP speaker supporting this draft MUST have the capability to 248 advertise its PCECC-SR capability to its peers. 250 o PCEP speaker not supporting this draft MUST be able to reject 251 PCECC-SR related message with a reason code that indicates no 252 support for PCECC. 254 o PCEP procedures MUST provide a means to update (or cleanup) the 255 label- map entry to the PCC. 257 o PCEP procedures SHOULD provide a means to synchronize the SR 258 labels allocations between PCE to PCC in the PCEP messages. 260 5. Procedures for Using the PCE as the Central Controller (PCECC) in 261 Segment Routing 263 5.1. Stateful PCE Model 265 Active stateful PCE is described in [RFC8231]. PCE as a central 266 controller (PCECC) reuses existing Active stateful PCE mechanism as 267 much as possible to control the LSP. 269 5.2. New LSP Functions 271 This document uses the same PCEP messages and its extensions which 272 are described in [I-D.ietf-pce-pcep-extension-for-pce-controller] for 273 PCECC-SR as well. 275 PCEP messages PCRpt, PCInitiate, PCUpd are also used to send LSP 276 Reports, LSP setup and LSP update respectively. The extended 277 PCInitiate message described in 278 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 279 or cleanup central controller's instructions (CCIs) (SR SID in scope 280 of this document). The extended PCRpt message described in 281 [I-D.ietf-pce-pcep-extension-for-pce-controller] is also used to 282 report the CCIs (SR SIDs) from PCC to PCE. 284 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 285 called CCI for the encoding of central controller's instructions. 286 This document extends the CCI by defining a new object-type for 287 segment routing. The PCEP messages are extended in this document to 288 handle the PCECC operations for SR. 290 5.3. PCECC Capability Advertisement 292 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 293 advertise their support of PCECC extensions. A PCEP Speaker includes 294 the "PCECC Capability" sub-TLV, described in 295 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 297 A new S-bit is added in PCECC-CAPABILITY sub-TLV to indicate support 298 for PCECC-SR. A PCC MUST set S-bit in PCECC-CAPABILITY sub-TLV and 299 include SR-PCE-CAPABILITY sub-TLV ([I-D.ietf-pce-segment-routing]) in 300 OPEN Object (inside the the PATH-SETUP-TYPE-CAPABILITY TLV) to 301 support the PCECC SR extensions defined in this document. If S-bit 302 is set in PCECC-CAPABILITY sub-TLV and SR-PCE-CAPABILITY sub-TLV is 303 not advertised in OPEN Object, PCE SHOULD send a PCErr message with 304 Error-Type=19 (Invalid Operation) and Error-value=TBD(SR capability 305 was not advertised) and terminate the session. 307 5.4. PCEP session IP address and TEDB Router ID 309 PCE may construct its TEDB by participating in the IGP ([RFC3630] and 310 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 311 alternative is offered by BGP-LS [RFC7752] and 312 [I-D.dhodylee-pce-pcep-ls]. 314 PCEP [RFC5440] speaker MAY use any IP address while creating a TCP 315 session. It is important to link the session IP address with the 316 Router ID in TEDB for successful PCECC operations. 318 During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping 319 information. Thus a PCC includes the "Node Attributes TLV" 320 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 321 in the OPEN Object for this purpose. [RFC7752] describes the usage 322 as auxiliary Router-IDs that the IGP might be using, e.g., for TE 323 purposes. If there are more than one auxiliary Router-ID of a given 324 type, then multiple TLVs are used to encode them. 326 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 327 address is directly used for the mapping purpose. 329 5.5. LSP Operations 331 The PCEP messages pertaining to PCECC-SR MUST include PATH-SETUP-TYPE 332 TLV [RFC8408] with PST=TBD in the SRP object to clearly identify the 333 PCECC-SR LSP is intended. 335 5.5.1. PCECC Segment Routing (SR) 337 Segment Routing (SR) as described in [RFC8402] depends on "segments" 338 that are advertised by Interior Gateway Protocols (IGPs). The SR- 339 node allocates and advertises the SID (node, adj etc) and flood via 340 the IGP. This document proposes a new mechanism where PCE allocates 341 the SID (label/index/SID) centrally and uses PCEP to advertise the 342 SID. In some deployments PCE (and PCEP) are better suited than IGP 343 because of centralized nature of PCE and direct TCP based PCEP 344 session to the node. 346 5.5.1.1. PCECC SR Node/Prefix SID allocation 348 Each node (PCC) is allocated a node-SID by the PCECC. The PCECC 349 sends PCInitiate message to update the label map of each node to all 350 the nodes in the domain. The TE router ID is determined from the 351 TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV 352 [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. 354 It is RECOMMENDED that PCEP session with PCECC SR capability to use a 355 different session IP address during TCP session establishment than 356 the node Router ID in TEDB, to make sure that the PCEP session does 357 not get impacted by the SR Node/Prefix Label maps (Section 5.4). 359 If a node (PCC) receives a PCInitiate message with a CCI encoding a 360 SID, out of the range set aside for the SRGB, it MUST send a PCErr 361 message with Error-type=TBD (PCECC failure) and Error-value=TBD (SID 362 out of range) and MUST include the SRP object to specify the error is 363 for the corresponding label update via PCInitiate message. 365 On receiving the label map, each node (PCC) uses the local 366 information to determine the next-hop and download the label 367 forwarding instructions accordingly. The PCInitiate message in this 368 case MUST NOT have LSP object but uses the new FEC object defined in 369 this document. 371 +---------+ +-------+ 372 |PCC | | PCE | 373 |192.0.2.3| +-------+ 374 +------| | | 375 | PCC +---------+ | 376 | 192.0.2.2| | | 377 +------| | | | 378 |PCC +----------+ | | 379 |192.0.2.1| | | | 380 +---------+ | | | 381 | | | | 382 |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map 383 | | | CC-ID=X | update 384 |------- PCRpt,CC-ID=X --------------------------->| 385 |Find | | | 386 |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map 387 |locally| | CC-ID=Y | update 388 | |----- PCRpt,CC-ID=Y -------------------->| 389 | | | | 390 | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map 391 | | | CC-ID=Z | update 392 | | |---- PCRpt,CC-ID=Z -------------->| 393 | | | | 395 The forwarding behavior and the end result is similar to IGP based 396 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 397 ECMP-aware shortest-path forwarding of the packet towards the related 398 node. 400 PCE relies on the Node/Prefix Label cleanup using the same PCInitiate 401 message. 403 The above example Figure 1 depict FEC and PCEP speakers that uses 404 IPv4 address. Similarly IPv6 address (such as 2001:DB8::1) can be 405 used during PCEP session establishment as well in FEC object as 406 described in this specification. 408 In case where the label allocation are made by the PCC itself (see 409 Section 5.5.1.6), the PCE could still request an allocation to be 410 made by the PCC, and where the PCC would send a PCRpt with the 411 allocated label encoded in the CC-ID object as shown below - 412 +---------+ +-------+ 413 |PCC | | PCE | 414 |192.0.2.3| +-------+ 415 +------| | | 416 | PCC +---------+ | 417 | 192.0.2.2| | | 418 +------| | | | 419 |PCC +----------+ | | 420 |192.0.2.1| | | | 421 +---------+ | | | 422 | | | | 423 |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map 424 | | | CC-ID=X,C=1 | request 425 |------- PCRpt,CC-ID=X,Label ---------------------->| 426 |Find | | | 427 |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map 428 |locally| | CC-ID=Y,C=0,Label | update 429 | |----- PCRpt,CC-ID=Y -------------------->| 430 | | | | 431 | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map 432 | | | CC-ID=Z,C=0,Label | update 433 | | |---- PCRpt,CC-ID=Z -------------->| 434 | | | | 436 It should be noted that in this example, the request is made to the 437 node 192.0.2.1 with C bit set in the CCI object to indicate that the 438 allocation needs to be done by this PCC and it responds with the 439 allocated label/SID to the PCE. The PCE would further inform the 440 other PCCs in the network about the allocation without setting the C 441 bit. 443 5.5.1.2. PCECC SR Adjacency Label allocation 445 [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE 446 to compute and initiate SR-TE paths, as well as a PCC to request a 447 path subject to certain constraint(s) and optimization criteria in SR 448 networks. 450 For PCECC SR, apart from node-SID, Adj-SID is used where each 451 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 452 PCInitiate message to update the label map of each Adj to the 453 corresponding nodes in the domain. Each node (PCC) download the 454 label forwarding instructions accordingly. Similar to SR Node/Prefix 455 Label allocation, the PCInitiate message in this case MUST NOT have 456 LSP object but uses the new FEC object defined in this document. 458 +---------+ +-------+ 459 |PCC | | PCE | 460 |192.0.2.3| +-------+ 461 +------| | | 462 | PCC +---------+ | 463 | 192.0.2.2| | | 464 +------| | | | 465 |PCC +----------+ | | 466 |192.0.2.1| | | | 467 +---------+ | | | 468 | | | | 469 |<------ PCInitiate, FEC=198.51.100.1 / --------- | Label Map 470 | | | 198.51.100.2 | update 471 | | | CC-ID=A | 472 |------- PCRpt,CC-ID=A ------------------------->| 473 | | | | 474 | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map 475 | | | 198.51.100.1 | update 476 | | | CC-ID=B | 477 | |----- PCRpt,CC-ID=B ----------------->| 478 | | | | 480 The forwarding behavior and the end result is similar to IGP based 481 "Adj-SID" in SR. 483 The Path Setup Type for segment routing MUST be set for PCECC SR = 484 TBD (see Section 7.2). All PCEP procedures and mechanism are similar 485 to [I-D.ietf-pce-segment-routing]. 487 PCE relies on the Adj label cleanup using the same PCInitiate 488 message. 490 The above example Figure 3 depict FEC and PCEP speakers that uses 491 IPv4 address. Similarly IPv6 address (such as 2001:DB8::1, 492 2001:DB8::2) can be used during PCEP session establishment as well in 493 FEC object as described in this specification. 495 In case where the label allocation are made by the PCC itself (see 496 Section 5.5.1.6), the PCE could still request an allocation to be 497 made by the PCC, and where the PCC would send a PCRpt with the 498 allocated label encoded in the CC-ID object as shown below - 499 +---------+ +-------+ 500 |PCC | | PCE | 501 |192.0.2.3| +-------+ 502 +------| | | 503 | PCC +---------+ | 504 | 192.0.2.2| | | 505 +------| | | | 506 |PCC +----------+ | | 507 |192.0.2.1| | | | 508 +---------+ | | | 509 | | | | 510 |<------ PCInitiate, FEC=198.51.100.1------------ | Label Map 511 | | | 198.51.100.2 | request 512 | | | CC-ID=A,C=1 | 513 |------- PCRpt,CC-ID=A,Label -------------------->| 514 | | | | 515 | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map 516 | | | 198.51.100.1 | request 517 | | | CC-ID=B,C=1 | 518 | |----- PCRpt,CC-ID=B,Label------------->| 519 | | | | 521 In this example the request is made to the node 192.0.2.1 with C bit 522 set in the CCI object to indicate that the allocation needs to be 523 done by this PCC for the adjacency (198.51.100.1 - 198.51.100.2) and 524 it responds with the allocated label/SID to the PCE. Similarly, 525 another request is made to the node 192.0.2.2 with C bit set in the 526 CCI object to indicate that the allocation needs to be done by this 527 PCC for the adjacency (198.51.100.2 - 198.51.100.1). 529 5.5.1.3. Redundant PCEs 531 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 532 between the stateful PCEs. The SR SIDs allocated by a PCE MUST also 533 be synchronized among PCEs for PCECC SR state synchronization. Note 534 that the SR SIDs are independent to the PCECC-SR LSP, and remains 535 intact till any topology change. The redundant PCEs MUST have a 536 common view of all SR SIDs allocated in the domain. 538 5.5.1.4. Re Delegation and Cleanup 540 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the action 541 needed for CCIs for the Basic PCECC LSP on this terminated session. 542 Similarly actions should be applied for the SR SID as well. 544 5.5.1.5. Synchronization of Label Allocations 546 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the 547 synchronization of Central Controller's Instructions (CCI) via LSP 548 state synchronization as described in [RFC8231] and [RFC8232]. Same 549 procedures should be applied for SR SIDs as well. 551 5.5.1.6. PCC Based Allocations 553 The PCE can request the PCC to allocate the label/SID using the 554 PCInitiate message. The C flag in the CCI object is set to 1 to 555 indicate that the allocation needs to be done by the PCC. The PCC 556 would allocate the SID/Label/Index and would report to the PCE using 557 the PCRpt message. 559 If the value of the SID/Label/Index is 0 and the C flag is set, it 560 indicates that the PCE is requesting the allocation to be done by the 561 PCC. If the SID/Label/Index is 'n' and the C flag is set in the CCI 562 object, it indicates that the PCE requests a specific value 'n' for 563 the SID/Label/Index. If the allocation is successful, the PCC should 564 report via PCRpt message with the CCI object. Else, it MUST send a 565 PCErr message with Error-Type = TBD ("PCECC failure") and Error Value 566 = TBD ("Invalid CCI"). If the value of the the SID/Label/Index in 567 the CCI object is valid, but the PCC is unable to allocate it, it 568 MUST send a PCErr message with Error-Type = TBD ("PCECC failure") and 569 Error Value = TBD ("Unable to allocate the specified CCI"). 571 If the PCC wishes to withdrawn or modify the previously assigned 572 label/SID, it MUST send a PCRpt message without any SID/Label/Index 573 or with the SID/Label/Index containing the new value respectively in 574 the CCI object. The PCE would further trigger the removal of the 575 central controller instruction as per this document. 577 5.5.1.7. Binding SID 579 A PCE as a central controller can allocate and provision the 580 node/prefix/adjacency label (SID) via PCEP. One such SID is binding 581 SID as described in [I-D.sivabalan-pce-binding-label-sid], the PCECC 582 mechanism can also be used to allocate the binding SID as described 583 in this section. 585 A procedure for binding label/SID allocation is described in 586 [I-D.ietf-pce-pcep-extension-for-pce-controller] and is applicable 587 for all path setup types (including SR paths). 589 6. PCEP messages 591 As defined in [RFC5440], a PCEP message consists of a common header 592 followed by a variable-length body made of a set of objects that can 593 be either mandatory or optional. An object is said to be mandatory 594 in a PCEP message when the object must be included for the message to 595 be considered valid. For each PCEP message type, a set of rules is 596 defined that specify the set of objects that the message can carry. 597 An implementation MUST form the PCEP messages using the object 598 ordering specified in this document. 600 6.1. Central Control Instructions 602 6.1.1. The PCInitiate message 604 The PCInitiate Message defined in [RFC8281] and extended in 605 [I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended 606 to support SR based central control instructions. 608 The format of the extended PCInitiate message is as follows: 610 ::= 611 612 Where: 613 is defined in [RFC5440] 615 ::= 616 [] 618 ::= 619 (| 620 | 621 ) 623 ::= 624 ( 625 )| 626 ( 627 ) 629 ::= 630 [] 632 Where: 633 and 634 are as per 635 [RFC8281]. 637 The LSP and SRP object is defined in [RFC8231]. 639 When PCInitiate message is used to distribute SR SIDs, the SRP, FEC 640 and CCI objects MUST be present. The error handling for missing SRP 641 or CCI object is as per 642 [I-D.ietf-pce-pcep-extension-for-pce-controller]. If the FEC object 643 is missing, the receiving PCC MUST send a PCErr message with Error- 644 type=6 (Mandatory Object missing) and Error-value=TBD (FEC object 645 missing). 647 To cleanup the SRP object must set the R (remove) bit. 649 6.1.2. The PCRpt message 651 The PCRpt message can be used to report the SR instructions received 652 from the central controller (PCE) during the state synchronization 653 phase. 655 The format of the PCRpt message is as follows: 657 ::= 658 659 Where: 661 ::= [] 663 ::= (| 664 ) 666 ::= [] 667 668 670 ::= [] 671 ( 672 )| 673 ( 674 ) 676 ::= 677 [] 679 Where: 680 is as per [RFC8231] and the LSP and SRP object are 681 also defined in [RFC8231]. 683 When PCRpt message is used to report the label map allocations, the 684 FEC and CCI objects MUST be present. The error handling for CCI 685 object is as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. 686 If the FEC object is missing, the receiving PCC MUST send a PCErr 687 message with Error-type=6 (Mandatory Object missing) and Error- 688 value=TBD (FEC object missing). 690 7. PCEP Objects 692 7.1. OPEN Object 694 7.1.1. PCECC Capability sub-TLV 696 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 697 CAPABILITY TLV. 699 A new S-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SR: 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type=TBD | Length=4 | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Flags |S| 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 S (PCECC-SR-CAPABILITY - 1 bit): If set to 1 by a PCEP speaker, it 710 indicates that the PCEP speaker is capable for PCECC-SR capability 711 and PCE would allocate node and Adj label on this session. 713 7.2. PATH-SETUP-TYPE TLV 715 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. PST = TBD is used 716 when Path is setup via PCECC SR mode. 718 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD indicates that this 719 LSP was setup via a PCECC-SR based mechanism where either the SIDs 720 were allocated/instructed by PCE via PCECC mechanism. 722 7.3. CCI Object 724 The Central Control Instructions (CCI) Object is used by the PCE to 725 specify the forwarding instructions is defined in 726 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 727 defines another object-type for SR purpose. 729 CCI Object-Type is TBD for SR as below - 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | CC-ID | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | MT-ID | Algorithm | Flags |C|N|E|V|L|O| 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 // SID/Label/Index (variable) // 739 +---------------------------------------------------------------+ 740 | | 741 // Optional TLV // 742 | | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 The field CC-ID is as described in 745 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following new 746 fields are defined for CCI Object-Type TBD - 748 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 750 Algorithm: Single octet identifying the algorithm the SID is 751 associated with. See [I-D.ietf-ospf-segment-routing-extensions]. 753 Flags: is used to carry any additional information pertaining to the 754 CCI. The O bit was defined in 755 [I-D.ietf-pce-pcep-extension-for-pce-controller], this document 756 further defines following bits- 758 * L-Bit (Local/Global): If set, then the value/index carried by 759 the CCI object has local significance. If not set, then the 760 value/index carried by this object has global significance. 762 * V-Bit (Value/Index): If set, then the CCI carries an absolute 763 value. If not set, then the CCI carries an index. 765 * E-Bit (Explicit-Null): If set, any upstream neighbor of the 766 node that advertised the SID MUST replace the SID with the 767 Explicit-NULL label (0 for IPv4) before forwarding the packet. 769 * N-Bit (No-PHP): If set, then the penultimate hop MUST NOT pop 770 the SID before delivering packets to the node that advertised 771 the SID. 773 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 774 that the allocation needs to be done by the PCC for this 775 central controller instruction. A PCE set this bit to request 776 the PCC to make an allocation from its SR label/ID space. A 777 PCC would set this bit to indicate that it has allocated the 778 CC-ID and report it to the PCE. 780 SID/Label/Index: According to the V and L flags, it contains either: 782 A 32-bit index defining the offset in the SID/Label space 783 advertised by this router. 785 A 24-bit label where the 20 rightmost bits are used for 786 encoding the label value. 788 7.4. FEC Object 790 The FEC Object is used to specify the FEC information and MAY be 791 carried within PCInitiate or PCRpt message. 793 FEC Object-Class is TBD. 795 FEC Object-Type is 1 'IPv4 Node ID'. 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | IPv4 Node ID | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 FEC Object-Type is 2 'IPv6 Node ID'. 805 0 1 2 3 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | | 809 // IPv6 Node ID (16 bytes) // 810 | | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 FEC Object-Type is 3 'IPv4 Adjacency'. 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Local IPv4 address | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Remote IPv4 address | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 FEC Object-Type is 4 'IPv6 Adjacency'. 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | | 829 // Local IPv6 address (16 bytes) // 830 | | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | 833 // Remote IPv6 address (16 bytes) // 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 FEC Object-Type is 5 'Unnumbered Adjacency with IPv4 NodeIDs'. 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Local Node-ID | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Local Interface ID | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Remote Node-ID | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Remote Interface ID | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 The FEC objects are as follows: 853 IPv4 Node ID: where IPv4 Node ID is specified as an IPv4 address of 854 the Node. FEC Object-type is 1, and the Object-Length is 4 in this 855 case. 857 IPv6 Node ID: where IPv6 Node ID is specified as an IPv6 address of 858 the Node. FEC Object-type is 2, and the Object-Length is 16 in this 859 case. 861 IPv4 Adjacency: where Local and Remote IPv4 address is specified as 862 pair of IPv4 address of the adjacency. FEC Object-type is 3, and the 863 Object-Length is 8 in this case. 865 IPv6 Adjacency: where Local and Remote IPv6 address is specified as 866 pair of IPv6 address of the adjacency. FEC Object-type is 4, and the 867 Object-Length is 32 in this case. 869 Unnumbered Adjacency with IPv4 NodeID: where a pair of Node ID / 870 Interface ID tuples is used. FEC Object-type is 5, and the Object- 871 Length is 16 in this case. 873 Binding ID: TBD 875 8. Security Considerations 877 The security considerations described in 878 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the 879 extensions described in this document. 881 9. Manageability Considerations 883 9.1. Control of Function and Policy 885 A PCE or PCC implementation SHOULD allow to configure to enable/ 886 disable PCECC SR capability as a global configuration. 888 9.2. Information and Data Models 890 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 891 PCECC SR capability status. 893 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 894 enable/disable PCECC SR capability. 896 9.3. Liveness Detection and Monitoring 898 Mechanisms defined in this document do not imply any new liveness 899 detection and monitoring requirements in addition to those already 900 listed in [RFC5440]. 902 9.4. Verify Correct Operations 904 Mechanisms defined in this document do not imply any new operation 905 verification requirements in addition to those already listed in 906 [RFC5440] and [RFC8231]. 908 9.5. Requirements On Other Protocols 910 PCEP extensions defined in this document do not put new requirements 911 on other protocols. 913 9.6. Impact On Network Operations 915 PCEP implementation SHOULD allow a limit to be placed on the rate of 916 PCLabelUpd messages sent by PCE and processed by PCC. It SHOULD also 917 allow sending a notification when a rate threshold is reached. 919 10. IANA Considerations 921 10.1. PCECC-CAPABILITY TLV 923 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 924 CAPABILITY TLV and requests that IANA creates a registry to manage 925 the value of the PCECC-CAPABILITY TLV's Flag field. IANA is 926 requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag 927 Field registry, as follows: 929 Bit Description Reference 930 31 S((PCECC-SR-CAPABILITY)) This document 932 10.2. New Path Setup Type Registry 934 IANA is requested to allocate new PST Field in PATH- SETUP-TYPE TLV. 935 The allocation policy for this new registry should be by IETF 936 Consensus. The new registry should contain the following value: 938 Value Description Reference 939 TBD Traffic engineering path is This document 940 setup using PCECC-SR mode 942 10.3. PCEP Object 944 IANA is requested to allocate new registry for FEC PCEP object. 946 Object-Class Value Name Reference 947 TBD FEC This document 948 Object-Type : 1 IPv4 Node ID 949 Object-Type : 2 IPv6 Node ID 950 Object-Type : 3 IPv4 Adjacency 951 Object-Type : 4 IPv6 Adjacency 952 Object-Type : 5 Unnumbered Adjacency 953 with IPv4 NodeID 955 10.4. PCEP-Error Object 957 IANA is requested to allocate new error types and error values within 958 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 959 PCEP Numbers registry for the following errors: 961 Error-Type Meaning 962 ---------- ------- 963 6 Mandatory Object missing. 965 Error-value = TBD : FEC object missing 966 19 Invalid operation. 968 Error-value = TBD : SR capability was 969 not advertised 971 11. Acknowledgments 973 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 974 Avantika for their useful comments and suggestions. 976 12. References 978 12.1. Normative References 980 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 981 Requirement Levels", BCP 14, RFC 2119, 982 DOI 10.17487/RFC2119, March 1997, 983 . 985 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 986 (TE) Extensions to OSPF Version 2", RFC 3630, 987 DOI 10.17487/RFC3630, September 2003, 988 . 990 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 991 Support of Generalized Multi-Protocol Label Switching 992 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 993 . 995 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 996 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 997 RFC 4915, DOI 10.17487/RFC4915, June 2007, 998 . 1000 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1001 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1002 2008, . 1004 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1005 in Support of Generalized Multi-Protocol Label Switching 1006 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1007 . 1009 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1010 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1011 DOI 10.17487/RFC5440, March 2009, 1012 . 1014 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1015 Hardwick, "Path Computation Element Communication Protocol 1016 (PCEP) Management Information Base (MIB) Module", 1017 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1018 . 1020 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1021 S. Ray, "North-Bound Distribution of Link-State and 1022 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1023 DOI 10.17487/RFC7752, March 2016, 1024 . 1026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1027 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1028 May 2017, . 1030 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1031 Computation Element Communication Protocol (PCEP) 1032 Extensions for Stateful PCE", RFC 8231, 1033 DOI 10.17487/RFC8231, September 2017, 1034 . 1036 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1037 Computation Element Communication Protocol (PCEP) 1038 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1039 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1040 . 1042 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1043 Hardwick, "Conveying Path Setup Type in PCE Communication 1044 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1045 July 2018, . 1047 12.2. Informative References 1049 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1050 Label Switching Architecture", RFC 3031, 1051 DOI 10.17487/RFC3031, January 2001, 1052 . 1054 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1055 Element (PCE)-Based Architecture", RFC 4655, 1056 DOI 10.17487/RFC4655, August 2006, 1057 . 1059 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1060 Margaria, "Requirements for GMPLS Applications of PCE", 1061 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1062 . 1064 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1065 Computation Element Architecture", RFC 7399, 1066 DOI 10.17487/RFC7399, October 2014, 1067 . 1069 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1070 Application-Based Network Operations", RFC 7491, 1071 DOI 10.17487/RFC7491, March 2015, 1072 . 1074 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1075 and D. Dhody, "Optimizations of Label Switched Path State 1076 Synchronization Procedures for a Stateful PCE", RFC 8232, 1077 DOI 10.17487/RFC8232, September 2017, 1078 . 1080 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1081 Architecture for Use of PCE and the PCE Communication 1082 Protocol (PCEP) in a Network with Central Control", 1083 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1084 . 1086 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1087 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1088 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1089 July 2018, . 1091 [I-D.ietf-teas-pcecc-use-cases] 1092 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1093 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1094 Gulida, "The Use Cases for Path Computation Element (PCE) 1095 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1096 use-cases-02 (work in progress), October 2018. 1098 [I-D.ietf-pce-pcep-yang] 1099 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1100 YANG Data Model for Path Computation Element 1101 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1102 yang-09 (work in progress), October 2018. 1104 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1105 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 1106 and C. Zhou, "PCEP Procedures and Protocol Extensions for 1107 Using PCE as a Central Controller (PCECC) of LSPs", draft- 1108 ietf-pce-pcep-extension-for-pce-controller-00 (work in 1109 progress), November 2018. 1111 [I-D.ietf-pce-segment-routing] 1112 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1113 and J. Hardwick, "PCEP Extensions for Segment Routing", 1114 draft-ietf-pce-segment-routing-14 (work in progress), 1115 October 2018. 1117 [I-D.ietf-isis-segment-routing-extensions] 1118 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1119 Gredler, H., and B. Decraene, "IS-IS Extensions for 1120 Segment Routing", draft-ietf-isis-segment-routing- 1121 extensions-22 (work in progress), December 2018. 1123 [I-D.ietf-ospf-segment-routing-extensions] 1124 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1125 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1126 Extensions for Segment Routing", draft-ietf-ospf-segment- 1127 routing-extensions-27 (work in progress), December 2018. 1129 [I-D.litkowski-pce-state-sync] 1130 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 1131 Stateful Path Computation Element communication 1132 procedures", draft-litkowski-pce-state-sync-04 (work in 1133 progress), October 2018. 1135 [I-D.dhodylee-pce-pcep-ls] 1136 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 1137 Distribution of Link-State and TE Information.", draft- 1138 dhodylee-pce-pcep-ls-12 (work in progress), December 2018. 1140 [I-D.ietf-spring-segment-routing-mpls] 1141 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1142 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1143 data plane", draft-ietf-spring-segment-routing-mpls-18 1144 (work in progress), December 2018. 1146 [I-D.sivabalan-pce-binding-label-sid] 1147 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1148 Previdi, S., and D. Dhody, "Carrying Binding Label/ 1149 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 1150 binding-label-sid-05 (work in progress), October 2018. 1152 Appendix A. Contributor Addresses 1154 Dhruv Dhody 1155 Huawei Technologies 1156 Divyashree Techno Park, Whitefield 1157 Bangalore, Karnataka 560066 1158 India 1160 EMail: dhruv.ietf@gmail.com 1162 Satish Karunanithi 1163 Huawei Technologies 1164 Divyashree Techno Park, Whitefield 1165 Bangalore, Karnataka 560066 1166 India 1168 EMail: satishk@huawei.com 1170 Adrian Farrel 1171 Juniper Networks, Inc 1172 UK 1174 EMail: adrian@olddog.co.uk 1176 Xuesong Geng 1177 Huawei Technologies 1178 China 1180 Email: gengxuesong@huawei.com 1182 Udayasree Palle 1183 Huawei Technologies 1184 Divyashree Techno Park, Whitefield 1185 Bangalore, Karnataka 560066 1186 India 1188 EMail: udayasreereddy@gmail.com 1190 Katherine Zhao 1191 Huawei Technologies 1192 2330 Central Expressway 1193 Santa Clara, CA 95050 1194 USA 1196 EMail: katherine.zhao@huawei.com 1198 Boris Zhang 1199 Telus Ltd. 1201 Toronto 1202 Canada 1204 EMail: boris.zhang@telus.com 1206 Alex Tokar 1207 Cisco Systems 1208 Slovak Republic 1210 EMail: atokar@cisco.com 1212 Authors' Addresses 1214 Quintin Zhao 1215 Huawei Technologies 1216 125 Nagog Technology Park 1217 Acton, MA 01719 1218 USA 1220 EMail: quintin.zhao@huawei.com 1222 Zhenbin Li 1223 Huawei Technologies 1224 Huawei Bld., No.156 Beiqing Rd. 1225 Beijing 100095 1226 China 1228 EMail: lizhenbin@huawei.com 1230 Mahendra Singh Negi 1231 Huawei Technologies 1232 Divyashree Techno Park, Whitefield 1233 Bangalore, Karnataka 560066 1234 India 1236 EMail: mahendrasingh@huawei.com 1238 Chao Zhou 1239 Cisco Systems 1241 EMail: choa.zhou@cisco.com