idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-srv6-02.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 (August 22, 2019) is 1709 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-02 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-02 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-05 -- 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-04 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-12 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-06 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-13 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-22 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Negi 3 Internet-Draft Z. Li 4 Intended status: Standards Track X. Geng 5 Expires: February 23, 2020 Huawei Technologies 6 August 22, 2019 8 PCEP Procedures and Protocol Extensions for Using PCE as a Central 9 Controller (PCECC) for SRv6 10 draft-dhody-pce-pcep-extension-pce-controller-srv6-02 12 Abstract 14 The Path Computation Element (PCE) is a core component of Software- 15 Defined Networking (SDN) systems. It can compute optimal paths for 16 traffic across a network and can also update the paths to reflect 17 changes in the network or traffic demands. 19 PCE was developed to derive paths for MPLS Label Switched Paths 20 (LSPs), which are supplied to the head end of the LSP using the Path 21 Computation Element Communication Protocol (PCEP). But SDN has a 22 broader applicability than signaled (G)MPLS traffic-engineered (TE) 23 networks, and the PCE may be used to determine paths in a range of 24 use cases. PCEP has been proposed as a control protocol for use in 25 these environments to allow the PCE to be fully enabled as a central 26 controller. 28 A PCE-based central controller (PCECC) can simplify the processing of 29 a distributed control plane by blending it with elements of SDN and 30 without necessarily completely replacing it. This document specifies 31 the procedures and PCEP protocol extensions when a PCE-based 32 controller is also responsible for configuring the forwarding actions 33 on the routers for Segment Routing in IPv6 (SRv6), in addition to 34 computing the SRv6 paths for packet flows and telling the edge 35 routers what instructions to attach to packets as they enter the 36 network. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on February 23, 2020. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. PCECC SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 77 5. Procedures for Using the PCE as the Central Controller 78 (PCECC) in SRv6 . . . . . . . . . . . . . . . . . . . . . . . 6 79 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 80 5.2. New Functions . . . . . . . . . . . . . . . . . . . . . . 6 81 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 82 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 7 83 5.5. SRv6 Path Operations . . . . . . . . . . . . . . . . . . 7 84 5.5.1. PCECC Segment Routing in IPv6 (SRv6) . . . . . . . . 7 85 5.5.1.1. PCECC SRv6 Node/Prefix SID allocation . . . . . . 7 86 5.5.1.2. PCECC SRv6 Adjacency SID allocation . . . . . . . 8 87 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 9 88 5.5.1.4. Re Delegation and Cleanup . . . . . . . . . . . . 9 89 5.5.1.5. Synchronization of SRv6 SID Allocations . . . . . 9 90 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 9 91 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 9 92 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 9 93 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 9 94 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10 95 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 96 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 11 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 98 9. Manageability Considerations . . . . . . . . . . . . . . . . 11 99 9.1. Control of Function and Policy . . . . . . . . . . . . . 11 100 9.2. Information and Data Models . . . . . . . . . . . . . . . 11 101 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 102 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 103 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 104 9.6. Impact On Network Operations . . . . . . . . . . . . . . 12 105 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 106 10.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 12 107 10.2. New Path Setup Type Registry . . . . . . . . . . . . . . 12 108 10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 13 109 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 112 12.2. Informative References . . . . . . . . . . . . . . . . . 14 113 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 17 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 116 1. Introduction 118 The Path Computation Element (PCE) [RFC4655] was developed to offload 119 path computation function from routers in an MPLS traffic-engineered 120 network. Since then, the role and function of the PCE has grown to 121 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 122 delegated control [RFC8231] and PCE-initiated use of network 123 resources [RFC8281]. 125 According to [RFC7399], Software-Defined Networking (SDN) refers to a 126 separation between the control elements and the forwarding components 127 so that software running in a centralized system, called a 128 controller, can act to program the devices in the network to behave 129 in specific ways. A required element in an SDN architecture is a 130 component that plans how the network resources will be used and how 131 the devices will be programmed. It is possible to view this 132 component as performing specific computations to place traffic flows 133 within the network given knowledge of the availability of network 134 resources, how other forwarding devices are programmed, and the way 135 that other flows are routed. This is the function and purpose of a 136 PCE, and the way that a PCE integrates into a wider network control 137 system (including an SDN system) is presented in [RFC7491]. 139 In early PCE implementations, where the PCE was used to derive paths 140 for MPLS Label Switched Paths (LSPs), paths were requested by network 141 elements (known as Path Computation Clients (PCCs)), and the results 142 of the path computations were supplied to network elements using the 143 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 145 This protocol was later extended to allow a PCE to send unsolicited 146 requests to the network for LSP establishment [RFC8281]. 148 [RFC8283] introduces the architecture for PCE as a central controller 149 as an extension of the architecture described in [RFC4655] and 150 assumes the continued use of PCEP as the protocol used between PCE 151 and PCC. [RFC8283] further examines the motivations and 152 applicability for PCEP as a Southbound Interface (SBI), and 153 introduces the implications for the protocol. 154 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 155 architecture. 157 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 158 procedures and PCEP protocol extensions for using the PCE as the 159 central controller for static LSPs, where LSPs can be provisioned as 160 explicit label instructions at each hop on the end-to-end path. 162 Segment Routing (SR) technology leverages the source routing and 163 tunneling paradigms. A source node can choose a path without relying 164 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 165 is specified as a set of "segments" advertised by link-state routing 166 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to SR 167 architecture. The corresponding IS-IS and OSPF extensions are 168 specified in [I-D.ietf-isis-segment-routing-extensions] and 169 [I-D.ietf-ospf-segment-routing-extensions] , respectively. It relies 170 on a series of forwarding instructions being placed in the header of 171 a packet. The list of segment forming the path is called the Segment 172 List and is encoded in the packet header. Segment Routing can be 173 applied to the IPv6 architecture with the Segment Routing Header 174 (SRH) [I-D.ietf-6man-segment-routing-header]. A segment is encoded 175 as an IPv6 address. An ordered list of segments is encoded as an 176 ordered list of IPv6 addresses in the routing header. The active 177 segment is indicated by the Destination Address of the packet. Upon 178 completion of a segment, a pointer in the new routing header is 179 incremented and indicates the next segment. The segment routing 180 architecture supports operations that can be used to steer packet 181 flows in a network, thus providing a form of traffic engineering. 182 [I-D.ietf-pce-segment-routing] 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 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 213 allow a stateful PCE to compute, update or initiate SR-TE paths for 214 MPLS dataplane. An ingress node of an SR-TE path appends all 215 outgoing packets with a list of MPLS labels (SIDs). This is encoded 216 in SR-ERO subobject, capable of carrying a label (SID) as well as the 217 identity of the node/adjacency label (SID). 218 [I-D.ietf-pce-segment-routing-ipv6] extends the procedure to include 219 support for SRv6 paths. 221 As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 222 128-bit value. "SRv6 SID" or simply "SID" are often used as a 223 shorter reference for "SRv6 Segment". Further details are in an 224 illustration provided in [I-D.ietf-spring-srv6-network-programming]. 225 The SR is applied to IPV6 forwarding plane using SRH. A SR path can 226 be derived from an IGP Shortest Path Tree (SPT), but SR-TE paths may 227 not follow IGP SPT. Such paths may be chosen by a suitable network 228 planning tool, or a PCE and provisioned on the ingress node. 229 [I-D.ietf-pce-segment-routing-ipv6] extended SR-ERO subobject capable 230 of carrying an SRv6 SID as well as the identity of the node/adjacency 231 represented by the SID. 233 As per [RFC8283], PCE as a central controller can allocate and 234 provision the node/prefix/adjacency label (SID) via PCEP. As per 235 [I-D.ietf-teas-pcecc-use-cases] this is also applicable to SRv6 SIDs. 237 Rest of the processing is similar to existing stateful PCE with SRv6 238 mechanism. 240 4. PCEP Requirements 242 Following key requirements for PCECC-SRv6 should be considered when` 243 designing the PCECC based solution: 245 o PCEP speaker supporting this draft MUST have the capability to 246 advertise its PCECC-SRv6 capability to its peers. 248 o PCEP speaker not supporting this draft MUST be able to reject 249 PCECC-SRv6 related message with a reason code that indicates no 250 support for it. 252 o PCEP procedures MUST provide a means to update (or cleanup) the 253 SRv6 SID to the PCC. 255 o PCEP procedures SHOULD provide a means to synchronize the SRv6 SID 256 allocations between PCE to PCC in the PCEP messages. 258 5. Procedures for Using the PCE as the Central Controller (PCECC) in 259 SRv6 261 5.1. Stateful PCE Model 263 Active stateful PCE is described in [RFC8231]. PCE as a central 264 controller (PCECC) reuses existing Active stateful PCE mechanism as 265 much as possible to control the LSP. 267 5.2. New Functions 269 This document uses the same PCEP messages and its extensions which 270 are described in [I-D.ietf-pce-pcep-extension-for-pce-controller] and 271 [I-D.zhao-pce-pcep-extension-pce-controller-sr] for PCECC-SRv6 as 272 well. 274 PCEP messages PCRpt, PCInitiate, PCUpd are also used to send LSP 275 Reports, LSP setup and LSP update respectively. The extended 276 PCInitiate message described in 277 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 278 or cleanup central controller's instructions (CCIs) (SRv6 SID in 279 scope of this document). The extended PCRpt message described in 280 [I-D.ietf-pce-pcep-extension-for-pce-controller] is also used to 281 report the CCIs (SRv6 SIDs) from PCC to PCE. 283 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 284 called CCI for the encoding of central controller's instructions. 285 [I-D.zhao-pce-pcep-extension-pce-controller-sr] extends the CCI by 286 defining a object-type for segment routing. This document further 287 extends the CCI by defining another object-type for SRv6. 289 5.3. PCECC Capability Advertisement 291 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 292 advertise their support of PCECC extensions. A PCEP Speaker includes 293 the "PCECC Capability" sub-TLV, described in 294 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 296 A S-bit is added in PCECC-CAPABILITY sub-TLV to indicate support for 297 PCECC-SR in [I-D.zhao-pce-pcep-extension-pce-controller-sr]. This 298 document adds another I-bit to indicate support for SR in IPv6. A 299 PCC MUST set I-bit in PCECC-CAPABILITY sub-TLV and include SRv6-PCE- 300 CAPABILITY sub-TLV ([I-D.ietf-pce-segment-routing-ipv6]) in OPEN 301 Object (inside the the PATH-SETUP-TYPE-CAPABILITY TLV) to support the 302 PCECC SRv6 extensions defined in this document. If I-bit is set in 303 PCECC-CAPABILITY sub-TLV and SRv6-PCE-CAPABILITY sub-TLV is not 304 advertised in OPEN Object, PCE SHOULD send a PCErr message with 305 Error-Type=19 (Invalid Operation) and Error-value=TBD(SRv6 capability 306 was not advertised) and terminate the session. 308 5.4. PCEP session IP address and TEDB Router ID 310 As described in [I-D.zhao-pce-pcep-extension-pce-controller-sr], it 311 is important to link the session IP address with the Router ID in 312 TEDB for successful PCECC operations. 314 5.5. SRv6 Path Operations 316 The PCEP messages pertaining to PCECC-SRv6 MUST include PATH-SETUP- 317 TYPE TLV [RFC8408] with PST=TBD in the SRP object to clearly identify 318 the PCECC-SRv6 setup is intended. 320 5.5.1. PCECC Segment Routing in IPv6 (SRv6) 322 Segment Routing (SR) as described in [RFC8402] depends on "segments" 323 that are advertised by Interior Gateway Protocols (IGPs). The SR- 324 node allocates and advertises the SID (node, adj etc) and flood via 325 the IGP. This document proposes a new mechanism where PCE allocates 326 the SRv6 SID centrally and uses PCEP to advertise the SRv6 SID. In 327 some deployments PCE (and PCEP) are better suited than IGP because of 328 centralized nature of PCE and direct TCP based PCEP session to the 329 node. 331 5.5.1.1. PCECC SRv6 Node/Prefix SID allocation 333 Each node (PCC) is allocated a node SRv6 SID by the PCECC. The PCECC 334 sends PCInitiate message to update the SID table of each node. The 335 TE router ID is determined from the TEDB or from "IPv4/IPv6 Router- 336 ID" Sub-TLV [I-D.dhodylee-pce-pcep-ls], in the OPEN Object. 338 On receiving the SRv6 node SID allocation, each node (PCC) uses the 339 local routing information to determine the next-hop and download the 340 forwarding instructions accordingly. The PCInitiate message in this 341 case MUST have FEC object. 343 On receiving the SRv6 node SID allocation: 345 For the local SID, node (PCC) needs to update SID with associated 346 function (END function in this case) in "My Local SID Table" 347 ([I-D.ietf-spring-srv6-network-programming]). 349 For the non-local SID, node (PCC) uses the local routing 350 information to determine the next-hop and download the forwarding 351 instructions accordingly. 353 The PCInitiate message in this case MUST have FEC object. 355 The forwarding behavior and the end result is similar to IGP based 356 "Node-SID" in SRv6. Thus, from anywhere in the domain, it enforces 357 the ECMP-aware shortest-path forwarding of the packet towards the 358 related node. 360 PCE relies on the Node/Prefix SRv6 SID cleanup using the same 361 PCInitiate message. 363 5.5.1.2. PCECC SRv6 Adjacency SID allocation 365 [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE 366 to compute and initiate SR-TE paths, as well as a PCC to request a 367 path subject to certain constraint(s) and optimization criteria in SR 368 networks. 370 For PCECC SR, apart from node-SID, Adj-SID is used where each 371 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 372 PCInitiate message to update the label map of each Adj to the 373 corresponding nodes in the domain. Each node (PCC) download the SRv6 374 SID instructions accordingly. Similar to SRv6 Node/Prefix Label 375 allocation, the PCInitiate message in this case uses the FEC object. 377 The forwarding behavior and the end result is similar to IGP based 378 "Adj-SID" in SRv6. 380 The Path Setup Type for segment routing MUST be set for PCECC SRv6 = 381 TBD (see Section 7.2). All PCEP procedures and mechanism are similar 382 to [I-D.ietf-pce-segment-routing]. 384 PCE relies on the Adj label cleanup using the same PCInitiate 385 message. 387 5.5.1.3. Redundant PCEs 389 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 390 between the stateful PCEs. The SRv6 SIDs allocated by a PCE MUST 391 also be synchronized among PCEs for PCECC SRv6 state synchronization. 392 Note that the SRv6 SIDs are independent to the PCECC-SRv6 paths, and 393 remains intact till any topology change. The redundant PCEs MUST 394 have a common view of all SRv6 SIDs allocated in the domain. 396 5.5.1.4. Re Delegation and Cleanup 398 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the action 399 needed for CCIs for the Basic PCECC LSP on this terminated session. 400 Similarly actions should be applied for the SRv6 SID as well. 402 5.5.1.5. Synchronization of SRv6 SID Allocations 404 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the 405 synchronization of Central Controller's Instructions (CCI) via LSP 406 state synchronization as described in [RFC8231] and [RFC8232]. Same 407 procedures should be applied for SRv6 SIDs as well. 409 6. PCEP messages 411 The PCEP message is as per 412 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 414 7. PCEP Objects 416 7.1. OPEN Object 418 7.1.1. PCECC Capability sub-TLV 420 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 421 CAPABILITY TLV. 423 A new I-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SRv6: 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type=TBD | Length=4 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Flags |I|S| 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 I (PCECC-SRv6-CAPABILITY - 1 bit): If set to 1 by a PCEP speaker, it 434 indicates that the PCEP speaker is capable for PCECC-SRv6 capability 435 and PCE would allocate node and Adj SRv6 SID on this session. 437 7.2. PATH-SETUP-TYPE TLV 439 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. PST = TBD is used 440 when Path is setup via PCECC SRv6 mode. 442 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD indicates that this 443 path was setup via a PCECC-SRv6 based mechanism where either the SIDs 444 were allocated/instructed by PCE via PCECC mechanism. 446 7.3. CCI Object 448 The Central Control Instructions (CCI) Object is used by the PCE to 449 specify the forwarding instructions is defined in 450 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 451 defines another object-type for SRv6 purpose. 453 CCI Object-Type is TBD for SRv6 as below - 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | CC-ID | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | MT-ID | Algorithm | Flags |N|E|V|L|O| 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Reserved | SRv6 Endpoint Function | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | | 465 | SRv6 Identifier | 466 | (128-bit) | 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 // Optional TLV // 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 The field CC-ID is as described in 475 [I-D.ietf-pce-pcep-extension-for-pce-controller]. The field MT-ID, 476 Algorithm, Flags are defined in 477 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 479 Reserved: MUST be set to 0 while sending and ignored on receipt. 481 SRv6 Endpoint Function: 16 bit field representing supported functions 482 associated with SRv6 SIDs. 484 SRv6 Identifier: 128 bit IPv6 addresses representing SRv6 segment. 486 [Editor's Note - It might be useful to seperate the LOC:FUNC part in 487 the SRv6 SID] 489 7.4. FEC Object 491 The FEC Object is used to specify the FEC information and MAY be 492 carried within PCInitiate or PCRpt message. 494 FEC Object (and various Object-Types) are described in 495 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. SRv6 Node SID MUST 496 includes the FEC Object-Type 2 for IPv6 Node. SRv6 Adjacency SID 497 MUST include the FEC Object-Type=4 for IPv6 adjacency. Further FEC 498 object types would be added in future revisions. 500 8. Security Considerations 502 The security considerations described in 503 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the 504 extensions described in this document. 506 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 507 be activated on authenticated and encrypted sessions across PCEs and 508 PCCs belonging to the same administrative authority, using Transport 509 Layer Security (TLS) [RFC8253] as per the recommendations and best 510 current practices in [RFC7525] (unless explicitly set aside in 511 [RFC8253]). 513 9. Manageability Considerations 515 9.1. Control of Function and Policy 517 A PCE or PCC implementation SHOULD allow to configure to enable/ 518 disable PCECC SR capability as a global configuration. 520 9.2. Information and Data Models 522 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 523 PCECC SR capability status. 525 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 526 enable/disable PCECC SR capability. 528 9.3. Liveness Detection and Monitoring 530 Mechanisms defined in this document do not imply any new liveness 531 detection and monitoring requirements in addition to those already 532 listed in [RFC5440]. 534 9.4. Verify Correct Operations 536 Mechanisms defined in this document do not imply any new operation 537 verification requirements in addition to those already listed in 538 [RFC5440] and [RFC8231]. 540 9.5. Requirements On Other Protocols 542 PCEP extensions defined in this document do not put new requirements 543 on other protocols. 545 9.6. Impact On Network Operations 547 PCEP implementation SHOULD allow a limit to be placed on the rate of 548 PCInitiate/PCUpd messages (as per [RFC8231]) sent by PCE and 549 processed by PCC. It SHOULD also allow sending a notification when a 550 rate threshold is reached. 552 10. IANA Considerations 554 10.1. PCECC-CAPABILITY TLV 556 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 557 CAPABILITY TLV and requests that IANA creates a registry to manage 558 the value of the PCECC-CAPABILITY TLV's Flag field. IANA is 559 requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag 560 Field registry, as follows: 562 Bit Description Reference 563 TBD I((PCECC-SRv6-CAPABILITY)) This document 565 10.2. New Path Setup Type Registry 567 IANA is requested to allocate new PST Field in PATH- SETUP-TYPE TLV. 568 The allocation policy for this new registry should be by IETF 569 Consensus. The new registry should contain the following value: 571 Value Description Reference 572 TBD Path is This document 573 setup using PCECC-SRv6 mode 575 10.3. PCEP-Error Object 577 IANA is requested to allocate new error types and error values within 578 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 579 PCEP Numbers registry for the following errors: 581 Error-Type Meaning 582 ---------- ------- 583 19 Invalid operation. 585 Error-value = TBD : SRv6 capability was 586 not advertised 588 11. Acknowledgments 590 12. References 592 12.1. Normative References 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, 597 . 599 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 600 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 601 DOI 10.17487/RFC5440, March 2009, 602 . 604 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 605 Hardwick, "Path Computation Element Communication Protocol 606 (PCEP) Management Information Base (MIB) Module", 607 RFC 7420, DOI 10.17487/RFC7420, December 2014, 608 . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 615 Computation Element Communication Protocol (PCEP) 616 Extensions for Stateful PCE", RFC 8231, 617 DOI 10.17487/RFC8231, September 2017, 618 . 620 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 621 Computation Element Communication Protocol (PCEP) 622 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 623 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 624 . 626 [I-D.ietf-pce-segment-routing-ipv6] 627 Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y. 628 Zhu, "PCEP Extensions for Segment Routing leveraging the 629 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-02 630 (work in progress), April 2019. 632 [I-D.ietf-pce-pcep-extension-for-pce-controller] 633 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 634 and Protocol Extensions for Using PCE as a Central 635 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 636 extension-for-pce-controller-02 (work in progress), July 637 2019. 639 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 640 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 641 and Protocol Extensions for Using PCE as a Central 642 Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- 643 extension-pce-controller-sr-05 (work in progress), July 644 2019. 646 12.2. Informative References 648 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 649 Element (PCE)-Based Architecture", RFC 4655, 650 DOI 10.17487/RFC4655, August 2006, 651 . 653 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 654 Margaria, "Requirements for GMPLS Applications of PCE", 655 RFC 7025, DOI 10.17487/RFC7025, September 2013, 656 . 658 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 659 Computation Element Architecture", RFC 7399, 660 DOI 10.17487/RFC7399, October 2014, 661 . 663 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 664 Application-Based Network Operations", RFC 7491, 665 DOI 10.17487/RFC7491, March 2015, 666 . 668 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 669 "Recommendations for Secure Use of Transport Layer 670 Security (TLS) and Datagram Transport Layer Security 671 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 672 2015, . 674 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 675 and D. Dhody, "Optimizations of Label Switched Path State 676 Synchronization Procedures for a Stateful PCE", RFC 8232, 677 DOI 10.17487/RFC8232, September 2017, 678 . 680 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 681 "PCEPS: Usage of TLS to Provide a Secure Transport for the 682 Path Computation Element Communication Protocol (PCEP)", 683 RFC 8253, DOI 10.17487/RFC8253, October 2017, 684 . 686 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 687 Architecture for Use of PCE and the PCE Communication 688 Protocol (PCEP) in a Network with Central Control", 689 RFC 8283, DOI 10.17487/RFC8283, December 2017, 690 . 692 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 693 Decraene, B., Litkowski, S., and R. Shakir, "Segment 694 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 695 July 2018, . 697 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 698 Hardwick, "Conveying Path Setup Type in PCE Communication 699 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 700 July 2018, . 702 [I-D.ietf-teas-pcecc-use-cases] 703 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 704 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 705 Gulida, "The Use Cases for Path Computation Element (PCE) 706 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 707 use-cases-04 (work in progress), July 2019. 709 [I-D.ietf-pce-pcep-yang] 710 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 711 YANG Data Model for Path Computation Element 712 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 713 yang-12 (work in progress), July 2019. 715 [I-D.ietf-pce-segment-routing] 716 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 717 and J. Hardwick, "PCEP Extensions for Segment Routing", 718 draft-ietf-pce-segment-routing-16 (work in progress), 719 March 2019. 721 [I-D.ietf-isis-segment-routing-extensions] 722 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 723 Gredler, H., and B. Decraene, "IS-IS Extensions for 724 Segment Routing", draft-ietf-isis-segment-routing- 725 extensions-25 (work in progress), May 2019. 727 [I-D.ietf-ospf-segment-routing-extensions] 728 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 729 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 730 Extensions for Segment Routing", draft-ietf-ospf-segment- 731 routing-extensions-27 (work in progress), December 2018. 733 [I-D.litkowski-pce-state-sync] 734 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 735 Stateful Path Computation Element (PCE) Communication 736 Procedures.", draft-litkowski-pce-state-sync-06 (work in 737 progress), July 2019. 739 [I-D.dhodylee-pce-pcep-ls] 740 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 741 Distribution of Link-State and TE Information.", draft- 742 dhodylee-pce-pcep-ls-13 (work in progress), February 2019. 744 [I-D.ietf-spring-srv6-network-programming] 745 Filsfils, C., Camarillo, P., Leddy, J., 746 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 747 Network Programming", draft-ietf-spring-srv6-network- 748 programming-01 (work in progress), July 2019. 750 [I-D.ietf-6man-segment-routing-header] 751 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 752 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 753 Routing Header (SRH)", draft-ietf-6man-segment-routing- 754 header-22 (work in progress), August 2019. 756 Appendix A. Contributor Addresses 758 Dhruv Dhody 759 Huawei Technologies 760 Divyashree Techno Park, Whitefield 761 Bangalore, Karnataka 560066 762 India 764 EMail: dhruv.ietf@gmail.com 766 Authors' Addresses 768 Mahendra Singh Negi 769 Huawei Technologies 770 Divyashree Techno Park, Whitefield 771 Bangalore, Karnataka 560066 772 India 774 EMail: mahend.ietf@gmail.com 776 Zhenbin Li 777 Huawei Technologies 778 Huawei Bld., No.156 Beiqing Rd. 779 Beijing 100095 780 China 782 EMail: lizhenbin@huawei.com 784 Xuesong Geng 785 Huawei Technologies 786 China 788 EMail: gengxuesong@huawei.com