TEAS WG Young Lee
Haomian Zheng
Internet Draft Huawei
Intended status: Informational
Daniel Ceccarrelli
Expires: December 31, 2017 Ericsson
Bin Yeong Yoon
ETRI
Oscar Gonzalez de Dios
Telefonica
Jong Yoon Shin
SKT
Sergio Belotti
Nokia
June 30, 2017
Applicability of YANG models for Abstraction and Control of Traffic
Engineered Networks
draft-zhang-teas-actn-yang-05
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Zhang, et al. Expires December 30, 2017 [Page 1]
Internet-Draft ACTN YANG June 2017
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2017.
Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network operations needed to orchestrate, control and manage
large-scale multi-domain TE networks, so as to facilitate network
programmability, automation, efficient resource sharing, and end-to-
end virtual service aware connectivity and network function
virtualization services.
This document explains how the different types of YANG models
defined in the Operations and Management Area and in the Routing
Area are applicable to the ACTN framework. This document also shows
how the ACTN architecture can be satisfied using classes of data
model that have already been defined, and discusses the
applicability of specific data models that are under development. It
also highlights where new data models may need to be developed.
Table of Contents
1. Introduction...................................................3
2. Abstraction and Control of TE Networks (ACTN) Architecture.....3
3. Service Models.................................................5
4. Service Model Mapping to ACTN..................................6
Zhang, et al. Expires December 30, 2017 [Page 2]
Internet-Draft ACTN YANG June 2017
4.1. Customer Service Models in the ACTN Architecture (CMI)....7
4.2. Service Delivery Models in ACTN Architecture..............8
4.3. Network Configuration Models in ACTN Architecture (MPI)...8
4.4. Device Models in ACTN Architecture (SBI)..................9
5. Examples of Using Different Types of YANG Models..............10
5.1. Simple Connectivity Examples.............................10
5.2. VN service example.......................................10
5.3. Data Center-Interconnection Example......................11
5.3.1. CMI (CNC-MDSC Interface)............................13
5.3.2. MPI (MDSC-PNC Interface)............................13
5.3.3. PDI (PNC-Device interface)..........................13
6. Security......................................................14
7. Acknowledgements..............................................14
8. References....................................................14
8.1. Informative References...................................14
9. Contributors..................................................16
Authors' Addresses...............................................17
1. Introduction
Abstraction and Control of TE Networks (ACTN) describes a method for
operating a Traffic Engineered (TE) network (such as an MPLS-TE
network or a layer 1 transport network) to provide connectivity and
virtual network services for customers of the TE network. The
services provided can be tuned to meet the requirements (such as
traffic patterns, quality, and reliability) of the applications
hosted by the customers. More details about ACTN can be found in
Section 2.
Data models are a representation of objects that can be configured
or monitored within a system. Within the IETF, YANG [RFC6020] is the
language of choice for documenting data models, and YANG models have
been produced to allow configuration or modelling of a variety of
network devices, protocol instances, and network services. YANG data
models have been classified in [Netmod-Yang-Model-Classification]
and [Service-YANG].
This document shows how the ACTN architecture can be satisfied using
classes of data model that have already been defined, and discusses
the applicability of specific data models that are under
development. It also highlights where new data models may need to be
developed.
2. Abstraction and Control of TE Networks (ACTN) Architecture
[ACTN-Requirements] describes the high-level ACTN requirements.
[ACTN-Frame] describes the architecture model for ACTN including the
Zhang, et al. Expires December 30, 2017 [Page 3]
Internet-Draft ACTN YANG June 2017
entities (Customer Network Controller (CNC), Multi-domain Service
Coordinator (MDSC), and Physical Network Controller (PNC)) and their
interfaces.
Figure 1 depicts a high-level control and interface architecture for
ACTN and is a reproduction of Figure 3 from [ACTN-Frame]. A number
of key ACTN interfaces exist for deployment and operation of ACTN-
based networks. These are highlighted in Figure 1 (ACTN Interfaces)
below:
+--------------+ +---------------+ +--------------+
| CNC-A | | CNC-B | | CNC-C |
|(DC provider) | | (ISP) | | (MVNO) |
+--------------+ +---------------+ +--------------+
\ | /
Business \ | /
Boundary =======\========================|=========================/=======
Between \ | CMI /
Customer & ----------- | --------------
Network Provider \ | /
+-----------------------+
| MDSC |
+-----------------------+
/ | \
------------ |MPI ----------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
| GMPLS / | / \
| trigger / |SBI / \
-------- ----- | / \
( ) ( ) | / \
- - ( Phys. ) | / -----
( GMPLS ) ( Net ) | / ( )
( Physical ) ---- | / ( Phys. )
( Network ) ----- ----- ( Net )
- - ( ) ( ) -----
( ) ( Phys. ) ( Phys. )
-------- ( Net ) ( Net )
----- -----
Figure 1 : ACTN Interfaces
The interfaces and functions are described below (without modifying
the definitions) in [ACTN-Frame]:
Zhang, et al. Expires December 30, 2017 [Page 4]
Internet-Draft ACTN YANG June 2017
. The CNC-MDSC Interface (CMI) is an interface between a Customer
Network Controller and a Multi Domain Service Controller. The
interface will communicate the service request or application
demand. A request will include specific service properties, for
example, services type, bandwidth and constraint information.
These constraints SHOULD be measurable by MDSC and therefore
visible to CNC via CMI. The CNC can also request the creation
of the virtual network based on underlying physical resources
to provide network services for the applications. The CNC can
provide the end-point information/characteristics, traffic
matrix specifying specific customer constraints. The MDSC may
also report potential network topology availability if queried
for current capability from the Customer Network Controller.
. The MDSC-PNC Interface (MPI) is an interface between a Multi
Domain Service Coordinator and a Physical Network Controller.
It allows the MDSC to communicate requests to create/delete
connectivity or to modify bandwidth reservations in the
physical network. In multi-domain environments, each PNC is
responsible for a separate domain. The MDSC needs to establish
multiple MPIs, one for each PNC and perform coordination
between them to provide cross-domain connectivity.
. The South-Bound Interface (SBI) is the provisioning interface
for creating forwarding state in the physical network,
requested via the Physical Network Controller. The SBI is not
in the scope of ACTN, however, it is included in this document
so that it can be compared to models in [Service-Yang].
3. Service Models
[Service-YANG] introduces a reference architecture to explain the
nature and usage of service YANG models in the context of service
orchestration. Figure 2 below depicts this relationship and is a
reproduction of Figure 2 from [Service-YANG]. Four models depicted
in Figure 2 are defined as follows:
. Customer Service Model: A customer service model is used to
describe a service as offer or delivered to a customer by a
network operator.
. Service Delivery Model: A service delivery model is used by a
network operator to define and configure how a service is
provided by the network.
. Network Configuration Model: A network configuration model is
used by a network orchestrator to provide network-level
configuration model to a controller.
Zhang, et al. Expires December 30, 2017 [Page 5]
Internet-Draft ACTN YANG June 2017
. Device Configuration Model: A device configuration model is
used by a controller to configure physical network elements.
Customer
------------------ Service ----------
| | Model | |
| Service |<-------->| Customer |
| Orchestrator | | |
| | ----------
------------------
. . -----------
. . ......|Application|
. . : | BSS/OSS |
. . : -----------
. Service Delivery . :
. Model . :
------------------ ------------------
| | | |
| Network | | Network |
| Orchestrator | | Orchestrator |
| | | |
.------------------ ------------------.
. : : .
. : Network Configuration : .
. : Model : .
------------ ------------ ------------ ------------
| | | | | | | |
| Controller | | Controller | | Controller | | Controller |
| | | | | | | |
------------ ------------ ------------ ------------
: . . : :
: . . Device : :
: . . Configuration : :
: . . Model : :
--------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- ---------
Figure 2: An SDN Architecture with a Service Orchestrator
4. Service Model Mapping to ACTN
YANG models coupled with the RESTCONF/NETCONF protocol
[Netconf][Restconf] provides solutions for the ACTN framework. This
section explains which types of YANG models apply to each of the
ACTN interfaces.
Zhang, et al. Expires December 30, 2017 [Page 6]
Internet-Draft ACTN YANG June 2017
Refer to Figure 5 of [ACTN-Frame] for details of the mapping between
ACTN functions and service models. In summary, the following
mappings are held between and Service Yang Models and the ACTN
interfaces.
o Customer Service Model <-> CMI
o Network Configuration Model <-> MPI
o Device Configuration Model <-> SBI
4.1. Customer Service Models in the ACTN Architecture (CMI)
Customer Service Models, which are used between a customer and a
service orchestrator as in [Service-YANG], should be used between
the CNC and MDSC (e.g., CMI) serving as providing a simple intent-
like model/interface.
Among the key functions of Customer Service Models on the CMI is the
service request. A request will include specific service properties,
including: service type and its characteristics, bandwidth,
constraint information, and end-point characteristics.
The following table provides a list of functions needed to build the
CMI. They are mapped with Customer Service Models.
Function Yang Model
-----------------------------------------------------------
Transport Service Request [Transport-Service-Model]
VN Service Request & Instantiation [ACTN-VN-YANG]
VN Path Computation Request [ACTN-VN-YANG]*
VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]**
Topology Abstraction [TE-topology]
*VN Path computation request in the CMI context means network path
computation request based on customer service connectivity request
constraints prior to the instantiation of a VN creation.
**ietf-actn-te-kpi-telemetry model describes performance telemetry
for ACTN VN model. This module also allows autonomic traffic
engineering scaling intent configuration mechanism on the VN level.
Scale in/out criteria might be used for network autonomics in order
the controller to react to a certain set of variations in monitored
parameters. Moreover, this module also provides mechanism to define
Zhang, et al. Expires December 30, 2017 [Page 7]
Internet-Draft ACTN YANG June 2017
aggregated telemetry parameters as a grouping of underlying VN level
telemetry parameters.
4.2. Service Delivery Models in ACTN Architecture
The Service Delivery Models where the service orchestration and the
network orchestration could be implemented as separate components as
seen in [Service-YANG]. This is also known as Network Service
Models. On the other hand, from an ACTN architecture point of view,
the service delivery model between the service orchestrator and the
network orchestrator is an internal interface between sub-components
of the MDSC in a single MDSC model.
In the MDSC hierarchical model where there are multiple MDSCs, the
interface between the top MDSC and the bottom MDSC can be mapped to
service delivery models.
4.3. Network Configuration Models in ACTN Architecture (MPI)
The Network Configuration Models is used between the network
orchestrator and the controller in [Service-YANG]. In ACTN, this
model is used primarily between a MDSC and a PNC. The Network
Configuration Model can be also used for the foundation of more
advanced models, like hierarchical MDSCs (see Section 4.5)
The Network Configuration Model captures the parameters which are
network wide information.
The following table provides a list of functions needed to build the
MPI. They are mapped with Network Configuration Yang Models. Note
that various Yang models are work in progress.
Function Yang Model
--------------------------------------------------------
Configuration Scheduling [Schedule]
Path computation [PATH_COMPUTATION-API]*
Path Provisioning [TE-Tunnel]**
Topology Abstraction [TE-topology]
Tunnel PM Telemetry [ACTN-PM-Telemetry]***
Service Provisioning TBD****
OTN Topology Abstraction [OTN-YANG]
WSON Topology Abstraction [WSON-YANG]
Flexi-grid Topology Abstraction [Flexi-YANG]
ODU Tunnel Model [ODU-Tunnel]
Zhang, et al. Expires December 30, 2017 [Page 8]
Internet-Draft ACTN YANG June 2017
WSON TE Tunnel Model [WSON-Tunnel]
Flexi-grid Tunnel Model [Flexigrid-Tunnel]
* Related draft is presenting use cases for path computation API,
and Yang related model is foreseen to be added.
** Note that path provisioning function is provided by ietf-te
module in [TE-Tunnel].
** ietf-actn-te-kpi-telemetry model describes performance telemetry
for TE-tunnel model. This module also allows autonomic traffic
engineering scaling intent configuration mechanism on the TE-tunnel
level. Various conditions can be set for auto-scaling based on the
telemetry data.
**** This function needs to be investigated further. This can be a
part of [TE-Tunnel] which is to be determined. Service provisioning
is an optional function that builds on top the path provisioning
one.
Path provisioning and Topology abstraction functions are mandatory
in any case, while Path Computation may be mandatory or optional
depending on the type of topology abstraction used. Details of this
topic are discussed in [ACTN-Abstraction].
Telemetry may also be an optional function.
4.4. Device Models in ACTN Architecture (SBI)
For the device YANG models are used for per-device configuration
purpose, they can be used between the PNC and the physical
network/devices. Note that SBI is not in the scope of ACTN. This
section is provided to give some examples of YANG-based Device
Models. An example of Device Models is ietf-te-device yang module
defined in [TE-tunnel].
Zhang, et al. Expires December 30, 2017 [Page 9]
Internet-Draft ACTN YANG June 2017
5. Examples of Using Different Types of YANG Models
5.1. Simple Connectivity Examples
The data model in [Transport-Service-Model] provides an intent-like
connectivity service model which can be used in connection-oriented
networks.
It would be used as follows in the ACTN architecture:
. A CNC uses this service model to specify the two client nodes
that are to be connected, and also indicates the amount of
traffic (i.e., the bandwidth required) and payload type. What
may be additionally specified is the SLA that describes the
required quality and resilience of the service.
. The MDSC uses the information in the request to pick the right
network (domain) and also to select the provider edge nodes
corresponding to the customer edge nodes.
If there are multiple domains, then the MDSC needs to
coordinate across domains to set up network tunnels to deliver
a service. Thus coordination includes, but is not limited to,
picking the right domain sequence to deliver a service. Before
it can perform such functions, it needs to get the topology
information from each PNC, using topology YANG models such as
[te-topology]. The topology reported from PNC to MDSC can
either be abstract or non-abstract.
Additionally, an MDSC can initiate the creation of a tunnel (or
tunnel segment) in order to fulfill the service request from
CNC based on path computation upon the overall topology
information it synthesized from different PNCs. The based model
that can cater this purpose is the te-tunnel model specified in
[te-tunnel].
. Then, the PNC needs to decide the explicit route of such a
tunnel or tunnel segment (in case of multiple domains), and
create such a tunnel using protocols such as PCEP and RSVP-TE
or using per-hop configuration.
5.2. VN service example
The service model defined in [ACTN-VN-YANG] describes a virtual
network (VN) as a service which is a set of multiple connectivity
services:
Zhang, et al. Expires December 30, 2017 [Page 10]
Internet-Draft ACTN YANG June 2017
. A CNC will request VN to the MDSC by specifying a list of VN
members. Each VN member specifies either a single connectivity
service, or a source with multiple potential destination points
in the case that the precise destination sites are to be
determined by MDSC.
o In the first case, the procedure is the same as the
connectivity service, except that in this case, there is a
list of connections requested.
o In the second case, where the CNC requests the MDSC to
select the right destination out of a list of candidates,
the MDSC needs to choose the best candidate and reply with
the chosen destination for a given VN member. After this
is selected, the connectivity request setup procedure is
the same as in the connectivity-as-a-service example.
After the VN is set up, a successful reply message is sent from MDSC
to CNC, indicating the VN is ready. This message can also be
achieved by using the model defined in [ACTN-VN-YANG].
5.3. Data Center-Interconnection Example
This section describes more concretely how existing YANG models
described in Section 4 map to an ACTN data center interconnection
use case. Figure 3 shows a use-case which shows service policy-
driven Data Center selection and is a reproduction of Figure A.1
from [ACTN-Info].
Zhang, et al. Expires December 30, 2017 [Page 11]
Internet-Draft ACTN YANG June 2017
+----------------+
| CNC |
| (Global DC |
| Operation |
| Control) |
+--------+-------+
| | VN Requirement/Policy:
CMI: | | - Endpoint/DC location info
Service model | | - Endpoint/DC dynamic
| | selection policy
| | (for VM migration, DR, LB)
| v
+---------+---------+
| Multi-domain | Service policy-driven
|Service Coordinator| dynamic DC selection
MPI: +-----+---+---+-----+
Network Configuration | | |
Model | | |
+----------------+ | +---------------+
| | |
+-----+-----+ +------+-----+ +------+-----+
| PNC for | | PNC for | | PNC for |
| Transport | | Transport | | Transport |
| Network A | | Network B | | network C |
+-----------+ +------------+ +------------+
Device | | |
Model | | |
| | |
+---+ ------ ------ ------ +---+
|DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5|
+---+ | | | | | | +---+
| TN A +-----+ TN B +----+ TN C |
/ | | | | |
/ \\\\ //// / \\\\ //// \\\\ ////
+---+ ------ / ------ \ ------ \
|DC2| / \ \+---+
+---+ / \ |DC6|
+---+ \ +---+ +---+
|DC3| \|DC4|
+---+ +---+
DR: Disaster Recovery
LB: Load Balancing
Figure 3: Service Policy-driven Data Center Selection
Zhang, et al. Expires December 30, 2017 [Page 12]
Internet-Draft ACTN YANG June 2017
Figure 3 shows how VN policies from the CNC (Global Data Center
Operation) are incorporated by the MDSC to support multi-destination
applications. Multi-destination applications refer to applications
in which the selection of the destination of a network path for a
given source needs to be decided dynamically to support such
applications.
Data Center selection problems arise for VM mobility, disaster
recovery and load balancing cases. VN's policy plays an important
role for virtual network operation. Policy can be static or dynamic.
Dynamic policy for data center selection may be placed as a result
of utilization of data center resources supporting VMs. The MDSC
would then incorporate this information to meet the objective of
this application.
5.3.1. CMI (CNC-MDSC Interface)
[ACTN-VN-YANG] is used to express the definition of a VN, its VN
creation request, the service objectives (metrics, QoS parameters,
etc.), dynamic service policy when VM needs to be moved from one
Data Center to another Data Center, etc. This service model is used
between the CNC and the MDSC (CMI). The CNC in this use-case is an
external entity that wants to create a VN and operates on the VN.
5.3.2. MPI (MDSC-PNC Interface)
The Network Configuration Model is used between the MDSC and the
PNCs. Based on the Customer Service Model's request, the MDSC will
need to translate the service model into the network configuration
model to instantiate a set of multi-domain connections between the
prescribed sources and the destinations. The MDSC will also need to
dynamically interact with the CNC for dynamic policy changes
initiated by the CNC. Upon the determination of the multi-domain
connections, the MDSC will need to use the network configuration
model such as [TE-Tunnel] to interact with each PNC involved on the
path. [TE-Topology] is used to for the purpose of underlying domain
network abstraction from the PNC to the MDSC.
5.3.3. PDI (PNC-Device interface)
The Device Model can be used between the PNC and its underlying
devices that are controlled by the PNC. The PNC will need to trigger
signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to
provision its domain path segment. There can be a plethora of
choices how to control/manage its domain network. The PNC is
responsible to abstract its domain network resources and update it
Zhang, et al. Expires December 30, 2017 [Page 13]
Internet-Draft ACTN YANG June 2017
to the MDSC. Note that this interface is not in the scope of ACTN.
This section is provided just for an illustration purpose.
6. Security
This document is an informational draft. When the models mentioned
in this draft are implemented, detailed security consideration will
be given in such work.
How security fits into the whole architecture has the following
components:
- the use of Restconf security between components
- the use of authentication and policy to govern which services can
be requested by different parties.
- how security may be requested as an element of a service and
mapped down to protocol security mechanisms as well as separation
(slicing) of physical resources)
7. Acknowledgements
We thank Adrian Farrel for providing useful comments and suggestions
for this draft.
8. References
8.1. Informative References
[Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models
Explained", draft-wu-opsawg-service-model-explained, work
in progress.
[Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C.
Moberg, "YANG Module Classification", draft-ietf-netmod-
yang-model-classification, work in progress.
[Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241.
[Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf, work in progress.
Zhang, et al. Expires December 30, 2017 [Page 14]
Internet-Draft ACTN YANG June 2017
[ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for
Abstraction and Control of TE Networks", draft-ietf-teas-
actn-requirements, work in progress.
[ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas-
actn-framework, work in progress.
[TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress.
[TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress.
[ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
Operation", draft-lee-teas-actn-vn-yang, work in progress.
[ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction
and Control of TE Networks (ACTN)", draft-leebelotti-teas-
actn-info, work in progress.
[Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model
for Connection-oriented Transport Networks", draft-zhang-
teas-transport-service-model, work in progress.
[PATH-COMPUTATION-API] I.Busi/S.Belotti et al. "Path Computation
API", draft-busibel-ccamp-path-computation-api-00.txt,
work in progress
[RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource
Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp,
work in progress.
[Schedule] X. Liu, et. al., "A YANG Data Model for Configuration
Scheduling", draft-liu-netmod-yang-schedule, work in
progress.
[ACTN-Abstraction] Y. Lee, D. Dhody, and D. Ceccarelli, "ACTN
Abstraction Methods", draft-lee-tease-actn-abstraction,
work in progress.
[OTN-YANG] X. Zhang, A. Sharma, and X. Liu, "A YANG Data Model for
Optical Transport Network Topology", draft-zhang-ccamp-l1-
topo-yang, work in progress.
Zhang, et al. Expires December 30, 2017 [Page 15]
Internet-Draft ACTN YANG June 2017
[WSON-YANG] Y. Lee, et. al., "A Yang Data Model for WSON Optical
Networks", draft-ietf-ccamp-wson-yang, work in progress.
[Flexi-YANG] J.E. Lopez de Vergara, et. al., "YANG data model for
Flexi-Grid Optical Networks", draft-vergara-ccamp-flexigrid-
yang, work in progress.[ODU-Tunnel] Sharma, R. Rao, and
X. Zhang, "OTN Service YANG Model", draft-sharma-ccamp-
otn-service-model, work in progress.
[ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D.
King, and D. Ceccarelli, "YANG models for ACTN TE
Performance Monitoring Telemetry and Network Autonomics",
draft-lee-teas-actn-pm-telemetry-autonomics, work in
progress.
[WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R.
Vilalta, "A Yang Data Model for WSON Tunnel", draft-lee-
ccamp-wson-tunnel-model, work in progress.
[Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de
Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model
for Flexi-Grid media-channels", draft-vergara-ccamp-
flexigrid-media-channel-yang, work in progress.
9. Contributors
Contributor's Addresses
Dhruv Dhody
Huawei Technologies
Email: dhruv.ietf@gmail.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Zhang, et al. Expires December 30, 2017 [Page 16]
Internet-Draft ACTN YANG June 2017
Authors' Addresses
Young Lee
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com
Bin Yeong Yoon
ETRI
Email: byyun@etri.re.kr
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Jong Yoon Shin
SKT
Email: jongyoon.shin@sk.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Zhang, et al. Expires December 30, 2017 [Page 17]
