draft-ietf-teas-actn-yang-08.txt   draft-ietf-teas-actn-yang-09.txt 
TEAS WG Young Lee TEAS WG Young Lee
Internet Draft Samsung Internet Draft Samsung
Intended status: Informational Haomian Zheng Intended status: Informational Haomian Zheng
Expires: March 8, 2022 Huawei Expires: September 7, 2022 Huawei
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Sergio Belotti Sergio Belotti
Nokia Nokia
September 8, 2021 March 7, 2022
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-08 draft-ietf-teas-actn-yang-09
Abstract Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network operations needed to orchestrate, control and manage virtual network operations needed to orchestrate, control and manage
large-scale multi-domain TE networks, so as to facilitate network large-scale multi-domain TE networks, so as to facilitate network
programmability, automation, efficient resource sharing, and end-to- programmability, automation, efficient resource sharing, and end-to-
end virtual service aware connectivity and network function end virtual service aware connectivity and network function
virtualization services. virtualization services.
This document explains how the different types of YANG models This document explains how the different types of YANG models
defined in the Operations and Management Area and in the Routing defined in the Operations and Management Area and in the Routing
Area are applicable to the ACTN framework. This document also shows Area are applicable to the ACTN framework. This document also shows
how the ACTN architecture can be satisfied using classes of data how the ACTN architecture can be satisfied using classes of data
model that have already been defined, and discusses the model that have already been defined, and discusses the
applicability of specific data models that are under development. It applicability of specific data models that are under development. It
also highlights where new data models may need to be developed. also highlights where new data models may need to be developed.
Status of this Memo Status of this Memo
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 March 8, 2022. This Internet-Draft will expire on March 8, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction ................................................ 3
1.1. Conventions Used in This Document.........................3 1.1. Conventions Used in This Document ...................... 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..................................7 4. Service Model Mapping to ACTN ............................... 7
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 ........... 10
5.1. Topology Collection......................................10 5.1. Topology Collection ................................... 10
5.2. Connectivity over Two Nodes..............................10 5.2. Connectivity over Two Nodes ........................... 10
5.3. VN example...............................................11 5.3. VN example ............................................ 11
5.4. Data Center-Interconnection Example......................12 5.4. Data Center-Interconnection Example ................... 12
5.4.1. CMI (CNC-MDSC Interface)............................14 5.4.1. CMI (CNC-MDSC Interface) ......................... 14
5.4.2. MPI (MDSC-PNC Interface)............................14 5.4.2. MPI (MDSC-PNC Interface) ......................... 14
5.4.3. SBI (Southbound interface between PNC and devices)..14 5.4.3. SBI (Southbound interface between PNC and devices) 14
6. Security......................................................15 6. Security ................................................... 15
7. IANA Considerations...........................................15 7. IANA Considerations ........................................ 15
8. Acknowledgements..............................................15 8. Acknowledgements ........................................... 15
9. References....................................................15 9. References ................................................. 15
9.1. Informative References...................................15 9.1. Informative References................................. 15
10. Contributors.................................................18 10. Contributors .............................................. 18
Authors' Addresses...............................................18 Authors' Addresses ............................................ 18
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
operating a Traffic Engineered (TE) network (such as an MPLS-TE operating a Traffic Engineered (TE) network (such as an MPLS-TE
network or a layer 1 transport network) to provide connectivity and network or a layer 1 transport network) to provide connectivity and
virtual network for customers of the TE network. The services virtual network for customers of the TE network. The services
provided can be tuned to meet the requirements (such as traffic provided can be tuned to meet the requirements (such as traffic
patterns, quality, and reliability) of the applications hosted by patterns, quality, and reliability) of the applications hosted by
the customers. More details about ACTN can be found in Section 2. the customers. More details about ACTN can be found in Section 2.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
- - ( ) ( ) ----- - - ( ) ( ) -----
( ) ( Phys. ) ( Phys. ) ( ) ( Phys. ) ( Phys. )
-------- ( Net ) ( Net ) -------- ( Net ) ( Net )
----- ----- ----- -----
Figure 1 : ACTN Interfaces Figure 1 : ACTN Interfaces
The interfaces and functions are described below (without modifying The interfaces and functions are described below (without modifying
the definitions) in [RFC8453]: the definitions) in [RFC8453]:
. The CNC-MDSC Interface (CMI) is an interface between a CNC and The CNC-MDSC Interface (CMI) is an interface between a CNC and
an MDSC. This interface is used to communicate the service an MDSC. This interface is used to communicate the service
request or application demand. A request will include specific request or application demand. A request will include specific
service properties, for example, services type, bandwidth and service properties, for example, services type, bandwidth and
constraint information. These constraints SHOULD be measurable constraint information. These constraints SHOULD be measurable
by MDSC and therefore visible to CNC via CMI. The CNC can also by MDSC and therefore visible to CNC via CMI. The CNC can also
request the creation of the virtual network based on underlying request the creation of the virtual network based on underlying
physical resources to provide network services for the physical resources to provide network services for the
applications. The CNC can provide the end-point applications. The CNC can provide the end-point
information/characteristics together with traffic matrix information/characteristics together with traffic matrix
specifying specific customer constraints. The MDSC may also specifying specific customer constraints. The MDSC may also
report potential network topology availability if queried for report potential network topology availability if queried for
current capability from the Customer Network Controller. current capability from the Customer Network Controller.
Performance monitoring is also applicable in CMI, which enables Performance monitoring is also applicable in CMI, which enables
the MDSC to report network parameters/telemetries that may the MDSC to report network parameters/telemetries that may
guide the CNC to create/change their services. guide the CNC to create/change their services.
. The MDSC-PNC Interface (MPI) is an interface between a MDSC and The MDSC-PNC Interface (MPI) is an interface between a MDSC and
a PNC. It allows the MDSC to communicate requests to a PNC. It allows the MDSC to communicate requests to
create/delete connectivity or to modify bandwidth reservations create/delete connectivity or to modify bandwidth reservations
in the physical network. In multi-domain environments, each PNC in the physical network. In multi-domain environments, each PNC
is responsible for a separate domain. The MDSC needs to is responsible for a separate domain. The MDSC needs to
establish multiple MPIs, one for each PNC and perform establish multiple MPIs, one for each PNC and perform
coordination between them to provide cross-domain connectivity. coordination between them to provide cross-domain connectivity.
MPI plays an important role for multi-vendor mechanism, inter- MPI plays an important role for multi-vendor mechanism, inter-
operability can be achieved by standardized interface modules. operability can be achieved by standardized interface modules.
. The South-Bound Interface (SBI) is the provisioning interface The South-Bound Interface (SBI) is the provisioning interface
for creating forwarding state in the physical network, for creating forwarding state in the physical network,
requested via the PNC. The SBI is not in the scope of ACTN, requested via the PNC. The SBI is not in the scope of ACTN,
however, it is included in this document so that it can be however, it is included in this document so that it can be
compared to models in [RFC8309]. compared to models in [RFC8309].
3. Service Models 3. Service Models
[RFC8309] introduces a reference architecture to explain the nature [RFC8309] introduces a reference architecture to explain the nature
and usage of service YANG models in the context of service and usage of service YANG models in the context of service
orchestration. Figure 2 below depicts this relationship and is a orchestration. Figure 2 below depicts this relationship and is a
reproduction of Figure 2 from [RFC8309]. Four models depicted in reproduction of Figure 2 from [RFC8309]. Four models depicted in
Figure 2 are defined as follows: Figure 2 are defined as follows:
. Customer Service Model: A customer service model is used to Customer Service Model: A customer service model is used to
describe a service as offer or delivered to a customer by a describe a service as offer or delivered to a customer by a
network operator. network operator.
. Service Delivery Model: A service delivery model is used by a Service Delivery Model: A service delivery model is used by a
network operator to define and configure how a service is network operator to define and configure how a service is
provided by the network. provided by the network.
. Network Configuration Model: A network configuration model is Network Configuration Model: A network configuration model is
used by a network orchestrator to provide network-level used by a network orchestrator to provide network-level
configuration model to a controller. configuration model to a controller.
. Device Configuration Model: A device configuration model is Device Configuration Model: A device configuration model is
used by a controller to configure physical network elements. used by a controller to configure physical network elements.
Customer Customer
------------------ Service ---------- ------------------ Service ----------
| | Model | | | | Model | |
| Service |<-------->| Customer | | Service |<-------->| Customer |
| Orchestrator | | | | Orchestrator | | |
| | ---------- | | ----------
------------------ ------------------
. . ----------- . . -----------
skipping to change at page 7, line 17 skipping to change at page 7, line 17
YANG models coupled with the RESTCONF/NETCONF protocol YANG models coupled with the RESTCONF/NETCONF protocol
[RFC6241][RFC8040] provides solutions for the ACTN framework. This [RFC6241][RFC8040] provides solutions for the ACTN framework. This
section explains which types of YANG models apply to each of the section explains which types of YANG models apply to each of the
ACTN interfaces. ACTN interfaces.
Refer to Figure 5 of [RFC8453] for details of the mapping between Refer to Figure 5 of [RFC8453] for details of the mapping between
ACTN functions and service models. In summary, the following ACTN functions and service models. In summary, the following
mappings are held between and Service Yang Models in [RFC8309] and mappings are held between and Service Yang Models in [RFC8309] and
the ACTN interfaces in [RFC8453]. the ACTN interfaces in [RFC8453].
o Customer Service Model <-> CMI o Customer Service Model <-> CMI
o Network Configuration Model <-> MPI o Network Configuration Model <-> MPI
o Device Configuration Model <-> SBI o Device Configuration Model <-> SBI
4.1. Customer Service Models in the ACTN Architecture (CMI) 4.1. Customer Service Models in the ACTN Architecture (CMI)
Customer Service Models, which are used between a customer and a Customer Service Models, which are used between a customer and a
service orchestrator as in [RFC8309], should be used between the CNC service orchestrator as in [RFC8309], should be used between the CNC
and MDSC (e.g., CMI) serving as providing a simple intent-like and MDSC (e.g., CMI) serving as providing a simple intent-like
model/interface. model/interface.
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
----------------------------------------------------------- -----------------------------------------------------------
VN Service Request [ACTN-VN-YANG] VN Service Request [ACTN-VN-YANG]
VN Computation Request [ACTN-VN-YANG]* VN Computation Request [ACTN-VN-YANG]*
TE & Service Mapping [TE-Service-Mapping]** TE & Service Mapping [TE-Service-Mapping]**
VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]*** VN Performance Monitoring Telemetry [ACTN-PM-Telemetry]***
Topology Abstraction [RFC8795]**** Topology Abstraction [RFC8795]****
Layer 1 Connectivity Service Model [L1CSM] Layer 1 Connectivity Service Model [L1CSM]
Layer 2 VPN Service Model [RFC8466] Layer 2 VPN Service Model [RFC8466]
Layer 3 VPN Service Model [RFC8299] Layer 3 VPN Service Model [RFC8299]
*VN computation request in the CMI context means network path *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.
**[TE-Service-Mapping] provides a mapping and cross-references **[TE-Service-Mapping] provides a mapping and cross-references
between service models (e.g., L3SM, L2SM, L1CSM) and TE model via between service models (e.g., L3SM, L2SM, L1CSM) and TE model via
[ACTN-VN-YANG] and [RFC8795]. This model can be used as either [ACTN-VN-YANG] and [RFC8795]. This model can be used as either
Customer Service Models, or Service Delivery model described in Customer Service Models, or Service Delivery model described in
Section 4.2. Section 4.2.
skipping to change at page 9, line 9 skipping to change at page 9, line 9
Model can be also used for the foundation of more advanced models, Model can be also used for the foundation of more advanced models,
like hierarchical MDSCs (see Section 4.5) like hierarchical MDSCs (see Section 4.5)
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]
Tunnel/LSP Provisioning [TE-tunnel] Tunnel/LSP Provisioning [TE-tunnel]
Topology Abstraction [RFC8795] Topology Abstraction [RFC8795]
Service Provisioning [Client-signal]&[TE-tunnel]* Service Provisioning [Client-signal]&[TE-tunnel]*
Client Topology Abstraction [Client-topo] Client Topology Abstraction [Client-topo]
OTN Topology Abstraction [OTN-topo] OTN Topology Abstraction [OTN-topo]
WSON Topology Abstraction [RFC9094] WSON Topology Abstraction [WSON-topo]
Flexi-grid Topology Abstraction [Flexi-topo] Flexi-grid Topology Abstraction [Flexi-topo]
Microwave Topology Abstraction [MW-topo] Microwave Topology Abstraction [MW-topo]
Client Signal Description [Client-signal] Client Signal Description [Client-signal]
OTN Tunnel Model [OTN-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]
* This function is a combination of tunnel set up and client signal * This function is a combination of tunnel set up and client signal
description. Usually a tunnel is setting up first to get prepared to description. Usually a tunnel is setting up first to get prepared to
carry a client signal, in order to do the service provisioning. Then carry a client signal, in order to do the service provisioning. Then
the client signal is adapted to the established tunnel. It is worth the client signal is adapted to the established tunnel. It is worth
noting that various tunnel models such as [OTN-Tunnel] and [WSON- noting that various tunnel models such as [OTN-Tunnel] and [WSON-
Tunnel] can be used together with the [TE-tunnel] model to construct Tunnel] can be used together with the [TE-tunnel] model to construct
technology-specific tunnels, and carry different types of client technology-specific tunnels, and carry different types of client
signals. More details can be found in [Client-signal]. signals. More details can be found in [Client-signal].
skipping to change at page 10, line 23 skipping to change at page 10, line 23
in the network operation. A few typical generic scenarios are in the network operation. A few typical generic scenarios are
involved. In [T-NBI Applicability], there are more transport-related involved. In [T-NBI Applicability], there are more transport-related
scenarios and examples. scenarios and examples.
5.1. Topology Collection 5.1. Topology Collection
Before any connection is requested and delivered, the controller Before any connection is requested and delivered, the controller
needs to understand the network topology. The topology information needs to understand the network topology. The topology information
is exchanged among controllers with topology models, such as is exchanged among controllers with topology models, such as
[RFC8795]. Moreover, technology-specific topology reporting may use [RFC8795]. Moreover, technology-specific topology reporting may use
the model described in [OTN-topo] [RFC9094], and [Flexi-topo] for the model described in [OTN-topo] [WSON-topo], and [Flexi-topo] for
OTN, WSON and Flexi-grid, respectively. By collecting the network OTN, WSON and Flexi-grid, respectively. By collecting the network
topology, each controller can therefore construct a local database, topology, each controller can therefore construct a local database,
which can be used for the further service deployment. which can be used for the further service deployment.
There can be different types of abstraction applied between each There can be different types of abstraction applied between each
pair of controllers, corresponding method can be found in [RFC8453]. pair of controllers, corresponding method can be found in [RFC8453].
The technology-specific features may be hidden after abstraction, to The technology-specific features may be hidden after abstraction, to
make the network easier for the user to operate. make the network easier for the user to operate.
When there is a topology change in the physical network, the PNC When there is a topology change in the physical network, the PNC
skipping to change at page 10, line 47 skipping to change at page 10, line 47
synchronization. synchronization.
5.2. Connectivity over Two Nodes 5.2. Connectivity over Two Nodes
The service models, such as described in [RFC8299], [RFC8466] and The service models, such as described in [RFC8299], [RFC8466] and
[L1CSM] provide a customer service model which can be used in [L1CSM] provide a customer service model which can be used in
provider networks. provider networks.
It would be used as follows in the ACTN architecture: It would be used as follows in the ACTN architecture:
. A CNC uses the service models 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 that describes the
required quality and resilience of the service. required quality and resilience of the service.
. 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. picking the right domain sequence to deliver a service.
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]. Technology-specific tunnel configuration may use [TE-tunnel]. Technology-specific tunnel configuration may use
the model described in [OTN-Tunnel] [WSON-Tunnel], and the model described in [OTN-Tunnel] [WSON-Tunnel], and
[Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively. [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively.
. Then, the PNCs need to decide the explicit route of such a Then, the PNCs need to decide the explicit route of such a
tunnel or tunnel segment (in case of multiple domains) for each tunnel or tunnel segment (in case of multiple domains) for each
domain, and then create such a tunnel using protocols such as domain, and then create such a tunnel using protocols such as
PCEP and RSVP-TE or using per-hop configuration. PCEP and RSVP-TE or using per-hop configuration.
5.3. VN example 5.3. VN 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 evaluate each candidate and then choose the MDSC needs to evaluate each candidate and then choose
the best one and reply with the chosen destination for a the best one and reply with the chosen destination for a
given VN member. After this is selected, the connectivity given VN member. After this is selected, the connectivity
request setup procedure is the same as in the connectivity request setup procedure is the same as in the connectivity
example in section 5.2. 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].
skipping to change at page 17, line 20 skipping to change at page 17, line 20
Networks", RFC 9094. Networks", RFC 9094.
[Flexi-topo] J.E. Lopez de Vergara, et. al., "YANG data model for [Flexi-topo] J.E. Lopez de Vergara, et. al., "YANG data model for
Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid- Flexi-Grid Optical Networks", draft-ietf-ccamp-flexigrid-
yang, work in progress. yang, work in progress.
[MW-topo] M. Ye, et. al., "A YANG Data Model for Microwave [MW-topo] M. Ye, et. al., "A YANG Data Model for Microwave
Topology", draft-ietf-ccamp-mw-topo-yang, work in Topology", draft-ietf-ccamp-mw-topo-yang, work in
progress. progress.
[OTN-Tunnel] H. Zheng, et. al., "OTN Tunnel YANG Model", draft- [OTN-Tunnel] H. Zheng, et. al., "OTN Tunnel YANG Model", draft-
ietf-ccamp-otn-tunnel-model, work in progress. ietf-ccamp-otn-tunnel-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-ietf-teas-actn-pm-telemetry-autonomics, work in draft-ietf-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-ietf- Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf-
 End of changes. 29 change blocks. 
84 lines changed or deleted 84 lines changed or added

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