idnits 2.17.1 draft-zhao-pce-pcep-extension-pce-controller-sr-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2020) is 1509 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) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-03 == 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 (-16) exists of draft-ietf-pce-binding-label-sid-01 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-07 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-14 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft Z. Li 4 Intended status: Standards Track M. Negi 5 Expires: September 9, 2020 S. Peng 6 Huawei Technologies 7 C. Zhou 8 Cisco Systems 9 March 8, 2020 11 PCEP Procedures and Protocol Extensions for Using PCE as a Central 12 Controller (PCECC) of SR-LSPs 13 draft-zhao-pce-pcep-extension-pce-controller-sr-06 15 Abstract 17 The Path Computation Element (PCE) is a core component of Software- 18 Defined Networking (SDN) systems. It can compute optimal paths for 19 traffic across a network and can also update the paths to reflect 20 changes in the network or traffic demands. 22 PCE was developed to derive paths for MPLS Label Switched Paths 23 (LSPs), which are supplied to the head end of the LSP using the Path 24 Computation Element Communication Protocol (PCEP). But SDN has a 25 broader applicability than signaled (G)MPLS traffic-engineered (TE) 26 networks, and the PCE may be used to determine paths in a range of 27 use cases. PCEP has been proposed as a control protocol for use in 28 these environments to allow the PCE to be fully enabled as a central 29 controller. 31 A PCE-based central controller (PCECC) can simplify the processing of 32 a distributed control plane by blending it with elements of SDN and 33 without necessarily completely replacing it. Thus, the LSP can be 34 calculated/setup/initiated and the label forwarding entries can also 35 be downloaded through a centralized PCE server to each network 36 devices along the path while leveraging the existing PCE technologies 37 as much as possible. 39 This document specifies the procedures and PCEP protocol extensions 40 when a PCE-based controller is also responsible for configuring the 41 forwarding actions on the routers, in addition to computing the paths 42 for packet flows in a segment routing network and telling the edge 43 routers what instructions to attach to packets as they enter the 44 network. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on September 9, 2020. 63 Copyright Notice 65 Copyright (c) 2020 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 82 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3. PCECC SR . . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 85 5. Procedures for Using the PCE as the Central Controller 86 (PCECC) in Segment Routing . . . . . . . . . . . . . . . . . 6 87 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 88 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 89 5.3. PCECC Capability Advertisement . . . . . . . . . . . . . 7 90 5.4. PCEP session IP address and TEDB Router ID . . . . . . . 7 91 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 8 92 5.5.1. PCECC Segment Routing (SR) . . . . . . . . . . . . . 8 93 5.5.1.1. PCECC SR Node/Prefix SID allocation . . . . . . . 8 94 5.5.1.2. PCECC SR Adjacency Label allocation . . . . . . . 10 95 5.5.1.3. Redundant PCEs . . . . . . . . . . . . . . . . . 12 96 5.5.1.4. Re Delegation and Cleanup . . . . . . . . . . . . 12 97 5.5.1.5. Synchronization of Label Allocations . . . . . . 13 98 5.5.1.6. PCC Based Allocations . . . . . . . . . . . . . . 13 99 5.5.1.7. Binding SID . . . . . . . . . . . . . . . . . . . 13 100 6. PCEP messages . . . . . . . . . . . . . . . . . . . . . . . . 14 101 6.1. Central Control Instructions . . . . . . . . . . . . . . 14 102 6.1.1. The PCInitiate message . . . . . . . . . . . . . . . 14 103 6.1.2. The PCRpt message . . . . . . . . . . . . . . . . . . 15 104 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 16 105 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 16 106 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 16 107 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 17 108 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 17 109 7.4. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 19 110 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 111 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 22 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 113 10. Manageability Considerations . . . . . . . . . . . . . . . . 22 114 10.1. Control of Function and Policy . . . . . . . . . . . . . 22 115 10.2. Information and Data Models . . . . . . . . . . . . . . 22 116 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 23 117 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 23 118 10.5. Requirements On Other Protocols . . . . . . . . . . . . 23 119 10.6. Impact On Network Operations . . . . . . . . . . . . . . 23 120 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 121 11.1. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . . . 23 122 11.2. New Path Setup Type Registry . . . . . . . . . . . . . . 24 123 11.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 24 124 11.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 24 125 11.5. CCI Object Flag Field for SR . . . . . . . . . . . . . . 24 126 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 127 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 128 13.1. Normative References . . . . . . . . . . . . . . . . . . 25 129 13.2. Informative References . . . . . . . . . . . . . . . . . 27 130 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 30 131 Appendix B. Contributor Addresses . . . . . . . . . . . . . . . 30 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 134 1. Introduction 136 The Path Computation Element (PCE) [RFC4655] was developed to offload 137 path computation function from routers in an MPLS traffic-engineered 138 network. Since then, the role and function of the PCE has grown to 139 cover a number of other uses (such as GMPLS [RFC7025]) and to allow 140 delegated control [RFC8231] and PCE-initiated use of network 141 resources [RFC8281]. 143 According to [RFC7399], Software-Defined Networking (SDN) refers to a 144 separation between the control elements and the forwarding components 145 so that software running in a centralized system, called a 146 controller, can act to program the devices in the network to behave 147 in specific ways. A required element in an SDN architecture is a 148 component that plans how the network resources will be used and how 149 the devices will be programmed. It is possible to view this 150 component as performing specific computations to place traffic flows 151 within the network given knowledge of the availability of network 152 resources, how other forwarding devices are programmed, and the way 153 that other flows are routed. This is the function and purpose of a 154 PCE, and the way that a PCE integrates into a wider network control 155 system (including an SDN system) is presented in [RFC7491]. 157 In early PCE implementations, where the PCE was used to derive paths 158 for MPLS Label Switched Paths (LSPs), paths were requested by network 159 elements (known as Path Computation Clients (PCCs)), and the results 160 of the path computations were supplied to network elements using the 161 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 162 This protocol was later extended to allow a PCE to send unsolicited 163 requests to the network for LSP establishment [RFC8281]. 165 [RFC8283] introduces the architecture for PCE as a central controller 166 as an extension of the architecture described in [RFC4655] and 167 assumes the continued use of PCEP as the protocol used between PCE 168 and PCC. [RFC8283] further examines the motivations and 169 applicability for PCEP as a Southbound Interface (SBI), and 170 introduces the implications for the protocol. 171 [I-D.ietf-teas-pcecc-use-cases] describes the use cases for the PCECC 172 architecture. 174 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 175 procedures and PCEP protocol extensions for using the PCE as the 176 central controller for static LSPs, where LSPs can be provisioned as 177 explicit label instructions at each hop on the end-to-end path. 179 Segment Routing (SR) technology leverages the source routing and 180 tunneling paradigms. A source node can choose a path without relying 181 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 182 is specified as a set of "segments" advertised by link-state routing 183 protocols (IS-IS or OSPF). [RFC8402] provides an introduction to SR 184 architecture. The corresponding IS-IS and OSPF extensions are 185 specified in [RFC8667] and [RFC8665] , respectively. It relies on a 186 series of forwarding instructions being placed in the header of a 187 packet. The segment routing architecture supports operations that 188 can be used to steer packet flows in a network, thus providing a form 189 of traffic engineering. [RFC8664] specify the SR specific PCEP 190 extensions. 192 PCECC may further use PCEP protocol for SR SID (Segment Identifier) 193 distribution on the SR nodes with some benefits. 195 This document specifies the procedures and PCEP protocol extensions 196 when a PCE-based controller is also responsible for configuring the 197 forwarding actions on the routers (SR SID distribution in this case), 198 in addition to computing the paths for packet flows in a segment 199 routing network and telling the edge routers what instructions to 200 attach to packets as they enter the network. 202 1.1. Requirements Language 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 206 "OPTIONAL" in this document are to be interpreted as described in BCP 207 14 [RFC2119] [RFC8174] when, and only when, they appear in all 208 capitals, as shown here. 210 2. Terminology 212 Terminologies used in this document is same as described in the draft 213 [RFC8283] and [I-D.ietf-teas-pcecc-use-cases]. 215 3. PCECC SR 217 [RFC8664] specifies extensions to PCEP that allow a stateful PCE to 218 compute, update or initiate SR-TE paths. An ingress node of an SR-TE 219 path appends all outgoing packets with a list of MPLS labels (SIDs). 220 This is encoded in SR-ERO subobject, capable of carrying a label 221 (SID) as well as the identity of the node/adjacency label (SID). 223 The notion of segment and SID is defined in [RFC8402], which fits the 224 MPLS architecture [RFC3031] as the label which is managed by a local 225 allocation process of LSR (similarly to other MPLS signaling 226 protocols) [RFC8660]. The SR information such as node/adjacency 227 label (SID) is flooded via IGP as specified in [RFC8667] and 228 [RFC8665]. 230 As per [RFC8283], PCE as a central controller can allocate and 231 provision the node/prefix/adjacency label (SID) via PCEP. 233 Rest of the processing is similar to existing stateful PCE with SR 234 mechanism. 236 For the purpose of this document, it is assumed that label range to 237 be used by a PCE is set on both PCEP peers. Further, a global label 238 range is assumed to be set on all PCEP peers in the SR domain. This 239 document also allow a case where the label space is maintained by PCC 240 itself, and the labels are allocated by the PCC, in this case, the 241 PCE should request the allocation from PCC as described in 242 Section 5.5.1.6. 244 4. PCEP Requirements 246 Following key requirements for PCECC-SR should be considered when` 247 designing the PCECC based solution: 249 o PCEP speaker supporting this draft MUST have the capability to 250 advertise its PCECC-SR capability to its peers. 252 o PCEP speaker not supporting this draft MUST be able to reject 253 PCECC-SR related message with a reason code that indicates no 254 support for PCECC. 256 o PCEP procedures MUST provide a means to update (or cleanup) the 257 label- map entry to the PCC. 259 o PCEP procedures SHOULD provide a means to synchronize the SR 260 labels allocations between PCE to PCC in the PCEP messages. 262 o PCEP procedures MAY allow for PCC based label allocations. 264 5. Procedures for Using the PCE as the Central Controller (PCECC) in 265 Segment Routing 267 5.1. Stateful PCE Model 269 Active stateful PCE is described in [RFC8231]. PCE as a central 270 controller (PCECC) reuses existing Active stateful PCE mechanism as 271 much as possible to control the LSP. 273 5.2. New LSP Functions 275 Several new functions are required in PCEP to support PCECC as 276 described in [I-D.ietf-pce-pcep-extension-for-pce-controller]. This 277 document reuses the existing messages to support PCECC-SR. 279 The PCEP messages PCRpt, PCInitiate, PCUpd are used to send LSP 280 Reports, LSP setup and LSP update respectively. The extended 281 PCInitiate message described in 282 [I-D.ietf-pce-pcep-extension-for-pce-controller] is used to download 283 or cleanup central controller's instructions (CCIs) (SR SID in scope 284 of this document). The extended PCRpt message described in 285 [I-D.ietf-pce-pcep-extension-for-pce-controller] is also used to 286 report the CCIs (SR SIDs) from PCC to PCE. 288 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify an object 289 called CCI for the encoding of central controller's instructions. 290 This document extends the CCI by defining a new object-type for 291 segment routing. The PCEP messages are extended in this document to 292 handle the PCECC operations for SR. 294 5.3. PCECC Capability Advertisement 296 During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 297 advertise their support of PCECC extensions. A PCEP Speaker includes 298 the "PCECC Capability" sub-TLV, described in 299 [I-D.ietf-pce-pcep-extension-for-pce-controller]. 301 A new S-bit is added in PCECC-CAPABILITY sub-TLV to indicate support 302 for PCECC-SR. A PCC MUST set S-bit in PCECC-CAPABILITY sub-TLV and 303 include SR-PCE-CAPABILITY sub-TLV ([RFC8664]) in OPEN Object (inside 304 the the PATH-SETUP-TYPE-CAPABILITY TLV) to support the PCECC SR 305 extensions defined in this document. If S-bit is set in PCECC- 306 CAPABILITY sub-TLV and SR-PCE-CAPABILITY sub-TLV is not advertised in 307 OPEN Object, PCE SHOULD send a PCErr message with Error-Type=19 308 (Invalid Operation) and Error-value=TBD(SR capability was not 309 advertised) and terminate the session. 311 5.4. PCEP session IP address and TEDB Router ID 313 PCE may construct its TEDB by participating in the IGP ([RFC3630] and 314 [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An 315 alternative is offered by BGP-LS [RFC7752] and 316 [I-D.dhodylee-pce-pcep-ls]. 318 PCEP [RFC5440] speaker MAY use any IP address while creating a TCP 319 session. It is important to link the session IP address with the 320 Router ID in TEDB for successful PCECC operations. 322 During PCEP Initialization Phase, PCC SHOULD advertise the TE mapping 323 information. Thus a PCC includes the "Node Attributes TLV" 324 [I-D.dhodylee-pce-pcep-ls] with "IPv4/IPv6 Router-ID of Local Node", 325 in the OPEN Object for this purpose. [RFC7752] describes the usage 326 as auxiliary Router-IDs that the IGP might be using, e.g., for TE 327 purposes. If there are more than one auxiliary Router-ID of a given 328 type, then multiple TLVs are used to encode them. 330 If "IPv4/IPv6 Router-ID" TLV is not present, the TCP session IP 331 address is directly used for the mapping purpose. 333 5.5. LSP Operations 335 The PCEP messages pertaining to PCECC-SR MUST include PATH-SETUP-TYPE 336 TLV [RFC8408] with PST=TBD in the SRP object to clearly identify the 337 PCECC-SR LSP is intended. 339 5.5.1. PCECC Segment Routing (SR) 341 Segment Routing (SR) as described in [RFC8402] depends on "segments" 342 that are advertised by Interior Gateway Protocols (IGPs). The SR- 343 node allocates and advertises the SID (node, adj etc) and flood via 344 the IGP. This document proposes a new mechanism where PCE allocates 345 the SID (label/index/SID) centrally and uses PCEP to advertise the 346 SID. In some deployments PCE (and PCEP) are better suited than IGP 347 because of centralized nature of PCE and direct TCP based PCEP 348 session to the node. 350 5.5.1.1. PCECC SR Node/Prefix SID allocation 352 Each node (PCC) is allocated a node-SID by the PCECC. The PCECC 353 sends PCInitiate message to update the label map of each node to all 354 the nodes in the domain. The TE router ID is determined from the 355 TEDB or from "IPv4/IPv6 Router-ID" Sub-TLV 356 [I-D.dhodylee-pce-pcep-ls], in the OPEN Object Section 5.4. 358 It is RECOMMENDED that PCEP session with PCECC SR capability to use a 359 different session IP address during TCP session establishment than 360 the node Router ID in TEDB, to make sure that the PCEP session does 361 not get impacted by the SR Node/Prefix Label maps (Section 5.4). 363 If a node (PCC) receives a PCInitiate message with a CCI encoding a 364 SID, out of the range set aside for the SRGB, it MUST send a PCErr 365 message with Error-type=TBD (PCECC failure) and Error-value=TBD (SID 366 out of range) and MUST include the SRP object to specify the error is 367 for the corresponding label update via PCInitiate message. 369 On receiving the label map, each node (PCC) uses the local 370 information to determine the next-hop and download the label 371 forwarding instructions accordingly. The PCInitiate message in this 372 case MUST NOT have LSP object but uses the new FEC object defined in 373 this document. 375 +---------+ +-------+ 376 |PCC | | PCE | 377 |192.0.2.3| +-------+ 378 +------| | | 379 | PCC +---------+ | 380 | 192.0.2.2| | | 381 +------| | | | 382 |PCC +----------+ | | 383 |192.0.2.1| | | | 384 +---------+ | | | 385 | | | | 386 |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map 387 | | | CC-ID=X | update 388 |------- PCRpt,CC-ID=X --------------------------->| CCI 389 |Find | | | 390 |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map 391 |locally| | CC-ID=Y | update 392 | |----- PCRpt,CC-ID=Y -------------------->| CCI 393 | | | | 394 | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map 395 | | | CC-ID=Z | update 396 | | |---- PCRpt,CC-ID=Z -------------->| CCI 397 | | | | 399 The forwarding behavior and the end result is similar to IGP based 400 "Node-SID" in SR. Thus, from anywhere in the domain, it enforces the 401 ECMP-aware shortest-path forwarding of the packet towards the related 402 node. 404 PCE relies on the Node/Prefix Label cleanup using the same PCInitiate 405 message. 407 The above example Figure 1 depict FEC and PCEP speakers that uses 408 IPv4 address. Similarly IPv6 address (such as 2001:DB8::1) can be 409 used during PCEP session establishment as well in FEC object as 410 described in this specification. 412 In case where the label allocation are made by the PCC itself (see 413 Section 5.5.1.6), the PCE could still request an allocation to be 414 made by the PCC, and where the PCC would send a PCRpt with the 415 allocated label encoded in the CC-ID object as shown below - 416 +---------+ +-------+ 417 |PCC | | PCE | 418 |192.0.2.3| +-------+ 419 +------| | | 420 | PCC +---------+ | 421 | 192.0.2.2| | | 422 +------| | | | 423 |PCC +----------+ | | 424 |192.0.2.1| | | | 425 +---------+ | | | 426 | | | | 427 |<------- PCInitiate, FEC=192.0.2.1---------------- | Label Map 428 | | | CC-ID=X,C=1 | request 429 |------- PCRpt,CC-ID=X,Label ---------------------->| CCI 430 |Find | | | 431 |Nexthop|<------- PCInitiate, FEC=192.0.2.1-------- | Label Map 432 |locally| | CC-ID=Y,C=0,Label | update 433 | |----- PCRpt,CC-ID=Y -------------------->| CCI 434 | | | | 435 | | |<--- PCInitiate, FEC=192.0.2.1---- | Label Map 436 | | | CC-ID=Z,C=0,Label | update 437 | | |---- PCRpt,CC-ID=Z -------------->| CCI 438 | | | | 440 It should be noted that in this example, the request is made to the 441 node 192.0.2.1 with C bit set in the CCI object to indicate that the 442 allocation needs to be done by this PCC and it responds with the 443 allocated label/SID to the PCE. The PCE would further inform the 444 other PCCs in the network about the allocation without setting the C 445 bit. 447 5.5.1.2. PCECC SR Adjacency Label allocation 449 [RFC8664] extends PCEP to allow a stateful PCE to compute and 450 initiate SR-TE paths, as well as a PCC to request a path subject to 451 certain constraint(s) and optimization criteria in SR networks. 453 For PCECC SR, apart from node-SID, Adj-SID is used where each 454 adjacency is allocated an Adj-SID by the PCECC. The PCECC sends 455 PCInitiate message to update the label map of each Adj to the 456 corresponding nodes in the domain. Each node (PCC) download the 457 label forwarding instructions accordingly. Similar to SR Node/Prefix 458 Label allocation, the PCInitiate message in this case MUST NOT have 459 LSP object but uses the new FEC object defined in this document. 461 +---------+ +-------+ 462 |PCC | | PCE | 463 |192.0.2.3| +-------+ 464 +------| | | 465 | PCC +---------+ | 466 | 192.0.2.2| | | 467 +------| | | | 468 |PCC +----------+ | | 469 |192.0.2.1| | | | 470 +---------+ | | | 471 | | | | 472 |<------ PCInitiate, FEC=198.51.100.1 / --------- | Label Map 473 | | | 198.51.100.2 | update 474 | | | CC-ID=A | CCI 475 |------- PCRpt,CC-ID=A ------------------------->| 476 | | | | 477 | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map 478 | | | 198.51.100.1 | update 479 | | | CC-ID=B | CCI 480 | |----- PCRpt,CC-ID=B ----------------->| 481 | | | | 483 The forwarding behavior and the end result is similar to IGP based 484 "Adj-SID" in SR. 486 The Path Setup Type for segment routing MUST be set for PCECC SR = 487 TBD (see Section 7.2). All PCEP procedures and mechanism are similar 488 to [RFC8664]. 490 PCE relies on the Adj label cleanup using the same PCInitiate 491 message. 493 The above example Figure 3 depict FEC and PCEP speakers that uses 494 IPv4 address. Similarly IPv6 address (such as 2001:DB8::1, 495 2001:DB8::2) can be used during PCEP session establishment as well in 496 FEC object as described in this specification. 498 In case where the label allocation are made by the PCC itself (see 499 Section 5.5.1.6), the PCE could still request an allocation to be 500 made by the PCC, and where the PCC would send a PCRpt with the 501 allocated label encoded in the CC-ID object as shown below - 502 +---------+ +-------+ 503 |PCC | | PCE | 504 |192.0.2.3| +-------+ 505 +------| | | 506 | PCC +---------+ | 507 | 192.0.2.2| | | 508 +------| | | | 509 |PCC +----------+ | | 510 |192.0.2.1| | | | 511 +---------+ | | | 512 | | | | 513 |<------ PCInitiate, FEC=198.51.100.1------------ | Label Map 514 | | | 198.51.100.2 | request 515 | | | CC-ID=A,C=1 | CCI 516 |------- PCRpt,CC-ID=A,Label -------------------->| 517 | | | | 518 | |<----- PCInitiate, FEC=198.51.100.2---- | Label Map 519 | | | 198.51.100.1 | request 520 | | | CC-ID=B,C=1 | CCI 521 | |----- PCRpt,CC-ID=B,Label------------->| 522 | | | | 524 In this example the request is made to the node 192.0.2.1 with C bit 525 set in the CCI object to indicate that the allocation needs to be 526 done by this PCC for the adjacency (198.51.100.1 - 198.51.100.2) and 527 it responds with the allocated label/SID to the PCE. Similarly, 528 another request is made to the node 192.0.2.2 with C bit set in the 529 CCI object to indicate that the allocation needs to be done by this 530 PCC for the adjacency (198.51.100.2 - 198.51.100.1). 532 5.5.1.3. Redundant PCEs 534 [I-D.litkowski-pce-state-sync] describes synchronization mechanism 535 between the stateful PCEs. The SR SIDs allocated by a PCE MUST also 536 be synchronized among PCEs for PCECC SR state synchronization. Note 537 that the SR SIDs are independent to the PCECC-SR LSP, and remains 538 intact till any topology change. The redundant PCEs MUST have a 539 common view of all SR SIDs allocated in the domain. 541 5.5.1.4. Re Delegation and Cleanup 543 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the action 544 needed for CCIs for the Basic PCECC LSP on this terminated session. 545 Similarly actions should be applied for the SR SID as well. 547 5.5.1.5. Synchronization of Label Allocations 549 [I-D.ietf-pce-pcep-extension-for-pce-controller] describes the 550 synchronization of Central Controller's Instructions (CCI) via LSP 551 state synchronization as described in [RFC8231] and [RFC8232]. Same 552 procedures should be applied for SR SIDs as well. 554 5.5.1.6. PCC Based Allocations 556 The PCE can request the PCC to allocate the label/SID using the 557 PCInitiate message. The C flag in the CCI object is set to 1 to 558 indicate that the allocation needs to be done by the PCC. The PCC 559 would allocate the SID/Label/Index and would report to the PCE using 560 the PCRpt message. 562 If the value of the SID/Label/Index is 0 and the C flag is set, it 563 indicates that the PCE is requesting the allocation to be done by the 564 PCC. If the SID/Label/Index is 'n' and the C flag is set in the CCI 565 object, it indicates that the PCE requests a specific value 'n' for 566 the SID/Label/Index. If the allocation is successful, the PCC should 567 report via PCRpt message with the CCI object. Else, it MUST send a 568 PCErr message with Error-Type = TBD ("PCECC failure") and Error Value 569 = TBD ("Invalid CCI"). If the value of the the SID/Label/Index in 570 the CCI object is valid, but the PCC is unable to allocate it, it 571 MUST send a PCErr message with Error-Type = TBD ("PCECC failure") and 572 Error Value = TBD ("Unable to allocate the specified CCI"). 574 If the PCC wishes to withdrawn or modify the previously assigned 575 label/SID, it MUST send a PCRpt message without any SID/Label/Index 576 or with the SID/Label/Index containing the new value respectively in 577 the CCI object. The PCE would further trigger the removal of the 578 central controller instruction as per this document. 580 5.5.1.7. Binding SID 582 A PCE as a central controller can allocate and provision the 583 node/prefix/adjacency label (SID) via PCEP. One such SID is binding 584 SID as described in [I-D.ietf-pce-binding-label-sid], the PCECC 585 mechanism can also be used to allocate the binding SID as described 586 in this section. 588 A procedure for binding label/SID allocation is described in 589 [I-D.ietf-pce-pcep-extension-for-pce-controller] and is applicable 590 for all path setup types (including SR paths). 592 6. PCEP messages 594 As defined in [RFC5440], a PCEP message consists of a common header 595 followed by a variable-length body made of a set of objects that can 596 be either mandatory or optional. An object is said to be mandatory 597 in a PCEP message when the object must be included for the message to 598 be considered valid. For each PCEP message type, a set of rules is 599 defined that specify the set of objects that the message can carry. 600 An implementation MUST form the PCEP messages using the object 601 ordering specified in this document. 603 6.1. Central Control Instructions 605 6.1.1. The PCInitiate message 607 The PCInitiate Message defined in [RFC8281] and extended in 608 [I-D.ietf-pce-pcep-extension-for-pce-controller] is further extended 609 to support SR based central control instructions. 611 The format of the extended PCInitiate message is as follows: 613 ::= 614 615 Where: 616 is defined in [RFC5440] 618 ::= 619 [] 621 ::= 622 (| 623 | 624 ) 626 ::= 627 ( 628 )| 629 ( 630 ) 632 ::= 633 [] 635 Where: 636 and 637 are as per 638 [RFC8281]. 640 The LSP and SRP object is defined in [RFC8231]. 642 When PCInitiate message is used to distribute SR SIDs, the SRP, FEC 643 and CCI objects MUST be present. The error handling for missing SRP 644 or CCI object is as per 645 [I-D.ietf-pce-pcep-extension-for-pce-controller]. If the FEC object 646 is missing, the receiving PCC MUST send a PCErr message with Error- 647 type=6 (Mandatory Object missing) and Error-value=TBD (FEC object 648 missing). 650 To cleanup the SRP object must set the R (remove) bit and include the 651 FEC and the CCI object. 653 6.1.2. The PCRpt message 655 The PCRpt message can be used to report the SR instructions received 656 from the central controller (PCE) during the state synchronization 657 phase. 659 The format of the PCRpt message is as follows: 661 ::= 662 663 Where: 665 ::= [] 667 ::= (| 668 ) 670 ::= [] 671 672 674 ::= [] 675 ( 676 )| 677 ( 678 ) 680 ::= 681 [] 683 Where: 684 is as per [RFC8231] and the LSP and SRP object are 685 also defined in [RFC8231]. 687 When PCRpt message is used to report the label map allocations, the 688 FEC and CCI objects MUST be present. The error handling for CCI 689 object is as per [I-D.ietf-pce-pcep-extension-for-pce-controller]. 690 If the FEC object is missing, the receiving PCC MUST send a PCErr 691 message with Error-type=6 (Mandatory Object missing) and Error- 692 value=TBD (FEC object missing). 694 7. PCEP Objects 696 7.1. OPEN Object 698 7.1.1. PCECC Capability sub-TLV 700 [I-D.ietf-pce-pcep-extension-for-pce-controller] defined the PCECC- 701 CAPABILITY TLV. 703 A new S-bit is defined in PCECC-CAPABILITY sub-TLV for PCECC-SR: 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Type=TBD | Length=4 | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Flags |S| 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 S (PCECC-SR-CAPABILITY - 1 bit): If set to 1 by a PCEP speaker, it 714 indicates that the PCEP speaker is capable for PCECC-SR capability 715 and PCE would allocate node and Adj label on this session. 717 7.2. PATH-SETUP-TYPE TLV 719 The PATH-SETUP-TYPE TLV is defined in [RFC8408]. PST = TBD is used 720 when Path is setup via PCECC SR mode. 722 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD indicates that this 723 LSP was setup via a PCECC-SR based mechanism where either the SIDs 724 were allocated/instructed by PCE via PCECC mechanism. 726 7.3. CCI Object 728 The Central Control Instructions (CCI) Object is used by the PCE to 729 specify the forwarding instructions is defined in 730 [I-D.ietf-pce-pcep-extension-for-pce-controller]. This document 731 defines another object-type for SR purpose. 733 CCI Object-Type is TBD for SR as below - 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | CC-ID | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | MT-ID | Algorithm | Flags |B|P|G|C|N|E|V|L|O| 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 // SID/Label/Index (variable) // 743 +---------------------------------------------------------------+ 744 | | 745 // Optional TLV // 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 The field CC-ID is as described in 749 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Following new 750 fields are defined for CCI Object-Type TBD - 752 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 754 Algorithm: Single octet identifying the algorithm the SID is 755 associated with. See [RFC8665]. 757 Flags: is used to carry any additional information pertaining to the 758 CCI. The O bit was defined in 759 [I-D.ietf-pce-pcep-extension-for-pce-controller], this document 760 further defines following bits- 762 * L-Bit (Local/Global): If set, then the value/index carried by 763 the CCI object has local significance. If not set, then the 764 value/index carried by this object has global significance. 766 * V-Bit (Value/Index): If set, then the CCI carries an absolute 767 value. If not set, then the CCI carries an index. 769 * E-Bit (Explicit-Null): If set, any upstream neighbor of the 770 node that advertised the SID MUST replace the SID with the 771 Explicit-NULL label (0 for IPv4) before forwarding the packet. 773 * N-Bit (No-PHP): If set, then the penultimate hop MUST NOT pop 774 the SID before delivering packets to the node that advertised 775 the SID. 777 * C-Bit (PCC Allocation): If the bit is set to 1, it indicates 778 that the allocation needs to be done by the PCC for this 779 central controller instruction. A PCE set this bit to request 780 the PCC to make an allocation from its SR label/ID space. A 781 PCC would set this bit to indicate that it has allocated the 782 CC-ID and report it to the PCE. 784 * Following bits are applicable when the SID represents an Adj- 785 SID only, it MUST be ignored for others - 787 + G-Bit (Group): When set, the G-Flag indicates that the Adj- 788 SID refers to a group of adjacencies (and therefore MAY be 789 assigned to other adjacencies as well). 791 + P-Bit (Persistent): When set, the P-Flag indicates that the 792 Adj-SID is persistently allocated, i.e., the Adj-SID value 793 remains consistent across router restart and/or interface 794 flap. 796 + B-Bit (Backup): If set, the Adj-SID refers to an adjacency 797 that is eligible for protection (e.g., using IP Fast Reroute 798 or MPLS-FRR (MPLS-Fast Reroute) as described in Section 2.1 799 of [RFC8402]. 801 SID/Label/Index: According to the V and L flags, it contains either: 803 A 32-bit index defining the offset in the SID/Label space 804 advertised by this router. 806 A 24-bit label where the 20 rightmost bits are used for 807 encoding the label value. 809 7.4. FEC Object 811 The FEC Object is used to specify the FEC information and MAY be 812 carried within PCInitiate or PCRpt message. 814 FEC Object-Class is TBD. 816 FEC Object-Type is 1 'IPv4 Node ID'. 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | IPv4 Node ID | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 FEC Object-Type is 2 'IPv6 Node ID'. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | | 830 // IPv6 Node ID (16 bytes) // 831 | | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 FEC Object-Type is 3 'IPv4 Adjacency'. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Local IPv4 address | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Remote IPv4 address | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 FEC Object-Type is 4 'IPv6 Adjacency'. 846 0 1 2 3 847 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 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | | 850 // Local IPv6 address (16 bytes) // 851 | | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | | 854 // Remote IPv6 address (16 bytes) // 855 | | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 FEC Object-Type is 5 'Unnumbered Adjacency with IPv4 NodeIDs'. 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Local Node-ID | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Local Interface ID | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Remote Node-ID | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Remote Interface ID | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 FEC Object-Type is 6 'Linklocal IPv6 Adjacency'. 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 // Local IPv6 address (16 octets) // 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Local Interface ID | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 // Remote IPv6 address (16 octets) // 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Remote Interface ID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 The FEC objects are as follows: 888 IPv4 Node ID: where IPv4 Node ID is specified as an IPv4 address of 889 the Node. FEC Object-type is 1, and the Object-Length is 4 in this 890 case. 892 IPv6 Node ID: where IPv6 Node ID is specified as an IPv6 address of 893 the Node. FEC Object-type is 2, and the Object-Length is 16 in this 894 case. 896 IPv4 Adjacency: where Local and Remote IPv4 address is specified as 897 pair of IPv4 address of the adjacency. FEC Object-type is 3, and the 898 Object-Length is 8 in this case. 900 IPv6 Adjacency: where Local and Remote IPv6 address is specified as 901 pair of IPv6 address of the adjacency. FEC Object-type is 4, and the 902 Object-Length is 32 in this case. 904 Unnumbered Adjacency with IPv4 NodeID: where a pair of Node ID / 905 Interface ID tuples is used. FEC Object-type is 5, and the Object- 906 Length is 16 in this case. 908 Linklocal IPv6 Adjacency: where a pair of (global IPv6 address, 909 interface ID) tuples is used. FEC object-type is 6, and the Object- 910 Length is 40 in this case. 912 8. Implementation Status 914 [Note to the RFC Editor - remove this section before publication, as 915 well as remove the reference to RFC 7942.] 917 This section records the status of known implementations of the 918 protocol defined by this specification at the time of posting of this 919 Internet-Draft, and is based on a proposal described in [RFC7942]. 920 The description of implementations in this section is intended to 921 assist the IETF in its decision processes in progressing drafts to 922 RFCs. Please note that the listing of any individual implementation 923 here does not imply endorsement by the IETF. Furthermore, no effort 924 has been spent to verify the information presented here that was 925 supplied by IETF contributors. This is not intended as, and must not 926 be construed to be, a catalog of available implementations or their 927 features. Readers are advised to note that other implementations may 928 exist. 930 According to [RFC7942], "this will allow reviewers and working groups 931 to assign due consideration to documents that have the benefit of 932 running code, which may serve as evidence of valuable experimentation 933 and feedback that have made the implemented protocols more mature. 934 It is up to the individual working groups to use this information as 935 they see fit". 937 8.1. Huawei's Proof of Concept based on ONOS 939 The PCE function was developed in the ONOS open source platform. 940 This extension was implemented on a private version as a proof of 941 concept for PCECC. 943 o Organization: Huawei 945 o Implementation: Huawei's PoC based on ONOS 947 o Description: PCEP as a southbound plugin was added to ONOS. To 948 support PCECC-SR, an earlier version of this I-D was implemented. 949 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 951 o Maturity Level: Prototype 953 o Coverage: Partial 955 o Contact: satishk@huawei.com 957 9. Security Considerations 959 The security considerations described in 960 [I-D.ietf-pce-pcep-extension-for-pce-controller] apply to the 961 extensions described in this document. 963 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 964 be activated on authenticated and encrypted sessions across PCEs and 965 PCCs belonging to the same administrative authority, using Transport 966 Layer Security (TLS) [RFC8253] as per the recommendations and best 967 current practices in [RFC7525] (unless explicitly set aside in 968 [RFC8253]). 970 10. Manageability Considerations 972 10.1. Control of Function and Policy 974 A PCE or PCC implementation SHOULD allow to configure to enable/ 975 disable PCECC SR capability as a global configuration. 977 10.2. Information and Data Models 979 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 980 PCECC SR capability status. 982 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 983 enable/disable PCECC SR capability. 985 10.3. Liveness Detection and Monitoring 987 Mechanisms defined in this document do not imply any new liveness 988 detection and monitoring requirements in addition to those already 989 listed in [RFC5440]. 991 10.4. Verify Correct Operations 993 Mechanisms defined in this document do not imply any new operation 994 verification requirements in addition to those already listed in 995 [RFC5440] and [RFC8231]. 997 10.5. Requirements On Other Protocols 999 PCEP extensions defined in this document do not put new requirements 1000 on other protocols. 1002 10.6. Impact On Network Operations 1004 PCEP implementation SHOULD allow a limit to be placed on the rate of 1005 PCLabelUpd messages sent by PCE and processed by PCC. It SHOULD also 1006 allow sending a notification when a rate threshold is reached. 1008 11. IANA Considerations 1010 11.1. PCECC-CAPABILITY sub-TLV 1012 [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC- 1013 CAPABILITY sub-TLV and requests that IANA creates a registry to 1014 manage the value of the PCECC-CAPABILITY sub-TLV's Flag field. New 1015 values are to be assigned by Standards Action [RFC8126]. Each bit 1016 should be tracked with the following qualities: 1018 o Bit number (counting from bit 0 as the most significant bit) 1020 o Capability description 1022 o Defining RFC 1024 IANA is requested to allocate a new bit in the PCECC-CAPABILITY sub- 1025 TLV Flag Field registry, as follows: 1027 Bit Description Reference 1028 31 S((PCECC-SR-CAPABILITY)) This document 1030 11.2. New Path Setup Type Registry 1032 [RFC8408] created a sub-registry within the "Path Computation Element 1033 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1034 IANA is requested to allocate a new code point within this registry, 1035 as follows: 1037 Value Description Reference 1038 TBD Traffic engineering path is This document 1039 setup using PCECC-SR mode 1041 11.3. PCEP Object 1043 IANA is requested to allocate new code-point for the new FEC object 1044 in "PCEP Objects" sub-registry as follows: 1046 Object-Class Value Name Reference 1047 TBD FEC This document 1048 Object-Type : 1 IPv4 Node ID 1049 Object-Type : 2 IPv6 Node ID 1050 Object-Type : 3 IPv4 Adjacency 1051 Object-Type : 4 IPv6 Adjacency 1052 Object-Type : 5 Unnumbered Adjacency 1053 with IPv4 NodeID 1054 Object-Type : 6 Linklocal IPv6 Adjacency 1056 11.4. PCEP-Error Object 1058 IANA is requested to allocate new error types and error values within 1059 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1060 PCEP Numbers registry for the following errors: 1062 Error-Type Meaning 1063 ---------- ------- 1064 6 Mandatory Object missing. 1066 Error-value = TBD : FEC object missing 1067 19 Invalid operation. 1069 Error-value = TBD : SR capability was 1070 not advertised 1072 11.5. CCI Object Flag Field for SR 1074 IANA is requested to create a new sub-registry to manage the Flag 1075 field of the CCI Object-Type=TBD for SR called "CCI Object Flag Field 1076 for SR". New values are to be assigned by Standards Action 1077 [RFC8126]. Each bit should be tracked with the following qualities: 1079 o Bit number (counting from bit 0 as the most significant bit) 1080 o Capability description 1081 o Defining RFC 1083 Following bits are defined for the CCI Object flag field for SR in 1084 this document as follows: 1086 Bit Description Reference 1087 0-7 Unassigned This document 1088 8 B-Bit - Backup This document 1089 9 P-Bit - Persistent This document 1090 10 G-Bit - Group This document 1091 11 C-Bit - PCC Allocation This document 1092 12 N-Bit - No-PHP This document 1093 13 E-Bit - Explicit-Null This document 1094 14 V-Bit - Value/Index This document 1095 15 L-Bit - Local/Global This document 1097 12. Acknowledgments 1099 We would like to thank Robert Tao, Changjing Yan, Tieying Huang and 1100 Avantika for their useful comments and suggestions. 1102 13. References 1104 13.1. Normative References 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1112 (TE) Extensions to OSPF Version 2", RFC 3630, 1113 DOI 10.17487/RFC3630, September 2003, 1114 . 1116 [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1117 Support of Generalized Multi-Protocol Label Switching 1118 (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, 1119 . 1121 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1122 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1123 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1124 . 1126 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1127 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1128 2008, . 1130 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 1131 in Support of Generalized Multi-Protocol Label Switching 1132 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 1133 . 1135 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1136 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1137 DOI 10.17487/RFC5440, March 2009, 1138 . 1140 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1141 Hardwick, "Path Computation Element Communication Protocol 1142 (PCEP) Management Information Base (MIB) Module", 1143 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1144 . 1146 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1147 "Recommendations for Secure Use of Transport Layer 1148 Security (TLS) and Datagram Transport Layer Security 1149 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1150 2015, . 1152 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1153 S. Ray, "North-Bound Distribution of Link-State and 1154 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1155 DOI 10.17487/RFC7752, March 2016, 1156 . 1158 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1159 Code: The Implementation Status Section", BCP 205, 1160 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1161 . 1163 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1164 Writing an IANA Considerations Section in RFCs", BCP 26, 1165 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1166 . 1168 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1169 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1170 May 2017, . 1172 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1173 Computation Element Communication Protocol (PCEP) 1174 Extensions for Stateful PCE", RFC 8231, 1175 DOI 10.17487/RFC8231, September 2017, 1176 . 1178 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1179 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1180 Path Computation Element Communication Protocol (PCEP)", 1181 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1182 . 1184 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1185 Computation Element Communication Protocol (PCEP) 1186 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1187 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1188 . 1190 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1191 Hardwick, "Conveying Path Setup Type in PCE Communication 1192 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1193 July 2018, . 1195 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1196 and J. Hardwick, "Path Computation Element Communication 1197 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1198 DOI 10.17487/RFC8664, December 2019, 1199 . 1201 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1202 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 1203 and Protocol Extensions for Using PCE as a Central 1204 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1205 extension-for-pce-controller-03 (work in progress), 1206 November 2019. 1208 13.2. Informative References 1210 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1211 Label Switching Architecture", RFC 3031, 1212 DOI 10.17487/RFC3031, January 2001, 1213 . 1215 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1216 Element (PCE)-Based Architecture", RFC 4655, 1217 DOI 10.17487/RFC4655, August 2006, 1218 . 1220 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1221 Margaria, "Requirements for GMPLS Applications of PCE", 1222 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1223 . 1225 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1226 Computation Element Architecture", RFC 7399, 1227 DOI 10.17487/RFC7399, October 2014, 1228 . 1230 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1231 Application-Based Network Operations", RFC 7491, 1232 DOI 10.17487/RFC7491, March 2015, 1233 . 1235 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1236 and D. Dhody, "Optimizations of Label Switched Path State 1237 Synchronization Procedures for a Stateful PCE", RFC 8232, 1238 DOI 10.17487/RFC8232, September 2017, 1239 . 1241 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1242 Architecture for Use of PCE and the PCE Communication 1243 Protocol (PCEP) in a Network with Central Control", 1244 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1245 . 1247 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1248 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1249 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1250 July 2018, . 1252 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1253 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1254 Routing with the MPLS Data Plane", RFC 8660, 1255 DOI 10.17487/RFC8660, December 2019, 1256 . 1258 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1259 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1260 Extensions for Segment Routing", RFC 8665, 1261 DOI 10.17487/RFC8665, December 2019, 1262 . 1264 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1265 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1266 Extensions for Segment Routing", RFC 8667, 1267 DOI 10.17487/RFC8667, December 2019, 1268 . 1270 [I-D.ietf-teas-pcecc-use-cases] 1271 Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang, 1272 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1273 Gulida, "The Use Cases for Path Computation Element (PCE) 1274 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1275 use-cases-05 (work in progress), March 2020. 1277 [I-D.ietf-pce-pcep-yang] 1278 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1279 YANG Data Model for Path Computation Element 1280 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1281 yang-13 (work in progress), October 2019. 1283 [I-D.ietf-pce-binding-label-sid] 1284 Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., 1285 Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID 1286 in PCE-based Networks.", draft-ietf-pce-binding-label- 1287 sid-01 (work in progress), November 2019. 1289 [I-D.litkowski-pce-state-sync] 1290 Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter 1291 Stateful Path Computation Element (PCE) Communication 1292 Procedures.", draft-litkowski-pce-state-sync-07 (work in 1293 progress), January 2020. 1295 [I-D.dhodylee-pce-pcep-ls] 1296 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 1297 Distribution of Link-State and TE Information.", draft- 1298 dhodylee-pce-pcep-ls-14 (work in progress), October 2019. 1300 Appendix A. Examples 1302 [Editor's Note: Add examples to show how the SID allocation are being 1303 done for LAN Adj-SID in a future revision] 1305 Appendix B. Contributor Addresses 1307 Dhruv Dhody 1308 Huawei Technologies 1309 Divyashree Techno Park, Whitefield 1310 Bangalore, Karnataka 560066 1311 India 1313 EMail: dhruv.ietf@gmail.com 1315 Satish Karunanithi 1316 Huawei Technologies 1317 Divyashree Techno Park, Whitefield 1318 Bangalore, Karnataka 560066 1319 India 1321 EMail: satishk@huawei.com 1323 Adrian Farrel 1324 Juniper Networks, Inc 1325 UK 1327 EMail: adrian@olddog.co.uk 1329 Xuesong Geng 1330 Huawei Technologies 1331 China 1333 Email: gengxuesong@huawei.com 1335 Udayasree Palle 1337 EMail: udayasreereddy@gmail.com 1339 Katherine Zhao 1340 Huawei Technologies 1341 2330 Central Expressway 1342 Santa Clara, CA 95050 1343 USA 1345 EMail: katherine.zhao@huawei.com 1347 Boris Zhang 1348 Telus Ltd. 1349 Toronto 1350 Canada 1352 EMail: boris.zhang@telus.com 1354 Alex Tokar 1355 Cisco Systems 1356 Slovak Republic 1358 EMail: atokar@cisco.com 1360 Authors' Addresses 1362 Quintin Zhao 1363 Huawei Technologies 1364 125 Nagog Technology Park 1365 Acton, MA 01719 1366 USA 1368 EMail: quintinzhao@gmail.com 1370 Zhenbin Li 1371 Huawei Technologies 1372 Huawei Bld., No.156 Beiqing Rd. 1373 Beijing 100095 1374 China 1376 EMail: lizhenbin@huawei.com 1378 Mahendra Singh Negi 1379 Huawei Technologies 1380 Divyashree Techno Park, Whitefield 1381 Bangalore, Karnataka 560066 1382 India 1384 EMail: mahendrasingh@huawei.com 1385 Shuping Peng 1386 Huawei Technologies 1387 Huawei Bld., No.156 Beiqing Rd. 1388 Beijing 100095 1389 China 1391 EMail: pengshuping@huawei.com 1393 Chao Zhou 1394 Cisco Systems 1396 EMail: choa.zhou@cisco.com