idnits 2.17.1 draft-li-pce-controlled-id-space-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2018) is 2137 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'I-D.li-pce-sr-path-segment' is mentioned on line 404, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-03 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-03 == Outdated reference: A later version (-03) exists of draft-cheng-spring-mpls-path-segment-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Experimental J. Dong 5 Expires: December 22, 2018 Z. Li 6 D. Dhody 7 Huawei Technologies 8 June 20, 2018 10 PCE Controlled ID Space 11 draft-li-pce-controlled-id-space-00 13 Abstract 15 The Path Computation Element Communication Protocol (PCEP) provides 16 mechanisms for Path Computation Elements (PCEs) to perform path 17 computations in response to Path Computation Clients (PCCs) requests. 18 The Stateful PCE extensions allow stateful control of Multiprotocol 19 Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths 20 (LSPs) using PCEP. Furthermore, PCEP can be used for computing paths 21 in SR networks. 23 Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a 24 model where the PCC delegates control over one or more locally 25 configured LSPs to the PCE. Further, stateful PCE could also create 26 and delete PCE-initiated LSPs itself. A PCE-based central controller 27 (PCECC) simplify the processing of a distributed control plane by 28 blending it with elements of Software-Defined Networking (SDN) and 29 without necessarily completely replacing it. 31 In some use cases, such as PCECC, Binding Segment Identifier (SID), 32 SR Path Identification, there is a requirement for a stateful PCE to 33 make allocation of labels, SID, Path-ID respectively. These use 34 cases require for the PCE to be aware of the various identifier space 35 from which to make allocations on behalf of PCC. This documents 36 specify a mechanism for a PCC to inform the PCE of the identifier 37 space under its control via PCEP. The identifier could be MPLS 38 label, SID, Path ID or another future identifier to be allocated by a 39 PCE. 41 Requirements Language 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 45 "OPTIONAL" in this document are to be interpreted as described in BCP 46 14 [RFC2119] [RFC8174] when, and only when, they appear in all 47 capitals, as shown here. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on December 22, 2018. 66 Copyright Notice 68 Copyright (c) 2018 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (https://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 3.1. PCE-based Central Control . . . . . . . . . . . . . . . . 4 87 3.2. Binding SID Allocation . . . . . . . . . . . . . . . . . 5 88 3.3. Path ID Allocation . . . . . . . . . . . . . . . . . . . 5 89 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 5. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 91 5.1. Open Object . . . . . . . . . . . . . . . . . . . . . . . 7 92 5.1.1. LABEL-CONTROL-SPACE TLV . . . . . . . . . . . . . . . 7 93 5.1.2. SRv6-PATH-ID-CONTROL-SPACE TLV . . . . . . . . . . . 8 94 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 9 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 97 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 100 10.2. Informative References . . . . . . . . . . . . . . . . . 11 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 103 1. Introduction 105 [RFC5440] defines the stateless Path Computation Element 106 communication Protocol (PCEP) for Path Computation Elements (PCEs) to 107 perform path computations in response to Path Computation Clients 108 (PCCs) requests. For supporting stateful operations, [RFC8231] 109 specifies a set of extensions to PCEP to enable stateful control of 110 LSPs within and across PCEP sessions in compliance with [RFC4657]. 111 Furthermore, [RFC8281] describes the setup, maintenance, and teardown 112 of PCE-initiated LSPs under the stateful PCE model, without the need 113 for local configuration on the PCC, thus allowing for a dynamic 114 network that is centrally controlled and deployed. 116 [RFC8283] introduces the architecture for PCE as a central 117 controller, it examines the motivations and applicability for PCEP as 118 a control protocol in this environment, and introduces the 119 implications for the protocol. Also, 120 [I-D.zhao-pce-pcep-extension-for-pce-controller] specifies the 121 procedures and PCEP protocol extensions for using the PCE as the 122 central controller, where LSPs are calculated/setup/initiated and 123 label forwarding entries are downloaded through extending PCEP. 124 However, the document assumes that label range to be used by a PCE is 125 known and set on both PCEP peers. This extension adds the capability 126 to advertise the range via a PCEP extension. 128 Similarly, [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies 129 the procedures and PCEP protocol extensions when a PCE-based 130 controller is also responsible for configuring the forwarding actions 131 on the routers (SR SID distribution in this case), in addition to 132 computing the paths for packet flows in a segment routing network and 133 telling the edge routers what instructions to attach to packets as 134 they enter the network. However, the document assumes that label 135 range to be used by a PCE is known and set on both PCEP peers. This 136 extension adds the capability to advertise the range (from SRGB or 137 SRLB of the node) via a PCEP extension. 139 [I-D.li-pce-sr-path-segment] defines a procedure for path ID in PCEP 140 for SR by defining the PATH-ID TLV. The path ID can be a path 141 segment in SR-MPLS [I-D.cheng-spring-mpls-path-segment], or a path ID 142 in SRv6 [I-D.li-spring-passive-pm-for-srv6-np], or other IDs that can 143 identify an SR path. This document specify the extension to support 144 advertisement of the various ID space to the PCE to control. 146 The usecase are described in Section 3. The ID space range 147 information can be advertised via the TLVs in the Open message. The 148 detailed procedures will be described in Section 4, and the objects' 149 format will be introduced in Section 5. 151 2. Terminology 153 This memo makes use of the terms defined in [RFC5440], [RFC8231], 154 [RFC8283] and [I-D.ietf-spring-segment-routing]. 156 3. Use cases 158 3.1. PCE-based Central Control 160 A PCE-based central controller (PCECC) can simplify the processing of 161 a distributed control plane by blending it with elements of SDN and 162 without necessarily completely replacing it. Thus, the LSP can be 163 calculated/setup/initiated and the label forwarding entries can also 164 be downloaded through a centralized PCE server to each network 165 devices along the path while leveraging the existing PCE technologies 166 as much as possible. 168 [I-D.zhao-pce-pcep-extension-for-pce-controller] describe a mode 169 where LSPs are provisioned as explicit label instructions at each hop 170 on the end-to-end path. Each router along the path must be told what 171 label forwarding instructions to program and what resources to 172 reserve. The controller uses PCEP to communicate with each router 173 along the path of the end-to-end LSP. For this to work, the PCE- 174 based controller will take responsibility for managing some part of 175 the MPLS label space for each of the routers that it controls as 176 described in section 3.1.2. of [RFC8283]. A mechanism for a PCC to 177 inform the PCE of such a label space to control is needed within 178 PCEP. 180 [I-D.ietf-pce-segment-routing] specifies extensions to PCEP that 181 allow a stateful PCE to compute, update or initiate SR-TE paths. 182 [I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the 183 mechanism for PCECC to allocate and provision the node/prefix/ 184 adjacency label (SID) via PCEP. To make such allocation PCE needs to 185 be aware of the label space from Segment Routing Global Block (SRGB) 186 or Segment Routing Local Block (SRLB) 187 [I-D.ietf-spring-segment-routing] of the node that it controls. A 188 mechanism for a PCC to inform the PCE of such a label space to 189 control is needed within PCEP. The full SRGB/SRLB of a node could be 190 learned via existing IGP or BGP-LS mechanism. 192 3.2. Binding SID Allocation 194 The headend of an SR Policy binds a binding SID to its policy 195 [I-D.ietf-spring-segment-routing]. The instantiation of which may 196 involve a list of SIDs. Currently binding SID are allocated by the 197 node, but there is an inherent advantage in the binding SID to be 198 allocated by a PCE to allow SR policies to be dynamically created, 199 updated according to the network status and operations. Therefore, a 200 PCE needs to obtain the authority and control to allocate binding SID 201 actively from the PCC's label space as described in above use case. 203 3.3. Path ID Allocation 205 Path identification is needed for several use cases such as 206 performance measurement in Segment Routing (SR) network. For 207 identifying an SR path, [I-D.cheng-spring-mpls-path-segment] 208 introduces a new segment that is referred to as Path Segment, and 209 [I-D.li-spring-passive-pm-for-srv6-np] introduces the path ID in 210 SRv6. 212 [I-D.li-pce-sr-path-segment] defines a procedure for path ID in PCEP 213 for SR. It describes a mode in which PCE could allocate path ID and 214 inform the ingress and egress PCC. To make such an allocation a PCE 215 needs to be aware of the path ID space under its control. A 216 mechanism for a PCC to inform the PCE of such a path ID space is 217 needed within PCEP. 219 4. Overview 221 During PCEP Initialization Phase, Open messages are exchanged between 222 PCCs and PCEs. The OPEN object may also contain a set of TLVs used 223 to convey capabilities in the Open message. The ID could be a MPLS 224 label, SRv6 path ID or any other future ID space for PCE to allocate. 225 A PCC can include a corresponding ID-CONTROL-SPACE TLVs, in the OPEN 226 Object to inform the corresponding ID space information that it wants 227 the PCE to control. This TLV MUST NOT be included by the PCE and 228 MUST be ignored on receipt by a PCC. This is an optional TLV, the 229 PCE could be aware of the ID space from some other means outside of 230 PCEP. 232 For delegating multiple types of ID space, multiple TLVs 233 corresponding to each ID type MUST be included in a Open message. 234 Each TLV (corresponding to each ID type) SHOULD be included only once 235 in a Open Message. On receipt, only the first instance is processed 236 and others MUST be ignored. The ID type can be MPLS label, SRv6 path 237 ID [I-D.li-spring-passive-pm-for-srv6-np] or other ID. The following 238 ID-CONTROL-SPACE TLVs are defined in this document - 239 o LABEL-CONTROL-SPACE - for MPLS Labels (including for SR-MPLS) 241 o SRv6-PATH-ID-CONTROL-SPACE - for SRv6 Path ID 243 The procedure of ID space control to PCE is shown below: 245 +-+-+ +-+-+ 246 |PCC| |PCE| 247 +-+-+ +-+-+ 248 | | 249 | Open msg (LABEL-CONTROL-SPACE, and/or | 250 | SRv6-PATH-ID-CONTROL-SPACE) | 251 |-------- | 252 | \ Open msg | 253 | \ -----------------------------| 254 | \/ | 255 | /\ | 256 | / ---------------------------->| 257 | / | 258 |<------ Keepalive | 259 | ----------------------------| 260 |Keepalive / | 261 |-------- / | 262 | \/ | 263 | /\ | 264 |<------ ------------------------------>| 265 | | 267 Figure 1: ID space control to PCE 269 If the ID space control procedure is successful, the PCE will return 270 a KeepAlive message to the PCC. If there is any error in processing 271 the corresponding TLV, an Error (PCErr) message will be sent to the 272 PCC with Error-Type=1 (PCEP session establishment failure) and Error- 273 value=TBD (ID space control failure). 275 After this process, a stateful PCE can learn the PCE controlled ID 276 spaces of a node (PCC) under its control. A PCE can then allocate 277 IDs within the control ID space. For example, a PCE can actively 278 allocate labels and download forwarding instructions for the PCECC 279 LSP as described in [I-D.zhao-pce-pcep-extension-for-pce-controller]. 280 A PCE can also allocate labels from SRGB/SRLB for PCECC-SR 281 [I-D.zhao-pce-pcep-extension-pce-controller-sr], binding segments, 282 and path segments [I-D.cheng-spring-mpls-path-segment]. The full 283 SRGB/SRLB of a node could be learned via existing IGP or BGP-LS 284 mechanism. Similarly a PCE can allocate SRv6 Path ID 286 [I-D.li-spring-passive-pm-for-srv6-np] according to the SRv6 Path ID 287 space under its control. 289 5. Objects 291 5.1. Open Object 293 For advertising the PCE controlled ID space to a PCE, this document 294 defines several TLVs within the Open object. 296 5.1.1. LABEL-CONTROL-SPACE TLV 298 For a PCC to inform the label space under the PCE control, this 299 document defines a new LABEL-CONTROL-SPACE TLV. 301 The LABEL-CONTROL-SPACE TLV is an optional TLV for use in the OPEN 302 object, and its format is shown in the following figure: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type=TBA | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Flags |A| 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Start (1) | Reserved | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Range (1) | Reserved | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | ... | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | ... | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Start (n) | Reserved | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Range (n) | Reserved | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 2: LABEL-CONTROL-SPACE TLV 326 The type (16 bits) of the TLV is TBA. The length field (16 bits) and 327 has a variable value. 329 Flags (32 bits): Following flags are currently defined 331 o A-flag: All space flag, set when all the label space is delegated 332 to a PCE. When A-flag is set, the pair of Start and End SHOULD 333 NOT appear unless the PCC needs to notify the entire ID space to a 334 PCE. 336 The unassigned bits of Flags field MUST be set to 0 on transmission 337 and MUST be ignored on receipt. 339 Start(i) (24 bits): indicates the beginning of the label block i. 341 Range(i) (24 bits): indicates the range of the label block i. 343 Reserved: SHOULD be set to 0 on transmission and MUST be ignored on 344 reception. 346 The number of label blocks can be calculated according to value of 347 the length field in the TLV. 349 A stateful PCE can actively allocate labels and download forwarding 350 instructions for the PCECC LSP as described in 351 [I-D.zhao-pce-pcep-extension-for-pce-controller]. A PCE can also 352 allocate labels from SRGB/SRLB for PCECC-SR 353 [I-D.zhao-pce-pcep-extension-pce-controller-sr] and binding segments 354 can be selected for the PCE controlled space. Also, Path segment 355 [I-D.cheng-spring-mpls-path-segment] can be allocated by a stateful 356 PCE in a similar same way as described in [I-D.li-pce-sr-path- 357 segment]. 359 5.1.2. SRv6-PATH-ID-CONTROL-SPACE TLV 361 For a PCC to inform the SRv6 path ID space under the PCE control, 362 this document defines a new SRv6-PATH-ID-CONTROL-SPACE TLV. 364 The SRv6-PATH-ID-CONTROL-SPACE TLV is an optional TLV for use in the 365 OPEN object, and its format is shown in the following figure: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type=TBA | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Flags |A| 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Start (1) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Range (1) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | ... | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | ... | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Start (n) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Range (n) | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 3: SRv6-PATH-ID-CONTROL-SPACE TLV 389 The type (16 bits) of the TLV is TBA. The length field (16 bits) and 390 has a variable value. 392 Flags (32 bits): is of same format as LABEL-CONTROL-SPACE TLV. Any 393 bits assigned in the LABEL-CONTROL-SPACE TLV are also applicable for 394 this. 396 Start(i) (32 bits): indicates the beginning of the SRv6 Path ID block 397 i. 399 Range(i) (32 bits): indicates the range of the SRv6 Path ID block i. 401 The number of Path ID blocks can be calculated according to the 402 length field in the TLV. Given the controlled ID spaces, a stateful 403 PCE can actively allocate path IDs to SRv6 paths from the controlled 404 ID spaces as described in [I-D.li-pce-sr-path-segment]. 406 6. Other Considerations 408 In case of multiple PCEs, a PCC MAY decide to give control over 409 different ID space to each instance of the PCE. In case a PCC 410 includes the same ID space to multiple PCEs, the PCE SHOULD use 411 synchronization mechanism (such as [I-D.litkowski-pce-state-sync]) to 412 avoid allocating the same ID. 414 7. IANA Considerations 416 TBA. 418 8. Security Considerations 420 TBA. 422 9. Acknowledgements 424 TBA. 426 10. References 428 10.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, 432 DOI 10.17487/RFC2119, March 1997, 433 . 435 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 436 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 437 DOI 10.17487/RFC5440, March 2009, 438 . 440 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 441 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 442 May 2017, . 444 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 445 Computation Element Communication Protocol (PCEP) 446 Extensions for Stateful PCE", RFC 8231, 447 DOI 10.17487/RFC8231, September 2017, 448 . 450 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 451 Computation Element Communication Protocol (PCEP) 452 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 453 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 454 . 456 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 457 Architecture for Use of PCE and the PCE Communication 458 Protocol (PCEP) in a Network with Central Control", 459 RFC 8283, DOI 10.17487/RFC8283, December 2017, 460 . 462 10.2. Informative References 464 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 465 Element (PCE) Communication Protocol Generic 466 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 467 2006, . 469 [I-D.ietf-pce-segment-routing] 470 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 471 and J. Hardwick, "PCEP Extensions for Segment Routing", 472 draft-ietf-pce-segment-routing-11 (work in progress), 473 November 2017. 475 [I-D.ietf-spring-segment-routing] 476 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 477 Litkowski, S., and R. Shakir, "Segment Routing 478 Architecture", draft-ietf-spring-segment-routing-15 (work 479 in progress), January 2018. 481 [I-D.zhao-pce-pcep-extension-for-pce-controller] 482 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 483 and C. Zhou, "PCEP Procedures and Protocol Extensions for 484 Using PCE as a Central Controller (PCECC) of LSPs", draft- 485 zhao-pce-pcep-extension-for-pce-controller-08 (work in 486 progress), June 2018. 488 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 489 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 490 and C. Zhou, "PCEP Procedures and Protocol Extensions for 491 Using PCE as a Central Controller (PCECC) of SR-LSPs", 492 draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work 493 in progress), June 2018. 495 [I-D.litkowski-pce-state-sync] 496 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 497 Stateful Path Computation Element communication 498 procedures", draft-litkowski-pce-state-sync-03 (work in 499 progress), April 2018. 501 [I-D.cheng-spring-mpls-path-segment] 502 Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., and S. 503 Zhan, "Path Segment in MPLS Based Sement Routing Network", 504 draft-cheng-spring-mpls-path-segment-01 (work in 505 progress), March 2018. 507 [I-D.li-spring-passive-pm-for-srv6-np] 508 Li, C. and M. Chen, "Passive Performance Measurement for 509 SRv6 Network Programming", draft-li-spring-passive-pm-for- 510 srv6-np-00 (work in progress), March 2018. 512 Authors' Addresses 514 Cheng Li 515 Huawei Technologies 516 Huawei Campus, No. 156 Beiqing Rd. 517 Beijing 100095 518 China 520 EMail: chengli13@huawei.com 522 Mach(Guoyi) Chen 523 Huawei Technologies 524 Huawei Campus, No. 156 Beiqing Rd. 525 Beijing 100095 526 China 528 EMail: Mach.chen@huawei.com 530 Jie Dong 531 Huawei Technologies 532 Huawei Campus, No. 156 Beiqing Rd. 533 Beijing 100095 534 China 536 EMail: jie.dong@huawei.com 538 Zhenbin Li 539 Huawei Technologies 540 Huawei Campus, No. 156 Beiqing Rd. 541 Beijing 100095 542 China 544 EMail: lizhenbin@huawei.com 545 Dhruv Dhody 546 Huawei Technologies 547 Divyashree Techno Park, Whitefield 548 Bangalore, Karnataka 560066 549 India 551 EMail: dhruv.ietf@gmail.com