idnits 2.17.00 (12 Aug 2021) /tmp/idnits31591/draft-ietf-pce-pcep-extension-pce-controller-sr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (6 March 2022) is 69 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) ** Downref: Normative reference to an Experimental draft: draft-dhodylee-pce-pcep-ls (ref. 'I-D.dhodylee-pce-pcep-ls') == Outdated reference: A later version (-08) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-07 == Outdated reference: A later version (-15) exists of draft-ietf-pce-binding-label-sid-14 == Outdated reference: A later version (-07) exists of draft-ietf-pce-segment-routing-policy-cp-06 == Outdated reference: A later version (-02) exists of draft-ietf-pce-state-sync-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-09) exists of draft-ietf-teas-pcecc-use-cases-08 == Outdated reference: A later version (-11) exists of draft-li-pce-controlled-id-space-10 Summary: 1 error (**), 0 flaws (~~), 7 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: 7 September 2022 M. Negi 6 RtBrick Inc 7 Q. Zhao 8 Etheric Networks 9 C. Zhou 10 HPE 11 6 March 2022 13 Path Computation Element Communication Protocol (PCEP) Procedures and 14 Extensions for Using PCE as a Central Controller (PCECC) for Segment 15 Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution. 16 draft-ietf-pce-pcep-extension-pce-controller-sr-04 18 Abstract 20 The Path Computation Element (PCE) is a core component of Software- 21 Defined Networking (SDN) systems. 23 A PCE-based Central Controller (PCECC) can simplify the processing of 24 a distributed control plane by blending it with elements of SDN and 25 without necessarily completely replacing it. Thus, the LSP can be 26 calculated/set up/initiated and the label forwarding entries can also 27 be downloaded through a centralized PCE server to each network device 28 along the path while leveraging the existing PCE technologies as much 29 as possible. 31 This document specifies the procedures and PCEP extensions when a 32 PCE-based controller is also responsible for configuring the 33 forwarding actions on the routers, in addition to computing the paths 34 for packet flows in a segment routing (SR) network and telling the 35 edge routers what instructions to attach to packets as they enter the 36 network. PCECC as defined in RFC 9050 is further enhanced for SR- 37 MPLS SID (Segment Identifier) allocation and distribution. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on 7 September 2022. 56 Copyright Notice 58 Copyright (c) 2022 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 63 license-info) in effect on the date of publication of this document. 64 Please review these documents carefully, as they describe your rights 65 and restrictions with respect to this document. Code Components 66 extracted from this document must include Revised BSD License text as 67 described in Section 4.e of the Trust Legal Provisions and are 68 provided without warranty as described in the Revised BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. PCECC SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 77 5. Procedures for Using the PCE as a Central Controller (PCECC) in 78 Segment Routing . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 7 80 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 7 81 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 82 5.4. PCEP session IP address and TED Router ID . . . . . . . . 8 83 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 84 5.5.1. PCECC Segment Routing (SR) . . . . . . . . . . . . . 9 85 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 15 86 6.1. Central Control Instructions . . . . . . . . . . . . . . 15 87 6.1.1. The PCInitiate Message . . . . . . . . . . . . . . . 15 88 6.1.2. The PCRpt message . . . . . . . . . . . . . . . . . . 17 89 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 17 90 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 18 91 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 18 92 7.2. SR-TE Path Setup . . . . . . . . . . . . . . . . . . . . 18 93 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 18 94 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 20 95 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 96 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 22 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 99 10. Manageability Considerations . . . . . . . . . . . . . . . . 22 100 10.1. Control of Function and Policy . . . . . . . . . . . . . 23 101 10.2. Information and Data Models . . . . . . . . . . . . . . 23 102 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 23 103 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 23 104 10.5. Requirements On Other Protocols . . . . . . . . . . . . 23 105 10.6. Impact On Network Operations . . . . . . . . . . . . . . 23 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 107 11.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 23 108 11.2. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 24 109 11.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 24 110 11.4. CCI Object Flag Field for SR . . . . . . . . . . . . . . 25 111 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 112 13. Normative References . . . . . . . . . . . . . . . . . . . . 26 113 14. Informative References . . . . . . . . . . . . . . . . . . . 28 114 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 117 1. Introduction 119 The Path Computation Element (PCE) [RFC4655] was developed to offload 120 the path computation function from routers in an MPLS traffic- 121 engineered network. It can compute optimal paths for traffic across 122 a network and can also update the paths to reflect changes in the 123 network or traffic demands. Since then, the role and function of the 124 PCE has grown to cover a number of other uses (such as GMPLS 125 [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated 126 use of network resources [RFC8281]. 128 According to [RFC7399], Software-Defined Networking (SDN) refers to a 129 separation between the control elements and the forwarding components 130 so that software running in a centralized system, called a 131 controller, can act to program the devices in the network to behave 132 in specific ways. A required element in an SDN architecture is a 133 component that plans how the network resources will be used and how 134 the devices will be programmed. It is possible to view this 135 component as performing specific computations to place traffic flows 136 within the network given knowledge of the availability of network 137 resources, how other forwarding devices are programmed, and the way 138 that other flows are routed. This is the function and purpose of a 139 PCE, and the way that a PCE integrates into a wider network control 140 system (including an SDN system) is presented in [RFC7491]. 142 In early PCE implementations, where the PCE was used to derive paths 143 for MPLS Label Switched Paths (LSPs), paths were requested by network 144 elements (known as Path Computation Clients (PCCs)), and the results 145 of the path computations were supplied to network elements using the 146 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 147 This protocol was later extended to allow a PCE to send unsolicited 148 requests to the network for LSP establishment [RFC8281]. 150 PCE was developed to derive paths for MPLS Label Switched Paths 151 (LSPs), which are supplied to the head end of the LSP using the Path 152 Computation Element Communication Protocol (PCEP). But SDN has a 153 broader applicability than signaled (G)MPLS traffic-engineered (TE) 154 networks, and the PCE may be used to determine paths in a range of 155 use cases. PCEP has been proposed as a control protocol for use in 156 these environments to allow the PCE to be fully enabled as a central 157 controller. 159 [RFC8283] introduces the architecture for PCE as a central controller 160 as an extension of the architecture described in [RFC4655] and 161 assumes the continued use of PCEP as the protocol used between PCE 162 and PCC. [RFC8283] further examines the motivations and 163 applicability for PCEP as a Southbound Interface (SBI), and 164 introduces the implications for the protocol. 165 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCE- 166 based Central Controller (PCECC) architecture. As described in 167 [RFC8283], PCECC simplifies the processing of a distributed IGP based 168 control plane by blending it with elements of SDN, without replacing 169 it. 171 [RFC9050] specify the procedures and PCEP extensions for using the 172 PCE as the central controller for static LSPs, where LSPs can be 173 provisioned as explicit label instructions at each hop on the end-to- 174 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 [RFC8667] and [RFC8665] , respectively. It relies on a 183 series of forwarding instructions being placed in the header of a 184 packet. The segment routing architecture supports operations that 185 can be used to steer packet flows in a network, thus providing a form 186 of traffic engineering. [RFC8664] specify the SR specific PCEP 187 extensions. 189 Segment Routing Policy for Traffic Engineering 190 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 191 Policy and approaches to steering traffic into an SR Policy. An SR 192 Policy contains one or more SR Policy Candidate Paths where one or 193 more such paths can be computed via PCE. 195 [I-D.ietf-pce-segment-routing-policy-cp] specifies PCEP extensions to 196 signal additional information to map candidate paths to their SR 197 policies. 199 PCECC may further use PCEP for SR SID (Segment Identifier) allocation 200 and distribution to all the SR nodes with some benefits. The SR 201 nodes continue to rely on IGP for distributed computation (nexthop 202 selection, protection etc) where PCE (and PCEP) does only the 203 allocation and distribution of SIDs in the network. Note that the 204 topology at PCE is still learned via existing mechanisms. 206 This document specifies the procedures and PCEP extensions when a 207 PCE-based controller is also responsible for configuring the 208 forwarding actions on the routers (i.e. the SR SID allocation and 209 distribution in this case), in addition to computing the SR paths for 210 packet flows in a segment routing network and telling the edge 211 routers what instructions to attach to packets as they enter the 212 network as described in [RFC8283]. 214 Only SR using MPLS dataplane (SR-MPLS) is in the scope of this 215 document. Refer [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 216 for use of PCECC technique for SR in IPv6 (SRv6) dataplane. 218 1.1. Requirements Language 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 222 "OPTIONAL" in this document are to be interpreted as described in BCP 223 14 [RFC2119] [RFC8174] when, and only when, they appear in all 224 capitals, as shown here. 226 2. Terminology 228 Terminologies used in this document is the same as described in the 229 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 231 3. PCECC SR-MPLS 233 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 234 compute, update, or initiate SR-TE paths. An ingress node of an SR- 235 TE path appends all outgoing packets with a list of MPLS labels 236 (SIDs). This is encoded in SR-ERO subobject, capable of carrying a 237 label (SID) as well as the identity of the node/adjacency. 239 The notion of segment and SID is defined in [RFC8402], which fits the 240 MPLS architecture [RFC3031] as the label which is managed by a local 241 allocation process of LSR (similarly to other MPLS signaling 242 protocols) [RFC8660]. The SR information such as node/adjacency 243 label (SID) is flooded via IGP as specified in [RFC8667] and 244 [RFC8665]. 246 [RFC8283] examines the motivations and applicability for PCECC and 247 use of PCEP as an SBI. Section 3.1.5. of [RFC8283] highlights the 248 use of PCECC for configuring the forwarding actions on the routers 249 and assume responsibility for managing the label space. It 250 simplifies the processing of a distributed control plane by blending 251 it with elements of SDN and without necessarily completely replacing 252 it. This allows the operator to introduce the advantages of SDN 253 (such as programmability) into the network. Further Section 3.3. of 254 [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where 255 the PCECC technique could be useful. Section 4 of [RFC8283] also 256 describe the implications on the protocol when used as an SDN SBI. 257 The operator needs to evaluate the advantages offered by PCECC 258 against the operational and scalability needs of the PCECC. 260 Thus, PCE as a central controller can allocate and provision the 261 node/prefix/adjacency label (SID) via PCEP. The rest of the 262 processing is similar to existing stateful PCE with SR mechanism. 264 For the purpose of this document, it is assumed that the label/SID 265 range to be used by a PCE is set on both PCEP peers. The PCC MUST 266 NOT make allocations from the label space set aside for the PCE to 267 avoid overlap and collisions of label allocations. Further, a global 268 label/SID range is assumed to be set on all PCEP peers in the SR 269 domain. A future extension could add the capability to advertise 270 this range via a possible PCEP extension as well (see 271 [I-D.li-pce-controlled-id-space]). This document also allows a case 272 where the label/SID space is maintained by PCC and the labels/SID are 273 allocated by it. In this case, the PCE should request the allocation 274 from PCC as described in Section 5.5.1.6. 276 4. PCEP Requirements 278 Following key requirements for PCECC-SR should be considered when` 279 designing the PCECC-based solution: 281 * A PCEP speaker supporting this document needs to have the 282 capability to advertise its PCECC-SR capability to its peers. 284 * PCEP procedures need to allow for PCC-based label/SID allocations. 286 * PCEP procedures need to provide a means to update (or clean up) 287 label-map entries downloaded to the PCC. 289 * PCEP procedures need to provide a means to synchronize the SR 290 label/SID allocations between the PCE to the PCC via PCEP 291 messages. 293 5. Procedures for Using the PCE as a Central Controller (PCECC) in 294 Segment Routing 296 5.1. Stateful PCE Model 298 Active stateful PCE is described in [RFC8231]. PCE as a Central 299 Controller (PCECC) reuses the existing active stateful PCE mechanism 300 as much as possible to control the LSPs. 302 5.2. New LSP Functions 304 Several new functions are required in PCEP to support PCECC as 305 described in [RFC9050]. This document reuses the existing messages 306 to support PCECC-SR. 308 The PCEP messages PCRpt, PCInitiate, PCUpd are used to send LSP 309 Reports, LSP setup, and LSP update respectively. The extended 310 PCInitiate message described in [RFC9050] is used to download or 311 clean up central controller's instructions (CCIs) (SR SID in the 312 scope of this document). The extended PCRpt message described in 313 [RFC9050] is also used to report the CCIs (SR SIDs) from PCC to PCE. 315 [RFC9050] specify an object called CCI for the encoding of the 316 central controller's instructions for Label. This document extends 317 the CCI by defining a new object-type for SR-MPLS. The PCEP messages 318 are extended in this document to handle the PCECC operations for SR. 320 5.3. PCECC Capability Advertisement 322 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 323 advertise their support of PCECC extensions. A PCEP Speaker includes 324 the "PCECC Capability" sub-TLV, described in [RFC9050]. 326 A new S-bit is added in the PCECC-CAPABILITY sub-TLV to indicate 327 support for PCECC-SR for SR-MPLS. A PCC MUST set the S-bit in the 328 PCECC-CAPABILITY sub-TLV and include the SR-PCE-CAPABILITY sub-TLV 329 ([RFC8664]) in the OPEN Object (inside the PATH-SETUP-TYPE-CAPABILITY 330 TLV) to support the PCECC SR-MPLS extensions defined in this 331 document. If the S-bit is set in the PCECC-CAPABILITY sub-TLV and 332 the SR-PCE-CAPABILITY sub-TLV is not advertised in the OPEN Object, 333 PCE SHOULD send a PCErr message with Error-Type=19 (Invalid 334 Operation) and Error-value=TBD4 (SR capability was not advertised) 335 and terminate the session. 337 The rest of the processing is as per [RFC9050]. 339 5.4. PCEP session IP address and TED Router ID 341 A PCE may construct its Traffic Engineering Database (TED) by 342 participating in the IGP ([RFC3630] and [RFC5305] for MPLS-TE; 343 [RFC4203] and [RFC5307] for GMPLS). An alternative is offered by 344 BGP-LS [RFC7752] or [I-D.dhodylee-pce-pcep-ls]. 346 A PCEP [RFC5440] speaker could use any local IP address while 347 creating a TCP session. It is important to link the session IP 348 address with the Router ID in TED for successful PCECC operations. 350 During PCEP Initialization Phase, the PCC SHOULD advertise the TE 351 mapping information by including the "Node Attributes TLV" 352 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 353 in the OPEN Object for this purpose. [RFC7752] describes the usage 354 as auxiliary Router-IDs that the IGP might be using, e.g., for TE 355 purposes. If there are more than one auxiliary Router-ID of a given 356 type, then multiple TLVs are used to encode them. 358 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 359 address is directly used for mapping purpose. 361 [Editor's Note: "Node Attributes TLV" could be moved to this document 362 if the progresses of [I-D.dhodylee-pce-pcep-ls] is lagging. This 363 needs to be handled before the WG LC.] 365 5.5. LSP Operations 367 [RFC8664] specify the PCEP extension to allow a stateful PCE to 368 compute and initiate SR-TE paths, as well as a PCC to request a path 369 subject to certain constraint(s) and optimization criteria in SR 370 networks. 372 The Path Setup Type for segment routing (PST=1) is used on the PCEP 373 session with the Ingress as per [RFC8664]. 375 5.5.1. PCECC Segment Routing (SR) 377 Segment Routing (SR) as described in [RFC8402] depends on "segments" 378 that are advertised by Interior Gateway Protocols (IGPs). The SR- 379 node allocates and advertises the SID (node, adj, etc) and flood them 380 via the IGP. This document proposes a new mechanism where PCE 381 allocates the SID (label/index/SID) centrally and uses PCEP to 382 distribute them to all nodes. In some deployments, PCE (and PCEP) 383 are better suited than IGP because of the centralized nature of PCE 384 and direct TCP based PCEP sessions to all the nodes. Note that only 385 the SID allocation and distribution is done by the PCEP, all other SR 386 operations (nexthop selection, protection, etc) are still done by the 387 node (and the IGPs). 389 5.5.1.1. PCECC SR Node/Prefix SID allocation 391 Each node (PCC) is allocated a node-SID by the PCECC. The PCECC 392 sends PCInitiate message to update the label map of each node to all 393 the nodes in the domain. The TE router ID is determined from the TED 394 or from "IPv4/IPv6 Router-ID" Sub-TLV [I-D.dhodylee-pce-pcep-ls], in 395 the OPEN Object Section 5.4. The LSP object is included in the 396 central controller instructions to continue using the flag field of 397 the LSP object as per [RFC8231] and [RFC8281]. The PLSP-ID is set to 398 the reserved value 0. As per [RFC8281], the LSP object also includes 399 the SPEAKER-ENTITY-ID TLV to identify the PCE that initiated these 400 instructions. 402 It is RECOMMENDED that PCEP session with PCECC-SR capability to use a 403 different session IP address during TCP session establishment than 404 the node Router ID in TEDB, to make sure that the PCEP session does 405 not get impacted by the SR Node/Prefix Label maps (Section 5.4). 407 If a node (PCC) receives a PCInitiate message with a CCI object- 408 type=TBD6 encoding a SID, out of the range set aside for the SR 409 Global Block (SRGB), it MUST send a PCErr message with Error-type=TBD 410 (PCECC failure) and Error-value=TBD (Label out of range) (defined in 411 [RFC9050]) and MUST include the SRP object to specify the error is 412 for the corresponding central control instruction via the PCInitiate 413 message. 415 On receiving the label map, each node (PCC) uses the local routing 416 information via IGP to determine the next-hop and download the label 417 forwarding instructions accordingly as shown in Figure 1. The 418 PCInitiate message in this case uses a new FEC object defined in 419 Section 7.4. 421 +---------+ +-------+ 422 |PCC | | PCE | 423 |192.0.2.3| +-------+ 424 +------| | | 425 | PCC +---------+ | 426 | 192.0.2.2| | | 427 +------| | | | 428 |PCC +----------+ | | 429 |192.0.2.1| | | | 430 +---------+ | | | 431 | | | | 432 |<--------PCInitiate,FEC=192.0.2.1------------------| Label Map 433 | | | CC-ID=X | update 434 |--------PCRpt,CC-ID=X----------------------------->| CCI 435 |Find | | | 436 |Nexthop|<--------PCInitiate,FEC=192.0.2.1----------| Label Map 437 |locally| | CC-ID=Y | update 438 | |-------PCRpt,CC-ID=Y---------------------->| CCI 439 | | | | 440 | | |<----PCInitiate,FEC=192.0.2.1------| Label Map 441 | | | CC-ID=Z | update 442 | | |-----PCRpt,CC-ID=Z---------------->| CCI 443 | | | | 445 Figure 1 447 The forwarding behavior and the end result is similar to IGP based 448 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 449 ECMP-aware shortest-path forwarding of the packet towards the related 450 node as per [RFC8402]. 452 PCE relies on the Node/Prefix Label clean up using the same 453 PCInitiate message as per [RFC8281]. 455 The above example Figure 1 depicts the FEC and PCEP speakers that 456 uses IPv4 address. Similarly an IPv6 address (such as 2001:db8::1) 457 can be used during PCEP session establishment in the FEC object as 458 described in this specification. 460 In the case where the label/SID allocation is made by the PCC itself 461 (see Section 5.5.1.6), the PCE could request an allocation to be made 462 by the PCC, and where the PCC would send a PCRpt with the allocated 463 label/SID encoded in the CC-ID object as shown in Figure 2. 465 +---------+ +-------+ 466 |PCC | | PCE | 467 |192.0.2.3| +-------+ 468 +------| | | 469 | PCC +---------+ | 470 | 192.0.2.2| | | 471 +------| | | | 472 |PCC +----------+ | | 473 |192.0.2.1| | | | 474 +---------+ | | | 475 | | | | 476 |<--------PCInitiate,FEC=192.0.2.1------------------| Label Map 477 | | | CC-ID=X,C=1 | request 478 |--------PCRpt,CC-ID=X,Label----------------------->| CCI 479 |Find | | | 480 |Nexthop|<--------PCInitiate,FEC=192.0.2.1----------| Label Map 481 |locally| | CC-ID=Y,C=0,Label | update 482 | |-------PCRpt,CC-ID=Y---------------------->| CCI 483 | | | | 484 | | |<----PCInitiate,FEC=192.0.2.1------| Label Map 485 | | | CC-ID=Z,C=0,Label | update 486 | | |-----PCRpt,CC-ID=Z---------------->| CCI 487 | | | | 489 Figure 2 491 It should be noted that in this example (Figure 2), the request is 492 made to the node 192.0.2.1 with C bit set in the CCI object to 493 indicate that the allocation needs to be done by this PCC and it 494 responds with the allocated label/SID to the PCE. The PCE would 495 further inform the other nodes (PCCs) in the network about the label- 496 map allocation without setting the C bit as before. 498 All other distributed operations such as nexthop change, protection, 499 etc is handled by the local node as before. 501 5.5.1.2. PCECC SR Adjacency Label allocation 503 For PCECC-SR, apart from node-SID, Adj-SID is used where each 504 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends the 505 PCInitiate message to update the label map of each adjacency to all 506 the nodes in the domain as shown in Figure 3. Each node (PCC) 507 download the label forwarding instructions accordingly. Similar to 508 SR Node/Prefix Label allocation, the PCInitiate message in this case 509 does not use the LSP object but uses the new FEC object defined in 510 this document. 512 +---------+ +-------+ 513 |PCC | | PCE | 514 |192.0.2.3| +-------+ 515 +------| | | 516 | PCC +---------+ | 517 | 192.0.2.2| | | 518 +------| | | | 519 |PCC +----------+ | | 520 |192.0.2.1| | | | 521 +---------+ | | | 522 | | | | 523 |<-------PCInitiate,FEC=198.51.100.1--------------| Label Map 524 | | | 198.51.100.2 | update 525 | | | CC-ID=A | CCI 526 |--------PCRpt,CC-ID=A--------------------------->| 527 | | | | 528 | |<------PCInitiate,FEC=198.51.100.1------| Label Map 529 | | | 198.51.100.2 | update 530 | | | CC-ID=B | CCI 531 | |-------PCRpt,CC-ID=B------------------->| 532 | | | | 533 | | | | 534 | | |<---PCInitiate,FEC=198.51.100.1--| Label Map 535 | | | 198.51.100.2 | update 536 | | | CC-ID=C | CCI 537 | | |-------PCRpt,CC-ID=C------------>| 539 Figure 3 541 The forwarding behavior and the end result is similar to IGP based 542 "Adj-SID" in SR. The Adj-SID is distributed to all nodes to enable 543 SR-TE and TI-LFA. 545 PCE relies on the Adj SID/label clean up using the same PCInitiate 546 message as per [RFC8281]. 548 The above example (Figure 3) depicts FEC object and PCEP speakers 549 that uses an IPv4 address. Similarly an IPv6 address (such as 550 2001:db8::1, 2001:db8::2) can be used during the PCEP session 551 establishment in the FEC object as described in this specification. 553 The handling of adjacencies on the LAN subnetworks is specified in 554 [RFC8402]. PCECC MUST assign Adj-SID for every pair of routers in 555 the LAN. The rest of the protocol mechanism remains the same. 557 In the case where the label/SID map allocation is made by the PCC 558 itself (see Section 5.5.1.6), the PCE could request an allocation to 559 be made by the PCC, and where the PCC would send a PCRpt with the 560 allocated label/SID encoded in the CC-ID object as shown in Figure 4. 562 +---------+ +-------+ 563 |PCC | | PCE | 564 |192.0.2.3| +-------+ 565 +------| | | 566 | PCC +---------+ | 567 | 192.0.2.2| | | 568 +------| | | | 569 |PCC +----------+ | | 570 |192.0.2.1| | | | 571 +---------+ | | | 572 | | | | 573 |<-------PCInitiate,FEC=198.51.100.1--------------| Label Map 574 | | | 198.51.100.2 | request 575 | | | CC-ID=A,C=1 | CCI 576 |--------PCRpt,CC-ID=A,Label--------------------->| 577 | | | | 578 | |<------PCInitiate,FEC=198.51.100.1------| Label Map 579 | | | 198.51.100.2 | update 580 | | | CC-ID=B,Label,C=0 | CCI 581 | |-------PCRpt,CC-ID=B------------------->| 582 | | | | 583 | | |<---PCInitiate,FEC=198.51.100.1--| Label Map 584 | | | 198.51.100.2 | update 585 | | | CC-ID=C,Label,C=0 | CCI 586 | | |-------PCRpt,CC-ID=C------------>| 588 Figure 4 590 In this example (Figure 4), the request is made to the node 192.0.2.1 591 with the C bit set in the CCI object to indicate that the allocation 592 needs to be done by this PCC for the adjacency (198.51.100.1 - 593 198.51.100.2) and it responds with the allocated label/SID to the 594 PCE. The PCE further distribute this to other nodes without setting 595 the C bit as before. 597 5.5.1.3. Redundant PCEs 599 [I-D.ietf-pce-state-sync] describes the synchronization mechanism 600 between the stateful PCEs. The SR SIDs allocated by a PCE MUST also 601 be synchronized among PCEs for PCECC SR state synchronization. Note 602 that the SR SIDs are independent of the SR-TE LSPs, and remains 603 intact till any topology change. The redundant PCEs MUST have a 604 common view of all SR SIDs allocated in the domain. 606 5.5.1.4. Re-Delegation and Clean up 608 As described in [RFC8281], a new PCE can gain control over an 609 orphaned LSP. In the case of a PCECC, the new PCE MUST also gain 610 control over the central controller instructions in the same way by 611 sending a PCInitiate message that includes the SRP, LSP, CCI, and FEC 612 objects and carries the CC-ID and SPEAKER-ENTITY-ID TLV (original 613 PCE) identifying the instruction that it wants to take control of. 615 Further, as described in [RFC8281], the State Timeout Interval timer 616 ensures that a PCE crash does not result in automatic and immediate 617 disruption for the services using PCE-initiated LSPs. Similarly, as 618 per [RFC9050], the central controller instructions are not removed 619 immediately upon PCE failure. Instead, they could be cleaned up on 620 the expiration of this timer. The allows for network clean up 621 without manual intervention. The PCC MUST support the removal of CCI 622 as one of the behaviors applied on expiration of the State Timeout 623 Interval timer. Note that the usual policy would be for the CCI 624 Object-Type=TBD6 remains intact until explicitly removed by a PCE or 625 via manual intervention. 627 5.5.1.5. Synchronization of Label Allocations 629 [RFC9050] describes the synchronization of Central Controller's 630 Instructions (CCI) via LSP state synchronization as described in 631 [RFC8231] and [RFC8232]. Same procedures are applied for the CCI for 632 SR SID as well. 634 5.5.1.6. PCC-Based Allocations 636 The PCE can request the PCC to allocate the label/SID using the 637 PCInitiate message. The C flag in the CCI object is set to 1 to 638 indicate that the allocation needs to be done by the PCC. The PCC 639 would allocate the SID/Label/Index and would report to the PCE using 640 the PCRpt message. 642 If the value of the SID/Label/Index is 0 and the C flag is set to 1, 643 it indicates that the PCE is requesting the allocation to be done by 644 the PCC. If the SID/Label/Index is 'n' and the C flag is set to 1 in 645 the CCI object, it indicates that the PCE requests a specific value 646 'n' for the SID/Label/Index. If the allocation is successful, the 647 PCC should report via PCRpt message with the CCI object. Else, it 648 MUST send a PCErr message with Error-Type = TBD ("PCECC failure") and 649 Error Value = TBD ("Invalid CCI") (defined in [RFC9050]). If the 650 value of the SID/Label/Index in the CCI object is valid, but the PCC 651 is unable to allocate it, it MUST send a PCErr message with Error- 652 Type = TBD ("PCECC failure") and Error Value = TBD ("Unable to 653 allocate the specified CCI") (defined in [RFC9050]). 655 If the PCC wishes to withdraw or modify the previously assigned 656 label/SID, it MUST send a PCRpt message without any SID/Label/Index 657 or with the SID/Label/Index containing the new value respectively in 658 the CCI object. The PCE would further trigger the removal of the 659 central controller instruction as per this document. 661 5.5.1.7. Binding SID 663 A PCECC can allocate and provision the node/prefix/adjacency label 664 (SID) via PCEP. Another SID called binding SID is described in 665 [I-D.ietf-pce-binding-label-sid], the PCECC mechanism can also be 666 used to allocate the binding SID. 668 A procedure for binding label/SID allocation is described in 669 [RFC9050] and is applicable for all path setup types (including SR 670 paths). 672 6. PCEP Messages 674 As defined in [RFC5440], a PCEP message consists of a common header 675 followed by a variable-length body made of a set of objects that can 676 be either mandatory or optional. An object is said to be mandatory 677 in a PCEP message when the object must be included for the message to 678 be considered valid. For each PCEP message type, a set of rules is 679 defined that specify the set of objects that the message can carry. 680 An implementation MUST form the PCEP messages using the object 681 ordering specified in this document. 683 Message formats in this section are presented using Routing Backus- 684 Naur Format (RBNF) as specified in [RFC5511]. 686 6.1. Central Control Instructions 688 6.1.1. The PCInitiate Message 690 The PCInitiate message defined in [RFC8281] and extended in [RFC9050] 691 is further extended to support SR based central control instructions. 693 The format of the extended PCInitiate message is as follows: 695 ::= 696 697 Where: 698 is defined in [RFC5440] 700 ::= 701 [] 703 ::= 704 (| 705 | 706 ) 708 ::= 709 710 (| 711 ( 712 )) 714 ::= 715 [] 717 Where: 718 and 719 are as per 720 [RFC8281]. 722 The LSP and SRP object is defined in [RFC8231]. 724 Figure 5 726 When the PCInitiate message is used to distribute SR SIDs, the SRP, 727 the LSP, the FEC and the CCI object of object-type=TBD6 MUST be 728 present. The error handling for missing SRP, LSP, or CCI object is 729 as per [RFC9050]. If the FEC object is missing, the receiving PCC 730 MUST send a PCErr message with Error-type=6 (Mandatory Object 731 missing) and Error-value=TBD5 (FEC object missing). The LSP Object 732 is included with PLSP-ID set to the reserved value 0. The flags in 733 the LSP object are set as per [RFC8281]. 735 To clean up, the R (remove) bit in the SRP object and the 736 corresponding FEC and the CCI object are included. 738 6.1.2. The PCRpt message 740 The PCRpt message can be used to report the SR central controller 741 instructions received from the PCECC during the state synchronization 742 phase or as an acknowledgment to the PCInitiate message. 744 The format of the PCRpt message is as follows: 746 ::= 747 748 Where: 750 ::= [] 752 ::= (| 753 ) 755 ::= [] 756 757 759 ::= [] 760 761 (| 762 ( 763 )) 765 ::= 766 [] 768 Where: 769 is as per [RFC8231] and the LSP and SRP object are 770 also defined in [RFC8231]. 772 Figure 6 774 When PCRpt message is used to report the label map allocations, the 775 LSP, the FEC, and CCI object of object-type=TBD6 MUST be present. 776 The error handling for the missing LSP and CCI object is as per 777 [RFC9050]. If the FEC object is missing, the receiving PCE MUST send 778 a PCErr message with Error-type=6 (Mandatory Object missing) and 779 Error-value=TBD5 (FEC object missing). The LSP Object is included 780 with PLSP-ID set to the reserved value 0. The flags in the LSP 781 object are set as per [RFC8231] and [RFC8281]. 783 7. PCEP Objects 784 7.1. OPEN Object 786 7.1.1. PCECC Capability sub-TLV 788 [RFC9050] defined the PCECC-CAPABILITY sub-TLV. 790 A new S-bit is added in PCECC-CAPABILITY sub-TLV for PCECC-SR: 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Type=TBD | Length=4 | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Flags |S|L| 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Figure 7 802 [Editor's Note - The above figure is included for ease of the reader 803 but should be removed before publication.] 805 S (PCECC-SR-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP 806 speaker, it indicates that the PCEP speaker is capable of PCECC-SR 807 for SR-MPLS and the PCE allocates the Node and Adj label/SID on this 808 session. 810 7.2. SR-TE Path Setup 812 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. A PST value of 1 is 813 used when Path is setup via SR mode as per [RFC8664]. The procedure 814 for SR-TE path setup as specified in [RFC8664] remains unchanged. 816 7.3. CCI Object 818 The Central Control Instructions (CCI) Object used by the PCE to 819 specify the controller instructions is defined in [RFC9050]. This 820 document defines another object-type for SR-MPLS purpose. 822 CCI Object-Type is TBD6 for SR-MPLS as below - 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | CC-ID | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | MT-ID | Algorithm | Flags |B|P|G|C|N|E|V|L| 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | SID/Label/Index | 831 +---------------------------------------------------------------+ 832 | | 833 // Optional TLV // 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 Figure 8 839 The field CC-ID is as described in [RFC9050]. Following new fields 840 are defined for CCI Object-Type TBD6 - 842 MT-ID: 843 Multi-Topology ID (as defined in [RFC4915]). 845 Algorithm: 846 Single octet identifying the algorithm the SID is associated with. 847 See [RFC8665]. 849 Flags: 850 is used to carry any additional information pertaining to the CCI. 851 The following bits are defined - 853 * L-Bit (Local/Global): If set, then the value/index carried by the 854 CCI object has local significance. If not set, then the value/ 855 index carried by this object has global significance. 857 * V-Bit (Value/Index): If set, then the CCI carries an absolute 858 value. If not set, then the CCI carries an 32-bit index. 860 * E-Bit (Explicit-Null): If set, any upstream neighbor of the node 861 that advertised the SID MUST replace the SID with the Explicit- 862 NULL label (0 for IPv4) before forwarding the packet. 864 * N-Bit (No-PHP): If set, then the penultimate hop MUST NOT pop the 865 SID before delivering packets to the node that advertised the SID. 867 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates that 868 the SR SID/label allocation needs to be done by the PCC for this 869 central controller instruction. A PCE set this bit to request the 870 PCC to make an allocation from its SR label/ID space. A PCC would 871 set this bit to indicate that it has allocated the SR SID/label 872 and report it to the PCE. 874 * Following bits are applicable when the SID represents an Adj-SID 875 only, it MUST be ignored for others - 877 * G-Bit (Group): When set, the G-Flag indicates that the Adj-SID 878 refers to a group of adjacencies (and therefore MAY be assigned to 879 other adjacencies as well). 881 * P-Bit (Persistent): When set, the P-Flag indicates that the Adj-SID 882 is persistently allocated, i.e., the Adj-SID value remains 883 consistent across router restart and/or interface flap. 885 * B-Bit (Backup): If set, the Adj-SID refers to an adjacency that is 886 eligible for protection (e.g., using IP Fast Reroute or MPLS-FRR 887 (MPLS-Fast Reroute) as described in Section 2.1 of [RFC8402]. 889 * All unassigned bits MUST be set to zero at transmission and ignored 890 at receipt. 892 SID/Label/Index: 893 A 32-bit field. According to the V flags, it contains either: 895 * 32-bit SID index defining the offset in the SID/Label space 896 advertised by this router. 898 * A 20-bit label where the 20 rightmost bits are used for encoding 899 the label value. Other bits are ignored. 901 The Address TLVs [RFC9050] could be optionally used in the PCRpt 902 message to include the next-hop information. 904 7.4. FEC Object 906 The FEC Object is used to specify the FEC information and MAY be 907 carried within PCInitiate or PCRpt message. 909 FEC Object-Class is TBD3. 911 The FEC objects are as follows: 913 IPv4 Node ID: where IPv4 Node ID is specified as an IPv4 address of 914 the Node. The FEC Object-type is 1, and the Object-Length is 4 in 915 this case. The object body is same as NAI field of IPv4 Node ID 916 [RFC8664]. 918 IPv6 Node ID: where IPv6 Node ID is specified as an IPv6 address of 919 the Node. The FEC Object-type is 2, and the Object-Length is 16 in 920 this case. The object body is same as NAI field of IPv6 Node ID 921 [RFC8664]. 923 IPv4 Adjacency: where Local and Remote IPv4 address is specified as 924 pair of IPv4 addresses of the adjacency. The FEC Object-type is 3, 925 and the Object-Length is 8 in this case. The object body is same as 926 NAI field of IPv4 Adjacency [RFC8664]. 928 IPv6 Global Adjacency: where Local and Remote global IPv6 address is 929 specified as pair of IPv6 addresses of the adjacency. The FEC 930 Object-type is 4, and the Object-Length is 32 in this case. The 931 object body is same as NAI field of IPv6 Global Adjacency [RFC8664]. 933 Unnumbered Adjacency with IPv4 NodeID: where a pair of Node ID / 934 Interface ID tuple is used. The FEC Object-type is 5, and the 935 Object-Length is 16 in this case. The object body is same as NAI 936 field of Unnumbered Adjacency with IPv4 NodeIDs [RFC8664]. 938 IPv6 Linklocal Adjacency: where a pair of (global IPv6 address, 939 interface ID) tuple is used. The FEC object-type is 6, and the 940 Object-Length is 40 in this case. The object body is same as NAI 941 field of IPv6 Link-Local Adjacency [RFC8664]. 943 8. Implementation Status 945 [Note to the RFC Editor - remove this section before publication, as 946 well as remove the reference to RFC 7942.] 948 This section records the status of known implementations of the 949 protocol defined by this specification at the time of posting of this 950 Internet-Draft, and is based on a proposal described in [RFC7942]. 951 The description of implementations in this section is intended to 952 assist the IETF in its decision processes in progressing drafts to 953 RFCs. Please note that the listing of any individual implementation 954 here does not imply endorsement by the IETF. Furthermore, no effort 955 has been spent to verify the information presented here that was 956 supplied by IETF contributors. This is not intended as, and must not 957 be construed to be, a catalog of available implementations or their 958 features. Readers are advised to note that other implementations may 959 exist. 961 According to [RFC7942], "this will allow reviewers and working groups 962 to assign due consideration to documents that have the benefit of 963 running code, which may serve as evidence of valuable experimentation 964 and feedback that have made the implemented protocols more mature. 965 It is up to the individual working groups to use this information as 966 they see fit". 968 8.1. Huawei's Proof of Concept based on ONOS 970 The PCE function was developed in the ONOS open source platform. 971 This extension was implemented on a private version as a proof of 972 concept for PCECC. 974 * Organization: Huawei 975 * Implementation: Huawei's PoC based on ONOS 976 * Description: PCEP as a southbound plugin was added to ONOS. To 977 support PCECC-SR, an earlier version of this I-D was implemented. 978 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 979 * Maturity Level: Prototype 980 * Coverage: Partial 981 * Contact: satishk@huawei.com 983 9. Security Considerations 985 As per [RFC8283], the security considerations for a PCE-based 986 controller is a little different from those for any other PCE system. 987 That is, the operation relies heavily on the use and security of 988 PCEP, so consideration should be given to the security features 989 discussed in [RFC5440] and the additional mechanisms described in 990 [RFC8253]. It further lists the vulnerability of a central 991 controller architecture, such as a central point of failure, denial- 992 of-service, and a focus for interception and modification of messages 993 sent to individual NEs. 995 The PCECC extension builds on the existing PCEP messages and thus the 996 security considerations described in [RFC5440], [RFC8231], [RFC8281], 997 and [RFC9050] continue to apply. 999 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 1000 be activated on mutually-authenticated and encrypted sessions across 1001 PCEs and PCCs belonging to the same administrative authority, using 1002 Transport Layer Security (TLS) [RFC8253] as per the recommendations 1003 and best current practices in [RFC7525] (unless explicitly set aside 1004 in [RFC8253]). 1006 10. Manageability Considerations 1007 10.1. Control of Function and Policy 1009 A PCE or PCC implementation SHOULD allow to configure to enable/ 1010 disable PCECC SR capability as a global configuration. The 1011 implementation SHOULD also allow setting the local IP address used by 1012 the PCEP session. 1014 10.2. Information and Data Models 1016 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1017 PCECC SR capability status. 1019 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1020 enable/disable PCECC SR capability. 1022 10.3. Liveness Detection and Monitoring 1024 Mechanisms defined in this document do not imply any new liveness 1025 detection and monitoring requirements in addition to those already 1026 listed in [RFC5440]. 1028 10.4. Verify Correct Operations 1030 Mechanisms defined in this document do not imply any new operation 1031 verification requirements in addition to those already listed in 1032 [RFC5440], [RFC8231], and [RFC9050]. 1034 10.5. Requirements On Other Protocols 1036 PCEP extensions defined in this document do not put new requirements 1037 on other protocols. 1039 10.6. Impact On Network Operations 1041 PCEP extensions defined in this document allow SR SID Label 1042 allocation to be done from a central controller and thus simplifying 1043 the initial network operations. 1045 11. IANA Considerations 1047 11.1. PCECC-CAPABILITY sub-TLV 1049 [RFC9050] defines the PCECC-CAPABILITY sub-TLV and requests that IANA 1050 to create a new sub-registry to manage the value of the PCECC- 1051 CAPABILITY sub-TLV's Flag field. 1053 IANA is requested to allocate a new bit in the PCECC-CAPABILITY sub- 1054 TLV Flag Field sub-registry, as follows: 1056 +======+=============+===============+ 1057 | Bit | Description | Reference | 1058 +======+=============+===============+ 1059 | TBD1 | SR-MPLS | This document | 1060 +------+-------------+---------------+ 1062 Table 1: The PCECC-CAPABILITY sub-TLV 1064 11.2. PCEP Object 1066 IANA is requested to allocate new code-points for the new FEC object 1067 and a new Object-Type for CCI object in "PCEP Objects" sub-registry 1068 as follows: 1070 +====================+======+=========================+===========+ 1071 | Object-Class Value | Name | Object-Type | Reference | 1072 +====================+======+=========================+===========+ 1073 | TBD3 | FEC | 1: IPv4 Node ID | This | 1074 | | | | document | 1075 +--------------------+------+-------------------------+-----------+ 1076 | | | 2: IPv6 Node ID | This | 1077 | | | | document | 1078 +--------------------+------+-------------------------+-----------+ 1079 | | | 3: IPv4 Adjacency | This | 1080 | | | | document | 1081 +--------------------+------+-------------------------+-----------+ 1082 | | | 4: IPv6 Global | This | 1083 | | | Adjacency | document | 1084 +--------------------+------+-------------------------+-----------+ 1085 | | | 5: Unnumbered Adjacency | This | 1086 | | | with IPv4 NodeID | document | 1087 +--------------------+------+-------------------------+-----------+ 1088 | | | 6: IPv6 Linklocal | This | 1089 | | | Adjacency | document | 1090 +--------------------+------+-------------------------+-----------+ 1091 | TBD | CCI | | [RFC9050] | 1092 +--------------------+------+-------------------------+-----------+ 1093 | | | TBD6: SR-MPLS | This | 1094 | | | | document | 1095 +--------------------+------+-------------------------+-----------+ 1097 Table 2: The PCEP Objects 1099 11.3. PCEP-Error Object 1101 IANA is requested to allocate a new error-value within the "PCEP- 1102 ERROR Object Error Types and Values" sub-registry of the PCEP Numbers 1103 registry for the following errors: 1105 +============+================+=====================+===========+ 1106 | Error-Type | Meaning | Error-value | Reference | 1107 +============+================+=====================+===========+ 1108 | 6 | Mandatory | TBD5: FEC object | This | 1109 | | Object missing | missing | document | 1110 +------------+----------------+---------------------+-----------+ 1111 | 19 | Invalid | TBD4: SR capability | This | 1112 | | Operation | was not advertised | document | 1113 +------------+----------------+---------------------+-----------+ 1115 Table 3: The PCEP-Error 1117 11.4. CCI Object Flag Field for SR 1119 IANA is requested to create a new sub-registry to manage the Flag 1120 field of the CCI Object-Type=TBD6 for SR called "CCI Object Flag 1121 Field for SR". New values are to be assigned by Standards Action 1122 [RFC8126]. Each bit should be tracked with the following qualities: 1124 * Bit number (counting from bit 0 as the most significant bit) 1125 * Capability description 1126 * Defining RFC 1128 Following bits are defined for the CCI Object flag field for SR in 1129 this document as follows: 1131 +=====+========================+===============+ 1132 | Bit | Description | Reference | 1133 +=====+========================+===============+ 1134 | 0-7 | Unassigned | This document | 1135 +-----+------------------------+---------------+ 1136 | 8 | B-Bit - Backup | This document | 1137 +-----+------------------------+---------------+ 1138 | 9 | P-Bit - Persistent | This document | 1139 +-----+------------------------+---------------+ 1140 | 10 | G-Bit - Group | This document | 1141 +-----+------------------------+---------------+ 1142 | 11 | C-Bit - PCC Allocation | This document | 1143 +-----+------------------------+---------------+ 1144 | 12 | N-Bit - No-PHP | This document | 1145 +-----+------------------------+---------------+ 1146 | 13 | E-Bit - Explicit-Null | This document | 1147 +-----+------------------------+---------------+ 1148 | 14 | V-Bit - Value/Index | This document | 1149 +-----+------------------------+---------------+ 1150 | 15 | L-Bit - Local/Global | This document | 1151 +-----+------------------------+---------------+ 1153 Table 4: The CCI Object Flag Field for SR 1155 12. Acknowledgments 1157 We would like to thank Robert Tao, Changjing Yan, Tieying Huang, 1158 Avantika, and Aijun Wang for their useful comments and suggestions. 1160 Further thanks to Stephane Litkowski, Robert Sawaya, Zafar Ali, and 1161 Mike Koldychev for useful discussion and ideas to improve the 1162 document. 1164 13. Normative References 1166 [I-D.dhodylee-pce-pcep-ls] 1167 Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A., 1168 Mishra, G., and S. Sivabalan, "PCEP extensions for 1169 Distribution of Link-State and TE Information", Work in 1170 Progress, Internet-Draft, draft-dhodylee-pce-pcep-ls-23, 5 1171 March 2022, . 1174 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1175 Requirement Levels", BCP 14, RFC 2119, 1176 DOI 10.17487/RFC2119, March 1997, 1177 . 1179 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1180 (TE) Extensions to OSPF Version 2", RFC 3630, 1181 DOI 10.17487/RFC3630, September 2003, 1182 . 1184 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1185 Support of Generalized Multi-Protocol Label Switching 1186 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1187 . 1189 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1190 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1191 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1192 . 1194 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1195 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1196 2008, . 1198 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1199 in Support of Generalized Multi-Protocol Label Switching 1200 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1201 . 1203 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1204 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1205 DOI 10.17487/RFC5440, March 2009, 1206 . 1208 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1209 S. Ray, "North-Bound Distribution of Link-State and 1210 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1211 DOI 10.17487/RFC7752, March 2016, 1212 . 1214 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1215 Code: The Implementation Status Section", BCP 205, 1216 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1217 . 1219 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1220 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1221 May 2017, . 1223 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1224 Computation Element Communication Protocol (PCEP) 1225 Extensions for Stateful PCE", RFC 8231, 1226 DOI 10.17487/RFC8231, September 2017, 1227 . 1229 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1230 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1231 Path Computation Element Communication Protocol (PCEP)", 1232 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1233 . 1235 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1236 Computation Element Communication Protocol (PCEP) 1237 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1238 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1239 . 1241 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1242 Hardwick, "Conveying Path Setup Type in PCE Communication 1243 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1244 July 2018, . 1246 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1247 and J. Hardwick, "Path Computation Element Communication 1248 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1249 DOI 10.17487/RFC8664, December 2019, 1250 . 1252 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 1253 Computation Element Communication Protocol (PCEP) 1254 Procedures and Extensions for Using the PCE as a Central 1255 Controller (PCECC) of LSPs", RFC 9050, 1256 DOI 10.17487/RFC9050, July 2021, 1257 . 1259 14. Informative References 1261 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 1262 Li, Z., Peng, S., Geng, X., and M. Negi, "Path Computation 1263 Element Communication Protocol (PCEP) Procedures and 1264 Extensions for Using the PCE as a Central Controller 1265 (PCECC) for SRv6 SID Allocation and Distribution.", Work 1266 in Progress, Internet-Draft, draft-dhody-pce-pcep- 1267 extension-pce-controller-srv6-07, 27 August 2021, 1268 . 1271 [I-D.ietf-pce-binding-label-sid] 1272 Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., 1273 and C. L. (editor), "Carrying Binding Label/Segment 1274 Identifier (SID) in PCE-based Networks.", Work in 1275 Progress, Internet-Draft, draft-ietf-pce-binding-label- 1276 sid-14, 3 March 2022, 1277 . 1280 [I-D.ietf-pce-pcep-yang] 1281 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 1282 "A YANG Data Model for Path Computation Element 1283 Communications Protocol (PCEP)", Work in Progress, 1284 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 1285 2022, . 1288 [I-D.ietf-pce-segment-routing-policy-cp] 1289 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 1290 Bidgoli, "PCEP extension to support Segment Routing Policy 1291 Candidate Paths", Work in Progress, Internet-Draft, draft- 1292 ietf-pce-segment-routing-policy-cp-06, 22 October 2021, 1293 . 1296 [I-D.ietf-pce-state-sync] 1297 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 1298 Stateful Path Computation Element (PCE) Communication 1299 Procedures.", Work in Progress, Internet-Draft, draft- 1300 ietf-pce-state-sync-01, 20 October 2021, 1301 . 1304 [I-D.ietf-spring-segment-routing-policy] 1305 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1306 P. Mattes, "Segment Routing Policy Architecture", Work in 1307 Progress, Internet-Draft, draft-ietf-spring-segment- 1308 routing-policy-18, 17 February 2022, 1309 . 1312 [I-D.ietf-teas-pcecc-use-cases] 1313 Li, Z. (., Dhody, D., Zhao, Q., Ke, K., Khasanov, B., 1314 Fang, L., Zhou, C., Zhang, B., Rachitskiy, A., and A. 1315 Gulida, "The Use Cases for Path Computation Element (PCE) 1316 as a Central Controller (PCECC).", Work in Progress, 1317 Internet-Draft, draft-ietf-teas-pcecc-use-cases-08, 25 1318 October 2021, . 1321 [I-D.li-pce-controlled-id-space] 1322 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1323 Controlled ID Space", Work in Progress, Internet-Draft, 1324 draft-li-pce-controlled-id-space-10, 24 February 2022, 1325 . 1328 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1329 Label Switching Architecture", RFC 3031, 1330 DOI 10.17487/RFC3031, January 2001, 1331 . 1333 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1334 Computation Element (PCE)-Based Architecture", RFC 4655, 1335 DOI 10.17487/RFC4655, August 2006, 1336 . 1338 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1339 Used to Form Encoding Rules in Various Routing Protocol 1340 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1341 2009, . 1343 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1344 Margaria, "Requirements for GMPLS Applications of PCE", 1345 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1346 . 1348 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1349 Computation Element Architecture", RFC 7399, 1350 DOI 10.17487/RFC7399, October 2014, 1351 . 1353 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1354 Hardwick, "Path Computation Element Communication Protocol 1355 (PCEP) Management Information Base (MIB) Module", 1356 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1357 . 1359 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1360 Application-Based Network Operations", RFC 7491, 1361 DOI 10.17487/RFC7491, March 2015, 1362 . 1364 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1365 "Recommendations for Secure Use of Transport Layer 1366 Security (TLS) and Datagram Transport Layer Security 1367 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1368 2015, . 1370 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1371 Writing an IANA Considerations Section in RFCs", BCP 26, 1372 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1373 . 1375 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1376 and D. Dhody, "Optimizations of Label Switched Path State 1377 Synchronization Procedures for a Stateful PCE", RFC 8232, 1378 DOI 10.17487/RFC8232, September 2017, 1379 . 1381 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1382 Architecture for Use of PCE and the PCE Communication 1383 Protocol (PCEP) in a Network with Central Control", 1384 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1385 . 1387 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1388 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1389 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1390 July 2018, . 1392 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1393 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1394 Routing with the MPLS Data Plane", RFC 8660, 1395 DOI 10.17487/RFC8660, December 2019, 1396 . 1398 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1399 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1400 Extensions for Segment Routing", RFC 8665, 1401 DOI 10.17487/RFC8665, December 2019, 1402 . 1404 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1405 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1406 Extensions for Segment Routing", RFC 8667, 1407 DOI 10.17487/RFC8667, December 2019, 1408 . 1410 Appendix A. Contributor Addresses 1412 Dhruv Dhody 1413 Huawei Technologies 1414 Divyashree Techno Park, Whitefield 1415 Bangalore, Karnataka 560066 1416 India 1418 EMail: dhruv.ietf@gmail.com 1420 Satish Karunanithi 1421 Huawei Technologies 1422 Divyashree Techno Park, Whitefield 1423 Bangalore, Karnataka 560066 1424 India 1426 EMail: satishk@huawei.com 1428 Adrian Farrel 1429 Old Dog Consulting 1430 UK 1432 EMail: adrian@olddog.co.uk 1434 Xuesong Geng 1435 Huawei Technologies 1436 China 1438 Email: gengxuesong@huawei.com 1440 Udayasree Palle 1442 EMail: udayasreereddy@gmail.com 1444 Katherine Zhao 1445 Huawei Technologies 1446 2330 Central Expressway 1447 Santa Clara, CA 95050 1448 USA 1450 EMail: katherine.zhao@huawei.com 1451 Boris Zhang 1452 Telus Ltd. 1453 Toronto 1454 Canada 1456 EMail: boris.zhang@telus.com 1458 Alex Tokar 1459 Cisco Systems 1460 Slovak Republic 1462 EMail: atokar@cisco.com 1464 Figure 9 1466 Authors' Addresses 1468 Zhenbin Li 1469 Huawei Technologies 1470 Huawei Bld., No.156 Beiqing Rd. 1471 Beijing 1472 100095 1473 China 1474 Email: lizhenbin@huawei.com 1476 Shuping Peng 1477 Huawei Technologies 1478 Huawei Bld., No.156 Beiqing Rd. 1479 Beijing 1480 100095 1481 China 1482 Email: pengshuping@huawei.com 1484 Mahendra Singh Negi 1485 RtBrick Inc 1486 N-17L, 18th Cross Rd, HSR Layout 1487 Bangalore 560102 1488 Karnataka 1489 India 1490 Email: mahend.ietf@gmail.com 1491 Quintin Zhao 1492 Etheric Networks 1493 1009 S CLAREMONT ST 1494 SAN MATEO, CA 94402 1495 United States of America 1496 Email: qzhao@ethericnetworks.com 1498 Chao Zhou 1499 HPE 1500 Email: chaozhou_us@yahoo.com