Editorial StaffI was at the 92nd IETF meeting in Dallas a few weeks ago. I attended 16 sessions, mostly in the routing area, and every single one had a discussion about the YANG data model (indeed most had several such discussions).
YANG is the data modeling language for the NETCONF protocol. NETCONF/YANG was picked by the Interface to Routing System (I2RS) Working Group for an SDN controller to interact with IP/MPLS routers. It makes an IP/MPLS network programmable. There are other IETF protocols in play as well, such as Path Computation Element Protocol (PCEP). To make SDN management service aware, we need to bind these paths to the services they are intended for. This is where NETCONF/YANG data models come to the rescue. I was very pleased to see the attention NETCONF/YANG data models got at the IETF.
One thing that can hinder quick adoption and implementation for some data models is competing proposals. Indeed, some camps have formed around competing proposals. This is not unusual in the IETF. Different Internet-drafts (documents intended to be adopted by working groups as standards) are first presented at the working groups. Often, the authors are requested to work together to align their drafts before a working group considers it for adoption.
One such camp with many data model drafts is the OpenConfig group led by engineers at Google and several operators including BT, Level 3, AT&T and Microsoft. The other camp is by the usual router vendors (at times different vendors had competing drafts as well). When a presenter from the OpenConfig group was asked to align their draft with a competing draft, they unfortunately stated that they wanted to keep their document independent for the time being “in order to experiment with it independently.” I do sympathize with the OpenConfig group’s desire to have the best data models for their operational use cases without being hindered by competing proposals. Hopefully, this will not slow down adoption too much.
One issue around the OpenConfig data models is that it tries to unify all vendor features. The fear here is that their model may become the “least common denominator” with features supported by all the vendors. Vendors need to have different feature sets to differentiate themselves from each other. Of course, Packet Design welcomes a single unified model. However, in our modeling experience over the last 10+ years, we realized the router vendors have different feature sets, and had to model the union of the features across the router vendors we support. Indeed, our customers are diverse and use different vendor features.
Then, there is the issue of ephemeral state. This is a criticism of the NETCONF protocol. It was originally intended for configuring IP/MPLS routers. The configuration is permanent. Once written, even if the router restarts (gracefully or perhaps after a crash), it will be remembered. Whereas in an SDN world, an application makes a request to the controller and as a result the changes (a new path establishment or a new service introduction) should not survive past the application’s lifetime. These kinds of changes are called ephemeral. NETCONF needs to address this drawback for it to be fully applicable to SDN.
Overall, I was very pleased to see very rapid progress by our industry. The new NETCONF/YANG data models are the right step towards making SDN management service aware.
Add comment