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