draft-ietf-teas-actn-yang-05.txt   draft-ietf-teas-actn-yang-06.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: August 19, 2020 Huawei Technologies Expires: February 22, 2021 Huawei
Daniele Ceccarelli Daniele Ceccarelli
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 19, 2020 August 22, 2020
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-05 draft-ietf-teas-actn-yang-06
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 1, line 45 skipping to change at page 1, line 45
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 19, 2020. This Internet-Draft will expire on February 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 39 skipping to change at page 2, line 39
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.
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... 4 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. 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
skipping to change at page 7, line 43 skipping to change at page 7, line 43
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 [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 [TE-topology]. 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.
***ietf-actn-te-kpi-telemetry model in [ACTN-PM-Telemetry] describes ***ietf-actn-te-kpi-telemetry model in [ACTN-PM-Telemetry] describes
performance telemetry for ACTN VN model. This module also allows performance telemetry for ACTN VN model. This module also allows
autonomic traffic engineering scaling intent configuration mechanism autonomic traffic engineering scaling intent configuration mechanism
on the VN level. Scale in/out criteria might be used for network on the VN level. Scale in/out criteria might be used for network
autonomics in order the controller to react to a certain set of autonomics in order the controller to react to a certain set of
variations in monitored parameters. Moreover, this module also variations in monitored parameters. Moreover, this module also
provides mechanism to define aggregated telemetry parameters as a provides mechanism to define aggregated telemetry parameters as a
grouping of underlying VN level telemetry parameters. grouping of underlying VN level telemetry parameters.
****TE-Topology's Connectivity Matrices/Matrix construct can be used ****RFC8795's Connectivity Matrices/Matrix construct can be used to
to instantiate VN Service via a suitable referencing and mapping instantiate VN Service via a suitable referencing and mapping with
with [ACTN-VN-YANG]. [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 [RFC8309]. On the other hand, from an ACTN architecture seen in [RFC8309]. On the other hand, from an ACTN architecture
point of view, the service delivery model between the service point of view, the service delivery model between the service
orchestrator and the network orchestrator is an internal interface orchestrator and the network orchestrator is an internal interface
between sub-components of the MDSC in a single MDSC model. between sub-components of the MDSC in a single MDSC model.
skipping to change at page 9, line 16 skipping to change at page 9, line 16
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 [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 [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]
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]
skipping to change at page 9, line 39 skipping to change at page 9, line 39
* 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].
[TE-topo-tunnel] provides the clarification and example usage for TE [TE-topo-tunnel] provides the clarification and example usage for TE
topology model [TE-topology] and TE tunnel model [TE-tunnel]. [T-NBI topology model [RFC8795] and TE tunnel model [TE-tunnel]. [T-NBI
Applicability] provides a summary on the applicability of existing Applicability] provides a summary on the applicability of existing
YANG model usage in the current network configuration, especially YANG model usage in the current network configuration, especially
for transport network. 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 is already Note that SBI is not in the scope of ACTN, as there is already
mature protocol solutions for various purpose on the device level of mature protocol solutions for various purpose on the device level of
ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The
interworking of such protocols and ACTN controller hierarchies can interworking of such protocols and ACTN controller hierarchies can
skipping to change at page 10, line 24 skipping to change at page 10, line 24
This section provides some examples on the usage of IETF YANG models This section provides some examples on the usage of IETF YANG models
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 [TE- is exchanged among controllers with topology models, such as
topology]. Moreover, technology-specific topology reporting may use [RFC8795]. Moreover, technology-specific topology reporting may use
the model described in [OTN-topo] [WSON-topo], 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.
skipping to change at page 11, line 46 skipping to change at page 11, line 46
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 14, line 40 skipping to change at page 14, line 40
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 sources and the destinations. The MDSC will also need to
dynamically interact with the CNC for dynamic policy changes 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. [RFC8795] 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.4.3. SBI (Southbound interface between PNC and devices) 5.4.3. SBI (Southbound interface between PNC and devices)
The Device Model can be used between the PNC and its underlying 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 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 signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to
provision its domain path segment. There can be a plethora of provision its domain path segment. There can be a plethora of
choices how to control/manage its domain network. The PNC is choices how to control/manage its domain network. The PNC is
responsible to abstract its domain network resources and update it responsible to abstract its domain network resources and update it
skipping to change at page 16, line 33 skipping to change at page 16, line 31
[RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data [RFC8299] Q. Wu, S. Litkowski, L. Tomotaki, K.Ogaki, "YANG Data
Model for L3VPN Service Delivery", RFC8299. Model for L3VPN Service Delivery", RFC8299.
[RFC8454] Y. Lee & S. Belotti, "Information Model for Abstraction [RFC8454] Y. Lee & S. Belotti, "Information Model for Abstraction
and Control of TE Networks (ACTN)", RFC8454. and Control of TE Networks (ACTN)", RFC8454.
[RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource
Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp, Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp,
work in progress. work in progress.
[TE-topology] X. Liu, et. al., "YANG Data Model for TE Topologies", [RFC8795] X. Liu, et. al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress. RFC8795.
[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
 End of changes. 21 change blocks. 
41 lines changed or deleted 41 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/