draft-clacla-netmod-yang-model-update-02 New YANG Module Update Procedure draft-clacla-netmod-yang-model-update-02 Benoît Claise, Cisco Joe Clarke, Cisco Kevin D'Souza, AT&T Netmod WG November 15, 2017

Problem Illustrated

Problem Illustrated

Problem Illustrated Area of confusion. E.g., ietf-rip shows a dependency to both ietf-routing and ietf-routing-2 since there is no explicit linkage between the two.

Problem Explication Background: ietf-routing-2 has been renamed to ietf-routing, so not really an issue Not a new problem, but the first occurrence in the IETF (openconfig mentioned this) Have to warn all ietf-routing dependent YANG module authors that they have to import a different YANG module now Btw, had to create a script from the yangcatalog to get those email addresses Industry-wide issue: cross SDO, cross opensource, cross vendors From a tooling point of view, no way to know that YANG module-B updates/obsoletes YANG module-A Without going the RFC header tag

Sources of the Problem Let’s re-think our YANG module update strategy YANG “updating a module” rules are strict in term of backward compatibility The YANG module (structure) have to be perfect Slow Standardization As a consequence of the YANG update rules Some YANG modules are not backward compatible. It’s a fact Ex: L3VPN Ex: some “native” models Let’s re-think our YANG module update strategy 

The Bigger Problem/End Goal: Service Composition Operators want to automate services Services YANG modules maps to multiple device YANG modules Potentially from multiple sources Service creation: which YANG module work together? Which YANG modules work together (“release bundle”, “package”) Testing and/or metadata (tree-type/dependency) Service maintenance/upgrade Mapping to all YANG paths Impact to my service if I upgrade a device? Path change? In case of non backward compatible YANG modules, is my service impacted? Let’s re-think our YANG module update strategy 

Proposed Solution We relax the YANG update rules: "As experience is gained with a module, it may be desirable to revise that module. Changes to published modules are allowed, even if they have some potential to cause interoperability problems, at the condition that the semantic versioning change are clearly indicated based on the SEMVER YANG extension.” Keep the same YANG module name SEMVER extension in YANG module MAJOR is incremented when the new version of the specification is incompatible with previous versions. MINOR is incremented when new functionality is added in a manner that is backward-compatible with previous versions. PATCH is incremented when bug fixes are made in a backward- compatible manner Note: based on an openconfig previous proposal

Tracking Module Changes ietf-interfaces@2013-12-23 ietf-interfaces@2017-08-17 Derived-semantic-version is determined using: Order all modules of the same name by revision from oldest to newest. If module A, revision N+1 has failed compilation, bump its derived semantic MAJOR version. Else, run "pyang --check-update-from" on module A, revision N and revision N+1 to see if backward-incompatible changes exist. If backward-incompatible changes exist, bump module A, revision N+1's derived MAJOR semantic version. If no backward-incompatible changes exist, compare the pyang trees of module A, revision N and revision N+1. If there are structural differences (e.g., new nodes), bump module A, revision N+1's derived MINOR semantic version. If no structural differences exist, bump module A, revision N+1's derived PATCH semantic version.

Which problem does it solve? YANG modules backward compatibility Automation oolchain works Experiment in yangcatalog.org Fit well in the service composition concept No YANG path update with new YANG modules SEMVER composition of any new YANG modules

Open Issues Next to “import by revision” (though this is seldom used), do we need import by semantic version: "version==X", "version>=X", "major version==X", "major version>=X", etc. A new naming convention for modules? Today, modules are named in module@revision.yang notation.  Re-using the '@' for version is not ideal.  Perhaps a new character such as '%' is needed (i.e., module%version.yang).  In this manner, both version and revision could be used. module bundle/package? modules that are part of a bundle and are known to interoperate.  A new kind of import is required.  Today, we have import by revision (though this is seldom used).  There should also be an import by module-version (i.e., the semantic version).  This import will not simply be a copy of import by revision.  Consideration needs to be given to expressions such as "version==X", "version>=X", "major version==X", "major version>=X", etc. Similarly to import-by-version, we may also require a new naming convention for modules.  Today, modules are named in module@revision.yang notation.  Re-using the '@' for version is not ideal.  Perhaps a new character such as '%' is needed (i.e., module%version.yang).  In this manner, both version and revision could be used. Taking another page from Openconfig, the notion of a module bundle should be considered.  That is, there may need to be a way to enumerate modules that are part of a bundle and are known to interoperate.  This may not be as critical if a rich import-by-version is defined. Similarly, the concept of a feature bundle should be considered.  Typically, operators combine and test YANG modules to build value-add services.  These bundles form releases for specific features or services, and it is critical to ensure as the modules evolve, the bundles can coherently evolve with them.