idnits 2.17.1 draft-dhody-pce-pcep-extension-pce-controller-srv6-00.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 (October 22, 2018) is 2012 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 (-04) exists of draft-negi-pce-segment-routing-ipv6-03 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-03 == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-02 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-14 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-19 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-25 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-03 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-11 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Z. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 25, 2019 October 22, 2018 7 PCEP Procedures and Protocol Extensions for Using PCE as a Central 8 Controller (PCECC) for SRv6 9 draft-dhody-pce-pcep-extension-pce-controller-srv6-00 11 Abstract 13 The Path Computation Element (PCE) is a core component of Software- 14 Defined Networking (SDN) systems. It can compute optimal paths for 15 traffic across a network and can also update the paths to reflect 16 changes in the network or traffic demands. 18 PCE was developed to derive paths for MPLS Label Switched Paths 19 (LSPs), which are supplied to the head end of the LSP using the Path 20 Computation Element Communication Protocol (PCEP). But SDN has a 21 broader applicability than signaled (G)MPLS traffic-engineered (TE) 22 networks, and the PCE may be used to determine paths in a range of 23 use cases. PCEP has been proposed as a control protocol for use in 24 these environments to allow the PCE to be fully enabled as a central 25 controller. 27 A PCE-based central controller (PCECC) can simplify the processing of 28 a distributed control plane by blending it with elements of SDN and 29 without necessarily completely replacing it. This document specifies 30 the procedures and PCEP protocol extensions when a PCE-based 31 controller is also responsible for configuring the forwarding actions 32 on the routers for Segment Routing in IPv6 (SRv6), in addition to 33 computing the SRv6 paths for packet flows and telling the edge 34 routers what instructions to attach to packets as they enter the 35 network. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 25, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. PCECC SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 76 5. Procedures for Using the PCE as the Central Controller 77 (PCECC) in SRv6 . . . . . . . . . . . . . . . . . . . . . . . 6 78 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 79 5.2. New Functions . . . . . . . . . . . . . . . . . . . . . . 6 80 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 81 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 7 82 5.5. SRv6 Path Operations . . . . . . . . . . . . . . . . . . 7 83 5.5.1. PCECC Segment Routing in IPv6 (SRv6) . . . . . . . . 7 84 5.5.1.1. PCECC SRv6 Node/Prefix SID allocation . . . . . . 7 85 5.5.1.2. PCECC SRv6 Adjacency SID allocation . . . . . . . 8 86 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 9 87 5.5.1.4. Re Delegation and Cleanup . . . . . . . . . . . . 9 88 5.5.1.5. Synchronization of SRv6 SID Allocations . . . . . 9 89 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 9 90 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 9 91 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 9 92 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 9 93 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 10 94 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 95 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 11 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 97 9. Manageability Considerations . . . . . . . . . . . . . . . . 11 98 9.1. Control of Function and Policy . . . . . . . . . . . . . 11 99 9.2. Information and Data Models . . . . . . . . . . . . . . . 11 100 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 11 101 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12 102 9.5. Requirements On Other Protocols . . . . . . . . . . . . . 12 103 9.6. Impact On Network Operations . . . . . . . . . . . . . . 12 104 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 105 10.1. PCECC-CAPABILITY TLV . . . . . . . . . . . . . . . . . . 12 106 10.2. New Path Setup Type Registry . . . . . . . . . . . . . . 12 107 10.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 12 108 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 110 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 111 12.2. Informative References . . . . . . . . . . . . . . . . . 14 112 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 17 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 115 1. Introduction 117 The Path Computation Element (PCE) [RFC4655] was developed to offload 118 path computation function from routers in an MPLS traffic-engineered 119 network. Since then, the role and function of the PCE has grown to 120 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 121 delegated control [RFC8231] and PCE-initiated use of network 122 resources [RFC8281]. 124 According to [RFC7399], Software-Defined Networking (SDN) refers to a 125 separation between the control elements and the forwarding components 126 so that software running in a centralized system, called a 127 controller, can act to program the devices in the network to behave 128 in specific ways. A required element in an SDN architecture is a 129 component that plans how the network resources will be used and how 130 the devices will be programmed. It is possible to view this 131 component as performing specific computations to place traffic flows 132 within the network given knowledge of the availability of network 133 resources, how other forwarding devices are programmed, and the way 134 that other flows are routed. This is the function and purpose of a 135 PCE, and the way that a PCE integrates into a wider network control 136 system (including an SDN system) is presented in [RFC7491]. 138 In early PCE implementations, where the PCE was used to derive paths 139 for MPLS Label Switched Paths (LSPs), paths were requested by network 140 elements (known as Path Computation Clients (PCCs)), and the results 141 of the path computations were supplied to network elements using the 142 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 143 This protocol was later extended to allow a PCE to send unsolicited 144 requests to the network for LSP establishment [RFC8281]. 146 [RFC8283] introduces the architecture for PCE as a central controller 147 as an extension of the architecture described in [RFC4655] and 148 assumes the continued use of PCEP as the protocol used between PCE 149 and PCC. [RFC8283] further examines the motivations and 150 applicability for PCEP as a Southbound Interface (SBI), and 151 introduces the implications for the protocol. 152 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 153 architecture. 155 [I-D.zhao-pce-pcep-extension-for-pce-controller] specify the 156 procedures and PCEP protocol extensions for using the PCE as the 157 central controller for static LSPs, where LSPs can be provisioned as 158 explicit label instructions at each hop on the end-to-end path. 160 Segment Routing (SR) technology leverages the source routing and 161 tunneling paradigms. A source node can choose a path without relying 162 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 163 is specified as a set of "segments" advertised by link-state routing 164 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to SR 165 architecture. The corresponding IS-IS and OSPF extensions are 166 specified in [I-D.ietf-isis-segment-routing-extensions] and 167 [I-D.ietf-ospf-segment-routing-extensions] , respectively. It relies 168 on a series of forwarding instructions being placed in the header of 169 a packet. The list of segment forming the path is called the Segment 170 List and is encoded in the packet header. Segment Routing can be 171 applied to the IPv6 architecture with the Segment Routing Header 172 (SRH) [I-D.ietf-6man-segment-routing-header]. A segment is encoded 173 as an IPv6 address. An ordered list of segments is encoded as an 174 ordered list of IPv6 addresses in the routing header. The active 175 segment is indicated by the Destination Address of the packet. Upon 176 completion of a segment, a pointer in the new routing header is 177 incremented and indicates the next segment. The segment routing 178 architecture supports operations that can be used to steer packet 179 flows in a network, thus providing a form of traffic engineering. 180 [I-D.ietf-pce-segment-routing] and 181 [I-D.negi-pce-segment-routing-ipv6] specify the SR specific PCEP 182 extensions. 184 PCECC may further use PCEP protocol for SR SID (Segment Identifier) 185 distribution on the SR nodes with some benefits. 186 [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the 187 procedures and PCEP protocol extensions when a PCE-based controller 188 is also responsible for configuring the forwarding actions on the 189 routers (SR SID distribution in this case), in addition to computing 190 the paths for packet flows in a segment routing network and telling 191 the edge routers what instructions to attach to packets as they enter 192 the network. This document extends this to include SRv6 SID 193 distribution as well. 195 1.1. Requirements Language 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 2. Terminology 205 Terminologies used in this document is same as described in the draft 206 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 208 3. PCECC SRv6 210 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 211 allow a stateful PCE to compute, update or initiate SR-TE paths for 212 MPLS dataplane. An ingress node of an SR-TE path appends all 213 outgoing packets with a list of MPLS labels (SIDs). This is encoded 214 in SR-ERO subobject, capable of carrying a label (SID) as well as the 215 identity of the node/adjacency label (SID). 216 [I-D.negi-pce-segment-routing-ipv6] extends the procedure to include 217 support for SRv6 paths. 219 As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 220 128-bit value. "SRv6 SID" or simply "SID" are often used as a 221 shorter reference for "SRv6 Segment". Further details are in an 222 illustration provided in 223 [I-D.filsfils-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.negi-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 MUST have the capability to 245 advertise its PCECC-SRv6 capability to its peers. 247 o PCEP speaker not supporting this draft MUST be able to reject 248 PCECC-SRv6 related message with a reason code that indicates no 249 support for it. 251 o PCEP procedures MUST provide a means to update (or cleanup) the 252 SRv6 SID to the PCC. 254 o PCEP procedures SHOULD provide a means to synchronize the SRv6 SID 255 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.zhao-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.zhao-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.zhao-pce-pcep-extension-for-pce-controller] is also used to 280 report the CCIs (SRv6 SIDs) from PCC to PCE. 282 [I-D.zhao-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.zhao-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.negi-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=TBD(SRv6 capability 305 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=TBD in the SRP object to clearly identify 317 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.filsfils-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 [I-D.ietf-pce-segment-routing] extends PCEP to allow a stateful PCE 365 to compute and initiate SR-TE paths, as well as a PCC to request a 366 path subject to certain constraint(s) and optimization criteria in SR 367 networks. 369 For PCECC SR, apart from node-SID, Adj-SID is used where each 370 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 371 PCInitiate message to update the label map of each Adj to the 372 corresponding nodes in the domain. Each node (PCC) download the SRv6 373 SID instructions accordingly. Similar to SRv6 Node/Prefix Label 374 allocation, the PCInitiate message in this case uses the FEC object. 376 The forwarding behavior and the end result is similar to IGP based 377 "Adj-SID" in SRv6. 379 The Path Setup Type for segment routing MUST be set for PCECC SRv6 = 380 TBD (see Section 7.2). All PCEP procedures and mechanism are similar 381 to [I-D.ietf-pce-segment-routing]. 383 PCE relies on the Adj label cleanup using the same PCInitiate 384 message. 386 5.5.1.3. Redundant PCEs 388 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 389 between the stateful PCEs. The SRv6 SIDs allocated by a PCE MUST 390 also be synchronized among PCEs for PCECC SRv6 state synchronization. 391 Note that the SRv6 SIDs are independent to the PCECC-SRv6 paths, and 392 remains intact till any topology change. The redundant PCEs MUST 393 have a common view of all SRv6 SIDs allocated in the domain. 395 5.5.1.4. Re Delegation and Cleanup 397 [I-D.zhao-pce-pcep-extension-for-pce-controller] describes the action 398 needed for CCIs for the Basic PCECC LSP on this terminated session. 399 Similarly actions should be applied for the SRv6 SID as well. 401 5.5.1.5. Synchronization of SRv6 SID Allocations 403 [I-D.zhao-pce-pcep-extension-for-pce-controller] describes the 404 synchronization of Central Controller's Instructions (CCI) via LSP 405 state synchronization as described in [RFC8231] and [RFC8232]. Same 406 procedures should be applied for SRv6 SIDs as well. 408 6. PCEP messages 410 The PCEP message is as per 411 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 413 7. PCEP Objects 415 7.1. OPEN Object 417 7.1.1. PCECC Capability sub-TLV 419 [I-D.zhao-pce-pcep-extension-for-pce-controller] defined the PCECC- 420 CAPABILITY TLV. 422 A new I-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SRv6: 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type=TBD | Length=4 | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Flags |I|S| 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 I (PCECC-SRv6-CAPABILITY - 1 bit): If set to 1 by a PCEP speaker, it 433 indicates that the PCEP speaker is capable for PCECC-SRv6 capability 434 and PCE would allocate node and Adj SRv6 SID on this session. 436 7.2. PATH-SETUP-TYPE TLV 438 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. PST = TBD is used 439 when Path is setup via PCECC SRv6 mode. 441 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD indicates that this 442 path was setup via a PCECC-SRv6 based mechanism where either the SIDs 443 were allocated/instructed by PCE via PCECC mechanism. 445 7.3. CCI Object 447 The Central Control Instructions (CCI) Object is used by the PCE to 448 specify the forwarding instructions is defined in 449 [I-D.zhao-pce-pcep-extension-for-pce-controller]. This document 450 defines another object-type for SRv6 purpose. 452 CCI Object-Type is TBD for SRv6 as below - 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | CC-ID | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | MT-ID | Algorithm | Flags |N|E|V|L|O| 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Reserved | SRv6 Endpoint Function | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 | SRv6 Identifier | 465 | (128-bit) | 466 | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 // Optional TLV // 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 The field CC-ID is as described in 474 [I-D.zhao-pce-pcep-extension-for-pce-controller]. The field MT-ID, 475 Algorithm, Flags are defined in 476 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 478 Reserved: MUST be set to 0 while sending and ignored on receipt. 480 SRv6 Endpoint Function: 16 bit field representing supported functions 481 associated with SRv6 SIDs. 483 SRv6 Identifier: 128 bit IPv6 addresses representing SRv6 segment. 485 [Editor's Note - It might be useful to seperate the LOC:FUNC part in 486 the SRv6 SID] 488 7.4. FEC Object 490 The FEC Object is used to specify the FEC information and MAY be 491 carried within PCInitiate or PCRpt message. 493 FEC Object (and various Object-Types) are described in 494 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. SRv6 Node SID MUST 495 includes the FEC Object-Type 2 for IPv6 Node. SRv6 Adjacency SID 496 MUST include the FEC Object-Type=4 for IPv6 adjacency. Further FEC 497 object types would be added in future revisions. 499 8. Security Considerations 501 The security considerations described in 502 [I-D.zhao-pce-pcep-extension-for-pce-controller] apply to the 503 extensions described in this document. 505 9. Manageability Considerations 507 9.1. Control of Function and Policy 509 A PCE or PCC implementation SHOULD allow to configure to enable/ 510 disable PCECC SR capability as a global configuration. 512 9.2. Information and Data Models 514 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 515 PCECC SR capability status. 517 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 518 enable/disable PCECC SR capability. 520 9.3. Liveness Detection and Monitoring 522 Mechanisms defined in this document do not imply any new liveness 523 detection and monitoring requirements in addition to those already 524 listed in [RFC5440]. 526 9.4. Verify Correct Operations 528 Mechanisms defined in this document do not imply any new operation 529 verification requirements in addition to those already listed in 530 [RFC5440] and [RFC8231]. 532 9.5. Requirements On Other Protocols 534 PCEP extensions defined in this document do not put new requirements 535 on other protocols. 537 9.6. Impact On Network Operations 539 PCEP implementation SHOULD allow a limit to be placed on the rate of 540 PCInitiate/PCUpd messages (as per [RFC8231]) sent by PCE and 541 processed by PCC. It SHOULD also allow sending a notification when a 542 rate threshold is reached. 544 10. IANA Considerations 546 10.1. PCECC-CAPABILITY TLV 548 [I-D.zhao-pce-pcep-extension-for-pce-controller] defines the PCECC- 549 CAPABILITY TLV and requests that IANA creates a registry to manage 550 the value of the PCECC-CAPABILITY TLV's Flag field. IANA is 551 requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag 552 Field registry, as follows: 554 Bit Description Reference 555 TBD I((PCECC-SRv6-CAPABILITY)) This document 557 10.2. New Path Setup Type Registry 559 IANA is requested to allocate new PST Field in PATH- SETUP-TYPE TLV. 560 The allocation policy for this new registry should be by IETF 561 Consensus. The new registry should contain the following value: 563 Value Description Reference 564 TBD Path is This document 565 setup using PCECC-SRv6 mode 567 10.3. PCEP-Error Object 569 IANA is requested to allocate new error types and error values within 570 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 571 PCEP Numbers registry for the following errors: 573 Error-Type Meaning 574 ---------- ------- 575 19 Invalid operation. 577 Error-value = TBD : SRv6 capability was 578 not advertised 580 11. Acknowledgments 582 12. References 584 12.1. Normative References 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, 588 DOI 10.17487/RFC2119, March 1997, 589 . 591 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 592 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 593 DOI 10.17487/RFC5440, March 2009, 594 . 596 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 597 Hardwick, "Path Computation Element Communication Protocol 598 (PCEP) Management Information Base (MIB) Module", 599 RFC 7420, DOI 10.17487/RFC7420, December 2014, 600 . 602 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 603 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 604 May 2017, . 606 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 607 Computation Element Communication Protocol (PCEP) 608 Extensions for Stateful PCE", RFC 8231, 609 DOI 10.17487/RFC8231, September 2017, 610 . 612 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 613 Computation Element Communication Protocol (PCEP) 614 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 615 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 616 . 618 [I-D.negi-pce-segment-routing-ipv6] 619 Negi, M., Dhody, D., Sivabalan, S., and P. Kaladharan, 620 "PCEP Extensions for Segment Routing leveraging the IPv6 621 data plane", draft-negi-pce-segment-routing-ipv6-03 (work 622 in progress), October 2018. 624 [I-D.zhao-pce-pcep-extension-for-pce-controller] 625 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 626 and C. Zhou, "PCEP Procedures and Protocol Extensions for 627 Using PCE as a Central Controller (PCECC) of LSPs", draft- 628 zhao-pce-pcep-extension-for-pce-controller-08 (work in 629 progress), June 2018. 631 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 632 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 633 and C. Zhou, "PCEP Procedures and Protocol Extensions for 634 Using PCE as a Central Controller (PCECC) of SR-LSPs", 635 draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work 636 in progress), June 2018. 638 12.2. Informative References 640 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 641 Element (PCE)-Based Architecture", RFC 4655, 642 DOI 10.17487/RFC4655, August 2006, 643 . 645 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 646 Margaria, "Requirements for GMPLS Applications of PCE", 647 RFC 7025, DOI 10.17487/RFC7025, September 2013, 648 . 650 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 651 Computation Element Architecture", RFC 7399, 652 DOI 10.17487/RFC7399, October 2014, 653 . 655 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 656 Application-Based Network Operations", RFC 7491, 657 DOI 10.17487/RFC7491, March 2015, 658 . 660 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 661 and D. Dhody, "Optimizations of Label Switched Path State 662 Synchronization Procedures for a Stateful PCE", RFC 8232, 663 DOI 10.17487/RFC8232, September 2017, 664 . 666 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 667 Architecture for Use of PCE and the PCE Communication 668 Protocol (PCEP) in a Network with Central Control", 669 RFC 8283, DOI 10.17487/RFC8283, December 2017, 670 . 672 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 673 Decraene, B., Litkowski, S., and R. Shakir, "Segment 674 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 675 July 2018, . 677 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 678 Hardwick, "Conveying Path Setup Type in PCE Communication 679 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 680 July 2018, . 682 [I-D.ietf-teas-pcecc-use-cases] 683 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 684 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 685 Gulida, "The Use Cases for Path Computation Element (PCE) 686 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 687 use-cases-02 (work in progress), October 2018. 689 [I-D.ietf-pce-pcep-yang] 690 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 691 YANG Data Model for Path Computation Element 692 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 693 yang-09 (work in progress), October 2018. 695 [I-D.ietf-pce-segment-routing] 696 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 697 and J. Hardwick, "PCEP Extensions for Segment Routing", 698 draft-ietf-pce-segment-routing-14 (work in progress), 699 October 2018. 701 [I-D.ietf-isis-segment-routing-extensions] 702 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 703 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 704 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 705 segment-routing-extensions-19 (work in progress), July 706 2018. 708 [I-D.ietf-ospf-segment-routing-extensions] 709 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 710 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 711 Extensions for Segment Routing", draft-ietf-ospf-segment- 712 routing-extensions-25 (work in progress), April 2018. 714 [I-D.litkowski-pce-state-sync] 715 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 716 Stateful Path Computation Element communication 717 procedures", draft-litkowski-pce-state-sync-03 (work in 718 progress), April 2018. 720 [I-D.dhodylee-pce-pcep-ls] 721 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 722 Distribution of Link-State and TE Information.", draft- 723 dhodylee-pce-pcep-ls-11 (work in progress), June 2018. 725 [I-D.filsfils-spring-srv6-network-programming] 726 Filsfils, C., Camarillo, P., Leddy, J., 727 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 728 Network Programming", draft-filsfils-spring-srv6-network- 729 programming-05 (work in progress), July 2018. 731 [I-D.ietf-6man-segment-routing-header] 732 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 733 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 734 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 735 progress), June 2018. 737 Appendix A. Contributor Addresses 739 Mahendra Singh Negi 740 Huawei Technologies 741 Divyashree Techno Park, Whitefield 742 Bangalore, Karnataka 560066 743 India 745 EMail: mahendrasingh@huawei.com 747 Authors' Addresses 749 Dhruv Dhody 750 Huawei Technologies 751 Divyashree Techno Park, Whitefield 752 Bangalore, Karnataka 560066 753 India 755 EMail: dhruv.ietf@gmail.com 757 Zhenbin Li 758 Huawei Technologies 759 Huawei Bld., No.156 Beiqing Rd. 760 Beijing 100095 761 China 763 EMail: lizhenbin@huawei.com