--- 1/draft-ietf-teas-actn-yang-05.txt 2020-08-22 03:13:11.304389483 -0700 +++ 2/draft-ietf-teas-actn-yang-06.txt 2020-08-22 03:13:11.360390909 -0700 @@ -1,31 +1,31 @@ TEAS WG Young Lee Internet Draft Samsung Intended status: Informational Haomian Zheng -Expires: August 19, 2020 Huawei Technologies +Expires: February 22, 2021 Huawei Daniele Ceccarelli Ericsson Bin Yeong Yoon ETRI Oscar Gonzalez de Dios Telefonica Jong Yoon Shin SKT Sergio Belotti Nokia - February 19, 2020 + August 22, 2020 Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks - draft-ietf-teas-actn-yang-05 + draft-ietf-teas-actn-yang-06 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -34,21 +34,21 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -70,37 +70,37 @@ This document explains how the different types of YANG models defined in the Operations and Management Area and in the Routing Area are applicable to the ACTN framework. This document also shows how the ACTN architecture can be satisfied using classes of data model that have already been defined, and discusses the applicability of specific data models that are under development. It also highlights where new data models may need to be developed. Table of Contents - 1. Introduction ................................................ 3 - 1.1. Conventions Used in This Document ...................... 3 + 1. Introduction ................................................. 3 + 1.1. Conventions Used in This Document ....................... 3 2. Abstraction and Control of TE Networks (ACTN) Architecture... 4 - 3. Service Models .............................................. 5 - 4. Service Model Mapping to ACTN ............................... 7 + 3. Service Models ............................................... 5 + 4. Service Model Mapping to ACTN ................................ 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.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.2. Connectivity over Two Nodes ........................... 10 - 5.3. VN example ............................................ 11 - 5.4. Data Center-Interconnection Example ................... 12 - 5.4.1. CMI (CNC-MDSC Interface) ......................... 14 - 5.4.2. MPI (MDSC-PNC Interface) ......................... 14 + 5.1. Topology Collection .................................... 10 + 5.2. Connectivity over Two Nodes ............................ 10 + 5.3. VN example ............................................. 11 + 5.4. Data Center-Interconnection Example .................... 12 + 5.4.1. CMI (CNC-MDSC Interface) .......................... 14 + 5.4.2. MPI (MDSC-PNC Interface) .......................... 14 5.4.3. SBI (Southbound interface between PNC and devices). 14 6. Security ................................................... 15 7. IANA Considerations ........................................ 15 8. Acknowledgements ........................................... 15 9. References ................................................. 15 9.1. Informative References ................................ 15 10. Contributors .............................................. 18 Authors' Addresses ............................................ 18 1. Introduction @@ -303,47 +303,47 @@ The following table provides a list of functions needed to build the CMI. They are mapped with Customer Service Models. Function Yang Model ----------------------------------------------------------- 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]**** + Topology Abstraction [RFC8795]**** Layer 1 Connectivity Service Model [L1CSM] Layer 2 VPN Service Model [RFC8466] Layer 3 VPN Service Model [RFC8299] *VN computation request in the CMI context means network path computation request based on customer service connectivity request constraints prior to the instantiation of a VN creation. **[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]. 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 Section 4.2. ***ietf-actn-te-kpi-telemetry model in [ACTN-PM-Telemetry] describes performance telemetry for ACTN VN model. This module also allows autonomic traffic engineering scaling intent configuration mechanism on the VN level. Scale in/out criteria might be used for network autonomics in order the controller to react to a certain set of variations in monitored parameters. Moreover, this module also provides mechanism to define aggregated telemetry parameters as a grouping of underlying VN level 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]. + ****RFC8795'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 The Service Delivery Models where the service orchestration and the network orchestration could be implemented as separate components as seen in [RFC8309]. On the other hand, from an ACTN architecture point of view, the service delivery model between the service orchestrator and the network orchestrator is an internal interface between sub-components of the MDSC in a single MDSC model. @@ -363,21 +363,21 @@ The following table provides a list of functions needed to build the MPI. They are mapped with Network Configuration Yang Models. Note that various Yang models are work in progress. Function Yang Model -------------------------------------------------------- Configuration Scheduling [Schedule] Path computation [PATH_COMPUTATION-API] Tunnel/LSP Provisioning [TE-tunnel] - Topology Abstraction [TE-topology] + Topology Abstraction [RFC8795] Service Provisioning [Client-signal]&[TE-tunnel]* Client Topology Abstraction [Client-topo] OTN Topology Abstraction [OTN-topo] WSON Topology Abstraction [WSON-topo] Flexi-grid Topology Abstraction [Flexi-topo] Microwave Topology Abstraction [MW-topo] Client Signal Description [Client-signal] OTN Tunnel Model [OTN-Tunnel] WSON TE Tunnel Model [WSON-Tunnel] @@ -386,21 +386,21 @@ * This function is a combination of tunnel set up and client signal description. Usually a tunnel is setting up first to get prepared to carry a client signal, in order to do the service provisioning. Then the client signal is adapted to the established tunnel. It is worth noting that various tunnel models such as [OTN-Tunnel] and [WSON- Tunnel] can be used together with the [TE-tunnel] model to construct technology-specific tunnels, and carry different types of client signals. More details can be found in [Client-signal]. [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 YANG model usage in the current network configuration, especially for transport network. 4.4. Device Models in ACTN Architecture (SBI) 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 ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The interworking of such protocols and ACTN controller hierarchies can @@ -415,22 +415,22 @@ 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. 5.1. Topology Collection 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 + is exchanged among controllers with topology models, such as + [RFC8795]. Moreover, technology-specific topology reporting may use the model described in [OTN-topo] [WSON-topo], and [Flexi-topo] 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, corresponding method can be found in [RFC8453]. The technology-specific features may be hidden after abstraction, to make the network easier for the user to operate. @@ -587,21 +587,21 @@ The Network Configuration Model is used between the MDSC and the PNCs. Based on the Customer Service Model's request, the MDSC will need to translate the service model into the network configuration model to instantiate a set of multi-domain connections between the prescribed sources and the destinations. The MDSC will also need to dynamically interact with the CNC for dynamic policy changes initiated by the CNC. Upon the determination of the multi-domain connections, the MDSC will need to use the network configuration model such as [TE-tunnel] to interact with each PNC involved on the - path. [TE-topology] is used to for the purpose of underlying domain + path. [RFC8795] is used to for the purpose of underlying domain network abstraction from the PNC to the MDSC. 5.4.3. SBI (Southbound interface between PNC and devices) 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 @@ -672,22 +670,22 @@ [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", - draft-ietf-teas-yang-te-topo, work in progress. + [RFC8795] X. Liu, et. al., "YANG Data Model for TE Topologies", + RFC8795. [TE-tunnel] T. Saad (Editor), "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang- te, work in progress. [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN Operation", draft-lee-teas-actn-vn-yang, work in progress. [L1CSM] G. Fioccola, K. Lee, Y. Lee, D. Dhody, O. Gonzalez de-Dios, D. Ceccarelli, "A Yang Data Model for L1 Connectivity