idnits 2.17.1 draft-zhao-pce-pcep-extension-pce-controller-sr-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 (July 8, 2019) is 1716 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 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-04 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-12 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-02 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-06 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-13 Summary: 2 errors (**), 0 flaws (~~), 6 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: January 9, 2020 Huawei Technologies 6 C. Zhou 7 Cisco Systems 8 July 8, 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-05 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 January 9, 2020. 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. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 110 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 21 111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 112 10. Manageability Considerations . . . . . . . . . . . . . . . . 22 113 10.1. Control of Function and Policy . . . . . . . . . . . . . 22 114 10.2. Information and Data Models . . . . . . . . . . . . . . 22 115 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 22 116 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 23 117 10.5. Requirements On Other Protocols . . . . . . . . . . . . 23 118 10.6. Impact On Network Operations . . . . . . . . . . . . . . 23 119 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 120 11.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 23 121 11.2. New Path Setup Type Registry . . . . . . . . . . . . . . 23 122 11.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 24 123 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 24 124 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 126 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 127 13.2. Informative References . . . . . . . . . . . . . . . . . 26 128 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 30 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 131 1. Introduction 133 The Path Computation Element (PCE) [RFC4655] was developed to offload 134 path computation function from routers in an MPLS traffic-engineered 135 network. Since then, the role and function of the PCE has grown to 136 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 137 delegated control [RFC8231] and PCE-initiated use of network 138 resources [RFC8281]. 140 According to [RFC7399], Software-Defined Networking (SDN) refers to a 141 separation between the control elements and the forwarding components 142 so that software running in a centralized system, called a 143 controller, can act to program the devices in the network to behave 144 in specific ways. A required element in an SDN architecture is a 145 component that plans how the network resources will be used and how 146 the devices will be programmed. It is possible to view this 147 component as performing specific computations to place traffic flows 148 within the network given knowledge of the availability of network 149 resources, how other forwarding devices are programmed, and the way 150 that other flows are routed. This is the function and purpose of a 151 PCE, and the way that a PCE integrates into a wider network control 152 system (including an SDN system) is presented in [RFC7491]. 154 In early PCE implementations, where the PCE was used to derive paths 155 for MPLS Label Switched Paths (LSPs), paths were requested by network 156 elements (known as Path Computation Clients (PCCs)), and the results 157 of the path computations were supplied to network elements using the 158 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 159 This protocol was later extended to allow a PCE to send unsolicited 160 requests to the network for LSP establishment [RFC8281]. 162 [RFC8283] introduces the architecture for PCE as a central controller 163 as an extension of the architecture described in [RFC4655] and 164 assumes the continued use of PCEP as the protocol used between PCE 165 and PCC. [RFC8283] further examines the motivations and 166 applicability for PCEP as a Southbound Interface (SBI), and 167 introduces the implications for the protocol. 168 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 169 architecture. 171 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 172 procedures and PCEP protocol extensions for using the PCE as the 173 central controller for static LSPs, where LSPs can be provisioned as 174 explicit label instructions at each hop on the end-to-end path. 176 Segment Routing (SR) technology leverages the source routing and 177 tunneling paradigms. A source node can choose a path without relying 178 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 179 is specified as a set of "segments" advertised by link-state routing 180 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to SR 181 architecture. The corresponding IS-IS and OSPF extensions are 182 specified in [I-D.ietf-isis-segment-routing-extensions] and 183 [I-D.ietf-ospf-segment-routing-extensions] , respectively. It relies 184 on a series of forwarding instructions being placed in the header of 185 a packet. The segment routing architecture supports operations that 186 can be used to steer packet flows in a network, thus providing a form 187 of traffic engineering. [I-D.ietf-pce-segment-routing] specify the 188 SR specific PCEP extensions. 190 PCECC may further use PCEP protocol for SR SID (Segment Identifier) 191 distribution on the SR nodes with some benefits. 193 This document specifies the procedures and PCEP protocol extensions 194 when a PCE-based controller is also responsible for configuring the 195 forwarding actions on the routers (SR SID distribution in this case), 196 in addition to computing the paths for packet flows in a segment 197 routing network and telling the edge routers what instructions to 198 attach to packets as they enter the network. 200 1.1. Requirements Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 204 "OPTIONAL" in this document are to be interpreted as described in BCP 205 14 [RFC2119] [RFC8174] when, and only when, they appear in all 206 capitals, as shown here. 208 2. Terminology 210 Terminologies used in this document is same as described in the draft 211 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 213 3. PCECC SR 215 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 216 allow a stateful PCE to compute, update or initiate SR-TE paths. An 217 ingress node of an SR-TE path appends all outgoing packets with a 218 list of MPLS labels (SIDs). This is encoded in SR-ERO subobject, 219 capable of carrying a label (SID) as well as the identity of the 220 node/adjacency label (SID). 222 The notion of segment and SID is defined in [RFC8402], which fits the 223 MPLS architecture [RFC3031] as the label which is managed by a local 224 allocation process of LSR (similarly to other MPLS signaling 225 protocols) [I-D.ietf-spring-segment-routing-mpls]. The SR 226 information such as node/adjacency label (SID) is flooded via IGP as 227 specified in [I-D.ietf-isis-segment-routing-extensions] and 228 [I-D.ietf-ospf-segment-routing-extensions]. 230 As per [RFC8283], PCE as a central controller can allocate and 231 provision the node/prefix/adjacency label (SID) via PCEP. 233 Rest of the processing is similar to existing stateful PCE with SR 234 mechanism. 236 For the purpose of this document, it is assumed that label range to 237 be used by a PCE is set on both PCEP peers. Further, a global label 238 range is assumed to be set on all PCEP peers in the SR domain. This 239 document also allow a case where the label space is maintained by PCC 240 itself, and the labels are allocated by the PCC, in this case, the 241 PCE should request the allocation from PCC as described in 242 Section 5.5.1.6. 244 4. PCEP Requirements 246 Following key requirements for PCECC-SR should be considered when` 247 designing the PCECC based solution: 249 o PCEP speaker supporting this draft MUST have the capability to 250 advertise its PCECC-SR capability to its peers. 252 o PCEP speaker not supporting this draft MUST be able to reject 253 PCECC-SR related message with a reason code that indicates no 254 support for PCECC. 256 o PCEP procedures MUST provide a means to update (or cleanup) the 257 label- map entry to the PCC. 259 o PCEP procedures SHOULD provide a means to synchronize the SR 260 labels allocations between PCE to PCC in the PCEP messages. 262 o PCEP procedures MAY allow for PCC based label allocations. 264 5. Procedures for Using the PCE as the Central Controller (PCECC) in 265 Segment Routing 267 5.1. Stateful PCE Model 269 Active stateful PCE is described in [RFC8231]. PCE as a central 270 controller (PCECC) reuses existing Active stateful PCE mechanism as 271 much as possible to control the LSP. 273 5.2. New LSP Functions 275 This document uses the same PCEP messages and its extensions which 276 are described in [I-D.ietf-pce-pcep-extension-for-pce-controller] for 277 PCECC-SR as well. 279 PCEP messages PCRpt, PCInitiate, PCUpd are also used to send LSP 280 Reports, LSP setup and LSP update respectively. The extended 281 PCInitiate message described in 282 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 283 or cleanup central controller's instructions (CCIs) (SR SID in scope 284 of this document). The extended PCRpt message described in 285 [I-D.ietf-pce-pcep-extension-for-pce-controller] is also used to 286 report the CCIs (SR SIDs) from PCC to PCE. 288 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 289 called CCI for the encoding of central controller's instructions. 290 This document extends the CCI by defining a new object-type for 291 segment routing. The PCEP messages are extended in this document to 292 handle the PCECC operations for SR. 294 5.3. PCECC Capability Advertisement 296 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 297 advertise their support of PCECC extensions. A PCEP Speaker includes 298 the "PCECC Capability" sub-TLV, described in 299 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 301 A new S-bit is added in PCECC-CAPABILITY sub-TLV to indicate support 302 for PCECC-SR. A PCC MUST set S-bit in PCECC-CAPABILITY sub-TLV and 303 include SR-PCE-CAPABILITY sub-TLV ([I-D.ietf-pce-segment-routing]) in 304 OPEN Object (inside the the PATH-SETUP-TYPE-CAPABILITY TLV) to 305 support the PCECC SR extensions defined in this document. If S-bit 306 is set in PCECC-CAPABILITY sub-TLV and SR-PCE-CAPABILITY sub-TLV is 307 not advertised in OPEN Object, PCE SHOULD send a PCErr message with 308 Error-Type=19 (Invalid Operation) and Error-value=TBD(SR capability 309 was not advertised) and terminate the session. 311 5.4. PCEP session IP address and TEDB Router ID 313 PCE may construct its TEDB by participating in the IGP ([RFC3630] and 314 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 315 alternative is offered by BGP-LS [RFC7752] and 316 [I-D.dhodylee-pce-pcep-ls]. 318 PCEP [RFC5440] speaker MAY use any IP address while creating a TCP 319 session. It is important to link the session IP address with the 320 Router ID in TEDB for successful PCECC operations. 322 During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping 323 information. Thus a PCC includes the "Node Attributes TLV" 324 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 325 in the OPEN Object for this purpose. [RFC7752] describes the usage 326 as auxiliary Router-IDs that the IGP might be using, e.g., for TE 327 purposes. If there are more than one auxiliary Router-ID of a given 328 type, then multiple TLVs are used to encode them. 330 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 331 address is directly used for the mapping purpose. 333 5.5. LSP Operations 335 The PCEP messages pertaining to PCECC-SR MUST include PATH-SETUP-TYPE 336 TLV [RFC8408] with PST=TBD in the SRP object to clearly identify the 337 PCECC-SR LSP is intended. 339 5.5.1. PCECC Segment Routing (SR) 341 Segment Routing (SR) as described in [RFC8402] depends on "segments" 342 that are advertised by Interior Gateway Protocols (IGPs). The SR- 343 node allocates and advertises the SID (node, adj etc) and flood via 344 the IGP. This document proposes a new mechanism where PCE allocates 345 the SID (label/index/SID) centrally and uses PCEP to advertise the 346 SID. In some deployments PCE (and PCEP) are better suited than IGP 347 because of centralized nature of PCE and direct TCP based PCEP 348 session to the node. 350 5.5.1.1. PCECC SR Node/Prefix SID allocation 352 Each node (PCC) is allocated a node-SID by the PCECC. The PCECC 353 sends PCInitiate message to update the label map of each node to all 354 the nodes in the domain. The TE router ID is determined from the 355 TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV 356 [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. 358 It is RECOMMENDED that PCEP session with PCECC SR capability to use a 359 different session IP address during TCP session establishment than 360 the node Router ID in TEDB, to make sure that the PCEP session does 361 not get impacted by the SR Node/Prefix Label maps (Section 5.4). 363 If a node (PCC) receives a PCInitiate message with a CCI encoding a 364 SID, out of the range set aside for the SRGB, it MUST send a PCErr 365 message with Error-type=TBD (PCECC failure) and Error-value=TBD (SID 366 out of range) and MUST include the SRP object to specify the error is 367 for the corresponding label update via PCInitiate message. 369 On receiving the label map, each node (PCC) uses the local 370 information to determine the next-hop and download the label 371 forwarding instructions accordingly. The PCInitiate message in this 372 case MUST NOT have LSP object but uses the new FEC object defined in 373 this document. 375 +---------+ +-------+ 376 |PCC | | PCE | 377 |192.0.2.3| +-------+ 378 +------| | | 379 | PCC +---------+ | 380 | 192.0.2.2| | | 381 +------| | | | 382 |PCC +----------+ | | 383 |192.0.2.1| | | | 384 +---------+ | | | 385 | | | | 386 |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map 387 | | | CC-ID=X | update 388 |------- PCRpt,CC-ID=X --------------------------->| CCI 389 |Find | | | 390 |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map 391 |locally| | CC-ID=Y | update 392 | |----- PCRpt,CC-ID=Y -------------------->| CCI 393 | | | | 394 | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map 395 | | | CC-ID=Z | update 396 | | |---- PCRpt,CC-ID=Z -------------->| CCI 397 | | | | 399 The forwarding behavior and the end result is similar to IGP based 400 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 401 ECMP-aware shortest-path forwarding of the packet towards the related 402 node. 404 PCE relies on the Node/Prefix Label cleanup using the same PCInitiate 405 message. 407 The above example Figure 1 depict FEC and PCEP speakers that uses 408 IPv4 address. Similarly IPv6 address (such as 2001:DB8::1) can be 409 used during PCEP session establishment as well in FEC object as 410 described in this specification. 412 In case where the label allocation are made by the PCC itself (see 413 Section 5.5.1.6), the PCE could still request an allocation to be 414 made by the PCC, and where the PCC would send a PCRpt with the 415 allocated label encoded in the CC-ID object as shown below - 416 +---------+ +-------+ 417 |PCC | | PCE | 418 |192.0.2.3| +-------+ 419 +------| | | 420 | PCC +---------+ | 421 | 192.0.2.2| | | 422 +------| | | | 423 |PCC +----------+ | | 424 |192.0.2.1| | | | 425 +---------+ | | | 426 | | | | 427 |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map 428 | | | CC-ID=X,C=1 | request 429 |------- PCRpt,CC-ID=X,Label ---------------------->| CCI 430 |Find | | | 431 |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map 432 |locally| | CC-ID=Y,C=0,Label | update 433 | |----- PCRpt,CC-ID=Y -------------------->| CCI 434 | | | | 435 | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map 436 | | | CC-ID=Z,C=0,Label | update 437 | | |---- PCRpt,CC-ID=Z -------------->| CCI 438 | | | | 440 It should be noted that in this example, the request is made to the 441 node 192.0.2.1 with C bit set in the CCI object to indicate that the 442 allocation needs to be done by this PCC and it responds with the 443 allocated label/SID to the PCE. The PCE would further inform the 444 other PCCs in the network about the allocation without setting the C 445 bit. 447 5.5.1.2. PCECC SR Adjacency Label allocation 449 [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE 450 to compute and initiate SR-TE paths, as well as a PCC to request a 451 path subject to certain constraint(s) and optimization criteria in SR 452 networks. 454 For PCECC SR, apart from node-SID, Adj-SID is used where each 455 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 456 PCInitiate message to update the label map of each Adj to the 457 corresponding nodes in the domain. Each node (PCC) download the 458 label forwarding instructions accordingly. Similar to SR Node/Prefix 459 Label allocation, the PCInitiate message in this case MUST NOT have 460 LSP object but uses the new FEC object defined in this document. 462 +---------+ +-------+ 463 |PCC | | PCE | 464 |192.0.2.3| +-------+ 465 +------| | | 466 | PCC +---------+ | 467 | 192.0.2.2| | | 468 +------| | | | 469 |PCC +----------+ | | 470 |192.0.2.1| | | | 471 +---------+ | | | 472 | | | | 473 |<------ PCInitiate, FEC=198.51.100.1 / --------- | Label Map 474 | | | 198.51.100.2 | update 475 | | | CC-ID=A | CCI 476 |------- PCRpt,CC-ID=A ------------------------->| 477 | | | | 478 | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map 479 | | | 198.51.100.1 | update 480 | | | CC-ID=B | CCI 481 | |----- PCRpt,CC-ID=B ----------------->| 482 | | | | 484 The forwarding behavior and the end result is similar to IGP based 485 "Adj-SID" in SR. 487 The Path Setup Type for segment routing MUST be set for PCECC SR = 488 TBD (see Section 7.2). All PCEP procedures and mechanism are similar 489 to [I-D.ietf-pce-segment-routing]. 491 PCE relies on the Adj label cleanup using the same PCInitiate 492 message. 494 The above example Figure 3 depict FEC and PCEP speakers that uses 495 IPv4 address. Similarly IPv6 address (such as 2001:DB8::1, 496 2001:DB8::2) can be used during PCEP session establishment as well in 497 FEC object as described in this specification. 499 In case where the label allocation are made by the PCC itself (see 500 Section 5.5.1.6), the PCE could still request an allocation to be 501 made by the PCC, and where the PCC would send a PCRpt with the 502 allocated label encoded in the CC-ID object as shown below - 503 +---------+ +-------+ 504 |PCC | | PCE | 505 |192.0.2.3| +-------+ 506 +------| | | 507 | PCC +---------+ | 508 | 192.0.2.2| | | 509 +------| | | | 510 |PCC +----------+ | | 511 |192.0.2.1| | | | 512 +---------+ | | | 513 | | | | 514 |<------ PCInitiate, FEC=198.51.100.1------------ | Label Map 515 | | | 198.51.100.2 | request 516 | | | CC-ID=A,C=1 | CCI 517 |------- PCRpt,CC-ID=A,Label -------------------->| 518 | | | | 519 | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map 520 | | | 198.51.100.1 | request 521 | | | CC-ID=B,C=1 | CCI 522 | |----- PCRpt,CC-ID=B,Label------------->| 523 | | | | 525 In this example the request is made to the node 192.0.2.1 with C bit 526 set in the CCI object to indicate that the allocation needs to be 527 done by this PCC for the adjacency (198.51.100.1 - 198.51.100.2) and 528 it responds with the allocated label/SID to the PCE. Similarly, 529 another request is made to the node 192.0.2.2 with C bit set in the 530 CCI object to indicate that the allocation needs to be done by this 531 PCC for the adjacency (198.51.100.2 - 198.51.100.1). 533 5.5.1.3. Redundant PCEs 535 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 536 between the stateful PCEs. The SR SIDs allocated by a PCE MUST also 537 be synchronized among PCEs for PCECC SR state synchronization. Note 538 that the SR SIDs are independent to the PCECC-SR LSP, and remains 539 intact till any topology change. The redundant PCEs MUST have a 540 common view of all SR SIDs allocated in the domain. 542 5.5.1.4. Re Delegation and Cleanup 544 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the action 545 needed for CCIs for the Basic PCECC LSP on this terminated session. 546 Similarly actions should be applied for the SR SID as well. 548 5.5.1.5. Synchronization of Label Allocations 550 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the 551 synchronization of Central Controller's Instructions (CCI) via LSP 552 state synchronization as described in [RFC8231] and [RFC8232]. Same 553 procedures should be applied for SR SIDs as well. 555 5.5.1.6. PCC Based Allocations 557 The PCE can request the PCC to allocate the label/SID using the 558 PCInitiate message. The C flag in the CCI object is set to 1 to 559 indicate that the allocation needs to be done by the PCC. The PCC 560 would allocate the SID/Label/Index and would report to the PCE using 561 the PCRpt message. 563 If the value of the SID/Label/Index is 0 and the C flag is set, it 564 indicates that the PCE is requesting the allocation to be done by the 565 PCC. If the SID/Label/Index is 'n' and the C flag is set in the CCI 566 object, it indicates that the PCE requests a specific value 'n' for 567 the SID/Label/Index. If the allocation is successful, the PCC should 568 report via PCRpt message with the CCI object. Else, it MUST send a 569 PCErr message with Error-Type = TBD ("PCECC failure") and Error Value 570 = TBD ("Invalid CCI"). If the value of the the SID/Label/Index in 571 the CCI object is valid, but the PCC is unable to allocate it, it 572 MUST send a PCErr message with Error-Type = TBD ("PCECC failure") and 573 Error Value = TBD ("Unable to allocate the specified CCI"). 575 If the PCC wishes to withdrawn or modify the previously assigned 576 label/SID, it MUST send a PCRpt message without any SID/Label/Index 577 or with the SID/Label/Index containing the new value respectively in 578 the CCI object. The PCE would further trigger the removal of the 579 central controller instruction as per this document. 581 5.5.1.7. Binding SID 583 A PCE as a central controller can allocate and provision the 584 node/prefix/adjacency label (SID) via PCEP. One such SID is binding 585 SID as described in [I-D.sivabalan-pce-binding-label-sid], the PCECC 586 mechanism can also be used to allocate the binding SID as described 587 in this section. 589 A procedure for binding label/SID allocation is described in 590 [I-D.ietf-pce-pcep-extension-for-pce-controller] and is applicable 591 for all path setup types (including SR paths). 593 6. PCEP messages 595 As defined in [RFC5440], a PCEP message consists of a common header 596 followed by a variable-length body made of a set of objects that can 597 be either mandatory or optional. An object is said to be mandatory 598 in a PCEP message when the object must be included for the message to 599 be considered valid. For each PCEP message type, a set of rules is 600 defined that specify the set of objects that the message can carry. 601 An implementation MUST form the PCEP messages using the object 602 ordering specified in this document. 604 6.1. Central Control Instructions 606 6.1.1. The PCInitiate message 608 The PCInitiate Message defined in [RFC8281] and extended in 609 [I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended 610 to support SR based central control instructions. 612 The format of the extended PCInitiate message is as follows: 614 ::= 615 616 Where: 617 is defined in [RFC5440] 619 ::= 620 [] 622 ::= 623 (| 624 | 625 ) 627 ::= 628 ( 629 )| 630 ( 631 ) 633 ::= 634 [] 636 Where: 637 and 638 are as per 639 [RFC8281]. 641 The LSP and SRP object is defined in [RFC8231]. 643 When PCInitiate message is used to distribute SR SIDs, the SRP, FEC 644 and CCI objects MUST be present. The error handling for missing SRP 645 or CCI object is as per 646 [I-D.ietf-pce-pcep-extension-for-pce-controller]. If the FEC object 647 is missing, the receiving PCC MUST send a PCErr message with Error- 648 type=6 (Mandatory Object missing) and Error-value=TBD (FEC object 649 missing). 651 To cleanup the SRP object must set the R (remove) bit. 653 6.1.2. The PCRpt message 655 The PCRpt message can be used to report the SR instructions received 656 from the central controller (PCE) during the state synchronization 657 phase. 659 The format of the PCRpt message is as follows: 661 ::= 662 663 Where: 665 ::= [] 667 ::= (| 668 ) 670 ::= [] 671 672 674 ::= [] 675 ( 676 )| 677 ( 678 ) 680 ::= 681 [] 683 Where: 684 is as per [RFC8231] and the LSP and SRP object are 685 also defined in [RFC8231]. 687 When PCRpt message is used to report the label map allocations, the 688 FEC and CCI objects MUST be present. The error handling for CCI 689 object is as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. 690 If the FEC object is missing, the receiving PCC MUST send a PCErr 691 message with Error-type=6 (Mandatory Object missing) and Error- 692 value=TBD (FEC object missing). 694 7. PCEP Objects 696 7.1. OPEN Object 698 7.1.1. PCECC Capability sub-TLV 700 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 701 CAPABILITY TLV. 703 A new S-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SR: 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Type=TBD | Length=4 | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Flags |S| 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 S (PCECC-SR-CAPABILITY - 1 bit): If set to 1 by a PCEP speaker, it 714 indicates that the PCEP speaker is capable for PCECC-SR capability 715 and PCE would allocate node and Adj label on this session. 717 7.2. PATH-SETUP-TYPE TLV 719 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. PST = TBD is used 720 when Path is setup via PCECC SR mode. 722 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD indicates that this 723 LSP was setup via a PCECC-SR based mechanism where either the SIDs 724 were allocated/instructed by PCE via PCECC mechanism. 726 7.3. CCI Object 728 The Central Control Instructions (CCI) Object is used by the PCE to 729 specify the forwarding instructions is defined in 730 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 731 defines another object-type for SR purpose. 733 CCI Object-Type is TBD for SR as below - 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | CC-ID | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | MT-ID | Algorithm | Flags |C|N|E|V|L|O| 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 // SID/Label/Index (variable) // 743 +---------------------------------------------------------------+ 744 | | 745 // Optional TLV // 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 The field CC-ID is as described in 749 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following new 750 fields are defined for CCI Object-Type TBD - 752 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 754 Algorithm: Single octet identifying the algorithm the SID is 755 associated with. See [I-D.ietf-ospf-segment-routing-extensions]. 757 Flags: is used to carry any additional information pertaining to the 758 CCI. The O bit was defined in 759 [I-D.ietf-pce-pcep-extension-for-pce-controller], this document 760 further defines following bits- 762 * L-Bit (Local/Global): If set, then the value/index carried by 763 the CCI object has local significance. If not set, then the 764 value/index carried by this object has global significance. 766 * V-Bit (Value/Index): If set, then the CCI carries an absolute 767 value. If not set, then the CCI carries an index. 769 * E-Bit (Explicit-Null): If set, any upstream neighbor of the 770 node that advertised the SID MUST replace the SID with the 771 Explicit-NULL label (0 for IPv4) before forwarding the packet. 773 * N-Bit (No-PHP): If set, then the penultimate hop MUST NOT pop 774 the SID before delivering packets to the node that advertised 775 the SID. 777 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 778 that the allocation needs to be done by the PCC for this 779 central controller instruction. A PCE set this bit to request 780 the PCC to make an allocation from its SR label/ID space. A 781 PCC would set this bit to indicate that it has allocated the 782 CC-ID and report it to the PCE. 784 SID/Label/Index: According to the V and L flags, it contains either: 786 A 32-bit index defining the offset in the SID/Label space 787 advertised by this router. 789 A 24-bit label where the 20 rightmost bits are used for 790 encoding the label value. 792 7.4. FEC Object 794 The FEC Object is used to specify the FEC information and MAY be 795 carried within PCInitiate or PCRpt message. 797 FEC Object-Class is TBD. 799 FEC Object-Type is 1 'IPv4 Node ID'. 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | IPv4 Node ID | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 FEC Object-Type is 2 'IPv6 Node ID'. 809 0 1 2 3 810 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 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | | 813 // IPv6 Node ID (16 bytes) // 814 | | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 FEC Object-Type is 3 'IPv4 Adjacency'. 819 0 1 2 3 820 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 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Local IPv4 address | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Remote IPv4 address | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 FEC Object-Type is 4 'IPv6 Adjacency'. 829 0 1 2 3 830 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 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | 833 // Local IPv6 address (16 bytes) // 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | | 837 // Remote IPv6 address (16 bytes) // 838 | | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 FEC Object-Type is 5 'Unnumbered Adjacency with IPv4 NodeIDs'. 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Local Node-ID | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Local Interface ID | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Remote Node-ID | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Remote Interface ID | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 FEC Object-Type is 6 'Linklocal IPv6 Adjacency'. 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 // Local IPv6 address (16 octets) // 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Local Interface ID | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 // Remote IPv6 address (16 octets) // 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Remote Interface ID | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 The FEC objects are as follows: 871 IPv4 Node ID: where IPv4 Node ID is specified as an IPv4 address of 872 the Node. FEC Object-type is 1, and the Object-Length is 4 in this 873 case. 875 IPv6 Node ID: where IPv6 Node ID is specified as an IPv6 address of 876 the Node. FEC Object-type is 2, and the Object-Length is 16 in this 877 case. 879 IPv4 Adjacency: where Local and Remote IPv4 address is specified as 880 pair of IPv4 address of the adjacency. FEC Object-type is 3, and the 881 Object-Length is 8 in this case. 883 IPv6 Adjacency: where Local and Remote IPv6 address is specified as 884 pair of IPv6 address of the adjacency. FEC Object-type is 4, and the 885 Object-Length is 32 in this case. 887 Unnumbered Adjacency with IPv4 NodeID: where a pair of Node ID / 888 Interface ID tuples is used. FEC Object-type is 5, and the Object- 889 Length is 16 in this case. 891 Linklocal IPv6 Adjacency: where a pair of (global IPv6 address, 892 interface ID) tuples is used. FEC object-type is 6, and the Object- 893 Length is 40 in this case. 895 8. Implementation Status 897 [Note to the RFC Editor - remove this section before publication, as 898 well as remove the reference to RFC 7942.] 900 This section records the status of known implementations of the 901 protocol defined by this specification at the time of posting of this 902 Internet-Draft, and is based on a proposal described in [RFC7942]. 903 The description of implementations in this section is intended to 904 assist the IETF in its decision processes in progressing drafts to 905 RFCs. Please note that the listing of any individual implementation 906 here does not imply endorsement by the IETF. Furthermore, no effort 907 has been spent to verify the information presented here that was 908 supplied by IETF contributors. This is not intended as, and must not 909 be construed to be, a catalog of available implementations or their 910 features. Readers are advised to note that other implementations may 911 exist. 913 According to [RFC7942], "this will allow reviewers and working groups 914 to assign due consideration to documents that have the benefit of 915 running code, which may serve as evidence of valuable experimentation 916 and feedback that have made the implemented protocols more mature. 917 It is up to the individual working groups to use this information as 918 they see fit". 920 8.1. Huawei's Proof of Concept based on ONOS 922 The PCE function was developed in the ONOS open source platform. 923 This extension was implemented on a private version as a proof of 924 concept for PCECC. 926 o Organization: Huawei 928 o Implementation: Huawei's PoC based on ONOS 929 o Description: PCEP as a southbound plugin was added to ONOS. To 930 support PCECC-SR, an earlier version of this I-D was implemented. 931 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 933 o Maturity Level: Prototype 935 o Coverage: Partial 937 o Contact: satishk@huawei.com 939 9. Security Considerations 941 The security considerations described in 942 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the 943 extensions described in this document. 945 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 946 be activated on authenticated and encrypted sessions across PCEs and 947 PCCs belonging to the same administrative authority, using Transport 948 Layer Security (TLS) [RFC8253] as per the recommendations and best 949 current practices in [RFC7525] (unless explicitly set aside in 950 [RFC8253]). 952 10. Manageability Considerations 954 10.1. Control of Function and Policy 956 A PCE or PCC implementation SHOULD allow to configure to enable/ 957 disable PCECC SR capability as a global configuration. 959 10.2. Information and Data Models 961 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 962 PCECC SR capability status. 964 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 965 enable/disable PCECC SR capability. 967 10.3. Liveness Detection and Monitoring 969 Mechanisms defined in this document do not imply any new liveness 970 detection and monitoring requirements in addition to those already 971 listed in [RFC5440]. 973 10.4. Verify Correct Operations 975 Mechanisms defined in this document do not imply any new operation 976 verification requirements in addition to those already listed in 977 [RFC5440] and [RFC8231]. 979 10.5. Requirements On Other Protocols 981 PCEP extensions defined in this document do not put new requirements 982 on other protocols. 984 10.6. Impact On Network Operations 986 PCEP implementation SHOULD allow a limit to be placed on the rate of 987 PCLabelUpd messages sent by PCE and processed by PCC. It SHOULD also 988 allow sending a notification when a rate threshold is reached. 990 11. IANA Considerations 992 11.1. PCECC-CAPABILITY sub-TLV 994 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 995 CAPABILITY sub-TLV and requests that IANA creates a registry to 996 manage the value of the PCECC-CAPABILITY sub-TLV's Flag field. New 997 values are to be assigned by Standards Action [RFC8126]. Each bit 998 should be tracked with the following qualities: 1000 o Bit number (counting from bit 0 as the most significant bit) 1002 o Capability description 1004 o Defining RFC 1006 IANA is requested to allocate a new bit in the PCECC-CAPABILITY sub- 1007 TLV Flag Field registry, as follows: 1009 Bit Description Reference 1010 31 S((PCECC-SR-CAPABILITY)) This document 1012 11.2. New Path Setup Type Registry 1014 [RFC8408] created a sub-registry within the "Path Computation Element 1015 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1016 IANA is requested to allocate a new code point within this registry, 1017 as follows: 1019 Value Description Reference 1020 TBD Traffic engineering path is This document 1021 setup using PCECC-SR mode 1023 11.3. PCEP Object 1025 IANA is requested to allocate new code-point for the new FEC object 1026 in "PCEP Objects" sub-registry as follows: 1028 Object-Class Value Name Reference 1029 TBD FEC This document 1030 Object-Type : 1 IPv4 Node ID 1031 Object-Type : 2 IPv6 Node ID 1032 Object-Type : 3 IPv4 Adjacency 1033 Object-Type : 4 IPv6 Adjacency 1034 Object-Type : 5 Unnumbered Adjacency 1035 with IPv4 NodeID 1036 Object-Type : 6 Linklocal IPv6 Adjacency 1038 11.4. PCEP-Error Object 1040 IANA is requested to allocate new error types and error values within 1041 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1042 PCEP Numbers registry for the following errors: 1044 Error-Type Meaning 1045 ---------- ------- 1046 6 Mandatory Object missing. 1048 Error-value = TBD : FEC object missing 1049 19 Invalid operation. 1051 Error-value = TBD : SR capability was 1052 not advertised 1054 12. Acknowledgments 1056 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1057 Avantika for their useful comments and suggestions. 1059 13. References 1061 13.1. Normative References 1063 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1064 Requirement Levels", BCP 14, RFC 2119, 1065 DOI 10.17487/RFC2119, March 1997, 1066 . 1068 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1069 (TE) Extensions to OSPF Version 2", RFC 3630, 1070 DOI 10.17487/RFC3630, September 2003, 1071 . 1073 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1074 Support of Generalized Multi-Protocol Label Switching 1075 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1076 . 1078 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1079 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1080 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1081 . 1083 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1084 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1085 2008, . 1087 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1088 in Support of Generalized Multi-Protocol Label Switching 1089 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1090 . 1092 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1093 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1094 DOI 10.17487/RFC5440, March 2009, 1095 . 1097 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1098 Hardwick, "Path Computation Element Communication Protocol 1099 (PCEP) Management Information Base (MIB) Module", 1100 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1101 . 1103 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1104 "Recommendations for Secure Use of Transport Layer 1105 Security (TLS) and Datagram Transport Layer Security 1106 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1107 2015, . 1109 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1110 S. Ray, "North-Bound Distribution of Link-State and 1111 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1112 DOI 10.17487/RFC7752, March 2016, 1113 . 1115 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1116 Code: The Implementation Status Section", BCP 205, 1117 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1118 . 1120 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1121 Writing an IANA Considerations Section in RFCs", BCP 26, 1122 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1123 . 1125 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1126 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1127 May 2017, . 1129 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1130 Computation Element Communication Protocol (PCEP) 1131 Extensions for Stateful PCE", RFC 8231, 1132 DOI 10.17487/RFC8231, September 2017, 1133 . 1135 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1136 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1137 Path Computation Element Communication Protocol (PCEP)", 1138 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1139 . 1141 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1142 Computation Element Communication Protocol (PCEP) 1143 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1144 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1145 . 1147 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1148 Hardwick, "Conveying Path Setup Type in PCE Communication 1149 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1150 July 2018, . 1152 13.2. Informative References 1154 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1155 Label Switching Architecture", RFC 3031, 1156 DOI 10.17487/RFC3031, January 2001, 1157 . 1159 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1160 Element (PCE)-Based Architecture", RFC 4655, 1161 DOI 10.17487/RFC4655, August 2006, 1162 . 1164 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1165 Margaria, "Requirements for GMPLS Applications of PCE", 1166 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1167 . 1169 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1170 Computation Element Architecture", RFC 7399, 1171 DOI 10.17487/RFC7399, October 2014, 1172 . 1174 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1175 Application-Based Network Operations", RFC 7491, 1176 DOI 10.17487/RFC7491, March 2015, 1177 . 1179 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1180 and D. Dhody, "Optimizations of Label Switched Path State 1181 Synchronization Procedures for a Stateful PCE", RFC 8232, 1182 DOI 10.17487/RFC8232, September 2017, 1183 . 1185 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1186 Architecture for Use of PCE and the PCE Communication 1187 Protocol (PCEP) in a Network with Central Control", 1188 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1189 . 1191 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1192 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1193 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1194 July 2018, . 1196 [I-D.ietf-teas-pcecc-use-cases] 1197 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1198 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1199 Gulida, "The Use Cases for Path Computation Element (PCE) 1200 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1201 use-cases-04 (work in progress), July 2019. 1203 [I-D.ietf-pce-pcep-yang] 1204 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1205 YANG Data Model for Path Computation Element 1206 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1207 yang-12 (work in progress), July 2019. 1209 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1210 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 1211 and Protocol Extensions for Using PCE as a Central 1212 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1213 extension-for-pce-controller-02 (work in progress), July 1214 2019. 1216 [I-D.ietf-pce-segment-routing] 1217 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1218 and J. Hardwick, "PCEP Extensions for Segment Routing", 1219 draft-ietf-pce-segment-routing-16 (work in progress), 1220 March 2019. 1222 [I-D.ietf-isis-segment-routing-extensions] 1223 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1224 Gredler, H., and B. Decraene, "IS-IS Extensions for 1225 Segment Routing", draft-ietf-isis-segment-routing- 1226 extensions-25 (work in progress), May 2019. 1228 [I-D.ietf-ospf-segment-routing-extensions] 1229 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1230 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1231 Extensions for Segment Routing", draft-ietf-ospf-segment- 1232 routing-extensions-27 (work in progress), December 2018. 1234 [I-D.litkowski-pce-state-sync] 1235 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 1236 Stateful Path Computation Element (PCE) Communication 1237 Procedures.", draft-litkowski-pce-state-sync-06 (work in 1238 progress), July 2019. 1240 [I-D.dhodylee-pce-pcep-ls] 1241 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 1242 Distribution of Link-State and TE Information.", draft- 1243 dhodylee-pce-pcep-ls-13 (work in progress), February 2019. 1245 [I-D.ietf-spring-segment-routing-mpls] 1246 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1247 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1248 data plane", draft-ietf-spring-segment-routing-mpls-22 1249 (work in progress), May 2019. 1251 [I-D.sivabalan-pce-binding-label-sid] 1252 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1253 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1254 in PCE-based Networks.", draft-sivabalan-pce-binding- 1255 label-sid-07 (work in progress), July 2019. 1257 Appendix A. Contributor Addresses 1259 Dhruv Dhody 1260 Huawei Technologies 1261 Divyashree Techno Park, Whitefield 1262 Bangalore, Karnataka 560066 1263 India 1265 EMail: dhruv.ietf@gmail.com 1267 Satish Karunanithi 1268 Huawei Technologies 1269 Divyashree Techno Park, Whitefield 1270 Bangalore, Karnataka 560066 1271 India 1273 EMail: satishk@huawei.com 1275 Adrian Farrel 1276 Juniper Networks, Inc 1277 UK 1279 EMail: adrian@olddog.co.uk 1281 Xuesong Geng 1282 Huawei Technologies 1283 China 1285 Email: gengxuesong@huawei.com 1287 Udayasree Palle 1289 EMail: udayasreereddy@gmail.com 1291 Katherine Zhao 1292 Huawei Technologies 1293 2330 Central Expressway 1294 Santa Clara, CA 95050 1295 USA 1297 EMail: katherine.zhao@huawei.com 1299 Boris Zhang 1300 Telus Ltd. 1301 Toronto 1302 Canada 1304 EMail: boris.zhang@telus.com 1305 Alex Tokar 1306 Cisco Systems 1307 Slovak Republic 1309 EMail: atokar@cisco.com 1311 Authors' Addresses 1313 Quintin Zhao 1314 Huawei Technologies 1315 125 Nagog Technology Park 1316 Acton, MA 01719 1317 USA 1319 EMail: quintinzhao@gmail.com 1321 Zhenbin Li 1322 Huawei Technologies 1323 Huawei Bld., No.156 Beiqing Rd. 1324 Beijing 100095 1325 China 1327 EMail: lizhenbin@huawei.com 1329 Mahendra Singh Negi 1330 Huawei Technologies 1331 Divyashree Techno Park, Whitefield 1332 Bangalore, Karnataka 560066 1333 India 1335 EMail: mahendrasingh@huawei.com 1337 Chao Zhou 1338 Cisco Systems 1340 EMail: choa.zhou@cisco.com