idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-srv6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1382 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-06 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-05 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-06 -- 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-05 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-13 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-08 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-15 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 Summary: 0 errors (**), 0 flaws (~~), 9 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: January 14, 2021 Huawei Technologies 6 M. Negi 7 RtBrick India 8 July 13, 2020 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-04 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 in IPv6 (SRv6), in addition to 36 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 January 14, 2021. 57 Copyright Notice 59 Copyright (c) 2020 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 the Central Controller 80 (PCECC) 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 TEDB Router ID . . . . . . . 7 85 5.5. SRv6 Path Operations . . . . . . . . . . . . . . . . . . 7 86 5.5.1. PCECC Segment Routing in IPv6 (SRv6) . . . . . . . . 7 87 5.5.1.1. PCECC SRv6 Node/Prefix SID allocation . . . . . . 7 88 5.5.1.2. PCECC SRv6 Adjacency SID allocation . . . . . . . 8 89 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 9 90 5.5.1.4. Re-Delegation and Cleanup . . . . . . . . . . . . 9 91 5.5.1.5. Synchronization of SRv6 SID Allocations . . . . . 9 92 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 9 93 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 9 94 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 9 95 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 9 96 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10 97 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 98 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 11 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 100 9. Manageability Considerations . . . . . . . . . . . . . . . . 11 101 9.1. Control of Function and Policy . . . . . . . . . . . . . 11 102 9.2. Information and Data Models . . . . . . . . . . . . . . . 12 103 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 104 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 105 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 106 9.6. Impact On Network Operations . . . . . . . . . . . . . . 12 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 108 10.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 12 109 10.2. New Path Setup Type Registry . . . . . . . . . . . . . . 13 110 10.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 13 111 10.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 13 112 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 114 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 115 12.2. Informative References . . . . . . . . . . . . . . . . . 15 116 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 18 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 119 1. Introduction 121 The Path Computation Element (PCE) [RFC4655] was developed to offload 122 path computation function from routers in an MPLS traffic-engineered 123 network. Since then, the role and function of the PCE has grown to 124 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 125 delegated control [RFC8231] and PCE-initiated use of network 126 resources [RFC8281]. 128 According to [RFC7399], Software-Defined Networking (SDN) refers to a 129 separation between the control elements and the forwarding components 130 so that software running in a centralized system, called a 131 controller, can act to program the devices in the network to behave 132 in specific ways. A required element in an SDN architecture is a 133 component that plans how the network resources will be used and how 134 the devices will be programmed. It is possible to view this 135 component as performing specific computations to place traffic flows 136 within the network given knowledge of the availability of network 137 resources, how other forwarding devices are programmed, and the way 138 that other flows are routed. This is the function and purpose of a 139 PCE, and the way that a PCE integrates into a wider network control 140 system (including an SDN system) is presented in [RFC7491]. 142 In early PCE implementations, where the PCE was used to derive paths 143 for MPLS Label Switched Paths (LSPs), paths were requested by network 144 elements (known as Path Computation Clients (PCCs)), and the results 145 of the path computations were supplied to network elements using the 146 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 147 This protocol was later extended to allow a PCE to send unsolicited 148 requests to the network for LSP establishment [RFC8281]. 150 [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 PCECC 157 architecture. 159 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 160 procedures and PCEP protocol extensions for using the PCE as the 161 central controller for static LSPs, where LSPs can be provisioned as 162 explicit 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 segment 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 protocol for SR SID (Segment Identifier) 187 distribution on the SR nodes with some benefits. 188 [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the 189 procedures and PCEP protocol extensions when a PCE-based controller 190 is also responsible for configuring the forwarding actions on the 191 routers (SR SID distribution in this case), in addition to computing 192 the paths for packet flows in a segment routing network and telling 193 the edge routers what instructions to attach to packets as they enter 194 the network. This document extends this to include SRv6 SID 195 distribution as well. 197 1.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 2. Terminology 207 Terminologies used in this document is same as described in the draft 208 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 210 3. PCECC SRv6 212 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 213 compute, update or initiate SR-TE paths for MPLS dataplane. An 214 ingress node of an SR-TE path appends all outgoing packets with a 215 list of MPLS labels (SIDs). This is encoded in SR-ERO subobject, 216 capable of carrying a label (SID) as well as the identity of the 217 node/adjacency label (SID). [I-D.ietf-pce-segment-routing-ipv6] 218 extends the procedure to include support for SRv6 paths. 220 As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or 221 simply "SID" are often used as a shorter reference for "SRv6 222 Segment". Further details are in an illustration provided in 223 [I-D.ietf-spring-srv6-network-programming]. The SR is applied to 224 IPV6 forwarding plane using SRH. A SR path can be derived from an 225 IGP Shortest Path Tree (SPT), but SR-TE paths may not follow IGP SPT. 226 Such paths may be chosen by a suitable network planning tool, or a 227 PCE and provisioned on the ingress node. 228 [I-D.ietf-pce-segment-routing-ipv6] extended SR-ERO subobject capable 229 of carrying an SRv6 SID as well as the identity of the node/adjacency 230 represented by the SID. 232 As per [RFC8283], PCE as a central controller can allocate and 233 provision the node/prefix/adjacency label (SID) via PCEP. As per 234 [I-D.ietf-teas-pcecc-use-cases] this is also applicable to SRv6 SIDs. 236 Rest of the processing is similar to existing stateful PCE with SRv6 237 mechanism. 239 4. PCEP Requirements 241 Following key requirements for PCECC-SRv6 should be considered when` 242 designing the PCECC based solution: 244 o PCEP speaker supporting this draft needs to have the capability to 245 advertise its PCECC-SRv6 capability to its peers. 247 o PCEP speaker not supporting this draft needs to be able to reject 248 PCECC-SRv6 related message with a reason code that indicates no 249 support for it. 251 o PCEP procedures needs to provide a means to update (or cleanup) 252 the SRv6 SID to the PCC. 254 o PCEP procedures needs to provide a means to synchronize the SRv6 255 SID allocations between PCE to PCC in the PCEP messages. 257 5. Procedures for Using the PCE as the Central Controller (PCECC) in 258 SRv6 260 5.1. Stateful PCE Model 262 Active stateful PCE is described in [RFC8231]. PCE as a central 263 controller (PCECC) reuses existing Active stateful PCE mechanism as 264 much as possible to control the LSP. 266 5.2. New Functions 268 This document uses the same PCEP messages and its extensions which 269 are described in [I-D.ietf-pce-pcep-extension-for-pce-controller] and 270 [I-D.zhao-pce-pcep-extension-pce-controller-sr] for PCECC-SRv6 as 271 well. 273 PCEP messages PCRpt, PCInitiate, PCUpd are also used to send LSP 274 Reports, LSP setup and LSP update respectively. The extended 275 PCInitiate message described in 276 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 277 or cleanup central controller's instructions (CCIs) (SRv6 SID in 278 scope of this document). The extended PCRpt message described in 279 [I-D.ietf-pce-pcep-extension-for-pce-controller] is also used to 280 report the CCIs (SRv6 SIDs) from PCC to PCE. 282 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 283 called CCI for the encoding of central controller's instructions. 284 [I-D.zhao-pce-pcep-extension-pce-controller-sr] extends the CCI by 285 defining a object-type for segment routing. This document further 286 extends the CCI by defining another object-type for SRv6. 288 5.3. PCECC Capability Advertisement 290 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 291 advertise their support of PCECC extensions. A PCEP Speaker includes 292 the "PCECC Capability" sub-TLV, described in 293 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 295 A S-bit is added in PCECC-CAPABILITY sub-TLV to indicate support for 296 PCECC-SR in [I-D.zhao-pce-pcep-extension-pce-controller-sr]. This 297 document adds another I-bit to indicate support for SR in IPv6. A 298 PCC MUST set I-bit in PCECC-CAPABILITY sub-TLV and include SRv6-PCE- 299 CAPABILITY sub-TLV ([I-D.ietf-pce-segment-routing-ipv6]) in OPEN 300 Object (inside the the PATH-SETUP-TYPE-CAPABILITY TLV) to support the 301 PCECC SRv6 extensions defined in this document. If I-bit is set in 302 PCECC-CAPABILITY sub-TLV and SRv6-PCE-CAPABILITY sub-TLV is not 303 advertised in OPEN Object, PCE SHOULD send a PCErr message with 304 Error-Type=19 (Invalid Operation) and Error-value=TBD4 (SRv6 305 capability was not advertised) and terminate the session. 307 5.4. PCEP session IP address and TEDB Router ID 309 As described in [I-D.zhao-pce-pcep-extension-pce-controller-sr], it 310 is important to link the session IP address with the Router ID in 311 TEDB for successful PCECC operations. 313 5.5. SRv6 Path Operations 315 The PCEP messages pertaining to PCECC-SRv6 MUST include PATH-SETUP- 316 TYPE TLV [RFC8408] with PST=TBD2 in the SRP object to clearly 317 identify the PCECC-SRv6 setup is intended. 319 5.5.1. PCECC Segment Routing in IPv6 (SRv6) 321 Segment Routing (SR) as described in [RFC8402] depends on "segments" 322 that are advertised by Interior Gateway Protocols (IGPs). The SR- 323 node allocates and advertises the SID (node, adj etc) and flood via 324 the IGP. This document proposes a new mechanism where PCE allocates 325 the SRv6 SID centrally and uses PCEP to advertise the SRv6 SID. In 326 some deployments PCE (and PCEP) are better suited than IGP because of 327 centralized nature of PCE and direct TCP based PCEP session to the 328 node. 330 5.5.1.1. PCECC SRv6 Node/Prefix SID allocation 332 Each node (PCC) is allocated a node SRv6 SID by the PCECC. The PCECC 333 sends PCInitiate message to update the SID table of each node. The 334 TE router ID is determined from the TEDB or from "IPv4/IPv6 Router- 335 ID" Sub-TLV [I-D.dhodylee-pce-pcep-ls], in the OPEN Object. 337 On receiving the SRv6 node SID allocation, each node (PCC) uses the 338 local routing information to determine the next-hop and download the 339 forwarding instructions accordingly. The PCInitiate message in this 340 case MUST have FEC object. 342 On receiving the SRv6 node SID allocation: 344 For the local SID, node (PCC) needs to update SID with associated 345 function (END function in this case) in "My Local SID Table" 346 ([I-D.ietf-spring-srv6-network-programming]). 348 For the non-local SID, node (PCC) uses the local routing 349 information to determine the next-hop and download the forwarding 350 instructions accordingly. 352 The PCInitiate message in this case MUST have FEC object. 354 The forwarding behavior and the end result is similar to IGP based 355 "Node-SID" in SRv6. Thus, from anywhere in the domain, it enforces 356 the ECMP-aware shortest-path forwarding of the packet towards the 357 related node. 359 PCE relies on the Node/Prefix SRv6 SID cleanup using the same 360 PCInitiate message. 362 5.5.1.2. PCECC SRv6 Adjacency SID allocation 364 [RFC8664] extends PCEP to allow a stateful PCE to compute and 365 initiate SR-TE paths, as well as a PCC to request a path subject to 366 certain constraint(s) and optimization criteria in SR networks. 368 For PCECC SR, apart from node-SID, Adj-SID is used where each 369 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 370 PCInitiate message to update the label map of each Adj to the 371 corresponding nodes in the domain. Each node (PCC) download the SRv6 372 SID instructions accordingly. Similar to SRv6 Node/Prefix Label 373 allocation, the PCInitiate message in this case uses the FEC object. 375 The forwarding behavior and the end result is similar to IGP based 376 "Adj-SID" in SRv6. 378 The Path Setup Type for segment routing MUST be set for PCECC SRv6 = 379 TBD2 (see Section 7.2). All PCEP procedures and mechanism are 380 similar to [RFC8664]. 382 PCE relies on the Adj label cleanup using the same PCInitiate 383 message. 385 5.5.1.3. Redundant PCEs 387 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 388 between the stateful PCEs. The SRv6 SIDs allocated by a PCE MUST 389 also be synchronized among PCEs for PCECC SRv6 state synchronization. 390 Note that the SRv6 SIDs are independent to the PCECC-SRv6 paths, and 391 remains intact till any topology change. The redundant PCEs MUST 392 have a common view of all SRv6 SIDs allocated in the domain. 394 5.5.1.4. Re-Delegation and Cleanup 396 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the action 397 needed for CCIs for the Basic PCECC LSP on this terminated session. 398 Similarly actions should be applied for the SRv6 SID as well. 400 5.5.1.5. Synchronization of SRv6 SID Allocations 402 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the 403 synchronization of Central Controller's Instructions (CCI) via LSP 404 state synchronization as described in [RFC8231] and [RFC8232]. Same 405 procedures should be applied for SRv6 SIDs as well. 407 6. PCEP messages 409 The PCEP messages are as per 410 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 412 7. PCEP Objects 414 7.1. OPEN Object 416 7.1.1. PCECC Capability sub-TLV 418 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 419 CAPABILITY TLV. 421 A new I-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SRv6: 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type=TBD | Length=4 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Flags |I|S| 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 [Editor's Note - The above figure is included for ease of the reader 432 but should be removed before publication.] 434 I (PCECC-SRv6-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP 435 speaker, it indicates that the PCEP speaker is capable for PCECC-SRv6 436 capability and PCE would allocate node and Adj SRv6 SID on this 437 session. 439 7.2. PATH-SETUP-TYPE TLV 441 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. PST = TBD2 is used 442 when Path is setup via PCECC SRv6 mode. 444 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD2 indicates that this 445 path was setup via a PCECC-SRv6 based mechanism where either the SIDs 446 were allocated/instructed by PCE via PCECC mechanism. 448 7.3. CCI Object 450 The Central Control Instructions (CCI) Object is used by the PCE to 451 specify the forwarding instructions is defined in 452 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 453 defines another object-type for SRv6 purpose. 455 CCI Object-Type is TBD3 for SRv6 as below - 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | CC-ID | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | MT-ID | Algorithm | Flags |B|P|G|C|N|E|V|L|O| 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Reserved | SRv6 Endpoint Function | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 | SRv6 Identifier | 468 | (128-bit) | 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 // Optional TLV // 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 The field CC-ID is as described in 476 [I-D.ietf-pce-pcep-extension-for-pce-controller]. The field MT-ID, 477 Algorithm, Flags are defined in 478 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 480 Reserved: MUST be set to 0 while sending and ignored on receipt. 482 SRv6 Endpoint Function: 16 bit field representing supported functions 483 associated with SRv6 SIDs. 485 SRv6 Identifier: 128 bit IPv6 addresses representing SRv6 segment. 487 [Editor's Note - It might be useful to seperate the LOC:FUNC part in 488 the SRv6 SID (future study)] 490 7.4. FEC Object 492 The FEC Object is used to specify the FEC information and MAY be 493 carried within PCInitiate or PCRpt message. 495 FEC Object (and various Object-Types) are described in 496 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. SRv6 Node SID MUST 497 includes the FEC Object-Type 2 for IPv6 Node. SRv6 Adjacency SID 498 MUST include the FEC Object-Type=4 for IPv6 adjacency. Further FEC 499 object types would be added in future revisions. 501 8. Security Considerations 503 The security considerations described in 504 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the 505 extensions described in this document. 507 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 508 be activated on authenticated and encrypted sessions across PCEs and 509 PCCs belonging to the same administrative authority, using Transport 510 Layer Security (TLS) [RFC8253] as per the recommendations and best 511 current practices in [RFC7525] (unless explicitly set aside in 512 [RFC8253]). 514 9. Manageability Considerations 516 9.1. Control of Function and Policy 518 A PCE or PCC implementation SHOULD allow to configure to enable/ 519 disable PCECC SR capability as a global configuration. 521 9.2. Information and Data Models 523 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 524 PCECC SR capability status. 526 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 527 enable/disable PCECC SR capability. 529 9.3. Liveness Detection and Monitoring 531 Mechanisms defined in this document do not imply any new liveness 532 detection and monitoring requirements in addition to those already 533 listed in [RFC5440]. 535 9.4. Verify Correct Operations 537 Mechanisms defined in this document do not imply any new operation 538 verification requirements in addition to those already listed in 539 [RFC5440] and [RFC8231]. 541 9.5. Requirements On Other Protocols 543 PCEP extensions defined in this document do not put new requirements 544 on other protocols. 546 9.6. Impact On Network Operations 548 PCEP implementation SHOULD allow a limit to be placed on the rate of 549 PCInitiate/PCUpd messages (as per [RFC8231]) sent by PCE and 550 processed by PCC. It SHOULD also allow sending a notification when a 551 rate threshold is reached. 553 10. IANA Considerations 555 10.1. PCECC-CAPABILITY TLV 557 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 558 CAPABILITY TLV and requests that IANA creates a registry to manage 559 the value of the PCECC-CAPABILITY TLV's Flag field. IANA is 560 requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag 561 Field registry, as follows: 563 Bit Description Reference 564 TBD1 I((PCECC-SRv6-CAPABILITY)) This document 566 10.2. New Path Setup Type Registry 568 IANA is requested to allocate new PST Field in PATH- SETUP-TYPE TLV. 569 The allocation policy for this new registry should be by IETF 570 Consensus. The new registry should contain the following value: 572 Value Description Reference 573 TBD2 Path is This document 574 setup using PCECC-SRv6 mode 576 10.3. PCEP Object 578 IANA is requested to allocate new code-point for the new CCI object- 579 type in "PCEP Objects" sub-registry as follows: 581 Object-Class Value Name Object-Type Reference 582 TBD CCI 583 TBD3: SRv6 This document 585 10.4. PCEP-Error Object 587 IANA is requested to allocate new error types and error values within 588 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 589 PCEP Numbers registry for the following errors: 591 Error-Type Meaning 592 ---------- ------- 593 19 Invalid operation. 595 Error-value = TBD4 : SRv6 capability was 596 not advertised 598 11. Acknowledgments 600 12. References 602 12.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, 606 DOI 10.17487/RFC2119, March 1997, 607 . 609 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 610 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 611 DOI 10.17487/RFC5440, March 2009, 612 . 614 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 615 Hardwick, "Path Computation Element Communication Protocol 616 (PCEP) Management Information Base (MIB) Module", 617 RFC 7420, DOI 10.17487/RFC7420, December 2014, 618 . 620 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 621 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 622 May 2017, . 624 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 625 Computation Element Communication Protocol (PCEP) 626 Extensions for Stateful PCE", RFC 8231, 627 DOI 10.17487/RFC8231, September 2017, 628 . 630 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 631 Computation Element Communication Protocol (PCEP) 632 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 633 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 634 . 636 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 637 and J. Hardwick, "Path Computation Element Communication 638 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 639 DOI 10.17487/RFC8664, December 2019, 640 . 642 [I-D.ietf-pce-segment-routing-ipv6] 643 Li, C., Negi, M., Koldychev, M., Kaladharan, P., and Y. 644 Zhu, "PCEP Extensions for Segment Routing leveraging the 645 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-06 646 (work in progress), July 2020. 648 [I-D.ietf-pce-pcep-extension-for-pce-controller] 649 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 650 Procedures and Protocol Extensions for Using PCE as a 651 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 652 extension-for-pce-controller-05 (work in progress), June 653 2020. 655 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 656 Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP 657 Procedures and Protocol Extensions for Using PCE as a 658 Central Controller (PCECC) of SR-LSPs", draft-zhao-pce- 659 pcep-extension-pce-controller-sr-06 (work in progress), 660 March 2020. 662 12.2. Informative References 664 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 665 Element (PCE)-Based Architecture", RFC 4655, 666 DOI 10.17487/RFC4655, August 2006, 667 . 669 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 670 Margaria, "Requirements for GMPLS Applications of PCE", 671 RFC 7025, DOI 10.17487/RFC7025, September 2013, 672 . 674 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 675 Computation Element Architecture", RFC 7399, 676 DOI 10.17487/RFC7399, October 2014, 677 . 679 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 680 Application-Based Network Operations", RFC 7491, 681 DOI 10.17487/RFC7491, March 2015, 682 . 684 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 685 "Recommendations for Secure Use of Transport Layer 686 Security (TLS) and Datagram Transport Layer Security 687 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 688 2015, . 690 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 691 and D. Dhody, "Optimizations of Label Switched Path State 692 Synchronization Procedures for a Stateful PCE", RFC 8232, 693 DOI 10.17487/RFC8232, September 2017, 694 . 696 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 697 "PCEPS: Usage of TLS to Provide a Secure Transport for the 698 Path Computation Element Communication Protocol (PCEP)", 699 RFC 8253, DOI 10.17487/RFC8253, October 2017, 700 . 702 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 703 Architecture for Use of PCE and the PCE Communication 704 Protocol (PCEP) in a Network with Central Control", 705 RFC 8283, DOI 10.17487/RFC8283, December 2017, 706 . 708 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 709 Decraene, B., Litkowski, S., and R. Shakir, "Segment 710 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 711 July 2018, . 713 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 714 Hardwick, "Conveying Path Setup Type in PCE Communication 715 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 716 July 2018, . 718 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 719 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 720 Extensions for Segment Routing", RFC 8665, 721 DOI 10.17487/RFC8665, December 2019, 722 . 724 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 725 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 726 Extensions for Segment Routing", RFC 8667, 727 DOI 10.17487/RFC8667, December 2019, 728 . 730 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 731 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 732 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 733 . 735 [I-D.ietf-teas-pcecc-use-cases] 736 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 737 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 738 Gulida, "The Use Cases for Path Computation Element (PCE) 739 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 740 use-cases-05 (work in progress), March 2020. 742 [I-D.ietf-pce-pcep-yang] 743 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 744 YANG Data Model for Path Computation Element 745 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 746 yang-13 (work in progress), October 2019. 748 [I-D.litkowski-pce-state-sync] 749 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 750 Stateful Path Computation Element (PCE) Communication 751 Procedures.", draft-litkowski-pce-state-sync-08 (work in 752 progress), July 2020. 754 [I-D.dhodylee-pce-pcep-ls] 755 Dhody, D., Peng, S., Lee, Y., and D. Ceccarelli, "PCEP 756 extensions for Distribution of Link-State and TE 757 Information", draft-dhodylee-pce-pcep-ls-15 (work in 758 progress), March 2020. 760 [I-D.ietf-spring-srv6-network-programming] 761 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 762 Matsushima, S., and Z. Li, "SRv6 Network Programming", 763 draft-ietf-spring-srv6-network-programming-16 (work in 764 progress), June 2020. 766 Appendix A. Contributor Addresses 768 Dhruv Dhody 769 Huawei Technologies 770 Divyashree Techno Park, Whitefield 771 Bangalore, Karnataka 560066 772 India 774 EMail: dhruv.ietf@gmail.com 776 Authors' Addresses 778 Zhenbin Li 779 Huawei Technologies 780 Huawei Bld., No.156 Beiqing Rd. 781 Beijing 100095 782 China 784 EMail: lizhenbin@huawei.com 786 Shuping Peng 787 Huawei Technologies 788 Huawei Bld., No.156 Beiqing Rd. 789 Beijing 100095 790 China 792 EMail: pengshuping@huawei.com 794 Xuesong Geng 795 Huawei Technologies 796 China 798 EMail: gengxuesong@huawei.com 800 Mahendra Singh Negi 801 RtBrick India 802 N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3 803 Bangalore, Karnataka 560102 804 India 806 EMail: mahend.ietf@gmail.com