idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-srv6-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 (27 August 2021) is 971 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) == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-09 == Outdated reference: A later version (-08) exists of draft-ietf-pce-pcep-extension-pce-controller-sr-02 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-07 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-16 == Outdated reference: A later version (-07) exists of draft-ietf-pce-state-sync-00 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-22 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 X. Geng 5 Expires: 28 February 2022 Huawei Technologies 6 M. Negi 7 RtBrick Inc 8 27 August 2021 10 Path Computation Element Communication Protocol (PCEP) Procedures and 11 Extensions for Using the PCE as a Central Controller (PCECC) for SRv6 12 SID Allocation and Distribution. 13 draft-dhody-pce-pcep-extension-pce-controller-srv6-07 15 Abstract 17 The Path Computation Element (PCE) is a core component of Software- 18 Defined Networking (SDN) systems. 20 A PCE-based Central Controller (PCECC) can simplify the processing of 21 a distributed control plane by blending it with elements of SDN and 22 without necessarily completely replacing it. This document specifies 23 the procedures and PCEP extensions when a PCE-based controller is 24 also responsible for configuring the forwarding actions on the 25 routers, in addition to computing the paths for packet flows in the 26 for Segment Routing (SR) in IPv6 (SRv6) network and telling the edge 27 routers what instructions to attach to packets as they enter the 28 network. PCECC is further enhanced for SRv6 SID (Segment Identifier) 29 allocation and distribution. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 28 February 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 3. PCECC SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Procedures for Using the PCE as a Central Controller (PCECC) in 70 SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 72 5.2. New Functions . . . . . . . . . . . . . . . . . . . . . . 6 73 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 74 5.4. PCEP session IP address and TED Router ID . . . . . . . . 7 75 5.5. SRv6 Path Operations . . . . . . . . . . . . . . . . . . 7 76 5.5.1. PCECC Segment Routing in IPv6 (SRv6) . . . . . . . . 8 77 5.5.1.1. PCECC SRv6 Node/Prefix SID allocation . . . . . . 8 78 5.5.1.2. PCECC SRv6 Adjacency SID allocation . . . . . . . 9 79 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 9 80 5.5.1.4. Re-Delegation and Cleanup . . . . . . . . . . . . 9 81 5.5.1.5. Synchronization of SRv6 SID Allocations . . . . . 9 82 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 9 83 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 10 84 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 10 85 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 10 86 7.2. SRv6 Path Setup . . . . . . . . . . . . . . . . . . . . . 10 87 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 88 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 11 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 9. Manageability Considerations . . . . . . . . . . . . . . . . 12 91 9.1. Control of Function and Policy . . . . . . . . . . . . . 12 92 9.2. Information and Data Models . . . . . . . . . . . . . . . 12 93 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 94 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 13 95 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 13 96 9.6. Impact On Network Operations . . . . . . . . . . . . . . 13 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 98 10.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 13 99 10.2. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 13 100 10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 14 101 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 104 12.2. Informative References . . . . . . . . . . . . . . . . . 15 105 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 18 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 The Path Computation Element (PCE) [RFC4655] was developed to offload 111 the path computation function from routers in an MPLS traffic- 112 engineered (TE) network. It can compute optimal paths for traffic 113 across a network and can also update the paths to reflect changes in 114 the network or traffic demands. Since then, the role and function of 115 the PCE have grown to cover a number of other uses (such as GMPLS 116 [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated 117 use of network resources [RFC8281]. 119 According to [RFC7399], Software-Defined Networking (SDN) refers to a 120 separation between the control elements and the forwarding components 121 so that software running in a centralized system, called a 122 controller, can act to program the devices in the network to behave 123 in specific ways. A required element in an SDN architecture is a 124 component that plans how the network resources will be used and how 125 the devices will be programmed. It is possible to view this 126 component as performing specific computations to place traffic flows 127 within the network given knowledge of the availability of network 128 resources, how other forwarding devices are programmed, and the way 129 that other flows are routed. This is the function and purpose of a 130 PCE, and the way that a PCE integrates into a wider network control 131 system (including an SDN system) is presented in [RFC7491]. 133 In early PCE implementations, where the PCE was used to derive paths 134 for MPLS Label Switched Paths (LSPs), paths were requested by network 135 elements (known as Path Computation Clients (PCCs)), and the results 136 of the path computations were supplied to network elements using the 137 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 138 This protocol was later extended to allow a PCE to send unsolicited 139 requests to the network for LSP establishment [RFC8281]. 141 [RFC8283] introduces the architecture for PCE as a central controller 142 as an extension of the architecture described in [RFC4655] and 143 assumes the continued use of PCEP as the protocol used between PCE 144 and PCC. [RFC8283] further examines the motivations and 145 applicability for PCEP as a Southbound Interface (SBI), and 146 introduces the implications for the protocol. 147 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 148 architecture. 150 [RFC9050] specify the procedures and PCEP extensions for using the 151 PCE as the central controller for static LSPs, where LSPs can be 152 provisioned as explicit label instructions at each hop on the end-to- 153 end path. 155 Segment Routing (SR) technology leverages the source routing and 156 tunneling paradigms. A source node can choose a path without relying 157 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 158 is specified as a set of "segments" advertised by link-state routing 159 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to SR 160 architecture. The corresponding IS-IS and OSPF extensions are 161 specified in [RFC8667] and [RFC8665] , respectively. It relies on a 162 series of forwarding instructions being placed in the header of a 163 packet. The list of segments forming the path is called the Segment 164 List and is encoded in the packet header. Segment Routing can be 165 applied to the IPv6 architecture with the Segment Routing Header 166 (SRH) [RFC8754]. A segment is encoded as an IPv6 address. An 167 ordered list of segments is encoded as an ordered list of IPv6 168 addresses in the routing header. The active segment is indicated by 169 the Destination Address of the packet. Upon completion of a segment, 170 a pointer in the new routing header is incremented and indicates the 171 next segment. The segment routing architecture supports operations 172 that can be used to steer packet flows in a network, thus providing a 173 form of traffic engineering. [RFC8664] and 174 [I-D.ietf-pce-segment-routing-ipv6] specify the SR specific PCEP 175 extensions. 177 PCECC may further use PCEP for SR SID (Segment Identifier) allocation 178 and distribution to all the SR nodes with some benefits. The SR 179 nodes continue to rely on IGP for distributed computation (nexthop 180 selection, protection etc) where PCE (and PCEP) does only the 181 allocation and distribution of SRv6 SIDs in the network. Note that 182 the topology at PCE is still learned via existing mechanisms. 184 [I-D.ietf-pce-pcep-extension-pce-controller-sr] specifies the 185 procedures and PCEP extensions when a PCE-based controller is also 186 responsible for configuring the forwarding actions on the routers 187 (SR-MPLS SID distribution), in addition to computing the paths for 188 packet flows in a segment routing network and telling the edge 189 routers what instructions to attach to packets as they enter the 190 network. This document extends this to include SRv6 SID distribution 191 as well. 193 2. Terminology 195 Terminologies used in this document is the same as described in the 196 document [RFC8283]. 198 2.1. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in BCP 203 14 [RFC2119] [RFC8174] when, and only when, they appear in all 204 capitals, as shown here. 206 3. PCECC SRv6 208 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 209 compute, update, or initiate SR-TE paths for MPLS dataplane. An 210 ingress node of an SR-TE path appends all outgoing packets with a 211 list of MPLS labels (SIDs). This is encoded in SR-ERO subobject, 212 capable of carrying a label (SID) as well as the identity of the 213 node/adjacency label (SID). [I-D.ietf-pce-segment-routing-ipv6] 214 extends the procedure to include support for SRv6 paths. 216 As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or 217 simply "SID" are often used as a shorter reference for "SRv6 218 Segment". Further details are in an illustration provided in 219 [RFC8986]. The SR is applied to IPV6 data plane using SRH. An SR 220 path can be derived from an IGP Shortest Path Tree (SPT), but SR-TE 221 paths may not follow IGP SPT. Such paths may be chosen by a suitable 222 network planning tool, or a PCE and provisioned on the ingress node. 223 [I-D.ietf-pce-segment-routing-ipv6] specify the SRv6-ERO subobject 224 capable of carrying an SRv6 SID as well as the identity of the node/ 225 adjacency represented by the SID. 227 [RFC8283] examines the motivations and applicability for PCECC and 228 use of PCEP as an SBI. Section 3.1.5. of [RFC8283] highlights the 229 use of PCECC for configuring the forwarding actions on the routers 230 and assume responsibility for managing the identifier space. It 231 simplifies the processing of a distributed control plane by blending 232 it with elements of SDN and without necessarily completely replacing 233 it. This allows the operator to introduce the advantages of SDN 234 (such as programmability) into the network. Further Section 3.3. of 235 [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where 236 the PCECC technique could be useful. Section 4 of [RFC8283] also 237 describe the implications on the protocol when used as an SDN SBI. 238 The operator needs to evaluate the advantages offered by PCECC 239 against the operational and scalability needs of the PCECC. 241 As per [RFC8283], PCECC can allocate and provision the node/prefix/ 242 adjacency label (SID) via PCEP. As per 243 [I-D.ietf-teas-pcecc-use-cases] this is also applicable to SRv6 SIDs. 245 The rest of the processing is similar to existing stateful PCE for 246 SRv6 [I-D.ietf-pce-segment-routing-ipv6]. 248 4. PCEP Requirements 250 Following key requirements for PCECC-SRv6 should be considered when 251 designing the PCECC-based solution: 253 * A PCEP speaker supporting this document needs to have the 254 capability to advertise its PCECC-SRv6 capability to its peers. 256 * PCEP procedures need to allow for PCC-based SRv6 SID allocations. 258 * PCEP procedures need to provide a means to update (or clean up) 259 the SRv6 SID to the PCC. 261 * PCEP procedures need to provide a means to synchronize the SRv6 262 SID allocations between the PCE to the PCC in the PCEP messages. 264 5. Procedures for Using the PCE as a Central Controller (PCECC) in SRv6 266 5.1. Stateful PCE Model 268 Active stateful PCE is described in [RFC8231]. A PCE as a Central 269 Controller (PCECC) reuses the existing active stateful PCE mechanism 270 as much as possible to control the LSPs. 272 5.2. New Functions 274 This document uses the same PCEP messages and its extensions which 275 are described in [RFC9050] and 276 [I-D.ietf-pce-pcep-extension-pce-controller-sr] for PCECC-SRv6 as 277 well. 279 The PCEP messages PCRpt, PCInitiate, PCUpd are used to send LSP 280 Reports, LSP setup, and LSP update respectively. The extended 281 PCInitiate message described in [RFC9050] is used to download or 282 clean up CCIs (a new CCI Object-Type=TBD3 for SRv6 SID). The 283 extended PCRpt message described in [RFC9050] is also used to report 284 the CCIs (SRv6 SIDs) from PCC to PCE. 286 [RFC9050] specify an object called CCI for the encoding of the 287 central controller's instructions. 288 [I-D.ietf-pce-pcep-extension-pce-controller-sr] defined a CCI object- 289 type for SR-MPLS. This document further defines a new CCI object- 290 type=TBD3 for SRv6. 292 5.3. PCECC Capability Advertisement 294 During the PCEP initialization phase, PCEP speakers (PCE or PCC) 295 advertise their support of and willingness to use PCEP extensions for 296 the PCECC. A PCEP speaker includes the PCECC-CAPABILITY sub-TLV in 297 the PATH-SETUP-TYPE-CAPABILITY TLV as per [RFC9050]. 299 A new S bit is added in the PCECC-CAPABILITY sub-TLV to indicate 300 support for PCECC-SR-MPLS in 301 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. This document adds 302 another I bit to indicate support for SR in IPv6. A PCC MUST set the 303 I bit in the PCECC-CAPABILITY sub-TLV and include the SRv6-PCE- 304 CAPABILITY sub-TLV ([I-D.ietf-pce-segment-routing-ipv6]) in the OPEN 305 object (inside the PATH-SETUP-TYPE-CAPABILITY TLV) to support the 306 PCECC SRv6 extensions defined in this document. 308 If the I bit is set in PCECC-CAPABILITY sub-TLV and the SRv6-PCE- 309 CAPABILITY sub-TLV is not advertised, or is advertised without the I 310 bit set, in the OPEN object, the receiver MUST: 312 * send a PCErr message with Error-Type=19 (Invalid Operation) and 313 Error-value=TBD4 (SRv6 capability was not advertised) and 315 * terminate the session. 317 The rest of the processing is as per [RFC9050] and 318 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 320 5.4. PCEP session IP address and TED Router ID 322 As described in [I-D.ietf-pce-pcep-extension-pce-controller-sr], it 323 is important to link the session IP address with the Router ID in TED 324 for successful PCECC-SRv6 operations. 326 5.5. SRv6 Path Operations 328 [RFC8664] specify the PCEP extension to allow a stateful PCE to 329 compute and initiate SR-TE paths, as well as a PCC to request a path 330 subject to certain constraint(s) and optimization criteria in SR 331 networks. [I-D.ietf-pce-segment-routing-ipv6] extends it to support 332 SRv6. 334 The Path Setup Type for SRv6 (PST=TBD) is used on the PCEP session 335 with the Ingress as per [I-D.ietf-pce-segment-routing-ipv6]. 337 5.5.1. PCECC Segment Routing in IPv6 (SRv6) 339 Segment Routing (SR) as described in [RFC8402] depends on "segments" 340 that are advertised by Interior Gateway Protocols (IGPs). The SR- 341 node allocates and advertises the SID (node, adj, etc) and floods 342 them via the IGP. This document proposes a new mechanism where PCE 343 allocates the SRv6 SID centrally and uses PCEP to distribute them to 344 all nodes. In some deployments, PCE (and PCEP) are better suited 345 than IGP because of the centralized nature of PCE and direct TCP 346 based PCEP sessions to the node. Note that only the SRv6 SID 347 allocation and distribution is done by the PCEP, all other SRv6 348 operations (nexthop selection, protection, etc) are still done by the 349 node (and the IGPs). 351 5.5.1.1. PCECC SRv6 Node/Prefix SID allocation 353 Each node (PCC) is allocated a node SRv6 SID by the PCECC. The PCECC 354 sends the PCInitiate message to update the SRv6 SID table of each 355 node. The TE router ID is determined from the TED or from "IPv4/IPv6 356 Router-ID" sub-TLV [I-D.dhodylee-pce-pcep-ls], in the OPEN Object. 358 On receiving the SRv6 node SID allocation, each node (PCC) uses the 359 local routing information to determine the next-hop and download the 360 forwarding instructions accordingly. The PCInitiate message uses the 361 FEC object [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 363 On receiving the SRv6 node SID allocation: 365 For the local SID, the node (PCC) needs to update SID with 366 associated function (END function in this case) in "My Local SID 367 Table" ([RFC8986]). 369 For the non-local SID, the node (PCC) uses the local routing 370 information to determine the next-hop and download the forwarding 371 instructions accordingly. 373 The forwarding behavior and the end result is similar to IGP based 374 "Node-SID" in SRv6. Thus, from anywhere in the domain, it enforces 375 the ECMP-aware shortest-path forwarding of the packet towards the 376 related node as per [RFC8402]. 378 PCE relies on the Node/Prefix SRv6 SID clean up using the same 379 PCInitiate message as per [RFC8281]. 381 5.5.1.2. PCECC SRv6 Adjacency SID allocation 383 For PCECC-SRv6, apart from node-SID, Adj-SID is used where each 384 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 385 PCInitiate message to update the SRv6 SID entry for each adjacency to 386 all nodes in the domain. Each node (PCC) download the SRv6 SID 387 instructions accordingly. Similar to SRv6 Node/Prefix Label 388 allocation, the PCInitiate message in this case uses the FEC object. 390 The forwarding behavior and the end result is similar to IGP based 391 "Adj-SID" in SRv6 as per [RFC8402]. 393 The handling of adjacencies on the LAN subnetworks is specified in 394 [RFC8402]. PCECC MUST assign Adj-SID for every pair of routers in 395 the LAN. The rest of the protocol mechanism remains the same. 397 PCE relies on the Adj label clean up using the same PCInitiate 398 message as per [RFC8281]. 400 5.5.1.3. Redundant PCEs 402 [I-D.ietf-pce-state-sync] describes the synchronization mechanism 403 between the stateful PCEs. The SRv6 SIDs allocated by a PCE MUST 404 also be synchronized among PCEs for PCECC-SRv6 state synchronization. 405 Note that the SRv6 SIDs are independent of the SRv6 paths, and 406 remains intact till any topology change. The redundant PCEs MUST 407 have a common view of all SRv6 SIDs allocated in the domain. 409 5.5.1.4. Re-Delegation and Cleanup 411 [RFC9050] describes the action needed for CCIs for the static LSPs on 412 a terminated session. Same holds true for the CCI for SRv6 SID as 413 well. 415 5.5.1.5. Synchronization of SRv6 SID Allocations 417 [RFC9050] describes the synchronization of CCIs via the LSP state 418 synchronization as described in [RFC8231] and [RFC8232]. Same 419 procedures are applied for the SRv6 SID CCIs. 421 6. PCEP Messages 423 The PCEP messages are as per 424 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 426 7. PCEP Objects 428 7.1. OPEN Object 430 7.1.1. PCECC Capability sub-TLV 432 [RFC9050] defined the PCECC-CAPABILITY sub-TLV. 434 A new I-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SRv6: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type=TBD | Length=4 | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Flags |I|S|L| 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 [Editor's Note - The above figure is included for ease of the reader 445 but should be removed before publication.] 447 I (PCECC-SRv6-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP 448 speaker, it indicates that the PCEP speaker is capable of PCECC-SRv6 449 capability and the PCE allocates the Node and Adj SRv6 SID on this 450 session. 452 7.2. SRv6 Path Setup 454 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. A PST value of TBD 455 is used when Path is setup via SRv6 mode as per 456 [I-D.ietf-pce-segment-routing-ipv6]. The procedure for SRv6 path 457 setup as specified in [I-D.ietf-pce-segment-routing-ipv6] remains 458 unchanged. 460 7.3. CCI Object 462 The Central Control Instructions (CCI) Object is used by the PCE to 463 specify the controller instructions is defined in [RFC9050]. This 464 document defines another object-type for SRv6 purpose. 466 CCI Object-Type is TBD3 for SRv6 as below - 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | CC-ID | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | MT-ID | Algorithm | Flags |B|P|G|C|N|E|V|L| 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Reserved | SRv6 Endpoint Function | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 | SRv6 Identifier | 478 | (128-bit) | 479 | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | SID | 482 | Structure | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 // Optional TLV // 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 The field CC-ID is as described in [RFC9050]. The field MT-ID, 490 Algorithm, Flags are defined in 491 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 493 Reserved: MUST be set to 0 while sending and ignored on receipt. 495 SRv6 Endpoint Function: 16-bit field representing supported functions 496 associated with SRv6 SIDs. 498 SRv6 Identifier: 128-bit IPv6 addresses representing SRv6 segment. 500 SID Structure: 64-bit field formatted as per "SID Structure" in 501 [I-D.ietf-pce-segment-routing-ipv6]. 503 7.4. FEC Object 505 The FEC Object is used to specify the FEC information and MAY be 506 carried within PCInitiate or PCRpt message. 508 FEC Object (and various Object-Types) are described in 509 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. SRv6 Node SID MUST 510 includes the FEC Object-Type 2 for IPv6 Node. SRv6 Adjacency SID 511 MUST include the FEC Object-Type=4 for IPv6 adjacency. Further FEC 512 object types could be added in future extensions. 514 8. Security Considerations 516 As per [RFC8283], the security considerations for a PCE-based 517 controller are a little different from those for any other PCE 518 system. That is, the operation relies heavily on the use and 519 security of PCEP, so consideration should be given to the security 520 features discussed in [RFC5440] and the additional mechanisms 521 described in [RFC8253]. It further lists the vulnerability of a 522 central controller architecture, such as a central point of failure, 523 denial of service, and a focus for interception and modification of 524 messages sent to individual Network Elements (NEs). 526 The PCECC extension builds on the existing PCEP messages; thus, the 527 security considerations described in [RFC5440], [RFC8231], [RFC8281], 528 [RFC9050], and [I-D.ietf-pce-pcep-extension-pce-controller-sr] 529 continue to apply. 531 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 532 be activated on mutually-authenticated and encrypted sessions across 533 PCEs and PCCs belonging to the same administrative authority, using 534 Transport Layer Security (TLS) [RFC8253] as per the recommendations 535 and best current practices in [RFC7525] (unless explicitly set aside 536 in [RFC8253]). 538 9. Manageability Considerations 540 9.1. Control of Function and Policy 542 A PCE or PCC implementation SHOULD allow to configure to enable/ 543 disable PCECC SRv6 capability as a global configuration. 545 9.2. Information and Data Models 547 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 548 PCECC SRv6 capability status. 550 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 551 enable/disable PCECC SRv6 capability. 553 9.3. Liveness Detection and Monitoring 555 Mechanisms defined in this document do not imply any new liveness 556 detection and monitoring requirements in addition to those already 557 listed in [RFC5440]. 559 9.4. Verify Correct Operations 561 Mechanisms defined in this document do not imply any new operation 562 verification requirements in addition to those already listed in 563 [RFC5440] and [RFC8231]. 565 9.5. Requirements On Other Protocols 567 PCEP extensions defined in this document do not put new requirements 568 on other protocols. 570 9.6. Impact On Network Operations 572 PCEP implementation SHOULD allow a limit to be placed on the rate of 573 PCInitiate/PCUpd messages (as per [RFC8231]) sent by PCE and 574 processed by PCC. It SHOULD also allow sending a notification when a 575 rate threshold is reached. 577 10. IANA Considerations 579 10.1. PCECC-CAPABILITY sub-TLV 581 [RFC9050] defines the PCECC-CAPABILITY sub-TLV and requests that IANA 582 creates a registry to manage the value of the PCECC-CAPABILITY sub- 583 TLV's Flag field. IANA is requested to allocate a new bit in the 584 PCECC-CAPABILITY sub-TLV Flag Field registry, as follows: 586 +======+=============+===============+ 587 | Bit | Description | Reference | 588 +======+=============+===============+ 589 | TBD1 | SRv6 | This document | 590 +------+-------------+---------------+ 592 Table 1 594 10.2. PCEP Object 596 IANA is requested to allocate a new code-point for the new CCI 597 object-type in "PCEP Objects" sub-registry as follows: 599 +====================+======+=============+===============+ 600 | Object-Class Value | Name | Object-Type | Reference | 601 +====================+======+=============+===============+ 602 | TBD | CCI | | [RFC9050] | 603 +--------------------+------+-------------+---------------+ 604 | | | TBD3: SRv6 | This document | 605 +--------------------+------+-------------+---------------+ 607 Table 2 609 10.3. PCEP-Error Object 611 IANA is requested to allocate new error types and error values within 612 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 613 PCEP Numbers registry for the following errors: 615 Error-Type Meaning 616 ---------- ------- 617 19 Invalid operation. 618 Error-value = TBD4 : SRv6 capability was 619 not advertised 621 The Reference is marked as "This document". 623 11. Acknowledgments 625 12. References 627 12.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, 631 DOI 10.17487/RFC2119, March 1997, 632 . 634 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 635 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 636 DOI 10.17487/RFC5440, March 2009, 637 . 639 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 640 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 641 May 2017, . 643 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 644 Computation Element Communication Protocol (PCEP) 645 Extensions for Stateful PCE", RFC 8231, 646 DOI 10.17487/RFC8231, September 2017, 647 . 649 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 650 Computation Element Communication Protocol (PCEP) 651 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 652 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 653 . 655 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 656 and J. Hardwick, "Path Computation Element Communication 657 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 658 DOI 10.17487/RFC8664, December 2019, 659 . 661 [I-D.ietf-pce-segment-routing-ipv6] 662 Li(Editor), C., Negi, M. S., Sivabalan, S., Koldychev, M., 663 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 664 Routing leveraging the IPv6 data plane", Work in Progress, 665 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27 666 May 2021, . 669 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 670 Computation Element Communication Protocol (PCEP) 671 Procedures and Extensions for Using the PCE as a Central 672 Controller (PCECC) of LSPs", RFC 9050, 673 DOI 10.17487/RFC9050, July 2021, 674 . 676 [I-D.ietf-pce-pcep-extension-pce-controller-sr] 677 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 678 "PCEP Procedures and Protocol Extensions for Using PCE as 679 a Central Controller (PCECC) for Segment Routing (SR) MPLS 680 Segment Identifier (SID) Allocation and Distribution.", 681 Work in Progress, Internet-Draft, draft-ietf-pce-pcep- 682 extension-pce-controller-sr-02, 25 March 2021, 683 . 686 12.2. Informative References 688 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 689 Computation Element (PCE)-Based Architecture", RFC 4655, 690 DOI 10.17487/RFC4655, August 2006, 691 . 693 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 694 Margaria, "Requirements for GMPLS Applications of PCE", 695 RFC 7025, DOI 10.17487/RFC7025, September 2013, 696 . 698 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 699 Computation Element Architecture", RFC 7399, 700 DOI 10.17487/RFC7399, October 2014, 701 . 703 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 704 Hardwick, "Path Computation Element Communication Protocol 705 (PCEP) Management Information Base (MIB) Module", 706 RFC 7420, DOI 10.17487/RFC7420, December 2014, 707 . 709 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 710 Application-Based Network Operations", RFC 7491, 711 DOI 10.17487/RFC7491, March 2015, 712 . 714 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 715 "Recommendations for Secure Use of Transport Layer 716 Security (TLS) and Datagram Transport Layer Security 717 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 718 2015, . 720 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 721 and D. Dhody, "Optimizations of Label Switched Path State 722 Synchronization Procedures for a Stateful PCE", RFC 8232, 723 DOI 10.17487/RFC8232, September 2017, 724 . 726 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 727 "PCEPS: Usage of TLS to Provide a Secure Transport for the 728 Path Computation Element Communication Protocol (PCEP)", 729 RFC 8253, DOI 10.17487/RFC8253, October 2017, 730 . 732 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 733 Architecture for Use of PCE and the PCE Communication 734 Protocol (PCEP) in a Network with Central Control", 735 RFC 8283, DOI 10.17487/RFC8283, December 2017, 736 . 738 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 739 Decraene, B., Litkowski, S., and R. Shakir, "Segment 740 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 741 July 2018, . 743 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 744 Hardwick, "Conveying Path Setup Type in PCE Communication 745 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 746 July 2018, . 748 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 749 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 750 Extensions for Segment Routing", RFC 8665, 751 DOI 10.17487/RFC8665, December 2019, 752 . 754 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 755 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 756 Extensions for Segment Routing", RFC 8667, 757 DOI 10.17487/RFC8667, December 2019, 758 . 760 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 761 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 762 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 763 . 765 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 766 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 767 (SRv6) Network Programming", RFC 8986, 768 DOI 10.17487/RFC8986, February 2021, 769 . 771 [I-D.ietf-teas-pcecc-use-cases] 772 Li, Z. (., Dhody, D., Zhao, Q., Ke, K., Khasanov, B., 773 Fang, L., Zhou, C., Zhang, B., Rachitskiy, A., and A. 774 Gulida, "The Use Cases for Path Computation Element (PCE) 775 as a Central Controller (PCECC).", Work in Progress, 776 Internet-Draft, draft-ietf-teas-pcecc-use-cases-07, 8 777 March 2021, . 780 [I-D.ietf-pce-pcep-yang] 781 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 782 "A YANG Data Model for Path Computation Element 783 Communications Protocol (PCEP)", Work in Progress, 784 Internet-Draft, draft-ietf-pce-pcep-yang-16, 22 February 785 2021, . 788 [I-D.ietf-pce-state-sync] 789 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 790 Stateful Path Computation Element (PCE) Communication 791 Procedures.", Work in Progress, Internet-Draft, draft- 792 ietf-pce-state-sync-00, 28 June 2021, 793 . 796 [I-D.dhodylee-pce-pcep-ls] 797 Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A., 798 Mishra, G., and S. Sivabalan, "PCEP extensions for 799 Distribution of Link-State and TE Information", Work in 800 Progress, Internet-Draft, draft-dhodylee-pce-pcep-ls-22, 801 25 August 2021, . 804 Appendix A. Contributor Addresses 806 Dhruv Dhody 807 Huawei Technologies 808 Divyashree Techno Park, Whitefield 809 Bangalore, Karnataka 560066 810 India 812 EMail: dhruv.ietf@gmail.com 814 Authors' Addresses 816 Zhenbin Li 817 Huawei Technologies 818 Huawei Bld., No.156 Beiqing Rd. 819 Beijing 820 100095 821 China 823 Email: lizhenbin@huawei.com 824 Shuping Peng 825 Huawei Technologies 826 Huawei Bld., No.156 Beiqing Rd. 827 Beijing 828 100095 829 China 831 Email: pengshuping@huawei.com 833 Xuesong Geng 834 Huawei Technologies 835 China 837 Email: gengxuesong@huawei.com 839 Mahendra Singh Negi 840 RtBrick Inc 841 N-17L, 18th Cross Rd, HSR Layout 842 Bangalore 560102 843 Karnataka 844 India 846 Email: mahend.ietf@gmail.com