draft-ietf-netmod-yang-model-classification-07.txt   draft-ietf-netmod-yang-model-classification-08.txt 
NETMOD D. Bogdanovic NETMOD D. Bogdanovic
Internet-Draft Volta Networks, Inc. Internet-Draft Volta Networks, Inc.
Intended status: Informational B. Claise Intended status: Informational B. Claise
Expires: November 17, 2017 C. Moberg Expires: December 15, 2017 C. Moberg
Cisco Systems, Inc. Cisco Systems, Inc.
May 16, 2017 June 13, 2017
YANG Module Classification YANG Module Classification
draft-ietf-netmod-yang-model-classification-07 draft-ietf-netmod-yang-model-classification-08
Abstract Abstract
The YANG data modeling language is currently being considered for a The YANG data modeling language is currently being considered for a
wide variety of applications throughout the networking industry at wide variety of applications throughout the networking industry at
large. Many standards development organizations (SDOs), open source large. Many standards development organizations (SDOs), open source
software projects, vendors and users are using YANG to develop and software projects, vendors and users are using YANG to develop and
publish YANG modules for a wide variety of applications. At the same publish YANG modules for a wide variety of applications. At the same
time, there is currently no well-known terminology to categorize time, there is currently no well-known terminology to categorize
various types of YANG modules. various types of YANG modules.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 17, 2017. This Internet-Draft will expire on December 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4 2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4
2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6 2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6
2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7 2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7
3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7 3. Second Dimension: Module Origin Types . . . . . . . . . . . . 7
3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8 3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8
3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8 3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8
3.3. User-specific YANG Modules and Extensions . . . . . . . . 9 3.3. User-specific YANG Modules and Extensions . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 16 skipping to change at page 3, line 16
layering of YANG modules according to abstraction, or how to classify layering of YANG modules according to abstraction, or how to classify
modules along the continuum spanning formal standards publications, modules along the continuum spanning formal standards publications,
vendor-specific modules and modules provided by end-users. vendor-specific modules and modules provided by end-users.
This document presents a set of concepts and terms to form a useful This document presents a set of concepts and terms to form a useful
taxonomy for consistent classification of YANG modules in two taxonomy for consistent classification of YANG modules in two
dimensions: dimensions:
o The layering of modules based on their abstraction levels o The layering of modules based on their abstraction levels
o The type of module based on the nature and intent of the content o The module origin type based on the nature and intent of the
content
The intent of this document is to provide a taxonomy to simplify The intent of this document is to provide a taxonomy to simplify
human communication around YANG modules. While the classification human communication around YANG modules. While the classification
boundaries are at times blurry, this document should provide a robust boundaries are at times blurry, this document should provide a robust
starting point as the YANG community gains further experience with starting point as the YANG community gains further experience with
designing and deploying modules. To be more explicit, it is expected designing and deploying modules. To be more explicit, it is expected
that the classification criteria will change over time. that the classification criteria will change over time.
A number of module types have created substantial discussion during A number of modules have created substantial discussion during the
the development of this document including those concerned with development of this document: for examples, modules concerned with
topologies. Topology modules are useful both on the Network Element topologies. Topology modules are useful both on the Network Element
level (e.g. link-state database content) as well as on the Network level (e.g. link-state database content) as well as on the Network
Service level (e.g. network-wide, configured topologies). In the Service level (e.g. network-wide, configured topologies). In the
end, it is the module developer that classifies the module according end, it is the module developer that classifies the module according
to the initial intent of the module content. to the initial intent of the module content.
This document should provide benefits to multiple audiences: This document should provide benefits to multiple audiences:
o First, a common taxonomy helps with the different standards o First, a common taxonomy helps with the different standards
development organizations and industry consortia discussions, development organizations and industry consortia discussions,
whose goals are determined in their respective areas of work. whose goals are determined in their respective areas of work.
o Second, operators might look at the YANG module classification o Second, operators might look at the YANG module abstraction layers
type to understand which Network Service YANG modules and Network to understand which Network Service YANG modules and Network
Element YANG modules are available for their service composition. Element YANG modules are available for their service composition.
It is difficult to determine the module type without inspecting It is difficult to determine the module type without inspecting
the YANG module itself. The YANG module name might provide some the YANG module itself. The YANG module name might provide some
useful information but is not a definite answer. For example, an useful information but is not a definite answer. For example, an
L2VPN YANG module might be a Network Service YANG module, ready to L2VPN YANG module might be a Network Service YANG module, ready to
be used as a service model by a network operator. Alternatively, be used as a service model by a network operator. Alternatively,
it might be a Network Element YANG module that contains the L2VPN it might be a Network Element YANG module that contains the L2VPN
data definitions required to be configured on a single device. data definitions required to be configured on a single device.
o And thirdly, this taxonomy would help equipment vendors (whether o And thirdly, this taxonomy would help equipment vendors (whether
physical or virtual), controller vendors, orchestrator vendors to physical or virtual), controller vendors, orchestrator vendors to
explain to their customers the relationship between the different explain to their customers the relationship between the different
YANG modules they support in their products. See Figure 1. YANG modules they support in their products.
1.1. Terminology 1.1. Terminology
[RFC7950] specifies: [RFC7950] specifies:
o data model: A data model describes how data is represented and o data model: A data model describes how data is represented and
accessed. accessed.
o module: A YANG module defines hierarchies of schema nodes. With o module: A YANG module defines hierarchies of schema nodes. With
its definitions and the definitions it imports or includes from its definitions and the definitions it imports or includes from
skipping to change at page 5, line 34 skipping to change at page 5, line 34
| | | | | | | | | | | | | | | |
| MPLS | | BGP | | IPv4 / IPv6 | | Ethernet | | MPLS | | BGP | | IPv4 / IPv6 | | Ethernet |
| | | | | | | | | | | | | | | |
+------------+ +------------+ +-------------+ +------------+ +------------+ +------------+ +-------------+ +------------+
L2VPN: Layer 2 Virtual Private Network L2VPN: Layer 2 Virtual Private Network
L3VPN: Layer 3 Virtual Private Network L3VPN: Layer 3 Virtual Private Network
VPWS: Virtual Private Wire Service VPWS: Virtual Private Wire Service
VPLS: Virtual Private LAN Service VPLS: Virtual Private LAN Service
Figure 1: YANG Module Layers Figure 1: YANG Module Abstraction Layers
Figure 1 illustrates the application of YANG modules at different Figure 1 illustrates the application of YANG modules at different
layers of abstraction. Layering of modules allows for reusability of layers of abstraction. Layering of modules allows for reusability of
existing lower layer modules by higher level modules while limiting existing lower layer modules by higher level modules while limiting
duplication of features across layers. duplication of features across layers.
For module developers, per-layer modeling allows for separation of For module developers, per-layer modeling allows for separation of
concern across editing teams focusing on specific areas. concern across editing teams focusing on specific areas.
As an example, experience from the IETF shows that creating useful As an example, experience from the IETF shows that creating useful
network element YANG modules for e.g. routing or switching protocols Network Element YANG modules for e.g. routing or switching protocols
requires teams that include developers with experience of requires teams that include developers with experience of
implementing those protocols. implementing those protocols.
On the other hand, network service YANG modules are best developed by On the other hand, Network Service YANG modules are best developed by
network operators experienced in defining network services for network operators experienced in defining network services for
consumption by programmers developing e.g. flow-through provisioning consumption by programmers developing e.g. flow-through provisioning
systems or self-service portals. systems or self-service portals.
2.1. Network Service YANG Modules 2.1. Network Service YANG Modules
Network Service YANG Modules describe the characteristics of a Network Service YANG Modules describe the characteristics of a
service, as agreed upon with consumers of that service. That is, a service, as agreed upon with consumers of that service. That is, a
service module does not expose the detailed configuration parameters service module does not expose the detailed configuration parameters
of all participating network elements and features, but describes an of all participating network elements and features, but describes an
skipping to change at page 6, line 39 skipping to change at page 6, line 39
YANG allows for different design patterns to describe network YANG allows for different design patterns to describe network
services, ranging from monolithic to component-based approaches. services, ranging from monolithic to component-based approaches.
The monolithic approach captures the entire service in a single The monolithic approach captures the entire service in a single
module and does not put focus on reusability of internal data module and does not put focus on reusability of internal data
definitions and groupings. The monolithic approach has the definitions and groupings. The monolithic approach has the
advantages of single-purpose development including development speed advantages of single-purpose development including development speed
at the expense of reusability. at the expense of reusability.
The component-based approach captures device-centric features (e.g. The component-based approach captures device-centric features (e.g.
the definition of a VRF, routing protocols, or packet filtering) in a the definition of a VPN Routing and Forwarding (VRF), routing
vendor-independent manner. The components are designed for reuse protocols, or packet filtering) in a vendor-independent manner. The
across many service modules. The set of components required for a components are designed for reuse across many service modules. The
specific service is then composed into the higher-level service. The set of components required for a specific service is then composed
component-based approach has the advantages of modular development into the higher-level service. The component-based approach has the
including a higher degree of reusability at the expense of initial advantages of modular development including a higher degree of
development speed. reusability at the expense of initial development speed.
As an example, an L2VPN service can be built on many different types As an example, an L2VPN service can be built on many different types
of transport network technologies, including e.g. MPLS or carrier of transport network technologies, including e.g. MPLS or carrier
ethernet. A component-based approach would allow for reuse of e.g. ethernet. A component-based approach would allow for reuse of e.g.
UNI-interface definitions independent of the underlying transport User-Network Interface (UNI) definitions independent of the
network (e.g. MEF UNI interface or MPLS interface). The monolithic underlying transport network (e.g. MEF UNI interface or MPLS
approach would assume a specific set of transport technologies and interface). The monolithic approach would assume a specific set of
interface definitions. transport technologies and interface definitions.
An example of a network service module is in [RFC8049]. It provides An example of a Network Service YANG module is in [RFC8049]. It
an abstract model for Layer 3 IP VPN service configuration. This provides an abstract model for Layer 3 IP VPN service configuration.
module includes e.g. the concept of a 'site-network-access' to This module includes e.g. the concept of a 'site-network-access' to
represent bearer and connection parameters. An orchestrator receives represent bearer and connection parameters. An orchestrator receives
operations on service instances according to the service module and operations on service instances according to the service module and
decomposes the data into configuration data according to specific decomposes the data into configuration data according to specific
Network Element YANG Modules to configure the participating network Network Element YANG Modules to configure the participating network
elements to the service. In the case of the L3VPN module, this would elements to the service. In the case of the L3VPN module, this would
include translating the 'site-network-access' parameters to the include translating the 'site-network-access' parameters to the
appropriate parameters in the Network Element YANG Module implemented appropriate parameters in the Network Element YANG Module implemented
on the constituent elements. on the constituent elements.
2.2. Network Element YANG Modules 2.2. Network Element YANG Modules
skipping to change at page 7, line 33 skipping to change at page 7, line 33
are commonly structured around features of the device, e.g. interface are commonly structured around features of the device, e.g. interface
configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and configuration [RFC7223], OSPF configuration [I-D.ietf-ospf-yang], and
firewall rules definitions [I-D.ietf-netmod-acl-model]. firewall rules definitions [I-D.ietf-netmod-acl-model].
The module provides a coherent data model representation of the The module provides a coherent data model representation of the
software environment consisting of the operating system and software environment consisting of the operating system and
applications running on the device. The decomposition, ordering, and applications running on the device. The decomposition, ordering, and
execution of changes to the operating system and application execution of changes to the operating system and application
configuration is the task of the agent that implements the module. configuration is the task of the agent that implements the module.
3. Second Dimension: Module Types 3. Second Dimension: Module Origin Types
This document suggests classifying YANG module types as standard YANG This document suggests classifying YANG module origin types as
modules, vendor-specific YANG modules and extensions, or user- standard YANG modules, vendor-specific YANG modules and extensions,
specific YANG modules and extensions or user-specific YANG modules and extensions
The suggested classification applies to both Network Element YANG The suggested classification applies to both Network Element YANG
Modules and Network Service YANG Modules. Modules and Network Service YANG Modules.
It is to be expected that real-world implementations of both Network It is to be expected that real-world implementations of both Network
Service YANG Modules and Network Element YANG Modules will include a Service YANG Modules and Network Element YANG Modules will include a
mix of all three types of modules. mix of all three module origin types.
Figure 2 illustrates the relationship between the three types of Figure 2 illustrates the relationship between the three types of
modules. modules.
+--------------+ +--------------+
| User | | User |
| Extensions | | Extensions |
+------+-------+ +------+-------+
Augments Augments
+------+-------+ +--------------+ +--------------+ +------+-------+ +--------------+ +--------------+
| Vendor | | User | | User | | Vendor | | User | | User |
| Extensions | | Extensions | | Extensions | | Extensions | | Extensions | | Extensions |
+------+-------+ +------+-------+ +------+-------+ +------+-------+ +------+-------+ +------+-------+
Augments Augments Augments Augments Augments Augments
+------+-----------------+-------+ +------+-------+ +--------------+ +------+-----------------+-------+ +------+-------+ +--------------+
| Standard | | Vendor | | User | | Standard | | Vendor | | User |
| Modules | | Modules | | Modules | | Modules | | Modules | | Modules |
+--------------------------------+ +--------------+ +--------------+ +--------------------------------+ +--------------+ +--------------+
Figure 2: YANG Module Types Figure 2: YANG Module Origin Types
3.1. Standard YANG Modules 3.1. Standard YANG Modules
Standard YANG Modules are published by standards development Standard YANG Modules are published by standards development
organizations (SDOs). Most SDOs create specifications according to a organizations (SDOs). Most SDOs create specifications according to a
formal process in order to produce a standard that is useful for formal process in order to produce a standard that is useful for
their constituencies. their constituencies.
The lifecycle of these modules is driven by the editing cycle of the The lifecycle of these modules is driven by the editing cycle of the
specification and not tied to a specific implementation. specification and not tied to a specific implementation.
Examples of SDOs in the networking industry are the IETF, the IEEE Examples of SDOs in the networking industry are the IETF and the
and the MEF. IEEE.
3.2. Vendor-specific YANG Modules and Extensions 3.2. Vendor-specific YANG Modules and Extensions
Vendor-specific YANG Modules are developed by organizations with the Vendor-specific YANG Modules are developed by organizations with the
intent to support a specific set of implementations under control of intent to support a specific set of implementations under control of
that organization. For example vendors of virtual or physical that organization. For example vendors of virtual or physical
equipment, industry consortia, and opensource projects. The intent equipment, industry consortia, and opensource projects. The intent
of these modules range from providing openly published YANG modules of these modules range from providing openly published YANG modules
that may eventually be contributed back to, or adopted by, an SDO, to that may eventually be contributed back to, or adopted by, an SDO, to
strictly internal YANG modules not intended for external consumption. strictly internal YANG modules not intended for external consumption.
 End of changes. 20 change blocks. 
36 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/