draft-ietf-teas-actn-yang-03.txt   draft-ietf-teas-actn-yang-04.txt 
TEAS WG Young Lee TEAS WG Young Lee
Haomian Zheng Internet Draft Futurewei
Internet Draft Huawei Intended status: Informational Haomian Zheng
Intended status: Informational Expires: February 16, 2020 Huawei
Daniele Ceccarelli Daniele Ceccarelli
Expires: February 23, 2019 Ericsson Ericsson
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica Telefonica
Jong Yoon Shin Jong Yoon Shin
SKT SKT
Sergio Belotti Sergio Belotti
Nokia Nokia
February 23, 2019 August 16, 2019
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-03 draft-ietf-teas-actn-yang-04
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 41
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 August 23, 2019. This Internet-Draft will expire on February 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 44 skipping to change at page 2, line 40
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.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ................................................ 3
2. Abstraction and Control of TE Networks (ACTN) Architecture .. 3 1.1. Conventions Used in This Document ...................... 3
2. Abstraction and Control of TE Networks (ACTN) Architecture... 4
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.1. Topology Collection ................................... 10 5. Examples of Using Different Types of YANG Models ............ 10
5.2. Connectivity over Two Nodes ........................... 10 5.1. Topology Collection ................................... 10
5.3. VN service example .................................... 11 5.2. Connectivity over Two Nodes ............................ 10
5.4. Data Center-Interconnection Example ................... 12 5.3. VN example ............................................. 11
5.4.1. CMI (CNC-MDSC Interface) ......................... 14 5.4. Data Center-Interconnection Example .................... 12
5.4.2. MPI (MDSC-PNC Interface) ......................... 14 5.4.1. CMI (CNC-MDSC Interface) .......................... 14
5.4.3. SBI (Southbound interface between PNC and devices) 14 5.4.2. MPI (MDSC-PNC Interface) .......................... 14
5.4.3. SBI (Southbound interface between PNC and devices). 14
6. Security ................................................... 15 6. Security ................................................... 15
7. Acknowledgements ........................................... 15 7. IANA Considerations ........................................ 15
8. References ................................................. 15 8. Acknowledgements ........................................... 15
8.1. Informative References................................. 15 9. References ................................................. 15
9. Contributors ............................................... 17 9.1. Informative References ................................ 15
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 services for customers of the TE network. The virtual network for customers of the TE network. The services
services provided can be tuned to meet the requirements (such as provided can be tuned to meet the requirements (such as traffic
traffic patterns, quality, and reliability) of the applications patterns, quality, and reliability) of the applications hosted by
hosted by the customers. More details about ACTN can be found in the customers. More details about ACTN can be found in Section 2.
Section 2.
Data models are a representation of objects that can be configured Data models are a representation of objects that can be configured
or monitored within a system. Within the IETF, YANG [RFC6241] is the or monitored within a system. Within the IETF, YANG [RFC6241] is the
language of choice for documenting data models, and YANG models have language of choice for documenting data models, and YANG models have
been produced to allow configuration or modelling of a variety of been produced to allow configuration or modelling of a variety of
network devices, protocol instances, and network services. YANG data network devices, protocol instances, and network services. YANG data
models have been classified in [RFC8199] and [RFC8309]. models have been classified in [RFC8199] and [RFC8309].
This document shows how the ACTN architecture can be satisfied using This document shows how the ACTN architecture can be satisfied using
various classes of data model that have already been defined, and various classes of data model that have already been defined, and
discusses the applicability of specific data models that are under discusses the applicability of specific data models that are under
development. It also highlights where new data models may need to be development. It also highlights where new data models may need to be
developed. developed.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Abstraction and Control of TE Networks (ACTN) Architecture 2. Abstraction and Control of TE Networks (ACTN) Architecture
[RFC8453] describes the architecture model for ACTN including the [RFC8453] describes the architecture model for ACTN including the
entities (Customer Network Controller (CNC), Multi-domain Service entities (Customer Network Controller (CNC), Multi-domain Service
Coordinator (MDSC), and Provisioning Network Controller (PNC)) and Coordinator (MDSC), and Provisioning Network Controller (PNC)) and
their interfaces. their interfaces.
Figure 1 depicts a high-level control and interface architecture for Figure 1 depicts a high-level control and interface architecture for
ACTN and is a reproduction of Figure 3 from [RFC8453]. A number of ACTN and is a reproduction of Figure 3 from [RFC8453]. A number of
key ACTN interfaces exist for deployment and operation of ACTN-based key ACTN interfaces exist for deployment and operation of ACTN-based
networks. These are highlighted in Figure 1 (ACTN Interfaces) below: networks. These are highlighted in Figure 1 (ACTN Interfaces) below:
+--------------+ +---------------+ +--------------+ +--------------+ +---------------+ +--------------+
| CNC-A | | CNC-B | | CNC-C | | CNC-A | | CNC-B | | CNC-C |
|(DC provider) | | (ISP) | | (MVNO) | |(DC provider) | | (ISP) | | (MVNO) |
+--------------+ +---------------+ +--------------+ +--------------+ +---------------+ +--------------+
\ | / \ | /
Business \ | / Business \ | /
Boundary =======\========================|=========================/======= Boundary =====\======================|=======================/======
Between \ | CMI / Between \ | CMI /
Customer & ----------- | -------------- Customer & ----------- | --------------
Network Provider \ | / Network Provider \ | /
+-----------------------+ +---------------------+
| MDSC | | MDSC |
+-----------------------+ +---------------------+
/ | \ / | \
------------ |MPI ---------------- ---------- |MPI --------------
/ | \ / | \
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| PNC | | PNC | | PNC | | PNC | | PNC | | PNC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| GMPLS / | / \ | GMPLS / | / \
| trigger / |SBI 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 )
----- ----- ----- -----
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 service based on request the creation of the virtual network based on underlying
underlying physical resources to provide network services for physical resources to provide network services for the
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
skipping to change at page 7, line 38 skipping to change at page 7, line 39
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 [TE-topology]**** Topology Abstraction [TE-topology]****
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
skipping to change at page 9, line 12 skipping to change at page 9, line 14
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 [TE-topology] Topology Abstraction [TE-topology]
Client Signal Description [Client-signal] Service Provisioning [Client-signal]&[TE-tunnel]*
Service Provisioning [Client-signal]&[TE-tunnel]*
OTN Topology Abstraction [OTN-topo] Client Topology Abstraction [Client-topo]
OTN Topology Abstraction [OTN-topo]
WSON Topology Abstraction [WSON-topo] 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]
OTN Tunnel Model [OTN-Tunnel] Client Signal Description [Client-signal]
WSON TE Tunnel Model [WSON-Tunnel] OTN Tunnel Model [OTN-Tunnel]
Flexi-grid Tunnel Model [Flexigrid-Tunnel] WSON TE Tunnel Model [WSON-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 11, line 30 skipping to change at page 11, line 34
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 service 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 13, line 11 skipping to change at page 13, line 11
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 [RFC8454]. from [RFC8454].
+----------------+ +----------------+
| CNC | | CNC |
| (Global DC | | (Global DC |
| Operation | | Operation |
| Control) | | Control) |
+--------+-------+ +--------+-------+
| | VN Requirement/Policy: | | VN Requirement/Policy:
CMI: | | - Endpoint/DC location info CMI: | |- Endpoint/DC location info
Service model | | - Endpoint/DC dynamic Service model | |- Endpoint/DC dynamic
| | selection policy | | selection policy
| | (for VM migration, DR, LB) | | (for VM migration, DR, LB)
| v | v
+---------+---------+ +---------+---------+
| Multi-domain | Service policy-driven | Multi-domain | Service policy-driven
|Service Coordinator| dynamic DC selection |Service Coordinator| dynamic DC selection
MPI: +-----+---+---+-----+ MPI: +-----+---+---+-----+
Network Configuration | | | Network Configuration | | |
Model | | | Model | | |
+----------------+ | +---------------+ +----------------+ | +---------------+
| | | | | |
+-----+-----+ +------+-----+ +------+-----+ +-----+-----+ +------+-----+ +------+-----+
skipping to change at page 15, line 25 skipping to change at page 15, line 25
- the use of Restconf security between components - the use of Restconf security between components
- the use of authentication and policy to govern which services can - the use of authentication and policy to govern which services can
be requested by different parties. be requested by different parties.
- how security may be requested as an element of a service and - how security may be requested as an element of a service and
mapped down to protocol security mechanisms as well as separation mapped down to protocol security mechanisms as well as separation
(slicing) of physical resources) (slicing) of physical resources)
7. Acknowledgements 7. IANA Considerations
This document requires no IANA actions.
8. Acknowledgements
We thank Adrian Farrel for providing useful comments and suggestions We thank Adrian Farrel for providing useful comments and suggestions
for this draft. for this draft.
8. References 9. References
8.1. Informative References 9.1. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained",
RFC 8309. RFC 8309.
[RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module
Classification", RFC 8199. Classification", RFC 8199.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241. (NETCONF)", RFC 6241.
[RFC8040] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF [RFC8040] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
Protocol", RFC 8040. Protocol", RFC 8040.
[RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and [RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", RFC8453. Control of Traffic Engineered Networks", RFC8453.
[RFC8466] B. Wen, G. Fioccola, C. Xie, L. Jalil, "A YANG Data Model
for L2VPN Service Delivery", RFC8466.
[RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC8299.
[RFC8454] Y. Lee & S. Belotti, "Information Model for Abstraction
and Control of TE Networks (ACTN)", RFC8454.
[RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource
Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp,
work in progress.
[TE-topology] X. Liu, et. al., "YANG Data Model for TE Topologies", [TE-topology] X. Liu, et. al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress. draft-ietf-teas-yang-te-topo, work in progress.
[TE-tunnel] T. Saad (Editor), "A YANG Data Model for Traffic [TE-tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress. te, work in progress.
[ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
Operation", draft-lee-teas-actn-vn-yang, work in progress. Operation", draft-lee-teas-actn-vn-yang, work in progress.
[L1CSM] G. Fioccola, K. Lee, Y. Lee, D. Dhody, O. Gonzalez de-Dios, [L1CSM] G. Fioccola, K. Lee, Y. Lee, D. Dhody, O. Gonzalez de-Dios,
D. Ceccarelli, "A Yang Data Model for L1 Connectivity D. Ceccarelli, "A Yang Data Model for L1 Connectivity
Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work
in progress. in progress.
[RFC8466] B. Wen, G. Fioccola, C. Xie, L. Jalil, "A YANG Data Model
for L2VPN Service Delivery", RFC8466.
[RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC8299.
[RFC8454] Y. Lee & S. Belotti, "Information Model for Abstraction
and Control of TE Networks (ACTN)", RFC8454.
[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 [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration
Scheduling", draft-liu-netmod-yang-schedule, work in Scheduling", draft-liu-netmod-yang-schedule, work in
progress. progress.
[OTN-topo] H. Zheng, et. al., "A YANG Data Model for Optical [OTN-topo] H. Zheng, et. al., "A YANG Data Model for Optical
Transport Network Topology", draft-ietf-ccamp-otn-topo- Transport Network Topology", draft-ietf-ccamp-otn-topo-
yang, work in progress. yang, work in progress.
[WSON-topo] Y. Lee, et. al., "A Yang Data Model for WSON Optical [WSON-topo] Y. Lee, et. al., "A Yang Data Model for WSON Optical
Networks", draft-ietf-ccamp-wson-yang, work in progress. Networks", draft-ietf-ccamp-wson-yang, work in progress.
[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-vergara-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-lee-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-
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-ietf-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 [Client-signal] H. Zheng, et al, "A YANG Data Model for Optical
Transport Network Client Signals", draft-zheng-ccamp- Transport Network Client Signals", draft-ietf-ccamp-
client-signal-yang, work in progress. client-signal-yang, work in progress.
[Client-topo] H. Zheng, et al, "A YANG Data Model for Ethernet TE
Topology", draft-zheng-ccamp-client-topo-yang, work in
progress.
[TE-topo-tunnel] I.Bryskin, et. al., "TE Topology and Tunnel [TE-topo-tunnel] I.Bryskin, et. al., "TE Topology and Tunnel
Modeling for Transport Networks", draft-ietf-teas-te-topo- Modeling for Transport Networks", draft-ietf-teas-te-topo-
and-tunnel-modeling, work in progress. and-tunnel-modeling, work in progress.
[T-NBI Applicability] I. Busi, et al, "Transport Northbound [T-NBI Applicability] I. Busi, et al, "Transport Northbound
Interface Applicability Statement and Use Cases", draft- Interface Applicability Statement and Use Cases", draft-
ietf-ccamp-transport-nbi-app-statement, work in progress. ietf-ccamp-transport-nbi-app-statement, work in progress.
[gmpls-controller-inter-work] H. Zheng, et al, "Interworking of [gmpls-controller-inter-work] H. Zheng, et al, "Interworking of
GMPLS Control and Centralized Controller System", draft- GMPLS Control and Centralized Controller System", draft-
zheng-teas-gmpls-controller-inter-work, work in progress. ietf-teas-gmpls-controller-inter-work, work in progress.
9. Contributors 10. 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
skipping to change at page 18, line 17 skipping to change at page 18, line 34
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
Authors' Addresses Authors' Addresses
Young Lee Young Lee
Huawei Technologies Futurewei Technologies
5340 Legacy Drive 5700 Tennyson Parkway, Suite 600
Plano, TX 75023, USA Plano, TX 75024, USA
Phone: (469)277-5838 Email: younglee.tx@gmail.com
Email: leeyoung@huawei.com
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Torshamnsgatan,48 Torshamnsgatan,48
Stockholm, Sweden Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Email: byyun@etri.re.kr Email: byyun@etri.re.kr
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica Telefonica
Email: oscar.gonzalezdedios@telefonica.com Email: oscar.gonzalezdedios@telefonica.com
Jong Yoon Shin Jong Yoon Shin
SKT SKT
Email: jongyoon.shin@sk.com Email: jongyoon.shin@sk.com
Sergio Belotti Sergio Belotti
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
 End of changes. 51 change blocks. 
131 lines changed or deleted 144 lines changed or added

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