New Series of YANG, NETCONF, RESTCONF RFCs Published

0

The last couple of weeks were important weeks for the world of YANG, NETCONF, and RESTCONF, as 8 new IETF RFCs were published:

  • RFC 8525 on YANG Library
  • RFC 8526 on NETCONF Extensions to Support the Network Management Datastore Architecture
  • RFC 8527 on RESTCONF Extensions to Support the Network Management Datastore Architecture
  • RFC 8528 on YANG Schema Mount
  • RFC 8529 on YANG Data Model for Network Instances
  • RFC 8530 on YANG Model for Logical Network Elements
  • RFC 8519 on YANG Data Model for Network Access Control Lists (ACLs)
  • RFC 8520 on Manufacturer Usage Description Specification

Most of those RFCs (the six first ones) are not basic technology YANG modules but more of foundational building blocks in the world of automation. Let’s review what those specifications can do for you. Note also that this number of IETF YANG modules keeps growing, slowly but surely!

Network Management Datastore Architecture (NMDA)

This RFC [RFC8342] is not new, but worth reviewing to better understand those six new RFCs. With the revised NMDA model , the data objects are specified a single time, as opposed to multiple re-definitions in different branches such -config or -state. The independent instantiations can appear in different datastores (for example, one for a configured value
and another for an operationally used value). To understand more about NMDA, refer to this blog! From now, all published YANG modules at the IETF must be NMDA-compliant.

The YANG Library (RFC 8525 )

When connecting to a typical router (a server in the NETCONF/RESTCONF terminology), the YANG Library YANG module provides information about all supported YANG modules on that server, along with the supported datastores, and datastore schemas used by a network management server.

The big difference compared to the previous YANG Library in RFC 7895, which this RFC obsoletes is that this version supports the NMDA by listing all datastores supported by a network management server and the schema that is used by each of these datastores. The text summary of all the changes are documented here. Working with automation, equally important is the difference between the YANG module revisions between the two RFCs: hopefully the yangcatalog.org tooling is there to help.

NETCONF Extensions to Support the Network Management Datastore Architecture (RFC 8526)

This document updates the NETCONF specification [RFC6241] in order to enable NETCONF clients to interact with all the datastores supported by a server implementing the NMDA. The update both adds new <get-data> and <edit-data> operations and augments existing <lock>, <unlock>, and <validate> operations. It also updates the YANG specifications [RFC7950] in order to enable NETCONF clients to both discover which datastores are supported by the NETCONF server and determine which modules are supported in each datastore. The update requires NETCONF servers implementing the NMDA to support the YANG library [RFC8525].

RESTCONF Extensions to Support the Network Management Datastore Architecture (RFC 8527)

This document extends the RESTCONF protocol  [RFC8040] in order to support the NMDA. Practically, it enables RESTCONF clients to discover which datastores are supported by the RESTCONF server, determine which modules are supported in each datastore, and interact with all the datastores supported by the NMDA. Specifically, the update introduces new datastore resources, adds a new query parameter, and requires the usage of the YANG library [RFC8525] by RESTCONF servers implementing the NMDA.

YANG Schema Mount (RFC 8528)

Should a YANG module such as the” ietf-interfaces”  have a specific container for VRF because some routers have a VRF function? That’s a valid question that started this entire YANG schema mount discussion. If the answer would have been “YES”, then the implication would have been new revisions of all YANG modules, just in case of a VRF deployment.

Hopefully, the YANG schema mount solves this issue in a different way:  It allows for mounting one data model consisting of any number of YANG modules at a specified location of another (parent) schema. Unlike the existing “uses” and “augment” approaches in YANG, the mounted modules needn’t be specially prepared for mounting; consequently, existing modules such as “ietf-interfaces” can be mounted without any modifications. 

The basic idea of schema mount is to label a data node in the parent schema as the mount point and then define a complete data model to be attached to the mount point so that the labeled data node effectively becomes the root node of the mounted data model. Note that the mounted schema solution targets the implementation time and run time, as opposed to the design time.

YANG Model for Logical Network Elements (RFC 8530) and YANG Data Model for Network Instances (RFC 8529)

Those two RFCs support the configuration and operation of network devices that allow for the partitioning of resources from both, or either, management and networking perspectives. Both leverage the YANG functionality enabled by YANG Schema Mount [RFC8528] and are NMDA-compliant.

The first form of resource partitioning provides a logical partitioning of a network device where each partition is separately managed as essentially an independent network element that is “hosted” by the base network device. These hosted network elements are referred to as logical network elements, or LNEs, and are supported by the logical-network-element module defined in [RFC8530]. That module is used to identify LNEs and associate resources from the network device with each LNE. LNEs themselves are represented in YANG as independent network devices; each is accessed independently. Examples of vendor terminology for an LNE include logical system or logical router and virtual switch, chassis, or fabric.

The second form,  specified in [RFC8529], provides support for what are commonly referred to as VPN Routing and Forwarding (VRF) instances as well as Virtual Switch Instances (VSI). In this form of resource partitioning, multiple control-plane and forwarding/bridging instances are provided by and managed through a single (physical or logical) network device. This form of resource partitioning is referred to as a Network Instance (NI) and is supported by the network instance module defined below. Configuration and operation of each network instance is always via the network device and the network instance module.

YANG Data Model for Network Access Control Lists (ACLs)  (RFC 8519)

Managing Access List (ACL) has been a painful task for many many years, with a not insignificant risk of locking yourself out of the device (I see some of you smiling at this point). Finally, we now have an ACL YANG module, specifying rules to find a match on a packet and define actions that will be performed on the packet. It’s an extremely important YANG module as ACLs are used in many networking technologies such as Policy-Based Routing (PBR), firewalls, etc. but also in many service YANG modules.

Manufacturer Usage Description Specification (RFC 8520)

Manufacturer Usage Descriptions (MUD) provide a means for IoT devices
to signal to the network what sort of access and network functionality
they require to properly function, with an initial goal of protecting
the device from attacks, hence the link with the ACL YANG
module. Happy to see that MUD authors thought about the automation
with YANG day one. Manufacturers looking to reduce their threat
surface should take a good look.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.