idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-10.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 (January 22, 2021) is 1189 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 informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-13) exists of draft-ietf-teas-pcecc-use-cases-06 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-05 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: July 26, 2021 M. Negi 6 RtBrick Inc 7 Q. Zhao 8 Etheric Networks 9 C. Zhou 10 HPE 11 January 22, 2021 13 PCEP Procedures and Protocol Extensions for Using PCE as a Central 14 Controller (PCECC) of LSPs 15 draft-ietf-pce-pcep-extension-for-pce-controller-10 17 Abstract 19 The Path Computation Element (PCE) is a core component of Software- 20 Defined Networking (SDN) systems. It can compute optimal paths for 21 traffic across a network and can also update the paths to reflect 22 changes in the network or traffic demands. 24 PCE was developed to derive paths for MPLS Label Switched Paths 25 (LSPs), which are supplied to the head end of the LSP using the Path 26 Computation Element Communication Protocol (PCEP). But SDN has a 27 broader applicability than signaled MPLS and GMPLS traffic-engineered 28 (TE) networks, and the PCE may be used to determine paths in a range 29 of use cases. PCEP has been proposed as a control protocol for use 30 in these environments to allow the PCE to be fully enabled as a 31 central controller. 33 A PCE-based Central Controller (PCECC) can simplify the processing of 34 a distributed control plane by blending it with elements of SDN and 35 without necessarily completely replacing it. Thus, the LSP can be 36 calculated/set up/initiated and the label forwarding entries can also 37 be downloaded through a centralized PCE server to each network device 38 along the path, while leveraging the existing PCE technologies as 39 much as possible. 41 This document specifies the procedures and PCEP extensions for using 42 the PCE as the central controller. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on July 26, 2021. 61 Copyright Notice 63 Copyright (c) 2021 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 80 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 82 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 83 5. Procedures for Using the PCE as a Central Controller (PCECC) 6 84 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 85 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 86 5.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 7 87 5.4. PCECC Capability Advertisement . . . . . . . . . . . . . 7 88 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9 89 5.5.1. PCE-Initiated PCECC LSP . . . . . . . . . . . . . . . 9 90 5.5.2. PCC-Initiated PCECC LSP . . . . . . . . . . . . . . . 13 91 5.5.3. Central Controller Instructions . . . . . . . . . . . 15 92 5.5.3.1. Label Download CCI . . . . . . . . . . . . . . . 16 93 5.5.3.2. Label Clean up CCI . . . . . . . . . . . . . . . 16 94 5.5.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 17 95 5.5.5. Re-Delegation and Clean up . . . . . . . . . . . . . 20 96 5.5.6. Synchronization of Central Controllers Instructions . 20 97 5.5.7. PCECC LSP State Report . . . . . . . . . . . . . . . 21 98 5.5.8. PCC-Based Allocations . . . . . . . . . . . . . . . . 21 99 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 21 100 6.1. The PCInitiate Message . . . . . . . . . . . . . . . . . 22 101 6.2. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23 102 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 24 103 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 24 104 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 25 105 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 25 106 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 26 107 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 27 108 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 28 109 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 29 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 111 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 29 112 10. Manageability Considerations . . . . . . . . . . . . . . . . 30 113 10.1. Control of Function and Policy . . . . . . . . . . . . . 30 114 10.2. Information and Data Models . . . . . . . . . . . . . . 30 115 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 30 116 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 30 117 10.5. Requirements On Other Protocols . . . . . . . . . . . . 31 118 10.6. Impact On Network Operations . . . . . . . . . . . . . . 31 119 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 120 11.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 31 121 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 31 122 11.3. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 31 123 11.4. Path Setup Type Registry . . . . . . . . . . . . . . . . 32 124 11.5. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 32 125 11.6. CCI Object Flag Field . . . . . . . . . . . . . . . . . 32 126 11.7. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 33 127 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 129 13.1. Normative References . . . . . . . . . . . . . . . . . . 34 130 13.2. Informative References . . . . . . . . . . . . . . . . . 35 131 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 38 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 134 1. Introduction 136 The Path Computation Element (PCE) [RFC4655] was developed to offload 137 the path computation function from routers in an MPLS traffic- 138 engineered network. Since then, the role and function of the PCE has 139 grown to cover a number of other uses (such as GMPLS [RFC7025]) and 140 to allow 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 A PCE-based Central Controller (PCECC) can simplify the processing of 175 a distributed control plane by blending it with elements of SDN and 176 without necessarily completely replacing it. Thus, the LSP can be 177 calculated/setup/initiated and the label forwarding entries can also 178 be downloaded through a centralized PCE server to each network 179 devices along the path while leveraging the existing PCE technologies 180 as much as possible. 182 This document specifies the procedures and PCEP extensions for using 183 the PCE as the central controller for static LSPs, where LSPs can be 184 provisioned as explicit label instructions at each hop on the end-to- 185 end path. Each router along the path must be told what label- 186 forwarding instructions to program and what resources to reserve. 187 The PCE-based controller keeps a view of the network and determines 188 the paths of the end-to-end LSPs, and the controller uses PCEP to 189 communicate with each router along the path of the end-to-end LSP. 191 While this document is focused on the procedures for the static LSPs 192 (referred to as basic PCECC mode in Section 3), the mechanisms and 193 protocol encodings are specified in such a way that extensions for 194 other use cases are easy to achieve. For example, the extensions for 195 PCECC for Segment Routing (SR) are specified in 196 [I-D.zhao-pce-pcep-extension-pce-controller-sr] and 197 [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 199 1.1. Requirements Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in BCP 204 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 2. Terminology 209 The terminology used in this document is the same as that described 210 in the draft [RFC8283]. 212 3. Basic PCECC Mode 214 In this mode, LSPs are provisioned as explicit label instructions at 215 each hop on the end-to-end path. Each router along the path must be 216 told what label forwarding instructions to program and what resources 217 to reserve. The controller uses PCEP to communicate with each router 218 along the path of the end-to-end LSP. 220 Note that the PCE-based controller will take responsibility for 221 managing some part of the MPLS label space for each of the routers 222 that it controls, and may take wider responsibility for partitioning 223 the label space for each router and allocating different parts for 224 different uses. This is also described in section 3.1.2. of 225 [RFC8283]. For the purpose of this document, it is assumed that the 226 label range to be used by a PCE is known and set on both PCEP peers. 227 A future extension could add the capability to advertise the range 228 via possible PCEP extensions as well (see 229 [I-D.li-pce-controlled-id-space]). The rest of the processing is 230 similar to the existing stateful PCE mechanism. 232 This document also allows a case where the label space is maintained 233 by the PCC itself, and the labels are allocated by the PCC, in this 234 case, the PCE should request the allocation from PCC as described in 235 Section 5.5.8. 237 4. PCEP Requirements 239 The following key requirements should be considered when designing 240 the PCECC-based solution: 242 1. A PCEP speaker supporting this draft needs to have the capability 243 to advertise its PCECC capability to its peers. 245 2. A PCEP speaker need means to identify PCECC-based LSP in the PCEP 246 messages. 248 3. PCEP procedures need to allow for PCC-based label allocations. 250 4. PCEP procedures need to provide a mean to update (or clean up) 251 the label-download entry to the PCC. 253 5. PCEP procedures need to provide a mean to synchronize the labels 254 between the PCE and the PCC via PCEP messages. 256 5. Procedures for Using the PCE as a Central Controller (PCECC) 258 5.1. Stateful PCE Model 260 Active stateful PCE is described in [RFC8231]. PCE as a central 261 controller (PCECC) reuses the existing active stateful PCE mechanism 262 as much as possible to control LSPs. 264 5.2. New LSP Functions 266 Several new functions are required in PCEP to support PCECC. This 267 document extends the existing messages to support the new functions 268 required by PCECC: 270 (PCInitiate): a PCEP message described in [RFC8281]. PCInitiate 271 message is used to set up PCE-Initiated LSP based on PCECC 272 mechanism. It is also extended for Central Controller 273 Instructions (CCI) (download or clean up the Label forwarding 274 instructions in the context of this document) on all nodes along 275 the path. 277 (PCRpt): a PCEP message described in [RFC8231]. PCRpt message is 278 used to send PCECC LSP Reports. It is also extended to report the 279 set of Central Controller Instructions (CCI) (label forwarding 280 instructions in the context of this document) received from the 281 PCE. See Section 5.5.6 for more details. 283 (PCUpd): a PCEP message described in [RFC8231]. PCUpd message is 284 used to send PCECC LSP Update. 286 The new functions defined in this document are mapped onto the PCEP 287 messages as shown in Table 1. 289 Function Message 290 PCECC Capability advertisement Open 291 Label entry Add PCInitiate 292 Label entry Clean up PCInitiate 293 PCECC Initiated LSP PCInitiate 294 PCECC LSP Update PCUpd 295 PCECC LSP State Report PCRpt 296 PCECC LSP Delegation PCRpt 297 PCECC Label Report PCRpt 299 Table 1: Functions mapped to the PCEP messages 301 5.3. New PCEP Object 303 This document defines a new PCEP object called CCI (Section 7.3) to 304 specify the central controller instructions. In the scope of this 305 document, this is limited to Label forwarding instructions. Future 306 documents can create new CCI object-types for other types of central 307 controller instructions. The CC-ID is the unique identifier for the 308 central controller instructions in PCEP. The PCEP messages are 309 extended in this document to handle the PCECC operations. 311 5.4. PCECC Capability Advertisement 313 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 314 advertise their support of and willingness to use PCEP extensions for 315 PCECC using these elements in the OPEN message: 317 o A new Path Setup Type (PST) in the PATH-SETUP-TYPE-CAPABILITY TLV 318 to indicate support for PCEP extensions for PCECC - TBD1 (Path is 319 set up via PCECC mode) 321 o A new PCECC-CAPABILITY sub-TLV with the L bit set to 1 inside the 322 PATH-SETUP-TYPE-CAPABILITY TLV to indicate a willingness to use 323 PCEP extensions for PCECC based central controller instructions 324 for label download 326 o The STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with the I flag set 327 [RFC8281]) 329 The new Path Setup Type is to be listed in the PATH-SETUP-TYPE- 330 CAPABILITY TLV by all PCEP speakers which support the PCEP extensions 331 for PCECC in this document. 333 The new PCECC-CAPABILITY sub-TLV is included in PATH-SETUP-TYPE- 334 CAPABILITY TLV in the OPEN object to indicate a willingness to use 335 the PCEP extensions for PCECC during the established PCEP session. 336 Using the L bit in this TLV, the PCE shows the intention to function 337 as a PCECC server, and the PCC shows a willingness to act as a PCECC 338 client for label download instructions (see Section 7.1.1). 340 If the PCECC-CAPABILITY sub-TLV is advertised and the STATEFUL-PCE- 341 CAPABILITY TLV is not advertised, or is advertised without the I flag 342 set, in the OPEN Object, the receiver MUST: 344 o Send a PCErr message with Error-Type=19 (Invalid Operation) and 345 Error-value=TBD4 (stateful PCE capability was not advertised) 347 o Terminate the session 349 If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with 350 the PCECC Path Setup Type but without the PCECC-CAPABILITY sub-TLV, 351 it MUST: 353 o Send a PCErr message with Error-Type 10 (Reception of an invalid 354 object) and Error-Value TBD2 (Missing PCECC-CAPABILITY sub-TLV) 356 o Terminate the PCEP session 358 The PCECC-CAPABILITY sub-TLV SHOULD NOT be used without the 359 corresponding Path Setup Type being listed in the PATH-SETUP-TYPE- 360 CAPABILITY TLV. If it is present without the corresponding Path 361 Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be 362 ignored. 364 If one or both speakers (PCE and PCC) have not indicated support and 365 willingness to use the PCEP extensions for PCECC, the PCEP extensions 366 for PCECC MUST NOT be used. If a PCECC operation is attempted when 367 both speakers have not agreed in the OPEN messages, the receiver of 368 the message MUST: 370 o Send a PCErr message with Error-Type=19 (Invalid Operation) and 371 Error-Value=TBD3 (Attempted PCECC operations when PCECC capability 372 was not advertised) 374 o Terminate the PCEP session 376 A legacy PCEP speaker (that does not recognize the PCECC Capability 377 sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and 378 [RFC5440]. As per [RFC8408], the legacy PCEP speaker (that does not 379 support PST), it will: 381 o Send a PCErr message with Error-Type = 21 (Invalid traffic 382 engineering path setup type) and Error-value = 1 (Unsupported path 383 setup type) 385 o Terminate the PCEP session 387 5.5. LSP Operations 389 The PCEP messages pertaining to a PCECC MUST include PATH-SETUP-TYPE 390 TLV [RFC8408] in the SRP (Stateful PCE Request Parameters) object 391 [RFC8231] with PST set to TBD1 to clearly identify that PCECC LSP is 392 intended. 394 5.5.1. PCE-Initiated PCECC LSP 396 The LSP Instantiation operation is defined in [RFC8281]. In order to 397 set up a PCE-Initiated LSP based on the PCECC mechanism, a PCE sends 398 PCInitiate message with PST set to TBD1 for PCECC (see Section 7.2) 399 to the ingress PCC. 401 The label forwarding instructions (see Section 5.5.3) from PCECC are 402 sent after the initial PCInitiate and PCRpt message exchange with the 403 ingress PCC as per [RFC8281] (see Figure 1). This is done so that 404 the PLSP-ID and other LSP identifiers can be obtained from the 405 ingress and can be included in the label forwarding instruction in 406 the next set of PCInitiate messages along the path as described 407 below. 409 An LSP-IDENTIFIER TLV MUST be included for PCECC LSPs, the tuple 410 uniquely identifies the LSP in the network. The LSP object is 411 included in the central controller instructions (label download 412 Section 7.3) to identify the PCECC LSP for this instruction. The 413 PLSP-ID is the original identifier used by the ingress PCC, so a 414 transit/egress LSR could have multiple central controller 415 instructions that have the same PLSP-ID. The PLSP-ID in combination 416 with the source (in LSP-IDENTIFIER TLV) MUST be unique. The PLSP-ID 417 is included for maintainability reasons to ease debugging. As per 418 [RFC8281], the LSP object could also include the SPEAKER-ENTITY-ID 419 TLV to identify the PCE that initiated these instructions. Also, the 420 CC-ID is unique in each PCEP session as described in Section 7.3. 422 The ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C 423 (Create) flag (see [RFC8281]) in the LSP object of the PCRpt message 424 to the PCE in the initial exchange. The PCC responds with a PCRpt 425 message with the status set to "GOING-UP" and carrying the assigned 426 PLSP-ID (see Figure 1). When the PCE receives this PCRpt message 427 with the PLSP-ID, it assigns labels along the path; and sets up the 428 path by sending a PCInitiate message to each node along the path of 429 the LSP as per the PCECC technique. The CC-ID uniquely identifies 430 the central controller instruction within a PCEP session. Each PCC 431 further responds with the PCRpt messages including the central 432 controller instruction (CCI) and the LSP objects. The PCC responds 433 with a PCRpt message to acknowledge the central controller 434 instruction. 436 The ingress node would receive one CCI object with O bit (out-label) 437 set. The transit node(s) would receive two CCI objects with the in- 438 label CCI without an O bit set and the out-label CCI with O bit set. 439 The egress node would receive one CCI object without O bit set (see 440 Figure 1). A node can determine its role based on the setting of the 441 O bit in the CCI object(s) and the LSP-IDENTIFIER TLV in the LSP 442 object. 444 The LSP deletion operation for PCE-Initiated PCECC LSP is the same as 445 defined in [RFC8281]. The PCE should further perform Label entry 446 clean up operation as described in Section 5.5.3.2 for the 447 corresponding LSP. 449 The PCE-Initiated PCECC LSP setup sequence is shown in Figure 1. 451 +-------+ +-------+ 452 |PCC | | PCE | 453 |ingress| +-------+ 454 +------| | | 455 | PCC +-------+ | 456 | transit| | | 457 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 458 |PCC +--------+ | | Initiate 459 |egress | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| PCECC LSP 460 +--------+ | | (GOING-UP) | 461 | | | | 462 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 463 | | | | download 464 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 465 | | | | 466 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2-----| Label 467 | | | | download 468 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=2--------->| CCI 469 | | | | 470 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 471 | | | | download 472 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 473 | | | | 474 | | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC LSP 475 | | | (UP) | Update 476 | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| 477 | | | (UP) | 479 Figure 1: PCE-Initiated PCECC LSP 481 Once the label operations are completed, the PCE SHOULD send a PCUpd 482 message to the ingress PCC. The PCUpd message is as per [RFC8231]. 484 The PCECC LSPs are considered to be 'up' by default (on receipt of 485 PCUpd message from PCE). The ingress MAY further choose to deploy a 486 data plane check mechanism and report the status back to the PCE via 487 a PCRpt message to make sure that the correct label instructions are 488 made along the path of the PCECC LSP (and it is ready to carry 489 traffic). 491 In the case where the label allocations are made by the PCC itself 492 (see Section 5.5.8), the PCE could request an allocation to be made 493 by the PCC, and then the PCC would send a PCRpt with the allocated 494 label encoded in the CC-ID object as shown in Figure 2 in the 495 configuration sequence from the egress towards the ingress along the 496 path. 498 +-------+ +-------+ 499 |PCC | | PCE | 500 |ingress| +-------+ 501 +------| | | 502 | PCC +-------+ | 503 | transit| | | 504 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,D=1--| PCECC LSP 505 |PCC +--------+ | | Initiate 506 |egress | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| PCECC LSP 507 +--------+ | | (GOING-UP) | 508 | | | | 509 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 510 | | | C=1 | download 511 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 512 | | | Label=L1 | 513 | |<------PCInitiate,PLSP-ID=2,----------------| Labels 514 | | | CC-ID=Y1,C=1 | download 515 | | | CC-ID=Y2,C=0,L1 | CCI 516 | |-------PCRpt,PLSP-ID=2--------------------->| 517 | | | CC-ID=Y1,Label=L2 | 518 | | | CC-ID=Y2 | 519 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 520 | | | C=0,L2 | download 521 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 522 | | | | 523 | | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC LSP 524 | | | (UP) | Update 526 - The O bit is set as before (and thus not included) 528 Figure 2: PCE-Initiated PCECC LSP (PCC allocation) 530 It should be noted that in this example, the request is made to the 531 egress node with the C bit set in the CCI object to indicate that the 532 label allocation needs to be done by the egress and the egress 533 responds with the allocated label to the PCE. The PCE further inform 534 the transit PCC without setting the C bit to 1 in the CCI object for 535 out-label but the C bit is set to 1 for in-label so the transit node 536 make the label allocation (for the in-label) and report to the PCE. 537 Similarly, the C bit is unset towards the ingress to complete all the 538 label allocation for the PCECC LSP. 540 5.5.2. PCC-Initiated PCECC LSP 542 In order to set up an LSP based on the PCECC mechanism where the LSP 543 is configured at the PCC, a PCC MUST delegate the LSP by sending a 544 PCRpt message with PST set for PCECC (see Section 7.2) and D 545 (Delegate) flag (see [RFC8231]) set in the LSP object (see Figure 3). 547 When a PCE receives the initial PCRpt message with D flag and PST 548 Type set to TBD1, it SHOULD calculate the path and assigns labels 549 along the path; and sets up the path by sending a PCInitiate message 550 to each node along the path of the LSP as per the PCECC technique 551 (see Figure 3). The CC-ID uniquely identifies the central controller 552 instruction within a PCEP session. Each PCC further responds with 553 the PCRpt messages including the central controller instruction (CCI) 554 and the LSP objects. 556 Once the central controller instructions (label operations) are 557 completed, the PCE MUST send the PCUpd message to the ingress PCC. 558 As per [RFC8231], this PCUpd message should include the path 559 information calculated by the PCE. 561 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 563 The LSP deletion operation for PCECC LSPs is the same as defined in 564 [RFC8231]. If the PCE receives a PCRpt message for LSP deletion then 565 it does label clean up operation as described in Section 5.5.3.2 for 566 the corresponding LSP. 568 The Basic PCECC LSP setup sequence is as shown in Figure 3. 570 +-------+ +-------+ 571 |PCC | | PCE | 572 |ingress| +-------+ 573 +------| | | 574 | PCC +-------+ | 575 | transit| | | 576 +------| | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| PCECC LSP 577 |PCC +--------+ | | 578 |egress | | | | 579 +--------+ | | | 580 | | | | 581 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 582 | | | L1,O=0 | download 583 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 584 | | | | 585 | |<------PCInitiate,PLSP-ID=1,---------------| Labels 586 | | | CC-ID=Y1,O=0,L2 | download 587 | | | CC-ID=Y2,O=1,L1 | CCI 588 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=1-------->| 589 | | | | 590 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 591 | | | L2,O=1 | download 592 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 593 | | | | 594 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC LSP 595 | | | | Update 596 | | | | 598 Figure 3: PCC-Initiated PCECC LSP 600 In the case where the label allocations are made by the PCC itself 601 (see Section 5.5.8), the PCE could request an allocation to be made 602 by the PCC, and then the PCC would send a PCRpt with the allocated 603 label encoded in the CC-ID object as shown in Figure 4. 605 +-------+ +-------+ 606 |PCC | | PCE | 607 |ingress| +-------+ 608 +------| | | 609 | PCC +-------+ | 610 | transit| | | 611 +------| | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| PCECC LSP 612 |PCC +--------+ | | 613 |egress | | | | 614 +--------+ | | | 615 | | | | 616 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 617 | | | C=1 | download 618 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 619 | | | Label=L1 | 620 | |<------PCInitiate,PLSP-ID=1,---------------| Labels 621 | | | CC-ID=Y1,C=1 | download 622 | | | CC-ID=Y2,C=0,L1 | CCI 623 | |-------PCRpt,PLSP-ID=1-------------------->| 624 | | | CC-ID=Y1,Label=L2 | 625 | | | CC-ID=Y2 | 626 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 627 | | | C=0,L2 | download 628 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 629 | | | | 630 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC LSP 631 | | | | Update 632 | | | | 634 - The O bit is set as before (and thus not included) 636 Figure 4: PCC-Initiated PCECC LSP (PCC allocation) 638 In the case where the label allocations are made by the PCC itself 639 (see Section 5.5.8), the procedure remains the same, with just an 640 additional constraint on the configuration sequence. 642 The rest of the PCC-Initiated PCECC LSP setup operations are the same 643 as those described in Section 5.5.1. 645 5.5.3. Central Controller Instructions 647 The new central controller instructions (CCI) for the label 648 operations in PCEP is done via the PCInitiate message, by defining a 649 new PCEP Object for CCI operations. The local label range of each 650 PCC is assumed to be known by both the PCC and the PCE. 652 5.5.3.1. Label Download CCI 654 In order to set up an LSP based on PCECC, the PCE sends a PCInitiate 655 message to each node along the path to download the Label instruction 656 as described in Section 5.5.1 and Section 5.5.2. 658 The CCI object MUST be included, along with the LSP object in the 659 PCInitiate message. The LSP-IDENTIFIER TLV MUST be included in the 660 LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in the LSP 661 object. 663 If a node (PCC) receives a PCInitiate message which includes a Label 664 to download, as part of CCI, that is out of the range set aside for 665 the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC 666 failure) and Error-value=TBD6 (Label out of range) and MUST include 667 the SRP object to specify the error is for the corresponding label 668 update via PCInitiate message. If a PCC receives a PCInitiate 669 message but fails to download the Label entry, it MUST send a PCErr 670 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 671 (instruction failed) and MUST include the SRP object to specify the 672 error is for the corresponding label update via PCInitiate message. 674 A new PCEP object for central controller instructions (CCI) is 675 defined in Section 7.3. 677 5.5.3.2. Label Clean up CCI 679 In order to delete an LSP based on PCECC, the PCE sends a central 680 controller instructions via a PCInitiate message to each node along 681 the path of the LSP to clean up the Label forwarding instruction. 683 If the PCC receives a PCInitiate message but does not recognize the 684 label in the CCI, the PCC MUST generate a PCErr message with Error- 685 Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and 686 MUST include the SRP object to specify the error is for the 687 corresponding label clean up (via PCInitiate message). 689 The R flag in the SRP object defined in [RFC8281] specifies the 690 deletion of Label Entry in the PCInitiate message. 692 +-------+ +-------+ 693 |PCC | | PCE | 694 |ingress| +-------+ 695 +------| | | 696 | PCC +-------+ | 697 | transit| | | 698 +------| | | | 699 |PCC +--------+ | | 700 |egress | | | | 701 +--------+ | | | 702 | | | | 703 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 704 | | | R=1 | clean up 705 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 706 | | | | 707 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2-----| Label 708 | | | R=1 | clean up 709 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=2--------->| CCI 710 | | | | 711 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 712 | | | R=1 | clean up 713 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 714 | | | | 715 | | |<--PCInitiate,PLSP-ID=2,PST=TBD1,R=1--| PCECC LSP 716 | | | | remove 718 Figure 5: Label Cleanup 720 As per [RFC8281], following the removal of the Label forwarding 721 instruction, the PCC MUST send a PCRpt message. The SRP object in 722 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 723 that triggered the removal. The R flag in the SRP object MUST be 724 set. 726 In the case where the label allocation is made by the PCC itself (see 727 Section 5.5.8), the removal procedure remains the same, adding the 728 sequence constraint. 730 5.5.4. PCECC LSP Update 732 The update is done as per the make-before-break procedures, i.e. the 733 PCECC first updates new label instructions based on the updated path 734 and then notify it to the ingress to switch traffic, before cleaning 735 up the former instructions. New CC-IDs are used to identify the 736 updated instructions, the identifiers in the LSP object identify the 737 existing LSP. Once new instructions are downloaded, the PCE further 738 updates the new path at the ingress which triggers the traffic switch 739 on the updated path. The ingress PCC acknowledges with a PCRpt 740 message, on receipt of the PCRpt message, the PCE does clean up 741 operation for the former LSP as described in Section 5.5.3.2. 743 The PCECC LSP Update sequence is shown in Figure 6. 745 +-------+ +-------+ 746 |PCC | | PCE | 747 |ingress| +-------+ 748 +------| | | 749 | PCC +-------+ | 750 | transit| | | 751 +------| | | | 752 |PCC +--------+ | | 753 |egress | | | | 754 +--------+ | | | 755 | | | | New Path 756 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 -------------| for LSP 757 | | | | trigger 758 |--------PCRpt,CC-ID=XX,PLSP-ID=1------------------>| new CCI 759 | | | | 760 | |<------PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 761 | | | | download 762 | |-------PCRpt,CC-ID=YY1,YY2,PLSP-ID=1------>| CCI 763 | | | | 764 | | |<----PCInitiate,CC-ID=ZZ,PLSP-ID=1---| Label 765 | | | | download 766 | | |-----PCRpt,CC-ID=ZZ,PLSP-ID=1------->| CCI 767 | | | | 768 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC 769 | | | SRP=S | LSP Update 770 | | | | 771 | | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| Trigger 772 | | | (SRP=S) | Delete 773 | | | | former CCI 774 | | | | 775 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 776 | | | R=1 | clean up 777 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 778 | | | | 779 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1----| Label 780 | | | R=1 | clean up 781 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=1-------->| CCI 782 | | | | 783 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 784 | | | R=1 | clean up 785 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 786 | | | | 788 Figure 6: PCECC LSP Update 790 The modified PCECC LSPs are considered to be 'up' by default. The 791 ingress MAY further choose to deploy a data plane check mechanism and 792 report the status back to the PCE via a PCRpt message. 794 In the case where the label allocations are made by the PCC itself 795 (see Section 5.5.8), the procedure remains the same. 797 5.5.5. Re-Delegation and Clean up 799 As described in [RFC8281], a new PCE can gain control over an 800 orphaned LSP. In the case of a PCECC LSP, the new PCE MUST also gain 801 control over the central controller instructions in the same way by 802 sending a PCInitiate message that includes the SRP, LSP, and CCI 803 objects and carries the CC-ID and PLSP-ID identifying the instruction 804 that it wants to take control of. 806 Further, as described in [RFC8281], the State Timeout Interval timer 807 ensures that a PCE crash does not result in automatic and immediate 808 disruption for the services using PCE-initiated LSPs. Similarly the 809 central controller instructions are not removed immediately upon PCE 810 failure. Instead, they are cleaned up on the expiration of this 811 timer. This allows for network clean up without manual intervention. 812 The PCC MUST support the removal of CCI as one of the behaviors 813 applied on expiration of the State Timeout Interval timer. 815 In case of PCC-initiated PCECC LSP, the control over the orphaned LSP 816 at the ingress PCC is taken over by the mechanism specified in 817 [RFC8741] to request delegation. The control over the central 818 controller instructions is described above using [RFC8281]. 820 5.5.6. Synchronization of Central Controllers Instructions 822 The purpose of Central Controllers Instructions synchronization 823 (labels in the context of this document) is to make sure that the 824 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 825 This synchronization is performed as part of the LSP state 826 synchronization as described in [RFC8231] and [RFC8232]. 828 As per LSP State Synchronization [RFC8231], a PCC reports the state 829 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 830 would initiate any missing LSPs and/or remove any LSPs that are not 831 wanted. The same PCEP messages and procedures are also used for the 832 Central Controllers Instructions synchronization. The PCRpt message 833 includes the CCI and the LSP object to report the label forwarding 834 instructions. The PCE would further remove any unwanted instructions 835 or initiate any missing instructions. 837 5.5.7. PCECC LSP State Report 839 As mentioned before, an ingress PCC MAY choose to apply any OAM 840 mechanism to check the status of LSP in the Data plane and MAY 841 further send its status in a PCRpt message to the PCE. 843 5.5.8. PCC-Based Allocations 845 The PCE can request the PCC to allocate the label using the 846 PCInitiate message. The C flag in the CCI object is set to 1 to 847 indicate that the allocation needs to be done by the PCC. The PCC 848 SHOULD allocate the Label and SHOULD report to the PCE using the 849 PCRpt message. 851 If the value of the Label is 0 and the C flag is set to 1, it 852 indicates that the PCE is requesting the allocation to be done by the 853 PCC. If the Label is 'n' and the C flag is set to 1 in the CCI 854 object, it indicates that the PCE requests a specific value 'n' for 855 the Label. If the allocation is successful, the PCC MUST report via 856 the PCRpt message with the CCI object. Else, it MUST send a PCErr 857 message with Error-Type = TBD5 ("PCECC failure") and Error Value = 858 TBD9 ("Invalid CCI"). If the value of the Label in the CCI object is 859 valid, but the PCC is unable to allocate it, it MUST send a PCErr 860 message with Error-Type = TBD5 ("PCECC failure") and Error Value = 861 TBD10 ("Unable to allocate the specified CCI"). 863 If the PCC wishes to withdraw or modify the previously assigned 864 label, it MUST send a PCRpt message without any Label or with the 865 Label containing the new value respectively in the CCI object. The 866 PCE would further trigger the removal of the central controller 867 instruction as per this document. 869 6. PCEP Messages 871 As defined in [RFC5440], a PCEP message consists of a common header 872 followed by a variable-length body made of a set of objects that can 873 be either mandatory or optional. An object is said to be mandatory 874 in a PCEP message when the object must be included for the message to 875 be considered valid. For each PCEP message type, a set of rules is 876 defined that specify the set of objects that the message can carry. 877 An implementation MUST form the PCEP messages using the object 878 ordering specified in this document. 880 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 882 The message formats in this document are specified using Routing 883 Backus-Naur Form (RBNF) encoding as specified in [RFC5511]. 885 6.1. The PCInitiate Message 887 The PCInitiate message [RFC8281] can be used to download or remove 888 the labels, this document extends the message as shown below - 890 ::= 891 892 Where: 893 is defined in [RFC5440] 895 ::= 896 [] 898 ::= 899 (| 900 | 901 ) 903 ::= 904 905 907 ::= 908 [] 910 Where: 911 and 912 are as per 913 [RFC8281]. 915 The LSP and SRP object is defined in [RFC8231]. 917 When PCInitiate message is used for the central controller 918 instructions (labels), the SRP, LSP, and CCI objects MUST be present. 919 The SRP object is defined in [RFC8231] and if the SRP object is 920 missing, the receiving PCC MUST send a PCErr message with Error- 921 type=6 (Mandatory Object missing) and Error-value=10 (SRP object 922 missing). The LSP object is defined in [RFC8231] and if the LSP 923 object is missing, the receiving PCC MUST send a PCErr message with 924 Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object 925 missing). The CCI object is defined in Section 7.3 and if the CCI 926 object is missing, the receiving PCC MUST send a PCErr message with 927 Error-type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI 928 object missing). More than one CCI object MAY be included in the 929 PCInitiate message for a transit LSR. 931 To clean up entries, the R (remove) bit MUST be set in the SRP object 932 to be encoded along with the LSP and the CCI object. 934 The CCI object received at the ingress node MUST have the O bit (out- 935 label) set. The CCI Object received at the egress MUST have the O 936 bit unset. If this is not the case, PCC MUST send a PCErr message 937 with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 938 ("Invalid CCI"). Other instances of the CCI object if present, MUST 939 be ignored. 941 At most two instances of the CCI object can be included, in the case 942 of transit LSR to encode both in-coming and out-going label 943 forwarding instructions. Other instances MUST be ignored for P2P 944 LSP. If the transit LSR did not receive two CCI object with one of 945 them having the O bit set and another with O bit unset, it MUST send 946 a PCErr message with Error-Type = TBD5 ("PCECC failure") and Error 947 Value = TBD9 ("Invalid CCI"). 949 Note that, on receipt of the PCInitiate message with CCI object, the 950 ingress, egress, or transit role of the PCC is identified via the 951 ingress and egress IP address encoded in the LSP-IDENTIFIERS TLV. 953 6.2. The PCRpt Message 955 The PCRpt message can be used to report the labels that were 956 allocated by the PCE, to be used during the state synchronization 957 phase or as acknowledgemnt to PCInitiate message. 959 ::= 960 961 Where: 963 ::= [] 965 ::= (| 966 ) 968 ::= [] 969 970 972 ::= [] 973 974 976 ::= 977 [] 979 Where: 980 is as per [RFC8231] and the LSP and SRP object are 981 also defined in [RFC8231]. 983 When PCRpt message is used to report the central controller 984 instructions (labels), the LSP and CCI objects MUST be present. The 985 LSP object is defined in [RFC8231] and if the LSP object is missing, 986 the receiving PCE MUST send a PCErr message with Error-type=6 987 (Mandatory Object missing) and Error-value=8 (LSP object missing). 988 The CCI object is defined in Section 7.3 and if the CCI object is 989 missing, the receiving PCE MUST send a PCErr message with Error- 990 type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object 991 missing). Two CCI objects can be included in the PCRpt message for a 992 transit LSR. 994 7. PCEP Objects 996 The PCEP objects defined in this document are compliant with the PCEP 997 object format defined in [RFC5440]. 999 7.1. OPEN Object 1001 This document defines a new PST (TBD1) to be included in the PATH- 1002 SETUP-TYPE-CAPABILITY TLV in the OPEN Object. Further, a new sub-TLV 1003 for PCECC capability exchange is also defined. 1005 7.1.1. PCECC Capability sub-TLV 1007 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 1008 Object in the PATH-SETUP-TYPE-CAPABILITY TLV, when the Path Setup 1009 Type list includes the PCECC Path Setup Type TBD1. A PCECC- 1010 CAPABILITY sub-TLV MUST be ignored if the PST list does not contain 1011 PST=TBD1. 1013 Its format is shown in Figure 7. 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Type=TBD12 | Length=4 | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Flags |L| 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Figure 7: PCECC Capability sub-TLV 1025 The type of the TLV is TBD12 and it has a fixed length of 4 octets. 1027 The value comprises a single field - Flags (32 bits). Currently, the 1028 following flag bit is defined: 1030 o L bit (Label): if set to 1 by a PCEP speaker, the L flag indicates 1031 that the PCEP speaker support and willing to handle the PCECC 1032 based central controller instructions for label download. The bit 1033 MUST be set to 1 by both a PCC and a PCE for the PCECC label 1034 download/report on a PCEP session. 1036 o Unassigned bits MUST be set to 0 on transmission and MUST be 1037 ignored on receipt. 1039 7.2. PATH-SETUP-TYPE TLV 1041 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 1042 defines a new PST value: 1044 o PST = TBD1: Path is set up via PCECC mode. 1046 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in the PATH-SETUP- 1047 TYPE TLV in the SRP object MUST be included for a LSP set up via the 1048 PCECC-based mechanism. 1050 7.3. CCI Object 1052 The Central Controller Instructions (CCI) Object is used by the PCE 1053 to specify the forwarding instructions (Label information in the 1054 context of this document) to the PCC, and MAY be carried within 1055 PCInitiate or PCRpt message for label download/report. 1057 CCI Object-Class is TBD13. 1059 CCI Object-Type is 1 for the MPLS Label. 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | CC-ID | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Reserved1 | Flags |C|O| 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Label | Reserved2 | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | | 1071 // Optional TLV // 1072 | | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 Figure 8: CCI Object 1077 The fields in the CCI object are as follows: 1079 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 1080 creates a CC-ID for each instruction, the value is unique within 1081 the scope of the PCE and is constant for the lifetime of a PCEP 1082 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 1083 used. 1085 Reserved1 (16 bit): Set to zero while sending, ignored on receive. 1087 Flags (16 bit): A field used to carry any additional information 1088 pertaining to the CCI. Currently, the following flag bits are 1089 defined: 1091 * O bit(Out-label) : If the bit is set to 1, it specifies the 1092 label is the OUT label and it is mandatory to encode the next- 1093 hop information (via IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or 1094 UNNUMBERED-IPV4-ID-ADDRESS TLV in the CCI object). If the bit 1095 is not set, it specifies the label is the IN label and it is 1096 optional to encode the local interface information (via 1097 IPV4-ADDRESS TLV or IPV6-ADDRESS TLV or UNNUMBERED-IPV4-ID- 1098 ADDRESS TLV in the CCI object). 1100 * C Bit (PCC Allocation): If the bit is set to 1, it indicates 1101 that the label allocation needs to be done by the PCC for this 1102 central controller instruction. A PCE sets this bit to request 1103 the PCC to make an allocation from its label space. A PCC 1104 would set this bit to indicate that it has allocated the label 1105 and report it to the PCE. 1107 * All unassigned bits MUST be set to zero at transmission and 1108 ignored at receipt. 1110 Label (20-bit): The Label information. 1112 Reserved2 (12 bit): Set to zero while sending, ignored on receive. 1114 7.3.1. Address TLVs 1116 This document defines the following TLVs for the CCI object to 1117 associate the next-hop information in the case of an outgoing label 1118 and local interface information in the case of an incoming label. 1120 IPV4-ADDRESS TLV: 1122 0 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Type=TBD14 | Length = 4 | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | IPv4 address | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 IPV6-ADDRESS TLV: 1132 0 1 2 3 1133 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 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Type=TBD15 | Length = 16 | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | | 1138 // IPv6 address (16 bytes) // 1139 | | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 UNNUMBERED-IPV4-ID-ADDRESS TLV: 1144 0 1 2 3 1145 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 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Type=TBD16 | Length = 8 | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Node-ID | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Interface ID | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 LINKLOCAL-IPV6-ID-ADDRESS TLV: 1156 0 1 2 3 1157 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 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Type=TBD17 | Length = 40 | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 // Local IPv6 address (16 octets) // 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | Local Interface ID | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 // Remote IPv6 address (16 octets) // 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Remote Interface ID | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 Figure 9: Address TLVs 1172 The address TLVs are as follows: 1174 IPV4-ADDRESS TLV: an IPv4 address. 1176 IPV6-ADDRESS TLV: an IPv6 address. 1178 UNNUMBERED-IPV4-ID-ADDRESS TLV: a Node ID / Interface ID tuple. 1180 LINKLOCAL-IPV6-ID-ADDRESS TLV: a pair of (global IPv6 address, 1181 interface ID) tuples. 1183 8. Implementation Status 1185 [Note to the RFC Editor - remove this section before publication, as 1186 well as remove the reference to RFC 7942.] 1188 This section records the status of known implementations of the 1189 protocol defined by this specification at the time of posting of this 1190 Internet-Draft, and is based on a proposal described in [RFC7942]. 1192 The description of implementations in this section is intended to 1193 assist the IETF in its decision processes in progressing drafts to 1194 RFCs. Please note that the listing of any individual implementation 1195 here does not imply endorsement by the IETF. Furthermore, no effort 1196 has been spent to verify the information presented here that was 1197 supplied by IETF contributors. This is not intended as, and must not 1198 be construed to be, a catalog of available implementations or their 1199 features. Readers are advised to note that other implementations may 1200 exist. 1202 According to [RFC7942], "this will allow reviewers and working groups 1203 to assign due consideration to documents that have the benefit of 1204 running code, which may serve as evidence of valuable experimentation 1205 and feedback that have made the implemented protocols more mature. 1206 It is up to the individual working groups to use this information as 1207 they see fit". 1209 8.1. Huawei's Proof of Concept based on ONOS 1211 The PCE function was developed in the ONOS open source platform. 1212 This extension was implemented on a private version as a proof of 1213 concept for PCECC. 1215 o Organization: Huawei 1217 o Implementation: Huawei's PoC based on ONOS 1219 o Description: PCEP as a southbound plugin was added to ONOS. To 1220 support PCECC, an earlier version of this I-D was implemented. 1221 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1223 o Maturity Level: Prototype 1225 o Coverage: Partial 1227 o Contact: satishk@huawei.com 1229 9. Security Considerations 1231 The security considerations described in [RFC8231] and [RFC8281] 1232 apply to the extensions described in this document. Additional 1233 considerations related to a malicious PCE are introduced. 1235 9.1. Malicious PCE 1237 PCE has complete control over PCC to update the labels and can cause 1238 the LSP's to behave inappropriately and cause major impact to the 1239 network. As a general precaution, it is RECOMMENDED that this PCEP 1240 extension be activated on authenticated and encrypted sessions across 1241 PCEs and PCCs belonging to the same administrative authority, using 1242 Transport Layer Security (TLS) [RFC8253], as per the recommendations 1243 and best current practices in [RFC7525]. 1245 10. Manageability Considerations 1247 10.1. Control of Function and Policy 1249 A PCE or PCC implementation SHOULD allow to configure to enable/ 1250 disable PCECC capability as a global configuration. Section 6.1 of 1251 [RFC8664] list various controlling factors regarding path setup type. 1252 They are also applicable to the PCECC path setup types. Further, 1253 Section 6.2 of [RFC8664] describe the migration steps when path setup 1254 type of an existing LSP is changed. 1256 10.2. Information and Data Models 1258 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1259 PCECC capability status. 1261 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1262 enable/disable PCECC capability. 1264 10.3. Liveness Detection and Monitoring 1266 Mechanisms defined in this document do not imply any new liveness 1267 detection and monitoring requirements in addition to those already 1268 listed in [RFC5440]. 1270 10.4. Verify Correct Operations 1272 The operator needs the following information to verify that PCEP is 1273 operating correctly with respect to the PCECC path setup type. 1275 o An implementation SHOULD allow the operator to view whether the 1276 PCEP speaker sent the PCECC PST capability to its peer. 1278 o An implementation SHOULD allow the operator to view whether the 1279 peer sent the PCECC PST capability. 1281 o An implementation SHOULD allow the operator to view whether the 1282 PCECC PST is enabled on the PCEP session. 1284 o If one PCEP speaker advertises the PCECC PST capability, but the 1285 other does not, then the implementation SHOULD create a log to 1286 inform the operator of the capability mismatch. 1288 o If a PCEP speaker rejects a CCI, then it SHOULD create a log to 1289 inform the operator, giving the reason for the decision (local 1290 policy, Label issues, etc.). 1292 10.5. Requirements On Other Protocols 1294 PCEP extensions defined in this document do not put new requirements 1295 on other protocols. 1297 10.6. Impact On Network Operations 1299 PCEP extensions defined in this document do not put new requirements 1300 on network operations. 1302 11. IANA Considerations 1304 11.1. PCEP TLV Type Indicators 1306 IANA is requested to allocate the following TLV Type Indicator values 1307 within the "PCEP TLV Type Indicators" sub-registry of the PCEP 1308 Numbers registry: 1310 Value Meaning Reference 1311 TBD14 IPV4-ADDRESS TLV This document 1312 TBD15 IPV6-ADDRESS TLV This document 1313 TBD16 UNNUMBERED-IPV4-ID-ADDRESS TLV This document 1314 TBD17 LINKLOCAL-IPV6-ID-ADDRESS TLV This document 1316 11.2. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1318 [RFC8408] requested the creation of "PATH-SETUP-TYPE-CAPABILITY Sub- 1319 TLV Type Indicators" sub-registry. Further IANA is requested to 1320 allocate the following code-point: 1322 Value Meaning Reference 1323 TBD12 PCECC-CAPABILITY This document 1325 11.3. PCECC-CAPABILITY sub-TLV's Flag field 1327 This document defines the PCECC-CAPABILITY sub-TLV and requests that 1328 IANA to create a new sub-registry to manage the value of the PCECC- 1329 CAPABILITY sub-TLV's 32-bits Flag field. New values are to be 1330 assigned by Standards Action [RFC8126]. Each bit should be tracked 1331 with the following qualities: 1333 o Bit number (counting from bit 0 as the most significant bit) 1335 o Capability description 1336 o Defining RFC 1338 Currently, there is one allocation in this registry. 1340 Bit Name Reference 1341 31 Label This document 1342 0-30 Unassigned This document 1344 11.4. Path Setup Type Registry 1346 [RFC8408] created a sub-registry within the "Path Computation Element 1347 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1348 IANA is requested to allocate a new code point within this registry, 1349 as follows: 1351 Value Description Reference 1352 TBD1 Traffic engineering path is This document 1353 set up using PCECC mode 1355 11.5. PCEP Object 1357 IANA is requested to allocate new code-point in the "PCEP Objects" 1358 sub-registry for the CCI object as follows: 1360 Object-Class Value Name Reference 1361 TBD13 CCI Object-Type This document 1362 0 Reserved 1363 1 MPLS Label 1365 11.6. CCI Object Flag Field 1367 IANA is requested to create a new sub-registry to manage the Flag 1368 field of the CCI object called "CCI Object 16-bits Flag Field". New 1369 values are to be assigned by Standards Action [RFC8126]. Each bit 1370 should be tracked with the following qualities: 1372 o Bit number (counting from bit 0 as the most significant bit) 1374 o Capability description 1376 o Defining RFC 1378 Two bits to be defined for the CCI Object flag field in this document 1379 as follows: 1381 Bit Description Reference 1382 0-13 Unassigned This document 1383 14 C Bit - PCC allocation This document 1384 15 O Bit - Specifies label This document 1385 is out-label 1387 11.7. PCEP-Error Object 1389 IANA is requested to allocate new error types and error values within 1390 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1391 PCEP Numbers registry for the following errors: 1393 Error-Type Meaning 1394 ---------- ------- 1395 6 Mandatory Object missing. 1397 Error-value = TBD11 : CCI object missing 1399 10 Reception of an invalid object. 1401 Error-value = TBD2 : Missing PCECC 1402 Capability sub-TLV 1403 19 Invalid operation. 1405 Error-value = TBD3 : Attempted PCECC 1406 operations when 1407 PCECC capability 1408 was not advertised 1409 Error-value = TBD4 : Stateful PCE 1410 capability was not 1411 advertised 1412 Error-value = TBD8 : Unknown Label 1414 TBD5 PCECC failure. 1416 Error-value = TBD6 : Label out of range. 1417 Error-value = TBD7 : Instruction failed. 1418 Error-value = TBD9 : Invalid CCI. 1419 Error-value = TBD10 : Unable to allocate 1420 the specified CCI. 1422 12. Acknowledgments 1424 We would like to thank Robert Tao, Changjing Yan, Tieying Huang, 1425 Avantika, and Aijun Wang for their useful comments and suggestions. 1427 Thanks to Julien Meuric for shepherding this I-D and providing 1428 valuable comments. 1430 Thanks to Victoria Pritchard for a very detailed RTGDIR review. 1432 13. References 1434 13.1. Normative References 1436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1437 Requirement Levels", BCP 14, RFC 2119, 1438 DOI 10.17487/RFC2119, March 1997, 1439 . 1441 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1442 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1443 DOI 10.17487/RFC5440, March 2009, 1444 . 1446 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1447 Used to Form Encoding Rules in Various Routing Protocol 1448 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1449 2009, . 1451 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1452 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1453 May 2017, . 1455 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1456 Computation Element Communication Protocol (PCEP) 1457 Extensions for Stateful PCE", RFC 8231, 1458 DOI 10.17487/RFC8231, September 2017, 1459 . 1461 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1462 Computation Element Communication Protocol (PCEP) 1463 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1464 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1465 . 1467 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1468 Hardwick, "Conveying Path Setup Type in PCE Communication 1469 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1470 July 2018, . 1472 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1473 and J. Hardwick, "Path Computation Element Communication 1474 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1475 DOI 10.17487/RFC8664, December 2019, 1476 . 1478 13.2. Informative References 1480 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1481 Element (PCE)-Based Architecture", RFC 4655, 1482 DOI 10.17487/RFC4655, August 2006, 1483 . 1485 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1486 Margaria, "Requirements for GMPLS Applications of PCE", 1487 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1488 . 1490 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1491 Computation Element Architecture", RFC 7399, 1492 DOI 10.17487/RFC7399, October 2014, 1493 . 1495 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1496 Hardwick, "Path Computation Element Communication Protocol 1497 (PCEP) Management Information Base (MIB) Module", 1498 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1499 . 1501 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1502 Application-Based Network Operations", RFC 7491, 1503 DOI 10.17487/RFC7491, March 2015, 1504 . 1506 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1507 "Recommendations for Secure Use of Transport Layer 1508 Security (TLS) and Datagram Transport Layer Security 1509 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1510 2015, . 1512 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1513 Code: The Implementation Status Section", BCP 205, 1514 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1515 . 1517 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1518 Writing an IANA Considerations Section in RFCs", BCP 26, 1519 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1520 . 1522 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1523 and D. Dhody, "Optimizations of Label Switched Path State 1524 Synchronization Procedures for a Stateful PCE", RFC 8232, 1525 DOI 10.17487/RFC8232, September 2017, 1526 . 1528 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1529 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1530 Path Computation Element Communication Protocol (PCEP)", 1531 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1532 . 1534 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1535 Architecture for Use of PCE and the PCE Communication 1536 Protocol (PCEP) in a Network with Central Control", 1537 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1538 . 1540 [RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and 1541 M. Negi, "Ability for a Stateful Path Computation Element 1542 (PCE) to Request and Obtain Control of a Label Switched 1543 Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020, 1544 . 1546 [I-D.ietf-teas-pcecc-use-cases] 1547 Li, Z., Khasanov, B., Dhody, D., Zhao, Q., Ke, Z., Fang, 1548 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1549 Gulida, "The Use Cases for Path Computation Element (PCE) 1550 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1551 use-cases-06 (work in progress), September 2020. 1553 [I-D.ietf-pce-pcep-yang] 1554 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1555 YANG Data Model for Path Computation Element 1556 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1557 yang-15 (work in progress), October 2020. 1559 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 1560 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1561 Procedures and Protocol Extensions for Using PCE as a 1562 Central Controller (PCECC) for Segment Routing (SR) MPLS 1563 Segment Identifier (SID) Allocation and Distribution.", 1564 draft-zhao-pce-pcep-extension-pce-controller-sr-09 (work 1565 in progress), November 2020. 1567 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 1568 Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures 1569 and Protocol Extensions for Using PCE as a Central 1570 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 1571 extension-pce-controller-srv6-05 (work in progress), 1572 November 2020. 1574 [I-D.li-pce-controlled-id-space] 1575 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1576 Controlled ID Space", draft-li-pce-controlled-id-space-07 1577 (work in progress), October 2020. 1579 Appendix A. Contributor Addresses 1581 Dhruv Dhody 1582 Huawei Technologies 1583 Divyashree Techno Park, Whitefield 1584 Bangalore, Karnataka 560066 1585 India 1587 EMail: dhruv.ietf@gmail.com 1589 Satish Karunanithi 1590 Huawei Technologies 1591 Divyashree Techno Park, Whitefield 1592 Bangalore, Karnataka 560066 1593 India 1595 EMail: satishk@huawei.com 1597 Adrian Farrel 1598 Old Dog Consulting 1599 UK 1601 EMail: adrian@olddog.co.uk 1603 Xuesong Geng 1604 Huawei Technologies 1605 China 1607 Email: gengxuesong@huawei.com 1609 Udayasree Palle 1611 EMail: udayasreereddy@gmail.com 1613 Katherine Zhao 1614 Futurewei Technologies 1616 EMail: katherine.zhao@futurewei.com 1618 Boris Zhang 1619 Telus Ltd. 1620 Toronto 1621 Canada 1623 EMail: boris.zhang@telus.com 1625 Alex Tokar 1626 Cisco Systems 1627 Slovak Republic 1629 EMail: atokar@cisco.com 1631 Authors' Addresses 1633 Zhenbin Li 1634 Huawei Technologies 1635 Huawei Bld., No.156 Beiqing Rd. 1636 Beijing 100095 1637 China 1639 EMail: lizhenbin@huawei.com 1641 Shuping Peng 1642 Huawei Technologies 1643 Huawei Bld., No.156 Beiqing Rd. 1644 Beijing 100095 1645 China 1647 EMail: pengshuping@huawei.com 1649 Mahendra Singh Negi 1650 RtBrick Inc 1651 N-17L, 18th Cross Rd, HSR Layout 1652 Bangalore, Karnataka 560102 1653 India 1655 EMail: mahend.ietf@gmail.com 1657 Quintin Zhao 1658 Etheric Networks 1659 1009 S CLAREMONT ST 1660 SAN MATEO, CA 94402 1661 USA 1663 EMail: qzhao@ethericnetworks.com 1665 Chao Zhou 1666 HPE 1668 EMail: chaozhou_us@yahoo.com