--- 1/draft-ietf-netmod-yang-model-classification-04.txt 2017-03-13 09:13:10.813779992 -0700 +++ 2/draft-ietf-netmod-yang-model-classification-05.txt 2017-03-13 09:13:10.837780557 -0700 @@ -1,30 +1,30 @@ NETMOD D. Bogdanovic Internet-Draft Volta Networks, Inc. Intended status: Informational B. Claise -Expires: April 29, 2017 C. Moberg +Expires: September 14, 2017 C. Moberg Cisco Systems, Inc. - October 26, 2016 + March 13, 2017 YANG Module Classification - draft-ietf-netmod-yang-model-classification-04 + draft-ietf-netmod-yang-model-classification-05 Abstract - The YANG [RFC6020] data modeling language is currently being - considered for a wide variety of applications throughout the - networking industry at large. Many standards-defining organizations - (SDOs), open source software projects, vendors and users are using - YANG to develop and publish YANG modules for a wide variety of - applications. At the same time, there is currently no well-known - terminology to categorize various types of YANG modules. + The YANG data modeling language is currently being considered for a + wide variety of applications throughout the networking industry at + large. Many standards-defining organizations (SDOs), open source + software projects, vendors and users are using YANG to develop and + publish YANG modules for a wide variety of applications. At the same + time, there is currently no well-known terminology to categorize + various types of YANG modules. A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG modules. Status of This Memo @@ -35,25 +35,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on April 29, 2017. + This Internet-Draft will expire on September 14, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -66,35 +66,35 @@ 2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4 2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6 2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7 3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7 3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8 3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8 3.3. User-specific YANG Modules and Extensions . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 + 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Internet Engineering Steering Group (IESG) has been actively - encouraging IETF working groups to use the YANG modeling language - [RFC6020], [RFC7950] and NETCONF protocol [RFC6241] for configuration - management purposes, especially in new working group charters - [Writable-MIB-Module-IESG-Statement]. + encouraging IETF working groups to use the YANG data modeling + language [RFC7950], [RFC7950] and NETCONF protocol [RFC6241] for + configuration management purposes, especially in new working group + charters [Writable-MIB-Module-IESG-Statement]. - YANG is also gaining wide acceptance as the de-facto standard + YANG is also gaining wide acceptance as the de-facto standard data modeling language in the broader industry. This extends beyond the IETF, including many standards development organizations, industry consortia, ad hoc groups, open source projects, vendors, and end- users. There are currently no clear guidelines on how to classify the layering of YANG modules according to abstraction, or how to classify modules along the continuum spanning formal standards publications, vendor-specific modules and modules provided by end-users. @@ -128,40 +128,39 @@ development organizations and industry consortia discussions, whose goals are determined in their respective areas of work. o Second, operators might look at the YANG module classification type to understand which Network Service YANG modules and Network Element YANG modules are available for their service composition. It is difficult to determine the module type without inspecting the YANG module itself. The YANG module name might provide some useful information but is not a definite answer. For example, an L2VPN YANG module might be a Network Service YANG module, ready to - be used by the operators. Alternatively, it might be a Network - Element YANG module that contains the L2VPN data definitions - required to be configured on a single device. + be used as a service model by network operator. Alternatively, it + might be a Network Element YANG module that contains the L2VPN + data definitions required to be configured on a single device. o And thirdly, this taxonomy would help equipment vendors (whether physical or virtual), controller vendors, orchestrator vendors to explain to their customers the relationship between the different - YANG modules they propose in their products. See Figure 1. + YANG modules they support in their products. See Figure 1. 1.1. Terminology [RFC7950] specifies: o data model: A data model describes how data is represented and accessed. - o module: A YANG module defines a hierarchy of nodes that can be - used for NETCONF-based operations. With its definitions and the - definitions it imports or includes from elsewhere, a module is - self-contained and "compilable". + o module: A YANG module defines hierarchies of schema nodes. With + its definitions and the definitions it imports or includes from + elsewhere, a module is self-contained and "compilable". 2. First Dimension: YANG Module Abstraction Layers Module developers have taken two approaches to developing YANG modules: top-down and bottom-up. The top-down approach starts with high level abstractions modeling business or customer requirements and maps them to specific networking technologies. The bottom-up approach starts with fundamental networking technologies and maps them into more abstract constructs. @@ -239,34 +238,38 @@ of all participating network elements and features, but describes an abstract model that allows instances of the service to be decomposed into instance data according to the Network Element YANG Modules of the participating network elements. The service-to-element decomposition is a separate process with details depending on how the network operator chooses to realize the service. For the purpose of this document we will use the term "orchestrator" to describe a system implementing such a process. As an example, the Network Service YANG Module defined in - [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract - model for Layer 3 IP VPN service configuration. This module includes - e.g. the concept of a 'site-network-access' to represent bearer and - connection parameters. An orchestrator receives operations on - service instances according to the service module and decomposes the - data into specific Network Element YANG Modules to configure the - participating network elements to perform the intent of the service. - In the case of the L3VPN module, this would include translating the - 'site-network-access' parameters to the appropriate parameters in the - Network Element YANG Module implemented on the constituent elements. + [draft-ietf-l3sm-l3vpn-service-model] provides an abstract model for + Layer 3 IP VPN service configuration. This module includes e.g. the + concept of a 'site-network-access' to represent bearer and connection + parameters. An orchestrator receives operations on service instances + according to the service module and decomposes the data into specific + Network Element YANG Modules to configure the participating network + elements to the service. In the case of the L3VPN module, this would + include translating the 'site-network-access' parameters to the + appropriate parameters in the Network Element YANG Module implemented + on the constituent elements. Network Service YANG Modules define service models to be consumed by - external systems. These modules are commonly designed, developed and - deployed by network infrastructure teams. + external systems. External systems can be provisioning systems, + service orchestrators, Operations Support Systems, Business Support + Systems and applications exposed to network service consumers, being + either internal network operations peole or extarnal customers. + These modules are commonly designed, developed and deployed by + network infrastructure teams. YANG allows for different design patterns to describe network services, ranging from monolithic to component-based approaches. The monolithic approach captures the entire service in a single module and does not put focus on reusability of internal data definitions and groupings. The monolithic approach has the advantages of single-purpose development including speed at the expense of reusability. @@ -288,25 +291,30 @@ interface definitions. 2.2. Network Element YANG Modules Network Element YANG Modules describe the characteristics of a network device as defined by the vendor of that device. The modules are commonly structured around features of the device, e.g. interface configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and firewall rules definitions [I-D.ietf-netmod-acl-model]. - The module provides a coherent data model representation of the - software environment consisting of the operating system and - applications running on the device. The decomposition, ordering, and - execution of changes to the operating system and application - configuration is the task of the agent that implements the module. + Although the [RFC7950], [RFC7950] doesn't explain the relationship of + the terms '(YANG) data model' and '(YANG) module', the authors + understand there is a 1:1 relationship between a data model and a + YANG module, but a data model may also be expressed using a + collection of YANG modules (and submodules). The module provides a + coherent data model representation of the software environment + consisting of the operating system and applications running on the + device. The decomposition, ordering, and execution of changes to the + operating system and application configuration is the task of the + agent that implements the module. 3. Second Dimension: Module Types This document suggests classifying YANG module types as standard YANG modules, vendor-specific YANG modules and extensions, or user- specific YANG modules and extensions The suggested classification applies to both Network Element YANG Modules and Network Service YANG Modules. @@ -419,60 +427,56 @@ alignment (YANG data model versus YANG module), explain better the distinction between the Network Element and Service YANG data models even if sometimes there are grey areas, editorial pass. Changed the use of the term 'model' to 'module' to be better aligned with RFC6020. 8. References 8.1. Normative References - [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for - the Network Configuration Protocol (NETCONF)", RFC 6020, - DOI 10.17487/RFC6020, October 2010, - . - [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . 8.2. Informative References + [draft-ietf-l3sm-l3vpn-service-model] + "YANG Data Model for L3VPN service delivery", + . + [I-D.ietf-netmod-acl-model] Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, "Network Access Control List (ACL) YANG Data Model", - draft-ietf-netmod-acl-model-09 (work in progress), October - 2016. + draft-ietf-netmod-acl-model-10 (work in progress), March + 2017. [I-D.ietf-ospf-yang] - Yeung, D., Qu, Y., Zhang, Z., Bogdanovic, D., and K. - Koushik, "Yang Data Model for OSPF Protocol", draft-ietf- - ospf-yang-05 (work in progress), July 2016. + Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, + "Yang Data Model for OSPF Protocol", draft-ietf-ospf- + yang-06 (work in progress), October 2016. [Writable-MIB-Module-IESG-Statement] "Writable MIB Module IESG Statement", . - [YANG-Data-Model-for-L3VPN-service-delivery] - "YANG Data Model for L3VPN service delivery", - . - Authors' Addresses Dean Bogdanovic Volta Networks, Inc. Email: dean@voltanet.io Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1