--- 1/draft-ietf-teas-actn-yang-03.txt 2019-08-15 19:13:13.313678562 -0700 +++ 2/draft-ietf-teas-actn-yang-04.txt 2019-08-15 19:13:13.357679671 -0700 @@ -1,35 +1,31 @@ TEAS WG Young Lee - Haomian Zheng -Internet Draft Huawei -Intended status: Informational +Internet Draft Futurewei +Intended status: Informational Haomian Zheng +Expires: February 16, 2020 Huawei Daniele Ceccarelli -Expires: February 23, 2019 Ericsson - + Ericsson Bin Yeong Yoon ETRI - Oscar Gonzalez de Dios Telefonica - Jong Yoon Shin SKT - Sergio Belotti Nokia - February 23, 2019 + August 16, 2019 Applicability of YANG models for Abstraction and Control of Traffic Engineered Networks - draft-ietf-teas-actn-yang-03 + draft-ietf-teas-actn-yang-04 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,24 +30,25 @@ other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six 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 23, 2019. + This Internet-Draft will expire on February 16, 2020. Copyright Notice Copyright (c) 2019 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 @@ -74,93 +71,103 @@ 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 - 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 - 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.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 - 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.2. Connectivity over Two Nodes ........................... 10 - 5.3. VN service 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 + 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. Acknowledgements ........................................... 15 - 8. References ................................................. 15 - 8.1. Informative References................................. 15 - 9. Contributors ............................................... 17 + 7. IANA Considerations ........................................ 15 + 8. Acknowledgements ........................................... 15 + 9. References ................................................. 15 + 9.1. Informative References ................................ 15 + 10. Contributors .............................................. 18 Authors' Addresses ............................................ 18 1. Introduction Abstraction and Control of TE Networks (ACTN) describes a method for operating a Traffic Engineered (TE) network (such as an MPLS-TE network or a layer 1 transport network) to provide connectivity and - virtual network services for customers of the TE network. The - services provided can be tuned to meet the requirements (such as - traffic patterns, quality, and reliability) of the applications - hosted by the customers. More details about ACTN can be found in - Section 2. + virtual network for customers of the TE network. The services + provided can be tuned to meet the requirements (such as traffic + patterns, quality, and reliability) of the applications hosted by + the customers. More details about ACTN can be found in Section 2. Data models are a representation of objects that can be configured or monitored within a system. Within the IETF, YANG [RFC6241] is the language of choice for documenting data models, and YANG models have been produced to allow configuration or modelling of a variety of network devices, protocol instances, and network services. YANG data models have been classified in [RFC8199] and [RFC8309]. This document shows how the ACTN architecture can be satisfied using various 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. +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 [RFC8453] describes the architecture model for ACTN including the entities (Customer Network Controller (CNC), Multi-domain Service Coordinator (MDSC), and Provisioning Network Controller (PNC)) and their interfaces. Figure 1 depicts a high-level control and interface architecture for ACTN and is a reproduction of Figure 3 from [RFC8453]. A number of key ACTN interfaces exist for deployment and operation of ACTN-based networks. These are highlighted in Figure 1 (ACTN Interfaces) below: +--------------+ +---------------+ +--------------+ | CNC-A | | CNC-B | | CNC-C | |(DC provider) | | (ISP) | | (MVNO) | +--------------+ +---------------+ +--------------+ \ | / Business \ | / - Boundary =======\========================|=========================/======= + Boundary =====\======================|=======================/====== Between \ | CMI / Customer & ----------- | -------------- Network Provider \ | / - +-----------------------+ + +---------------------+ | MDSC | - +-----------------------+ + +---------------------+ / | \ - ------------ |MPI ---------------- + ---------- |MPI -------------- / | \ +-------+ +-------+ +-------+ | PNC | | PNC | | PNC | +-------+ +-------+ +-------+ | GMPLS / | / \ | trigger / |SBI SBI / \ -------- ----- | / \ ( ) ( ) | / \ - - ( Phys. ) | / ----- ( GMPLS ) ( Net ) | / ( ) @@ -175,23 +182,23 @@ The interfaces and functions are described below (without modifying the definitions) in [RFC8453]: The CNC-MDSC Interface (CMI) is an interface between a CNC and an MDSC. This interface is used to communicate the service request or application demand. A request will include specific service properties, for example, services type, bandwidth and constraint information. These constraints SHOULD be measurable by MDSC and therefore visible to CNC via CMI. The CNC can also - request the creation of the virtual network service based on - underlying physical resources to provide network services for - the applications. The CNC can provide the end-point + request the creation of the virtual network based on underlying + physical resources to provide network services for the + applications. The CNC can provide the end-point information/characteristics together with traffic matrix specifying specific customer constraints. The MDSC may also report potential network topology availability if queried for current capability from the Customer Network Controller. Performance monitoring is also applicable in CMI, which enables the MDSC to report network parameters/telemetries that may guide the CNC to create/change their services. The MDSC-PNC Interface (MPI) is an interface between a MDSC and a PNC. It allows the MDSC to communicate requests to @@ -360,27 +364,28 @@ 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] - Client Signal Description [Client-signal] 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] Flexi-grid Tunnel Model [Flexigrid-Tunnel] * 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 @@ -465,21 +470,21 @@ that can cater this purpose is the TE tunnel model specified in [TE-tunnel]. Technology-specific tunnel configuration may use the model described in [OTN-Tunnel] [WSON-Tunnel], and [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively. Then, the PNCs need to decide the explicit route of such a tunnel or tunnel segment (in case of multiple domains) for each domain, and then create such a tunnel using protocols such as PCEP and RSVP-TE or using per-hop configuration. -5.3. VN service example +5.3. VN example The service model defined in [ACTN-VN-YANG] describes a virtual network (VN) as a service which is a set of multiple connectivity services: A CNC will request VN to the MDSC by specifying a list of VN members. Each VN member specifies either a single connectivity service, or a source with multiple potential destination points in the case that the precise destination sites are to be determined by MDSC. @@ -614,135 +619,149 @@ - the use of Restconf security between components - the use of authentication and policy to govern which services can be requested by different parties. - how security may be requested as an element of a service and mapped down to protocol security mechanisms as well as separation (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 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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", RFC 8309. [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module Classification", RFC 8199. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241. [RFC8040] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF Protocol", RFC 8040. [RFC8453] D. Ceccarelli and Y. Lee, "Framework for Abstraction and 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", draft-ietf-teas-yang-te-topo, work in progress. [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 Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work 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 Scheduling", draft-liu-netmod-yang-schedule, work in progress. [OTN-topo] H. Zheng, et. al., "A YANG Data Model for Optical Transport Network Topology", draft-ietf-ccamp-otn-topo- yang, work in progress. [WSON-topo] Y. Lee, et. al., "A Yang Data Model for WSON Optical Networks", draft-ietf-ccamp-wson-yang, work in progress. [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. [MW-topo] M. Ye, et. al., "A YANG Data Model for Microwave Topology", draft-ietf-ccamp-mw-topo-yang, work in progress. [OTN-Tunnel] H. Zheng, et. al., "OTN Tunnel YANG Model", draft- ietf-ccamp-otn-tunnel-model, work in progress. [ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D. King, and D. Ceccarelli, "YANG models for ACTN TE 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. [WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R. Vilalta, "A Yang Data Model for WSON Tunnel", draft-ietf- ccamp-wson-tunnel-model, work in progress. [Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model for Flexi-Grid media-channels", draft-ietf-ccamp- flexigrid-media-channel-yang, work in progress. - [TE-Service-Mapping] Y. Lee, et al, "Traffic Engineering and Service - Mapping Yang Model", draft-lee-teas-te-service-mapping- - yang, work in progress. - [Client-signal] H. Zheng, et al, "A YANG Data Model for Optical - Transport Network Client Signals", draft-zheng-ccamp- + Transport Network Client Signals", draft-ietf-ccamp- 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 Modeling for Transport Networks", draft-ietf-teas-te-topo- and-tunnel-modeling, work in progress. [T-NBI Applicability] I. Busi, et al, "Transport Northbound Interface Applicability Statement and Use Cases", draft- ietf-ccamp-transport-nbi-app-statement, work in progress. [gmpls-controller-inter-work] H. Zheng, et al, "Interworking of GMPLS Control and Centralized Controller System", draft- - zheng-teas-gmpls-controller-inter-work, work in progress. + ietf-teas-gmpls-controller-inter-work, work in progress. -9. Contributors +10. Contributors Contributor's Addresses + Dhruv Dhody Huawei Technologies Email: dhruv.ietf@gmail.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com @@ -742,48 +761,39 @@ Email: dhruv.ietf@gmail.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Authors' Addresses Young Lee - Huawei Technologies - 5340 Legacy Drive - Plano, TX 75023, USA - Phone: (469)277-5838 - - Email: leeyoung@huawei.com + Futurewei Technologies + 5700 Tennyson Parkway, Suite 600 + Plano, TX 75024, USA + Email: younglee.tx@gmail.com Haomian Zheng Huawei Technologies - Email: zhenghaomian@huawei.com - Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden - Email: daniele.ceccarelli@ericsson.com Bin Yeong Yoon ETRI - Email: byyun@etri.re.kr Oscar Gonzalez de Dios Telefonica - Email: oscar.gonzalezdedios@telefonica.com Jong Yoon Shin SKT - Email: jongyoon.shin@sk.com Sergio Belotti Nokia - Email: sergio.belotti@nokia.com