Courtesy - Dave Tucker
What is NETCONF
NETCONF is defined in RFC 6241 which describes it as follows:
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs).
It's not a new technology, as work started on this approximately 10 years ago, but what it gives us is an extensible and robust mechanism for managing network devices.
NETCONF understands the difference between configuration data and state data. As somebody who has been bitten by trying to perform a create operation and faced validation issues as I've mistakenly sent (or worse, edited) a read-only field in a request, I feel this is really valuable.
Another great thing from an operations perspective is the ability to test/validate configuration before it's applied to the device. NETCONF allows you to set at test-option for an edit-config operation that will either test only, or test then set the configuration.
Being XML-based, we can also validate our NETCONF against an XML Schema Document (XSD).
NETCONF supports devices with multiple config datastores e.g running/startup or candidate/running/startup.
Furthermore, we can also subscribe to notifications or perform other Remote Procedure Calls (RPCs) using NETCONF.
What is YANG
YANG is defined in RFC 6020 which describes it as follows:
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
I am going to make a bold assertion here
Machines love XML
Human's do not love XML.
-- Dave Tucker
Unfortunately it's humans that write standards, and standards dictate data models. Therefore it's in our interest to have a modeling language that people unfamiliar with XML can use and this is where YANG really shines.
YANG is hierarchical (like XML) and supports all of the niceties of a programming language like re-usable types and groupings and more importantly, extensibility. It has a powerful feature called "Augmentation" that allow you to extend an existing tree with some additional information. As it's designed for NETCONF, it allows you to model NETCONF-specific items like additional RPC's and the contents of notifications.
YANG is supported by some awesome open source tooling like pyang.
NETCONF <3 font="" yang="">
NETCONF is XML-based, which means that somebody (your network vendor) needs to model their configuration structure appropriately (unless they cheat and use a CLI format). Yang is the perfect way to do this, and also acts as good user documentation when parsed through pyang.
Consider the following yang snippet:
It doesn't take too much brain power to work out that this is a list of interfaces, the unique key is interface-name, and each interface has a speed and duplex. The accompanying XML would then be:
My hope for NETCONF and YANG is that the IETF and other SDO's standardize as many data models as they can. In this way, we can have a standard set of models that can be used for true multi-vendor network management. We don't want hundreds of proprietary MIB files, and I hope that the ease of modeling in Yang will encourage this.
So what has this got to do with SDN?
Even in SDN, we still have persistent state on network devices. OpenFlow doesn't automatically configure itself which is why OF-Config, which uses NETCONF, was developed. Open vSwitch, the de-facto standard for virtual switching, uses Open vSwitch Database Management Protocol (OVSDB) defined in informational RFC7047 which uses JSON-RPC.
Where I see NETCONF adding value is that we have a single protocol for managing configuration for both the traditional, and software defined network. I also don't want to get in to an Open Source vs Open Standards debate, but when interoperability is concerned open standards are essential, and having a standard set of Yang models would be advantageous.
It also has one other benefit, enabled by RESTCONF. Device-level Northbound API standardization.
What is RESTCONF you say? RESTCONF is currently an IETF Draft.
This document describes a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF.
Now device-level NBI's aren't exactly SDN in my book, but they are pretty useful to Network DevOps. What RESTCONF does, is enable simple Yang models to be accessed over HTTP using RESTful-ish style.
Why is this so awesome?
NETCONF is really powerful, but it's a little cumbersome for small tasks. RESTCONF is the more nimble cousin which allow people that are already well-versed in a little REST-API work to perform small tasks without needing to learn an entirely new skill set. That's a real win for DevOps in my book.
What is NETCONF
NETCONF is defined in RFC 6241 which describes it as follows:
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs).
It's not a new technology, as work started on this approximately 10 years ago, but what it gives us is an extensible and robust mechanism for managing network devices.
NETCONF understands the difference between configuration data and state data. As somebody who has been bitten by trying to perform a create operation and faced validation issues as I've mistakenly sent (or worse, edited) a read-only field in a request, I feel this is really valuable.
Another great thing from an operations perspective is the ability to test/validate configuration before it's applied to the device. NETCONF allows you to set at test-option for an edit-config operation that will either test only, or test then set the configuration.
Being XML-based, we can also validate our NETCONF against an XML Schema Document (XSD).
NETCONF supports devices with multiple config datastores e.g running/startup or candidate/running/startup.
Furthermore, we can also subscribe to notifications or perform other Remote Procedure Calls (RPCs) using NETCONF.
What is YANG
YANG is defined in RFC 6020 which describes it as follows:
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
I am going to make a bold assertion here
Human's do not love XML.
-- Dave Tucker
Unfortunately it's humans that write standards, and standards dictate data models. Therefore it's in our interest to have a modeling language that people unfamiliar with XML can use and this is where YANG really shines.
YANG is hierarchical (like XML) and supports all of the niceties of a programming language like re-usable types and groupings and more importantly, extensibility. It has a powerful feature called "Augmentation" that allow you to extend an existing tree with some additional information. As it's designed for NETCONF, it allows you to model NETCONF-specific items like additional RPC's and the contents of notifications.
YANG is supported by some awesome open source tooling like pyang.
NETCONF <3 font="" yang="">
NETCONF is XML-based, which means that somebody (your network vendor) needs to model their configuration structure appropriately (unless they cheat and use a CLI format). Yang is the perfect way to do this, and also acts as good user documentation when parsed through pyang.
Consider the following yang snippet:
It doesn't take too much brain power to work out that this is a list of interfaces, the unique key is interface-name, and each interface has a speed and duplex. The accompanying XML would then be:
My hope for NETCONF and YANG is that the IETF and other SDO's standardize as many data models as they can. In this way, we can have a standard set of models that can be used for true multi-vendor network management. We don't want hundreds of proprietary MIB files, and I hope that the ease of modeling in Yang will encourage this.
So what has this got to do with SDN?
Even in SDN, we still have persistent state on network devices. OpenFlow doesn't automatically configure itself which is why OF-Config, which uses NETCONF, was developed. Open vSwitch, the de-facto standard for virtual switching, uses Open vSwitch Database Management Protocol (OVSDB) defined in informational RFC7047 which uses JSON-RPC.
Where I see NETCONF adding value is that we have a single protocol for managing configuration for both the traditional, and software defined network. I also don't want to get in to an Open Source vs Open Standards debate, but when interoperability is concerned open standards are essential, and having a standard set of Yang models would be advantageous.
It also has one other benefit, enabled by RESTCONF. Device-level Northbound API standardization.
What is RESTCONF you say? RESTCONF is currently an IETF Draft.
This document describes a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF.
Now device-level NBI's aren't exactly SDN in my book, but they are pretty useful to Network DevOps. What RESTCONF does, is enable simple Yang models to be accessed over HTTP using RESTful-ish style.
Why is this so awesome?
NETCONF is really powerful, but it's a little cumbersome for small tasks. RESTCONF is the more nimble cousin which allow people that are already well-versed in a little REST-API work to perform small tasks without needing to learn an entirely new skill set. That's a real win for DevOps in my book.
No comments:
Post a Comment