idnits 2.17.1 draft-lee-teas-te-service-mapping-yang-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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2017) is 2605 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ACTN-Applicability' is mentioned on line 91, but not defined == Missing Reference: 'L3SM-Yang' is mentioned on line 148, but not defined == Missing Reference: 'RFC3688' is mentioned on line 647, but not defined == Missing Reference: 'RFC7950' is mentioned on line 658, but not defined == Unused Reference: 'Netconf' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'Restconf' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'TE-Topology' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'TE-Tunnel' is defined on line 706, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS WG Young Lee 2 Dhruv Dhody 3 Internet Draft Huawei 4 Intended status: standard 5 Daniele Ceccarrelli 6 Expires: September 2017 Ericsson 8 - 10 March 9, 2017 12 Traffic Engineering and Service Mapping Yang Model 13 draft-lee-teas-te-service-mapping-yang-00 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with 18 the provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 9, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 This document provides a YANG data model to map service model (e.g. 56 L3SM) and Traffic Engineering model (e.g. TE Tunnel or ACTN VN 57 model). This model is referred to as TE service Mapping Model. This 58 model is applicable to the operation's need for a seamless control 59 and management of their L3VPN with TE tunnel support. 61 Table of Contents 63 1. Introduction...................................................2 64 2. L3VPN Architecture in ACTN context.............................4 65 3. TE-Service Mapping Model.......................................7 66 4. YANG Data Tree.................................................7 67 5. Yang Data Model................................................9 68 6. Security......................................................16 69 7. Acknowledgements..............................................16 70 8. References....................................................17 71 8.1. Informative References...................................17 72 9. Contributors..................................................18 73 Authors' Addresses...............................................18 75 1. Introduction 77 Data models are a representation of objects that can be configured 78 or monitored within a system. Within the IETF, YANG [RFC6020] is the 79 language of choice for documenting data models, and YANG models have 80 been produced to allow configuration or modeling of a variety of 81 network devices, protocol instances, and network services. YANG data 82 models have been classified in [Netmod-Yang-Model-Classification] 83 and [Service-YANG]. 85 [RFC4110] provides a framework for Layer 3 Provider-Provisioned 86 Virtual Private Networks (PPVPNs). [L3SM-YANG] provides a L3VPN 87 service delivery YANG model for PE-based VPNs. 89 [ACTN-VN-YANG] describes how customers or end to end orchestrators 90 can request and/or instantiate a generic virtual network service. 91 [ACTN-Applicability] describes a connection between IETF YANG model 92 classifications to ACTN interfaces. In particular, it describes the 93 customer service model can be mapped into the CMI (CNC-MDSC 94 Interface) of the ACTN architecture. 96 The YANG model on the ACTN CMI is known as customer service model in 97 [Service-YANG]. The YANG model developed in this document describes 98 how operator's end to end orchestrator interacts with the MDSC so 99 that the MDSC then can coordinate the control and management of 100 L3VPN MPLS TE tunnels that traverse both IP/MPLS and Transport 101 networks. 103 While IP/MPLS PNC is responsible for provisioning the VPN service on 104 the PE nodes, the MDSC can coordinate how to map the VPN services 105 with TE tunnels. This is consistent with the two of the core 106 functions of the MDSC specified in [ACTN-Frame]: 108 . Customer mapping/translation function: This function is to map 109 customer requests/commands into network provisioning requests 110 that can be sent to the Physical Network Controller (PNC) 111 according to business policies provisioned statically or 112 dynamically. Specifically, it provides mapping and translation 113 of a customer's service request into a set of parameters that 114 are specific to a network type and technology such that network 115 configuration process is made possible. 117 . Virtual service coordination function: This function translates 118 customer service-related information into virtual network 119 service operations in order to seamlessly operate virtual 120 networks while meeting a customer's service requirements. In 121 the context of ACTN, service/virtual service coordination 122 includes a number of service orchestration functions such as 123 multi-destination load balancing, guarantees of service 124 quality, bandwidth and throughput. It also includes 125 notifications for service fault and performance degradation and 126 so forth. 128 In some cases, under the confines of service policy, dynamic TE 129 tunnel creation may need to be supported for the VPN service. This 130 may occur when there are no suitable existing TE tunnels that can 131 support VPN service requirements. Or the operator would like to 132 dynamically create and bind tunnels to the VPN, which could not be 133 shared for network slicing. 135 To summarize there are two mode of operations - 137 . VN/Tunnel Binding - Customer could use the VPN service model 138 [L3SM-Yang] to communicate to the network operator to deliver 139 a L3VPN service. Based on the sites, QoS parameters, VPN service 140 topology, the network operator could create an ACTN VN [ACTN-VN- 141 YANG]. Further the mapping yang model described in Section 5 of 142 this document is used to set this mapping between the L3VPN 143 service and the ACTN VN. Note that this could be done dynamically. 144 The VN (and TE tunnels) could be bound to the L3VPN and not used 145 for any other VPN. 147 . VN/Tunnel Selection - Customer could request an L3VPN service 148 [L3SM-Yang], and with this model as input, the PNC configures the 149 different network elements to deliver the service. Each network 150 element would select a tunnel based on the configuration. With 151 this mode, new tunnels (or VN) are not created for each VPN. Thus, 152 the tunnels can be shared across multiple VPN. Further the mapping 153 yang model described in Section 5 of this document is used to get 154 the mapping between the L3VPN and the tunnels in use. 156 The YANG model described in this document provides an ACTN TE- 157 service mapping model that enables a seamless service mapping across 158 L3VPN, ACTN VN and TE-tunnel models at the controllers. 160 2. L3VPN Architecture in ACTN context 162 Figure 1 shows the architectural context of this document. 164 | L3SM (+CMI) 165 V 166 +------+ 167 | MDSC | 168 +------+ 169 | 170 +-------------------------------+ 171 | | | 172 V V V 173 +--------+ +--------+ +--------+ 174 |IP/MPLS | | Transp.| |IP/MPLS | 175 | PNC 1 | | PNC | | PNC 2 | 176 +--------+ +--------+ +--------+ 178 CE CE 179 \ AS 100 AS 200 / 180 \ / 181 A----B----C----ASBR1------ASBR2----D----E----F 182 /: / /: /: /: /: /: /: 183 / : / / : / : / : / : / : / : 184 CE----G--:-H----I--:-ASBR3-:----ASBR4-:--J--:-K--:-L--:---CE 185 : : : : : : : : : : : : : : 186 : : : : : : : : : : : : : : 187 : : : : : : : : : : : : : : 188 : M-:----:--P---:---S------:---U-----V-:--X-:--Y 189 : / : : / : / : / : / : / 190 :/ : :/ : / : / :/ :/ 191 N----O----Q-------R----------T----------W----Z 192 Transport Network 194 Figure 1: L3VPN Architecture from the IP+Optical Network Perspective 196 There are three main entities in the architecture. 198 . MDSC: This entity is responsible for coordinating a L3VPN service 199 request (expressed in L3SM) with the IP PNC and the Transport PNC. 200 One of the key responsibilities of the MDSC for TE services is to 201 coordinate with both the IP PNC and the Transport PNC for the 202 mapping of L3VPN Service Model and ACTN VN/TE-Tunnel models. With 203 the VN/TE-tunnel binding case, the MDSC will need to coordinate 204 with the Transport PNC to dynamically create the TE-tunnel(s) in 205 the Transport network as needed. These tunnels are added as links 206 in the IP Layer topology. The MDSC coordinates with IP PNC to 207 create the TE-tunnel(s) in the IP layer, as part of the ACTN VN 208 creation. 210 . IP/MPLS PNC: This entity is responsible for device configuration 211 to create PE-PE L3VPN tunnels for the VPN customer and for the 212 configuration of the L3VPN VRF on the PE nodes. Each network 213 element would select a tunnel based on the configuration. 215 . Transport PNC: This entity is responsible for device configuration 216 for TE tunnels in the transport networks. 218 High-Level Control Flows 220 1. Customer asks for a L3VPN between CE1 and CE2 with TE 221 constraints using L3SM model. The customer can provide tunnel 222 creation policy where it allows dynamic VN/TE tunnel creation 223 or not. Under this policy, dynamic VN/TE tunnels can be created 224 when there are no proper VN/TE-tunnels that can support L3VPN 225 tunnels or when there is a strict isolation requirement for the 226 VPN service, e.g., no sharing with other tunnels is allowed. 228 2. The MDSC determines if it needs to create a new VN, and if that 229 is the case, ACTN VN YANG [ACTN-VN-YANG] is used to configure a 230 new VN based on this VPN and map the VPN service to ACTN VN. In 231 case an existing tunnel is to be used, each device will select 232 which tunnel to use and populates this mapping information. 234 3. The MDSC interacts with both the IP/MPLS PNC and the Transport 235 PNC to create a PE-PE tunnel in the IP network mapped to a TE 236 tunnel in the transport network by providing the inter-layer 237 access points and tunnel requirements. The specific service 238 information are passed to the IP/MPLS PNC for the actual VPN 239 configuration and activation. 241 a. The Transport PNC creates the corresponding TE tunnel 242 matching with the access point and egress point. 243 b. The IP/MPLS PNC maps the VPN ID with the corresponding TE 244 tunnel ID to bind these two IDs. 246 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 247 customer. (This is not covered by the Yang Model presented in 248 this draft). 250 3. TE-Service Mapping Model 252 The role of TE-service Mapping model is to create a binding 253 relationship across L3SM and TE Tunnel model via generic ACTN VN 254 Model. The ACTN VN YANG model is a generic virtual network service 255 model that allows customers (internal or external) to create a VN 256 that meets the customer's service objective with various 257 constraints. The TE-service mapping model is needed to bind L3VPN 258 specific service model with TE-specific parameters. This binding 259 will facilitate a seamless service operation with underlay-TE 260 network visibility. The TE-service model developed in this document 261 can also be extended to support other services such as L2SM and so 262 one. 264 +---------+ +-------------+ +----------+ 265 | L3SM | <------> | | <-----> | TE-Tunnel| 266 +---------+ | | | Model | 267 | TE-Service | +-----^----+ 268 |Mapping Model| | 269 +---------+ | | +-----v----+ 270 | L2SM | <------> | | <-----> | ACTN VN | 271 +---------+ +-------------+ | Model | 272 +----------+ 274 . . . 276 4. YANG Data Tree 278 module: ietf-te-service-mapping 279 +--rw te-service-mapping 280 | +--rw service-mapping 281 | | +--rw mapping-list* [map-id] 282 | | +--rw map-id uint32 283 | | +--rw map-type? map-type 284 | | +--rw (service)? 285 | | | +--:(l3vpn) 286 | | | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/vpn-services/vpn- 287 service/vpn-id 288 | | | +--:(l2vpn) 289 | | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/vpn-services/vpn- 290 svc/vpn-id 291 | | +--rw (te)? 292 | | +--:(actn-vn) 293 | | | +--rw actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id 294 | | +--:(te) 295 | | +--rw te-tunnel-list* te:tunnel-ref 296 | +--rw site-mapping 297 | +--rw mapping-list* [map-id] 298 | +--rw map-id uint32 299 | +--rw (service)? 300 | | +--:(l3vpn) 301 | | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/sites/site/site-id 302 | | +--:(l2vpn) 303 | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/sites/site/site-id 304 | +--rw (te)? 305 | +--:(actn-vn) 306 | | +--rw actn-vn-ref? -> /vn:actn/ap/access-point-list/access- 307 point-id 308 | +--:(te) 309 +--ro te-service-mapping-state 310 +--ro service-mapping 311 | +--ro mapping-list* [map-id] 312 | +--ro map-id uint32 313 | +--ro map-type? map-type 314 | +--ro (service)? 315 | | +--:(l3vpn) 316 | | | +--ro l3vpn-ref? -> /l3:l3vpn-svc/vpn-services/vpn- 317 service/vpn-id 318 | | +--:(l2vpn) 319 | | +--ro l2vpn-ref? -> /l2:l2vpn-svc/vpn-services/vpn- 320 svc/vpn-id 321 | +--ro (te)? 322 | +--:(actn-vn) 323 | | +--ro actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id 324 | +--:(te) 325 | +--ro te-tunnel-list* te:tunnel-ref 326 +--ro site-mapping 327 +--ro mapping-list* [map-id] 328 +--ro map-id uint32 329 +--ro (service)? 330 | +--:(l3vpn) 331 | | +--ro l3vpn-ref? -> /l3:l3vpn-svc/sites/site/site-id 332 | +--:(l2vpn) 333 | +--ro l2vpn-ref? -> /l2:l2vpn-svc/sites/site/site-id 334 +--ro (te)? 335 +--:(actn-vn) 336 | +--ro actn-vn-ref? -> /vn:actn/ap/access-point-list/access- 337 point-id 338 +--:(te) 340 5. Yang Data Model 342 The YANG code is as follows: 344 file "ietf-te-service-mapping@2017-03-09.yang" 346 module ietf-te-service-mapping { 348 namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping"; 350 prefix "tm"; 352 import ietf-l3vpn-svc { 353 prefix "l3"; 354 } 356 import ietf-l2vpn-svc { 357 prefix "l2"; 358 } 360 import ietf-te { 361 prefix "te"; 362 } 364 import ietf-actn-vn { 365 prefix "vn"; 366 } 368 organization 369 "IETF Traffic Engineering Architecture and Signaling (TEAS) 370 Working Group"; 372 contact 373 "Editor: Young Lee 374 Dhruv Dhody "; 376 description 377 "This module contains a YANG module for the mapping of 378 service (e.g. L3VPN) to the TE tunnels or ACTN VN."; 380 revision 2017-03-09 { 381 description 382 "initial version."; 383 reference 384 "TBD"; 385 } 387 /* 388 * Identities 389 */ 390 identity service-type { 391 description 392 "Base identity from which specific service types are 393 derived."; 394 } 396 identity l3vpn-service { 397 base service-type; 398 description 399 "L3VPN service type."; 400 } 402 identity l2vpn-service { 403 base service-type; 404 description 405 "L2VPN service type."; 406 } 408 /* 409 * Enum 410 */ 411 typedef map-type { 412 type enumeration { 413 enum "bind" { 414 description 415 "The VN/tunnels are binded to the service"; 416 } 417 enum "select" { 418 description 419 "The VPN service select an existing tunnel"; 421 } 422 } 423 description 424 "The map-type"; 425 } 427 /* 428 * Groupings 429 */ 430 grouping service-ref{ 431 description 432 "The reference to the service."; 433 choice service { 434 description 435 "The service"; 436 case l3vpn { 437 leaf l3vpn-ref { 438 type leafref { 439 path "/l3:l3vpn-svc/l3:vpn-services/" 440 + "l3:vpn-service/l3:vpn-id"; 441 } 442 description 443 "The reference to L3VPN Service Yang Model"; 444 } 445 } 446 case l2vpn { 447 leaf l2vpn-ref { 448 type leafref { 449 path "/l2:l2vpn-svc/l2:vpn-services/" 450 + "l2:vpn-svc/l2:vpn-id"; 451 } 452 description 453 "The reference to L2VPN Service Yang Model"; 454 } 456 } 458 } 459 } 461 grouping site-ref { 462 description 463 "The reference to the site."; 464 choice service { 465 description 466 "The service choice"; 467 case l3vpn { 468 leaf l3vpn-ref{ 469 type leafref { 470 path "/l3:l3vpn-svc/l3:sites/l3:site/" 471 + "l3:site-id"; 472 } 473 description 474 "The reference to L3VPN Service Yang Model"; 475 } 476 } 477 case l2vpn { 478 leaf l2vpn-ref{ 479 type leafref { 480 path "/l2:l2vpn-svc/l2:sites/l2:site/" 481 + "l2:site-id"; 482 } 483 description 484 "The reference to L2VPN Service Yang Model"; 485 } 487 } 489 } 490 } 492 grouping te-ref { 493 description 494 "The reference to TE."; 495 choice te { 496 description 497 "The TE"; 498 case actn-vn { 499 leaf actn-vn-ref { 500 type leafref { 501 path "/vn:actn/vn:vn/vn:vn-list/vn:vn-id"; 502 } 503 description 504 "The reference to ACTN VN"; 505 } 506 } 507 case te { 508 leaf-list te-tunnel-list { 509 type te:tunnel-ref; 510 description 511 "Reference to TE Tunnels"; 512 } 513 } 515 } 517 } 519 grouping te-endpoint-ref { 520 description 521 "The reference to TE endpoints."; 522 choice te { 523 description 524 "The TE"; 525 case actn-vn { 526 leaf actn-vn-ref { 527 type leafref { 528 path "/vn:actn/vn:ap/vn:access-point-list" 529 + "/vn:access-point-id"; 530 } 531 description 532 "The reference to ACTN VN"; 533 } 534 } 535 case te { 536 /*should we refer to Te-topology or Te-tunnel's 537 endpoint(?)*/ 538 } 540 } 542 } 543 grouping service-mapping { 544 description 545 "Mapping between Services and TE"; 546 container service-mapping { 547 description 548 "Mapping between Services and TE"; 550 list mapping-list { 551 key "map-id"; 552 description 553 "Mapping identified via a map-id"; 554 leaf map-id { 555 type uint32; 556 description 557 "a unique mapping identifier"; 558 } 559 leaf map-type { 560 type map-type; 561 description 562 "Tunnel Bind or Tunnel Selection"; 563 } 564 uses service-ref; 566 uses te-ref; 567 } 568 } 569 } 570 grouping site-mapping { 571 description 572 "Mapping between VPN access site and TE 573 endpoints or AP"; 574 container site-mapping { 575 description 576 "Mapping between VPN access site and TE 577 endpoints or AP"; 578 list mapping-list { 579 key "map-id"; 580 description 581 "Mapping identified via a map-id"; 582 leaf map-id { 583 type uint32; 584 description 585 "a unique mapping identifier"; 586 } 587 uses site-ref; 589 uses te-endpoint-ref; 590 } 592 } 593 } 595 /* 596 * Configuration data nodes 597 */ 598 container te-service-mapping { 599 description 600 "Mapping between Services and TE"; 602 uses service-mapping; 604 uses site-mapping; 605 } 607 /* 608 * Operational data nodes 609 */ 611 container te-service-mapping-state{ 612 config false; 614 description 615 "Mapping between Services and TE"; 617 uses service-mapping; 619 uses site-mapping; 620 } 622 } 624 626 6. Security 628 This document is an informational draft. When the models mentioned 629 in this draft are implemented, detailed security consideration will 630 be given in such work. 632 How security fits into the whole architecture has the following 633 components: 635 - the use of Restconf security between components 637 - the use of authentication and policy to govern which services can 638 be requested by different parties. 640 - how security may be requested as an element of a service and 641 mapped down to protocol security mechanisms as well as separation 642 (slicing) of physical resources) 644 7. IANA Considerations 646 This document registers the following namespace URIs in the IETF XML 647 registry [RFC3688]: 649 -------------------------------------------------------------------- 650 URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping 651 Registrant Contact: The IESG. 652 XML: N/A, the requested URI is an XML namespace. 653 -------------------------------------------------------------------- 655 This document registers the following YANG modules in the YANG 656 Module 658 Names registry [RFC7950]: 660 -------------------------------------------------------------------- 661 name: ietf-service-mapping 662 namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping 663 prefix: rip 664 reference: RFC XXXX (TDB) 665 -------------------------------------------------------------------- 667 8. Acknowledgements 669 We thank Diego Caviglia and Igor Bryskin for useful discussions and 670 motivation for this work. 672 9. References 674 9.1. Informative References 676 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 677 Provider-Provisioned Virtual Private Networks (PPVPNs)", 678 RFC 4110, July 2005. 680 [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for 681 the Network Configuration Protocol (NETCONF)", RFC 6020, 682 October 2010. 684 [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 685 Explained", draft-wu-opsawg-service-model-explained, work 686 in progress. 688 [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. 689 Moberg, "YANG Module Classification", draft-ietf-netmod- 690 yang-model-classification, work in progress. 692 [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 693 and A. Bierman, Ed., "Network Configuration Protocol 694 (NETCONF)", RFC 6241. 696 [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF 697 Protocol", draft-ietf-netconf-restconf, work in progress. 699 [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and 700 Control of Traffic Engineered Networks", draft-ietf-teas- 701 actn-framework, work in progress. 703 [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", 704 draft-ietf-teas-yang-te-topo, work in progress. 706 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic 707 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 708 te, work in progress. 710 [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN 711 Operation", draft-lee-teas-actn-vn-yang, work in progress. 713 [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model 714 for L3VPN service delivery", draft-ietf-l3sm-l3vpn- 715 service-model, work in progress. 717 10. Contributors 719 Authors' Addresses 721 Young Lee 722 Huawei Technologies 723 5340 Legacy Drive 724 Plano, TX 75023, USA 725 Phone: (469)277-5838 727 Email: leeyoung@huawei.com 729 Dhruv Dhody 730 Huawei Technologies 732 Email: dhruv.ietf@gmail.com 734 Daniele Ceccarelli 735 Ericsson 736 Torshamnsgatan,48 737 Stockholm, Sweden 739 Email: daniele.ceccarelli@ericsson.com