idnits 2.17.1 draft-ietf-pce-pcep-extension-for-pce-controller-14.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 4, 2021) is 1150 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) == 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 (-08) exists of draft-ietf-pce-pcep-extension-pce-controller-sr-00 == 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 == Outdated reference: A later version (-11) exists of draft-gont-numeric-ids-sec-considerations-06 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: September 5, 2021 M. Negi 6 RtBrick Inc 7 Q. Zhao 8 Etheric Networks 9 C. Zhou 10 HPE 11 March 4, 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-14 17 Abstract 19 The Path Computation Element (PCE) is a core component of Software- 20 Defined Networking (SDN) systems. 22 A PCE-based Central Controller (PCECC) can simplify the processing of 23 a distributed control plane by blending it with elements of SDN and 24 without necessarily completely replacing it. Thus, the LSP can be 25 calculated/set up/initiated and the label forwarding entries can also 26 be downloaded through a centralized PCE server to each network device 27 along the path, while leveraging the existing PCE technologies as 28 much as possible. 30 This document specifies the procedures and PCEP extensions for using 31 the PCE as the central controller for provisioning labels along the 32 path of the static LSP. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 5, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Basic PCECC Mode . . . . . . . . . . . . . . . . . . . . . . 5 71 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Procedures for Using the PCE as a Central Controller (PCECC) 6 73 5.1. Stateful PCE Model . . . . . . . . . . . . . . . . . . . 6 74 5.2. New LSP Functions . . . . . . . . . . . . . . . . . . . . 6 75 5.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 7 76 5.4. PCECC Capability Advertisement . . . . . . . . . . . . . 7 77 5.5. LSP Operations . . . . . . . . . . . . . . . . . . . . . 9 78 5.5.1. PCE-Initiated PCECC LSP . . . . . . . . . . . . . . . 9 79 5.5.2. PCC-Initiated PCECC LSP . . . . . . . . . . . . . . . 12 80 5.5.3. Central Controller Instructions . . . . . . . . . . . 15 81 5.5.3.1. Label Download CCI . . . . . . . . . . . . . . . 16 82 5.5.3.2. Label Clean up CCI . . . . . . . . . . . . . . . 16 83 5.5.4. PCECC LSP Update . . . . . . . . . . . . . . . . . . 17 84 5.5.5. Re-Delegation and Clean up . . . . . . . . . . . . . 20 85 5.5.6. Synchronization of Central Controllers Instructions . 20 86 5.5.7. PCECC LSP State Report . . . . . . . . . . . . . . . 21 87 5.5.8. PCC-Based Allocations . . . . . . . . . . . . . . . . 21 88 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 21 89 6.1. The PCInitiate Message . . . . . . . . . . . . . . . . . 22 90 6.2. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23 91 7. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . . 24 92 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 24 93 7.1.1. PCECC Capability sub-TLV . . . . . . . . . . . . . . 25 94 7.2. PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . . 25 95 7.3. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 26 96 7.3.1. Address TLVs . . . . . . . . . . . . . . . . . . . . 27 97 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 98 8.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 28 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 100 9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 29 101 9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 29 102 10. Manageability Considerations . . . . . . . . . . . . . . . . 29 103 10.1. Control of Function and Policy . . . . . . . . . . . . . 29 104 10.2. Information and Data Models . . . . . . . . . . . . . . 30 105 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 30 106 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 30 107 10.5. Requirements On Other Protocols . . . . . . . . . . . . 30 108 10.6. Impact On Network Operations . . . . . . . . . . . . . . 31 109 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 110 11.1. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 31 111 11.2. PCECC-CAPABILITY sub-TLV's Flag field . . . . . . . . . 31 112 11.3. Path Setup Type Registry . . . . . . . . . . . . . . . . 31 113 11.4. PCEP Object . . . . . . . . . . . . . . . . . . . . . . 32 114 11.5. CCI Object Flag Field . . . . . . . . . . . . . . . . . 32 115 11.6. PCEP-Error Object . . . . . . . . . . . . . . . . . . . 32 116 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 117 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 118 13.1. Normative References . . . . . . . . . . . . . . . . . . 33 119 13.2. Informative References . . . . . . . . . . . . . . . . . 35 120 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 38 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 123 1. Introduction 125 The Path Computation Element (PCE) [RFC4655] was developed to offload 126 the path computation function from routers in an MPLS traffic- 127 engineered network. It can compute optimal paths for traffic across 128 a network and can also update the paths to reflect changes in the 129 network or traffic demands. Since then, the role and function of the 130 PCE has grown to cover a number of other uses (such as GMPLS 131 [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated 132 use of network resources [RFC8281]. 134 According to [RFC7399], Software-Defined Networking (SDN) refers to a 135 separation between the control elements and the forwarding components 136 so that software running in a centralized system, called a 137 controller, can act to program the devices in the network to behave 138 in specific ways. A required element in an SDN architecture is a 139 component that plans how the network resources will be used and how 140 the devices will be programmed. It is possible to view this 141 component as performing specific computations to place traffic flows 142 within the network given knowledge of the availability of network 143 resources, how other forwarding devices are programmed, and the way 144 that other flows are routed. This is the function and purpose of a 145 PCE, and the way that a PCE integrates into a wider network control 146 system (including an SDN system) is presented in [RFC7491]. 148 In early PCE implementations, where the PCE was used to derive paths 149 for MPLS Label Switched Paths (LSPs), paths were requested by network 150 elements (known as Path Computation Clients (PCCs)), and the results 151 of the path computations were supplied to network elements using the 152 Path Computation Element Communication Protocol (PCEP) [RFC5440]. 153 This protocol was later extended to allow a PCE to send unsolicited 154 requests to the network for LSP establishment [RFC8281]. 156 PCE was developed to derive paths for MPLS Label Switched Paths 157 (LSPs), which are supplied to the head end of the LSP using the Path 158 Computation Element Communication Protocol (PCEP). But SDN has a 159 broader applicability than signaled MPLS and GMPLS traffic-engineered 160 (TE) networks, and the PCE may be used to determine paths in a range 161 of use cases. PCEP has been proposed as a control protocol for use 162 in these environments to allow the PCE to be fully enabled as a 163 central controller. 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 device 179 along the path while leveraging the existing PCE technologies as much 180 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.ietf-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 [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 [RFC8283] examines the motivations and applicability for PCECC and 221 use of PCEP as an SBI. Section 3.1.2. of [RFC8283] highlights the 222 use of PCECC for label allocation along the static LSPs and it 223 simplifies the processing of a distributed control plane by blending 224 it with elements of SDN and without necessarily completely replacing 225 it. This allows the operator to introduce the advantages of SDN 226 (such as programmability) into the network. Further Section 3.3. of 227 [I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where 228 the PCECC technique could be useful. Section 4 of [RFC8283] also 229 describe the implications on the protocol when used as an SDN SBI. 230 The operator needs to evaluate the advantages offered by PCECC 231 against the operational and scalability needs of the PCECC. 233 As per Section 3.1.2. of [RFC8283], the PCE-based controller will 234 take responsibility for managing some part of the MPLS label space 235 for each of the routers that it controls, and may take wider 236 responsibility for partitioning the label space for each router and 237 allocating different parts for different uses. The PCC MUST NOT make 238 allocations from the label space set aside for the PCE to avoid 239 overlap and collisions of label allocations. It is RECOMMENDED that 240 PCE makes allocations (from the label space set aside for the PCE) 241 for all nodes along the path. For the purpose of this document, it 242 is assumed that the exclusive label range to be used by a PCE is 243 known and set on both PCEP peers. A future extension could add the 244 capability to advertise this range via a possible PCEP extension as 245 well (see [I-D.li-pce-controlled-id-space]). The rest of the 246 processing is similar to the existing stateful PCE mechanism. 248 This document also allows a case where the label space is maintained 249 by the PCC and the labels are allocated by it. In this case, the PCE 250 should request the allocation from PCC as described in Section 5.5.8. 252 4. PCEP Requirements 254 The following key requirements should be considered when designing 255 the PCECC-based solution: 257 1. A PCEP speaker supporting this document needs to have the 258 capability to advertise its PCECC capability to its peers. 260 2. A PCEP speaker need means to identify PCECC-based LSP in the PCEP 261 messages. 263 3. PCEP procedures need to allow for PCC-based label allocations. 265 4. PCEP procedures need to provide a means to update (or clean up) 266 label entries downloaded to the PCC. 268 5. PCEP procedures need to provide a means to synchronize the labels 269 between the PCE and the PCC via PCEP messages. 271 5. Procedures for Using the PCE as a Central Controller (PCECC) 273 5.1. Stateful PCE Model 275 Active stateful PCE is described in [RFC8231]. PCE as a central 276 controller (PCECC) reuses the existing active stateful PCE mechanism 277 as much as possible to control LSPs. 279 5.2. New LSP Functions 281 Several new functions are required in PCEP to support PCECC. This 282 document extends the existing messages to support the new functions 283 required by PCECC: 285 PCInitiate: a PCEP message described in [RFC8281]. PCInitiate 286 message is used to set up PCE-Initiated LSP based on PCECC 287 mechanism. It is also extended for Central Controller 288 Instructions (CCI) (download or clean up the Label forwarding 289 instructions in the context of this document) on all nodes along 290 the path as described in Section 6.1. 292 PCRpt: a PCEP message described in [RFC8231]. PCRpt message is used 293 to send PCECC LSP Reports. It is also extended to report the set 294 of Central Controller Instructions (CCI) (label forwarding 295 instructions in the context of this document) received from the 296 PCE as described in Section 6.2. Section 5.5.6 describes the use 297 of PCRpt message during synchronization. 299 PCUpd: a PCEP message described in [RFC8231]. PCUpd message is used 300 to send PCECC LSP Updates. 302 The new functions defined in this document are mapped onto the PCEP 303 messages as shown in Table 1. 305 Function Message 306 PCECC Capability advertisement Open 307 Label entry Add PCInitiate 308 Label entry Clean up PCInitiate 309 PCECC Initiated LSP PCInitiate 310 PCECC LSP Update PCUpd 311 PCECC LSP State Report PCRpt 312 PCECC LSP Delegation PCRpt 313 PCECC Label Report PCRpt 315 Table 1: Functions mapped to the PCEP messages 317 5.3. New PCEP Object 319 This document defines a new PCEP object called CCI (Section 7.3) to 320 specify the central controller instructions. In the scope of this 321 document, this is limited to Label forwarding instructions. Future 322 documents can create new CCI object-types for other types of central 323 controller instructions. The CC-ID is the unique identifier for the 324 central controller instructions in PCEP. The PCEP messages are 325 extended in this document to handle the PCECC operations. 327 5.4. PCECC Capability Advertisement 329 During the PCEP Initialization Phase, PCEP Speakers (PCE or PCC) 330 advertise their support of and willingness to use PCEP extensions for 331 PCECC using these elements in the OPEN message: 333 o A new Path Setup Type (PST) (Section 7.2) in the PATH-SETUP-TYPE- 334 CAPABILITY TLV to indicate support for PCEP extensions for PCECC - 335 TBD1 (Path is set up via PCECC mode) 337 o A new PCECC-CAPABILITY sub-TLV (Section 7.1.1) with the L bit set 338 to 1 inside the PATH-SETUP-TYPE-CAPABILITY TLV to indicate a 339 willingness to use PCEP extensions for PCECC based central 340 controller instructions for label download 342 o The STATEFUL-PCE-CAPABILITY TLV ([RFC8231]) (with the I flag set 343 [RFC8281]) 345 The new Path Setup Type is to be listed in the PATH-SETUP-TYPE- 346 CAPABILITY TLV by all PCEP speakers which support the PCEP extensions 347 for PCECC in this document. 349 The new PCECC-CAPABILITY sub-TLV is included in PATH-SETUP-TYPE- 350 CAPABILITY TLV in the OPEN object to indicate a willingness to use 351 the PCEP extensions for PCECC during the established PCEP session. 352 Using the L bit in this TLV, the PCE shows the intention to function 353 as a PCECC server, and the PCC shows a willingness to act as a PCECC 354 client for label download instructions (see Section 7.1.1). 356 If the PCECC-CAPABILITY sub-TLV is advertised and the STATEFUL-PCE- 357 CAPABILITY TLV is not advertised, or is advertised without the I flag 358 set, in the OPEN Object, the receiver MUST: 360 o Send a PCErr message with Error-Type=19 (Invalid Operation) and 361 Error-value=TBD4 (stateful PCE capability was not advertised) 363 o Terminate the session 365 If a PCEP speaker receives the PATH-SETUP-TYPE-CAPABILITY TLV with 366 the PCECC Path Setup Type but without the PCECC-CAPABILITY sub-TLV, 367 it MUST: 369 o Send a PCErr message with Error-Type 10 (Reception of an invalid 370 object) and Error-Value TBD2 (Missing PCECC-CAPABILITY sub-TLV) 372 o Terminate the PCEP session 374 The PCECC-CAPABILITY sub-TLV MUST NOT be used without the 375 corresponding Path Setup Type being listed in the PATH-SETUP-TYPE- 376 CAPABILITY TLV. If it is present without the corresponding Path 377 Setup Type listed in the PATH-SETUP-TYPE-CAPABILITY TLV, it MUST be 378 ignored. 380 If one or both speakers (PCE and PCC) have not indicated support and 381 willingness to use the PCEP extensions for PCECC, the PCEP extensions 382 for PCECC MUST NOT be used. If a PCECC operation is attempted when 383 both speakers have not agreed in the OPEN messages, the receiver of 384 the message MUST: 386 o Send a PCErr message with Error-Type=19 (Invalid Operation) and 387 Error-Value=TBD3 (Attempted PCECC operations when PCECC capability 388 was not advertised) 390 o Terminate the PCEP session 392 A legacy PCEP speaker (that does not recognize the PCECC Capability 393 sub-TLV) will ignore the sub-TLV in accordance with [RFC8408] and 394 [RFC5440]. As per [RFC8408], the legacy PCEP speaker on receipt of 395 an unsupported PST in RP (Request Parameter) /SRP (Stateful PCE 396 Request Parameters) Object will: 398 o Send a PCErr message with Error-Type = 21 (Invalid traffic 399 engineering path setup type) and Error-value = 1 (Unsupported path 400 setup type) 402 o Terminate the PCEP session 404 5.5. LSP Operations 406 The PCEP messages pertaining to a PCECC MUST include PATH-SETUP-TYPE 407 TLV [RFC8408] in the SRP object [RFC8231] with PST set to TBD1 to 408 clearly identify that PCECC LSP is intended. 410 5.5.1. PCE-Initiated PCECC LSP 412 The LSP Instantiation operation is defined in [RFC8281]. In order to 413 set up a PCE-Initiated LSP based on the PCECC mechanism, a PCE sends 414 PCInitiate message with PST set to TBD1 for PCECC (see Section 7.2) 415 to the ingress PCC. 417 The label forwarding instructions (see Section 5.5.3) from PCECC are 418 sent after the initial PCInitiate and PCRpt message exchange with the 419 ingress PCC as per [RFC8281] (see Figure 1). This is done so that 420 the PLSP-ID and other LSP identifiers can be obtained from the 421 ingress and can be included in the label forwarding instruction in 422 the next set of PCInitiate messages along the path as described 423 below. 425 An LSP-IDENTIFIERS TLV [RFC8231] MUST be included for PCECC LSPs, it 426 uniquely identifies the LSP in the network. Note that the fields in 427 the LSP-IDENTIFIERS TLV are described for the RSVP-signaled LSPs but 428 are applicable to the PCECC LSP as well. The LSP object is included 429 in the central controller instructions (label download Section 7.3) 430 to identify the PCECC LSP for this instruction. The PLSP-ID is the 431 original identifier used by the ingress PCC, so a transit/egress LSR 432 could have multiple central controller instructions that have the 433 same PLSP-ID. The PLSP-ID in combination with the source (in LSP- 434 IDENTIFIERS TLV) MUST be unique. The PLSP-ID is included for 435 maintainability reasons to ease debugging. As per [RFC8281], the LSP 436 object could also include the SPEAKER-ENTITY-ID TLV to identify the 437 PCE that initiated these instructions. Also, the CC-ID is unique in 438 each PCEP session as described in Section 7.3. 440 On receipt of PCInitiate message for the PCECC LSP, the PCC responds 441 with a PCRpt message with the status set to "GOING-UP" and carrying 442 the assigned PLSP-ID (see Figure 1). The ingress PCC also sets the D 443 (Delegate) flag (see [RFC8231]) and C (Create) flag (see [RFC8281]) 444 in the LSP object. When the PCE receives this PCRpt message with the 445 PLSP-ID, it assigns labels along the path; and sets up the path by 446 sending a PCInitiate message to each node along the path of the LSP 447 as per the PCECC technique. The CC-ID uniquely identifies the 448 central controller instruction within a PCEP session. Each node 449 along the path (PCC) responds with a PCRpt message to acknowledge the 450 central controller instruction with the PCRpt messages including the 451 central controller instruction (CCI) and the LSP objects. 453 The ingress node would receive one CCI object with O bit (out-label) 454 set. The transit node(s) would receive two CCI objects with the in- 455 label CCI without an O bit set and the out-label CCI with O bit set. 456 The egress node would receive one CCI object without O bit set (see 457 Figure 1). A node can determine its role based on the setting of the 458 O bit in the CCI object(s) and the LSP-IDENTIFIERS TLV in the LSP 459 object. 461 The LSP deletion operation for PCE-Initiated PCECC LSP is the same as 462 defined in [RFC8281]. The PCE should further perform Label entry 463 clean up operation as described in Section 5.5.3.2 for the 464 corresponding LSP. 466 The PCE-Initiated PCECC LSP setup sequence is shown in Figure 1. 468 +-------+ +-------+ 469 |PCC | | PCE | 470 |ingress| +-------+ 471 +------| | | 472 | PCC +-------+ | 473 | transit| | | 474 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1------| PCECC LSP 475 |PCC +--------+ | | Initiate 476 |egress | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| PCECC LSP 477 +--------+ | | (GOING-UP) | 478 | | | | 479 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 480 | | | | download 481 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 482 | | | | 483 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2-----| Label 484 | | | | download 485 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=2--------->| CCI 486 | | | | 487 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 488 | | | | download 489 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 490 | | | | 491 | | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC LSP 492 | | | (UP) | Update 493 | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| 494 | | | (UP) | 496 Figure 1: PCE-Initiated PCECC LSP 498 Once the label operations are completed, the PCE MUST send a PCUpd 499 message to the ingress PCC. The PCUpd message is as per [RFC8231] 500 with D flag set. 502 The PCECC LSPs are considered to be 'up' by default (on receipt of 503 PCUpd message from PCE). The ingress could further choose to deploy 504 a data plane check mechanism and report the status back to the PCE 505 via a PCRpt message to make sure that the correct label instructions 506 are made along the path of the PCECC LSP (and it is ready to carry 507 traffic). The exact mechanism is out of scope of this document. 509 In the case where the label allocations are made by the PCC itself 510 (see Section 5.5.8), the PCE could request an allocation to be made 511 by the PCC, and then the PCC would send a PCRpt with the allocated 512 label encoded in the CC-ID object as shown in Figure 2 in the 513 configuration sequence from the egress towards the ingress along the 514 path. 516 +-------+ +-------+ 517 |PCC | | PCE | 518 |ingress| +-------+ 519 +------| | | 520 | PCC +-------+ | 521 | transit| | | 522 +------| | |<--PCInitiate,PLSP-ID=0,PST=TBD1,-----| PCECC LSP 523 |PCC +--------+ | | Initiate 524 |egress | | |----PCRpt,PLSP-ID=2,D=1,C=1---------->| PCECC LSP 525 +--------+ | | (GOING-UP) | 526 | | | | 527 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 528 | | | C=1,O=0 | download 529 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 530 | | | Label=L1 | 531 | |<------PCInitiate,PLSP-ID=2,----------------| Labels 532 | | | CC-ID=Y1,C=1,O=0 | download 533 | | | CC-ID=Y2,C=0,O=1,L1 | CCI 534 | |-------PCRpt,PLSP-ID=2--------------------->| 535 | | | CC-ID=Y1,O=0,Label=L2 | 536 | | | CC-ID=Y2,O=1 | 537 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 538 | | | C=0,O=1,L2 | download 539 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 540 | | | | 541 | | |<---PCUpd,PLSP-ID=2,PST=TBD1,D=1------| PCECC LSP 542 | | | (UP) | Update 544 Figure 2: PCE-Initiated PCECC LSP (PCC allocation) 546 It should be noted that in this example, the request is made to the 547 egress node with the C bit set in the CCI object to indicate that the 548 label allocation needs to be done by the egress and the egress 549 responds with the allocated label to the PCE. The PCE further inform 550 the transit PCC without setting the C bit to 1 in the CCI object for 551 out-label but the C bit is set to 1 for in-label so the transit node 552 make the label allocation (for the in-label) and report to the PCE. 553 Similarly, the C bit is unset towards the ingress to complete all the 554 label allocation for the PCECC LSP. 556 5.5.2. PCC-Initiated PCECC LSP 558 In order to set up an LSP based on the PCECC mechanism where the LSP 559 is configured at the PCC, a PCC MUST delegate the LSP by sending a 560 PCRpt message with PST set for PCECC (see Section 7.2) and D 561 (Delegate) flag (see [RFC8231]) set in the LSP object (see Figure 3). 563 When a PCE receives the initial PCRpt message with D flag and PST 564 Type set to TBD1, it SHOULD calculate the path and assigns labels 565 along the path; and sets up the path by sending a PCInitiate message 566 to each node along the path of the LSP as per the PCECC technique 567 (see Figure 3). The CC-ID uniquely identifies the central controller 568 instruction within a PCEP session. Each PCC further responds with 569 the PCRpt messages including the central controller instruction (CCI) 570 and the LSP objects. 572 Once the central controller instructions (label operations) are 573 completed, the PCE MUST send the PCUpd message to the ingress PCC. 574 As per [RFC8231], this PCUpd message should include the path 575 information calculated by the PCE. 577 Note that the PCECC LSPs MUST be delegated to a PCE at all times. 579 The LSP deletion operation for PCECC LSPs is the same as defined in 580 [RFC8231]. If the PCE receives a PCRpt message for LSP deletion then 581 it does label clean up operation as described in Section 5.5.3.2 for 582 the corresponding LSP. 584 The Basic PCECC LSP setup sequence is as shown in Figure 3. 586 +-------+ +-------+ 587 |PCC | | PCE | 588 |ingress| +-------+ 589 +------| | | 590 | PCC +-------+ | 591 | transit| | | 592 +------| | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| PCECC LSP 593 |PCC +--------+ | | 594 |egress | | | | 595 +--------+ | | | 596 | | | | 597 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 598 | | | L1,O=0 | download 599 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 600 | | | | 601 | |<------PCInitiate,PLSP-ID=1,---------------| Labels 602 | | | CC-ID=Y1,O=0,L2 | download 603 | | | CC-ID=Y2,O=1,L1 | CCI 604 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=1-------->| 605 | | | | 606 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 607 | | | L2,O=1 | download 608 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 609 | | | | 610 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC LSP 611 | | | | Update 612 | | | | 614 Figure 3: PCC-Initiated PCECC LSP 616 In the case where the label allocations are made by the PCC itself 617 (see Section 5.5.8), the PCE could request an allocation to be made 618 by the PCC, and then the PCC would send a PCRpt with the allocated 619 label encoded in the CC-ID object as shown in Figure 4. 621 +-------+ +-------+ 622 |PCC | | PCE | 623 |ingress| +-------+ 624 +------| | | 625 | PCC +-------+ | 626 | transit| | | 627 +------| | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| PCECC LSP 628 |PCC +--------+ | | 629 |egress | | | | 630 +--------+ | | | 631 | | | | 632 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 633 | | | C=1 | download 634 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 635 | | | Label=L1 | 636 | |<------PCInitiate,PLSP-ID=1,---------------| Labels 637 | | | CC-ID=Y1,C=1 | download 638 | | | CC-ID=Y2,C=0,L1 | CCI 639 | |-------PCRpt,PLSP-ID=1-------------------->| 640 | | | CC-ID=Y1,Label=L2 | 641 | | | CC-ID=Y2 | 642 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 643 | | | C=0,L2 | download 644 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 645 | | | | 646 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC LSP 647 | | | | Update 648 | | | | 650 - The O bit is set as before (and thus not included) 652 Figure 4: PCC-Initiated PCECC LSP (PCC allocation) 654 In the case where the label allocations are made by the PCC itself 655 (see Section 5.5.8), the procedure remains the same, with just an 656 additional constraint on the configuration sequence. 658 The rest of the PCC-Initiated PCECC LSP setup operations are the same 659 as those described in Section 5.5.1. 661 5.5.3. Central Controller Instructions 663 The new central controller instructions (CCI) for the label 664 operations in PCEP are done via the PCInitiate message (Section 6.1), 665 by defining a new PCEP Object for CCI operations. The local label 666 range of each PCC is assumed to be known by both the PCC and the PCE. 668 5.5.3.1. Label Download CCI 670 In order to set up an LSP based on PCECC, the PCE sends a PCInitiate 671 message to each node along the path to download the Label instruction 672 as described in Section 5.5.1 and Section 5.5.2. 674 The CCI object MUST be included, along with the LSP object in the 675 PCInitiate message. The LSP-IDENTIFIERS TLV MUST be included in the 676 LSP object. The SPEAKER-ENTITY-ID TLV SHOULD be included in the LSP 677 object. 679 If a node (PCC) receives a PCInitiate message which includes a Label 680 to download, as part of CCI, that is out of the range set aside for 681 the PCE, it MUST send a PCErr message with Error-type=TBD5 (PCECC 682 failure) and Error-value=TBD6 (Label out of range) and MUST include 683 the SRP object to specify the error is for the corresponding label 684 update via PCInitiate message. If a PCC receives a PCInitiate 685 message but fails to download the Label entry, it MUST send a PCErr 686 message with Error-type=TBD5 (PCECC failure) and Error-value=TBD7 687 (instruction failed) and MUST include the SRP object to specify the 688 error is for the corresponding label update via PCInitiate message. 690 A new PCEP object for central controller instructions (CCI) is 691 defined in Section 7.3. 693 5.5.3.2. Label Clean up CCI 695 In order to delete an LSP based on PCECC, the PCE sends a central 696 controller instructions via a PCInitiate message to each node along 697 the path of the LSP to clean up the Label forwarding instruction. 699 If the PCC receives a PCInitiate message but does not recognize the 700 label in the CCI, the PCC MUST generate a PCErr message with Error- 701 Type 19(Invalid operation) and Error-Value=TBD8, "Unknown Label" and 702 MUST include the SRP object to specify the error is for the 703 corresponding label clean up (via PCInitiate message). 705 The R flag in the SRP object defined in [RFC8281] specifies the 706 deletion of Label Entry in the PCInitiate message. 708 +-------+ +-------+ 709 |PCC | | PCE | 710 |ingress| +-------+ 711 +------| | | 712 | PCC +-------+ | 713 | transit| | | 714 +------| | | | 715 |PCC +--------+ | | 716 |egress | | | | 717 +--------+ | | | 718 | | | | 719 |<-------PCInitiate,CC-ID=X,PLSP-ID=2----------------| Label 720 | | | R=1 | clean up 721 |--------PCRpt,CC-ID=X,PLSP-ID=2-------------------->| CCI 722 | | | R=1 | 723 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=2-----| Label 724 | | | R=1 | clean up 725 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=2--------->| CCI 726 | | | R=1 | 727 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=2-----| Label 728 | | | R=1 | clean up 729 | | |-----PCRpt,CC-ID=Z,PLSP-ID=2--------->| CCI 730 | | | R=1 | 731 | | |<--PCInitiate,PLSP-ID=2,PST=TBD1,R=1--| PCECC LSP 732 | | | | remove 734 Figure 5: Label Cleanup 736 As per [RFC8281], following the removal of the Label forwarding 737 instruction, the PCC MUST send a PCRpt message. The SRP object in 738 the PCRpt MUST include the SRP-ID-number from the PCInitiate message 739 that triggered the removal. The R flag in the SRP object MUST be 740 set. 742 In the case where the label allocation is made by the PCC itself (see 743 Section 5.5.8), the removal procedure remains the same, adding the 744 sequence constraint. 746 5.5.4. PCECC LSP Update 748 The update is done as per the make-before-break procedures, i.e. the 749 PCECC first updates new label instructions based on the updated path 750 and then informs the ingress to switch traffic, before cleaning up 751 the former instructions. New CC-IDs are used to identify the updated 752 instructions; the identifiers in the LSP object uniquely identify the 753 existing LSP. Once new instructions are downloaded, the PCE further 754 updates the new path at the ingress which triggers the traffic switch 755 on the updated path. The ingress PCC acknowledges with a PCRpt 756 message, on receipt of the PCRpt message, the PCE does clean up 757 operation for the former LSP as described in Section 5.5.3.2. 759 The PCECC LSP Update sequence is shown in Figure 6. 761 +-------+ +-------+ 762 |PCC | | PCE | 763 |ingress| +-------+ 764 +------| | | 765 | PCC +-------+ | 766 | transit| | | 767 +------| | | | 768 |PCC +--------+ | | 769 |egress | | | | 770 +--------+ | | | 771 | | | | New Path 772 |<------ PCInitiate,CC-ID=XX,PLSP-ID=1 -------------| for LSP 773 | | | | trigger 774 |--------PCRpt,CC-ID=XX,PLSP-ID=1------------------>| new CCI 775 | | | | 776 | |<------PCInitiate,CC-ID=YY1,YY2,PLSP-ID=1--| Label 777 | | | | download 778 | |-------PCRpt,CC-ID=YY1,YY2,PLSP-ID=1------>| CCI 779 | | | | 780 | | |<----PCInitiate,CC-ID=ZZ,PLSP-ID=1---| Label 781 | | | | download 782 | | |-----PCRpt,CC-ID=ZZ,PLSP-ID=1------->| CCI 783 | | | | 784 | | |<---PCUpd,PLSP-ID=1,PST=TBD1,D=1-----| PCECC 785 | | | SRP=S | LSP Update 786 | | | | 787 | | |---PCRpt,PLSP-ID=1,PST=TBD1,D=1----->| Trigger 788 | | | (SRP=S) | Delete 789 | | | | former CCI 790 | | | | 791 |<-------PCInitiate,CC-ID=X,PLSP-ID=1---------------| Label 792 | | | R=1 | clean up 793 |--------PCRpt,CC-ID=X,PLSP-ID=1------------------->| CCI 794 | | | R=1 | 795 | |<------PCInitiate,CC-ID=Y1,Y2,PLSP-ID=1----| Label 796 | | | R=1 | clean up 797 | |-------PCRpt,CC-ID=Y1,Y2,PLSP-ID=1-------->| CCI 798 | | | R=1 | 799 | | |<----PCInitiate,CC-ID=Z,PLSP-ID=1----| Label 800 | | | R=1 | clean up 801 | | |-----PCRpt,CC-ID=Z,PLSP-ID=1-------->| CCI 802 | | | R=1 | 804 Figure 6: PCECC LSP Update 806 The modified PCECC LSPs are considered to be 'up' by default. The 807 ingress could further choose to deploy a data plane check mechanism 808 and report the status back to the PCE via a PCRpt message. The exact 809 mechanism is out of scope of this document. 811 In the case where the label allocations are made by the PCC itself 812 (see Section 5.5.8), the procedure remains the same. 814 5.5.5. Re-Delegation and Clean up 816 As described in [RFC8281], a new PCE can gain control over an 817 orphaned LSP. In the case of a PCECC LSP, the new PCE MUST also gain 818 control over the central controller instructions in the same way by 819 sending a PCInitiate message that includes the SRP, LSP, and CCI 820 objects and carries the CC-ID and PLSP-ID identifying the instruction 821 that it wants to take control of. 823 Further, as described in [RFC8281], the State Timeout Interval timer 824 ensures that a PCE crash does not result in automatic and immediate 825 disruption for the services using PCE-initiated LSPs. Similarly the 826 central controller instructions are not removed immediately upon PCE 827 failure. Instead, they are cleaned up on the expiration of this 828 timer. This allows for network clean up without manual intervention. 829 The PCC MUST support the removal of CCI as one of the behaviors 830 applied on expiration of the State Timeout Interval timer. 832 In case of PCC-initiated PCECC LSP, the control over the orphaned LSP 833 at the ingress PCC is taken over by the mechanism specified in 834 [RFC8741] to request delegation. The control over the central 835 controller instructions is described above using [RFC8281]. 837 5.5.6. Synchronization of Central Controllers Instructions 839 The purpose of Central Controllers Instructions synchronization 840 (labels in the context of this document) is to make sure that the 841 PCE's view of CCI (Labels) matches with the PCC's Label allocation. 842 This synchronization is performed as part of the LSP state 843 synchronization as described in [RFC8231] and [RFC8232]. 845 As per LSP State Synchronization [RFC8231], a PCC reports the state 846 of its LSPs to the PCE using PCRpt messages and as per [RFC8281], PCE 847 would initiate any missing LSPs and/or remove any LSPs that are not 848 wanted. The same PCEP messages and procedures are also used for the 849 Central Controllers Instructions synchronization. The PCRpt message 850 includes the CCI and the LSP object to report the label forwarding 851 instructions. The PCE would further remove any unwanted instructions 852 or initiate any missing instructions. 854 5.5.7. PCECC LSP State Report 856 As mentioned before, an ingress PCC MAY choose to apply any OAM 857 mechanism to check the status of LSP in the Data plane and MAY 858 further send its status in a PCRpt message to the PCE. 860 5.5.8. PCC-Based Allocations 862 The PCE can request the PCC to allocate the label using the 863 PCInitiate message. The C flag in the CCI object is set to 1 to 864 indicate that the allocation needs to be done by the PCC. The PCC 865 MUST try to allocate the Label and MUST report to the PCE via PCRpt 866 or PCErr message. 868 If the value of the Label is 0 and the C flag is set to 1, it 869 indicates that the PCE is requesting the allocation to be done by the 870 PCC. If the Label is 'n' and the C flag is set to 1 in the CCI 871 object, it indicates that the PCE requests a specific value 'n' for 872 the Label. If the allocation is successful, the PCC MUST report via 873 the PCRpt message with the CCI object. If the value of the Label in 874 the CCI object is invalid, it MUST send a PCErr message with Error- 875 Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid CCI"). 876 If it is valid but the PCC is unable to allocate it, it MUST send a 877 PCErr message with Error-Type = TBD5 ("PCECC failure") and Error 878 Value = TBD10 ("Unable to allocate the specified CCI"). 880 If the PCC wishes to withdraw or modify the previously assigned 881 label, it MUST send a PCRpt message without any Label or with the 882 Label containing the new value respectively in the CCI object. The 883 PCE would further trigger the Label cleanup of older label as per 884 Section 5.5.3.2. 886 6. PCEP Messages 888 As defined in [RFC5440], a PCEP message consists of a common header 889 followed by a variable-length body made of a set of objects that can 890 be either mandatory or optional. An object is said to be mandatory 891 in a PCEP message when the object must be included for the message to 892 be considered valid. For each PCEP message type, a set of rules is 893 defined that specify the set of objects that the message can carry. 894 An implementation MUST form the PCEP messages using the object 895 ordering specified in this document. 897 LSP-IDENTIFIERS TLV MUST be included in the LSP object for PCECC LSP. 899 The message formats in this document are specified using Routing 900 Backus-Naur Form (RBNF) encoding as specified in [RFC5511]. 902 6.1. The PCInitiate Message 904 The PCInitiate message [RFC8281] can be used to download or remove 905 the labels, this document extends the message as shown below - 907 ::= 908 909 Where: 910 is defined in [RFC5440] 912 ::= 913 [] 915 ::= 916 (| 917 | 918 ) 920 ::= 921 922 924 ::= 925 [] 927 Where: 928 and 929 are as per 930 [RFC8281]. 932 The LSP and SRP object is defined in [RFC8231]. 934 When PCInitiate message is used for the central controller 935 instructions (labels), the SRP, LSP, and CCI objects MUST be present. 936 The SRP object is defined in [RFC8231] and if the SRP object is 937 missing, the receiving PCC MUST send a PCErr message with Error- 938 type=6 (Mandatory Object missing) and Error-value=10 (SRP object 939 missing). The LSP object is defined in [RFC8231] and if the LSP 940 object is missing, the receiving PCC MUST send a PCErr message with 941 Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object 942 missing). The CCI object is defined in Section 7.3 and if the CCI 943 object is missing, the receiving PCC MUST send a PCErr message with 944 Error-type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI 945 object missing). More than one CCI object MAY be included in the 946 PCInitiate message for a transit LSR. 948 To clean up entries, the R (remove) bit MUST be set in the SRP object 949 to be encoded along with the LSP and the CCI object. 951 The CCI object received at the ingress node MUST have the O bit (out- 952 label) set. The CCI Object received at the egress MUST have the O 953 bit unset. If this is not the case, PCC MUST send a PCErr message 954 with Error-Type = TBD5 ("PCECC failure") and Error Value = TBD9 955 ("Invalid CCI"). Other instances of the CCI object if present, MUST 956 be ignored. 958 For the P2P LSP setup via PCECC technique, at the transit LSR two CCI 959 objects are expected for in-coming and outgoing label associated with 960 the LSP object. If any other CCI object is included in the 961 PCInitiate message, it MUST be ignored. If the transit LSR did not 962 receive two CCI object with one of them having the O bit set and 963 another with O bit unset, it MUST send a PCErr message with Error- 964 Type = TBD5 ("PCECC failure") and Error Value = TBD9 ("Invalid CCI"). 966 Note that, on receipt of the PCInitiate message with CCI object, the 967 ingress, egress, or transit role of the PCC is identified via the 968 ingress and egress IP address encoded in the LSP-IDENTIFIERS TLV. 970 6.2. The PCRpt Message 972 The PCRpt message can be used to report the labels that were 973 allocated by the PCE, to be used during the state synchronization 974 phase or as an acknowledgment to PCInitiate message. 976 ::= 977 978 Where: 980 ::= [] 982 ::= (| 983 ) 985 ::= [] 986 987 989 ::= [] 990 991 993 ::= 994 [] 996 Where: 997 is as per [RFC8231] and the LSP and SRP object are 998 also defined in [RFC8231]. 1000 When PCRpt message is used to report the central controller 1001 instructions (labels), the LSP and CCI objects MUST be present. The 1002 LSP object is defined in [RFC8231] and if the LSP object is missing, 1003 the receiving PCE MUST send a PCErr message with Error-type=6 1004 (Mandatory Object missing) and Error-value=8 (LSP object missing). 1005 The CCI object is defined in Section 7.3 and if the CCI object is 1006 missing, the receiving PCE MUST send a PCErr message with Error- 1007 type=6 (Mandatory Object missing) and Error-value=TBD11 (CCI object 1008 missing). Two CCI objects can be included in the PCRpt message for a 1009 transit LSR. 1011 7. PCEP Objects 1013 The PCEP objects defined in this document are compliant with the PCEP 1014 object format defined in [RFC5440]. 1016 7.1. OPEN Object 1018 This document defines a new PST (TBD1) to be included in the PATH- 1019 SETUP-TYPE-CAPABILITY TLV in the OPEN Object. Further, a new sub-TLV 1020 for PCECC capability exchange is also defined. 1022 7.1.1. PCECC Capability sub-TLV 1024 The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN 1025 Object in the PATH-SETUP-TYPE-CAPABILITY TLV, when the Path Setup 1026 Type list includes the PCECC Path Setup Type TBD1. A PCECC- 1027 CAPABILITY sub-TLV MUST be ignored if the PST list does not contain 1028 PST=TBD1. 1030 Its format is shown in Figure 7. 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Type=TBD12 | Length=4 | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Flags |L| 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 Figure 7: PCECC Capability sub-TLV 1042 The type of the TLV is TBD12 and it has a fixed length of 4 octets. 1044 The value comprises a single field - Flags (32 bits). Currently, the 1045 following flag bit is defined: 1047 o L bit (Label): if set to 1 by a PCEP speaker, the L flag indicates 1048 that the PCEP speaker support and is willing to handle the PCECC 1049 based central controller instructions for label download. The bit 1050 MUST be set to 1 by both a PCC and a PCE for the PCECC label 1051 download/report on a PCEP session. 1053 o Unassigned bits MUST be set to 0 on transmission and MUST be 1054 ignored on receipt. 1056 7.2. PATH-SETUP-TYPE TLV 1058 The PATH-SETUP-TYPE TLV is defined in [RFC8408]; this document 1059 defines a new PST value: 1061 o PST = TBD1: Path is set up via PCECC mode. 1063 On a PCRpt/PCUpd/PCInitiate message, the PST=TBD1 in the PATH-SETUP- 1064 TYPE TLV in the SRP object MUST be included for a LSP set up via the 1065 PCECC-based mechanism. 1067 7.3. CCI Object 1069 The Central Controller Instructions (CCI) Object is used by the PCE 1070 to specify the forwarding instructions (Label information in the 1071 context of this document) to the PCC, and MAY be carried within 1072 PCInitiate or PCRpt message for label download/report. 1074 CCI Object-Class is TBD13. 1076 CCI Object-Type is 1 for the MPLS Label. 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | CC-ID | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Reserved1 | Flags |C|O| 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Label | Reserved2 | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | | 1088 // Optional TLV // 1089 | | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 Figure 8: CCI Object 1094 The fields in the CCI object are as follows: 1096 CC-ID: A PCEP-specific identifier for the CCI information. A PCE 1097 creates a CC-ID for each instruction, the value is unique within 1098 the scope of the PCE and is constant for the lifetime of a PCEP 1099 session. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be 1100 used. Note that [I-D.gont-numeric-ids-sec-considerations] gives 1101 advice on assigning transient numeric identifiers such as the CC- 1102 ID so as to minimize security risks. 1104 Reserved1 (16 bit): Set to zero while sending, ignored on receive. 1106 Flags (16 bit): A field used to carry any additional information 1107 pertaining to the CCI. Currently, the following flag bits are 1108 defined: 1110 * O bit(Out-label) : If the bit is set to 1, it specifies the 1111 label is the OUT label and it is mandatory to encode the next- 1112 hop information (via Address TLVs Section 7.3.1 in the CCI 1113 object). If the bit is not set, it specifies the label is the 1114 IN label and it is optional to encode the local interface 1115 information (via Address TLVs in the CCI object). 1117 * C Bit (PCC Allocation): If the bit is set to 1, it indicates 1118 that the label allocation needs to be done by the PCC for this 1119 central controller instruction. A PCE sets this bit to request 1120 the PCC to make an allocation from its label space. A PCC 1121 would set this bit to indicate that it has allocated the label 1122 and report it to the PCE. 1124 * All unassigned bits MUST be set to zero at transmission and 1125 ignored at receipt. 1127 Label (20-bit): The Label information. 1129 Reserved2 (12 bit): Set to zero while sending, ignored on receive. 1131 7.3.1. Address TLVs 1133 [RFC8779] defines IPV4-ADDRESS, IPV6-ADDRESS, and UNNUMBERED-ENDPOINT 1134 TLVs for the use of Generalized Endpoint. The same TLVs can also be 1135 used in the CCI object to associate the next-hop information in the 1136 case of an outgoing label and local interface information in the case 1137 of an incoming label. The next-hop information encoded in these TLVs 1138 needs to be a directly connected IP address/interface information. 1139 If the PCC is not able to resolve the next-hop information, it MUST 1140 reject the CCI and respond with a PCErr message with Error-Type = 1141 TBD5 ("PCECC failure") and Error Value = TBD15 ("Invalid next-hop 1142 information"). 1144 8. Implementation Status 1146 [Note to the RFC Editor - remove this section before publication, as 1147 well as remove the reference to RFC 7942.] 1149 This section records the status of known implementations of the 1150 protocol defined by this specification at the time of posting of this 1151 Internet-Draft, and is based on a proposal described in [RFC7942]. 1152 The description of implementations in this section is intended to 1153 assist the IETF in its decision processes in progressing drafts to 1154 RFCs. Please note that the listing of any individual implementation 1155 here does not imply endorsement by the IETF. Furthermore, no effort 1156 has been spent to verify the information presented here that was 1157 supplied by IETF contributors. This is not intended as, and must not 1158 be construed to be, a catalog of available implementations or their 1159 features. Readers are advised to note that other implementations may 1160 exist. 1162 According to [RFC7942], "this will allow reviewers and working groups 1163 to assign due consideration to documents that have the benefit of 1164 running code, which may serve as evidence of valuable experimentation 1165 and feedback that have made the implemented protocols more mature. 1166 It is up to the individual working groups to use this information as 1167 they see fit". 1169 8.1. Huawei's Proof of Concept based on ONOS 1171 The PCE function was developed in the ONOS open source platform. 1172 This extension was implemented on a private version as a proof of 1173 concept for PCECC. 1175 o Organization: Huawei 1177 o Implementation: Huawei's PoC based on ONOS 1179 o Description: PCEP as a southbound plugin was added to ONOS. To 1180 support PCECC, an earlier version of this I-D was implemented. 1181 Refer https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 1183 o Maturity Level: Prototype 1185 o Coverage: Partial 1187 o Contact: satishk@huawei.com 1189 9. Security Considerations 1191 As per [RFC8283], the security considerations for a PCE-based 1192 controller is a little different from those for any other PCE system. 1193 That is, the operation relies heavily on the use and security of 1194 PCEP, so consideration should be given to the security features 1195 discussed in [RFC5440] and the additional mechanisms described in 1196 [RFC8253]. It further lists the vulnerability of a central 1197 controller architecture, such as a central point of failure, denial- 1198 of-service, and a focus for interception and modification of messages 1199 sent to individual NEs. 1201 In PCECC operations, the PCEP sessions are also required to the 1202 internal routers and thus increasing the resources required for the 1203 session management at the PCE. 1205 The PCECC extension builds on the existing PCEP messages and thus the 1206 security considerations described in [RFC5440], [RFC8231] and 1207 [RFC8281] continue to apply. [RFC8253] specify the support of 1208 Transport Layer Security (TLS) in PCEP, as it provides support for 1209 peer authentication, message encryption, and integrity. It further 1210 provide mechanisms for associating peer identities with different 1211 levels of access and/or authoritativeness via an attribute in X.509 1212 certificates or a local policy with a specific accept-list of X.509 1213 certificate. This can be used to check the authority for the PCECC 1214 operations. Additional considerations are discussed in following 1215 sections. 1217 9.1. Malicious PCE 1219 In this extension, the PCE has complete control over the PCC to 1220 download/remove the labels and can cause the LSP's to behave 1221 inappropriately and cause a major impact to the network. As a 1222 general precaution, it is RECOMMENDED that this PCEP extension be 1223 activated on mutually-authenticated and encrypted sessions across 1224 PCEs and PCCs belonging to the same administrative authority, using 1225 TLS [RFC8253], as per the recommendations and best current practices 1226 in BCP 195 [RFC7525]. 1228 Further, an attacker may flood the PCC with PCECC related messages at 1229 a rate that exceeds either the PCC's ability to process them or the 1230 network's ability to send them, by either spoofing messages or 1231 compromising the PCE itself. [RFC8281] provides a mechanism to 1232 protect the PCC by imposing a limit. The same can be used for the 1233 PCECC operations as well. 1235 As specified in Section 5.5.3.1, a PCC needs to check if the label in 1236 the CCI object is in the range set aside for the PCE, otherwise it 1237 MUST send a PCErr message with Error-type=TBD5 (PCECC failure) and 1238 Error-value=TBD6 (Label out of range). 1240 9.2. Malicious PCC 1242 The PCECC mechanism described in this document requires the PCE to 1243 keep labels (CCI) that it downloads and relies on the PCC responding 1244 (with either an acknowledgment or an error message) to requests for 1245 LSP instantiation. This is an additional attack surface by placing a 1246 requirement for the PCE to keep a CCI/label replica for each PCC. It 1247 is RECOMMENDED that PCE implementations provide a limit on resources 1248 (in this case the CCI) a single PCC can occupy. [RFC8231] provides a 1249 notification mechanism when such threshold is reached. 1251 10. Manageability Considerations 1253 10.1. Control of Function and Policy 1255 A PCE or PCC implementation SHOULD allow the PCECC capability to be 1256 enabled/disabled as part of the global configuration. Section 6.1 of 1257 [RFC8664] list various controlling factors regarding path setup type. 1259 They are also applicable to the PCECC path setup types. Further, 1260 Section 6.2 of [RFC8664] describe the migration steps when path setup 1261 type of an existing LSP is changed. 1263 10.2. Information and Data Models 1265 [RFC7420] describes the PCEP MIB, this MIB can be extended to get the 1266 PCECC capability status. 1268 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 1269 enable/disable PCECC capability. 1271 10.3. Liveness Detection and Monitoring 1273 Mechanisms defined in this document do not imply any new liveness 1274 detection and monitoring requirements in addition to those already 1275 listed in [RFC5440]. 1277 10.4. Verify Correct Operations 1279 The operator needs the following information to verify that PCEP is 1280 operating correctly with respect to the PCECC path setup type. 1282 o An implementation SHOULD allow the operator to view whether the 1283 PCEP speaker sent the PCECC PST capability to its peer. 1285 o An implementation SHOULD allow the operator to view whether the 1286 peer sent the PCECC PST capability. 1288 o An implementation SHOULD allow the operator to view whether the 1289 PCECC PST is enabled on a PCEP session. 1291 o If one PCEP speaker advertises the PCECC PST capability, but the 1292 other does not, then the implementation SHOULD create a log to 1293 inform the operator of the capability mismatch. 1295 o If a PCEP speaker rejects a CCI, then it SHOULD create a log to 1296 inform the operator, giving the reason for the decision (local 1297 policy, Label issues, etc.). 1299 10.5. Requirements On Other Protocols 1301 PCEP extensions defined in this document do not put new requirements 1302 on other protocols. 1304 10.6. Impact On Network Operations 1306 PCEP extensions defined in this document do not put new requirements 1307 on network operations. 1309 11. IANA Considerations 1311 11.1. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 1313 [RFC8408] requested the creation of "PATH-SETUP-TYPE-CAPABILITY Sub- 1314 TLV Type Indicators" sub-registry. Further IANA is requested to 1315 allocate the following code-point: 1317 Value Meaning Reference 1318 TBD12 PCECC-CAPABILITY This document 1320 11.2. PCECC-CAPABILITY sub-TLV's Flag field 1322 This document defines the PCECC-CAPABILITY sub-TLV and requests that 1323 IANA to create a new sub-registry to manage the value of the PCECC- 1324 CAPABILITY sub-TLV's 32-bits Flag field. New values are to be 1325 assigned by Standards Action [RFC8126]. Each bit should be tracked 1326 with the following qualities: 1328 o Bit number (counting from bit 0 as the most significant bit) 1330 o Capability description 1332 o Defining RFC 1334 Currently, there is one allocation in this registry. 1336 Bit Name Reference 1337 31 Label This document 1338 0-30 Unassigned This document 1340 11.3. Path Setup Type Registry 1342 [RFC8408] created a sub-registry within the "Path Computation Element 1343 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 1344 IANA is requested to allocate a new code point within this registry, 1345 as follows: 1347 Value Description Reference 1348 TBD1 Traffic engineering path is This document 1349 set up using PCECC mode 1351 11.4. PCEP Object 1353 IANA is requested to allocate new code-point in the "PCEP Objects" 1354 sub-registry for the CCI object as follows: 1356 Object-Class Value Name Reference 1357 TBD13 CCI Object-Type This document 1358 0 Reserved 1359 1 MPLS Label 1361 11.5. CCI Object Flag Field 1363 IANA is requested to create a new sub-registry to manage the Flag 1364 field of the CCI object called "CCI Object Flag Field for MPLS 1365 Label". New values are to be assigned by Standards Action [RFC8126]. 1366 Each bit should be tracked with the following qualities: 1368 o Bit number (counting from bit 0 as the most significant bit) 1370 o Capability description 1372 o Defining RFC 1374 Two bits to be defined for the CCI Object flag field in this document 1375 as follows: 1377 Bit Description Reference 1378 0-13 Unassigned This document 1379 14 C Bit - PCC allocation This document 1380 15 O Bit - Specifies label This document 1381 is out-label 1383 11.6. PCEP-Error Object 1385 IANA is requested to allocate new error types and error values within 1386 the "PCEP-ERROR Object Error Types and Values" sub-registry of the 1387 PCEP Numbers registry for the following errors: 1389 Error-Type Meaning 1390 ---------- ------- 1391 6 Mandatory Object missing. 1393 Error-value = TBD11 : CCI object missing 1395 10 Reception of an invalid object. 1397 Error-value = TBD2 : Missing PCECC 1398 Capability sub-TLV 1399 19 Invalid operation. 1401 Error-value = TBD3 : Attempted PCECC 1402 operations when 1403 PCECC capability 1404 was not advertised 1405 Error-value = TBD4 : Stateful PCE 1406 capability was not 1407 advertised 1408 Error-value = TBD8 : Unknown Label 1410 TBD5 PCECC failure. 1412 Error-value = TBD6 : Label out of range. 1413 Error-value = TBD7 : Instruction failed. 1414 Error-value = TBD9 : Invalid CCI. 1415 Error-value = TBD10 : Unable to allocate 1416 the specified CCI. 1417 Error-value = TBD15 : Invalid next-hop 1418 information. 1420 12. Acknowledgments 1422 We would like to thank Robert Tao, Changjing Yan, Tieying Huang, 1423 Avantika, and Aijun Wang for their useful comments and suggestions. 1425 Thanks to Julien Meuric for shepherding this I-D and providing 1426 valuable comments. Thanks to Deborah Brungard for being the 1427 responsible AD. 1429 Thanks to Victoria Pritchard for a very detailed RTGDIR review. 1430 Thanks to Yaron Sheffer for the SECDIR review. Thanks to Gyan Mishra 1431 for the GENART review. 1433 Thanks to Alvaro Retana, Murray Kucherawy, Benjamin Kaduk, Roman 1434 Danyliw, Robert Wilton, Eric Vyncke, and Erik Kline for the IESG 1435 review. 1437 13. References 1439 13.1. Normative References 1441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1442 Requirement Levels", BCP 14, RFC 2119, 1443 DOI 10.17487/RFC2119, March 1997, 1444 . 1446 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1447 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1448 DOI 10.17487/RFC5440, March 2009, 1449 . 1451 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1452 Used to Form Encoding Rules in Various Routing Protocol 1453 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1454 2009, . 1456 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1457 "Recommendations for Secure Use of Transport Layer 1458 Security (TLS) and Datagram Transport Layer Security 1459 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1460 2015, . 1462 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1463 Writing an IANA Considerations Section in RFCs", BCP 26, 1464 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1465 . 1467 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1468 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1469 May 2017, . 1471 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1472 Computation Element Communication Protocol (PCEP) 1473 Extensions for Stateful PCE", RFC 8231, 1474 DOI 10.17487/RFC8231, September 2017, 1475 . 1477 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1478 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1479 Path Computation Element Communication Protocol (PCEP)", 1480 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1481 . 1483 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1484 Computation Element Communication Protocol (PCEP) 1485 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1486 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1487 . 1489 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1490 Hardwick, "Conveying Path Setup Type in PCE Communication 1491 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1492 July 2018, . 1494 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1495 and J. Hardwick, "Path Computation Element Communication 1496 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1497 DOI 10.17487/RFC8664, December 2019, 1498 . 1500 [RFC8779] Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F. 1501 Zhang, Ed., "Path Computation Element Communication 1502 Protocol (PCEP) Extensions for GMPLS", RFC 8779, 1503 DOI 10.17487/RFC8779, July 2020, 1504 . 1506 13.2. Informative References 1508 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1509 Element (PCE)-Based Architecture", RFC 4655, 1510 DOI 10.17487/RFC4655, August 2006, 1511 . 1513 [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. 1514 Margaria, "Requirements for GMPLS Applications of PCE", 1515 RFC 7025, DOI 10.17487/RFC7025, September 2013, 1516 . 1518 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1519 Computation Element Architecture", RFC 7399, 1520 DOI 10.17487/RFC7399, October 2014, 1521 . 1523 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1524 Hardwick, "Path Computation Element Communication Protocol 1525 (PCEP) Management Information Base (MIB) Module", 1526 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1527 . 1529 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 1530 Application-Based Network Operations", RFC 7491, 1531 DOI 10.17487/RFC7491, March 2015, 1532 . 1534 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1535 Code: The Implementation Status Section", BCP 205, 1536 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1537 . 1539 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1540 and D. Dhody, "Optimizations of Label Switched Path State 1541 Synchronization Procedures for a Stateful PCE", RFC 8232, 1542 DOI 10.17487/RFC8232, September 2017, 1543 . 1545 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1546 Architecture for Use of PCE and the PCE Communication 1547 Protocol (PCEP) in a Network with Central Control", 1548 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1549 . 1551 [RFC8741] Raghuram, A., Goddard, A., Karthik, J., Sivabalan, S., and 1552 M. Negi, "Ability for a Stateful Path Computation Element 1553 (PCE) to Request and Obtain Control of a Label Switched 1554 Path (LSP)", RFC 8741, DOI 10.17487/RFC8741, March 2020, 1555 . 1557 [I-D.ietf-teas-pcecc-use-cases] 1558 Li, Z., Khasanov, B., Dhody, D., Zhao, Q., Ke, Z., Fang, 1559 L., Zhou, C., Communications, T., Rachitskiy, A., and A. 1560 Gulida, "The Use Cases for Path Computation Element (PCE) 1561 as a Central Controller (PCECC).", draft-ietf-teas-pcecc- 1562 use-cases-06 (work in progress), September 2020. 1564 [I-D.ietf-pce-pcep-yang] 1565 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1566 YANG Data Model for Path Computation Element 1567 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1568 yang-15 (work in progress), October 2020. 1570 [I-D.ietf-pce-pcep-extension-pce-controller-sr] 1571 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 1572 Procedures and Protocol Extensions for Using PCE as a 1573 Central Controller (PCECC) for Segment Routing (SR) MPLS 1574 Segment Identifier (SID) Allocation and Distribution.", 1575 draft-ietf-pce-pcep-extension-pce-controller-sr-00 (work 1576 in progress), December 2020. 1578 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 1579 Li, Z., Peng, S., Geng, X., and M. Negi, "PCEP Procedures 1580 and Protocol Extensions for Using PCE as a Central 1581 Controller (PCECC) for SRv6", draft-dhody-pce-pcep- 1582 extension-pce-controller-srv6-05 (work in progress), 1583 November 2020. 1585 [I-D.li-pce-controlled-id-space] 1586 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1587 Controlled ID Space", draft-li-pce-controlled-id-space-07 1588 (work in progress), October 2020. 1590 [I-D.gont-numeric-ids-sec-considerations] 1591 Gont, F. and I. Arce, "Security Considerations for 1592 Transient Numeric Identifiers Employed in Network 1593 Protocols", draft-gont-numeric-ids-sec-considerations-06 1594 (work in progress), December 2020. 1596 Appendix A. Contributor Addresses 1598 Dhruv Dhody 1599 Huawei Technologies 1600 Divyashree Techno Park, Whitefield 1601 Bangalore, Karnataka 560066 1602 India 1604 EMail: dhruv.ietf@gmail.com 1606 Satish Karunanithi 1607 Huawei Technologies 1608 Divyashree Techno Park, Whitefield 1609 Bangalore, Karnataka 560066 1610 India 1612 EMail: satishk@huawei.com 1614 Adrian Farrel 1615 Old Dog Consulting 1616 UK 1618 EMail: adrian@olddog.co.uk 1620 Xuesong Geng 1621 Huawei Technologies 1622 China 1624 Email: gengxuesong@huawei.com 1626 Udayasree Palle 1628 EMail: udayasreereddy@gmail.com 1630 Katherine Zhao 1631 Futurewei Technologies 1633 EMail: katherine.zhao@futurewei.com 1635 Boris Zhang 1636 Telus Ltd. 1637 Toronto 1638 Canada 1640 EMail: boris.zhang@telus.com 1642 Alex Tokar 1643 Cisco Systems 1644 Slovak Republic 1646 EMail: atokar@cisco.com 1648 Authors' Addresses 1650 Zhenbin Li 1651 Huawei Technologies 1652 Huawei Bld., No.156 Beiqing Rd. 1653 Beijing 100095 1654 China 1656 EMail: lizhenbin@huawei.com 1658 Shuping Peng 1659 Huawei Technologies 1660 Huawei Bld., No.156 Beiqing Rd. 1661 Beijing 100095 1662 China 1664 EMail: pengshuping@huawei.com 1666 Mahendra Singh Negi 1667 RtBrick Inc 1668 N-17L, 18th Cross Rd, HSR Layout 1669 Bangalore, Karnataka 560102 1670 India 1672 EMail: mahend.ietf@gmail.com 1674 Quintin Zhao 1675 Etheric Networks 1676 1009 S CLAREMONT ST 1677 SAN MATEO, CA 94402 1678 USA 1680 EMail: qzhao@ethericnetworks.com 1682 Chao Zhou 1683 HPE 1685 EMail: chaozhou_us@yahoo.com