YANG Module Classification
draft-ietf-netmod-yang-model-classification-03

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.

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

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 3, 2017.

Copyright Notice

Copyright (c) 2016 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 described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 2. First Dimension: YANG Module Abstraction Layers
• 2.1. Network Service YANG Modules
• 2.2. Network Element YANG Modules
• 3. Second Dimension: Module Types
• 3.1. Standard YANG Modules
• 3.2. Vendor-specific YANG Modules and Extensions
• 3.3. User-specific YANG Modules and Extensions
• 4. Adding The Classification Type to YANG Module Catalogs
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. Change log [RFC Editor: Please remove]
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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].

YANG is also gaining wide acceptance as the de-facto standard 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.

This document presents a set of concepts and terms to form a useful taxonomy for consistent classification of YANG modules in two dimensions:

• The layering of modules based on their abstraction levels
• The type of module based on the nature and intent of the content

The intent of this document is to provide a taxonomy to simplify human communication around YANG modules. The authors acknowledge that the classification boundaries are at times blurry, but believe that this document should provide a robust starting point as the YANG community gains further experience with designing and deploying modules. To be more explicit, the authors believe that the classification criteria will change over time.

A number of module types have created substantial discussion during the development of this document including those concerned with topologies. Topology modules are useful both on the Network Element level (e.g. link-state database content) as well as on the Network Service level (e.g. network-wide, configured topologies). In the end, it is the module developer that classifies the module according to the initial intent of the module content.

This document should provide benefits to multiple audiences:

• First, a common taxonomy helps with the different standards development organizations and industry consortia discussions, whose goals are determined in their respective areas of work.
• 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.
• 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.

1.1. Terminology

[RFC7950] specifies:

• data model: A data model describes how data is represented and accessed.
• 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".

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.

There are currently no specific requirements on, or well-defined best practices around the development of YANG modules. For the purpose of this document we assume that both approaches (bottom-up and top-down) will be used as they both provide benefits that appeal to different groups.

For layering purposes, this document suggests the classification of YANG modules into two distinct abstraction layers:

• Network Element YANG Modules describe the configuration, state data, operations and notifications of specific device-centric technologies or features
• Network Service YANG Modules describe the configuration, state data, operations and notifications of abstract representations of services implemented on one or multiple network elements

                    +--------------------------+
                    |  Operations and Business |
                    |      Support Systems     |
                    |        (OSS/BSS)         |
                    +--------------------------+

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Network Service YANG Modules 

         +------------+      +-------------+      +-------------+
         |            |      |             |      |             |
         |  - L2VPN   |      |   - L2VPN   |      |    L3VPN    |
         |  - VPWS    |      |   - VPLS    |      |             |
         |            |      |             |      |             |
         +------------+      +-------------+      +-------------+
    
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Network Element YANG Modules

    +------------+  +------------+  +-------------+  +------------+
    |            |  |            |  |             |  |            |
    |    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
    |            |  |            |  |             |  |            |
    +------------+  +------------+  +-------------+  +------------+

      L2VPN: Layer 2 Virtual Private Network
      L3VPN: Layer 3 Virtual Private Network
      VPWS: Virtual Private Wire Service
      VPLS: Virtual Private LAN Service
      

+--------------+
|     User     |
|   Extensions |
+------+-------+
    Augments
+------+-------+  +--------------+  +--------------+
|   Vendor     |  |     User     |  |     User     |
|  Extensions  |  |  Extensions  |  |  Extensions  |
+------+-------+  +------+-------+  +------+-------+
    Augments          Augments          Augments
+------+-----------------+-------+  +------+-------+  +--------------+
|            Standard            |  |    Vendor    |  |    User      |
|            Modules             |  |    Modules   |  |   Modules    |
+--------------------------------+  +--------------+  +--------------+
      

         leaf module-class{
           type enum {
                service
                device
                notApplicable
           }
           description
              "Categorization of the YANG module based on 
               draft-ietf-netmod-yang-model-classification.";
         }