One document matched: draft-bogdanovic-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-bogdanovic-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">
<organization>Juniper Networks</organization>
<address>
<email>deanb@juniper.net</email>
</address>
</author>
<date day="13" month="February" year="2015" />
<area>Operations and Management</area>
<workgroup>NETMOD</workgroup>
<abstract>
<t>More and more groups are using YANG to create network models, from
configuration to service models. Currently there is no good overview of
how to classify network models in general.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
</t>
<section title="Definitions and Acronyms">
<t>VRF: Virtual Routing and Forwarding</t>
<t>SDO: Standards Definition Organization</t>
<t>OSP: Open Source Project</t>
<t>VPWS: Virtual Private Wire Service</t>
<t>VPLS: Virtual Private LAN Service</t>
<t>BGP: Border Gateway Protocol</t>
<t>MPLS: MultiProtocol Label Switching</t>
<t>L2VPN: Layer 2 Virtual Private Network</t>
<t>IP: Internet Protocol</t>
<t>IPv4: Internet Protocol version 4</t>
<t>IPv6: Internet Protocol version 6</t>
<t>IETF: Interet Engineering Task Force</t>
<t>WG: Working Group</t>
</section> <!-- definitions -->
</section> <!-- intro -->
<section anchor="problem" title="Problem Statement">
<t>YANG is becoming de facto standard language for network modeling in the
industry. There is big adoption movement at the moment and many models are
being developed and published, by multiple SDOs, different consortiums,
ad hoc groups and OSP. Today there is no classification of models, there
are no clear guidelines on how to layer models on each other, or how to
classify existing or new models.
With this draft, author is proposing a new way for YANG model classifications.
</t>
</section> <!-- problem -->
<section anchor="layers" title="Network YANG data model layers">
<t>When developing models, there are two approaches possible, top down and
bottom up. Top down approach is driven by business requirements and bottom
up is driven by technological ones. In general, we can classify data models
into three categories:
</t>
<t><list style="empty">
<t>configuration</t>
<t>service</t>
<t>business</t>
</list></t>
<t>Base model for all other models is the configuration model. It describes
all configurable capabalities of the device and what device vendor exposes
for configuration. We can divide the configuration model into two types:
</t>
<t><list style="letters">
<t>vendor configuration model</t>
<t>standard configuration model</t>
</list></t>
<section anchor="config_models" title="Configuration models">
<section anchor="vendor" title="Vendor configuration model">
<t>Vendor configuration model is the superset for the network model
supported on the device. All other models are derived based on this
model. Although all vendors provide very similar functionality using
standards, implementations are different. One of basic examples are
dynamic routing protocols. We can see today two main types of routing
protocol configuration.
</t>
<t><list style="empty">
<t>protocol centric - all the protocol related config is contained
with the protocol itself. Especially in case of multiple instances
of the routing protocol running in different routing-instances
(routing-instance as described in core routing model <xref target="I-D.ietf-netmod-routing-cfg"/>),
all the routing-instance protocol config is contained in the
default routing instance.
</t>
</list>
</t>
<figure>
<artwork>
Router ospf 10
Default-metric 100
Address-family ipv4 vrf VRF1
Network x.x.x.x area 0
Address-family ipv4 vrf VRF2
Network x.x.x.x area 0
Address-family ipv4
Network x.x.x.x area 1
</artwork>
</figure>
<t><list style="empty">
<t>In term of YANG model, the routing protocol configuration will be
defined within the default routing-instance and the routing-protocol
config will contain multiple instances referring to other
routing-instances.
</t>
<t>VRF centric - All the protocol related config for a routing-instance
is contained within this routing-instance.
</t>
</list></t>
<figure>
<artwork>
Routing-instance VRF1 {
Protocols isis {
}
}
Routing-instance VRF2 {
Protocols isis {
}
}
</artwork>
</figure>
<t><list style="empty">
<t>In term of YANG model, the routing protocol configuration for a
routing-instance will be defined within the associated
routing-instance.
</t>
</list>
</t>
</section> <!--vendor -->
<section anchor="standard" title="Standard configuration model">
<t>With YANG we have a common language, that enables different
communities to express data models that are widely understandable
without lot of additional explanation. This enables different groups
to standardize data models and vendors to support them, which will
make it easier to for network operators to manage their network
configuration programmatically.
</t>
<t>IETF, as SDO, is really well positioned to standardize configuration
models. With a wide range of expertize found within its WGs focused on
protocol definitions. As IETF participants implement those protocols,
they have deep expertize about the implementation and finding a common
base standard configuration model between vendors should be a very
viable goal.
</t>
<t>The standard configuration model is a subset of vendor configuration
model. The standard configuration model can be broken into base model
and standard extension models, where the base is common data model and
standard extensions are standard features which can not be all
implemented by vendors. Example of standard base model is Access
Control List and routing filter is a standard extension on ACL. Or
another example: encryption algorithm is standard feature, but the
different types, like md5, hmac-md5, hmac-sha1, etc are standard
extensions, as it is not that all vendors have all encryption
algorithm types implemented.
</t>
</section> <!-- standard -->
</section> <!-- config_models -->
<section anchor="networkService" title="Network service models">
<t>As YANG is used to describe configuration models of a device, standard
and vendor proprietary models, the language can be used also to describe network
service models. Network service models are created by network operators
when they choose how to configure their network from technology point of
view. They decide which technology is best match for their business
needs and based on that create network service data models. With more and
more configuration models being available, both vendor and standards one,
network service model developer can create reusable components based on
the configuration models, and use those service components data models to
create end to end service model.
</t>
<section anchor="component" title="Service component data model">
<t>Service component is specific way how operator is using configuration options
in the data model to create part of a service. Such example can be iBGP.
Full BGP configuration model is available as vendor and standard models,
but service model developer has a choice to create iBGP as separate
service component that can be reused in other models. There can be multiple
iBGP service component models, as not all service model developers have to
use same abstraction, and it can be helpful to have multiple models
developed that cover different use cases.
</t>
</section> <!-- component -->
<section anchor="service" title="Network service data model">
<t>Network service data models can be developed in multiple ways. Building
them monolithic from vendor models or by combining one or more service
components into an end to end service data model. It specifies complete
service that is provided by the network operator. Building monolithic
network service model has an advantage of doing it fast, but at the expense
of flexibility of updating the service later or switching vendors.
Such an end to end service can be VPLS/VPWS L2VPN, IPsec, etc. If we take
into example VPLS L2VPN service,
</t>
</section> <!-- service -->
</section> <!-- networkService -->
<section anchor="business" title="Business service model">
<t>Business service models are the top level and are very customer specific.
Vendors don't know what is important to the carrier from OSS perspective. That
is known to the network operator and their customer specific use cases.
Business service developer can create a very high level model, for example:
customer LAN service
</t>
<figure>
<artwork>
container customer {
description “adding metro LAN customers”
leaf customer-name{
description virtual LAN customer name";
type string;
}
leaf interface-name{
description “metro LAN customer interface”
type interface-name;
}
leaf site-name{
description “customer site name";
type string;
}
}
</artwork>
</figure>
<t>The model above is a simple business model. It can be exposed to external
applications that can very effecitively create a new service. The application
developer doesn't have to know the underlying technology used, as it potentially
would have no meaning if exposed as network service model name VPLS L2VPN. The
network service model might have some parameters that would have no meaning to
the end developer, like route-distiguisher, vrf-target, instance-type.
These parameters can be very effectively hidden from the high level business
service API consumer.
</t>
</section> <!-- business -->
</section> <!-- layers -->
<section anchor="dependencies" title="Dependencies between models">
<t>As mentioned earlier in this document, there are two ways of designing
models, top down and bottom up with one restriction. Everything is dependent
on the vendor data model. That model describes all the possibilities and if
model developers prefers, they can use vendor model only to design service
components, network service and business service. Using vendor model provides
all capabilities today, but it comes with restrictions of portability between
vendors and to certain extent devices.
On the other hand, only standard models and standard extensions can be used,
but this might result in less feature rich or less efficient services.
Service model developer has a choice to reuse service components or write
a model completely based on vendor data model.
</t>
<figure>
<artwork>
+----------------------------------------------------------------+
| vendor data model |
| |
| +------------------------+ +--------------------+ |
| | standard data model | |standard extensions | |
| +------------------------+ +--------------------+ |
| |
| +--------------------------------------------------------+ |
| |network service model | |
| | +---------------------+ +----------------------+ | |
| | | service component | | service component | | |
| | | model | | model | | |
| | | | | | | |
| | +---------------------+ +----------------------+ | |
| | +-------------------------+ | |
| | | business service model | | |
| | +-------------------------+ | |
| +--------------------------------------------------------+ |
+----------------------------------------------------------------+
</artwork>
</figure>
</section> <!-- dependencies -->
<section anchor="final" title="Network Model layers">
<t>With the explanation of varios network data models above, here is the complete
list.
</t>
<t><list style="numbers">
<t>vendor configuration model</t>
<t>standard configuration model</t>
<t>service component</t>
<t>service model</t>
<t>business service model</t>
</list></t>
<t>and graphical representation
</t>
<figure align="center">
<artwork align="center"><![CDATA[
business service models ------------------------------------------------
+-----------------------+
| |
| metro ethernet |
| service |
| |
+-----------------------+
service models ---------------------------------------------------------
+------------+ +-------------+
| | | |
| VPWS | | VPLS |
| L2VPN | | L2VPN |
| | | |
+------------+ +-------------+
service component models -----------------------------------------------
+--------------+ +-------------+ +------------+
| Service | | | | |
| Interface | | LDP | | iBGP |
| | | | | |
+--------------+ +-------------+ +------------+
standard configuration models ------------------------------------------
+--------------+ +------------+ +--------------+ +-------------+
| | | | | | | |
| MPLS | | BGP | | Interface | | Routing |
| | | | | | | |
+--------------+ +------------+ +--------------+ +-------------+
vendor configuration models --------------------------------------------
+--------------+ +-------------+ +---------------+
| | | | | |
| vendor A | | vendor C | | vendor J |
| | | | | |
+--------------+ +-------------+ +---------------+
]]></artwork>
</figure> <!-- YANG model layers -->
<t>There are no hard requirements on how to do the modeling, but it would be
useful to have a classification and to create models that can be easily reused,
as with this time and energy will be saved in future development. We should
stimulate both development styles, bottom up and top down, as each has its
benefits and groups to which a certain style will be more appealing then the
other.
</t>
</section> <!-- final -->
<section anchor="security" title="Security Considerations">
<t>At this stage, author 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></t>
</section> <!-- ack -->
<section anchor ="changes" title="Change log [RFC Editor: Please remove]">
<t></t>
</section> <!-- changes -->
</middle>
<back>
<references title="References">
<?rfc include='reference.RFC.6020'?>
<?rfc include='reference.RFC.6241'?>
<?rfc include='reference.RFC.6242'?>
<?rfc include='reference.RFC.6536'?>
<?rfc include='reference.I-D.ietf-netmod-routing-cfg'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:50:28 |