idnits 2.17.1 draft-dhody-pce-stateful-pce-interdomain-04.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 12, 2017) is 2602 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-10) exists of draft-litkowski-pce-state-sync-01 == Outdated reference: A later version (-03) exists of draft-dhodylee-pce-stateful-hpce-02 Summary: 0 errors (**), 0 flaws (~~), 5 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 13, 2017 March 12, 2017 7 Stateful Path Computation Element (PCE) Inter-domain Considerations 8 draft-dhody-pce-stateful-pce-interdomain-04 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 extentions 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 http://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 13, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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 (http://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.3. Hierarchical PCE . . . . . . . . . . . . . . . . . . 8 69 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Delegation . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. PCE-initiated LSP . . . . . . . . . . . . . . . . . . . . 9 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6. Manageability Considerations . . . . . . . . . . . . . . . . 9 74 6.1. Control of Function and Policy . . . . . . . . . . . . . 9 75 6.2. Information and Data Models . . . . . . . . . . . . . . . 9 76 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 77 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 78 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 79 6.6. Impact On Network Operations . . . . . . . . . . . . . . 10 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 9.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 [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to 99 provide stateful control. A stateful PCE has access to not only the 100 information carried by the network's Interior Gateway Protocol (IGP), 101 but also 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. [I-D.ietf-pce-stateful-pce] applies equally to MPLS-TE 128 and GMPLS LSPs and distinguishes between an active and a passive 129 stateful PCE. A passive stateful PCE uses LSP state information to 130 optimize path computations but does not actively update LSP state. 131 In contrast, an active stateful PCE may issue recommendations to the 132 network. For example, an active stateful PCE may update LSP 133 parameters for those LSPs that have been delegated control over to 134 the PCE by its PCCs. 136 The capability to compute the routes of end-to-end inter-domain MPLS- 137 TE LSPs is expressed as requirements in [RFC4105] and [RFC4216] and 138 may be realized by PCE(s). PCEs may use one of the following 139 mechanisms to compute end-to-end paths: 141 o a per-domain path computation technique [RFC5152]; 142 o a Backward-Recursive PCE-based Computation (BRPC) mechanism 143 [RFC5441]; 145 o a Hierarchical PCE mechanism [RFC6805]; 147 This document examines the stateful PCE inter-domain considerations 148 for all of these mechanisms. 150 2.1. LSP State Synchronization 152 The population of the LSP-DB using information received from PCCs 153 (ingress LSR) is supported by the stateful PCE extensions defined in 154 [I-D.ietf-pce-stateful-pce] , i.e., via LSP state report messages. 156 The inter-domain LSP state is synchronized to the ingress-PCE from 157 the ingress LSR (PCC), but this PCC cannot synchronize to other PCEs 158 (in transit or egress domains), thus other mechanism must be 159 investigated for this purpose. 161 Either the boundary node of the other domains, would need to 162 synchronize the state of LSP passing though it to the PCE, or a 163 mechanism for synchronization of inter-domain LSPs between the PCEs 164 is required. The former would require small change in the existing 165 state synchronization and reporting where a border node acts as a 166 PCC. The later could use the mechanism described in 167 [I-D.litkowski-pce-state-sync] can be used between the PCEs to 168 synchronize the inter-domain LSP state between each other. Further 169 section provide various considerations for this choice. 171 3. Stateful PCE Deployments 173 There are multiple models to perform PCE-based inter-domain path 174 computation: 176 o A single PCE 178 o Multiple PCEs 180 * without inter-PCE communication 182 * with inter-PCE communication 184 This section describe stateful PCE considerations for each of these 185 deployment models. 187 3.1. Single Stateful PCE, Multiple Domains 189 In this model, inter-domain path computation is performed by a single 190 stateful PCE that has topology visibility into all domains. The 191 inter-domain LSP state is synchronized to the PCE from the ingress 192 LSR (PCC) itself. The PCC may also choose to delegate control over 193 this LSP to the PCE. Thus this model is similar to a single domain 194 in all aspects. 196 Following figure show an example of inter-area case comprising of 197 Area 0,1 and 2. A single stateful PCE is deployed for all areas. 199 ******* 200 * PCE * 201 ******* 203 ! ! 204 ! ! 205 A----B----C----ABR1----D----E----F----ABR2----G----H----I 206 | | | | | | | | | | | 207 | | | | | | | | | | | 208 J----K----L----ABR3----M----N----O----ABR4----P----Q----R 209 ! ! 210 Area 1 ! Area 0 ! Area 2 212 In this model, PCE has visibility into the topology (TED) of all 213 domains as well as the state of all active LSPs (LSP-DB) including 214 inter-domain LSPs. This model is thus well suited to take advantage 215 of all stateful PCE capabilities. 217 It should be noted that in some deployments, a single stateful PCE 218 may not be possible because of administrative and confidentiality 219 concerns. 221 3.2. Multiple Stateful PCE, Multiple Domains 223 In this model, there is at least one PCE per domain, and each PCE has 224 topology (TED) visibility restricted to its own domain. The inter- 225 domain LSP state is synchronized to the ingress-PCE from the ingress 226 LSR (PCC), but this PCC may not be able to synchronize to other PCEs 227 (in transit or egress domains). This PCC may also choose to delegate 228 control over this LSP to the Ingress-PCE, which may issue inter- 229 domain path computation or re-optimization request to other PCEs. An 230 inter-domain LSP that originates in a domain, is synchronized to the 231 PCE in that domain. A new procedure is needed to synchronize state 232 of inter-domain LSP that do not originate in the domain. In other 233 words, inter-domain LSP state should also be synchronized to transit 234 and egress PCEs as the inter-domain LSP traverse through those 235 domains. 237 Following figure show an example of inter-AS case comprising of AS 238 100 and AS 200. A stateful PCE is deployed per AS. 240 ******** ******** 241 * PCE1 * * PCE2 * 242 ******** ******** 244 ! ! 245 ! ! 246 A----B----C----ASBR1------ASBR2----D----E----F 247 | | | | | | | | 248 | | | | | | | | 249 G----H----I----ASBR3------ASBR4----J----K----L 250 ! ! 251 AS100 ! ! AS200 253 In order to conceal the information, a PCE may use path-key based 254 confidentiality mechanisms as per [RFC5520]. 256 This section further describes considerations with respect to each of 257 the inter-domain path computation techniques. 259 3.2.1. Per Domain Path Computation 261 The per domain path computation technique [RFC5152] is based on 262 Multiple PCE Path Computation without Inter-PCE Communication Model 263 as described in [RFC4655]. It defines a method where the path is 264 computed during the signaling process (on a per-domain basis). The 265 entry Boundary Node (BN) of each domain is responsible for performing 266 the path computation for the section of the LSP that crosses the 267 domain, or for requesting that a PCE for that domain computes that 268 piece of the path. 270 The ingress LSR would synchronize the state to the ingress PCE, 271 further the entry boundary nodes should also synchronize the state of 272 inter-domain LSP to transit and egress PCEs. Note that the BN on the 273 path of an LSP can probably see the path (through the Record Route 274 object in RSVP-TE signaling [RFC3209]) and knows the bandwidth 275 reserved for the LSP. Thus each entry BN along the path could be 276 made responsible to synchronize the LSP state to the transit/egress 277 PCE(s). 279 Since the stateful PCE(s) do not communicate during this inter-domain 280 path computation technique and each entry BN would perform path 281 computation via Path Computation Request (PCReq) and Reply (PCRep) 282 messages, a passive stateful PCE is well suited for this case. 284 In case of delegation to the ingress PCE (active stateful PCE), it 285 would be capable of loose path computation only and make updates to 286 the ingress LSR with this limited visibility. The entry BN would 287 perform path computation via Path Computation Request and Reply 288 messages (and thus rely on the passive stateful mode). Thus the 289 inter-domain LSP is delegated only to the ingress PCE. 291 3.2.2. Backward-Recursive PCE-based Computation 293 The BRPC [RFC5441] technique is based on Multiple PCE Path 294 Computation with Inter-PCE Communication Model as described in 295 [RFC4655]. It involves cooperation and communication between PCEs in 296 order to compute an optimal end-to-end path across multiple domains. 297 The sequence of domains to be traversed may be known before the path 298 computation, but it can also be used when the domain path is unknown 299 and determined during path computation. 301 As described in Section 3.2.1, the entry boundary nodes may 302 synchronize the state of inter-domain LSPs to transit and egress 303 PCEs. An alternative approach may be for each PCE to synchronize the 304 state along the path across domains, i.e., each PCE would report the 305 state to the next PCE(s) in the adjacent domain along the domain 306 sequence of the inter-domain path. A mechanism described in 307 [I-D.litkowski-pce-state-sync] can be utilized to synchronize 308 between inter-domain PCEs. 310 Some path segment in the end to end path may also be hidden via path- 311 key as per [RFC5520] during state synchronization. 313 In case of passive path computation request to the ingress PCE from 314 the ingress LSR the BRPC path computation procedure is applied to 315 compute end-to-end path by using PCReq and PCRep messages among 316 stateful PCE(s) in passive mode. 318 In case of delegation to the ingress PCE (active stateful PCE), the 319 ingress PCE may trigger the end-to-end path computation via the same 320 BRPC procedure using the path computation request and reply messages 321 among stateful PCE(s) (acting in passive mode). For re-optimization 322 the ingress PCE still rely on the same BRPC procedure triggered by 323 the ingress PCE. Ultimately the inter-domain LSP is delegated to the 324 ingress PCE and only the ingress PCE can trigger end-to-end (E2E) 325 path re-optimization with help of transit/egress PCE using the BRPC 326 procedure, based on the result the ingress PCE would issue updates to 327 the inter-domain LSP. 329 3.2.3. Hierarchical PCE 331 In H-PCE [RFC6805] architecture, the parent PCE is used to compute a 332 multi-domain path based on the domain connectivity information. The 333 parent PCE may be requested to provide a end-to-end path or only the 334 sequence of domains. 336 As described in Section 3.2.1 and Section 3.2.2, the entry boundary 337 nodes may synchronize the state of inter-domain LSP to transit and 338 egress child PCEs. In this case, it might not be possible to 339 synchronize state to the parent PCE. If the parent PCE provides the 340 sequence of domains and BRPC procedure is used to get the E2E path, 341 each PCE may be responsible to synchronize the state along the path 342 across domains similar to Section 3.2.2. An alternative approach may 343 be for ingress PCE to synchronize LSP state with the Parent PCE and 344 it may further synchronize the state to the child PCE(s) along the 345 path across domains, i.e. parent PCE would report the state to the 346 child PCE(s) along the domain sequence. A mechanism described in 347 [I-D.litkowski-pce-state-sync] can be utilized to synchronize 348 between the child and the parent PCE. 350 Some path segment in the end to end path may also be hidden via path- 351 key as per [RFC5520] during state synchronization. 353 In case of passive path computation request to the ingress PCE from 354 the ingress LSR, the H-PCE path computation procedure is applied to 355 compute sequence of domains or end-to-end path by using PCReq and 356 PCRep messages among stateful PCE(s) in passive mode. 358 In case of delegation to the ingress PCE (active stateful PCE), the 359 ingress child PCE may further delegate to parent PCE. See 360 [I-D.dhodylee-pce-stateful-hpce] for details. 362 4. Other Considerations 364 4.1. Delegation 366 As noted in this document, the inter-domain LSP is delegated to the 367 ingress PCE and only the ingress PCE can issue updates to the inter- 368 domain LSP. The ingress PCE is responsible to trigger E2E path re- 369 optimization. 371 Thus the ingress PCE can recommend updation for all aspects of the 372 inter-domain LSP including the segment of path in another domain 373 (which it may have computed with the help of other cooperating PCEs). 374 These interaction between PCEs for the inter-domain path computation 375 are done using PCReq/PCRep messages (i.e., in a passive mode). 377 The transit/egress PCE cannot update any attribute of the inter- 378 domain LSP on its own as it may not have any interaction with the 379 ingress LSR. A mechanism may be developed for transit/egress PCE to 380 inform the ingress PCE to trigger E2E re-optimization and choose to 381 update the inter-domain LSP based on the result. Also the ingress 382 PCE may use combination of local information and events along with 383 some external mechanism (management / monitoring interface) to 384 trigger E2E path re-optimization. 386 Though ingress PCE can recommend update for path segments in other 387 domains, the entry boundary node of that domain can apply policy 388 control during signalling as explained in [RFC4105] and [RFC4216]. 390 4.2. PCE-initiated LSP 392 [I-D.ietf-pce-pce-initiated-lsp] describes setup, maintenance and 393 teardown of PCE-initiated LSPs under the stateful PCE model, without 394 the need for local configuration on the PCC. Similar to LSP 395 updation, the inter-domain LSP can be initiated by the ingress PCE 396 using the PCInitiate message to the ingress LSR. Note that per- 397 domain LSP may also be initiated by respective domain's PCE and 398 stitched together but this is out of scope for this document. 400 5. Security Considerations 402 The security considerations are as per [RFC5440] and 403 [I-D.ietf-pce-stateful-pce]. Any multi-domain operation necessarily 404 involves the exchange of information across domain boundaries. This 405 may represent a significant security and confidentiality risk 406 especially when the domains are controlled by different commercial 407 entities. PCEP allows individual PCEs to maintain confidentiality of 408 their domain path information by using path-keys [RFC5520]. 410 6. Manageability Considerations 412 6.1. Control of Function and Policy 414 Mechanisms defined in this document do not imply any new control of 415 function and policy requirements. 417 6.2. Information and Data Models 419 [RFC7420] describes the PCEP MIB, there are no new MIB Objects for 420 this document. 422 6.3. Liveness Detection and Monitoring 424 Mechanisms defined in this document do not imply any new liveness 425 detection and monitoring requirements in addition to those already 426 listed in [RFC5440]. 428 6.4. Verify Correct Operations 430 Mechanisms defined in this document do not imply any new operation 431 verification requirements in addition to those already listed in 432 [RFC5440]. 434 6.5. Requirements On Other Protocols 436 Mechanisms defined in this document do not imply any new requirements 437 on other protocols. 439 6.6. Impact On Network Operations 441 Mechanisms defined in this document do not have any impact on network 442 operations in addition to those already listed in [RFC5440]. 444 7. IANA Considerations 446 This is an informational document and has no IANA considerations. 448 8. Acknowledgments 450 The authors would like to that Young Lee, Haomian Zheng, Fatai Zhang 451 for this comments. 453 9. References 455 9.1. Normative References 457 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 458 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 459 DOI 10.17487/RFC5440, March 2009, 460 . 462 [I-D.ietf-pce-stateful-pce] 463 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 464 Extensions for Stateful PCE", draft-ietf-pce-stateful- 465 pce-18 (work in progress), December 2016. 467 9.2. Informative References 469 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 470 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 471 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 472 . 474 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., 475 "Requirements for Inter-Area MPLS Traffic Engineering", 476 RFC 4105, DOI 10.17487/RFC4105, June 2005, 477 . 479 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous 480 System (AS) Traffic Engineering (TE) Requirements", 481 RFC 4216, DOI 10.17487/RFC4216, November 2005, 482 . 484 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 485 Element (PCE)-Based Architecture", RFC 4655, 486 DOI 10.17487/RFC4655, August 2006, 487 . 489 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 490 Per-Domain Path Computation Method for Establishing Inter- 491 Domain Traffic Engineering (TE) Label Switched Paths 492 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 493 . 495 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 496 "A Backward-Recursive PCE-Based Computation (BRPC) 497 Procedure to Compute Shortest Constrained Inter-Domain 498 Traffic Engineering Label Switched Paths", RFC 5441, 499 DOI 10.17487/RFC5441, April 2009, 500 . 502 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 503 "Preserving Topology Confidentiality in Inter-Domain Path 504 Computation Using a Path-Key-Based Mechanism", RFC 5520, 505 DOI 10.17487/RFC5520, April 2009, 506 . 508 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 509 Path Computation Element Architecture to the Determination 510 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 511 DOI 10.17487/RFC6805, November 2012, 512 . 514 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 515 Hardwick, "Path Computation Element Communication Protocol 516 (PCEP) Management Information Base (MIB) Module", 517 RFC 7420, DOI 10.17487/RFC7420, December 2014, 518 . 520 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 521 Stateful Path Computation Element (PCE)", RFC 8051, 522 DOI 10.17487/RFC8051, January 2017, 523 . 525 [I-D.ietf-pce-pce-initiated-lsp] 526 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 527 Extensions for PCE-initiated LSP Setup in a Stateful PCE 528 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 529 progress), March 2017. 531 [I-D.litkowski-pce-state-sync] 532 Litkowski, S., Sivabalan, S., and D. Dhody, "Inter 533 Stateful Path Computation Element communication 534 procedures", draft-litkowski-pce-state-sync-01 (work in 535 progress), February 2017. 537 [I-D.dhodylee-pce-stateful-hpce] 538 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 539 and O. Dios, "Hierarchical Stateful Path Computation 540 Element (PCE).", draft-dhodylee-pce-stateful-hpce-02 (work 541 in progress), October 2016. 543 Appendix A. Contributor Addresses 545 Udayasree Palle 546 Huawei Technologies 547 Divyasree Techno Park, Whitefield 548 Bangalore, Karnataka 560066 549 India 551 EMail: udayasree.palle@huawei.com 553 Avantika 554 Huawei Technologies 555 Divyasree Techno Park, Whitefield 556 Bangalore, Karnataka 560066 557 India 559 EMail: avantika.sushilkumar@huawei.com 561 Authors' Addresses 563 Dhruv Dhody 564 Huawei Technologies 565 Divyasree Techno Park, Whitefield 566 Bangalore, Karnataka 560066 567 India 569 EMail: dhruv.ietf@gmail.com 571 Xian Zhang 572 Huawei Technologies 573 Bantian, Longgang District 574 Shenzhen 518129 575 P.R.China 577 EMail: zhang.xian@huawei.com