idnits 2.17.1 draft-dhody-pce-stateful-pce-interdomain-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2018) is 2246 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-02 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-02 == Outdated reference: A later version (-04) exists of draft-dugeon-pce-stateful-interdomain-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft X. Zhang 4 Intended status: Informational Huawei Technologies 5 Expires: September 3, 2018 March 2, 2018 7 Stateful Path Computation Element (PCE) Inter-domain Considerations 8 draft-dhody-pce-stateful-pce-interdomain-06 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 September 3, 2018. 43 Copyright Notice 45 Copyright (c) 2018 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. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 5. Manageability Considerations . . . . . . . . . . . . . . . . 9 74 5.1. Control of Function and Policy . . . . . . . . . . . . . 10 75 5.2. Information and Data Models . . . . . . . . . . . . . . . 10 76 5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 77 5.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 78 5.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 79 5.6. Impact On Network Operations . . . . . . . . . . . . . . 10 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 8.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 The Path Computation Element communication Protocol (PCEP) provides 91 mechanisms for Path Computation Elements (PCEs) to perform path 92 computations in response to Path Computation Clients' (PCCs) 93 requests. 95 [RFC8051] describes general considerations for a stateful PCE 96 deployment and examines its applicability and benefits, as well as 97 its challenges and limitations through a number of use cases. 98 [RFC8231] describes a set of extensions to PCEP to provide stateful 99 control. A stateful PCE has access to not only the information 100 carried by the network's Interior Gateway Protocol (IGP), but also 101 the set of active paths and their reserved resources for its 102 computations. The additional state allows the PCE to compute 103 constrained paths while considering individual LSPs and their 104 interactions. 106 The ability to compute shortest constrained TE LSPs in Multiprotocol 107 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 108 multiple domains has been identified as a key motivation for PCE 109 development. In this context, a domain is a collection of network 110 elements within a common sphere of address management or path 111 computational responsibility such as an Interior Gateway Protocol 112 (IGP) area or an Autonomous Systems (AS). 114 This document presents general considerations for stateful PCE(s) 115 deployment in multi-domain scenarios. 117 2. Overview 119 A stateful PCE maintains two sets of information for use in path 120 computation. The first is the Traffic Engineering Database (TED) 121 which includes the topology and resource state in the network. The 122 second is the LSP State Database (LSP-DB), in which a PCE stores 123 attributes of all active LSPs in the network, such as their paths 124 through the network, bandwidth/resource usage, switching types and 125 LSP constraints. This state information allows the PCE to compute 126 constrained paths while considering individual LSPs and their inter- 127 dependency. [RFC8231] applies equally to MPLS-TE and GMPLS LSPs and 128 distinguishes between an active and a passive stateful PCE. A 129 passive stateful PCE uses LSP state information to optimize path 130 computations but does not actively update LSP state. In contrast, an 131 active stateful PCE may issue recommendations to the network. For 132 example, an active stateful PCE may update LSP parameters for those 133 LSPs that have been delegated control over to the PCE by its PCCs. 135 The capability to compute the routes of end-to-end inter-domain MPLS- 136 TE LSPs is expressed as requirements in [RFC4105] and [RFC4216] and 137 may be realized by PCE(s). PCEs may use one of the following 138 mechanisms to compute end-to-end paths: 140 o a per-domain path computation technique [RFC5152]; 141 o a Backward-Recursive PCE-based Computation (BRPC) mechanism 142 [RFC5441]; 144 o a Hierarchical PCE mechanism [RFC6805]; 146 This document examines the stateful PCE inter-domain considerations 147 for all of these mechanisms. 149 2.1. LSP State Synchronization 151 The population of the LSP-DB using information received from PCCs 152 (ingress LSR) is supported by the stateful PCE extensions defined in 153 [RFC8231] , i.e., via LSP state report messages. 155 The inter-domain LSP state is synchronized to the ingress-PCE from 156 the ingress LSR (PCC), but this PCC cannot synchronize to other PCEs 157 (in transit or egress domains), thus other mechanism must be 158 investigated for this purpose. 160 Either the boundary node of the other domains, would need to 161 synchronize the state of LSP passing though it to the PCE, or a 162 mechanism for synchronization of inter-domain LSPs between the PCEs 163 is required. The former would require small change in the existing 164 state synchronization and reporting where a border node acts as a 165 PCC. The later could use the mechanism described in 166 [I-D.litkowski-pce-state-sync] can be used between the PCEs to 167 synchronize the inter-domain LSP state between each other. Further 168 section provide various considerations for this choice. 170 3. Stateful PCE Deployments 172 There are multiple models to perform PCE-based inter-domain path 173 computation: 175 o A single PCE 177 o Multiple PCEs 179 * without inter-PCE communication 181 * with inter-PCE communication 183 This section describe stateful PCE considerations for each of these 184 deployment models. 186 3.1. Single Stateful PCE, Multiple Domains 188 In this model, inter-domain path computation is performed by a single 189 stateful PCE that has topology visibility into all domains. The 190 inter-domain LSP state is synchronized to the PCE from the ingress 191 LSR (PCC) itself. The PCC may also choose to delegate control over 192 this LSP to the PCE. Thus this model is similar to a single domain 193 in all aspects. 195 Following figure show an example of inter-area case comprising of 196 Area 0,1 and 2. A single stateful PCE is deployed for all areas. 198 ******* 199 * PCE * 200 ******* 202 ! ! 203 ! ! 204 A----B----C----ABR1----D----E----F----ABR2----G----H----I 205 | | | | | | | | | | | 206 | | | | | | | | | | | 207 J----K----L----ABR3----M----N----O----ABR4----P----Q----R 208 ! ! 209 Area 1 ! Area 0 ! Area 2 211 In this model, PCE has visibility into the topology (TED) of all 212 domains as well as the state of all active LSPs (LSP-DB) including 213 inter-domain LSPs. This model is thus well suited to take advantage 214 of all stateful PCE capabilities. 216 It should be noted that in some deployments, a single stateful PCE 217 may not be possible because of administrative and confidentiality 218 concerns. 220 3.2. Multiple Stateful PCE, Multiple Domains 222 In this model, there is at least one PCE per domain, and each PCE has 223 topology (TED) visibility restricted to its own domain. The inter- 224 domain LSP state is synchronized to the ingress-PCE from the ingress 225 LSR (PCC), but this PCC may not be able to synchronize to other PCEs 226 (in transit or egress domains). This PCC may also choose to delegate 227 control over this LSP to the Ingress-PCE, which may issue inter- 228 domain path computation or re-optimization request to other PCEs. An 229 inter-domain LSP that originates in a domain, is synchronized to the 230 PCE in that domain. A new procedure is needed to synchronize state 231 of inter-domain LSP that do not originate in the domain. In other 232 words, inter-domain LSP state should also be synchronized to transit 233 and egress PCEs as the inter-domain LSP traverse through those 234 domains. 236 Following figure show an example of inter-AS case comprising of AS 237 100 and AS 200. A stateful PCE is deployed per AS. 239 ******** ******** 240 * PCE1 * * PCE2 * 241 ******** ******** 243 ! ! 244 ! ! 245 A----B----C----ASBR1------ASBR2----D----E----F 246 | | | | | | | | 247 | | | | | | | | 248 G----H----I----ASBR3------ASBR4----J----K----L 249 ! ! 250 AS100 ! ! AS200 252 In order to conceal the information, a PCE may use path-key based 253 confidentiality mechanisms as per [RFC5520]. 255 This section further describes considerations with respect to each of 256 the inter-domain path computation techniques. 258 3.2.1. Per Domain Path Computation 260 The per domain path computation technique [RFC5152] is based on 261 Multiple PCE Path Computation without Inter-PCE Communication Model 262 as described in [RFC4655]. It defines a method where the path is 263 computed during the signaling process (on a per-domain basis). The 264 entry Boundary Node (BN) of each domain is responsible for performing 265 the path computation for the section of the LSP that crosses the 266 domain, or for requesting that a PCE for that domain computes that 267 piece of the path. 269 The ingress LSR would synchronize the state to the ingress PCE, 270 further the entry boundary nodes should also synchronize the state of 271 inter-domain LSP to transit and egress PCEs. Note that the BN on the 272 path of an LSP can probably see the path (through the Record Route 273 object in RSVP-TE signaling [RFC3209]) and knows the bandwidth 274 reserved for the LSP. Thus each entry BN along the path could be 275 made responsible to synchronize the LSP state to the transit/egress 276 PCE(s). 278 Since the stateful PCE(s) do not communicate during this inter-domain 279 path computation technique and each entry BN would perform path 280 computation via Path Computation Request (PCReq) and Reply (PCRep) 281 messages, a passive stateful PCE is well suited for this case. 283 In case of delegation to the ingress PCE (active stateful PCE), it 284 would be capable of loose path computation only and make updates to 285 the ingress LSR with this limited visibility. The entry BN would 286 perform path computation via Path Computation Request and Reply 287 messages (and thus rely on the passive stateful mode). Thus the 288 inter-domain LSP is delegated only to the ingress PCE. 290 3.2.2. Backward-Recursive PCE-based Computation 292 The BRPC [RFC5441] technique is based on Multiple PCE Path 293 Computation with Inter-PCE Communication Model as described in 294 [RFC4655]. It involves cooperation and communication between PCEs in 295 order to compute an optimal end-to-end path across multiple domains. 296 The sequence of domains to be traversed may be known before the path 297 computation, but it can also be used when the domain path is unknown 298 and determined during path computation. 300 As described in Section 3.2.1, the entry boundary nodes may 301 synchronize the state of inter-domain LSPs to transit and egress 302 PCEs. An alternative approach may be for each PCE to synchronize the 303 state along the path across domains, i.e., each PCE would report the 304 state to the next PCE(s) in the adjacent domain along the domain 305 sequence of the inter-domain path. A mechanism similar to state-sync 306 described in [I-D.litkowski-pce-state-sync] may be utilized for this 307 purpose. 309 Some path segment in the end to end path may also be hidden via path- 310 key as per [RFC5520] during state synchronization. 312 In case of passive path computation request to the ingress PCE from 313 the ingress LSR the BRPC path computation procedure is applied to 314 compute end-to-end path by using PCReq and PCRep messages among 315 stateful PCE(s) in passive mode. 317 In case of delegation to the ingress PCE (active stateful PCE), the 318 ingress PCE may trigger the end-to-end path computation via the same 319 BRPC procedure using the path computation request and reply messages 320 among stateful PCE(s) (acting in passive mode). For re-optimization 321 the ingress PCE still rely on the same BRPC procedure triggered by 322 the ingress PCE. Ultimately the inter-domain LSP is delegated to the 323 ingress PCE and only the ingress PCE can trigger end-to-end (E2E) 324 path re-optimization with help of transit/egress PCE using the BRPC 325 procedure, based on the result the ingress PCE would issue updates to 326 the inter-domain LSP. 328 3.2.2.1. Delegation 330 As noted in this document, the inter-domain LSP is delegated to the 331 ingress PCE and only the ingress PCE can issue updates to the inter- 332 domain LSP. The ingress PCE is responsible to trigger E2E path re- 333 optimization. 335 Thus the ingress PCE can recommend updation for all aspects of the 336 inter-domain LSP including the segment of path in another domain 337 (which it may have computed with the help of other cooperating PCEs). 338 These interaction between PCEs for the inter-domain path computation 339 are done using PCReq/PCRep messages (i.e., in a passive mode). 341 The transit/egress PCE cannot update any attribute of the inter- 342 domain LSP on its own as it may not have any interaction with the 343 ingress LSR. A mechanism may be developed for transit/egress PCE to 344 inform the ingress PCE to trigger E2E re-optimization and choose to 345 update the inter-domain LSP based on the result. Also the ingress 346 PCE may use combination of local information and events along with 347 some external mechanism (management / monitoring interface) to 348 trigger E2E path re-optimization. 350 Though ingress PCE can recommend update for path segments in other 351 domains, the entry boundary node of that domain can apply policy 352 control during signaling as explained in [RFC4105] and [RFC4216]. 354 3.2.2.2. PCE-initiated LSP 356 [RFC8281] describes setup, maintenance and teardown of PCE-initiated 357 LSPs under the stateful PCE model, without the need for local 358 configuration on the PCC. Similar to LSP updation, the inter-domain 359 LSP can be initiated by the ingress PCE using the PCInitiate message 360 to the ingress LSR. Note that per-domain LSP may also be initiated 361 by respective domain's PCE and stitched together. 363 3.2.2.3. LSP Stitching 365 [I-D.dugeon-pce-stateful-interdomain] describes a proposal to combine 366 a Backward Recursive method with PCInitiate message to setup 367 independent paths per domain, and combine these different paths 368 together in order to operated them as end-to-end inter-domain paths 369 without the need of signaling session between AS border routers. 371 3.2.3. Hierarchical PCE 373 In H-PCE [RFC6805] architecture, the parent PCE is used to compute a 374 multi-domain path based on the domain connectivity information. The 375 parent PCE may be requested to provide a end-to-end path or only the 376 sequence of domains. 378 As described in Section 3.2.1 and Section 3.2.2, the entry boundary 379 nodes may synchronize the state of inter-domain LSP to transit and 380 egress child PCEs. In this case, it might not be possible to 381 synchronize state to the parent PCE. If the parent PCE provides the 382 sequence of domains and BRPC procedure is used to get the E2E path, 383 each PCE may be responsible to synchronize the state along the path 384 across domains similar to Section 3.2.2. An alternative approach may 385 be for ingress PCE to synchronize LSP state with the Parent PCE and 386 it may further synchronize the state to the child PCE(s) along the 387 path across domains, i.e. parent PCE would report the state to the 388 child PCE(s) along the domain sequence. 390 Some path segment in the end to end path may also be hidden via path- 391 key as per [RFC5520] during state synchronization. 393 In case of passive path computation request to the ingress PCE from 394 the ingress LSR, the H-PCE path computation procedure is applied to 395 compute sequence of domains or end-to-end path by using PCReq and 396 PCRep messages among stateful PCE(s) in passive mode. 398 In case of delegation to the ingress PCE (active stateful PCE), the 399 ingress child PCE may further delegate to parent PCE as per 400 [I-D.ietf-pce-stateful-hpce]. The parent PCE could update the path 401 of the inter-domain LSP. Both per-domain stitched LSP as well as E2E 402 contiguous LSP are possible. Further parent PCE could also initiate 403 the creation of LSP for both per-domain stitched LSP to all child PCE 404 or E2E contiguous LSP to ingress child PCE as described in 405 [I-D.ietf-pce-stateful-hpce]. 407 4. Security Considerations 409 The security considerations are as per [RFC5440] and [RFC8231]. Any 410 multi-domain operation necessarily involves the exchange of 411 information across domain boundaries. This may represent a 412 significant security and confidentiality risk especially when the 413 domains are controlled by different commercial entities. PCEP allows 414 individual PCEs to maintain confidentiality of their domain path 415 information by using path-keys [RFC5520]. 417 5. Manageability Considerations 418 5.1. Control of Function and Policy 420 Mechanisms defined in this document do not imply any new control of 421 function and policy requirements. 423 5.2. Information and Data Models 425 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 426 this document. 428 5.3. Liveness Detection and Monitoring 430 Mechanisms defined in this document do not imply any new liveness 431 detection and monitoring requirements in addition to those already 432 listed in [RFC5440]. 434 5.4. Verify Correct Operations 436 Mechanisms defined in this document do not imply any new operation 437 verification requirements in addition to those already listed in 438 [RFC5440]. 440 5.5. Requirements On Other Protocols 442 Mechanisms defined in this document do not imply any new requirements 443 on other protocols. 445 5.6. Impact On Network Operations 447 Mechanisms defined in this document do not have any impact on network 448 operations in addition to those already listed in [RFC5440]. 450 6. IANA Considerations 452 This is an informational document and has no IANA considerations. 454 7. Acknowledgments 456 The authors would like to that Young Lee, Haomian Zheng, Fatai Zhang 457 for this comments. 459 8. References 461 8.1. Normative References 463 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 464 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 465 DOI 10.17487/RFC5440, March 2009, 466 . 468 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 469 Computation Element Communication Protocol (PCEP) 470 Extensions for Stateful PCE", RFC 8231, 471 DOI 10.17487/RFC8231, September 2017, 472 . 474 8.2. Informative References 476 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 477 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 478 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 479 . 481 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., 482 "Requirements for Inter-Area MPLS Traffic Engineering", 483 RFC 4105, DOI 10.17487/RFC4105, June 2005, 484 . 486 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous 487 System (AS) Traffic Engineering (TE) Requirements", 488 RFC 4216, DOI 10.17487/RFC4216, November 2005, 489 . 491 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 492 Element (PCE)-Based Architecture", RFC 4655, 493 DOI 10.17487/RFC4655, August 2006, 494 . 496 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 497 Per-Domain Path Computation Method for Establishing Inter- 498 Domain Traffic Engineering (TE) Label Switched Paths 499 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 500 . 502 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 503 "A Backward-Recursive PCE-Based Computation (BRPC) 504 Procedure to Compute Shortest Constrained Inter-Domain 505 Traffic Engineering Label Switched Paths", RFC 5441, 506 DOI 10.17487/RFC5441, April 2009, 507 . 509 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 510 "Preserving Topology Confidentiality in Inter-Domain Path 511 Computation Using a Path-Key-Based Mechanism", RFC 5520, 512 DOI 10.17487/RFC5520, April 2009, 513 . 515 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 516 Path Computation Element Architecture to the Determination 517 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 518 DOI 10.17487/RFC6805, November 2012, 519 . 521 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 522 Hardwick, "Path Computation Element Communication Protocol 523 (PCEP) Management Information Base (MIB) Module", 524 RFC 7420, DOI 10.17487/RFC7420, December 2014, 525 . 527 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 528 Stateful Path Computation Element (PCE)", RFC 8051, 529 DOI 10.17487/RFC8051, January 2017, 530 . 532 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 533 Computation Element Communication Protocol (PCEP) 534 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 535 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 536 . 538 [I-D.ietf-pce-stateful-hpce] 539 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 540 and O. Dios, "Hierarchical Stateful Path Computation 541 Element (PCE).", draft-ietf-pce-stateful-hpce-02 (work in 542 progress), October 2017. 544 [I-D.litkowski-pce-state-sync] 545 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 546 Stateful Path Computation Element communication 547 procedures", draft-litkowski-pce-state-sync-02 (work in 548 progress), August 2017. 550 [I-D.dugeon-pce-stateful-interdomain] 551 Dugeon, O. and J. Meuric, "PCEP Extension for Stateful 552 Inter-Domain Tunnels", draft-dugeon-pce-stateful- 553 interdomain-00 (work in progress), October 2017. 555 Appendix A. Contributor Addresses 557 Udayasree Palle 558 Huawei Technologies 559 Divyasree Techno Park, Whitefield 560 Bangalore, Karnataka 560066 561 India 563 EMail: udayasreereddy@gmail.com 565 Avantika 566 Huawei Technologies 567 Divyasree Techno Park, Whitefield 568 Bangalore, Karnataka 560066 569 India 571 EMail: s.avantika.avantika@gmail.com 573 Authors' Addresses 575 Dhruv Dhody 576 Huawei Technologies 577 Divyasree Techno Park, Whitefield 578 Bangalore, Karnataka 560066 579 India 581 EMail: dhruv.ietf@gmail.com 583 Xian Zhang 584 Huawei Technologies 585 Bantian, Longgang District 586 Shenzhen 518129 587 P.R.China 589 EMail: zhang.xian@huawei.com