--- 1/draft-ietf-i2rs-yang-l3-topology-04.txt 2016-11-16 02:13:07.472147017 -0800 +++ 2/draft-ietf-i2rs-yang-l3-topology-05.txt 2016-11-16 02:13:07.512147425 -0800 @@ -1,34 +1,33 @@ Network Working Group A. Clemm -Internet-Draft J. Medved -Intended status: Standards Track Cisco -Expires: March 23, 2017 R. Varga +Internet-Draft Sympotech +Intended status: Standards Track J. Medved +Expires: May 20, 2017 Cisco + R. Varga Pantheon Technologies SRO - T. Tkacik - X. Liu Ericsson I. Bryskin Huawei A. Guo Adva Optical H. Ananthakrishnan Packet Design N. Bahadur Bracket Computing V. Beeram Juniper Networks - September 19, 2016 + November 16, 2016 A YANG Data Model for Layer 3 Topologies - draft-ietf-i2rs-yang-l3-topology-04.txt + draft-ietf-i2rs-yang-l3-topology-05.txt Abstract This document defines a YANG data model for layer 3 network topologies. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -36,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 23, 2017. + This Internet-Draft will expire on May 20, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -69,58 +68,60 @@ the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4 - 3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 5 4. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5 5. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7 6. Extending the Model . . . . . . . . . . . . . . . . . . . . . 14 6.1. Example 1: OSPF Topology . . . . . . . . . . . . . . . . 14 - 6.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 15 - 6.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 17 - 6.2. Example 2: IS-IS Topology . . . . . . . . . . . . . . . . 22 - 6.2.1. Model Overview . . . . . . . . . . . . . . . . . . . 22 + 6.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 14 + 6.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 16 + 6.2. Example 2: IS-IS Topology . . . . . . . . . . . . . . . . 21 + 6.2.1. Model Overview . . . . . . . . . . . . . . . . . . . 21 6.2.2. IS-IS Topology YANG Module . . . . . . . . . . . . . 23 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 - 10.2. Informative References . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + 7. Interactions with Other YANG Modules . . . . . . . . . . . . 28 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 + 12.2. Informative References . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction This document introduces a YANG [RFC7950] [RFC6991] data model for Layer 3 network topologies, specifically Layer 3 Unicast. The model allows an application to have a holistic view of the topology of a Layer 3 network, all contained in a single conceptual YANG datastore. The data model builds on top of, and augments, the data model for network topologies defined in [I-D.draft-ietf-i2rs-yang-network-topo]. An earlier revision of that Internet Draft contained not just the general model for network topologies, but also the model for layer 3 network topologies that is being specified here. However, we decided to "split" the earlier draft to separate the truly general aspects of a topology data model, which apply to any type of topology, from the application of this model to a particular domain, here: a Layer 3 network. The document also shows how the model can be further refined to cover different Layer 3 Unicast topology types. For this purpose, example - models are introduced that cover IS-IS [RFC1195] and OSPF [RFC2178]. + models are introduced that cover IS-IS [RFC1195] and OSPF [RFC2328]. Those examples are intended purely for illustrative purposes; we expect that full-blown IS-IS and OSPF models will be more comprehensive and refined than the examples shown here. There are multiple applications for a topology data model. A number of use cases have been defined in section 6 of [I-D.draft-ietf-i2rs-usecase-reqs-summary]. For example, nodes within the network can use the data model to capture their understanding of the overall network topology and expose it to a network controller. A network controller can then use the @@ -295,21 +297,21 @@ type of event, the topology from which it originated, and the affected node, or link, or prefix, or termination point. In addition, as a convenience to applications, additional data of the affected node, or link, or termination point (respectively) is included. While this makes notifications larger in volume than they would need to be, it avoids the need for subsequent retrieval of context information, which also might have changed in the meantime. 5. Layer 3 Unicast Topology YANG Module - file "ietf-l3-unicast-topology@2016-09-19.yang" + file "ietf-l3-unicast-topology@2016-11-16.yang" module ietf-l3-unicast-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology"; prefix "l3t"; import ietf-network { prefix "nd"; } import ietf-network-topology { prefix "lnk"; @@ -320,27 +322,25 @@ organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: WG List: WG Chair: Susan Hares WG Chair: Russ White Editor: Alexander Clemm - + Editor: Jan Medved Editor: Robert Varga - - Editor: Tony Tkacik - + Editor: Xufeng Liu Editor: Igor Bryskin Editor: Aihua Guo Editor: Nitin Bahadur Editor: Hariharan Ananthakrishnan @@ -351,40 +351,38 @@ topologies. Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of - draft-ietf-i2rs-yang-network-topo-04; + draft-ietf-i2rs-yang-l3-topology-05; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-04 with RFC + draft-ietf-i2rs-yang-l3-topology-05 with RFC number when published (i.e. RFC xxxx)."; - revision "2016-09-19" { + revision "2016-11-16" { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference - to draft-ietf-i2rs-yang-l3-topology-04 with + to draft-ietf-i2rs-yang-l3-topology-05 with RFC number when published (i.e. RFC xxxx)."; reference - "draft-ietf-i2rs-yang-l3-topology-04"; + "draft-ietf-i2rs-yang-l3-topology-05"; } identity flag-identity { description "Base type for flags"; - } - typedef l3-event-type { type enumeration { enum "add" { description "An Layer 3 node or link or prefix or termination-point has been added"; } enum "remove" { description "An Layer 3 node or link or prefix or termination-point has @@ -654,34 +652,37 @@ The model can be extended for specific Layer 3 Unicast types. Examples include OSPF and IS-IS topologies. In the following, two additional YANG modules are introduced that define simple topology models for OSPF and IS-IS, respectively. These modules intended to serve as examples that illustrate how the general topology model can be refined across multiple levels; they do not constitute full- fledged OSPF and IS-IS topology models which may be more comprehensive and refined than the models that are described here. 6.1. Example 1: OSPF Topology + 6.1.1. Model Overview The following model shows how the Layer 3 Unicast topology model can be extended to cover OSFP topologies. For this purpose, a set of augmentations are introduced in a separate YANG module, "ietf-ospf- topology", whose structure is depicted in the following diagram. + Like before, brackets enclose list keys, "rw" means configuration, "ro" operational state data, "?" designates optional nodes, "*" designates nodes that can have multiple instances. Parantheses enclose choice and case nodes. A "+" at the end of a line indicates a line break. module: ietf-ospf-topology -augment /nd:networks/nd:network/nd:network-types/l3t:l3-unicast-topology: + augment /nd:networks/nd:network/nd:network-types/+ + l3t:l3-unicast-topology: +--rw ospf! augment /nd:networks/nd:network/l3t:l3-topology-attributes: +--rw ospf-topology-attributes +--rw area-id? area-id-type augment /nd:networks/nd:network/nd:node/l3t:l3-node-attributes: +--rw ospf-node-attributes +--rw (router-type)? | +--:(abr) | | +--rw abr? empty | +--:(asbr) @@ -737,55 +738,52 @@ In addition, the module extends notifications for events concerning Layer 3 nodes, links, termination points, and prefixes with OSPF attributes. It should be noted that the model defined here represents topology and is intended as an example. It does not define how to configure OSPF routers or interfaces. 6.1.2. OSPF Topology YANG Module - file "ietf-ospf-topology@2016-09-19.yang" + file "ietf-ospf-topology@2016-11-16.yang" module ietf-ospf-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-topology"; prefix "ospft"; import ietf-yang-types { prefix "yang"; } import ietf-network { prefix "nd"; } import ietf-network-topology { prefix "lnk"; } import ietf-l3-unicast-topology { prefix "l3t"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact - "WG Web: <>http://tools.ietf.org/wg/i2rs/> + "WG Web: WG List: WG Chair: Susan Hares - WG Chair: Russ White Editor: Alexander Clemm - + Editor: Jan Medved Editor: Robert Varga - - Editor: Tony Tkacik - + Editor: Xufeng Liu Editor: Igor Bryskin Editor: Aihua Guo Editor: Nitin Bahadur Editor: Hariharan Ananthakrishnan @@ -795,33 +793,34 @@ "This module defines a model for OSPF network topologies. Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of - draft-ietf-i2rs-yang-network-topo-04; + draft-ietf-i2rs-yang-l3-topology-05; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-04 with RFC + draft-ietf-i2rs-yang-l3-topology-05 with RFC number when published (i.e. RFC xxxx)."; - revision "2016-09-19" { + revision "2016-11-16" { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference - to draft-ietf-i2rs-yang-l3-topology-04 with + to draft-ietf-i2rs-yang-l3-topology-05 with RFC number when published (i.e. RFC xxxx)."; + reference - "draft-ietf-i2rs-yang-l3-topology-04"; + "draft-ietf-i2rs-yang-l3-topology-05"; } typedef area-id-type { type yang:dotted-quad; description "Area ID type."; } grouping ospf-topology-type { description "Identifies the OSPF topology type."; container ospf { @@ -903,24 +903,23 @@ } case pseudonode { leaf pseudonode { type empty; description "The node is pseudonode"; } } } leaf dr-interface-id { - when "../router-type/pseudonode" { + when "../pseudonode" { description "Valid only for pseudonode"; - } type uint32; default "0"; description "For pseudonodes, DR interface-id"; } leaf-list multi-topology-id { type uint8 { range "0..127"; } @@ -969,21 +967,22 @@ in the case of OSPF topology, a model for IS-IS topology can be defined in a separate module which augments "ietf-l3-unicast-igp- topology". The structure of a corresponding model, "ietf-isis- topology", is depicted in the following diagram. Like before, brackets enclose list keys, "rw" means configuration, "ro" operational state data, "?" designates optional nodes, "*" designates nodes that can have multiple instances. Parantheses enclose choice and case nodes. A "+" at the end of a line indicates a line break. module: ietf-isis-topology -augment /nd:networks/nd:network/nd:network-types/l3t:l3-unicast-topology: + augment /nd:networks/nd:network/nd:network-types/+ + l3t:l3-unicast-topology: +--rw isis! augment /nd:networks/nd:network/l3t:l3-topology-attributes: +--rw isis-topology-attributes +--rw net? area-address augment /nd:networks/nd:network/nd:node/l3t:l3-node-attributes: +--rw isis-node-attributes +--rw iso | +--rw iso-system-id? system-id | +--rw iso-pseudonode-id? iso-pseudonode-id +--rw net* area-address @@ -1026,52 +1025,49 @@ In addition, the module augments nodes and links with IS-IS attributes. Again, it should be noted that the model defined here represents topology and is intended as an example. It does not define how to configure IS-IS routers or interfaces. 6.2.2. IS-IS Topology YANG Module - file "ietf-isis-topology@2016-09-19.yang" + file "ietf-isis-topology@2016-11-16.yang" module ietf-isis-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-isis-topology"; prefix "isist"; import ietf-network { prefix "nd"; } import ietf-network-topology { prefix "lnk"; } import ietf-l3-unicast-topology { prefix "l3t"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact - "WG Web: > + "WG Web: WG List: WG Chair: Susan Hares WG Chair: Russ White - Editor: Alexander Clemm - + Editor: Jan Medved Editor: Robert Varga - - Editor: Tony Tkacik - + Editor: Xufeng Liu Editor: Igor Bryskin Editor: Aihua Guo Editor: Nitin Bahadur Editor: Hariharan Ananthakrishnan @@ -1081,38 +1077,37 @@ "This module defines a model for IS-IS network topologies. Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of - draft-ietf-i2rs-yang-network-topo-04; + draft-ietf-i2rs-yang-l3-topology-05; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-04 with RFC + draft-ietf-i2rs-yang-l3-topology-05 with RFC number when published (i.e. RFC xxxx)."; - revision "2016-09-19" { + revision "2016-11-16" { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference - to draft-ietf-i2rs-yang-l3-topology-4 with + to draft-ietf-i2rs-yang-l3-topology-5 with RFC number when published (i.e. RFC xxxx)."; reference - draft-ietf-i2rs-yang-l3-topology-04; + draft-ietf-i2rs-yang-l3-topology-05; } typedef iso-pseudonode-id { type string { pattern '[0-9a-fA-F]{2}'; - } description "ISO pseudonode id for broadcast network."; } typedef area-address{ type string { pattern '[0-9A-Fa-f]{2}\.([0-9A-Fa-f]{4}\.){0,3}'; } description "This type defines the area address."; @@ -1260,111 +1254,207 @@ "ISIS node event"; uses isis-topology-type; uses isis-node-attributes; } augment "/l3t:l3-link-event" { description "ISIS link event"; uses isis-topology-type; uses isis-link-attributes; } + } -7. Security Considerations +7. Interactions with Other YANG Modules - The transport protocol used for sending the topology data MUST - support authentication and SHOULD support encryption. The data-model - by itself does not create any security implications. + As described in section Section 3, the model builds on top of, and + augments, the YANG modules defined in + [I-D.draft-ietf-i2rs-yang-network-topo]. Specifically, module ietf- + l3-unicast-topology augments modules "ietf-network" and "ietf- + network-topology". In addition, the model makes use of data types + that have been defined in [RFC6991]. -8. Contributors + The moodel defines a protocol independent YANG data model with layer + 3 topology information. It is separate from and not linked with data + models that are used to configure routing protocols or routing + information. This includes e.g. model "ietf-routing" [RFC8022] and + model "ietf-fb-rib" [I-D.draft-acee-rtgwg-yang-rib-extend]. + + The model obeys the requirements for the ephemeral state found in the + document [I-D.draft-ietf-i2rs-ephemeral-state]. For ephemeral + topology data that is server provided, the process tasked with + maintaining topology information will load information from the + routing process (such as OSPF) into the data model without relying on + a configuration datastore. + +8. IANA Considerations + + This document registers the following namespace URIs in the "IETF XML + Registry" [RFC3688]: + + URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology + Registrant Contact: The IESG. + XML: N/A; the requested URI is an XML namespace. + + URI:urn:ietf:params:xml:ns:yang:ietf-ospf-topology + Registrant Contact: The IESG. + XML: N/A; the requested URI is an XML namespace. + + URI:urn:ietf:params:xml:ns:yang:ietf-isis-topology + Registrant Contact: The IESG. + XML: N/A; the requested URI is an XML namespace. + + This document registers the following YANG modules in the "YANG + Module Names" registry [RFC6020]: + + Name: ietf-l3-unicast-topology + Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology + Prefix: l3t + Reference: draft-ietf-i2rs-yang-l3-topology-05.txt (RFC form) + + Name: ietf-ospf-topology + Namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-topology + Prefix: ospft + Reference: draft-ietf-i2rs-yang-l3-topology-05.txt (RFC form) + + Name: ietf-isis-topology + Namespace: urn:ietf:params:xml:ns:yang:ietf-isis-topology + Prefix: isist + Reference: draft-ietf-i2rs-yang-l3-topology-05.txt (RFC form) + +9. Security Considerations + + The YANG module defined in this memo is designed to be accessed via + the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the + secure transport layer, and the mandatory-to-implement secure + transport is Secure Shell (SSH) [RFC6242]. The NETCONF access + control model [RFC6536] provides the means to restrict access for + particular NETCONF users to a pre-configured subset of all available + NETCONF protocol operations and content. + + In general, Layer 3 Unicast topologies are server-provided and + provide ephemeral topology information. As they provide read-only + access to clients, they are less vulnerable. That said, the YANG + module does in principle allow information to be configurable in + certain instances (when the server-provided flag for the topology is + set to false). In such cases, a malicious client could introduce + topologies that are undesired. For example, a client could remove or + add topological links between nodes, which could lead to an undesired + and suboptimal topology, which might impact service levels and + network utilization. It is therefore important that the NETCONF + access control model is vigorously applied to prevent topology + configuration by unauthorized clients. + +10. Contributors The model presented in this paper was contributed to by more people than can be listed on the author list. Additional contributors include: o Ken Gray, Juniper Networks o Tom Nadeau, Brocade + o Tony Tkacik o Aleksandr Zhdankin, Cisco -9. Acknowledgements +11. Acknowledgements We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Ladislav Lhotka, Andy Bierman, Carlos Pignataro, Joel Halpern, Juergen Schoenwaelder, Alia Atlas, Susan Hares, Benoit Claise, and Carl Moberg. -10. References +12. References -10.1. Normative References +12.1. Normative References [I-D.draft-ietf-i2rs-yang-network-topo] - Clemm, A., Medved, J., Tkacik, T., Varga, R., Bahadur, N., + Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", I-D draft-ietf-i2rs-yang-network- - topo-06, September 2016. + topo-08, November 2016. [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990. - [RFC2178] Moy, J., "OSPF Version 2", RFC 2178, July 1997. + [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. + + [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January + 2004. + + [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the + Network Configuration Protocol (NETCONF)", RFC 6020, + October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure + Shell (SSH)", RFC 6242, June 2011. + + [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration + Protocol (NETCONF) Access Control Model", RFC 6536, March + 2012. + [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013. - [RFC7223] Bjorklund, M., "A YANG Data Model for Interface - Management", RFC 7223, May 2014. - [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC 7950, August 2016. -10.2. Informative References +12.2. Informative References + + [I-D.draft-acee-rtgwg-yang-rib-extend] + Lindem, A. and Y. Qu, "YANG Data Model for RIB + Extensions", I-D draft-acee-rtgwg-yang-rib-extend-02, + October 2016. + + [I-D.draft-ietf-i2rs-ephemeral-state] + Haas, J. and S. Hares, "I2RS Ephemeral State + Requirements", I-D draft-ietf-i2rs-ephemeral-state-22, + November 2016. [I-D.draft-ietf-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- - 02, March 2016. + 03, November 2016. [OpenDaylight] Medved, J., Varga, R., Tkacik, T., and K. Gray, "OpenDaylight: Towards a Model-Driven SDN Controller architecture", IEEE 15th Int. Symposium on World of Wireless, Mobile and Multimedia Networks (IEEE WoWMoM 2014), June 2014. + [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing + Management", RFC 8022, November 2016. + Authors' Addresses Alexander Clemm - Cisco + Sympotech + + EMail: alex@sympotech.com - EMail: ludwig@clemm.org Jan Medved Cisco EMail: jmedved@cisco.com Robert Varga Pantheon Technologies SRO EMail: robert.varga@pantheon.sk - - Tony Tkacik - - EMail: tony.tkacik@gmail.com - Xufeng Liu Ericsson EMail: xliu@kuatrotech.com Igor Bryskin Huawei EMail: Igor.Bryskin@huawei.com