idnits 2.17.1 draft-zhao-pce-pcep-extension-pce-controller-sr-07.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 13, 2020) is 1355 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 (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-05 == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-05 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 == Outdated reference: A later version (-16) exists of draft-ietf-pce-binding-label-sid-03 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-08 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-15 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-03 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 14, 2021 M. Negi 6 RtBrick India 7 Q. Zhao 8 Etheric Networks 9 C. Zhou 10 Cisco Systems 11 July 13, 2020 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of SR-LSPs 15 draft-zhao-pce-pcep-extension-pce-controller-sr-07 17 Abstract 19 The Path Computation Element (PCE) is a core component of Software- 20 Defined Networking (SDN) systems. It can compute optimal paths for 21 traffic across a network and can also update the paths to reflect 22 changes in the network or traffic demands. 24 PCE was developed to derive paths for MPLS Label Switched Paths 25 (LSPs), which are supplied to the head end of the LSP using the Path 26 Computation Element Communication Protocol (PCEP). But SDN has a 27 broader applicability than signaled (G)MPLS traffic-engineered (TE) 28 networks, and the PCE may be used to determine paths in a range of 29 use cases. PCEP has been proposed as a control protocol for use in 30 these environments to allow the PCE to be fully enabled as a central 31 controller. 33 A PCE-based central controller (PCECC) can simplify the processing of 34 a distributed control plane by blending it with elements of SDN and 35 without necessarily completely replacing it. Thus, the LSP can be 36 calculated/setup/initiated and the label forwarding entries can also 37 be downloaded through a centralized PCE server to each network 38 devices along the path while leveraging the existing PCE technologies 39 as much as possible. 41 This document specifies the procedures and PCEP protocol extensions 42 when a PCE-based controller is also responsible for configuring the 43 forwarding actions on the routers, in addition to computing the paths 44 for packet flows in a segment routing network and telling the edge 45 routers what instructions to attach to packets as they enter the 46 network. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at https://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on January 14, 2021. 65 Copyright Notice 67 Copyright (c) 2020 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (https://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 3. PCECC SR . . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 87 5. Procedures for Using the PCE as the Central Controller 88 (PCECC) in Segment Routing . . . . . . . . . . . . . . . . . 6 89 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 90 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 91 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 92 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 7 93 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 94 5.5.1. PCECC Segment Routing (SR) . . . . . . . . . . . . . 8 95 5.5.1.1. PCECC SR Node/Prefix SID allocation . . . . . . . 8 96 5.5.1.2. PCECC SR Adjacency Label allocation . . . . . . . 10 97 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 12 98 5.5.1.4. Re Delegation and Cleanup . . . . . . . . . . . . 12 99 5.5.1.5. Synchronization of Label Allocations . . . . . . 13 100 5.5.1.6. PCC Based Allocations . . . . . . . . . . . . . . 13 101 5.5.1.7. Binding SID . . . . . . . . . . . . . . . . . . . 13 102 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 14 103 6.1. Central Control Instructions . . . . . . . . . . . . . . 14 104 6.1.1. The PCInitiate message . . . . . . . . . . . . . . . 14 105 6.1.2. The PCRpt message . . . . . . . . . . . . . . . . . . 15 106 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 16 107 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 16 108 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 16 109 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 17 110 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 17 111 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 19 112 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 113 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 22 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 115 10. Manageability Considerations . . . . . . . . . . . . . . . . 23 116 10.1. Control of Function and Policy . . . . . . . . . . . . . 23 117 10.2. Information and Data Models . . . . . . . . . . . . . . 23 118 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 23 119 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 23 120 10.5. Requirements On Other Protocols . . . . . . . . . . . . 23 121 10.6. Impact On Network Operations . . . . . . . . . . . . . . 23 122 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 123 11.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 24 124 11.2. New Path Setup Type Registry . . . . . . . . . . . . . . 24 125 11.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 24 126 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 24 127 11.5. CCI Object Flag Field for SR . . . . . . . . . . . . . . 25 128 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 129 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 130 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 131 13.2. Informative References . . . . . . . . . . . . . . . . . 28 132 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 31 133 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 31 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 136 1. Introduction 138 The Path Computation Element (PCE) [RFC4655] was developed to offload 139 path computation function from routers in an MPLS traffic-engineered 140 network. Since then, the role and function of the PCE has grown to 141 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 142 delegated control [RFC8231] and PCE-initiated use of network 143 resources [RFC8281]. 145 According to [RFC7399], Software-Defined Networking (SDN) refers to a 146 separation between the control elements and the forwarding components 147 so that software running in a centralized system, called a 148 controller, can act to program the devices in the network to behave 149 in specific ways. A required element in an SDN architecture is a 150 component that plans how the network resources will be used and how 151 the devices will be programmed. It is possible to view this 152 component as performing specific computations to place traffic flows 153 within the network given knowledge of the availability of network 154 resources, how other forwarding devices are programmed, and the way 155 that other flows are routed. This is the function and purpose of a 156 PCE, and the way that a PCE integrates into a wider network control 157 system (including an SDN system) is presented in [RFC7491]. 159 In early PCE implementations, where the PCE was used to derive paths 160 for MPLS Label Switched Paths (LSPs), paths were requested by network 161 elements (known as Path Computation Clients (PCCs)), and the results 162 of the path computations were supplied to network elements using the 163 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 164 This protocol was later extended to allow a PCE to send unsolicited 165 requests to the network for LSP establishment [RFC8281]. 167 [RFC8283] introduces the architecture for PCE as a central controller 168 as an extension of the architecture described in [RFC4655] and 169 assumes the continued use of PCEP as the protocol used between PCE 170 and PCC. [RFC8283] further examines the motivations and 171 applicability for PCEP as a Southbound Interface (SBI), and 172 introduces the implications for the protocol. 173 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 174 architecture. 176 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 177 procedures and PCEP protocol extensions for using the PCE as the 178 central controller for static LSPs, where LSPs can be provisioned as 179 explicit label instructions at each hop on the end-to-end path. 181 Segment Routing (SR) technology leverages the source routing and 182 tunneling paradigms. A source node can choose a path without relying 183 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 184 is specified as a set of "segments" advertised by link-state routing 185 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to SR 186 architecture. The corresponding IS-IS and OSPF extensions are 187 specified in [RFC8667] and [RFC8665] , respectively. It relies on a 188 series of forwarding instructions being placed in the header of a 189 packet. The segment routing architecture supports operations that 190 can be used to steer packet flows in a network, thus providing a form 191 of traffic engineering. [RFC8664] specify the SR specific PCEP 192 extensions. 194 PCECC may further use PCEP protocol for SR SID (Segment Identifier) 195 distribution on the SR nodes with some benefits. 197 This document specifies the procedures and PCEP protocol extensions 198 when a PCE-based controller is also responsible for configuring the 199 forwarding actions on the routers (SR SID distribution in this case), 200 in addition to computing the paths for packet flows in a segment 201 routing network and telling the edge routers what instructions to 202 attach to packets as they enter the network. 204 Only SR using MPLS dataplane (SR-MPLS) is in scope of this document. 205 Refer [I-D.dhody-pce-pcep-extension-pce-controller-srv6] for PCECC- 206 SRv6. 208 1.1. Requirements Language 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 212 "OPTIONAL" in this document are to be interpreted as described in BCP 213 14 [RFC2119] [RFC8174] when, and only when, they appear in all 214 capitals, as shown here. 216 2. Terminology 218 Terminologies used in this document is same as described in the draft 219 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 221 3. PCECC SR 223 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 224 compute, update or initiate SR-TE paths. An ingress node of an SR-TE 225 path appends all outgoing packets with a list of MPLS labels (SIDs). 226 This is encoded in SR-ERO subobject, capable of carrying a label 227 (SID) as well as the identity of the node/adjacency label (SID). 229 The notion of segment and SID is defined in [RFC8402], which fits the 230 MPLS architecture [RFC3031] as the label which is managed by a local 231 allocation process of LSR (similarly to other MPLS signaling 232 protocols) [RFC8660]. The SR information such as node/adjacency 233 label (SID) is flooded via IGP as specified in [RFC8667] and 234 [RFC8665]. 236 As per [RFC8283], PCE as a central controller can allocate and 237 provision the node/prefix/adjacency label (SID) via PCEP. 239 Rest of the processing is similar to existing stateful PCE with SR 240 mechanism. 242 For the purpose of this document, it is assumed that label range to 243 be used by a PCE is set on both PCEP peers. Further, a global label 244 range is assumed to be set on all PCEP peers in the SR domain. This 245 document also allow a case where the label space is maintained by PCC 246 itself, and the labels are allocated by the PCC, in this case, the 247 PCE should request the allocation from PCC as described in 248 Section 5.5.1.6. 250 4. PCEP Requirements 252 Following key requirements for PCECC-SR should be considered when` 253 designing the PCECC based solution: 255 o PCEP speaker supporting this draft needs to have the capability to 256 advertise its PCECC-SR capability to its peers. 258 o PCEP speaker not supporting this draft needs to be able to reject 259 PCECC-SR related message with a reason code that indicates no 260 support for PCECC. 262 o PCEP procedures needs to provide a means to update (or cleanup) 263 the label- map entry to the PCC. 265 o PCEP procedures needs to provide a means to synchronize the SR 266 labels allocations between PCE to PCC in the PCEP messages. 268 o PCEP procedures MAY could allow for PCC based label allocations. 270 5. Procedures for Using the PCE as the Central Controller (PCECC) in 271 Segment Routing 273 5.1. Stateful PCE Model 275 Active stateful PCE is described in [RFC8231]. PCE as a central 276 controller (PCECC) reuses existing Active stateful PCE mechanism as 277 much as possible to control the LSP. 279 5.2. New LSP Functions 281 Several new functions are required in PCEP to support PCECC as 282 described in [I-D.ietf-pce-pcep-extension-for-pce-controller]. This 283 document reuses the existing messages to support PCECC-SR. 285 The PCEP messages PCRpt, PCInitiate, PCUpd are used to send LSP 286 Reports, LSP setup and LSP update respectively. The extended 287 PCInitiate message described in 288 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 289 or cleanup central controller's instructions (CCIs) (SR SID in scope 290 of this document). The extended PCRpt message described in 291 [I-D.ietf-pce-pcep-extension-for-pce-controller] is also used to 292 report the CCIs (SR SIDs) from PCC to PCE. 294 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 295 called CCI for the encoding of central controller's instructions. 296 This document extends the CCI by defining a new object-type for 297 segment routing. The PCEP messages are extended in this document to 298 handle the PCECC operations for SR. 300 5.3. PCECC Capability Advertisement 302 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 303 advertise their support of PCECC extensions. A PCEP Speaker includes 304 the "PCECC Capability" sub-TLV, described in 305 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 307 A new S-bit is added in PCECC-CAPABILITY sub-TLV to indicate support 308 for PCECC-SR. A PCC MUST set S-bit in PCECC-CAPABILITY sub-TLV and 309 include SR-PCE-CAPABILITY sub-TLV ([RFC8664]) in OPEN Object (inside 310 the the PATH-SETUP-TYPE-CAPABILITY TLV) to support the PCECC SR 311 extensions defined in this document. If S-bit is set in PCECC- 312 CAPABILITY sub-TLV and SR-PCE-CAPABILITY sub-TLV is not advertised in 313 OPEN Object, PCE SHOULD send a PCErr message with Error-Type=19 314 (Invalid Operation) and Error-value=TBD4 (SR capability was not 315 advertised) and terminate the session. 317 5.4. PCEP session IP address and TEDB Router ID 319 PCE may construct its TEDB by participating in the IGP ([RFC3630] and 320 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 321 alternative is offered by BGP-LS [RFC7752] and 322 [I-D.dhodylee-pce-pcep-ls]. 324 PCEP [RFC5440] speaker MAY use any IP address while creating a TCP 325 session. It is important to link the session IP address with the 326 Router ID in TEDB for successful PCECC operations. 328 During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping 329 information. Thus a PCC includes the "Node Attributes TLV" 330 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 331 in the OPEN Object for this purpose. [RFC7752] describes the usage 332 as auxiliary Router-IDs that the IGP might be using, e.g., for TE 333 purposes. If there are more than one auxiliary Router-ID of a given 334 type, then multiple TLVs are used to encode them. 336 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 337 address is directly used for the mapping purpose. 339 5.5. LSP Operations 341 The PCEP messages pertaining to PCECC-SR MUST include PATH-SETUP-TYPE 342 TLV [RFC8408] with PST=TBD2 in the SRP object to clearly identify the 343 PCECC-SR LSP is intended. 345 5.5.1. PCECC Segment Routing (SR) 347 Segment Routing (SR) as described in [RFC8402] depends on "segments" 348 that are advertised by Interior Gateway Protocols (IGPs). The SR- 349 node allocates and advertises the SID (node, adj etc) and flood via 350 the IGP. This document proposes a new mechanism where PCE allocates 351 the SID (label/index/SID) centrally and uses PCEP to advertise the 352 SID. In some deployments PCE (and PCEP) are better suited than IGP 353 because of centralized nature of PCE and direct TCP based PCEP 354 session to the node. 356 5.5.1.1. PCECC SR Node/Prefix SID allocation 358 Each node (PCC) is allocated a node-SID by the PCECC. The PCECC 359 sends PCInitiate message to update the label map of each node to all 360 the nodes in the domain. The TE router ID is determined from the 361 TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV 362 [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. 364 It is RECOMMENDED that PCEP session with PCECC SR capability to use a 365 different session IP address during TCP session establishment than 366 the node Router ID in TEDB, to make sure that the PCEP session does 367 not get impacted by the SR Node/Prefix Label maps (Section 5.4). 369 If a node (PCC) receives a PCInitiate message with a CCI encoding a 370 SID, out of the range set aside for the SRGB, it MUST send a PCErr 371 message with Error-type=TBD (PCECC failure) and Error-value=TBD 372 (Label out of range) (defined in 373 [I-D.ietf-pce-pcep-extension-for-pce-controller]) and MUST include 374 the SRP object to specify the error is for the corresponding label 375 update via PCInitiate message. 377 On receiving the label map, each node (PCC) uses the local 378 information to determine the next-hop and download the label 379 forwarding instructions accordingly. The PCInitiate message in this 380 case MUST NOT have LSP object but uses the new FEC object defined in 381 this document. 383 +---------+ +-------+ 384 |PCC | | PCE | 385 |192.0.2.3| +-------+ 386 +------| | | 387 | PCC +---------+ | 388 | 192.0.2.2| | | 389 +------| | | | 390 |PCC +----------+ | | 391 |192.0.2.1| | | | 392 +---------+ | | | 393 | | | | 394 |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map 395 | | | CC-ID=X | update 396 |------- PCRpt,CC-ID=X --------------------------->| CCI 397 |Find | | | 398 |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map 399 |locally| | CC-ID=Y | update 400 | |----- PCRpt,CC-ID=Y -------------------->| CCI 401 | | | | 402 | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map 403 | | | CC-ID=Z | update 404 | | |---- PCRpt,CC-ID=Z -------------->| CCI 405 | | | | 407 The forwarding behavior and the end result is similar to IGP based 408 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 409 ECMP-aware shortest-path forwarding of the packet towards the related 410 node. 412 PCE relies on the Node/Prefix Label cleanup using the same PCInitiate 413 message. 415 The above example Figure 1 depict FEC and PCEP speakers that uses 416 IPv4 address. Similarly IPv6 address (such as 2001:DB8::1) can be 417 used during PCEP session establishment as well in FEC object as 418 described in this specification. 420 In case where the label allocation are made by the PCC itself (see 421 Section 5.5.1.6), the PCE could still request an allocation to be 422 made by the PCC, and where the PCC would send a PCRpt with the 423 allocated label encoded in the CC-ID object as shown below - 424 +---------+ +-------+ 425 |PCC | | PCE | 426 |192.0.2.3| +-------+ 427 +------| | | 428 | PCC +---------+ | 429 | 192.0.2.2| | | 430 +------| | | | 431 |PCC +----------+ | | 432 |192.0.2.1| | | | 433 +---------+ | | | 434 | | | | 435 |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map 436 | | | CC-ID=X,C=1 | request 437 |------- PCRpt,CC-ID=X,Label ---------------------->| CCI 438 |Find | | | 439 |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map 440 |locally| | CC-ID=Y,C=0,Label | update 441 | |----- PCRpt,CC-ID=Y -------------------->| CCI 442 | | | | 443 | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map 444 | | | CC-ID=Z,C=0,Label | update 445 | | |---- PCRpt,CC-ID=Z -------------->| CCI 446 | | | | 448 It should be noted that in this example, the request is made to the 449 node 192.0.2.1 with C bit set in the CCI object to indicate that the 450 allocation needs to be done by this PCC and it responds with the 451 allocated label/SID to the PCE. The PCE would further inform the 452 other PCCs in the network about the allocation without setting the C 453 bit. 455 5.5.1.2. PCECC SR Adjacency Label allocation 457 [RFC8664] extends PCEP to allow a stateful PCE to compute and 458 initiate SR-TE paths, as well as a PCC to request a path subject to 459 certain constraint(s) and optimization criteria in SR networks. 461 For PCECC SR, apart from node-SID, Adj-SID is used where each 462 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 463 PCInitiate message to update the label map of each Adj to the 464 corresponding nodes in the domain. Each node (PCC) download the 465 label forwarding instructions accordingly. Similar to SR Node/Prefix 466 Label allocation, the PCInitiate message in this case MUST NOT have 467 LSP object but uses the new FEC object defined in this document. 469 +---------+ +-------+ 470 |PCC | | PCE | 471 |192.0.2.3| +-------+ 472 +------| | | 473 | PCC +---------+ | 474 | 192.0.2.2| | | 475 +------| | | | 476 |PCC +----------+ | | 477 |192.0.2.1| | | | 478 +---------+ | | | 479 | | | | 480 |<------ PCInitiate, FEC=198.51.100.1 / --------- | Label Map 481 | | | 198.51.100.2 | update 482 | | | CC-ID=A | CCI 483 |------- PCRpt,CC-ID=A ------------------------->| 484 | | | | 485 | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map 486 | | | 198.51.100.1 | update 487 | | | CC-ID=B | CCI 488 | |----- PCRpt,CC-ID=B ----------------->| 489 | | | | 491 The forwarding behavior and the end result is similar to IGP based 492 "Adj-SID" in SR. 494 The Path Setup Type for segment routing MUST be set for PCECC SR = 495 TBD2 (see Section 7.2). All PCEP procedures and mechanism are 496 similar to [RFC8664]. 498 PCE relies on the Adj label cleanup using the same PCInitiate 499 message. 501 The above example Figure 3 depict FEC and PCEP speakers that uses 502 IPv4 address. Similarly IPv6 address (such as 2001:DB8::1, 503 2001:DB8::2) can be used during PCEP session establishment as well in 504 FEC object as described in this specification. 506 In case where the label allocation are made by the PCC itself (see 507 Section 5.5.1.6), the PCE could still request an allocation to be 508 made by the PCC, and where the PCC would send a PCRpt with the 509 allocated label encoded in the CC-ID object as shown below - 510 +---------+ +-------+ 511 |PCC | | PCE | 512 |192.0.2.3| +-------+ 513 +------| | | 514 | PCC +---------+ | 515 | 192.0.2.2| | | 516 +------| | | | 517 |PCC +----------+ | | 518 |192.0.2.1| | | | 519 +---------+ | | | 520 | | | | 521 |<------ PCInitiate, FEC=198.51.100.1------------ | Label Map 522 | | | 198.51.100.2 | request 523 | | | CC-ID=A,C=1 | CCI 524 |------- PCRpt,CC-ID=A,Label -------------------->| 525 | | | | 526 | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map 527 | | | 198.51.100.1 | request 528 | | | CC-ID=B,C=1 | CCI 529 | |----- PCRpt,CC-ID=B,Label------------->| 530 | | | | 532 In this example the request is made to the node 192.0.2.1 with C bit 533 set in the CCI object to indicate that the allocation needs to be 534 done by this PCC for the adjacency (198.51.100.1 - 198.51.100.2) and 535 it responds with the allocated label/SID to the PCE. Similarly, 536 another request is made to the node 192.0.2.2 with C bit set in the 537 CCI object to indicate that the allocation needs to be done by this 538 PCC for the adjacency (198.51.100.2 - 198.51.100.1). 540 5.5.1.3. Redundant PCEs 542 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 543 between the stateful PCEs. The SR SIDs allocated by a PCE MUST also 544 be synchronized among PCEs for PCECC SR state synchronization. Note 545 that the SR SIDs are independent to the PCECC-SR LSP, and remains 546 intact till any topology change. The redundant PCEs MUST have a 547 common view of all SR SIDs allocated in the domain. 549 5.5.1.4. Re Delegation and Cleanup 551 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the action 552 needed for CCIs for the Basic PCECC LSP on this terminated session. 553 Similarly actions should be applied for the SR SID as well. 555 5.5.1.5. Synchronization of Label Allocations 557 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the 558 synchronization of Central Controller's Instructions (CCI) via LSP 559 state synchronization as described in [RFC8231] and [RFC8232]. Same 560 procedures should be applied for SR SIDs as well. 562 5.5.1.6. PCC Based Allocations 564 The PCE can request the PCC to allocate the label/SID using the 565 PCInitiate message. The C flag in the CCI object is set to 1 to 566 indicate that the allocation needs to be done by the PCC. The PCC 567 would allocate the SID/Label/Index and would report to the PCE using 568 the PCRpt message. 570 If the value of the SID/Label/Index is 0 and the C flag is set, it 571 indicates that the PCE is requesting the allocation to be done by the 572 PCC. If the SID/Label/Index is 'n' and the C flag is set in the CCI 573 object, it indicates that the PCE requests a specific value 'n' for 574 the SID/Label/Index. If the allocation is successful, the PCC should 575 report via PCRpt message with the CCI object. Else, it MUST send a 576 PCErr message with Error-Type = TBD ("PCECC failure") and Error Value 577 = TBD ("Invalid CCI") (defined in 578 [I-D.ietf-pce-pcep-extension-for-pce-controller]). If the value of 579 the the SID/Label/Index in the CCI object is valid, but the PCC is 580 unable to allocate it, it MUST send a PCErr message with Error-Type = 581 TBD ("PCECC failure") and Error Value = TBD ("Unable to allocate the 582 specified CCI") (defined in 583 [I-D.ietf-pce-pcep-extension-for-pce-controller]). 585 If the PCC wishes to withdrawn or modify the previously assigned 586 label/SID, it MUST send a PCRpt message without any SID/Label/Index 587 or with the SID/Label/Index containing the new value respectively in 588 the CCI object. The PCE would further trigger the removal of the 589 central controller instruction as per this document. 591 5.5.1.7. Binding SID 593 A PCE as a central controller can allocate and provision the 594 node/prefix/adjacency label (SID) via PCEP. One such SID is binding 595 SID as described in [I-D.ietf-pce-binding-label-sid], the PCECC 596 mechanism can also be used to allocate the binding SID as described 597 in this section. 599 A procedure for binding label/SID allocation is described in 600 [I-D.ietf-pce-pcep-extension-for-pce-controller] and is applicable 601 for all path setup types (including SR paths). 603 6. PCEP messages 605 As defined in [RFC5440], a PCEP message consists of a common header 606 followed by a variable-length body made of a set of objects that can 607 be either mandatory or optional. An object is said to be mandatory 608 in a PCEP message when the object must be included for the message to 609 be considered valid. For each PCEP message type, a set of rules is 610 defined that specify the set of objects that the message can carry. 611 An implementation MUST form the PCEP messages using the object 612 ordering specified in this document. 614 6.1. Central Control Instructions 616 6.1.1. The PCInitiate message 618 The PCInitiate Message defined in [RFC8281] and extended in 619 [I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended 620 to support SR based central control instructions. 622 The format of the extended PCInitiate message is as follows: 624 ::= 625 626 Where: 627 is defined in [RFC5440] 629 ::= 630 [] 632 ::= 633 (| 634 | 635 ) 637 ::= 638 ( 639 )| 640 ( 641 ) 643 ::= 644 [] 646 Where: 647 and 648 are as per 649 [RFC8281]. 651 The LSP and SRP object is defined in [RFC8231]. 653 When PCInitiate message is used to distribute SR SIDs, the SRP, FEC 654 and CCI objects MUST be present. The error handling for missing SRP 655 or CCI object is as per 656 [I-D.ietf-pce-pcep-extension-for-pce-controller]. If the FEC object 657 is missing, the receiving PCC MUST send a PCErr message with Error- 658 type=6 (Mandatory Object missing) and Error-value=TBD5 (FEC object 659 missing). 661 To cleanup the SRP object must set the R (remove) bit and include the 662 FEC and the CCI object. 664 6.1.2. The PCRpt message 666 The PCRpt message can be used to report the SR instructions received 667 from the central controller (PCE) during the state synchronization 668 phase. 670 The format of the PCRpt message is as follows: 672 ::= 673 674 Where: 676 ::= [] 678 ::= (| 679 ) 681 ::= [] 682 683 685 ::= [] 686 ( 687 )| 688 ( 689 ) 691 ::= 692 [] 694 Where: 695 is as per [RFC8231] and the LSP and SRP object are 696 also defined in [RFC8231]. 698 When PCRpt message is used to report the label map allocations, the 699 FEC and CCI objects MUST be present. The error handling for CCI 700 object is as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. 701 If the FEC object is missing, the receiving PCC MUST send a PCErr 702 message with Error-type=6 (Mandatory Object missing) and Error- 703 value=TBD5 (FEC object missing). 705 7. PCEP Objects 707 7.1. OPEN Object 709 7.1.1. PCECC Capability sub-TLV 711 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 712 CAPABILITY TLV. 714 A new S-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SR: 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type=TBD | Length=4 | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Flags |S| 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 [Editor's Note - The above figure is included for ease of the reader 725 but should be removed before publication.] 727 S (PCECC-SR-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP 728 speaker, it indicates that the PCEP speaker is capable for PCECC-SR 729 capability and PCE would allocate node and Adj label on this session. 731 7.2. PATH-SETUP-TYPE TLV 733 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. PST = TBD2 is used 734 when Path is setup via PCECC SR mode. 736 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD2 indicates that this 737 LSP was setup via a PCECC-SR based mechanism where either the SIDs 738 were allocated/instructed by PCE via PCECC mechanism. 740 7.3. CCI Object 742 The Central Control Instructions (CCI) Object is used by the PCE to 743 specify the forwarding instructions is defined in 744 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 745 defines another object-type for SR-MPLS purpose. 747 CCI Object-Type is TBD6 for SR-MPLS as below - 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | CC-ID | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | MT-ID | Algorithm | Flags |B|P|G|C|N|E|V|L|O| 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 // SID/Label/Index (variable) // 756 +---------------------------------------------------------------+ 757 | | 758 // Optional TLV // 759 | | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 The field CC-ID is as described in 763 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following new 764 fields are defined for CCI Object-Type TBD6 - 766 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 768 Algorithm: Single octet identifying the algorithm the SID is 769 associated with. See [RFC8665]. 771 Flags: is used to carry any additional information pertaining to the 772 CCI. The O bit was defined in 773 [I-D.ietf-pce-pcep-extension-for-pce-controller], this document 774 further defines following bits- 776 * L-Bit (Local/Global): If set, then the value/index carried by 777 the CCI object has local significance. If not set, then the 778 value/index carried by this object has global significance. 780 * V-Bit (Value/Index): If set, then the CCI carries an absolute 781 value. If not set, then the CCI carries an index. 783 * E-Bit (Explicit-Null): If set, any upstream neighbor of the 784 node that advertised the SID MUST replace the SID with the 785 Explicit-NULL label (0 for IPv4) before forwarding the packet. 787 * N-Bit (No-PHP): If set, then the penultimate hop MUST NOT pop 788 the SID before delivering packets to the node that advertised 789 the SID. 791 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 792 that the allocation needs to be done by the PCC for this 793 central controller instruction. A PCE set this bit to request 794 the PCC to make an allocation from its SR label/ID space. A 795 PCC would set this bit to indicate that it has allocated the 796 CC-ID and report it to the PCE. 798 * Following bits are applicable when the SID represents an Adj- 799 SID only, it MUST be ignored for others - 801 + G-Bit (Group): When set, the G-Flag indicates that the Adj- 802 SID refers to a group of adjacencies (and therefore MAY be 803 assigned to other adjacencies as well). 805 + P-Bit (Persistent): When set, the P-Flag indicates that the 806 Adj-SID is persistently allocated, i.e., the Adj-SID value 807 remains consistent across router restart and/or interface 808 flap. 810 + B-Bit (Backup): If set, the Adj-SID refers to an adjacency 811 that is eligible for protection (e.g., using IP Fast Reroute 812 or MPLS-FRR (MPLS-Fast Reroute) as described in Section 2.1 813 of [RFC8402]. 815 + All unassigned bits MUST be set to zero at transmission and 816 ignored at receipt. 818 SID/Label/Index: According to the V and L flags, it contains either: 820 A 32-bit index defining the offset in the SID/Label space 821 advertised by this router. 823 A 24-bit label where the 20 rightmost bits are used for 824 encoding the label value. 826 7.4. FEC Object 828 The FEC Object is used to specify the FEC information and MAY be 829 carried within PCInitiate or PCRpt message. 831 FEC Object-Class is TBD3. 833 FEC Object-Type is 1 'IPv4 Node ID'. 835 0 1 2 3 836 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 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | IPv4 Node ID | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 FEC Object-Type is 2 'IPv6 Node ID'. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | | 846 // IPv6 Node ID (16 bytes) // 847 | | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 FEC Object-Type is 3 'IPv4 Adjacency'. 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Local IPv4 address | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Remote IPv4 address | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 FEC Object-Type is 4 'IPv6 Adjacency'. 862 0 1 2 3 863 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 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | | 866 // Local IPv6 address (16 bytes) // 867 | | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | | 870 // Remote IPv6 address (16 bytes) // 871 | | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 FEC Object-Type is 5 'Unnumbered Adjacency with IPv4 NodeIDs'. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Local Node-ID | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Local Interface ID | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Remote Node-ID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Remote Interface ID | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 FEC Object-Type is 6 'Linklocal IPv6 Adjacency'. 890 0 1 2 3 891 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 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 // Local IPv6 address (16 octets) // 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Local Interface ID | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 // Remote IPv6 address (16 octets) // 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Remote Interface ID | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 The FEC objects are as follows: 904 IPv4 Node ID: where IPv4 Node ID is specified as an IPv4 address of 905 the Node. FEC Object-type is 1, and the Object-Length is 4 in this 906 case. 908 IPv6 Node ID: where IPv6 Node ID is specified as an IPv6 address of 909 the Node. FEC Object-type is 2, and the Object-Length is 16 in this 910 case. 912 IPv4 Adjacency: where Local and Remote IPv4 address is specified as 913 pair of IPv4 address of the adjacency. FEC Object-type is 3, and the 914 Object-Length is 8 in this case. 916 IPv6 Adjacency: where Local and Remote IPv6 address is specified as 917 pair of IPv6 address of the adjacency. FEC Object-type is 4, and the 918 Object-Length is 32 in this case. 920 Unnumbered Adjacency with IPv4 NodeID: where a pair of Node ID / 921 Interface ID tuples is used. FEC Object-type is 5, and the Object- 922 Length is 16 in this case. 924 Linklocal IPv6 Adjacency: where a pair of (global IPv6 address, 925 interface ID) tuples is used. FEC object-type is 6, and the Object- 926 Length is 40 in this case. 928 8. Implementation Status 930 [Note to the RFC Editor - remove this section before publication, as 931 well as remove the reference to RFC 7942.] 932 This section records the status of known implementations of the 933 protocol defined by this specification at the time of posting of this 934 Internet-Draft, and is based on a proposal described in [RFC7942]. 935 The description of implementations in this section is intended to 936 assist the IETF in its decision processes in progressing drafts to 937 RFCs. Please note that the listing of any individual implementation 938 here does not imply endorsement by the IETF. Furthermore, no effort 939 has been spent to verify the information presented here that was 940 supplied by IETF contributors. This is not intended as, and must not 941 be construed to be, a catalog of available implementations or their 942 features. Readers are advised to note that other implementations may 943 exist. 945 According to [RFC7942], "this will allow reviewers and working groups 946 to assign due consideration to documents that have the benefit of 947 running code, which may serve as evidence of valuable experimentation 948 and feedback that have made the implemented protocols more mature. 949 It is up to the individual working groups to use this information as 950 they see fit". 952 8.1. Huawei's Proof of Concept based on ONOS 954 The PCE function was developed in the ONOS open source platform. 955 This extension was implemented on a private version as a proof of 956 concept for PCECC. 958 o Organization: Huawei 960 o Implementation: Huawei's PoC based on ONOS 962 o Description: PCEP as a southbound plugin was added to ONOS. To 963 support PCECC-SR, an earlier version of this I-D was implemented. 964 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 966 o Maturity Level: Prototype 968 o Coverage: Partial 970 o Contact: satishk@huawei.com 972 9. Security Considerations 974 The security considerations described in 975 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the 976 extensions described in this document. 978 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 979 be activated on authenticated and encrypted sessions across PCEs and 980 PCCs belonging to the same administrative authority, using Transport 981 Layer Security (TLS) [RFC8253] as per the recommendations and best 982 current practices in [RFC7525] (unless explicitly set aside in 983 [RFC8253]). 985 10. Manageability Considerations 987 10.1. Control of Function and Policy 989 A PCE or PCC implementation SHOULD allow to configure to enable/ 990 disable PCECC SR capability as a global configuration. 992 10.2. Information and Data Models 994 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 995 PCECC SR capability status. 997 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 998 enable/disable PCECC SR capability. 1000 10.3. Liveness Detection and Monitoring 1002 Mechanisms defined in this document do not imply any new liveness 1003 detection and monitoring requirements in addition to those already 1004 listed in [RFC5440]. 1006 10.4. Verify Correct Operations 1008 Mechanisms defined in this document do not imply any new operation 1009 verification requirements in addition to those already listed in 1010 [RFC5440] and [RFC8231]. 1012 10.5. Requirements On Other Protocols 1014 PCEP extensions defined in this document do not put new requirements 1015 on other protocols. 1017 10.6. Impact On Network Operations 1019 PCEP implementation SHOULD allow a limit to be placed on the rate of 1020 PCLabelUpd messages sent by PCE and processed by PCC. It SHOULD also 1021 allow sending a notification when a rate threshold is reached. 1023 11. IANA Considerations 1024 11.1. PCECC-CAPABILITY sub-TLV 1026 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 1027 CAPABILITY sub-TLV and requests that IANA to create a new sub- 1028 registry to manage the value of the PCECC-CAPABILITY sub-TLV's Flag 1029 field. 1031 IANA is requested to allocate a new bit in the PCECC-CAPABILITY sub- 1032 TLV Flag Field sub-registry, as follows: 1034 Bit Description Reference 1035 TBD1 S((PCECC-SR-CAPABILITY)) This document 1037 11.2. New Path Setup Type Registry 1039 [RFC8408] created a sub-registry within the "Path Computation Element 1040 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1041 IANA is requested to allocate a new code point within this registry, 1042 as follows: 1044 Value Description Reference 1045 TBD2 Traffic engineering path is This document 1046 setup using PCECC-SR mode 1048 11.3. PCEP Object 1050 IANA is requested to allocate new code-point for the new FEC object 1051 and a new Object-Type for CCI object in "PCEP Objects" sub-registry 1052 as follows: 1054 Object-Class Name Object-Type Reference 1055 Value 1056 TBD3 FEC 1: IPv4 Node ID This document 1057 2: IPv6 Node ID This document 1058 3: IPv4 Adjacency This document 1059 4: IPv6 Adjacency This document 1060 5: Unnumbered Adjacency with This document 1061 IPv4 NodeID 1062 6: Linklocal IPv6 Adjacency This document 1063 TBD CCI 1064 TBD6: SR-MPLS This document 1066 11.4. PCEP-Error Object 1068 IANA is requested to allocate new error types and error values within 1069 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1070 PCEP Numbers registry for the following errors: 1072 Error-Type Meaning 1073 ---------- ------- 1074 6 Mandatory Object missing. 1076 Error-value = TBD5 : FEC object missing 1077 19 Invalid operation. 1079 Error-value = TBD4 : SR capability was 1080 not advertised 1082 11.5. CCI Object Flag Field for SR 1084 IANA is requested to create a new sub-registry to manage the Flag 1085 field of the CCI Object-Type=TBD6 for SR called "CCI Object Flag 1086 Field for SR". New values are to be assigned by Standards Action 1087 [RFC8126]. Each bit should be tracked with the following qualities: 1089 o Bit number (counting from bit 0 as the most significant bit) 1090 o Capability description 1091 o Defining RFC 1093 Following bits are defined for the CCI Object flag field for SR in 1094 this document as follows: 1096 Bit Description Reference 1097 0-7 Unassigned This document 1098 8 B-Bit - Backup This document 1099 9 P-Bit - Persistent This document 1100 10 G-Bit - Group This document 1101 11 C-Bit - PCC Allocation This document 1102 12 N-Bit - No-PHP This document 1103 13 E-Bit - Explicit-Null This document 1104 14 V-Bit - Value/Index This document 1105 15 L-Bit - Local/Global This document 1107 12. Acknowledgments 1109 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1110 Avantika for their useful comments and suggestions. 1112 13. References 1114 13.1. Normative References 1116 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1117 Requirement Levels", BCP 14, RFC 2119, 1118 DOI 10.17487/RFC2119, March 1997, 1119 . 1121 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1122 (TE) Extensions to OSPF Version 2", RFC 3630, 1123 DOI 10.17487/RFC3630, September 2003, 1124 . 1126 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1127 Support of Generalized Multi-Protocol Label Switching 1128 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1129 . 1131 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1132 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1133 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1134 . 1136 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1137 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1138 2008, . 1140 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1141 in Support of Generalized Multi-Protocol Label Switching 1142 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1143 . 1145 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1146 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1147 DOI 10.17487/RFC5440, March 2009, 1148 . 1150 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1151 Hardwick, "Path Computation Element Communication Protocol 1152 (PCEP) Management Information Base (MIB) Module", 1153 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1154 . 1156 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1157 "Recommendations for Secure Use of Transport Layer 1158 Security (TLS) and Datagram Transport Layer Security 1159 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1160 2015, . 1162 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1163 S. Ray, "North-Bound Distribution of Link-State and 1164 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1165 DOI 10.17487/RFC7752, March 2016, 1166 . 1168 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1169 Code: The Implementation Status Section", BCP 205, 1170 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1171 . 1173 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1174 Writing an IANA Considerations Section in RFCs", BCP 26, 1175 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1176 . 1178 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1179 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1180 May 2017, . 1182 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1183 Computation Element Communication Protocol (PCEP) 1184 Extensions for Stateful PCE", RFC 8231, 1185 DOI 10.17487/RFC8231, September 2017, 1186 . 1188 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1189 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1190 Path Computation Element Communication Protocol (PCEP)", 1191 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1192 . 1194 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1195 Computation Element Communication Protocol (PCEP) 1196 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1197 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1198 . 1200 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1201 Hardwick, "Conveying Path Setup Type in PCE Communication 1202 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1203 July 2018, . 1205 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1206 and J. Hardwick, "Path Computation Element Communication 1207 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1208 DOI 10.17487/RFC8664, December 2019, 1209 . 1211 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1212 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 1213 Procedures and Protocol Extensions for Using PCE as a 1214 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1215 extension-for-pce-controller-05 (work in progress), June 1216 2020. 1218 13.2. Informative References 1220 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1221 Label Switching Architecture", RFC 3031, 1222 DOI 10.17487/RFC3031, January 2001, 1223 . 1225 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1226 Element (PCE)-Based Architecture", RFC 4655, 1227 DOI 10.17487/RFC4655, August 2006, 1228 . 1230 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1231 Margaria, "Requirements for GMPLS Applications of PCE", 1232 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1233 . 1235 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1236 Computation Element Architecture", RFC 7399, 1237 DOI 10.17487/RFC7399, October 2014, 1238 . 1240 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1241 Application-Based Network Operations", RFC 7491, 1242 DOI 10.17487/RFC7491, March 2015, 1243 . 1245 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1246 and D. Dhody, "Optimizations of Label Switched Path State 1247 Synchronization Procedures for a Stateful PCE", RFC 8232, 1248 DOI 10.17487/RFC8232, September 2017, 1249 . 1251 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1252 Architecture for Use of PCE and the PCE Communication 1253 Protocol (PCEP) in a Network with Central Control", 1254 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1255 . 1257 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1258 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1259 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1260 July 2018, . 1262 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1263 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1264 Routing with the MPLS Data Plane", RFC 8660, 1265 DOI 10.17487/RFC8660, December 2019, 1266 . 1268 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1269 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1270 Extensions for Segment Routing", RFC 8665, 1271 DOI 10.17487/RFC8665, December 2019, 1272 . 1274 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1275 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1276 Extensions for Segment Routing", RFC 8667, 1277 DOI 10.17487/RFC8667, December 2019, 1278 . 1280 [I-D.ietf-teas-pcecc-use-cases] 1281 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1282 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1283 Gulida, "The Use Cases for Path Computation Element (PCE) 1284 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1285 use-cases-05 (work in progress), March 2020. 1287 [I-D.ietf-pce-pcep-yang] 1288 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1289 YANG Data Model for Path Computation Element 1290 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1291 yang-13 (work in progress), October 2019. 1293 [I-D.ietf-pce-binding-label-sid] 1294 Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J., 1295 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1296 in PCE-based Networks.", draft-ietf-pce-binding-label- 1297 sid-03 (work in progress), June 2020. 1299 [I-D.litkowski-pce-state-sync] 1300 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 1301 Stateful Path Computation Element (PCE) Communication 1302 Procedures.", draft-litkowski-pce-state-sync-08 (work in 1303 progress), July 2020. 1305 [I-D.dhodylee-pce-pcep-ls] 1306 Dhody, D., Peng, S., Lee, Y., and D. Ceccarelli, "PCEP 1307 extensions for Distribution of Link-State and TE 1308 Information", draft-dhodylee-pce-pcep-ls-15 (work in 1309 progress), March 2020. 1311 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 1312 Negi, M., Li, Z., Geng, X., and S. Peng, "PCEP Procedures 1313 and Protocol Extensions for Using PCE as a Central 1314 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 1315 extension-pce-controller-srv6-03 (work in progress), March 1316 2020. 1318 Appendix A. Examples 1320 [Editor's Note: Add examples to show how the SID allocation are being 1321 done for LAN Adj-SID in a future revision] 1323 Appendix B. Contributor Addresses 1325 Dhruv Dhody 1326 Huawei Technologies 1327 Divyashree Techno Park, Whitefield 1328 Bangalore, Karnataka 560066 1329 India 1331 EMail: dhruv.ietf@gmail.com 1333 Satish Karunanithi 1334 Huawei Technologies 1335 Divyashree Techno Park, Whitefield 1336 Bangalore, Karnataka 560066 1337 India 1339 EMail: satishk@huawei.com 1341 Adrian Farrel 1342 Juniper Networks, Inc 1343 UK 1345 EMail: adrian@olddog.co.uk 1347 Xuesong Geng 1348 Huawei Technologies 1349 China 1351 Email: gengxuesong@huawei.com 1353 Udayasree Palle 1355 EMail: udayasreereddy@gmail.com 1357 Katherine Zhao 1358 Huawei Technologies 1359 2330 Central Expressway 1360 Santa Clara, CA 95050 1361 USA 1363 EMail: katherine.zhao@huawei.com 1365 Boris Zhang 1366 Telus Ltd. 1367 Toronto 1368 Canada 1370 EMail: boris.zhang@telus.com 1372 Alex Tokar 1373 Cisco Systems 1374 Slovak Republic 1376 EMail: atokar@cisco.com 1378 Authors' Addresses 1380 Zhenbin Li 1381 Huawei Technologies 1382 Huawei Bld., No.156 Beiqing Rd. 1383 Beijing 100095 1384 China 1386 EMail: lizhenbin@huawei.com 1388 Shuping Peng 1389 Huawei Technologies 1390 Huawei Bld., No.156 Beiqing Rd. 1391 Beijing 100095 1392 China 1394 EMail: pengshuping@huawei.com 1396 Mahendra Singh Negi 1397 RtBrick India 1398 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 1399 Bangalore, Karnataka 560102 1400 India 1402 EMail: mahend.ietf@gmail.com 1403 Quintin Zhao 1404 Etheric Networks 1405 1009 S CLAREMONT ST 1406 SAN MATEO, CA 94402 1407 USA 1409 EMail: qzhao@ethericnetworks.com 1411 Chao Zhou 1412 Cisco Systems 1414 EMail: choa.zhou@cisco.com