One document matched: draft-ietf-netmod-yang-model-classification-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
(which supports the latest, sometimes undocumented and under-tested, features.) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?> <!-- You want a table of contents -->
<?rfc symrefs="yes"?> <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?> <!-- This sorts the references -->
<?rfc iprnotified="no" ?> <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-ietf-netmod-yang-model-classification-00" category="info" >
<front>
<title abbrev="YANG Model Classification">YANG Model Classification</title>
<author fullname="Dean Bogdanovic" initials="D." surname="Bogdanovic">
<address>
<email>ivandean@gmail.com</email>
</address>
</author>
<author fullname="Benoit Claise" initials="B." surname="Claise">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>bclaise@cisco.com</email>
</address>
</author>
<author fullname="Carl Moberg" initials="C." surname="Moberg">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>camoberg@cisco.com</email>
</address>
</author>
<!-- Let xml2rfc figure out the date -->
<date/>
<area>Operations and Management</area>
<workgroup>NETMOD</workgroup>
<abstract>
<t>The YANG <xref target="RFC6020"/> data modeling language is currently
being considered for a wide variety of applications throughout the
networking industry at large. Many standards defining organizations,
open source software projects, and vendors are using YANG to
develop and publish models of configuration, state data and operations
for a wide variety of applications. At the same time, there is currently
no well-known terminology to categorize various types of YANG models.</t>
<t>A consistent terminology would help with the categorization of models,
assist in the analysis the YANG data modeling efforts in the IETF and
other organizations, and bring clarity to the YANG-related discussions
between the different groups.</t>
<t>This document describes a set of concepts and associated terms to
support consistent classification of YANG models.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The Internet Engineering Steering Group (IESG) has been actively
encouraging IETF working groups to use the NETCONF
<xref target="RFC6241"/> and YANG standards for configuration
management purposes, especially in new working group charters
<xref target="Writable-MIB-Module-IESG-Statement"/>.</t>
<t>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 and vendors.</t>
<t>There are currently no clear guidelines on how to classify the layering
of YANG models according to abstraction, or how to classify models along
the continuum spanning formal standards publications and vendor-specific
models.</t>
<t>This document presents a set of concepts and terms to form a useful
taxonomy for consistent classification of YANG models in two dimensions:
<list style="symbols">
<t>The layering of models based on their abstraction levels</t>
<t>The type of model based on the nature and intent of the content</t>
</list>
The two categories are covered in the next two sections.
</t>
</section> <!-- intro -->
<section anchor="firstdimension" title="First Dimension: YANG Model Abstraction Layers">
<t>Model developers have taken two approaches to developing YANG model:
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.</t>
<t>There are currently no specific requirements on, or well-defined best
practices around the development of models. 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 appeals to different groups.
</t>
<t>For layering purposes, this documents suggests the classification of
data models into two distinct abstraction layers:</t>
<t>
<list style="symbols">
<t>Network Element YANG Models describe the configuration, state
data and operations of a specific device-centric technology or
feature.</t>
<t>Network Service YANG Models describes the configuration, state
data and operations of an abstract representation of a service
implemented on one or multiple network elements</t>
</list>
</t>
<t>Figure 1 illustrates the application of YANG models at different
layers of abstraction. Layering of models allow for reusability of
existing lower layer models by higher level models while limiting
duplication of features across layers.</t>
<t>For model developers, per-layer modeling allows for separation of
concern across editing teams focusing on specific areas.</t>
<t>As an example, experience from the IETF shows that creating useful
network element YANG models for e.g routing or switching protocols
requires teams that include developers with experience from
implementing those protocols.</t>
<t>On the other hand, network service models are best developed by people
experienced in defining network services for consumption by programmers
developing e.g. flow-through provisioning systems or self-service
portals.</t>
<figure align="center">
<artwork align="center"><![CDATA[
+--------------------------+
| Operations and Business |
| Support Systems |
| (OSS/BSS) |
+--------------------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Service YANG data models
+------------+ +-------------+ +-------------+
| | | | | |
| - VPWS | | - VPLS | | L3VPN |
| - L2VPN | | - L2VPN | | |
| | | | | |
+------------+ +-------------+ +-------------+
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Network Element YANG data models
+------------+ +------------+ +-------------+ +------------+
| | | | | | | |
| MPLS | | BGP | | IPv4 & IPv6 | | Ethernet |
| | | | | | | |
+------------+ +------------+ +-------------+ +------------+
Fig. 1 YANG Model Layers
]]></artwork>
</figure> <!-- YANG model layers -->
<section anchor="networkservice" title="Network Service YANG Data Models">
<t>Network Service YANG Data Models describe the characteristics of a
service, as agreed upon with consumers of that service. That is, a
service model does not expose the detailed configuration parameters 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 data models 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.</t>
<t>As an example, the Network Service model included in
<xref target='YANG-Data-Model-for-L3VPN-service-delivery'/> provides
an abstracted model for Layer 3 IP VPN service configuration. An
orchestrator receives operations on service instances according to the
service model and decomposes the data into specific Network Element
models to configure the participating network elements to perform the
intent of the service.</t>
<t>Network Service YANG models defines services models to be consumed
by external systems. These models are commonly designed, developed and
deployed by network infrastructure teams.</t>
<t>YANG allows for different design patterns to describe network services,
ranging from monolithic to component-based approaches.</t>
<t>The monolithic approach captures the entire service in a single model
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.</t>
<t>The component-based approach captures device-centric features (e.g.
the definition of a VRF, routing protocols, or packet filtering) in a
vendor-independent manner. The components are designed for reuse across
many services. The set of components required for a specific service is
then composed into the higher-level service. The component-based
approach has the advantages of modular development including a higher
degree of reusability at the expense of initial speed.</t>
<t>As an example, an L2VPN service can be built on many different types of
transport network technologies, including e.g. MPLS or carrier ethernet.
A component-based approach would allow for reuse of e.g. UNI-interface
definitions independent of the underlying transport network (e.g. MEF
UNI interface or MPLS interface). The monolithic approach would assume
a specific set of transport technologies and interface definitions.</t>
</section> <!-- networkservice -->
<section anchor="networkElement" title="Network Element YANG Data models">
<t>Network Element YANG Data Models describe the configuration, state
data and operations of a network device as defined by the vendor of
that device. The models are commonly structured around features of the
device, e.g. interface configuration <xref target='RFC7223'/>, OSPF
configuration <xref target='I-D.ietf-ospf-yang'/>, and firewall rules
definitions <xref target='I-D.ietf-netmod-acl-model'/>. The model
provides a coherent data model representation of what is commonly a very
mixed software environment consisting of the operating system and
applications running on the device.</t>
<t>The decomposition, ordering, and execution of changes to the operating
system and application configuration is the task of the management
framework that implements the YANG model.</t>
</section> <!-- protocol/feature YANG data models -->
</section> <!-- firstdimension -->
<section title="Second Dimension: Model Types">
<t>This document suggests classifying YANG model types as either standard
YANG models, vendor-specific YANG models, or vendor-specific
extensions.</t>
<t>The suggested classification applies to both Network Element YANG Data
Models and to Network Service YANG Data Models.</t>
<t>It is to be expected that real-world implementations of both Network
Service and Network Element models will include a mix of all three types
of models.</t>
<section title="Standard YANG Models">
<t>Standard YANG models are published by standards defining organizations
(SDOs). While there is no formal definition of what construes an SDO,
a common feature is that they publish specifications along specific
processes with content that reflects some sort of membership
consensus. The specifications are developed for wide use among the
membership or for audiences beyond that.</t>
<t>The lifecycle of these models are driven by the editing cycle of the
specification and not tied to a specific implementation.</t>
<t>Examples of SDOs in the networking industry are the IETF, the IEEE and
the MEF.</t>
</section>
<section title="Vendor-specific YANG Models">
<t>Vendor-specific YANG models are developed by organizations with the
intent to support a specific set of implementations under control of
that organization. The intent of these models range from providing
openly published YANG models that may eventually be contributed back
to, or adopted by an SDO, to strictly internal YANG models not intended
for external consumption.</t>
<t>The lifecycle of these models are generally aligned with the release
cycle of the product or open source software project deliverables.</t>
<t>It is worth noting that there is an increasing amount of interaction
between open source projects and SDOs in the networking industry. This
includes open source projects implementing published standards as well
as open source projects contributing content to SDO processes.</t>
</section>
<section title="Vendor-specific Extensions">
<t>Vendors develop Vendor-specific Extensions to standard models using
YANG constructs for extending data definitions of previously published
models. This is done using the ‘augment’ statement that allows locally
defined data trees to be augmented into locations in externally defined
data trees.</t>
<t>Vendors use this to extend standard data models to cover the
full scope of features in implementations, which commonly is broader
than what is covered by the standard model.</t>
</section>
</section> <!-- Second Dimension -->
<section anchor="security" title="Security Considerations">
<t>At this stage, authors of the draft didn't look into security considerations.</t>
</section> <!-- security -->
<section anchor="iana" title="IANA Considerations">
<t>This document requests no action by IANA.</t>
</section> <!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>Thanks to David Ball for his enlightenments on Metro Ethernet Forum service aspects.</t>
</section> <!-- ack -->
<section anchor ="changes" title="Change log [RFC Editor: Please remove]">
<t>version 1: restructure the document, add the two dimensions, add the interaction with the different
SDOs and opensource projects, add the definitions.</t>
<t>version 2: added definitions for config and service models
clarified second dimension of model classification.
fixed typos</t>
<t>version 3: restructure and partial rewrite of section 2.</t>
<t>version 4: Language fixes</t>
</section> <!-- changes -->
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6020'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6241'?>
<?rfc include='reference.RFC.7223'?>
<?rfc include='reference.I-D.ietf-netmod-acl-model'?>
<?rfc include='reference.I-D.ietf-ospf-yang'?>
<reference anchor="Writable-MIB-Module-IESG-Statement" target="https://www.ietf.org/iesg/statement/writable-mib-module.html">
<front>
<title>Writable MIB Module IESG Statement</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="YANG-Data-Model-for-L3VPN-service-delivery" target="https://tools.ietf.org/id/draft-l3vpn-service-yang">
<front>
<title>YANG Data Model for L3VPN service delivery</title>
<author/>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:19:16 |