Automation & Programmability
Showing results for 
Search instead for 
Do you mean 

Netconf and YANG – explained in a layman’s term

by Juniper Employee ‎08-19-2015 11:30 PM - edited ‎09-03-2015 05:15 AM

I’ve seen that whenever I try explaining about Netconf and YANG to those who are new to these terms, most of them do not seem to completely understand it. I try drawing parallels between SNMP/ASN/MIBs and Netconf/YANG/YANG-models, but I can then see eyes glazing over.

 

Being a mom of two school going kids, I usually end up explaining things to my kids in ways that they understand. So I took the challenge on how would I teach them about what is Netconf and YANG.

 

Let’s forget the networking world for now, and just look at a communication problem that we humans have solved. Now imagine that I am a teacher in a class. I can communicate with the students either by talking, writing or using sign language. At the start of the class, we decide that the protocol to communicate will be verbal communication, i.e., I will teach the class by talking.

 

Now let’s look at this class where there are three students. I as the teacher know to talk only in English. As the students, Sara knows only French, Stefan knows only German and Sophie knows only Spanish.

 

Scene#1:

 

I am teaching the class by talking in English, however Sara, Stefan and Sophie cannot understand anything that I say. This is an unsuccessful class, with total chaos.

 

 

 

 

 

 

Scene#2:

I as the teacher take the onus of explaining things to every student in their language. So I talk to Sara in French, Stefan in German and Sophie in Spanish. It certainly makes my job as a teacher very complex. Now if a fourth student comes to the class and let’s say she speaks Japanese, I as a teacher will first have to learn that language. At some point of time, my brain becomes the bottleneck to accommodate new students in the class, because every time I have to learn a new language, and my brain becomes so complex that I start mixing up things.

 

Scene#3:

We decide to adopt English as the choice of language for this class. Now even here, we have different flavors (dialects) of English – Singlish, Hinglish, Queen’s-English, US-English. And before the class, we freeze on the flavor of English. I decide to teach the class in Queen’s-English. Every student has to ensure that they understand this language.

Which means that I am teaching in Queen’s-English, and Sara now understands Queen’s-English. Her brain does the Queen’s-English to French translation and registers the information being disseminated in the class. Same with Stefan and Sophie, where they now understand Queen’s-English. Now, this is a perfect class!

 

Simple and this is all common sense!

 

Now let’s come back to the networking world.

 

In the classroom the first decision was to choose a protocol to communicate. In this case we chose ‘talking’. The same way, a Network Management entity can talk to network devices in many ways – CLI screen scraping, SNMP, XML, APIs. Netconf is the IETF defined protocol for the Network Management entity to talk to the network devices. So, with this the Network Management entity does not have to talk to every vendor’s box in a different way. It uses Netconf as the standard protocol to talk to all networking devices.

 

Now, even though vendorA, vendorB, vendorC claim that they all support Netconf, a Network Management entity still has to configure BGP in different ways on these three boxes. This is the same problem as the classroom scene#2, where the teacher has to talk to every student in his or her language. This is where YANG comes into picture. YANG is an IETF defined data modeling language that describes how config and operational data is structured. Using YANG as the language, one can define YANG models, which define how config or commands for certain network functionality will look. (Think of YANG as the English alphabet and grammar, and YANG-model as Queen’s-English)

 

With vendorA, vendorB and vendorC now supporting YANG, the Network Management entity needs to configure BGP in just one way, as defined in the common BGP YANG model, and all these network devices will understand that config.

 

Isn’t this perfect? Because now the Network Management entity does not have to change whenever a new vendor is added to the network, and there is no device specific intelligence in the Network Management entity. This is same as the class in scene#3.

 

NETCONF == talking

YANG == alphabet and grammar rules of English

YANG models == any of Hinglish, Singlish, Queen’s English

IETF YANG Model == Queen’s English

 

So if this is common sense, why is it that we still don’t have this supported yet by all vendors?

 

In these series of blogs, Nilesh and I will explain how the concept of Netconf and YANG has been ingrained in Junos right from day-one, how introducing new YANG models is super easy on Junos and also walk through some of the YANG features in Junos.

 

(Next of the series posted here)

Comments
by Juniper Employee
on ‎08-20-2015 08:12 AM

Thanks Pallavi for making it so simple to underdtand...  looking forward to more  in the future .. 

by Juniper Employee
on ‎08-20-2015 11:53 AM

excellent and quick intro to Netconf & Yang. Thanks Pallavi !

Naren

by Juniper Employee
on ‎08-20-2015 02:11 PM

Excellent explanation!  Now if only we can get these analogies going for the rest networking Smiley Wink

by chinar.trivedi
on ‎08-20-2015 09:57 PM
Hi Pallavi, I was lucky enough to attend this presentation yesterday by you at Juniper Bangalore office YANG , which I thought is a complex thing was so much simplified by that Teacher-Student analogy. Keep up the good work of making our SPs Network manageability easy. Hope Yang works someday but again that shouldn't nullfy my JunOS CLI expertise I have gained Smiley Tongue Cheers
by vvijay
on ‎08-28-2015 11:24 PM

Excellent article! This is how complex topics should be explained so that people can overcome initial apprehensions of new technology and start embracing it


pallavi wrote:

I’ve seen that whenever I try explaining about Netconf and YANG to those who are new to these terms, most of them do not seem to completely understand it. I try drawing parallels between SNMP/ASN/MIBs and Netconf/YANG/YANG-models, but I can then see eyes glazing over.

 

Being a mom of two school going kids, I usually end up explaining things to my kids in ways that they understand. So I took the challenge on how would I teach them about what is Netconf and YANG.

 

Let’s forget the networking world for now, and just look at a communication problem that we humans have solved. Now imagine that I am a teacher in a class. I can communicate with the students either by talking, writing or using sign language. At the start of the class, we decide that the protocol to communicate will be verbal communication, i.e., I will teach the class by talking.

 

Now let’s look at this class where there are three students. I as the teacher know to talk only in English. As the students, Sara knows only French, Stefan knows only German and Sophie knows only Spanish.

 

Scene#1:

 

I am teaching the class by talking in English, however Sara, Stefan and Sophie cannot understand anything that I say. This is an unsuccessful class, with total chaos.

 

 

 

 

 

Scene#2:

I as the teacher take the onus of explaining things to every student in their language. So I talk to Sara in French, Stefan in German and Sophie in Spanish. It certainly makes my job as a teacher very complex. Now if a fourth student comes to the class and let’s say she speaks Japanese, I as a teacher will first have to learn that language. At some point of time, my brain becomes the bottleneck to accommodate new students in the class, because every time I have to learn a new language, and my brain becomes so complex that I start mixing up things.

 

Scene#3:

We decide to adopt English as the choice of language for this class. Now even here, we have different flavors (dialects) of English – Singlish, Hinglish, Queen’s-English, US-English. And before the class, we freeze on the flavor of English. I decide to teach the class in Queen’s-English. Every student has to ensure that they understand this language.

Which means that I am teaching in Queen’s-English, and Sara now understands Queen’s-English. Her brain does the Queen’s-English to French translation and registers the information being disseminated in the class. Same with Stefan and Sophie, where they now understand Queen’s-English. Now, this is a perfect class!

 

Simple and this is all common sense!

 

Now let’s come back to the networking world.

 

In the classroom the first decision was to choose a protocol to communicate. In this case we chose ‘talking’. The same way, a Network Management entity can talk to network devices in many ways – CLI screen scraping, SNMP, XML, APIs. Netconf is the IETF defined protocol for the Network Management entity to talk to the network devices. So, with this the Network Management entity does not have to talk to every vendor’s box in a different way. It uses Netconf as the standard protocol to talk to all networking devices.

 

Now, even though vendorA, vendorB, vendorC claim that they all support Netconf, a Network Management entity still has to configure BGP in different ways on these three boxes. This is the same problem as the classroom scene#2, where the teacher has to talk to every student in his or her language. This is where YANG comes into picture. YANG is an IETF defined data modeling language that describes how config and operational data is structured. Using YANG as the language, one can define YANG models, which define how config or commands for certain network functionality will look. (Think of YANG as the English alphabet and grammar, and YANG-model as Queen’s-English)

 

With vendorA, vendorB and vendorC now supporting YANG, the Network Management entity needs to configure BGP in just one way, as defined in the common BGP YANG model, and all these network devices will understand that config.

 

Isn’t this perfect? Because now the Network Management entity does not have to change whenever a new vendor is added to the network, and there is no device specific intelligence in the Network Management entity. This is same as the class in scene#3.

 

NETCONF == talking

YANG == alphabet and grammar rules of English

YANG models == any of Hinglish, Singlish, Queen’s English

IETF YANG Model == Queen’s English

 

So if this is common sense, why is it that we still don’t have this supported yet by all vendors?

 

In these series of blogs, Nilesh and I will explain how the concept of Netconf and YANG has been ingrained in Junos right from day-one, how introducing new YANG models is super easy on Junos and also walk through some of the YANG features in Junos.



.

by Juniper Employee
on ‎09-09-2015 10:55 AM

Great Article on YANG.  Thank you for posting.  Hope to see more.

by Juniper Employee
on ‎09-22-2015 10:49 PM

Very nicely put

Announcements

Juniper Design & Architecture Center - Mobile Cloud
About the Author
  • Ben has been working with service providers around the world for the last 15 years developing business cases for a variety of product concepts and new ventures. Ben holds an MBA from MIT and a BS & MS in Mechanical Engineering from Johns Hopkins University.
  • Part of Juniper PS EMEA since 2005 Primarily interested in making technology do the boring repetitive work so I can do fun new work.
  • Donyel Jones-Williams is the Director of Service Provider Product Marketing Management overseeing all of Juniper's Service Provider Products for Juniper Networks. In this role, he leads all of the internal and external marketing activities for Juniper with respect to routing, automation, SDN and NFV. Prior to joining Juniper Networks in January 2014, Donyel was a Senior Product Line Manager for Cisco Systems with in the High End Optical Routing Group managing product lifecycle for multiple products lines helping telecom providers operate efficiently and effectively including; ONS 155xx Product Family, ONS 15216, ONS 15454 MSTP, Carrier Packet Transport Product Family, ME 2600x, & ASR 9000v. He also negotiated favorable agreements with 3rd-party vendors furnishing components and parts and conducted both outbound and inbound marketing (webinars, case study-development, developed and delivered both business & technical at Cisco Live 2005-2012). Donyel graduated from California Polytechnic State University-San Luis Obispo with a Bachelor of Science in Computer Science. While attending Cal Poly SLO he was a collegiate student athlete playing football as a wide receiver and a key member of the National Society of Black Engineers. Donyel is now an active volunteer for V Foundation.
  • Ebben Aries is a Principal Engineer for Junos Manageability in the Juniper Development and Innovation Division.
  • Michael Pergament, JNCIE-SP #510, JNCIE-ENT #23, JNCIP-SEC
  • Pallavi Mahajan is Vice President Engineering, Junos Engineering, and leads the Junos Programmability & Automation teams
  • Product Manager, JUNOS Automation