idnits 2.17.00 (12 Aug 2021) /tmp/idnits33349/draft-dhody-pce-pcep-extension-pce-controller-srv6-08.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) == Outdated reference: A later version (-13) exists of draft-ietf-pce-segment-routing-ipv6-11 == Outdated reference: A later version (-09) exists of draft-ietf-teas-pcecc-use-cases-08 == Outdated reference: A later version (-02) exists of draft-ietf-pce-state-sync-01 Summary: 0 errors (**), 0 flaws (~~), 3 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 X. Geng 5 Expires: 7 September 2022 Huawei Technologies 6 M. Negi 7 RtBrick Inc 8 6 March 2022 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-08 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 7 September 2022. 48 Copyright Notice 50 Copyright (c) 2022 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 Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised 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 . . . . . . . . . . . . 13 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 103 11.2. Informative References . . . . . . . . . . . . . . . . . 15 104 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 18 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 107 1. Introduction 109 The Path Computation Element (PCE) [RFC4655] was developed to offload 110 the path computation function from routers in an MPLS traffic- 111 engineered (TE) network. It can compute optimal paths for traffic 112 across a network and can also update the paths to reflect changes in 113 the network or traffic demands. Since then, the role and function of 114 the PCE have grown to cover a number of other uses (such as GMPLS 115 [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated 116 use of network resources [RFC8281]. 118 According to [RFC7399], Software-Defined Networking (SDN) refers to a 119 separation between the control elements and the forwarding components 120 so that software running in a centralized system, called a 121 controller, can act to program the devices in the network to behave 122 in specific ways. A required element in an SDN architecture is a 123 component that plans how the network resources will be used and how 124 the devices will be programmed. It is possible to view this 125 component as performing specific computations to place traffic flows 126 within the network given knowledge of the availability of network 127 resources, how other forwarding devices are programmed, and the way 128 that other flows are routed. This is the function and purpose of a 129 PCE, and the way that a PCE integrates into a wider network control 130 system (including an SDN system) is presented in [RFC7491]. 132 In early PCE implementations, where the PCE was used to derive paths 133 for MPLS Label Switched Paths (LSPs), paths were requested by network 134 elements (known as Path Computation Clients (PCCs)), and the results 135 of the path computations were supplied to network elements using the 136 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 137 This protocol was later extended to allow a PCE to send unsolicited 138 requests to the network for LSP establishment [RFC8281]. 140 [RFC8283] introduces the architecture for PCE as a central controller 141 as an extension of the architecture described in [RFC4655] and 142 assumes the continued use of PCEP as the protocol used between PCE 143 and PCC. [RFC8283] further examines the motivations and 144 applicability for PCEP as a Southbound Interface (SBI), and 145 introduces the implications for the protocol. 146 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 147 architecture. 149 [RFC9050] specify the procedures and PCEP extensions for using the 150 PCE as the central controller for static LSPs, where LSPs can be 151 provisioned as explicit label instructions at each hop on the end-to- 152 end path. 154 Segment Routing (SR) technology leverages the source routing and 155 tunneling paradigms. A source node can choose a path without relying 156 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 157 is specified as a set of "segments" advertised by link-state routing 158 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to SR 159 architecture. The corresponding IS-IS and OSPF extensions are 160 specified in [RFC8667] and [RFC8665] , respectively. It relies on a 161 series of forwarding instructions being placed in the header of a 162 packet. The list of segments forming the path is called the Segment 163 List and is encoded in the packet header. Segment Routing can be 164 applied to the IPv6 architecture with the Segment Routing Header 165 (SRH) [RFC8754]. A segment is encoded as an IPv6 address. An 166 ordered list of segments is encoded as an ordered list of IPv6 167 addresses in the routing header. The active segment is indicated by 168 the Destination Address of the packet. Upon completion of a segment, 169 a pointer in the new routing header is incremented and indicates the 170 next segment. The segment routing architecture supports operations 171 that can be used to steer packet flows in a network, thus providing a 172 form of traffic engineering. [RFC8664] and 173 [I-D.ietf-pce-segment-routing-ipv6] specify the SR specific PCEP 174 extensions. 176 PCECC may further use PCEP for SR SID (Segment Identifier) allocation 177 and distribution to all the SR nodes with some benefits. The SR 178 nodes continue to rely on IGP for distributed computation (nexthop 179 selection, protection etc) where PCE (and PCEP) does only the 180 allocation and distribution of SRv6 SIDs in the network. Note that 181 the topology at PCE is still learned via existing mechanisms. 183 [I-D.ietf-pce-pcep-extension-pce-controller-sr] specifies the 184 procedures and PCEP extensions when a PCE-based controller is also 185 responsible for configuring the forwarding actions on the routers 186 (SR-MPLS SID distribution), in addition to computing the paths for 187 packet flows in a segment routing network and telling the edge 188 routers what instructions to attach to packets as they enter the 189 network. This document extends this to include SRv6 SID distribution 190 as well. 192 2. Terminology 194 Terminologies used in this document is the same as described in the 195 document [RFC8283]. 197 2.1. Requirements Language 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described in BCP 202 14 [RFC2119] [RFC8174] when, and only when, they appear in all 203 capitals, as shown here. 205 3. PCECC SRv6 207 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 208 compute, update, or initiate SR-TE paths for MPLS dataplane. An 209 ingress node of an SR-TE path appends all outgoing packets with a 210 list of MPLS labels (SIDs). This is encoded in SR-ERO subobject, 211 capable of carrying a label (SID) as well as the identity of the 212 node/adjacency label (SID). [I-D.ietf-pce-segment-routing-ipv6] 213 extends the procedure to include support for SRv6 paths. 215 As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or 216 simply "SID" are often used as a shorter reference for "SRv6 217 Segment". Further details are in an illustration provided in 218 [RFC8986]. The SR is applied to IPV6 data plane using SRH. An SR 219 path can be derived from an IGP Shortest Path Tree (SPT), but SR-TE 220 paths may not follow IGP SPT. Such paths may be chosen by a suitable 221 network planning tool, or a PCE and provisioned on the ingress node. 222 [I-D.ietf-pce-segment-routing-ipv6] specify the SRv6-ERO subobject 223 capable of carrying an SRv6 SID as well as the identity of the node/ 224 adjacency represented by the SID. 226 [RFC8283] examines the motivations and applicability for PCECC and 227 use of PCEP as an SBI. Section 3.1.5. of [RFC8283] highlights the 228 use of PCECC for configuring the forwarding actions on the routers 229 and assume responsibility for managing the identifier space. It 230 simplifies the processing of a distributed control plane by blending 231 it with elements of SDN and without necessarily completely replacing 232 it. This allows the operator to introduce the advantages of SDN 233 (such as programmability) into the network. Further Section 3.3. of 234 [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where 235 the PCECC technique could be useful. Section 4 of [RFC8283] also 236 describe the implications on the protocol when used as an SDN SBI. 237 The operator needs to evaluate the advantages offered by PCECC 238 against the operational and scalability needs of the PCECC. 240 As per [RFC8283], PCECC can allocate and provision the node/prefix/ 241 adjacency label (SID) via PCEP. As per 242 [I-D.ietf-teas-pcecc-use-cases] this is also applicable to SRv6 SIDs. 244 The rest of the processing is similar to existing stateful PCE for 245 SRv6 [I-D.ietf-pce-segment-routing-ipv6]. 247 4. PCEP Requirements 249 Following key requirements for PCECC-SRv6 should be considered when 250 designing the PCECC-based solution: 252 * A PCEP speaker supporting this document needs to have the 253 capability to advertise its PCECC-SRv6 capability to its peers. 255 * PCEP procedures need to allow for PCC-based SRv6 SID allocations. 257 * PCEP procedures need to provide a means to update (or clean up) 258 the SRv6 SID to the PCC. 260 * PCEP procedures need to provide a means to synchronize the SRv6 261 SID allocations between the PCE to the PCC in the PCEP messages. 263 5. Procedures for Using the PCE as a Central Controller (PCECC) in SRv6 265 5.1. Stateful PCE Model 267 Active stateful PCE is described in [RFC8231]. A PCE as a Central 268 Controller (PCECC) reuses the existing active stateful PCE mechanism 269 as much as possible to control the LSPs. 271 5.2. New Functions 273 This document uses the same PCEP messages and its extensions which 274 are described in [RFC9050] and 275 [I-D.ietf-pce-pcep-extension-pce-controller-sr] for PCECC-SRv6 as 276 well. 278 The PCEP messages PCRpt, PCInitiate, PCUpd are used to send LSP 279 Reports, LSP setup, and LSP update respectively. The extended 280 PCInitiate message described in [RFC9050] is used to download or 281 clean up CCIs (a new CCI Object-Type=TBD3 for SRv6 SID). The 282 extended PCRpt message described in [RFC9050] is also used to report 283 the CCIs (SRv6 SIDs) from PCC to PCE. 285 [RFC9050] specify an object called CCI for the encoding of the 286 central controller's instructions. 287 [I-D.ietf-pce-pcep-extension-pce-controller-sr] defined a CCI object- 288 type for SR-MPLS. This document further defines a new CCI object- 289 type=TBD3 for SRv6. 291 5.3. PCECC Capability Advertisement 293 During the PCEP initialization phase, PCEP speakers (PCE or PCC) 294 advertise their support of and willingness to use PCEP extensions for 295 the PCECC. A PCEP speaker includes the PCECC-CAPABILITY sub-TLV in 296 the PATH-SETUP-TYPE-CAPABILITY TLV as per [RFC9050]. 298 A new S bit is added in the PCECC-CAPABILITY sub-TLV to indicate 299 support for PCECC-SR-MPLS in 300 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. This document adds 301 another I bit to indicate support for SR in IPv6. A PCC MUST set the 302 I bit in the PCECC-CAPABILITY sub-TLV and include the SRv6-PCE- 303 CAPABILITY sub-TLV ([I-D.ietf-pce-segment-routing-ipv6]) in the OPEN 304 object (inside the PATH-SETUP-TYPE-CAPABILITY TLV) to support the 305 PCECC SRv6 extensions defined in this document. 307 If the I bit is set in PCECC-CAPABILITY sub-TLV and the SRv6-PCE- 308 CAPABILITY sub-TLV is not advertised, or is advertised without the I 309 bit set, in the OPEN object, the receiver MUST: 311 * send a PCErr message with Error-Type=19 (Invalid Operation) and 312 Error-value=TBD4 (SRv6 capability was not advertised) and 314 * terminate the session. 316 The rest of the processing is as per [RFC9050] and 317 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 319 5.4. PCEP session IP address and TED Router ID 321 As described in [I-D.ietf-pce-pcep-extension-pce-controller-sr], it 322 is important to link the session IP address with the Router ID in TED 323 for successful PCECC-SRv6 operations. 325 5.5. SRv6 Path Operations 327 [RFC8664] specify the PCEP extension to allow a stateful PCE to 328 compute and initiate SR-TE paths, as well as a PCC to request a path 329 subject to certain constraint(s) and optimization criteria in SR 330 networks. [I-D.ietf-pce-segment-routing-ipv6] extends it to support 331 SRv6. 333 The Path Setup Type for SRv6 (PST=TBD) is used on the PCEP session 334 with the Ingress as per [I-D.ietf-pce-segment-routing-ipv6]. 336 5.5.1. PCECC Segment Routing in IPv6 (SRv6) 338 Segment Routing (SR) as described in [RFC8402] depends on "segments" 339 that are advertised by Interior Gateway Protocols (IGPs). The SR- 340 node allocates and advertises the SID (node, adj, etc) and floods 341 them via the IGP. This document proposes a new mechanism where PCE 342 allocates the SRv6 SID centrally and uses PCEP to distribute them to 343 all nodes. In some deployments, PCE (and PCEP) are better suited 344 than IGP because of the centralized nature of PCE and direct TCP 345 based PCEP sessions to the node. Note that only the SRv6 SID 346 allocation and distribution is done by the PCEP, all other SRv6 347 operations (nexthop selection, protection, etc) are still done by the 348 node (and the IGPs). 350 5.5.1.1. PCECC SRv6 Node/Prefix SID allocation 352 Each node (PCC) is allocated a node SRv6 SID by the PCECC. The PCECC 353 sends the PCInitiate message to update the SRv6 SID table of each 354 node. The TE router ID is determined from the TED or from "IPv4/IPv6 355 Router-ID" sub-TLV [I-D.dhodylee-pce-pcep-ls], in the OPEN Object. 357 On receiving the SRv6 node SID allocation, each node (PCC) uses the 358 local routing information to determine the next-hop and download the 359 forwarding instructions accordingly. The PCInitiate message uses the 360 FEC object [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 362 On receiving the SRv6 node SID allocation: 364 For the local SID, the node (PCC) needs to update SID with 365 associated function (END function in this case) in "My Local SID 366 Table" ([RFC8986]). 368 For the non-local SID, the node (PCC) uses the local routing 369 information to determine the next-hop and download the forwarding 370 instructions accordingly. 372 The forwarding behavior and the end result is similar to IGP based 373 "Node-SID" in SRv6. Thus, from anywhere in the domain, it enforces 374 the ECMP-aware shortest-path forwarding of the packet towards the 375 related node as per [RFC8402]. 377 PCE relies on the Node/Prefix SRv6 SID clean up using the same 378 PCInitiate message as per [RFC8281]. 380 5.5.1.2. PCECC SRv6 Adjacency SID allocation 382 For PCECC-SRv6, apart from node-SID, Adj-SID is used where each 383 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 384 PCInitiate message to update the SRv6 SID entry for each adjacency to 385 all nodes in the domain. Each node (PCC) download the SRv6 SID 386 instructions accordingly. Similar to SRv6 Node/Prefix Label 387 allocation, the PCInitiate message in this case uses the FEC object. 389 The forwarding behavior and the end result is similar to IGP based 390 "Adj-SID" in SRv6 as per [RFC8402]. 392 The handling of adjacencies on the LAN subnetworks is specified in 393 [RFC8402]. PCECC MUST assign Adj-SID for every pair of routers in 394 the LAN. The rest of the protocol mechanism remains the same. 396 PCE relies on the Adj label clean up using the same PCInitiate 397 message as per [RFC8281]. 399 5.5.1.3. Redundant PCEs 401 [I-D.ietf-pce-state-sync] describes the synchronization mechanism 402 between the stateful PCEs. The SRv6 SIDs allocated by a PCE MUST 403 also be synchronized among PCEs for PCECC-SRv6 state synchronization. 404 Note that the SRv6 SIDs are independent of the SRv6 paths, and 405 remains intact till any topology change. The redundant PCEs MUST 406 have a common view of all SRv6 SIDs allocated in the domain. 408 5.5.1.4. Re-Delegation and Cleanup 410 [RFC9050] describes the action needed for CCIs for the static LSPs on 411 a terminated session. Same holds true for the CCI for SRv6 SID as 412 well. 414 5.5.1.5. Synchronization of SRv6 SID Allocations 416 [RFC9050] describes the synchronization of CCIs via the LSP state 417 synchronization as described in [RFC8231] and [RFC8232]. Same 418 procedures are applied for the SRv6 SID CCIs. 420 6. PCEP Messages 422 The PCEP messages are as per 423 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 425 7. PCEP Objects 427 7.1. OPEN Object 429 7.1.1. PCECC Capability sub-TLV 431 [RFC9050] defined the PCECC-CAPABILITY sub-TLV. 433 A new I-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SRv6: 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type=TBD | Length=4 | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Flags |I|S|L| 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 [Editor's Note - The above figure is included for ease of the reader 444 but should be removed before publication.] 446 I (PCECC-SRv6-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP 447 speaker, it indicates that the PCEP speaker is capable of PCECC-SRv6 448 capability and the PCE allocates the Node and Adj SRv6 SID on this 449 session. 451 7.2. SRv6 Path Setup 453 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. A PST value of TBD 454 is used when Path is setup via SRv6 mode as per 455 [I-D.ietf-pce-segment-routing-ipv6]. The procedure for SRv6 path 456 setup as specified in [I-D.ietf-pce-segment-routing-ipv6] remains 457 unchanged. 459 7.3. CCI Object 461 The Central Control Instructions (CCI) Object is used by the PCE to 462 specify the controller instructions is defined in [RFC9050]. This 463 document defines another object-type for SRv6 purpose. 465 CCI Object-Type is TBD3 for SRv6 as below - 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | CC-ID | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | MT-ID | Algorithm | Flags |B|P|G|C|N|E|V|L| 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Reserved | SRv6 Endpoint Function | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | | 476 | SRv6 Identifier | 477 | (128-bit) | 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | SID | 481 | Structure | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | 484 // Optional TLV // 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 The field CC-ID is as described in [RFC9050]. The field MT-ID, 489 Algorithm, Flags are defined in 490 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. 492 Reserved: MUST be set to 0 while sending and ignored on receipt. 494 SRv6 Endpoint Function: 16-bit field representing supported functions 495 associated with SRv6 SIDs. 497 SRv6 Identifier: 128-bit IPv6 addresses representing SRv6 segment. 499 SID Structure: 64-bit field formatted as per "SID Structure" in 500 [I-D.ietf-pce-segment-routing-ipv6]. The sum of all four sizes in 501 the SID Structure must be lower or equal to 128 bits. If the sum of 502 all four sizes advertised in the SID Structure is larger than 128 503 bits, the corresponding SRv6 SID MUST be considered invalid and a 504 PCErr message with Error-Type = 10 ("Reception of an invalid object") 505 and Error-Value = TBD ("Invalid SRv6 SID Structure") is returned. 507 7.4. FEC Object 509 The FEC Object is used to specify the FEC information and MAY be 510 carried within PCInitiate or PCRpt message. 512 FEC Object (and various Object-Types) are described in 513 [I-D.ietf-pce-pcep-extension-pce-controller-sr]. SRv6 Node SID MUST 514 includes the FEC Object-Type 2 for IPv6 Node. SRv6 Adjacency SID 515 MUST include the FEC Object-Type=4 for IPv6 adjacency. Further FEC 516 object types could be added in future extensions. 518 8. Security Considerations 520 As per [RFC8283], the security considerations for a PCE-based 521 controller are a little different from those for any other PCE 522 system. That is, the operation relies heavily on the use and 523 security of PCEP, so consideration should be given to the security 524 features discussed in [RFC5440] and the additional mechanisms 525 described in [RFC8253]. It further lists the vulnerability of a 526 central controller architecture, such as a central point of failure, 527 denial of service, and a focus for interception and modification of 528 messages sent to individual Network Elements (NEs). 530 The PCECC extension builds on the existing PCEP messages; thus, the 531 security considerations described in [RFC5440], [RFC8231], [RFC8281], 532 [RFC9050], and [I-D.ietf-pce-pcep-extension-pce-controller-sr] 533 continue to apply. 535 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 536 be activated on mutually-authenticated and encrypted sessions across 537 PCEs and PCCs belonging to the same administrative authority, using 538 Transport Layer Security (TLS) [RFC8253] as per the recommendations 539 and best current practices in [RFC7525] (unless explicitly set aside 540 in [RFC8253]). 542 9. Manageability Considerations 544 9.1. Control of Function and Policy 546 A PCE or PCC implementation SHOULD allow to configure to enable/ 547 disable PCECC SRv6 capability as a global configuration. 549 9.2. Information and Data Models 551 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 552 PCECC SRv6 capability status. 554 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 555 enable/disable PCECC SRv6 capability. 557 9.3. Liveness Detection and Monitoring 559 Mechanisms defined in this document do not imply any new liveness 560 detection and monitoring requirements in addition to those already 561 listed in [RFC5440]. 563 9.4. Verify Correct Operations 565 Mechanisms defined in this document do not imply any new operation 566 verification requirements in addition to those already listed in 567 [RFC5440] and [RFC8231]. 569 9.5. Requirements On Other Protocols 571 PCEP extensions defined in this document do not put new requirements 572 on other protocols. 574 9.6. Impact On Network Operations 576 PCEP implementation SHOULD allow a limit to be placed on the rate of 577 PCInitiate/PCUpd messages (as per [RFC8231]) sent by PCE and 578 processed by PCC. It SHOULD also allow sending a notification when a 579 rate threshold is reached. 581 10. IANA Considerations 583 10.1. PCECC-CAPABILITY sub-TLV 585 [RFC9050] defines the PCECC-CAPABILITY sub-TLV and requests that IANA 586 creates a registry to manage the value of the PCECC-CAPABILITY sub- 587 TLV's Flag field. IANA is requested to allocate a new bit in the 588 PCECC-CAPABILITY sub-TLV Flag Field registry, as follows: 590 +======+=============+===============+ 591 | Bit | Description | Reference | 592 +======+=============+===============+ 593 | TBD1 | SRv6 | This document | 594 +------+-------------+---------------+ 596 Table 1 598 10.2. PCEP Object 600 IANA is requested to allocate a new code-point for the new CCI 601 object-type in "PCEP Objects" sub-registry as follows: 603 +====================+======+=============+===============+ 604 | Object-Class Value | Name | Object-Type | Reference | 605 +====================+======+=============+===============+ 606 | TBD | CCI | | [RFC9050] | 607 +--------------------+------+-------------+---------------+ 608 | | | TBD3: SRv6 | This document | 609 +--------------------+------+-------------+---------------+ 611 Table 2 613 10.3. PCEP-Error Object 615 IANA is requested to allocate new error types and error values within 616 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 617 PCEP Numbers registry for the following errors: 619 Error-Type Meaning 620 ---------- ------- 621 19 Invalid operation. 622 Error-value = TBD4 : SRv6 capability was 623 not advertised 625 The Reference is marked as "This document". 627 11. References 629 11.1. Normative References 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, 633 DOI 10.17487/RFC2119, March 1997, 634 . 636 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 637 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 638 DOI 10.17487/RFC5440, March 2009, 639 . 641 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 642 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 643 May 2017, . 645 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 646 Computation Element Communication Protocol (PCEP) 647 Extensions for Stateful PCE", RFC 8231, 648 DOI 10.17487/RFC8231, September 2017, 649 . 651 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 652 Computation Element Communication Protocol (PCEP) 653 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 654 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 655 . 657 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 658 and J. Hardwick, "Path Computation Element Communication 659 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 660 DOI 10.17487/RFC8664, December 2019, 661 . 663 [I-D.ietf-pce-segment-routing-ipv6] 664 Li(Editor), C., Negi, M. S., Sivabalan, S., Koldychev, M., 665 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 666 Routing leveraging the IPv6 data plane", Work in Progress, 667 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-11, 10 668 January 2022, . 671 [RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path 672 Computation Element Communication Protocol (PCEP) 673 Procedures and Extensions for Using the PCE as a Central 674 Controller (PCECC) of LSPs", RFC 9050, 675 DOI 10.17487/RFC9050, July 2021, 676 . 678 [I-D.ietf-pce-pcep-extension-pce-controller-sr] 679 Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, 680 "Path Computation Element Communication Protocol (PCEP) 681 Procedures and Extensions for Using PCE as a Central 682 Controller (PCECC) for Segment Routing (SR) MPLS Segment 683 Identifier (SID) Allocation and Distribution.", Work in 684 Progress, Internet-Draft, draft-ietf-pce-pcep-extension- 685 pce-controller-sr-04, 6 March 2022, 686 . 689 11.2. Informative References 691 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 692 Computation Element (PCE)-Based Architecture", RFC 4655, 693 DOI 10.17487/RFC4655, August 2006, 694 . 696 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 697 Margaria, "Requirements for GMPLS Applications of PCE", 698 RFC 7025, DOI 10.17487/RFC7025, September 2013, 699 . 701 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 702 Computation Element Architecture", RFC 7399, 703 DOI 10.17487/RFC7399, October 2014, 704 . 706 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 707 Hardwick, "Path Computation Element Communication Protocol 708 (PCEP) Management Information Base (MIB) Module", 709 RFC 7420, DOI 10.17487/RFC7420, December 2014, 710 . 712 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 713 Application-Based Network Operations", RFC 7491, 714 DOI 10.17487/RFC7491, March 2015, 715 . 717 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 718 "Recommendations for Secure Use of Transport Layer 719 Security (TLS) and Datagram Transport Layer Security 720 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 721 2015, . 723 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 724 and D. Dhody, "Optimizations of Label Switched Path State 725 Synchronization Procedures for a Stateful PCE", RFC 8232, 726 DOI 10.17487/RFC8232, September 2017, 727 . 729 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 730 "PCEPS: Usage of TLS to Provide a Secure Transport for the 731 Path Computation Element Communication Protocol (PCEP)", 732 RFC 8253, DOI 10.17487/RFC8253, October 2017, 733 . 735 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 736 Architecture for Use of PCE and the PCE Communication 737 Protocol (PCEP) in a Network with Central Control", 738 RFC 8283, DOI 10.17487/RFC8283, December 2017, 739 . 741 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 742 Decraene, B., Litkowski, S., and R. Shakir, "Segment 743 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 744 July 2018, . 746 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 747 Hardwick, "Conveying Path Setup Type in PCE Communication 748 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 749 July 2018, . 751 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 752 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 753 Extensions for Segment Routing", RFC 8665, 754 DOI 10.17487/RFC8665, December 2019, 755 . 757 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 758 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 759 Extensions for Segment Routing", RFC 8667, 760 DOI 10.17487/RFC8667, December 2019, 761 . 763 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 764 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 765 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 766 . 768 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 769 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 770 (SRv6) Network Programming", RFC 8986, 771 DOI 10.17487/RFC8986, February 2021, 772 . 774 [I-D.ietf-teas-pcecc-use-cases] 775 Li, Z. (., Dhody, D., Zhao, Q., Ke, K., Khasanov, B., 776 Fang, L., Zhou, C., Zhang, B., Rachitskiy, A., and A. 777 Gulida, "The Use Cases for Path Computation Element (PCE) 778 as a Central Controller (PCECC).", Work in Progress, 779 Internet-Draft, draft-ietf-teas-pcecc-use-cases-08, 25 780 October 2021, . 783 [I-D.ietf-pce-pcep-yang] 784 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 785 "A YANG Data Model for Path Computation Element 786 Communications Protocol (PCEP)", Work in Progress, 787 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 788 2022, . 791 [I-D.ietf-pce-state-sync] 792 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 793 Stateful Path Computation Element (PCE) Communication 794 Procedures.", Work in Progress, Internet-Draft, draft- 795 ietf-pce-state-sync-01, 20 October 2021, 796 . 799 [I-D.dhodylee-pce-pcep-ls] 800 Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A., 801 Mishra, G., and S. Sivabalan, "PCEP extensions for 802 Distribution of Link-State and TE Information", Work in 803 Progress, Internet-Draft, draft-dhodylee-pce-pcep-ls-23, 5 804 March 2022, . 807 Appendix A. Contributor Addresses 809 Dhruv Dhody 810 Huawei Technologies 811 Divyashree Techno Park, Whitefield 812 Bangalore, Karnataka 560066 813 India 815 EMail: dhruv.ietf@gmail.com 817 Authors' Addresses 819 Zhenbin Li 820 Huawei Technologies 821 Huawei Bld., No.156 Beiqing Rd. 822 Beijing 823 100095 824 China 825 Email: lizhenbin@huawei.com 826 Shuping Peng 827 Huawei Technologies 828 Huawei Bld., No.156 Beiqing Rd. 829 Beijing 830 100095 831 China 832 Email: pengshuping@huawei.com 834 Xuesong Geng 835 Huawei Technologies 836 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 845 Email: mahend.ietf@gmail.com