idnits 2.17.1 draft-zheng-ccamp-client-topo-yang-03.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 70 instances of too long lines in the document, the longest one being 70 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 (August 30, 2018) is 2065 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ccamp-otn-tunnel-model' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC7139' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'RFC7062' is defined on line 685, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-05 == Outdated reference: A later version (-20) exists of draft-ietf-ccamp-otn-tunnel-model-05 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-18 == Outdated reference: A later version (-28) exists of draft-ietf-ccamp-wson-yang-13 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group H. Zheng 3 Internet-Draft A. Guo 4 Intended status: Standards Track I. Busi 5 Expires: March 3, 2019 Huawei Technologies 6 Y. Xu 7 CAICT 8 Y. Zhao 9 China Mobile 10 X. Liu 11 Volta Networks 12 G. Fioccola 13 Telecom Italia 14 August 30, 2018 16 A YANG Data Model for Client-layer Topology 17 draft-zheng-ccamp-client-topo-yang-03 19 Abstract 21 A transport network is a server-layer network to provide connectivity 22 services to its client. In this draft the topology of client is 23 described. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 3, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Notations . . . . . . . . . . . . . . . . . . 3 61 3. YANG Model for Topology of Client Layer . . . . . . . . . . . 3 62 3.1. YANG Tree for Ethernet Topology . . . . . . . . . . . . . 3 63 3.2. YANG Tree for topology Model of other Client Layer . . . 5 64 4. YANG Code for Topology Client Layer . . . . . . . . . . . . . 5 65 4.1. The ETH Topology YANG Code . . . . . . . . . . . . . . . 5 66 4.2. Other OTN client signal YANG Code . . . . . . . . . . . . 13 67 5. Considerations and Open Issue . . . . . . . . . . . . . . . . 13 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 7. Manageability Considerations . . . . . . . . . . . . . . . . 13 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 11.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 A transport network is a server-layer network designed to provide 81 connectivity services for a client-layer network to carry the client 82 traffic transparently across the server-layer network resources. The 83 topology model in Traffic-Engineered network has been defined in both 84 generic way and technology-specific way. The generic model, which is 85 the base TE YANG model, can be found at [I-D.ietf-teas-yang-te-topo]. 86 Technology-specific models, such as OTN/WSON topology model, have 87 also been defined in [I-D.ietf-ccamp-otn-topo-yang] and 88 [I-D.ietf-ccamp-wson-yang] respectively. Corresponding topology on 89 client-layer is also required, to have a complete topology view from 90 the perspective of network controllers. 92 This document defines a data model of all client-layer Topology, 93 using YANG language defined in [RFC7950]. The model is augmenting 94 the generic TE topology model, and can be used by either applications 95 exposing to a network controller or among controllers. Furthermore, 96 it can be used by an application for topology description in client- 97 layer network. 99 2. Terminology and Notations 101 A simplified graphical representation of the data model is used in 102 this document. The meaning of the symbols in the YANG data tree 103 presented later in this document is defined in [RFC8340]. They are 104 provided below for reference. 106 o Brackets "[" and "]" enclose list keys. 108 o Abbreviations before data node names: "rw" means configuration 109 (read-write) and "ro" state data (read-only). 111 o Symbols after data node names: "?" means an optional node, "!" 112 means a presence container, and "*" denotes a list and leaf-list. 114 o Parentheses enclose choice and case nodes, and case nodes are also 115 marked with a colon (":"). 117 o Ellipsis ("...") stands for contents of subtrees that are not 118 shown. 120 3. YANG Model for Topology of Client Layer 122 3.1. YANG Tree for Ethernet Topology 124 module: ietf-eth-te-topology 125 augment /nd:networks/nd:network/nd:network-types/tet:te-topology: 126 +--rw eth-tran-topology! 127 augment /nd:networks/nd:network/lnk:link/tet:te/tet:te-link-attributes: 128 +--rw max-bandwidth? uint64 129 +--rw available-bandwidth? uint64 130 +--rw available-vlan-range? etht-types:vid-range-type 131 augment /nd:networks/nd:network/nd:node/lnk:termination-point: 132 +--rw ltp-mac-address? yang:mac-address 133 +--rw port-vlan-id? etht-types:vlanid 134 +--rw maximum-frame-size? uint16 135 +--rw (direction)? 136 | +--:(symmetrical) 137 | | +--rw ingress-egress-bandwidth-profile 138 | | +--rw bandwidth-profile-name? string 139 | | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 140 | | +--rw CIR? uint64 141 | | +--rw CBS? uint64 142 | | +--rw EIR? uint64 143 | | +--rw EBS? uint64 144 | | +--rw color-aware? boolean 145 | | +--rw coupling-flag? boolean 146 | +--:(asymmetrical) 147 | +--rw ingress-bandwidth-profile 148 | | +--rw bandwidth-profile-name? string 149 | | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 150 | | +--rw CIR? uint64 151 | | +--rw CBS? uint64 152 | | +--rw EIR? uint64 153 | | +--rw EBS? uint64 154 | | +--rw color-aware? boolean 155 | | +--rw coupling-flag? boolean 156 | +--rw egress-bandwidth-profile 157 | +--rw bandwidth-profile-name? string 158 | +--rw bandwidth-profile-type? etht-types:bandwidth-profile-type 159 | +--rw CIR? uint64 160 | +--rw CBS? uint64 161 | +--rw EIR? uint64 162 | +--rw EBS? uint64 163 | +--rw color-aware? boolean 164 | +--rw coupling-flag? boolean 165 +--rw svc! 166 +--rw client-facing? boolean 167 +--rw supported-classification 168 | +--rw port-classification? boolean 169 | +--rw vlan-classification 170 | +--rw vlan-tag-classification? boolean 171 | +--rw outer-tag 172 | | +--rw supported-tag-types* etht-types:eth-tag-classify 173 | | +--rw vlan-bundling? boolean 174 | | +--rw vlan-range? etht-types:vid-range-type 175 | +--rw second-tag 176 | +--rw second-tag-classification? boolean 177 | +--rw supported-tag-types* etht-types:eth-tag-classify 178 | +--rw vlan-bundling? boolean 179 | +--rw vlan-range? etht-types:vid-range-type 180 +--rw supported-vlan-operations 181 +--rw asymmetrical-operations? boolean 182 +--rw transparent-vlan-operations? boolean 183 +--rw vlan-pop 184 | +--rw vlan-pop-operations? boolean 185 | +--rw max-pop-tags? uint8 186 +--rw vlan-push 187 +--rw vlan-push-operation? boolean 188 +--rw outer-tag 189 | +--rw supported-tag-types* etht-types:eth-tag-type 190 | +--rw vlan-range? etht-types:vid-range-type 191 +--rw second-tag 192 +--rw push-second-tag? boolean 193 +--rw supported-tag-types* etht-types:eth-tag-type 194 +--rw vlan-range? etht-types:vid-range-type 196 3.2. YANG Tree for topology Model of other Client Layer 198 This section will be completed later. 200 4. YANG Code for Topology Client Layer 202 4.1. The ETH Topology YANG Code 204 file "ietf-eth-te-topology@2018-03-01.yang" 206 module ietf-eth-te-topology { 208 namespace "urn:ietf:params:xml:ns:yang:ietf-eth-te-topology"; 210 prefix "ethtetopo"; 212 import ietf-network { 213 prefix "nd"; 214 } 216 import ietf-network-topology { 217 prefix "lnk"; 218 } 220 import ietf-te-topology { 221 prefix "tet"; 222 } 224 import ietf-yang-types { 225 prefix "yang"; 226 } 228 import ietf-eth-tran-types { 229 prefix "etht-types"; 230 } 231 organization 232 "Internet Engineering Task Force (IETF) CCAMP WG"; 233 contact 234 " 235 WG List: 237 ID-draft editor: 238 Haomian Zheng (zhenghaomian@huawei.com); 239 Italo Busi (italo.busi@huawei.com); 240 Aihua Guo (aihuaguo@huawei.com); 241 Yunbin Xu (xuyunbin@ritt.cn); 242 Yang Zhao (zhaoyangyjy@chinamobile.com); 243 Xufeng Liu (Xufeng_Liu@jabil.com); 244 Giuseppe Fioccola (giuseppe.fioccola@telecomitalia.it); 245 "; 247 description 248 "This module defines a YANG data model for describing 249 layer-2 Ethernet transport topologies."; 251 revision 2018-03-01 { 252 description 253 "Initial revision"; 254 reference 255 "draft-zheng-ccamp-client-topo-yang"; 256 } 258 /* 259 Groupings 260 */ 262 grouping eth-tran-topology-type { 263 description 264 "Identifies the Ethernet Transport topology type"; 266 container eth-tran-topology { 267 presence "indicates a topology type of Ethernet 268 Transport Network."; 269 description "Eth transport topology type"; 270 } 271 } 273 grouping eth-link-te-attributes { 274 description "Ethernet TE link attributes"; 276 leaf max-bandwidth { 277 type uint64{ 278 range "0..10000000000"; 280 } 281 units "Kbps"; 282 description 283 "Maximum bandwith value expressed in kilobits per second"; 284 } 286 leaf available-bandwidth { 287 type uint64{ 288 range "0..10000000000"; 289 } 290 units "Kbps"; 291 description 292 "Available bandwith value expressed in kilobits per second"; 293 } 295 leaf available-vlan-range { 296 type etht-types:vid-range-type; 297 description 298 "The range of the VLAN values that are available."; 299 } 300 } 302 grouping ltp-bandwidth-profiles { 303 description 304 "A grouping which represents the bandwidt profile(s) for the ETH LTP."; 306 choice direction { 307 description 308 "Whether the bandwidth profiles are symmetrical or 309 asymmetrical"; 310 case symmetrical { 311 description 312 "The same bandwidth profile is used to describe the ingress 313 and the egress bandwidth profile."; 315 container ingress-egress-bandwidth-profile { 316 description 317 "The bandwith profile used in the ingress and egress direction."; 318 uses etht-types:etht-bandwidth-profiles; 319 } 320 } 321 case asymmetrical { 322 description 323 "Different ingress and egress bandwidth profiles 324 can be specified."; 325 container ingress-bandwidth-profile { 326 description 327 "The bandwidth profile used in the ingress direction."; 329 uses etht-types:etht-bandwidth-profiles; 330 } 331 container egress-bandwidth-profile { 332 description 333 "The bandwidth profile used in the egress direction."; 334 uses etht-types:etht-bandwidth-profiles; 335 } 336 } 337 } 338 } 340 grouping eth-ltp-attributes { 341 description 342 "Ethernet transport link termination point attributes"; 344 /* 345 Open Issue: should we remove this attribute (duplicates with I2RS L2 attributes)? 346 */ 347 leaf ltp-mac-address { 348 type yang:mac-address; 349 description "the MAC address of the LTP."; 350 } 351 /* 352 Open Issue: should we remove this attribute (duplicates with I2RS L2 attributes)? 353 */ 354 leaf port-vlan-id { 355 type etht-types:vlanid; 356 description "the port VLAN ID of the LTP."; 357 } 358 /* 359 Open Issue: should we remove this attribute (duplicates with I2RS L2 attributes)? 360 */ 361 leaf maximum-frame-size { 362 type uint16 { 363 range "64 .. 65535"; 364 } 365 description 366 "Maximum frame size"; 367 } 368 uses ltp-bandwidth-profiles; 369 } 371 grouping svc-vlan-classification { 372 description 373 "Grouping defining the capabilities for VLAN classification."; 375 leaf-list supported-tag-types { 376 type etht-types:eth-tag-classify; 377 description 378 "List of VLAN tag types that can be used for the VLAN classification. 379 In case VLAN classification is not supported, the list is empty."; 380 } 381 leaf vlan-bundling { 382 type boolean; 383 description 384 "In case VLAN classification is supported, indicates whether VLAN bundling classification is also supported."; 385 } 386 leaf vlan-range { 387 type etht-types:vid-range-type; 388 description 389 "In case VLAN classification is supported, indicates the of available VLAN ID values."; 390 } 391 } 393 grouping svc-vlan-push { 394 description 395 "Grouping defining the capabilities for VLAN push or swap operations."; 397 leaf-list supported-tag-types { 398 type etht-types:eth-tag-type; 399 description 400 "List of VLAN tag types that can be used to push or swap a VLAN tag. 401 In case VLAN push/swap is not supported, the list is empty."; 402 } 403 leaf vlan-range { 404 type etht-types:vid-range-type; 405 description 406 "In case VLAN push/swap operation is supported, the range of available VLAN ID values."; 407 } 408 } 410 grouping eth-ltp-svc-attributes { 411 description 412 "Ethernet link termination point (LTP) service attributes."; 414 leaf client-facing { 415 type boolean; 416 description 417 "indicates whether this LTP is a client-facing ltp."; 418 } 420 container supported-classification { 421 description 422 "Service classification capabilities supported by the ETH LTP."; 424 leaf port-classification { 425 type boolean; 426 description 427 "Indicates that the ETH LTP support port-based service classification."; 428 } 429 container vlan-classification { 430 description 431 "Service classification capabilities based on the VLAN tag(s) 432 supported by the ETH LTP."; 434 leaf vlan-tag-classification { 435 type boolean; 436 description 437 "Indicates that the ETH LTP supports VLAN service classification."; 438 } 439 container outer-tag { 440 description 441 "Service classification capabilities based on the outer VLAN tag, 442 supported by the ETH LTP."; 443 uses svc-vlan-classification; 444 } 445 container second-tag { 446 description 447 "Service classification capabilities based on the second VLAN tag, 448 supported by the ETH LTP."; 449 /* 450 Open issue: indicates that second-tag-classification can be True only if 451 outer-tag-classification is also True. 452 */ 453 leaf second-tag-classification { 454 type boolean; 455 description 456 "Indicates that the ETH LTP support VLAN service classification 457 based on the second VLAN tag."; 458 } 459 uses svc-vlan-classification; 460 } 461 } 462 } 464 container supported-vlan-operations { 465 description 466 "Description."; 467 leaf asymmetrical-operations { 468 type boolean; 469 description 470 "Indicates whether the ETH LTP supports also asymmetrical VLAN operations. 471 It is assumed that symmetrical VLAN operations are alwyas supported."; 472 } 473 leaf transparent-vlan-operations { 474 type boolean; 475 description 476 "Indicates that the ETH LTP supports transparent operations."; 477 } 478 container vlan-pop { 479 description 480 "Indicates VLAN pop or swap operations capabilities."; 482 leaf vlan-pop-operations { 483 type boolean; 484 description 485 "Indicates that the ETH LTP supports VLAN pop or swap operations."; 486 } 487 leaf max-pop-tags { 488 type uint8 { 489 range "1..2"; 490 } 491 description 492 "Indicates the maximum number of tags that can be popped/swapped."; 493 } 494 } 495 container vlan-push { 496 description 497 "Indicates VLAN push or swap operations capabilities."; 499 leaf vlan-push-operation { 500 type boolean; 501 description 502 "Indicates that the ETH LTP supports VLAN push or swap operations."; 503 } 504 container outer-tag { 505 description 506 "Indicates the supported VLAN operation capabilities on the outer VLAN tag."; 507 uses svc-vlan-push; 508 } 509 container second-tag { 510 description 511 "Indicates the supported VLAN operation capabilities on the second VLAN tag."; 513 leaf push-second-tag { 514 type boolean; 515 description 516 "Indicates that the ETH LTP supports VLAN push or swap operations 517 for the second VLAN tag."; 518 } 519 uses svc-vlan-push; 520 } 522 } 523 } 524 } 526 /* 527 Data nodes 528 */ 530 augment "/nd:networks/nd:network/nd:network-types/tet:te-topology" { 531 description 532 "Augment network types to include ETH transport newtork"; 534 uses eth-tran-topology-type; 535 } 537 augment "/nd:networks/nd:network/lnk:link/tet:te/tet:te-link-attributes" { 538 when "../../../nd:network-types/tet:te-topology/eth-tran-topology" { 539 description 540 "Augment only for ETH transport network."; 541 } 542 description 543 "Augment ETH transport link config attributes"; 545 uses eth-link-te-attributes; 546 } 548 augment "/nd:networks/nd:network/nd:node/lnk:termination-point" { 549 when "../../nd:network-types/tet:te-topology/eth-tran-topology" { 550 description 551 "Augment only for ETH transport network"; 552 } 553 description 554 "Augment ETH LTP attributes"; 556 uses eth-ltp-attributes; 557 container svc { 558 presence "client-facing LTP."; 560 description 561 "ETH LTP Service attributes."; 562 uses eth-ltp-svc-attributes; 563 } 564 } 565 } 567 568 4.2. Other OTN client signal YANG Code 570 TBD. 572 5. Considerations and Open Issue 574 Editor Notes: This section is used to note temporary discussion/ 575 conclusion that to be fixed in the future version, and will be 576 removed before publication. 578 6. IANA Considerations 580 TBD. 582 7. Manageability Considerations 584 TBD. 586 8. Security Considerations 588 The data following the model defined in this document is exchanged 589 via, for example, the interface between an orchestrator and a 590 transport network controller. The security concerns mentioned in 591 [I-D.ietf-teas-yang-te-topo] for using ietf-te-topology.yang model 592 also applies to this document. 594 The YANG module defined in this document can be accessed via the 595 RESTCONF protocol defined in [RFC8040], or maybe via the NETCONF 596 protocol [RFC6241]. 598 There are a number of data nodes defined in the YANG module which are 599 writable/creatable/deletable (i.e., config true, which is the 600 default). These data nodes may be considered sensitive or vulnerable 601 in some network environments. Write operations (e.g., POST) to these 602 data nodes without proper protection can have a negative effect on 603 network operations. 605 Editors note: to list specific subtrees and data nodes and their 606 sensitivity/vulnerability. 608 9. Acknowledgements 610 We would like to thank Igor Bryskin and Daniel King for their 611 comments and discussions. 613 10. Contributors 615 Yanlei Zheng 616 China Unicom 617 Email: zhengyl@dimpt.com 619 Zhe Liu 620 Huawei Technologies, 621 Email: liuzhe123@huawei.com 623 Zheyu Fan 624 Huawei Technologies, 625 Email: fanzheyu2@huawei.com 627 Sergio Belotti 628 Nokia, 629 Email: sergio.belotti@nokia.com 631 Yingxi Yao 632 Shanghai Bell, 633 yingxi.yao@nokia-sbell.com 635 11. References 637 11.1. Normative References 639 [I-D.ietf-ccamp-otn-topo-yang] 640 zhenghaomian@huawei.com, z., Guo, A., Busi, I., Sharma, 641 A., Liu, X., Belotti, S., Xu, Y., Wang, L., and O. Dios, 642 "A YANG Data Model for Optical Transport Network 643 Topology", draft-ietf-ccamp-otn-topo-yang-05 (work in 644 progress), August 2018. 646 [I-D.ietf-ccamp-otn-tunnel-model] 647 zhenghaomian@huawei.com, z., Guo, A., Busi, I., Sharma, 648 A., Rao, R., Belotti, S., Lopezalvarez, V., Li, Y., and Y. 649 Xu, "OTN Tunnel YANG Model", draft-ietf-ccamp-otn-tunnel- 650 model-05 (work in progress), August 2018. 652 [I-D.ietf-teas-yang-te-topo] 653 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 654 O. Dios, "YANG Data Model for Traffic Engineering (TE) 655 Topologies", draft-ietf-teas-yang-te-topo-18 (work in 656 progress), June 2018. 658 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 659 and A. Bierman, Ed., "Network Configuration Protocol 660 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 661 . 663 [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., 664 and K. Pithewan, "GMPLS Signaling Extensions for Control 665 of Evolving G.709 Optical Transport Networks", RFC 7139, 666 DOI 10.17487/RFC7139, March 2014, 667 . 669 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 670 RFC 7950, DOI 10.17487/RFC7950, August 2016, 671 . 673 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 674 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 675 . 677 11.2. Informative References 679 [I-D.ietf-ccamp-wson-yang] 680 Lee, Y., Dhody, D., Guo, A., Lopezalvarez, V., King, D., 681 Yoon, B., and R. Vilata, "A Yang Data Model for WSON 682 Optical Networks", draft-ietf-ccamp-wson-yang-13 (work in 683 progress), August 2018. 685 [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. 686 Ceccarelli, "Framework for GMPLS and PCE Control of G.709 687 Optical Transport Networks", RFC 7062, 688 DOI 10.17487/RFC7062, November 2013, 689 . 691 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 692 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 693 . 695 Authors' Addresses 697 Haomian Zheng 698 Huawei Technologies 699 F3 R&D Center, Huawei Industrial Base, Bantian, Longgang District 700 Shenzhen, Guangdong 518129 701 P.R.China 703 Email: zhenghaomian@huawei.com 704 Aihua Guo 705 Huawei Technologies 707 Email: aihuaguo@huawei.com 709 Italo Busi 710 Huawei Technologies 712 Email: Italo.Busi@huawei.com 714 Yunbin Xu 715 CAICT 717 Email: xuyunbin@ritt.cn 719 Yang Zhao 720 China Mobile 722 Email: zhaoyangyjy@chinamobile.com 724 Xufeng Liu 725 Volta Networks 727 Email: xufeng.liu.ietf@gmail.com 729 Giuseppe Fioccola 730 Telecom Italia 732 Email: giuseppe.fioccola@telecomitalia.it