idnits 2.17.1 draft-dhody-pce-stateful-pce-interdomain-08.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 (February 19, 2019) is 1891 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-pce-inter-area-as-applicability-07 == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-15 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-01 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-04 == Outdated reference: A later version (-04) exists of draft-dugeon-pce-stateful-interdomain-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft X. Zhang 4 Intended status: Informational Huawei Technologies 5 Expires: August 23, 2019 February 19, 2019 7 Stateful Path Computation Element (PCE) Inter-domain Considerations 8 draft-dhody-pce-stateful-pce-interdomain-08 10 Abstract 12 A stateful Path Computation Element (PCE) maintains information about 13 Label Switched Path (LSP) characteristics and resource usage within a 14 network in order to provide traffic engineering path calculations for 15 its associated Path Computation Clients (PCCs). Furthermore, PCEs 16 are used to compute shortest constrained Traffic Engineering Label 17 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 18 Generalized MPLS (GMPLS) networks across multiple domains. 20 This document describes general considerations for the deployment of 21 stateful PCE(s) in inter-domain scenarios including inter-area and 22 inter-AS. The inter-layer considerations will be described in a 23 separate document. This document does not specify any extensions to 24 PCEP. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 23, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. LSP State Synchronization . . . . . . . . . . . . . . . . 4 63 3. Stateful PCE Deployments . . . . . . . . . . . . . . . . . . 4 64 3.1. Single Stateful PCE, Multiple Domains . . . . . . . . . . 5 65 3.2. Multiple Stateful PCE, Multiple Domains . . . . . . . . . 5 66 3.2.1. Per Domain Path Computation . . . . . . . . . . . . . 6 67 3.2.2. Backward-Recursive PCE-based Computation . . . . . . 7 68 3.2.2.1. Delegation . . . . . . . . . . . . . . . . . . . 8 69 3.2.2.2. PCE-initiated LSP . . . . . . . . . . . . . . . . 8 70 3.2.2.3. LSP Stitching . . . . . . . . . . . . . . . . . . 8 71 3.2.3. Hierarchical PCE . . . . . . . . . . . . . . . . . . 8 72 4. Interworking between different signalling types . . . . . . . 9 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. Manageability Considerations . . . . . . . . . . . . . . . . 10 75 6.1. Control of Function and Policy . . . . . . . . . . . . . 10 76 6.2. Information and Data Models . . . . . . . . . . . . . . . 10 77 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 78 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 79 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 80 6.6. Impact On Network Operations . . . . . . . . . . . . . . 10 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 9.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 The Path Computation Element communication Protocol (PCEP) provides 92 mechanisms for Path Computation Elements (PCEs) to perform path 93 computations in response to Path Computation Clients' (PCCs) 94 requests. 96 [RFC8051] describes general considerations for a stateful PCE 97 deployment and examines its applicability and benefits, as well as 98 its challenges and limitations through a number of use cases. 99 [RFC8231] describes a set of extensions to PCEP to provide stateful 100 control. A stateful PCE has access to not only the information 101 carried by the network's Interior Gateway Protocol (IGP), but also 102 the set of active paths and their reserved resources for its 103 computations. The additional state allows the PCE to compute 104 constrained paths while considering individual LSPs and their 105 interactions. 107 The ability to compute shortest constrained TE LSPs in Multiprotocol 108 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 109 multiple domains has been identified as a key motivation for PCE 110 development. In this context, a domain is a collection of network 111 elements within a common sphere of address management or path 112 computational responsibility such as an Interior Gateway Protocol 113 (IGP) area or an Autonomous Systems (AS). 115 This document presents general considerations for stateful PCE(s) 116 deployment in multi-domain scenarios. Further, 117 [I-D.ietf-pce-inter-area-as-applicability] examines the applicability 118 of the PCE architecture, protocols, and protocol extensions for 119 computing multi-area and multi-AS paths in MPLS and GMPLS networks 120 with focus on the stateless PCE deployments. 122 2. Overview 124 A stateful PCE maintains two sets of information for use in path 125 computation. The first is the Traffic Engineering Database (TED) 126 which includes the topology and resource state in the network. The 127 second is the LSP State Database (LSP-DB), in which a PCE stores 128 attributes of all active LSPs in the network, such as their paths 129 through the network, bandwidth/resource usage, switching types and 130 LSP constraints. This state information allows the PCE to compute 131 constrained paths while considering individual LSPs and their inter- 132 dependency. [RFC8231] applies equally to MPLS-TE and GMPLS LSPs and 133 distinguishes between an active and a passive stateful PCE. A 134 passive stateful PCE uses LSP state information to optimize path 135 computations but does not actively update LSP state. In contrast, an 136 active stateful PCE may issue recommendations to the network. For 137 example, an active stateful PCE may update LSP parameters for those 138 LSPs that have been delegated control over to the PCE by its PCCs. 140 The capability to compute the routes of end-to-end inter-domain MPLS- 141 TE LSPs is expressed as requirements in [RFC4105] and [RFC4216] and 142 may be realized by PCE(s). PCEs may use one of the following 143 mechanisms to compute end-to-end paths: 145 o a per-domain path computation technique [RFC5152]; 147 o a Backward-Recursive PCE-based Computation (BRPC) mechanism 148 [RFC5441]; 150 o a Hierarchical PCE mechanism [RFC6805]; 152 This document examines the stateful PCE inter-domain considerations 153 for all of these mechanisms. 155 2.1. LSP State Synchronization 157 The population of the LSP-DB using information received from PCCs 158 (ingress LSR) is supported by the stateful PCE extensions defined in 159 [RFC8231] , i.e., via LSP state report messages. 161 The inter-domain LSP state is synchronized to the ingress-PCE from 162 the ingress LSR (PCC), but this PCC cannot synchronize to other PCEs 163 (in transit or egress domains), thus other mechanism must be 164 investigated for this purpose. 166 Either the boundary node of the other domains, would need to 167 synchronize the state of LSP passing though it to the PCE, or a 168 mechanism for synchronization of inter-domain LSPs between the PCEs 169 is required. The former would require small change in the existing 170 state synchronization and reporting where a border node acts as a 171 PCC. The later could use the mechanism described in 172 [I-D.litkowski-pce-state-sync] can be used between the PCEs to 173 synchronize the inter-domain LSP state between each other. Further 174 section provide various considerations for this choice. 176 3. Stateful PCE Deployments 178 There are multiple models to perform PCE-based inter-domain path 179 computation: 181 o A single PCE 183 o Multiple PCEs 185 * without inter-PCE communication 187 * with inter-PCE communication 189 This section describe stateful PCE considerations for each of these 190 deployment models. 192 3.1. Single Stateful PCE, Multiple Domains 194 In this model, inter-domain path computation is performed by a single 195 stateful PCE that has topology visibility into all domains. The 196 inter-domain LSP state is synchronized to the PCE from the ingress 197 LSR (PCC) itself. The PCC may also choose to delegate control over 198 this LSP to the PCE. Thus this model is similar to a single domain 199 in all aspects. 201 Following figure show an example of inter-area case comprising of 202 Area 0,1 and 2. A single stateful PCE is deployed for all areas. 204 ******* 205 * PCE * 206 ******* 208 ! ! 209 ! ! 210 A----B----C----ABR1----D----E----F----ABR2----G----H----I 211 | | | | | | | | | | | 212 | | | | | | | | | | | 213 J----K----L----ABR3----M----N----O----ABR4----P----Q----R 214 ! ! 215 Area 1 ! Area 0 ! Area 2 217 In this model, PCE has visibility into the topology (TED) of all 218 domains as well as the state of all active LSPs (LSP-DB) including 219 inter-domain LSPs. This model is thus well suited to take advantage 220 of all stateful PCE capabilities. 222 It should be noted that in some deployments, a single stateful PCE 223 may not be possible because of administrative and confidentiality 224 concerns. 226 3.2. Multiple Stateful PCE, Multiple Domains 228 In this model, there is at least one PCE per domain, and each PCE has 229 topology (TED) visibility restricted to its own domain. The inter- 230 domain LSP state is synchronized to the ingress-PCE from the ingress 231 LSR (PCC), but this PCC may not be able to synchronize to other PCEs 232 (in transit or egress domains). This PCC may also choose to delegate 233 control over this LSP to the Ingress-PCE, which may issue inter- 234 domain path computation or re-optimization request to other PCEs. An 235 inter-domain LSP that originates in a domain, is synchronized to the 236 PCE in that domain. A new procedure is needed to synchronize state 237 of inter-domain LSP that do not originate in the domain. In other 238 words, inter-domain LSP state should also be synchronized to transit 239 and egress PCEs as the inter-domain LSP traverse through those 240 domains. 242 Following figure show an example of inter-AS case comprising of AS 243 100 and AS 200. A stateful PCE is deployed per AS. 245 ******** ******** 246 * PCE1 * * PCE2 * 247 ******** ******** 249 ! ! 250 ! ! 251 A----B----C----ASBR1------ASBR2----D----E----F 252 | | | | | | | | 253 | | | | | | | | 254 G----H----I----ASBR3------ASBR4----J----K----L 255 ! ! 256 AS100 ! ! AS200 258 In order to conceal the information, a PCE may use path-key based 259 confidentiality mechanisms as per [RFC5520]. 261 This section further describes considerations with respect to each of 262 the inter-domain path computation techniques. 264 3.2.1. Per Domain Path Computation 266 The per domain path computation technique [RFC5152] is based on 267 Multiple PCE Path Computation without Inter-PCE Communication Model 268 as described in [RFC4655]. It defines a method where the path is 269 computed during the signaling process (on a per-domain basis). The 270 entry Boundary Node (BN) of each domain is responsible for performing 271 the path computation for the section of the LSP that crosses the 272 domain, or for requesting that a PCE for that domain computes that 273 piece of the path. 275 The ingress LSR would synchronize the state to the ingress PCE, 276 further the entry boundary nodes should also synchronize the state of 277 inter-domain LSP to transit and egress PCEs. Note that the BN on the 278 path of an LSP can probably see the path (through the Record Route 279 object in RSVP-TE signaling [RFC3209]) and knows the bandwidth 280 reserved for the LSP. Thus each entry BN along the path could be 281 made responsible to synchronize the LSP state to the transit/egress 282 PCE(s). 284 Since the stateful PCE(s) do not communicate during this inter-domain 285 path computation technique and each entry BN would perform path 286 computation via Path Computation Request (PCReq) and Reply (PCRep) 287 messages, a passive stateful PCE is well suited for this case. 289 In case of delegation to the ingress PCE (active stateful PCE), it 290 would be capable of loose path computation only and make updates to 291 the ingress LSR with this limited visibility. The entry BN would 292 perform path computation via Path Computation Request and Reply 293 messages (and thus rely on the passive stateful mode). Thus the 294 inter-domain LSP is delegated only to the ingress PCE. 296 3.2.2. Backward-Recursive PCE-based Computation 298 The BRPC [RFC5441] technique is based on Multiple PCE Path 299 Computation with Inter-PCE Communication Model as described in 300 [RFC4655]. It involves cooperation and communication between PCEs in 301 order to compute an optimal end-to-end path across multiple domains. 302 The sequence of domains to be traversed may be known before the path 303 computation, but it can also be used when the domain path is unknown 304 and determined during path computation. 306 As described in Section 3.2.1, the entry boundary nodes may 307 synchronize the state of inter-domain LSPs to transit and egress 308 PCEs. An alternative approach may be for each PCE to synchronize the 309 state along the path across domains, i.e., each PCE would report the 310 state to the next PCE(s) in the adjacent domain along the domain 311 sequence of the inter-domain path. A mechanism similar to state-sync 312 described in [I-D.litkowski-pce-state-sync] may be utilized for this 313 purpose. 315 Some path segment in the end to end path may also be hidden via path- 316 key as per [RFC5520] during state synchronization. 318 In case of passive path computation request to the ingress PCE from 319 the ingress LSR the BRPC path computation procedure is applied to 320 compute end-to-end path by using PCReq and PCRep messages among 321 stateful PCE(s) in passive mode. 323 In case of delegation to the ingress PCE (active stateful PCE), the 324 ingress PCE may trigger the end-to-end path computation via the same 325 BRPC procedure using the path computation request and reply messages 326 among stateful PCE(s) (acting in passive mode). For re-optimization 327 the ingress PCE still rely on the same BRPC procedure triggered by 328 the ingress PCE. Ultimately the inter-domain LSP is delegated to the 329 ingress PCE and only the ingress PCE can trigger end-to-end (E2E) 330 path re-optimization with help of transit/egress PCE using the BRPC 331 procedure, based on the result the ingress PCE would issue updates to 332 the inter-domain LSP. 334 3.2.2.1. Delegation 336 As noted in this document, the inter-domain LSP is delegated to the 337 ingress PCE and only the ingress PCE can issue updates to the inter- 338 domain LSP. The ingress PCE is responsible to trigger E2E path re- 339 optimization. 341 Thus the ingress PCE can recommend updation for all aspects of the 342 inter-domain LSP including the segment of path in another domain 343 (which it may have computed with the help of other cooperating PCEs). 344 These interaction between PCEs for the inter-domain path computation 345 are done using PCReq/PCRep messages (i.e., in a passive mode). 347 The transit/egress PCE cannot update any attribute of the inter- 348 domain LSP on its own as it may not have any interaction with the 349 ingress LSR. A mechanism may be developed for transit/egress PCE to 350 inform the ingress PCE to trigger E2E re-optimization and choose to 351 update the inter-domain LSP based on the result. Also the ingress 352 PCE may use combination of local information and events along with 353 some external mechanism (management / monitoring interface) to 354 trigger E2E path re-optimization. 356 Though ingress PCE can recommend update for path segments in other 357 domains, the entry boundary node of that domain can apply policy 358 control during signaling as explained in [RFC4105] and [RFC4216]. 360 3.2.2.2. PCE-initiated LSP 362 [RFC8281] describes setup, maintenance and teardown of PCE-initiated 363 LSPs under the stateful PCE model, without the need for local 364 configuration on the PCC. Similar to LSP updation, the inter-domain 365 LSP can be initiated by the ingress PCE using the PCInitiate message 366 to the ingress LSR. Note that per-domain LSP may also be initiated 367 by respective domain's PCE and stitched together. 369 3.2.2.3. LSP Stitching 371 [I-D.dugeon-pce-stateful-interdomain] describes a proposal to combine 372 a Backward Recursive method with PCInitiate message to setup 373 independent paths per domain, and combine these different paths 374 together in order to operated them as end-to-end inter-domain paths 375 without the need of signaling session between AS border routers. 377 3.2.3. Hierarchical PCE 379 In H-PCE [RFC6805] architecture, the parent PCE is used to compute a 380 multi-domain path based on the domain connectivity information. The 381 parent PCE may be requested to provide a end-to-end path or only the 382 sequence of domains. 384 As described in Section 3.2.1 and Section 3.2.2, the entry boundary 385 nodes may synchronize the state of inter-domain LSP to transit and 386 egress child PCEs. In this case, it might not be possible to 387 synchronize state to the parent PCE. If the parent PCE provides the 388 sequence of domains and BRPC procedure is used to get the E2E path, 389 each PCE may be responsible to synchronize the state along the path 390 across domains similar to Section 3.2.2. An alternative approach may 391 be for ingress PCE to synchronize LSP state with the Parent PCE and 392 it may further synchronize the state to the child PCE(s) along the 393 path across domains, i.e. parent PCE would report the state to the 394 child PCE(s) along the domain sequence. 396 Some path segment in the end to end path may also be hidden via path- 397 key as per [RFC5520] during state synchronization. 399 In case of passive path computation request to the ingress PCE from 400 the ingress LSR, the H-PCE path computation procedure is applied to 401 compute sequence of domains or end-to-end path by using PCReq and 402 PCRep messages among stateful PCE(s) in passive mode. 404 In case of delegation to the ingress PCE (active stateful PCE), the 405 ingress child PCE may further delegate to parent PCE as per 406 [I-D.ietf-pce-stateful-hpce]. The parent PCE could update the path 407 of the inter-domain LSP. Both per-domain stitched LSP as well as E2E 408 contiguous LSP are possible. Further parent PCE could also initiate 409 the creation of LSP for both per-domain stitched LSP to all child PCE 410 or E2E contiguous LSP to ingress child PCE as described in 411 [I-D.ietf-pce-stateful-hpce]. 413 4. Interworking between different signalling types 415 Apart from the RSVP-TE signaling protocol, other TE path setup 416 methods are possible within the PCE architecture, such as Segment 417 Routing (SR) [I-D.ietf-pce-segment-routing] and PCECC 418 [I-D.ietf-pce-pcep-extension-for-pce-controller]. There is a 419 possibility of where two domains may use different setup technique 420 and coordination would be needed for inter-working. PCE can play an 421 important in stitching per-domain heterogeneous LSPs. 423 5. Security Considerations 425 The security considerations are as per [RFC5440] and [RFC8231]. Any 426 multi-domain operation necessarily involves the exchange of 427 information across domain boundaries. This may represent a 428 significant security and confidentiality risk especially when the 429 domains are controlled by different commercial entities. PCEP allows 430 individual PCEs to maintain confidentiality of their domain path 431 information by using path-keys [RFC5520]. 433 6. Manageability Considerations 435 6.1. Control of Function and Policy 437 Mechanisms defined in this document do not imply any new control of 438 function and policy requirements. 440 6.2. Information and Data Models 442 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 443 this document. 445 6.3. Liveness Detection and Monitoring 447 Mechanisms defined in this document do not imply any new liveness 448 detection and monitoring requirements in addition to those already 449 listed in [RFC5440]. 451 6.4. Verify Correct Operations 453 Mechanisms defined in this document do not imply any new operation 454 verification requirements in addition to those already listed in 455 [RFC5440]. 457 6.5. Requirements On Other Protocols 459 Mechanisms defined in this document do not imply any new requirements 460 on other protocols. 462 6.6. Impact On Network Operations 464 Mechanisms defined in this document do not have any impact on network 465 operations in addition to those already listed in [RFC5440]. 467 7. IANA Considerations 469 This is an informational document and has no IANA considerations. 471 8. Acknowledgments 473 The authors would like to that Young Lee, Haomian Zheng, Fatai Zhang 474 for this comments. 476 9. References 478 9.1. Normative References 480 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 481 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 482 DOI 10.17487/RFC5440, March 2009, 483 . 485 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 486 Computation Element Communication Protocol (PCEP) 487 Extensions for Stateful PCE", RFC 8231, 488 DOI 10.17487/RFC8231, September 2017, 489 . 491 9.2. Informative References 493 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 494 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 495 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 496 . 498 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., 499 "Requirements for Inter-Area MPLS Traffic Engineering", 500 RFC 4105, DOI 10.17487/RFC4105, June 2005, 501 . 503 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous 504 System (AS) Traffic Engineering (TE) Requirements", 505 RFC 4216, DOI 10.17487/RFC4216, November 2005, 506 . 508 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 509 Element (PCE)-Based Architecture", RFC 4655, 510 DOI 10.17487/RFC4655, August 2006, 511 . 513 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 514 Per-Domain Path Computation Method for Establishing Inter- 515 Domain Traffic Engineering (TE) Label Switched Paths 516 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 517 . 519 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 520 "A Backward-Recursive PCE-Based Computation (BRPC) 521 Procedure to Compute Shortest Constrained Inter-Domain 522 Traffic Engineering Label Switched Paths", RFC 5441, 523 DOI 10.17487/RFC5441, April 2009, 524 . 526 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 527 "Preserving Topology Confidentiality in Inter-Domain Path 528 Computation Using a Path-Key-Based Mechanism", RFC 5520, 529 DOI 10.17487/RFC5520, April 2009, 530 . 532 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 533 Path Computation Element Architecture to the Determination 534 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 535 DOI 10.17487/RFC6805, November 2012, 536 . 538 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 539 Hardwick, "Path Computation Element Communication Protocol 540 (PCEP) Management Information Base (MIB) Module", 541 RFC 7420, DOI 10.17487/RFC7420, December 2014, 542 . 544 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 545 Stateful Path Computation Element (PCE)", RFC 8051, 546 DOI 10.17487/RFC8051, January 2017, 547 . 549 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 550 Computation Element Communication Protocol (PCEP) 551 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 552 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 553 . 555 [I-D.ietf-pce-inter-area-as-applicability] 556 King, D. and H. Zheng, "Applicability of the Path 557 Computation Element to Inter-Area and Inter-AS MPLS and 558 GMPLS Traffic Engineering", draft-ietf-pce-inter-area-as- 559 applicability-07 (work in progress), December 2018. 561 [I-D.ietf-pce-stateful-hpce] 562 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 563 and O. Dios, "Hierarchical Stateful Path Computation 564 Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in 565 progress), October 2018. 567 [I-D.ietf-pce-segment-routing] 568 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 569 and J. Hardwick, "PCEP Extensions for Segment Routing", 570 draft-ietf-pce-segment-routing-15 (work in progress), 571 February 2019. 573 [I-D.ietf-pce-pcep-extension-for-pce-controller] 574 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 575 and Protocol Extensions for Using PCE as a Central 576 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 577 extension-for-pce-controller-01 (work in progress), 578 February 2019. 580 [I-D.litkowski-pce-state-sync] 581 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 582 Stateful Path Computation Element communication 583 procedures", draft-litkowski-pce-state-sync-04 (work in 584 progress), October 2018. 586 [I-D.dugeon-pce-stateful-interdomain] 587 Dugeon, O., Meuric, J., Lee, Y., Dhody, D., and D. 588 Ceccarelli, "PCEP Extension for Stateful Inter-Domain 589 Tunnels", draft-dugeon-pce-stateful-interdomain-01 (work 590 in progress), July 2018. 592 Appendix A. Contributor Addresses 594 Dhruv Dhody 595 Huawei Technologies 596 Divyashree Techno Park, Whitefield 597 Bangalore, Karnataka 560066 598 India 600 EMail: dhruv.ietf@gmail.com 602 Udayasree Palle 604 EMail: udayasreereddy@gmail.com 606 Avantika 608 EMail: s.avantika.avantika@gmail.com 610 Authors' Addresses 612 Cheng Li 613 Huawei Technologies 614 Huawei Campus, No. 156 Beiqing Rd. 615 Beijing 100095 616 China 618 EMail: chengli13@huawei.com 620 Xian Zhang 621 Huawei Technologies 622 Bantian, Longgang District 623 Shenzhen 518129 624 P.R.China 626 EMail: zhang.xian@huawei.com