YANG model classification
draft-bogdanovic-netmod-yang-model-classification-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Dean Bogdanović | ||
| Last updated | 2015-02-13 | ||
| Replaced by | draft-ietf-netmod-yang-model-classification, draft-ietf-netmod-yang-model-classification, RFC 8199 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bogdanovic-netmod-yang-model-classification-00
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
Abstract
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.
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 August 17, 2015.
Copyright Notice
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.
Bogdanovic Expires August 17, 2015 [Page 1]
Internet-Draft YANG model classification February 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Network YANG data model layers . . . . . . . . . . . . . . . 3
3.1. Configuration models . . . . . . . . . . . . . . . . . . 3
3.1.1. Vendor configuration model . . . . . . . . . . . . . 3
3.1.2. Standard configuration model . . . . . . . . . . . . 4
3.2. Network service models . . . . . . . . . . . . . . . . . 5
3.2.1. Service component data model . . . . . . . . . . . . 5
3.2.2. Network service data model . . . . . . . . . . . . . 6
3.3. Business service model . . . . . . . . . . . . . . . . . 6
4. Dependencies between models . . . . . . . . . . . . . . . . . 7
5. Network Model layers . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
1.1. Definitions and Acronyms
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
Bogdanovic Expires August 17, 2015 [Page 2]
Internet-Draft YANG model classification February 2015
IETF: Interet Engineering Task Force
WG: Working Group
2. Problem Statement
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.
3. Network YANG data model layers
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:
configuration
service
business
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:
a. vendor configuration model
b. standard configuration model
3.1. Configuration models
3.1.1. Vendor configuration model
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.
Bogdanovic Expires August 17, 2015 [Page 3]
Internet-Draft YANG model classification February 2015
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
[I-D.ietf-netmod-routing-cfg]), all the routing-instance protocol
config is contained in the default routing instance.
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
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.
VRF centric - All the protocol related config for a routing-
instance is contained within this routing-instance.
Routing-instance VRF1 {
Protocols isis {
}
}
Routing-instance VRF2 {
Protocols isis {
}
}
In term of YANG model, the routing protocol configuration for a
routing-instance will be defined within the associated routing-
instance.
3.1.2. Standard configuration model
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
Bogdanovic Expires August 17, 2015 [Page 4]
Internet-Draft YANG model classification February 2015
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.
3.2. Network service models
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.
3.2.1. Service component data 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.
Bogdanovic Expires August 17, 2015 [Page 5]
Internet-Draft YANG model classification February 2015
3.2.2. Network service data model
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,
3.3. Business service model
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.
Bogdanovic Expires August 17, 2015 [Page 6]
Internet-Draft YANG model classification February 2015
4. Dependencies between models
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 | | |
| | +-------------------------+ | |
| +--------------------------------------------------------+ |
+----------------------------------------------------------------+
5. Network Model layers
With the explanation of varios network data models above, here is the
complete list.
1. vendor configuration model
2. standard configuration model
3. service component
4. service model
Bogdanovic Expires August 17, 2015 [Page 7]
Internet-Draft YANG model classification February 2015
5. business service model
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 |
| | | | | |
+--------------+ +-------------+ +---------------+
Bogdanovic Expires August 17, 2015 [Page 8]
Internet-Draft YANG model classification February 2015
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.
6. Security Considerations
At this stage, author of the draft didn't look into security
considerations.
7. IANA Considerations
This document requests no action by IANA.
8. Acknowledgements
9. Change log [RFC Editor: Please remove]
10. References
[I-D.ietf-netmod-routing-cfg]
Lhotka, L., "A YANG Data Model for Routing Management",
draft-ietf-netmod-routing-cfg-16 (work in progress),
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.
Author's Address
Dean Bogdanovic
Juniper Networks
Email: deanb@juniper.net
Bogdanovic Expires August 17, 2015 [Page 9]