| NETMOD | D. Bogdanovic |
| Internet-Draft | Juniper Networks |
| Intended status: Informational | February 13, 2015 |
| Expires: August 17, 2015 |
YANG model classification
draft-bogdanovic-netmod-yang-model-classification-00
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.
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 August 17, 2015.
Copyright (c) 2015 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.
VRF: Virtual Routing and Forwarding
SDO: Standards Definition Organization
OSP: Open Source Project
VPWS: Virtual Private Wire Service
VPLS: Virtual Private LAN Service
BGP: Border Gateway Protocol
MPLS: MultiProtocol Label Switching
L2VPN: Layer 2 Virtual Private Network
IP: Internet Protocol
IPv4: Internet Protocol version 4
IPv6: Internet Protocol version 6
IETF: Interet Engineering Task Force
WG: Working Group
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.
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:
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:
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.
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
Routing-instance VRF1 {
Protocols isis {
}
}
Routing-instance VRF2 {
Protocols isis {
}
}
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.
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.
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.
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.
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.
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,
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
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;
}
}
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.
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.
+----------------------------------------------------------------+
| vendor data model |
| |
| +------------------------+ +--------------------+ |
| | standard data model | |standard extensions | |
| +------------------------+ +--------------------+ |
| |
| +--------------------------------------------------------+ |
| |network service model | |
| | +---------------------+ +----------------------+ | |
| | | service component | | service component | | |
| | | model | | model | | |
| | | | | | | |
| | +---------------------+ +----------------------+ | |
| | +-------------------------+ | |
| | | business service model | | |
| | +-------------------------+ | |
| +--------------------------------------------------------+ |
+----------------------------------------------------------------+
With the explanation of varios network data models above, here is the complete list.
and graphical representation
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 |
| | | | | |
+--------------+ +-------------+ +---------------+
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.
At this stage, author of the draft didn't look into security considerations.
This document requests no action by IANA.
| [I-D.ietf-netmod-routing-cfg] | Lhotka, L., "A YANG Data Model for Routing Management", Internet-Draft draft-ietf-netmod-routing-cfg-16, October 2014. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. |
| [RFC6242] | Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011. |
| [RFC6536] | Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012. |