draft-ietf-teas-actn-yang-00.txt   draft-ietf-teas-actn-yang-01.txt 
TEAS WG Young Lee TEAS WG Young Lee
Haomian Zheng Internet Draft Haomian Zheng
Internet Draft Huawei Intended status: Informational Huawei
Intended status: Informational Expires: August 28, 2018
Daniel Ceccarrelli Daniel Ceccarelli
Expires: May 12, 2018 Ericsson Ericsson
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Oscar Gonzalez de Dios
Telefonica
Jong Yoon Shin
SKT
Sergio Belotti Sergio Belotti
Nokia Nokia
November 12, 2017 February 28, 2018
Applicability of YANG models for Abstraction and Control of Traffic Applicability of YANG models for Abstraction and Control of Traffic
Engineered Networks Engineered Networks
draft-ietf-teas-actn-yang-00 draft-ietf-teas-actn-yang-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 4 skipping to change at page 1, line 39
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 12, 2017. This Internet-Draft will expire on August 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 3, line 8 skipping to change at page 2, line 47
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Abstraction and Control of TE Networks (ACTN) Architecture.....3 2. Abstraction and Control of TE Networks (ACTN) Architecture.....3
3. Service Models.................................................5 3. Service Models.................................................5
4. Service Model Mapping to ACTN..................................6 4. Service Model Mapping to ACTN..................................6
4.1. Customer Service Models in the ACTN Architecture (CMI)....7 4.1. Customer Service Models in the ACTN Architecture (CMI)....7
4.2. Service Delivery Models in ACTN Architecture..............8 4.2. Service Delivery Models in ACTN Architecture..............8
4.3. Network Configuration Models in ACTN Architecture (MPI)...8 4.3. Network Configuration Models in ACTN Architecture (MPI)...8
4.4. Device Models in ACTN Architecture (SBI)..................9 4.4. Device Models in ACTN Architecture (SBI)..................9
5. Examples of Using Different Types of YANG Models..............10 5. Examples of Using Different Types of YANG Models...............9
5.1. Simple Connectivity Examples.............................10 5.1. Topology Collection.......................................9
5.2. VN service example.......................................10 5.2. Connectivity over Two Client Nodes.......................10
5.3. Data Center-Interconnection Example......................11 5.3. VN service example.......................................11
5.3.1. CMI (CNC-MDSC Interface)............................13 5.4. Data Center-Interconnection Example......................11
5.3.2. MPI (MDSC-PNC Interface)............................13 5.4.1. CMI (CNC-MDSC Interface)............................13
5.3.3. PDI (PNC-Device interface)..........................13 5.4.2. MPI (MDSC-PNC Interface)............................13
6. Security......................................................14 6. Security......................................................14
7. Acknowledgements..............................................14 7. Acknowledgements..............................................14
8. References....................................................14 8. References....................................................14
8.1. Informative References...................................14 8.1. Informative References...................................14
9. Contributors..................................................16 9. Contributors..................................................16
Authors' Addresses...............................................17 Authors' Addresses...............................................17
1. Introduction 1. Introduction
Abstraction and Control of TE Networks (ACTN) describes a method for Abstraction and Control of TE Networks (ACTN) describes a method for
skipping to change at page 4, line 34 skipping to change at page 4, line 31
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+
/ | \ / | \
------------ |MPI ---------------- ------------ |MPI ----------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| GMPLS / | / \ | GMPLS / | / \
| trigger / |SBI / \ | trigger / |SBI SBI / \
-------- ----- | / \ -------- ----- | / \
( ) ( ) | / \ ( ) ( ) | / \
- - ( Phys. ) | / ----- - - ( Phys. ) | / -----
( GMPLS ) ( Net ) | / ( ) ( GMPLS ) ( Net ) | / ( )
( Physical ) ---- | / ( Phys. ) ( Physical ) ---- | / ( Phys. )
( Network ) ----- ----- ( Net ) ( Network ) ----- ----- ( Net )
- - ( ) ( ) ----- - - ( ) ( ) -----
( ) ( Phys. ) ( Phys. ) ( ) ( Phys. ) ( Phys. )
-------- ( Net ) ( Net ) -------- ( Net ) ( Net )
----- ----- ----- -----
skipping to change at page 7, line 31 skipping to change at page 7, line 28
Among the key functions of Customer Service Models on the CMI is the Among the key functions of Customer Service Models on the CMI is the
service request. A request will include specific service properties, service request. A request will include specific service properties,
including: service type and its characteristics, bandwidth, including: service type and its characteristics, bandwidth,
constraint information, and end-point characteristics. constraint information, and end-point characteristics.
The following table provides a list of functions needed to build the The following table provides a list of functions needed to build the
CMI. They are mapped with Customer Service Models. CMI. They are mapped with Customer Service Models.
Function Yang Model 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 VN Service Request [ACTN-VN-YANG]
VN Computation Request [ACTN-VN-YANG]*
TE & Service Mapping [TE-Service-Mapping]**
VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]***
Topology Abstraction [TE-topology]****
*VN computation request in the CMI context means network path
computation request based on customer service connectivity request computation request based on customer service connectivity request
constraints prior to the instantiation of a VN creation. constraints prior to the instantiation of a VN creation.
**ietf-actn-te-kpi-telemetry model describes performance telemetry **[TE-Service-Mapping] provides a mapping and cross-references
between service models (e.g., L3SM, L2SM, L1CSM) and TE model via
[ACTN-VN-YANG] and [TE-topology].
***ietf-actn-te-kpi-telemetry model describes performance telemetry
for ACTN VN model. This module also allows autonomic traffic for ACTN VN model. This module also allows autonomic traffic
engineering scaling intent configuration mechanism on the VN level. engineering scaling intent configuration mechanism on the VN level.
Scale in/out criteria might be used for network autonomics in order Scale in/out criteria might be used for network autonomics in order
the controller to react to a certain set of variations in monitored the controller to react to a certain set of variations in monitored
parameters. Moreover, this module also provides mechanism to define parameters. Moreover, this module also provides mechanism to define
aggregated telemetry parameters as a grouping of underlying VN level aggregated telemetry parameters as a grouping of underlying VN level
telemetry parameters. telemetry parameters.
****TE-Topology's Connectivity Matrices/Matrix construct can be used
to instantiate VN Service via a suitable referencing and mapping
with [ACTN-VN-YANG].
4.2. Service Delivery Models in ACTN Architecture 4.2. Service Delivery Models in ACTN Architecture
The Service Delivery Models where the service orchestration and the The Service Delivery Models where the service orchestration and the
network orchestration could be implemented as separate components as network orchestration could be implemented as separate components as
seen in [Service-YANG]. This is also known as Network Service seen in [Service-YANG]. This is also known as Network Service
Models. On the other hand, from an ACTN architecture point of view, Models. On the other hand, from an ACTN architecture point of view,
the service delivery model between the service orchestrator and the the service delivery model between the service orchestrator and the
network orchestrator is an internal interface between sub-components network orchestrator is an internal interface between sub-components
of the MDSC in a single MDSC model. of the MDSC in a single MDSC model.
skipping to change at page 8, line 39 skipping to change at page 8, line 45
The Network Configuration Model captures the parameters which are The Network Configuration Model captures the parameters which are
network wide information. network wide information.
The following table provides a list of functions needed to build the The following table provides a list of functions needed to build the
MPI. They are mapped with Network Configuration Yang Models. Note MPI. They are mapped with Network Configuration Yang Models. Note
that various Yang models are work in progress. that various Yang models are work in progress.
Function Yang Model Function Yang Model
-------------------------------------------------------- --------------------------------------------------------
Configuration Scheduling [Schedule] Configuration Scheduling [Schedule]
Path computation [PATH_COMPUTATION-API]* Path computation [PATH_COMPUTATION-API]
Path Provisioning [TE-Tunnel]** Tunnel/LSP Provisioning [TE-Tunnel]
Topology Abstraction [TE-topology] Topology Abstraction [TE-topology]
Tunnel PM Telemetry [ACTN-PM-Telemetry]*** Client Signal Description [Client-signal]
Service Provisioning TBD**** Service Provisioning TBD*
OTN Topology Abstraction [OTN-YANG] OTN Topology Abstraction [OTN-YANG]
WSON Topology Abstraction [WSON-YANG] WSON Topology Abstraction [WSON-YANG]
Flexi-grid Topology Abstraction [Flexi-YANG] Flexi-grid Topology Abstraction [Flexi-YANG]
ODU Tunnel Model [ODU-Tunnel] OTN Tunnel Model [OTN-Tunnel]
WSON TE Tunnel Model [WSON-Tunnel] WSON TE Tunnel Model [WSON-Tunnel]
Flexi-grid Tunnel Model [Flexigrid-Tunnel] Flexi-grid Tunnel Model [Flexigrid-Tunnel]
* Related draft is presenting use cases for path computation API, * This function needs to be investigated further. This can be a part
and Yang related model is foreseen to be added. of [TE-Tunnel] which is to be determined. Service provisioning is an
optional function that builds on top the path provisioning one.
** 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. [T-NBI Applicability] provides a summary on the applicability of
existing YANG model usage in the current network configuration,
especially for transport network.
4.4. Device Models in ACTN Architecture (SBI) 4.4. Device Models in ACTN Architecture (SBI)
Note that SBI is not in the scope of ACTN, as there are already
mature protocol solutions for various purpose on the device level of
ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The
interworking of such protocols and ACTN controller hierarchies can
be found in [gmpls-controller-inter-work].
For the device YANG models are used for per-device configuration For the device YANG models are used for per-device configuration
purpose, they can be used between the PNC and the physical purpose, they can be used between the PNC and the physical
network/devices. Note that SBI is not in the scope of ACTN. This network/devices. One example of Device Models is ietf-te-device yang
section is provided to give some examples of YANG-based Device module defined in [TE-tunnel].
Models. An example of Device Models is ietf-te-device yang module
defined in [TE-tunnel].
5. Examples of Using Different Types of YANG Models 5. Examples of Using Different Types of YANG Models
5.1. Simple Connectivity Examples This section provides some examples on the usage of IETF YANG models
in the network operation. A few typical generic scenarios are
involved. In [T-NBI Applicability], there are more transport-related
scenarios and examples.
The data model in [Transport-Service-Model] provides an intent-like 5.1. Topology Collection
connectivity service model which can be used in connection-oriented
networks. Before any connection is requested and delivered, the controller
needs to understand the network topology. The topology information
is exchanged among controllers with topology models, such as [te-
topology]. Moreover, technology-specific topology reporting may use
the model described in [OTN-YANG] [WSON-YANG], and [Flexi-YANG] for
OTN, WSON and Flexi-grid, respectively. By collecting the network
topology, each controller can therefore construct a local database,
which can be used for the further service deployment.
There can be different types of abstraction applied between each
pair of controllers as discussed in in [ACTN-frame]. The technology-
specific features may be hidden after abstraction to make the
network operation easier.
When there are topology changes in the physical network, the PNC
should report the change to upper level of controllers via updating
messages using topology models. Accordingly, such changes are
propagated between different controllers for further
synchronization.
5.2. Connectivity over Two Client Nodes
The service models, such as described in [RFC8049], [L2SM] and
[L1CSM], provide a connectivity service model which can be used in
connection-oriented networks.
It would be used as follows in the ACTN architecture: It would be used as follows in the ACTN architecture:
. A CNC uses this service model to specify the two client nodes . A CNC uses the service models to specify the two client nodes
that are to be connected, and also indicates the amount of that are to be connected, and also indicates the amount of
traffic (i.e., the bandwidth required) and payload type. What traffic (i.e., the bandwidth required) and payload type. What
may be additionally specified is the SLA that describes the may be additionally specified is the SLA/Policy that describes
required quality and resilience of the service. the required quality and resilience of the service especially
on TE binding with the service (e.g., soft isolation, hard
isolation, etc.) as defined in [TE-Service-Mapping].
. The MDSC uses the information in the request to pick the right . The MDSC uses the information in the request to pick the right
network (domain) and also to select the provider edge nodes network (domain) and also to select the provider edge nodes
corresponding to the customer edge nodes. corresponding to the customer edge nodes.
If there are multiple domains, then the MDSC needs to If there are multiple domains, then the MDSC needs to
coordinate across domains to set up network tunnels to deliver coordinate across domains to set up network tunnels to deliver
a service. Thus coordination includes, but is not limited to, a service. Thus coordination includes, but is not limited to,
picking the right domain sequence to deliver a service. Before picking the right domain sequence to deliver a service.
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 Additionally, an MDSC can initiate the creation of a tunnel (or
tunnel segment) in order to fulfill the service request from tunnel segment) in order to fulfill the service request from
CNC based on path computation upon the overall topology CNC based on path computation upon the overall topology
information it synthesized from different PNCs. The based model information it synthesized from different PNCs. The based model
that can cater this purpose is the te-tunnel model specified in 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 [te-tunnel]. Technology-specific tunnel configuration may use
tunnel or tunnel segment (in case of multiple domains), and the model described in [OTN-Tunnel] [WSON-Tunnel], and
create such a tunnel using protocols such as PCEP and RSVP-TE [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively.
or using per-hop configuration.
5.2. VN service example . Then, the PNCs need to decide the explicit route of such a
tunnel or tunnel segment (in case of multiple domains) for each
domain, and then create such a tunnel using protocols such as
PCEP and RSVP-TE or using per-hop configuration.
5.3. VN service example
The service model defined in [ACTN-VN-YANG] describes a virtual The service model defined in [ACTN-VN-YANG] describes a virtual
network (VN) as a service which is a set of multiple connectivity network (VN) as a service which is a set of multiple connectivity
services: services:
. A CNC will request VN to the MDSC by specifying a list of VN . A CNC will request VN to the MDSC by specifying a list of VN
members. Each VN member specifies either a single connectivity members. Each VN member specifies either a single connectivity
service, or a source with multiple potential destination points service, or a source with multiple potential destination points
in the case that the precise destination sites are to be in the case that the precise destination sites are to be
determined by MDSC. determined by MDSC.
o In the first case, the procedure is the same as the o In the first case, the procedure is the same as the
connectivity service, except that in this case, there is a connectivity service, except that in this case, there is a
list of connections requested. list of connections requested.
o In the second case, where the CNC requests the MDSC to o In the second case, where the CNC requests the MDSC to
select the right destination out of a list of candidates, select the right destination out of a list of candidates,
the MDSC needs to choose the best candidate and reply with the MDSC needs to evaluate each candidate and then choose
the chosen destination for a given VN member. After this the best one and reply with the chosen destination for a
is selected, the connectivity request setup procedure is given VN member. After this is selected, the connectivity
the same as in the connectivity-as-a-service example. request setup procedure is the same as in the connectivity
example in section 5.2.
After the VN is set up, a successful reply message is sent from MDSC 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 to CNC, indicating the VN is ready. This message can also be
achieved by using the model defined in [ACTN-VN-YANG]. achieved by using the model defined in [ACTN-VN-YANG].
5.3. Data Center-Interconnection Example 5.4. Data Center-Interconnection Example
This section describes more concretely how existing YANG models This section describes more concretely how existing YANG models
described in Section 4 map to an ACTN data center interconnection described in Section 4 map to an ACTN data center interconnection
use case. Figure 3 shows a use-case which shows service policy- use case. Figure 3 shows a use-case which shows service policy-
driven Data Center selection and is a reproduction of Figure A.1 driven Data Center selection and is a reproduction of Figure A.1
from [ACTN-Info]. from [ACTN-Info].
+----------------+ +----------------+
| CNC | | CNC |
| (Global DC | | (Global DC |
skipping to change at page 13, line 20 skipping to change at page 13, line 20
applications. applications.
Data Center selection problems arise for VM mobility, disaster Data Center selection problems arise for VM mobility, disaster
recovery and load balancing cases. VN's policy plays an important recovery and load balancing cases. VN's policy plays an important
role for virtual network operation. Policy can be static or dynamic. role for virtual network operation. Policy can be static or dynamic.
Dynamic policy for data center selection may be placed as a result Dynamic policy for data center selection may be placed as a result
of utilization of data center resources supporting VMs. The MDSC of utilization of data center resources supporting VMs. The MDSC
would then incorporate this information to meet the objective of would then incorporate this information to meet the objective of
this application. this application.
5.3.1. CMI (CNC-MDSC Interface) 5.4.1. CMI (CNC-MDSC Interface)
[ACTN-VN-YANG] is used to express the definition of a VN, its VN [ACTN-VN-YANG] is used to express the definition of a VN, its VN
creation request, the service objectives (metrics, QoS parameters, creation request, the service objectives (metrics, QoS parameters,
etc.), dynamic service policy when VM needs to be moved from one etc.), dynamic service policy when VM needs to be moved from one
Data Center to another Data Center, etc. This service model is used 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 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. external entity that wants to create a VN and operates on the VN.
5.3.2. MPI (MDSC-PNC Interface) 5.4.2. MPI (MDSC-PNC Interface)
The Network Configuration Model is used between the MDSC and the The Network Configuration Model is used between the MDSC and the
PNCs. Based on the Customer Service Model's request, the MDSC will PNCs. Based on the Customer Service Model's request, the MDSC will
need to translate the service model into the network configuration need to translate the service model into the network configuration
model to instantiate a set of multi-domain connections between the model to instantiate a set of multi-domain connections between the
prescribed sources and the destinations. The MDSC will also need to prescribed DC sources and DC destinations. The MDSC will also need
dynamically interact with the CNC for dynamic policy changes to dynamically interact with the CNC for dynamic policy changes
initiated by the CNC. Upon the determination of the multi-domain initiated by the CNC. Upon the determination of the multi-domain
connections, the MDSC will need to use the network configuration connections, the MDSC will need to use the network configuration
model such as [TE-Tunnel] to interact with each PNC involved on the 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 path. [TE-Topology] is used to for the purpose of underlying domain
network abstraction from the PNC to the MDSC. 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
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 6. Security
This document is an informational draft. When the models mentioned This document is an informational draft. When the models mentioned
in this draft are implemented, detailed security consideration will in this draft are implemented, detailed security consideration will
be given in such work. be given in such work.
How security fits into the whole architecture has the following How security fits into the whole architecture has the following
components: components:
- the use of Restconf security between components - the use of Restconf security between components
skipping to change at page 16, line 21 skipping to change at page 16, line 21
X. Zhang, "OTN Service YANG Model", draft-sharma-ccamp- X. Zhang, "OTN Service YANG Model", draft-sharma-ccamp-
otn-service-model, work in progress. otn-service-model, work in progress.
[ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D. [ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D.
King, and D. Ceccarelli, "YANG models for ACTN TE King, and D. Ceccarelli, "YANG models for ACTN TE
Performance Monitoring Telemetry and Network Autonomics", Performance Monitoring Telemetry and Network Autonomics",
draft-lee-teas-actn-pm-telemetry-autonomics, work in draft-lee-teas-actn-pm-telemetry-autonomics, work in
progress. progress.
[WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R. [WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R.
Vilalta, "A Yang Data Model for WSON Tunnel", draft-lee- Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf-
ccamp-wson-tunnel-model, work in progress. ccamp-wson-tunnel-model, work in progress.
[Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de [Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de
Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model
for Flexi-Grid media-channels", draft-vergara-ccamp- for Flexi-Grid media-channels", draft-ietf-ccamp-
flexigrid-media-channel-yang, work in progress. flexigrid-media-channel-yang, work in progress.
[TE-Service-Mapping] Y. Lee, et al, "Traffic Engineering and Service
Mapping Yang Model", draft-lee-teas-te-service-mapping-
yang, work in progress.
[Client-signal] H. Zheng, et al, "A YANG Data Model for Optical
Transport Network Client Signals", draft-zheng-ccamp-otn-
client-signal-yang, work in progress.
[T-NBI Applicability] I. Busi, et al, "Transport Northbound
Interface Applicability Statement and Use Cases", draft-
ietf-ccamp-transport-nbi-app-statement, work in progress.
[gmpls-controller-inter-work] H. Zheng, et al, "Interworking of
GMPLS Control and Centralized Controller System", draft-
zheng-ccamp-gmpls-controller-inter-work, work in progress.
9. Contributors 9. Contributors
Contributor's Addresses Contributor's Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
 End of changes. 38 change blocks. 
103 lines changed or deleted 128 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/