Skip to content

NMDA Existing Model Migration FAQ

Jump to bottom
Robert Wilton edited this page Sep 7, 2017 · 4 revisions

This page provides answers for common questions related to migrating existing models to NMDA style models.

Table of Contents

  1. When is it necessary to wait for updated versions of non-NMDA style published model before updating an augmenting model to conform to NMDA?
  2. If we have an non-NMDA draft in progress then is it OK to publish the non NMDA model followed by an NMDA version?
  3. Which YANG modules already specified need to be updated to be NMDA compliant?
  4. What happens to the old config false "-state" tree in a published YANG module when a NMDA compatible revision is produced?

Questions

Q 1. When is it necessary to wait for updated versions of non-NMDA style published models (e.g. ietf-interfaces.yang) before updating an augmenting model to conform to NMDA?

It is only necessary to wait if the augmenting model needs to augment a container in the state tree that has no direct equivalent in the config tree. This is perhaps best illustrated through two examples:

  1. If an existing model augments if:interfaces-state and needs to move to NMDA structure, then it can be changed to augment if:interfaces instead, and it has no direct dependency on an updated version of ietf-interfaces.yang.
  2. However, If an existing model augments if:interfaces-state/statistics and needs to move to NMDA structure, then it must wait until an updated version of ietf-interfaces.yang is available that provides the equivalent if:interfaces/statistics container to augment from.

Q 2. If we have an non-NMDA draft in progress then is it OK to publish the non NMDA model followed by an NMDA version?

No, this is not recommended because it is likely to cause confusion in the industry. It is unlikely to increase market adoption because implementors are likely to know that the module will soon be updated to be NMDA compliant, perhaps requiring a non backwards compatible v2 version. Instead, if the model is still in draft form it should be immediately updated to NMDA style before being published, and if necessary, an additional transient "-state" module could be published. E.g. as described in NMDA Modelling FAQ. This allows everyone to work with the long term model structure now.

Q 3. Which YANG modules already specified need to be updated to be NMDA compliant?

Existing YANG Module RFC Status Updated NMDA YANG Module (if available)
ietf-interfaces@2014-05-08.yang 7223 ID bis available ietf-interfaces@2017-08-17.yang (from bis draft)
ietf-ip@2014-06-16.yang 7277 ID bis available ietf-ip@2017-08-21.yang (from bis draft)
ietf-routing@2016-11-04.yang 8022 ID bis available tbd (from bis draft)
ietf-ipv4-unicast-routing@2016-11-04.yang 8022 ID bis available tbd (from bis draft)
ietf-ipv6-unicast-routing@2016-11-04.yang 8022 ID bis available tbd (from bis draft)
ietf-ipv6-router-advertisements@2016-11-04.yang 8022 ID bis available tbd (from bis draft)
ietf-netconf-monitoring@2010-10-04.yang 6022 Unclear if updates are required tbd
ietf-netconf-time@2016-01-26.yang 7758 Experimental, no current plans to migrate to NMDA not applicable
ietf-restconf-monitoring@2017-01-26.yang 8040 Unclear if any updated is required, otherwise covered by draft-ietf-netconf-nmda-restconf tbd
ietf-system@2014-08-06.yang 7317 tbd, requried for IEEE modules tbd
ietf-yang-library@2016-06-21.yang 7895 WG adopted bis draft-ietf-netconf-rfc7895bis Contained in bis document

Note: No update to ietf-restconf@2017-01-26.yang is required because it does not define any data nodes.

Q 4. What happens to the old config false "-state" tree in a published YANG module when a NMDA compatible revision is produced?

The specific YANG rules for updating existing modules are specified in RFC 7950 section 11. These rules apply for any YANG module that has been published (i.e. is within an RFC or other published standard).

Hence in the NMDA compatible module, all nodes in the any existing "-state" tree should be explicitly marked as "deprecated". In a future revision, the deprecated nodes could be marked as "obsolete". Perhaps they could be removed entirely in a future revision, but this would require a change to the module update rules currently specified in RFC 7950.

To help ensure that the module doesn't become cluttered, the deprecated definitions could be moved to a separate sub-module - this is a completely backwards compatible change.

Clone this wiki locally